Business values

Data integration and more powerful search technologies are the IT backbone for deriving business value from the plethora of data fogging the pharmaceutical industry today. Fortunately, this is not a problem for this industry alone, and the best and brightest of IT minds and companies are focused squarely on this problem. In addition, further advances in how humans process data and information will also come to bear. 

Innovation Center for U.S. Dairy (2008). U.S. Dairy Sustainability Initiative. A roadmap to reduce greenhouse gas emissions and increase business value. December 18, 2008. http // www.usdairy.eom/Sustainability/Commitment01d/Documents/RoadmapToR-educeGHGEmissions.pdf. (accessed 23.10.10), p. 215. 

Use cases give reasonable guidelines on how fine-grained a use case should become, if only at the bottom end of the spectrum If the next level of refinement provides no meaningful unit of business value or information, do not bother with finer-grained use cases just document them as steps of the previous level of use case. 

Step 1 Business value assessment Identify and quantify the business value for the proposed new method or analyzer. This is done jointly by the customer and the project manager. Ideally the value of the technology can be expressed concretely in monetary terms (e.g. dollars) as, for example, a net present value (NPV) or an internal rate of return (IRR). It is critical to include a realistic estimate of the costs of implementing and maintaining the analyzer, as weU as the benefits to be realized from it. This assessment is used to prioritize effort and expenses and to justify any capifal purchases needed. The various ways that process analyzers can connibute to business value are discussed in Section 15.2.2. 

Step 2 Technical requirements Determine the specific technical requirements for the new method and/or analyzer that will ensure that it captures the previously determined business value. This is also done jointly by the customer and the project manager. Avoid nice to have and focus on what is necessary. Technical requirements may include accuracy, precision, specificity, turnaround time, response time, robusmess, maintenance needs, etc. They should be focused on what the analyzer needs to do (e.g. determine the concentration of component X with 1.5% relative precision, once a minute, in a corrosive process stream at 80 °C), not how it will be done. Issues that need to be considered in setting technical requirements are discussed in Section 15.2.3. 

Step 4 Project initiation and approval Define a project to develop and implement the proposed new method or analyzer and get it approved by the sponsor. The documentation required by the sponsor is usually company-specific, but will typically include goal, business value, critical technical issues to be addressed, ramifications, proposed approach, resources needed (including personnel time), deliverables, and timing. 

Note It is assumed that if the analyzer meets the previously agreed-upon technical requirements, it will then deliver the agreed-upon business value. Some companies may require that this be verified, for example, by tracking the savings over a specified period of time, and the results included in the project closure documentation. 

Process Analytical Technology 15.2.2.1 Business Value Example... 

The applications described in this second part of the chapter are intended to illustrate the wide range of uses for NIR in the chemical industry. The selection of examples was intentionally limited to work done within industry and published in the open literature in order to keep the focus on work that has demonstrated business value. However, it has been the authors experience that for every industrial NIR application published in the open literature there are at least two others practiced as trade secrets for business reasons. This is especially true for on-hne applications that have progressed beyond the feasibility stage, since the NIR results can reveal a great deal of information about the chemical process itself - information which industry managers are often reluctant to share. Pubhshed industrial applications should therefore be considered merely the tip of the iceberg. 

Chabot et al. at Atofina Chemicals (King of Prussia, PA, USA) used in-line NIR to monitor monomer conversion in real time in a batch emulsion polymerization process. The business value of this monitoring... 

Sollinger and Voges at Akzo Nobel (Obemburg, Germany) used off-line transmission NIR to monitor the key quality parameters in cellulose hber (viscose) spinning solutions over time. The business value lay both... 

Brearley et al" at DuPont (Wilmington, DE, USA) used in-line transmission NIR to monitor carboxyl end groups and degree of polymerization (DP) in PET oligomer and prepolymer melt streams in a new polyester process. The business value was derived from several sources. 

A significant business value is created when the focus is on having aU ingredients end up in useful products and less and less in landfills, incinerators, and other places... 

The reason I include this seemingly irrelevant chapter in this book is because it is important. What are the factors that make a software project succeed One could say the project has to provide good business values. In addition, the project team has to be technically competent. Although these factors are all necessary for the project to succeed, they are not sufficient. Especially for a software project that has some level of complexity, tight timelines, and resource constraints, a good development process is also critical. Unless your development process is ad hoc, most likely you will use either the waterfall or the iterative development process. Many researchers show that the latter is a much better choice than the former, and many thoughtful leaders advocate its use in most software development projects. 

A software project is hard to predict. The best you can do is to make sure that the delivered software has the most business value and the highest quality possible at any point in time. The agile iterative process helps you to achieve that. 

We said that iteration planning should be based on business values, risks, and complexity. Using our case study, CRS as an example, here is a... 

Iteration Features Time Frame Business Value Complexity Risk... 

In an agile iterative process, not all use case specifications need to be fully developed before the design and implementation starts. Usually, a scope and a vision document are developed with a fist of features that should be included in the system, including a brief description of each feature as in the Brief Description section of the above use case specification. These features are prioritized and planned according to their business values, complexity, and architectural significance (please see Chapter 5). At the beginning of an... 

Again regardless of in-house or outsource development, document a list of features and prioritize them. Break the project down into short, timeboxed iterations, each focusing on one or two of these features (Chapter 5). Do not let the iteration deadline slip. Reduce the scope of the iteration if necessary. Implement features with high business values and high business and technical risks in early iterations. Make sure each iteration delivers a production quality partial system to solicit feedback and let the system grow incrementally. The project plan should be adjusted based on the feedback. It is OK if the initial project plan is not accurate. However, it should become more and more accurate as more iterations are completed. Test and integrate early and frequently. 

---