Operations management Excel decision tree model

¶ … HTEK Solutions Inc. is a research and development firm that specializes in navigation products and aerial survey equipment. The company has operations in several locations around the country. The Hawaii division is in charge of the development of the QNAV. This research and development is carried out in Hawaii because of the strong Geomatics department at the University of Hawaii. The Hawaii group consists of five engineers, each of whom plays an important role in the design of the QNAV product.

QNAV combines GPS and IMU data to form an inertially-aided navigation system, used primarily with aerial digital and LIDAR cameras. The data collected from the QNAV 20 is used to stabilize the camera/laser system in real time and aids in rectifying the data through post-mission post-processing. The QNAV project is a key component in HTEK's portfolio because it is bundled with every airborne digital and LIDAR camera that is sold. HTEK also markets QNAV as a standout product in the OEM market. Prior to QNAV, HTEK used a similar technology from SNAV. However, that company was purchased by one of QNAV's major competitors in the airborne market, necessitating the development of in-house technology.

Description of the Problem

The initial development of QNAV technology was rapid, because of HTEK's desire to cease purchases of SNAV in the shortest time possible. The main decision-making criterion during the initial development phase was time-to-market, with other considerations subordinated. One outcome of this decision-making strategy was pieces of existing software were ported to a real-time environment to reduce development time. The company knew that this was a temporary solution. Once QNAV was functional, the company could then take more time and outline a more sophisticated plan for future development. At this point, QNAV is functional and HTEK needs to decide on the best course of action for proceeding with the software development. This decision is important because the QNAV product is integrated into some of HTEK's other products; therefore the corporate strategy of HTEK is tied in part to the future of QNAV.

Three main alternatives have been identified: do nothing; rewrite the code; and update the hardware as well as rewrite the code. The "do nothing" option has the advantage of requiring the least amount of investment. The technology that has been developed to this point is already workable and being used in HTEK products. Another advantage is that the company will not incur any hardware development expenses, which the firm expects would be substantial. Doing nothing, however, has several disadvantages. Because the current code was put together with a time-to-market mindset, it is a mess. Functionality is somewhat impaired and the current code does not allow for easy upgrades in the future. Another disadvantage is that some of the components of the current code are not the intellectual property of HTEK. Therefore, licensing rights must be paid for RTX SDK, RTX runtime and XPE.

The third disadvantage is that the current code is not stable, as it relies on XPE, which is not a real-time operating system. Finally, using XPE/RTX comes with significant hardware resource requirements that reduce the potential efficiency and effectiveness of the QNAV product. So while doing nothing leaves us with a workable product, it also leaves us with a less-than-ideal product that reduces the effectiveness of the in-house products in which we use it, and reduces opportunities for OEM sales.

The second option, rewriting the code, has the advantage of addressing some of these concerns. It would allow for cleanup and documentation of the software. It would also allow us to improve the capacity of the code to take on new features. The second option also retains the lack of costly hardware R&D investment. However, rewriting the code still leaves the disadvantages associated with using RTX SDK, RTX runtime and XPE, such as licensing fees, stability issues and high hardware resource requirements.

The third option eliminates many of these disadvantages. For example, it would allow for a move to Linux/Xenomai architecture, eliminating license fees, improving stability and reducing resource requirements. It would represent a true RTOS and have a low end cost. Also, the third option would provide us with better debugging capabilities and greater community development support. However, this option is time-consuming to develop, which would put a freeze on new features for several months. The third option also carries a high cost associated with R&D on the hardware.

Data/Assumptions

Our decision will be based on the following criteria: costs, payback and probability of success. The cost savings data can be easily calculated since the majority of costs are known in advance. We attempted to identify the cost drivers early in the process, which allowed us to detect escalating development costs so that we could determine when to abort. Payback is readily available through forecasts derived from historical data and in-hand purchase orders. Assumptions regarding the probability of success are derived from historical data and our in-depth knowledge of the industry as gathered through discussions with company management and other internal stakeholders. In calculating the probability of success we took several factors into account such as schedule slips, development/testing failure, management decision-making and customer demand.

It should be noted that in order to satisfy the company's requirement of non-disclosure regarding confidential information, we have scaled the numbers in order to disguise them. The end result was verified internally with the model, using the actual numbers. Anytime numbers are forecast, there is a percentage of error involved. To address this, we conducted a sensitivity analysis to determine the allowable margin of error.

Model and Analysis

Our company's model was best designed by using a Palisade Precision Tree. Since it was very difficult to get an accurate assessment of costs and probabilities, the sensitivity analysis played an important role in this project. At every step, we ascribed some value to the "abandon project" option since we felt that this was a distinct possibility for which we should account. We also needed to ensure that the company would be aware at each step the sunk costs and future costs of each course of action. Some of the major sources of errors, such as the schedule slippage, were difficult to account for but we attempted to account for them as best as possible.

It may have been controversial to include a probability for losing market share in our analysis of option #1. However, management felt this was a risk that we needed to incorporate into the model. We agreed that "do nothing" does not guarantee the continuation of the status quo.

We conducted a sensitivity analysis on the cost savings per unit. We also performed a sensitivity analysis on the forecasted number of units sold. Management felt that these analyses would be critical to their final decision, in particular with regards to determining a reasonable breakeven point. We also wanted to determine the amount of money that should be paid for the market research. The model determined that maximum the company should pay for perfect information was $X.