Question: 1. Governance and methodology are important for ERP implementations Discuss theme of cach und bow each of them was implemented in the US Army case

1. Governance and methodology are important for1. Governance and methodology are important for1. Governance and methodology are important for1. Governance and methodology are important for1. Governance and methodology are important for1. Governance and methodology are important for

1. Governance and methodology are important for ERP implementations Discuss theme of cach und bow each of them was implemented in the US Army case 2. When ERP implementations are addressed the infrastructure also needs to be ressed. Describe the infrastructure components and what is imoved in choosing and installing the components Chapter 3. Implementation tegies 161 CASE 5-2 Real-World Case United States Army Source: From US Army Wehin ERP implementation 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 Amy and One Enterprise perspective. The capability to employ, deploy, and sustain tespitive combat capability can only be realized thucugh knowlelge superiority provided by systems that provide a comman 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 rallocate the resources (i.c. personnel, dollars, and time) required for this transformation ross the business mission capabilities designated by the BMMP: - Acquisition Financial management Huruan 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 aren Each of these business mission capabilities and mission areas must work together to eliminate boundaries, to synchronize transformation between the institutional and perational 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 mujor business transformation efforts historically fail. The failure fate 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) considerntions, along with the specific challenge for the army and strategies to overcome these challenges Table 5-2 offers several considerations. These will now he looked at more closely 162 Chapter 5. fuplementation Stics Jul B4% 19:46 Edit 8 162 Chapter 5. Implementation Stmiegies 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 Justity 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 totate often, und one ERP implementation could span two or even three sponsors Sponsors need to be engaged, not just brought in. They also need convey the importance of continued engagement to their necessary during transition Stakeholder Alignment. The army his traditionally been "stovepiped" (L.c., 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 CONT. Transformation management cun 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 truc 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 t.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 us to say, "I recog- mize we need to change. I am going to change, and I want you to change with me for the good of the army." w Tools Mobile View Share PDF to DOC Il B4% 19:46 Edit 8 X SOVIETS. USINESS SS personnel extermyn Tegastos. taxpayers). A communications strategy that includes lactical 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 diort, but governance of ERP programs is even more critical because of the size and scopo 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. 164 Chapter 5. Implementation Strategies 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 D W DD Tools Mobile View Share PDF to DOC Jul B4% 19:46 Edit 8 X 164 Chapter 5. Implementation Sungles The common argument for customiziny 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 usunlly the case. The statement is usually made by stakeholders or team members who either do not think they ure empowered to make decisions about process changes or want to aver 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 rure. 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 rigorots pilots should be a list of valid customization mainly based upon statutory and regulatory rules that carat he 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 vendeur. Belt-on provides similar benefits to those of ERP software. It can also provide process innovations necessary for specialized inchustry needs The additional cost of support anul muintenance of an acilitical software license would need to he 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 verstis 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 boll- ons may not meet the need. The next priority should be changing a business processor, usa last resort, customization of ERP software There are two potential methods for customizing ERP software, but only one method should ever be mad. The method that shall be prohibited by project leadership is modifica- tion of delivered software code from the venue. The cupted method is the creation of new code have 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 Minor Customizations Description Processing engines End-to-end processes Security structure Clone and modify ERP code Simple processing routines Reports Web pages Menus DO DD W Tools Mobile View Share PDF to DOC Menus Chapter 5. Implementation Strategies 165 the new code, creating a potentially castly modification from a time and budget perspective. a major business requirement needs to be met, a bolt-on is the preferred approach. Table S-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 uperades will update the delivered code, and the modified code can be integrated into the upgraded application if the underlying technology temuins 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 any 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 Teatre 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 atmount of customized code us 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 purse 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 fuer the definition of the buseline delivered code versus customized code. Finally, this analysis also presumes that a common baseline would be applicable across ERP puckages, leading to a comparable assessment of the levels of customization of, for example, a SAP verslas un 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, muy 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- mury of the configuration and customization approaches along with some pros and cons. 166 Chapter 5. Implementation Strategies TABLE 5-4 Comparison of Customization and Configuration Approaches Attribute Customize Configure Functionality Custom coding or Choose from out-of-the-box ul B4% 19:46 Edit 8 X 166 Chapter 5. Implementation Strategies TABLE 5-4 Comparison of Customization and Configuration Approaches Attribute Customize Configure Functionality Custom coding on 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. CASE QUESTIONS 1. What were the key goals in the army using an ERP system? 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? 3. How was the change management process incorporated into the implementation? 4. Discuss the pros and cons to customizing the system. W Tools Mobile View Share PDF to DOC

Step by Step Solution

There are 3 Steps involved in it

1 Expert Approved Answer
Step: 1 Unlock blur-text-image
Question Has Been Solved by an Expert!

Get step-by-step solutions from verified subject matter experts

Step: 2 Unlock
Step: 3 Unlock

Students Have Also Explored These Related General Management Questions!