US Army

2. What were the key implementation considerations that were addressed as part of the planning process, especially related to using an integrated ERP and transforming the culture? Explain. Elaborate on your answer.

part 2. Why is this important?

The case study

. GOAL The army's ability to see, anticipate, and respond to the rapidly changing operational environment is possible through the management of information and knowledge from a One Army and One Enterprise perspective. The capability to employ, deploy, and sustain responsive combat capability can only be realized through knowledge superiority provided by systems that provide a common view of the environment as well as the ability to rapidly affect combat operations by anticipating change and providing decisive and dominant combat capability where and when required. It is the institutional army's transformation of business systems, processes, and practices that will produce the streamlining necessary to reallocate the resources (i.e., personnel, dollars, and time) required for this transformation across the business mission capabilities designated by the BMMP: Acquisition Financial management Human resource management Installation and environment Logistics The operational army will be represented in the three other mission areas: Warfighting mission area Intelligence Enterprise information environment mission area Each of these business mission capabilities and mission areas must work together to eliminate boundaries, to synchronize transformation between the institutional and operational army. They will identify opportunities to optimize the army at the enterprise level. The army must transform from end to end: One Army, One Enterprise, and so on. The army has recognized that an ERP implementation is high risk and high reward. With that in mind they have developed standards and guidelines for any ERP implementation they undertake. KEYS TO SUCCESS Change Management Most major business transformation efforts historically fail. The failure rate is often as high as 65-75 percent. The primary cause of failure is most frequently the failure to anticipate and effectively manage cultural and organizational change. Table 5-2 identifies five transformation management (TM) considerations, along with the specific challenge for the army and strategies to overcome these challenges. Table 5-2 offers several considerations. These will now be looked at more closely. TABLE 5-2 Change Management Considerations Consideration Army Challenge Strategy to overcome Sponsorship or Rotation Engaged leadership Leadership Comprehensive transition Stakeholder Enterprise view Enterprise-level governance Alignment Cost Hard to justify $$ Make the case for change (10-15 percent) Justify based on lessons learned Project Life Cycle When to start Communications Iterative process Culture Resistance to change Sponsorship from within Education Communication Number of Communication strategy that includes stakeholders tactical methods of disseminating program information Sponsorship. ERPs require sustained leadership, but army leaders rotate often, and one ERP implementation could span two or even three sponsors. Sponsors need to be engaged, not just brought in. They also need to convey the importance of continued engagement to their successors during transition. Stakeholder Alignment. The army has traditionally been stovepiped (i.e., operating in silos). The ERP model requires making trade-offs in some domains for the greater good of the enterprise. These decisions require governance above the mission area and the domain level. Cost. Transformation management can cost as much as 15 percent of the program budget and is one of the first areas to get cut when budgets are trimmed. This is a big mistake, as the Gartner quote earlier in the chapter shows; therefore, the case for TM and its value must be made. TM is an investment in the success of the program and must be portrayed as such. Project Life Cycle. TM is often left as an afterthought, started just before Go-live. It needs to start at the outset of the project and continue throughout. Culture. The army is an organization with a lot of history and tradition. As such it can be resistant to change. This is not true of everyone, and not of every part, but it is an issue in the army just as it is in most large organizations. The solution to this issue is sponsorship from within the army (i.e., it cannot be outsourced). A system integrator or other consultant can bring experience, tools, and methodologies, but sponsorship has to come from within. A leader from the inside has to say, "I recog- nize we need to change, I am going to change, and I want you to change with me for the good of the army." Communication. Communication is a key implementation consideration because there are so many stakeholder groups impacted by an ERP program both internal (e.g., soldiers, business mission area personnel) and external to the army (e.g., legislators, taxpayers). A communications strategy that includes tactical methods of disseminating ERP program information both top-down and bottom-up via diverse communication channels is an effective approach that contributes to program success. GOVERNANCE Governance of any major change in an organization is critical to the success of the change effort, but governance of ERP programs is even more critical because of the size and scope of the programs. They change both technology and business processes and job content. This level of change requires that the organization understand the implications and be prepared to make tough decisions. These types of decisions require executive sponsorship and governance at the most senior level of the organization. PERFORMANCE MEASUREMENT Performance measurement of ERP generally includes two components: the ERP imple- mentation itself and the operational or business results, or both. For the implementation itself, the traditional measures of cost, performance, and schedule can be used. In terms of operational or business results, or both, types of measures should include effectiveness, efficiency, and customer satisfaction (i.e., the customer category can include internal and external customers). An example of measuring business results is reducing the average cycle time of vehicle parts restocking from 10 days to 4 days. All performance measures must have a baseline. If there is not a baseline, there is nothing against which future per- formance can be compared; therefore, there are no valid results. CUSTOMIZATION AND CONFIGURATION The decision to customize ERP software core functionality is not one to be made lightly. The decision to modify ERP software is traditionally made to avoid painful and necessary business process change and should be strongly questioned by senior leadership. The benefits of ERP software, including the ability to take advantage of vendor updates to functionality, are negated by customizations. There are huge dollar amounts and resource hours involved, often in ACAT 1 programs, so it benefits the army to ensure that the investment is appropriately realized. In addition to the benefits of ERP implementations as detailed in the ERP overview, there are specific benefits to not customizing ERP software: Proven industry business practices can become embedded in the enterprise if effec- tive change management is conducted. Maximizing investment in ERP software by minimizing the cost of upgrades and maintenance of software. Integrating processes and information systems on a DoD-wide level is significantly less complicated and costly if multiple components have the same application and version of an ERP module without modifications. Reducing the need for scarce technical resources because the army would be able to leverage the vendor's support organization and realize the full value of the ongoing support and maintenance fees charged by software vendors. The common argument for customizing ERP software is that it is not possible to run the army using commercial processes because army processes are too dissimilar and vary due to specific mission or organizational objectives. Even though that can be a true state- ment based upon statutory and regulatory constraints, this is not usually the case. The statement is usually made by stakeholders or team members who either do not think they are empowered to make decisions about process changes or want to avert change to main- tain the status quo. If the organization is committed to changing business processes to match those inherent to the software package, customization of ERP software should be rare. The effort involved to reengineer business processes to fulfill this commitment cannot be understated. There are various DoD statutory and regulatory rules that are not accommodated by ERP software; however, this does not have to be a barrier to using the delivered ERP functionality. Sometimes these regulations can be changed to accomplish the same goal using the delivered software. Blueprinting, which includes comprehensive pilots on a live system of proposed business processes using delivered ERP functionality, is key to developing an effective and accurate process. The result of these rigorous pilots should be a list of valid customizations mainly based upon statutory and regulatory rules that cannot be changed in the foreseeable future or cannot be accommodated by changing a current business process. The first line of defense if major business requirements cannot be met by delivered ERP software functionality is acquisition of a bolt-on, whether it's a product of the same ERP vendor or a third-party software vendor. Bolt-on provides similar benefits to those of ERP software. It can also provide process innovations necessary for specialized industry needs. The additional cost of support and maintenance of an additional software license would need to be evaluated versus the magnitude of the customization required to meet the necessary business requirements. Table 5-3 contains the type of customizations that could be candidates for bolt-on versus minor customizations to meet a requirement that cannot be met by the ERP software or a process change. If a requirement is historically too industry specific, even bolt- ons may not meet the need. The next priority should be changing a business process or, as a last resort, customization of ERP software. There are two potential methods for customizing ERP software, but only one method should ever be used. The method that should be prohibited by project leadership is modifica- tion of delivered software code from the vendor. The accepted method is the creation of a new code base, also called an extension, which is derived from a clone of a delivered software routine. The modified code is then referenced by core application components. This approach requires that all the references to the delivered code be changed to reference TABLE 5-3 ERP Approach to Meet Requirement Gaps Major Customizations Approach Bolt-on product Description Processing engines End-to-end processes Security structure Minor Customizations Clone and modify ERP code Simple processing routines Reports Web pages Menus the new code, creating a potentially costly modification from a time and budget perspective. If a major business requirement needs to be met, a bolt-on is the preferred approach. Table 5-3 lists the development platforms that could be cloned and modified in the major ERP packages to create an extension. An extension retains the delivered vendor's code in the database, but the original code is no longer used. Subsequent ERP upgrades will update the delivered code, and the modified code can be integrated into the upgraded application if the underlying technology remains the same. The following must also be considered: The upgrade process for a customized ERP implementation is more time consuming than an upgrade of an ERP implementation with no customizations. The time frame and cost of upgrades increase exponentially with the number of customizations due to validation and testing. Customizations are not supported by the vendor and must be maintained and updated by army or contractor staff. If the army's customization is one used by multiple clients, there is the possibility that the ERP vendor can be persuaded to include this customization in their next product release, but this could require significant negotiating leverage and is uncertain. Depending upon the magnitude of the required customization, a bolt-on can be more cost-effective, less susceptible to defects, and enable the team to meet project timelines. The measurement of the level of customization of a particular installation of an ERP system is difficult to judge. There is currently no industry measurement baseline or metric for this type of analysis. Objective measurements would ideally involve a determination of the amount of customized code as a percentage of the vendor's delivered code. In order for this measurement to be meaningful across industries, and even within the army, there would need to be a common metric for delivered code and a common method for determin- ing the means to parse and quantify the amount of customized code. These measurements would be further complicated by the fact that implementing an ERP product often does not include implementing full functionality. ERP modules are often implemented over a period of time in a phased approach that leads to the need to refine further the definition of the baseline delivered code versus customized code. Finally, this analysis also presumes that a common baseline would be applicable across ERP packages, leading to a comparable assessment of the levels of customization of, for example, a SAP versus an Oracle imple- mentation. This task is not without merit, but it will require industry and organizational alignment to reach fruition. A final consideration related to this discussion is the configuration of ERP software. Configuration is not customization or modification, it is the entry of customer-specific data into the tables delivered in ERP software. A standard, simple or pre-configuration, however, may allow faster processing speeds and easier queries. A more complex configuration may cost more in terms of user training, processing speed, and data access. Complex configurations may better support current or legacy business processes. They may not. however, represent best practices or changed business processes. Table 5-4 provides a sum- mary of the configuration and customization approaches along with some pros and cons. TABLE 5-4 Comparison of Customization and Configuration Approaches Attribute Customize Configure Functionality Custom coding or Choose from out-of-the-box modification processes and functions More control over Set parameters functionality Less control over functionality Cost Higher Lower Upgrades More difficult Easier Longer cycle Shorter cycle Support Reduced vendor support Full vendor support INTERFACES AND INTEGRATION OF EXISTING OR THIRD-PARTY SYSTEMS Additional issues that must be considered when planning ERP implementations are the costs and time associated with developing interfaces and integration with existing systems. Even though the ERP database becomes the central, authoritative data source, most organizations are not able to eliminate all existing databases. As a result they must build interfaces between the ERP system and existing systems that will not be retired immediately. Not all systems will be retired by implementing an ERP