Figure 3.0-1 Through Life Information Management Plan Steps
The mechanism for developing and supporting this Shared Data Environment is a Through Life Information Management Plan. This TLIM Plan is necessary to provide an orderly transition of information and data requirements throughout the life-cycle of a defense system. There are a number of different owners of the data throughout the evolution of a defense system. The ability to transition in an orderly manner from one "owner" to another is key to providing life-cycle support to a defense system.
This SDE will support the systems engineering process through which technical data can be collected, managed, and used to support concurrent engineering, continuous design and program reviews, and can be continued into the operational phase of a defense system's life-cycle.
Even if an SDE cannot be created for this specific program, a TLIM Plan will be needed to address the orderly management of information. In such case, the TLIM Plan should address the specifics of data exchange and Interchange Specifications.
Similar to selecting the logistics support concept early in a program's life-cycle, the SDE concept must be established as early as possible. The activities of the information management group closely parallel those of all other groups, i.e., design, logistics, and production engineers.
The information management group must be given equal status with other DS program groups such as design, logistics, and production. The products of the information systems engineers must fully support, and be used by, the other traditional engineering disciplines. The means for achieving this is through an Information Management Plan and the concurrent development of data, software, and hardware infrastructures to support program management, engineering, and logistics data needs. Early buy-in of this concept is essential for the successful implementation of an integrated CALS-supported environment.
By achieving this Shared Data Environment, the other benefits of concurrent engineering, continuous review and approval processes, and better configuration management can be attained. The SDE provides the structure and the mechanism on which the defense systems technical and operational data will reside.
Table 3.0-1 shows the relationships of each phase in a product life-cycle to its associated information management planning function and activity.
Table 3.0-1 Major System Life-cycle Phases and Information Management Activities
Program Phase |
Major Program Functions |
Pre-concept |
· No major information management planning requirements. |
Advance planning and conceptual design [Concept] |
· Capture structure requirements,
|
Advance development and preliminary system design
|
· Development of information management planning specifications
|
Detail design and development
|
· Implement information management plans
|
Production and/or construction
|
· Use information infrastructure to capture and distribute product and manufacturing data (as required) |
System use and life-cycle support (consumer)
|
· Implement interfaces with operational support activities
|
System retirement
|
· Archive information management planning documentation
|
The scope of the information covered by the TLIM Plan is up to the individual program. However, to clearly identify and standardize all of the information on a program is too complex an effort and not necessary from a NATO perspective. The NATO CALS focus is on through-life product identification and in-service logistics support. In particular, NATO is focused on keeping the product related technical information to support these business functions in synchronization with the changing product.
NATO is developing a NATO CALS Data Model to support the following product related technical data and information:
· Product Identification (including NATO Stock Number)
· Configuration Identification
· Logistic Support Information
· Provisioning Data
· Technical Documentation in Support of Maintenance
Figure 3.0-2 depicts the scope for the NATO TLIM Plan. The activities listed support development of the TLIM Plan for an individual program.
Figure 3.0-2 Develop an Information Management Plan (IMP)
3.1 Analyze User Requirements
The IMP needs to detail the following:
· What information is needed?
· Who needs it?
· When it is needed?
· What it is needed for?
· What form is it needed in?
· What are the delivery mechanisms ?
3.2 Define Information Requirements
From user requirements the following information requirements can be determined:
· Definitions of information needed
· Envisioned use of information
· Anticipated life-cycle of the information
· Form(s) of the information
· Management of the DS requirements and associated information
3.3 Define Infrastructure Requirements
To implement a CALS Environment effectively in a program, the existing and planned information technology capabilities of both the government and industrial team members must be analyzed. It is important to understand that the organizations team responsibilities and IT capabilities supporting a program and its end product will change during the program and product life-cycle. Therefore, a major advantage of implementing a CALS Environment is to plan for and manage these changes from program inception. Detailed information on infrastructure requirements for the creation, management, and use of digital data may be found in Appendix I.
An important decision on IT infrastructure is the level of investment within the program. The DS Program Manager must determine what to request from offerors in the pre-procurement phase to ensure the industrial and governmental infrastructures are interoperable and satisfy the CALS goals and objectives of the program. The goal of this activity is to create a Shared Data Environment that supports the program goals utilizing the NATO CALS Products throughout the full life-cycle of the DS program. The following categories shown in Table 3-2 should be examined when analyzing the existing and planned IT infrastructure.
Table 3.3-1 IT Infrastructure Analysis
3.4 Develop Information Management Plan
The Information Management Plan (IMP) is a comprehensive document to support the intended program business strategy as developed in Stage 1. The IMP should address both government and industrial requirements and is under program management control throughout the life-cycle. All parties (NATO, nations, armed services, contractors, etc.) must agree to the IMP. The following content shown in Table 3-3 is recommended for the IMP.
Table 3.4-1 Information Management Plan (IMP) Content
3.5 Develop a Business Case for Through Life Information Management
The DS information requirements, either in the realm of Electronic Document Management (EDM) or Product Data Management (PDM), will require substantial expenditures of manpower and financial resources. The Business Case demonstrates to management the financial viability of the project, and is often the key activity in obtaining funds for the project.
3.5.1 Business Case Need
EDM/PDM projects are often implemented to improve the efficiency of an existing business process, possibly in conjunction with a business process re-engineering effort. In other cases, the Project is part of a larger program, (e.g., weapon system modernization, new weapon system production, new product introduction) and the Project costs are simply part of the larger program budget. Both the costs and benefits must be considered when making the financial analysis.
3.5.2 Why Do We Need It Now?
It can be argued that the costs cannot be accurately determined until after the Vendor Selection phase is complete. That is a true but not very useful answer. Experience in information technology (IT) projects has taught that funding a major IT initiative is a process, rather than an event. As such, it is usually necessary to set cost expectations early, and then refine the cost information as the Project progresses.
An organization needs time to overcome the "sticker shock" that is usually associated with these Projects. If one waits until after Vendor Selection to determine and publish cost information, the project will likely be on hold while the cost/benefit information is scrutinized and validated. Meanwhile, the project has lost momentum and the team will become demoralized or be disbanded. That is why it is important to complete the Business Case right after the scope is determined in the Initial Requirements Study.
Newcomers to this technology usually have a difficult time in determining the costs; vendors can help in setting product costs, while consultants can aid in determining overall project costs.
Of course, the cost estimates will evolve as the Project matures through the Requirements phase. Now there is a cost model that can be used to assess the impact of decisions made during the Requirements phase.
A more complete discussion of this topic with a sample outline of "how to" may be found in Section 8.1.4 of this handbook.
3.5.3.1 Benefit Indication
The benefits of an EDM or PDM implementation are numerous. Many individual benefits that can be determined by brainstorming, interviewing, research in industry publications, engaging consultants, etc.
3.5.3.2 Benefit Classification
A business case presentation is an exercise undertaken to answer one question in the mind of the approver(s): "Convince me that this investment is financially sound." Therefore, the validity of a given benefit is primarily a perception of the listener and only secondarily an inherent property of the benefit. Benefits therefore must be classified into what are perceived as "strong" and "weak" arguments. Obviously, the "strong" benefits are emphasized while the "weak" benefits are de-emphasized or eliminated.
Figure 3.5.3.2-1 shows benefits classified in terms of specificity and technique. A "broad brush" analysis is usually stated in very general wording. For instance, "Engineers spend XX% of their time looking for information. With EDM system, we will save some portion, say 50%, of that time." This is much less convincing than an analysis of a specific situation. Specific situations may include shop floor drawing retrieval, ISO quality manual management and distribution, supplier drawing review and approval.
Figure 3.5.3.2-1 Strength of Benefits
The analysis technique also impacts how the benefit argument is perceived. Here is an example of such an argument based on conjecture. A Sales Executive says, "If we managed our documents better when we are preparing bids for our customers, we would win about 10% more of the work that we compete for." This argument, while it might be correct, is difficult to substantiate, so it is only compelling to the extent that the Executive is respected in the organization. It will only work when he is personally promoting it.
A statistical analysis is stronger than guessing, for example, using this method in analyzing how the frequency of scrap and rework events related to the timing of drawing availability, in a fast track design/construction environment. In this case, detailed information was available regarding the timing and frequency of events associated with drawing transmittal. In addition, detailed information was available which related scrap events to drawing errors that could have been avoided-a necessity since not all scrap can be avoided by implementing EDM. Statistical arguments are difficult to convey because of the complexity of the mathematics involved-if you use them, you must pay close attention to how the data is presented. A prime benefit of EDM is cycle time reduction, often demonstrated using a statistical analysis.
A deterministic analysis is the most compelling. This involves a detailed analysis of a specific business process. Consider: "A person in the plant requires about 30 minutes to walk to the drawing vault, identify the drawing needed, and get a print. This happens 7,300 times a year. This time would be reduced to, say, 3 minutes per transaction, with EDM on the shop floor." This type of analysis can be applied to any business process that is observable and can be measured in real time.
3.5.4 Cost Determination
There are two significant aspects of costs: what the costs are and when they are accrued.
3.5.4.1 Unit Costs
Cost data must be collected for estimating the cost of each project alternative. Six traditional sources of data are historical organization experience, current system costs, market research, publications, analyst judgment, and special studies. This step is the preparation for the actually estimating costs. Special studies include parametric modeling, function cost analysis, or engineering analysis.
Many factors must be considered during the process of estimating the costs associated with competing alternatives. All costs for the full system life-cycle for each competing alternative must be included. The following factors must be addressed: Activities and Resources, Cost Categories, Personnel Costs, Direct and Indirect Costs (Overhead), Depreciation, and Annual Costs. It is critical that all costs of ownership be ascertained. These costs include, but are not limited to: labor, materials, components, software, hardware, maintenance costs, and engineering change costs.
3.5.4.2 When Costs Are Accrued
Costs can be accrued at three different "times:"
· Initial costs: when the system is first installed.
· Incremental costs: whenever the system is extended in any way. See "Rollout" below.
· Annual costs: upgrades and annual maintenance costs.
Costs are, in fact, a time series-hardware, software and service cost events usually occur repeatedly.
3.5.5 The Analysis
Unit costs and unit benefits are necessary, but do not provide sufficient information to determine the viability of a project. We must know when these cost and benefit events occur, and this is determined in the Rollout Model.
3.5.5.1 Rollout Model
In larger systems, e.g., large, multi-discipline engineering organization, weapons production and deployment, manufacturing company, the entire system is not installed on day 1. In practice, an "initial system" is installed, and then deployed or "rolled out" elsewhere. The dimensions of the rollout include adding:
· Users
· Concurrent users
· New applications
· New functions
· Departments
· Buildings and special facilities
· Remote sites
3.5.6 The Financial Model
Each rollout increment adds costs (determined from the unit costs) immediately, and adds benefits thereafter. Typically, a mathematical model of the organization is created, and costs are parameterized for the number of users, concurrent users, applications, departments, etc. This organizational model is then the basis for aggregating the costs and benefits in the financial model.
The financial model is constructed to determine the Net Present Value, "NPV," Internal Rate of Return, "IRR," and the Payback Period. Expected values of IRR's of 25% to 35% and Payback Periods of 1.5 to 2.5 years would be typical of EDM/PDM projects in the $1 million range.
3.5.7 Sensitivity Analysis
When the business case is presented, it is likely that assumptions will be questioned. To prepare for this eventuality, it is possible to adjust the assumptions/parameters in the financial model to determine the "sensitivity" of the NPV and IRR to changes in the assumptions. Obviously, if the NPV or IRR is very sensitive to a particular assumption, a strong reason must be made for why the specific value was chosen. For example, one project showed an IRR of 0% if the system life was assumed to be two years, 44% if the system life was five years, and 60% if the system life was seven years. Assumptions are important and should not be taken lightly.
3.5.8 Project Specific Aspects
Projects differ in how certain aspects of a financial analysis are calculated. Projects should validate their calculation technique with NATO standards before presenting results. Areas of greatest variation include the treatment of:
· Depreciation
· Leasing
· Maintenance costs
· Manpower costs
· Capitalization of services
· Infrastructure costs (e.g., networks)
