Framework: An Integrated Approach to Portfolio, Program and Project
|[AACE HOME] -- [TCM HOME] -- [BUY THE TCM FRAMEWORK] --[DOWNLOAD PDF VERSION]|
[TOC] [PREVIOUS] [NEXT]
II. STRATEGIC ASSET MANAGEMENT PROCESS - CHAPTER 6 - STRATEGIC ASSET PERFORMANCE ASSESSMENT
6.3 Asset Historical Database Management
Asset historical database management is a process for collecting, maintaining, and analyzing asset historical information so that it is ready for use by the other strategic asset management processes and for project control. Empirical information is the most fundamental asset planning resource available, and it is manifested in the form of quantified and documented historical data and information. The historical database management process captures empirical information and retains this experience within the institutional memory to support the development of continually improving asset management plans as well as improved methods and tools. The purpose of the process is not to repeat history, but to learn from it (i.e., to enable continuous improvement in the asset management system).
To illustrate historical datas importance, Figure 6.3-1 provides a simplified block flow diagram of the information flow in the strategic asset management process. Each block represents an asset management process that incorporates data manipulation methods or tools (e.g., investment decision analysis models). The interconnecting lines show the general flow of data and information products among the processes. Clearly, if you remove the historical block from the diagram, there is no closure in the information flow. Without the historical data process, asset planning methods and tools have no other basis other than the personal knowledge of the asset planning team members; no institutional memory is developed and no opportunity for a learning organization exists.
Figure 6.3-1 Strategic Asset Management
Process Information Flow
For asset management, historical data take on even greater importance because asset planning and decision making are highly dependent on cost and economic modeling and risk analysis that use stochastic, probabilistic methods. Without empirical data, the quality of output of these types of methods is greatly diminished and it is much more likely that inappropriate investment decisions will be made.
.1 Asset Management and Project Control Database Integration
Figure 6.3-1 is essentially the same as Figure 10.4-1 (Section 10.4) for the project historical database management process. While the figures show separate blocks for the asset and project processes, the distinction between them is somewhat artificial. Both processes have similar needs for performance benchmarks, cost references, and other information. If an enterprises project system is viewed as a strategic asset of the enterprise, the asset database can be viewed as the master. In any case, through a relational database structure or some other means, the databases should be integrated, allowing users to access life cycle information about the asset and project portfolios.
Where the distinction between the databases is real is in the data sources (more apt to be external for projects), end users (e.g., teams or organizations), and processes they support. In terms of end users, project teams may use a closely integrated project information system or more or less independent systems. Assets may be owned and operated by various business units that may have centralized or decentralized databases.
Increasingly, enterprises are using enterprise resource planning (ERP) and business intelligence (BI) systems that use one software platform and database to support most of the enterprises business functions such as finance, manufacturing, human resources, warehousing, and so on. These systems have evolved to include the project management/control function as well. ERP systems are complex and are a major asset of any enterprise that uses them. Projects to implement and maintain ERP and similar systems are often among the enterprises most significant asset investments.
.2 Other Systems Integration
Strategic asset management uses data for planning, assessing, and reporting performance from multiple perspectives such as investment decision making (Section 3.3), profitability analysis, and target costing (Section 3.1). Sometimes the data structure or characteristics required from one analytical perspective may conflict with another. For example, data for financial reporting that is in accordance with Generally Accepted Accounting Principles (GAAP) often does not readily support product costing using ABC/M methods (e.g., when costs are recognized, how they are allocated, etc.). Attempts to fully integrate databases and systems (e.g., ERP) can lead to sacrifices in the quality or timeliness of information from one or more perspectives. Figure 6.3-2 illustrates an example of a modular approach that uses legacy accounting systems and specialized ABC/M systems to feed a common data repository that in turn supports customized planning and assessment toolboxes (or workbenches). Many enterprises with ERP systems have not implemented the available project management modules because of perceived problems or tradeoffs with full integration.
Figure 6.3-2 Illustration of an Overall
Analytical Database and Reporting Vision
Data for specialized end uses are often manually entered in the data repository. However, ERP and Enterprise Performance Management (EPM) system developers are increasingly attempting to provide systems that integrate all the functions so that data are only entered once and can be broadly accessed. However, it is likely that there will always be specialized analysis models, tools, and data that will reside outside of the ERP scope.
6.3.2 Process Map for Asset Historical Database Management
Figure 6.3-3 illustrates the process map for asset historical database management. The two main steps of the process include collecting data of various types and processing it into useful information products.
Figure 6.3-3 Process Map for Asset Historical Database Management
The following sections briefly describe the steps in the asset historical database management process. These steps are very similar to those in the project historical database management process (see Section 10.4).
.1 Plan for Asset Historical Database Management
Asset historical database management starts with planning. As discussed, the asset and project databases should be integrated; therefore, planning must first consider the interface/interaction of the project data inputs and outputs with the asset management database. For example, are project data captured in real time, at some reporting time interval, or only during the project closeout process?, what data formats and level of granularity should be used?, and so on.
The asset historical database management inputs include planned and actual quantitative data and qualitative information about the performance of assets and asset management methods and tools. Data from the project system, which are an asset of the enterprise, are an input to the asset database management process. The quantitative data (e.g., cost estimates, actual costs, schedules, etc.) must be processed. Processing includes cleaning, organizing, and normalizing the data as required for inclusion in the master database(s) for continued use. The qualitative information (e.g., lessons learned, etc.) must be cleaned, organized, and standardized as required for inclusion as well. These collection and processing activities, some of which are done on an ongoing basis, and others periodically or as a specific effort, must be planned and resources allocated for their performance.
The processed quantitative data are then used for the development and maintenance of reference databases for planning (e.g., cost estimating model databases), metrics for plan validation (e.g., check estimate competitiveness), and tools development (e.g., estimating algorithm development, templates, etc.). The processed information, including lessons learned, helps guide the effective application of the data in the development and maintenance tasks, but also serve as direct references to aid asset planning.
The plan for asset historical database management must address the collection and processing work. Planning topics may include, but are not limited to the following:
roles and responsibilities
collection methods (throughout the asset life cycle)
data structure and format (asset registers, cost code structure, etc.)
level of detail and comprehensiveness of records
data and record quality
storage and maintenance (tools and systems)
access and retrieval (methods and access rights)
analysis methods (where applicable)
information product quality (data validation)
legal issues (retention, claims issues, etc.)
Databases capture both electronic and hard-copy information; each type of data has specific considerations. In whatever form it is captured, the goal is to store the data in a way that is easy to find, retrieve, update, and use. There may also be multiple databases that support specific purposes that each must be considered. Finally, some enterprises have limits or restrictions on retaining original data and records that must be adhered to as a matter of policy and must be addressed (e.g., use the raw data to create metrics, then discard the original data).
For projects, data collection and processing activities may be a responsibility of cost engineers in a project control role supporting the project manager. For assets, data collection and processing responsibilities tend to be the more dispersed among finance, operations, maintenance, and other organizations. However, database analysis and development for strategic asset management purposes may be supported by a cost engineer. Another aspect to plan for is the interaction/interface of suppliers and contractors with the owners databases and vice versa. Given the many participants or users of an asset historical database, it is important to give prior consideration to the available data format and granularity to ease data integration into the database or facilitate the datas later use and to ensure that responsibilities are clearly defined.
.2 Collect and Process Data
The database inputs include estimated, planned, and actual quantitative data about the performance of assets including the project system. The quantitative data (cost, revenues, performance rates, etc.) must be collected and processed. Data collection for assets is usually done in real time or at regular reporting intervals. As illustrated in Figure 6.3-2, much of the data also supports the enterprises financial reporting system (increasingly supported by an ERP system database), which will have established data needs and reporting requirements.
Data processing includes cleaning, organizing, and normalizing the data as appropriate to incorporate into the master database(s) for continued use. Data cleaning refers to ensuring that the data are complete and acceptably accurate for database purposes, which may differ from accounting, finance, and operations purposes. Organizing data refers to making sure the data are coded in accordance with the structures used by the database and are otherwise identifiable (e.g., meaningful account titles, category descriptions, etc.).
It should be noted that cost data as reported directly from cost accounting systems are useful, but are usually neither clean nor organized in a manner that best supports asset planning, methods, and tools development, and so on.
Normalizing data is a more complex step that involves translating the data so that it is on a standard or "normal" basis in terms of time, location, and currency. After processing, the data may then be entered in an electronic database and/or kept in hard-copy form.
Qualitative Data (Process Lessons Learned)
Database inputs also include qualitative information about the performance of the strategic asset management processes or systems. This information may include assessments of how successful the asset portfolio is in achieving its objectives, and what factors contributed to the success or failure. Subjective information may be captured through the use of surveys, narrative descriptions, interviews, formal lessons learned workshops, or forensic performance assessment (Section 6.4). More objective information can be obtained by benchmarking (see Section 6.1), which involves comparing asset management and project system practices and performance to that of other enterprises that used the best practices and achieved the best performance.
The qualitative information must also be cleaned, edited, and organized as required for incorporation into master database(s). After processing, the data may then be entered in an electronic database and/or kept in hard-copy form. The goal is to capture qualitative information that will allow the next investment decision to be made based on successful approaches, avoid repeating unsuccessful ones, and provide context for assessing quantitative data.
Procedural (Methods and Tools Lessons Learned)
In an extension of the above methods, additional qualitative information is captured about the performance of asset management methods and tools. For asset management, models are central to many of the processes (e.g., decision analysis, ABC/M, etc.), so lessons learned about model development and use will be most useful.
.3 Analyze and Process Data
Reference Data Development
Many planning and assessment methods and tools rely on reference databases of some sort. For example, the reference database for a conceptual cost estimating system may contain many parameters and adjustment factors. The reference data provide an empirical basis for planning.
The reference data should be consistent, reliable, and competitive with a well defined basis (e.g., assumptions, conditions, etc.) such that any asset planning effort can determine how its requirements and basis conditions differ from the reference and adjust accordingly. The quality of a reference database is not judged by how correct or accurate its entries are in terms of representing the absolute cost or duration of any given item or activity on any given project. Rather, it is judged by how reliable a planning "base" it is in terms of competitiveness and consistency, with consistency meaning that the basis is known and is consistent between similar items and does not change over time unless the change is has been justified by analysis.
Reference data are typically normalized to a standard basis (i.e., in terms of time, location, currency, conditions, etc.). Established reference databases generally do not require constant updating; annual updates are common. At the time of review and update, the data from the asset portfolio collected over the period are analyzed to determine if the existing data are still good references. If new reference data are developed, the basis must be consistent and well documented.
Benchmarks and Metrics Development
Benchmarks and metrics are a form of reference data, but the purpose is primarily to support the validation of asset planning (See Section 3.2). Benchmarking metrics are also useful references for stochastic (i.e., top-down or conceptual) planning methods and tools, including models. Benchmarking is a process that compares practices, processes, and relevant measures to those of a selected basis of comparison (i.e., the benchmark) with the goal of improving performance. The comparison basis includes internal or external competitive or best practices, processes, or measures. Validation is a form of benchmarking applied specifically to plans to assess whether the plan results are competitive and achieve the performance objectives.
Methods and Tools Development
Each of the strategic asset management processes includes a step for methods and tools development (e.g., new or updated models, forms, systems, etc.). Each of these processes has historical information as an input for development of methods and tools. This information typically includes examples of methods and tools used on other assets and lessons learned from their use. Also, quantitative data can be used to support the development of planning algorithms and models (e.g., regression analysis of inputs and outputs to develop a parametric estimating model).
6.3.3 Inputs to Asset Historical Database Management
.1 Requirements. The requirements elicitation and analysis process (see Section 3.1) will establish requirements for the historical databases, which are assets of the enterprise.
.2 Investment Decision Basis. Asset investment plans (see Section 3.3) may describe specific systems and approaches for asset historical database management. Also, the historical database captures plan data as well as actual performance data.
.3 Project Database Plans. Asset and project historical database management (see Section 10.4) should be planned together.
.4 Actual Performance Data. Asset performance assessment (see Section 6.1) feeds actual performance data to the historical database management process.
.5 Performance and Methods and Tools Experiences. Qualitative lessons learned are collected from all strategic asset management processes (Chapters 3, 4, 5, and 6).
.6 Project Information. The project historical database management process (Section 10.4) provides project data as needed to manage the enterprises project system.
6.3.4 Outputs from Asset Historical Database Management
.1 Asset Database Plans. Asset and project historical database management (see Section 10.4) should be planned together.
.2 Planning Reference Data. Many asset planning methods and tools (Chapter 3) rely on historically based reference data. This is particularly true for the stochastic, probabilistic methods (e.g., models, risk analysis, etc.) used in asset planning.
.3 Planning Validation Data. Benchmarking and validation methods rely on historically based benchmarks and metrics.
.4 Data to Support Methods and Tools Development. Each of the strategic asset management processes (Chapters 3, 4, 5, and 6) includes a step for methods and tools development, and each of these steps has historical project information (e.g., examples, lessons learned, model parameters, etc.) as an input.
.5 Information for Project Control. Some asset and project system performance benchmarks and metrics may be used for project control purposes.
6.3.5 Key Concepts for Asset Historical Database Management
The key following concepts and terminology described in this and other chapters are particularly important to understanding both the asset and historical database management processes of TCM (also refer to section 10.4.5 for further elaboration on these concepts):
.1 Database. (See Sections 6.3.1 and 11.3).
.2 Continuous Improvement. (See Section 6.3.1).
.3 Basis. (See Section 6.3.1).
.4 Enterprise Resource Planning (ERP). (See Section 18.104.22.168).
.5 Enterprise Performance Management (EPM). (See Section 22.214.171.124).
.6 Normalization. (See Section 126.96.36.199).
.7 Lessons Learned. (See Section 188.8.131.52).
.8 Reference Data. (See Section 184.108.40.206).
.9 Metric. (See Section 220.127.116.11).
.10 Benchmark and Benchmarking. (See Section 18.104.22.168).
.11 Validation. (See Section 22.214.171.124).
Further Readings and Sources
Sources on ERP/EPM and business intelligence systems provide most of the literature regarding databases to support strategic asset management processes. Much of the discussion is centered on financial, operational, and perspectives other than asset investment and management. The following references provide basic information and will lead to more detailed treatments.
Cokins, Gary. Performance Management (Finding the Missing Pieces to Close the Intelligence Gap). New York: John Wiley & Sons, 2004.
Langenwalter, Gary A. Enterprise Resources Planning and Beyond. Boca Raton, FL: CRC Press, 1999.
[TOC] [PREVIOUS] [NEXT]
2008 By AACE® International www.aacei.org