faculty.babson.edu grossman breeze_erp_erp_printable_version

1

F.W. Olin Graduate School of Business

Enterprise Resource Planning Systems(ERP)

a pre-briefing for the Cisco case

Understanding the Technology and the Issues of ERP Systems

By Professor Ted Grossman

Welcome to the pre-brief for the Cisco Case: Understanding the Technology, and the Issues of ERP Systems. Let me take a minute to inform you about the controls at the bottom of the screen. The right arrow is to advance to the next slide, and the left arrow is used to reverse one slide. The presentation will not automatically advance to the next slide at the end of the audio. It will be necessary for you to click the right arrow to go to the next slide. On the left hand side of the screen is the list of slides. You may use these as a navigation tool. If for example: you leave the presentation, and wish to return to a particular slide, click on the slide you wish to advance to. Lastly, on the bottom of the next slide is a button labeled “printable version”. If you click on this button, the system will pop up a window with an Adobe PDF version of the slides which you can print from. Once you have printed the slides, make sure to close the pop up window, to return to the pre-brief. Now click on the next slide arrow.

2


Introduction and Learning Objectives

In this lesson, we will:

• describe the functional modules in an ERP system

• understand the process by which ERP systems are implemented

• understand the issues that companies have faced when implementing ERP systems

• provide background for analyzing the experience encountered by Cisco in its implementation of an ERP system

printable version

There are several goals that we’re trying to accomplish as a part of this pre-brief. The first is to help you understand the various functions that are provided as part of an ERP system. As you’ll learn in this presentation there are numerous functional modules that come in the ERP system, and it’s important to understand what they all do, and how they contribute to the success of the ERP system. The second is to understand the process by which companies implement an ERP system. The third is to understand the issues that companies face when they implement an ERP system. As you’ll learn as a part of this presentation there have been numeroussuccesses, and some highly publicized failures, for small medium and large companies, in implementing ERP systems, and we need to understand why those have occurred. Lastly, I want to mention to you, that while this pre-brief is to help you analyze the Cisco case, we will not be discussing the Cisco case, but it’s important to understand how ERP systems work, their history, how they’re implemented, and what their critical success factors are so that you better analyze, and understand why Cisco did what they did, and why they were successful in their implementation of an ERP system.

3


Enterprise Systems Model

Enterprise ResourcePlanning(ERP)

Customer RelationshipManagement

(CRM)

Supply ChainManagement

(SCM)

It’s important to understand where an ERP or an Enterprise Resource Planning system fits into a company’s enterprise system model. We typically think of three main components, although there are many, many other components in a company’s IT strategy, and IT architecture. The three main ones we think about are supply chain management, enterprise resource planning systems, and customer relation management systems. As you see from this diagram, the ERP system is really the central focus for the internal functions of the company, with the ERP system supplying information to the supply chain management system, which passes information back, and likewise with the CRM system, there is this passing of information between the customer facing system, the CRM system, and the ERP system.

4


Enterprise Systems Model

CustomerImproved Customer ServiceIncreased RevenuesReduced Sales Cost

CRM

Internal Enterprise

Corporate EfficiencyReduced CostsReduced InventoryIncreased ControlIntegrated SystemCentral Data RepositoryStandardized Practices

ERP

SupplierReduced Purchasing CostInformation ExchangeCollaborationReduced Inventory

SCM

FocusValue PropositionSystem

Supply chain management system, focuses on our supplier, and how we exchange information with that supplier so that we can reduce the purchasing cost of all the materials, be it, direct materials, or maintenance repair and operation materials, from that supplier. The goal is of course reducing cost, but also providing a platform for exchanging information and to collaborate with that supplier, and to reduce the inventory, and the cycle time from when we determine that we need to order additional inventory, and when we receive it. In an ERP system, our focus is internal within the enterprise or the corporation. We’re trying to create corporate efficiencies which helps us control our inventory, control our costs by reducing inventory. We want to increase control over our entire operation, not just over our inventory, but over our manufacturing, our human resource management, and get better control over our accounts receivables, and our payables. We do that by having one integrated system; one central data depository which is integrated where all of these systems feed from this one integrated data source. Lastly we try to standardize our practices throughout the enterprise. That helps to provide efficiency and gives us greater control. In a customer relationship management system, a CRM system, our focus is customer. It is a customer faced system. We’re trying to increase customer service, increase revenues, and reduce sales cost. As I mentioned in the prior slide, we do this by feeding data back and forth between our ERP system, and our CRM system, where by our ERP system provides information about our inventory, and the cost of our materials, so that we can supply better information to our customers about their orders and when their going to be received and any problems they might be having with those orders.

5


ERP History• Companies initially developed disparate financial

and inventory applications

• They then began applying IT to developing manufacturing applications (MRP III)

• Software companies integrated all these functions, including distribution and warehousing, into a single integrated package called ERP using a single integrated database. One transaction updates all applications.

• As ERP companies installed more ERP systems, they learned “industry best practices” and offered personalization options (switches – turn on or off) in the package without having to modify the software. As options expanded, the number and complexity of personalization switches increased tremendously (thousands of switches).

It’s important to understand the evolution behind EPR systems. Initially companies developed financial and inventory applications. These were considered the low hanging fruit for management information systems back in the 70’s and 80’s, so the initial applications tended to be accounts receivable, accounts payable, payroll, general ledger, and inventory control. Then companies started migrating toward order entry. As companies became more sophisticated, they started looking at manufacturing applications and the first major manufacturing application that was developed was MRP3, which stands for manufacturing resource planning. In those systems companies said, “Well, what kinds of raw materials do I need to make this product, and if I know that I have to make 1000 of these widgets, therefore what kinds of components to I need to order from my suppliers, and what kind of manufacturing schedule to I need to have to accomplish that?” At some point in the late 80’s software companies looked at these financial and inventory applications and manufacturing applications and started integrating these applications into one package, which ultimately became called ERP systems. As time went on, these packages became more and more complex, with more functions being added to them, including, distribution, transportation, warehousing, human resource management, etc. The important thing was that they fed off of one integrated database. In the past all of those disparate financial applications and manufacturing applications had multiple file systems and multiple databases so therefore it was possible to have multiple versions of the truth. You could have vendor information in both of those systems which would differ. In your accounts payable system you would have the names and addresses where you would be paying a bill, where as in manufacturing system you would have the names and addresses of where you would be ordering merchandise from, so therefore you ended up with multiple files with differing information, all correct, but multiple versions of the truth. The goal in the initial applications of ERP systems was to have one single integrated database that all of these systems would feed from, and also that one transaction would update all of these applications, so it wouldn’t be necessary to input multiple transactions for the same sale. Entering a sale took care of invoicing the customer, decrementing the inventory, changing the manufacturing requirements, changing the ordering needs etc. As ERP companies became more sophisticated, and as they implemented more and more of these systems across a vertical industry they developed what’s commonly referred to as industry best practices. They learned as they implemented more and more of these systems, and started to personalize, or create personalization options within their package. Instead of having to reprogram the package, or to customize the package for each implementation, what they did was they programmed a series of switches, software switches, which you would either turn on or turn off, which would turn on, or turn off options within that package. Some of those things would be the kind of printouts that would be available, or what information would show up on the screen, or whether an item was ordered in each’s, or by the pound, or whether an item had sales tax, or even whether this company dealt in dollars or in British pounds, or Deutch Marks, or all kinds of options that were available to these packages. The result of that was that these packages became extremely complex, as the number of personalization switches increased into the thousands.

6


ERP History (continued)

• Because ERP packages are tightly integrated, personalization was the route of preference (installing vanilla) over modifying (rewriting the programs) the software.

• As the complexity of the ERP packages increased, ERP vendors enlisted 3rd party consulting organizations to help implement the packages at client sites, creating a major industry in ERP consulting practices.

• The platforms moved from mainframe to client server to Web enabled.

• ERP vendors have steadily increased the scope of ERP to include a “soup to nuts” menu, including full financials, manufacturing, distribution, HRM, analytics, etc.

• Over the past few years, major consolidation has taken place in the ERP vendor space.

Because ERP packages are so tightly integrated, and highly complex, it is very difficult to modify the software, or to rewrite the software. Because there are so many different personalization switches available as part of the ERP system, the route of preference by most companies was to try to live with the functionality that was offered within that ERP package, That was referred to as installing Vanilla, in reference to going out for ice cream and buying a simple flavor, and not an exotic flavor like Tuty Fruity. Companies tried to stick with the Vanilla software. However these packages are so complex, and the ERP software developers realized that it takes a long time to implement these packages, and we’re not talking about implementing them in weeks or months, but in many cases, over a period of two or three or four or five years, and it requires a tremendous amount of resources from the ERP software vendor to help the company implement these packages. Realizing that they didn’t have the resources to do it, ERP systems vendors went out and started to train third party consulting organizations to help implement the packages at the client sites. This created a major industry in ERP consulting practices. If you look at most of the large and many of the small consulting companies in the United States you’ll find that many of them have major consulting practices in implementing all of the various ERP systems. Historically the initial ERP implementations were on main frame computers; typically large IBM main frame computers. As we moved into the 90’s that migrated to client server technology, and many of the companies SAP, JD Edwards, and Oracle started offering their software in a client server environment. Ultimately as we moved into the late 90’s they changed that to make them web enabled. What you’ll find is that many companies have a mixture of the technology. They still have some of the stuff on main frame, but most of them have a mixture of client server, and web enabled ERP systems. ERP vendors have steadily increased their offerings of modules and have expanded the scope of their ERP systems to include a veritable suit to nut menus of functionality, including virtually all of the financial, manufacturing, distribution, transportation, analytics, human resource management, and demand planning and in fact many of them have now blurred the distinction between CRM and supply chain management, and have started to offer some of the modules that you would typically think of being CRM, and SCM. Over the past few years there has been a tremendous consolidation that has taken place over the ERP vendor space. Just recently, People soft, and JD Edwards merged. A company like Bohn has virtually gone out of business in the United States, so there have been a number of companies that had major positions in the 90’s in ERP who are no longer here and others have merged.

7


ERP Functionality

Source: www.sap.com

This slide, taken from the SAP web site, gives you an example of the suit to nuts menu that is available within an ERP system. As you can see, on the left hand side are the major categories of modules that are available within SAP’s ERP offering. It breaks in to analytics, financials, human capital management, operations, value generation, support operations, and corporate services. We’re going to take a look at a couple of those things, but as you look through what’s available there, within each of those colored blocks, like financial accounting, or financial analytics, or manufacturing, those break into hundreds and hundreds, of functions and modules that are available within that particular part of SAP’s offering.

8


ERP Financials

Source: www.sap.com

It’s important to understand that most companies to not implement all of the modules that are available within an ERP system. In fact, many companies only implement the financial modules, or the manufacturing modules. Some companies start with the financials and then a couple of years later implement the manufacturing modules etc. This slide, again from SAP, shows you just the financials that are available within their ERP system. If you look on the left hand side under financial accounting you’ve got the traditional general ledger, accounts receivable, accounts payable, fixed assets. Then you move towards the middle and you get into management accounting, with profit center accounting, and project accounting, and product cost accounting, and profitability accounting, and transfer pricing. As we move a little further to the right you get into cash management, and credit management. As you move all the way to the right you get into a relatively new area for ERP systems, and that’s corporate governance. That deals with auditing, and whistle blower. Some of this has come about in fact due to recent litigations, and changes which have occurred in the laws effecting public companies specifically the Sarveighn Oxly act which creates all kinds of new requirements on public companies in terms of how they report, and how they back up their numbers, and what their obligations are. Companies like SAP saw this as an opportunity to offer additional modules that they could integrate within their systems.

9


ERP Sales Orders, Manufacturing, Transportation, and Procurement

Source: www.sap.com

Financials and what SAP refers to as value generation are probably the two most important parts of an ERP system. SAP has lumped a whole number of different functions within this value generation; from procurement, and sales order entry and management to customer service, inventory and warehouse management, manufacturing, transportation. As you think about it, this is really the meat of what an ERP system does. It integrates this entire sales, procurement of raw materials and finished goods, managing the manufacturing process, managing the inventory and warehouse replenishment, the transportation. It’s the entire cycle, from when an order comes in, to how you produce it, how you warehouse it, how you distribute it, and ship it to customer, how you bill your customer, and then how you provide the appropriate customer service that is necessary for a successful transaction with your client. Remember, all of this comes from one transaction, one sales transaction updating one integrated database, so that there is one source for the transaction, and one central data repository which provides all of the information for all of the functions that are listed on this screen.

10


ERP Analytics

Source: www.sap.com

While the prior two slides focused on those functions that we typically refer to as operational control systems, those systems that are used by the worker bees of the organization to run the day to day operations of the company, analytics, those contained within this slide, are typically used by middle and senior level management of the company to help make better decisions, in running the medium term, and long term operations of the company. They provide the exception reports, and the strategic reports that help manage the direction of the company, and look for problem areas within the company so that they can better and more efficiently manage the company. If you look at this menu of modules within it you see things like strategic planning, or financial statement planning, or overhead cost management, profitability management. If you think about it, those are the kids of things that historical data, those pieces of information that bubble up from those financial systems, and the purchasing and the distribution and inventory and manufacturing to help consolidate and provide information for management to do their planning and their budgeting and to make decisions where they need to control cost or expand, offerings or expand staff, or whatever. Those are the functions that are available within analytics.

11


ERP Vendors• SAP: Click on MySAP Solutions Map to view

previous slides in more detail.

• Oracle

• J.D. Edwards

• PeopleSoft

• Microsoft Great Plains

• Macola

• Others

So who offers these services? Well, there are a number of companies that provide ERP solutions. The two largest companies, that have been in the business for the longest period of time are SAP, which is a European based company, and Oracle which you’ll notice was the company of choice in the Cisco case. They have the largest market share especially for medium to large companies here in the United States. Then come companies like J.D Edwards, and PeopleSoft which also have significant market share within the medium to large company market. Beneath that you’ve got Microsoft Great Plains and Macola, and a number of other companies that offer packages that are targeted toward small to medium sized companies. These distinctions have become blurred as time has gone on. SAP is trying to provide a scaled down ERP system for smaller companies, Great Planes having been acquired by Microsoft is trying to make their package more robust and go after more of the larger marketplace. PeopleSoft has acquired J.D Edwards, where PeopleSoft was stronger in human resource management, systems, and J.D Edwards was stronger in the manufacturing side of ERP. They’ve now consolidated their offering. As you can see the marketplace is getting somewhat blurred as to who’s stronger in what areas, but it’s clearly gone through consolidation, and the offerings are growing.

12


Project Initiation& Mobilization

Technical Assessment

& BusinessProcess

Redesign

Fit Assessment& Validation

Rapid Application

Development

Testing&

User Training

Implementation &

Go Live

Information Technology FrameworkERP Implementation Process

As I mentioned earlier, implementing an ERP system is not a trivial process. As you saw from the prior slides, ERP systems offer modules which impact all of the various departments within the organization of a company. As a result, implementing an ERP system requires representation from all of the user groups to participate in that implementation. The steps that we go through to implement an ERP system are represented on this slide. And they start off from project initialization and mobilization, through technical assessment, fit assessment, rapid application development, testing and implementation. We’re going to talk at length, and in depth about what each of those steps mean.

13


Project Initiation and Mobilization

• Confirm project goals

• Develop detailed project plan

• Establish Steering Committee and communications plan

• Establish cross functional core team

• Develop training plan and conduct core team training

Implementing an ERP system requires a tremendous amount of planning in terms of what your project goals are: What are you trying to accomplish? Drawing a tight box around what this system needs to accomplish, and what you’re willing to sacrifice as part of this implementation. You need to develop a detailed project plan: Who’s going to be doing what? how soon do I need to have it done by? You need to establish an executive level steering committee, and a communications plan. This is probably the most important part of any ERP, or in fact system implementation. If you don’t get the proper level of executive support from within a company, if the organization doesn’t see the commitment from senior executive management towards this project, you won’t get the cooperation that you need from the people who actually have to do the work. The next group that you need to form are those people who are actually going to determine the functions, test the system, go out and proselytize the system, and train the entire organization in how to use this system. This core team needs to have representation from all of the various core functions within the organization. They will be the ones who will be driving the planning and the implementation of the ERP system during the entire project. Lastly, you need to develop a training plan for the core team, and conduct core team training. They need to understand what this ERP system is capable of doing so that they can determine how it will fit within the organization.

14


Technical Assessment and Business Process Redesign

• Document “As Is” business processes, data and technology requirements

• Document “To Be” business processes, data and technology requirements

This next step is really referred to as requirements definition, and it really breaks down into two or three steps. The first is to understand how the company currently does business. What are its current business practices? What data and technology are available, within its current environment? Then you need to understand how the ERP system, as it is available from the manufacturer with all of its personalization switches works. What’s available? What functions are available with it? How it can fit in within your company. What data elements are available within that ERP system and what its technology requirements are? What kind of hardware does it use and what kind of network is required to make it work? Then based on understanding how you’re currently doing business and the way the package is capable of working you determine where you want to go, or the to be business processes. How are we going to run our business based on the capabilities of that ERP system, and the data that’s available within it, and the technology requirements that will be inherent in this new to be environment?

15


Fit Assessment and Validation• Perform “As Is” and “To Be” gap analysis

• Establish and test prototype environment: conference room pilot (CRP)

• Resolve process and technology gap issues

• Research and acquire “Bolt Ons”

It’s always necessary to reconcile the differences between the “as is”, and the “to be.” This isn’t just in terms of processes because clearly the new system is going to require that the company change the way they do business, the way they handle orders, they way they handle materials, or the way they communicate with their customers, or whatever it is. Those are the business process reengineering that’s necessary when you implement a new ERP system. However, there are also organizational changes that go along with the change from the “as is” to the “to be” and that’s part of this ying and yang that goes on as you implement an ERP system. The next step is to take this “to be” system, set the switches and establish a prototype environment. We usually refer to this as a conference room pilot, and it’s called that because what companies to is, they take a conference room, they set up a series of computer terminals connected to this new technology environment and hooked up to the ERP system, and they set all the systems, and they prototype how this new system will work. They bring in people representing the various functions company, and they’ll sit them down, and say: “try out this screen, how does it work, how does it reconcile with the way you’re doing business, are you comfortable with it?” It’s very important that you prototype the environment, and understand the implications on the organization and what processes are going to have to be changed, and how the organizations going to have to be changed, to fit this new “to be” environment. Then you have to resolve these differences in processes and in technologies and we usually refer to these as gaps. Some systems will do a great job in some areas, but will have gaps, and might not have enough EDI or might not be able to handle multiple kinds of taxes, or multiple kinds of currencies. The question is how do we adapt the system to do that? Currently what you have to do, is you have to go out, and find other software packages that you can bolt on, to the ERP system, and you’ll have to interface those “bolt on’s” to the ERP system, so that they pass the right data back and forth.

16


Rapid Application Development• Identify data conversion sources / data

mapping and data cleansing

• Develop, test, and install data conversion tools

• Design and develop system interfaces to legacy systems and “Bolt Ons”

• Develop process documentation and training material

Once you’ve prototyped the system, the next step is to actually develop and implement the ERP system. Most people really don’t think about this issue of data conversion however, it’s probably the one that’s the most difficult to do. You first have to identify what data elements you have within your legacy systems. Where do I have customer information? Where do I currently have billing information? Where do I have my accounts receivable, my accounts payable, my current manufacturing data? Where does it reside, and what does it look like? What are the data requirements of the new system? Well, if a customer name is 30 characters in the old system and it’s only 25 characters in the new system, how do I convert that? If I had a 4 line address in the old system and a 3 line address in the new system, or if I had a 3 line address in the old system, and a 4 line address in the new system how do I map that from one to the other? Also how do I clean my data? I might have data appearing in my legacy systems in multiple places and multiple sources for the same data. Which one is the right data? How do I clean my data so that when I bring my data over to the new system, I know that it’s correct? You have to develop, and test and install those toolsthat you’re going to use for converting the data from the old system to the new system. You have to design and develop the interfaces between the old legacy system, and the new system, and the “bolt on’s” to the new system. Sometimes these can be very difficult, especially when they have different kinds of data requirements. Lastly you have to develop documentation, and training manuals. This is one area that companies frequently skip on. They don’t provide the right amount of training, and if you don’t train your organization either they’re not going to use the system, or they’re not going to use it properly, and you’re going to have all kinds of problems when you go live with a new system.

17


Testing and User Training• Load production hardware, software, and

interfaces

• Execute conference room pilot and confirm personalization

• Test system interfaces

• Schedule and conduct end user training

The next step is to test, and to train your users. You have to load the production hardware, software, and the interfaces. You have to execute your conference room pilot with the latest of changes, and confirm that everything works the way you want. You have to test those system interfaces between the legacy systems that will remain, perhaps your new data warehouse, the “bolt on’s” and you have to schedule and conduct, end user training. As I mentioned in my last slide, this is the one that takes the most time. Because every group within the company is impacted by this system, how do you think about training all those people? Do you train the trainers, and the trainers go out and train the people within their user groups. There are different strategies that you can use to provide end user training, especially where you’ve got multiple geographical user locations, located within the United States, or in many different countries that are going to be impacted by the system. How do you get to all those people, how do you train them appropriately? How do you train them in their particular area, and in some cases in their language? Remember, many of these people don’t have technical knowledge. Many of them might be technophobes. How do you train them, so that they become comfortable with change? Managing change, and getting people to accept change, is very difficult.

18


Implementation and Go Live• Load and validate production data

• Develop go-live checklist

• Implement new system and routines

• Stabilize environment

The last step in the process is to implement the system, and to go live. That requires you to load and validate the production data. We talked earlier about the issues of mapping data, and cleansing data and coming up with the tools to move the data from your old legacy systems to your new ERP systems, and that’s all done in advance of going live. In fact, there’s certain static data that we can move, from the old system to the new system, before we’re ready to go live. Things like customer data or historical sales data can be moved from the old system to the new system, well in advance of going live. However, there’s certain dynamic data, like accounts receivable information, or inventory information which has to be loaded at the last minute. This is information that has to be accurate as of last night, or just before you turn the system on. While you’ve done all the testing to make sure that when you go to move the production data that it’s accurate, it has to be done once again, at the very last minute. You have to develop your go-live check list, you have to implement the new systems and routines, and make sure that they’re working, and that they’re working correctly, and you’ve got to stabilize the environment. As you read the Cisco case, you’re going to see that that was one of the problems that they had when they went live. Their environment wasn’t stabilized, and they had to do some things to get those computers to have the proper response time. That’s one of the things that all of these companies have to think about when they’re implementing an ERP system. You can have all the functionality in the world, and this could be the best system in the world, but if you don’t have the right kind of response time, if when you go to do an inquiry, or to enter a sales order, it takes five minutes for the computer to come back to you with a response, that system doesn’t work. It doesn’t work effectively, and it won’t get used well, so the technical environment must be stabilized so that the system works appropriately.

19


Issues in Implementing ERP Systems

Most ERP implementations today result in cost and schedule overrunsSource: Standish Group

The next part of our pre-brief deals with issues in implementing ERP systems, and there are some interesting statistics that I wanted to share with you today. On the left hand side of your screen is a pie chart, which has some rather telling information about ERP implementation results. If you’ll notice, 35% of ERP system implementations actually get cancelled. 55% of ERP implementations result in overruns of one sort or another. And only 10% of ERP implementations are delivered on time, on budget, and as planned. If you look at the chart on the right hand side of the screen, you’ll notice that the average cost overrun is 178% of budget. The average schedule overrun is 230% and in fact many systems see less than 60% of the functionality that was originally planned at the beginning of the ERP implementation. That should tell you, that for some reason, companies don’t have a realistic view of what it takes to implement an ERP system. It takes much longer, it costs much more, and you don’t always get, what you think you’re going to get, when you started this initial odyssey.

20


Common Barriers to Success

1. Focusing on technology2. Ignoring the importance of requirements

definition3. Jumping from the requirements definition

to the development phase4. Not performing sufficient due diligence of

the vendor and the software package5. Data conversion6. Insufficient training

The most common mistakes of ERP implementations:

There are many mistakes that organizations make in implementing ERP systems. The six on this slide are the most common ones. The first is focusing on technology. Technology companies frequently try to push a silver bullet approach to solving problems however there is no evidence, anywhere in the history of information technology that software alone will solve a business problem. The second is ignoring the importance of requirements definition. Organizations too often ignore the need to define an optimal process, and then use the technology as an enabler for that process. In too many instances organizations try to either adopt a process that is inherent in the ERP solution even if it doesn’t fit their business requirements, or they to shoehorn their legacy processes into a into a software package that is not designed to support their processes. In both cases, they sub-optimize the capabilities of the technology, and don’t take advantage of the opportunity to streamline their business processes, which is the entire point of technology implementations. In some cases they give up certain processes that are strategic for them, just because they think that the processes within the ERP system can be implemented, faster than modifying the existing system. Frequently they jump from the requirements definition to the development phase too soon. Pressed to deliver a system against predefined time lines that don’t take into account all of the necessary implementation steps, organizations frequently rush the process and they neglect to build a solid implementation plan, and establish a solid agreement across the organization as to what it will take to develop and implement the solution prior to implementing the technology. Because these systems are so complex, it’s very important to perform sufficient due diligence of both the vendor, and the software package before committing to it. This is not a simple process. You can interview the vendor, you can go through demonstrations of the package, you can request to interview some of the vendor’s customers although the vendor will certainly not tell you about those customers that have been unsuccessful, but it’s important that the company perform it’s own due diligence of the package. They need to get a demo version of the package, and test it to make sure that all of the basic functions that are necessary for that company are contained within the package. Data conversion and training are two step children that are not taken into consideration adequately when planning an ERP implementation. It’s very important that the data elements be available and companies understand how they’re going to go about cleansing those data elements, and converting them into the new system, and how they’re going to train the organization to use this new system. Without adequate training, this system will not work well.

21


1. Focusing on technology2. Ignoring the importance of requirements

definition3. Jumping from the requirements definition

to the development phase4. Not performing sufficient due diligence of

the vendor and the software package5. Data conversion6. Insufficient training

Common Barriers to Success

CULTUREThe most common mistakes of ERP implementations:

All of this translates into culture. How do you get the ERP system to capture the culture of the organization, and how do you get the culture of the organization to understand and adapt itself to the processes, and the changing needs of the organization as a result of implementing this ERP system?

22


ERP Disasters• While there have been many successes in

ERP implementations, two well-publicized problem stories include:

1. Hershey Foods: Click on Hershey to read about the problems at Hershey.

2. Nestle SA: Click on Nestle to read about the experience at Nestle.

While there have been many successes in ERP implementations there have also been several high profile, well publicized disasters. Hershey Foods is an example of one of them. Hershey Foods rushed their ERP implementation and as a result missed shipping their merchandise during their busiest time of the year, which is Halloween, resulting in Hershey Foods having to take a major hit against their quarterly earnings. Nestle is another example of a troubled ERP implementation. Click on the links on this page to read about both the Hershey, and the Nestle problems.

23


Additional Suggested Readings• The ABCs of ERP

• The Return of Enterprise Solutions: The Director’s Cut

• Faster, Cheaper ERP

• Getting ERP Deployments Right the First Time Around

There are four articles that I’ve provided you here on this page, that provide additional information about ERP systems. I encourage you to click on the links, and read the articles, as they will supply you some additional information to better understand both the implications of implementing it, and some of the results for companies that have implemented ERP systems.

24


Conclusion

In this lesson, we:

• described the functional modules in an ERP system

• understood the process by which ERP systems are implemented

• understood the issues that companies have faced when implementing ERP systems

• provided background for analyzing the experience encountered by Cisco in its implementation of an ERP system

Let’s recap what we learned in this pre-brief. The first thing we did was we described the history of ERP systems. We gained an understanding of the functional modules within an ERP system. We gained an appreciation of the integrated nature of an ERP system. Then we learned about the processes by which ERP systems are implemented, the steps that are necessary, the implications on the organizations, and what must be done to make it work right, and what are the critical success factors, and the mistakes that are commonly made. Then we looked at understanding the issues that companies have faced in implementing ERP systems, and we gained an appreciation for what those are by looking at the statistics of what percentages are canceled, and the cost overruns, and the time overruns etc. Hopefully this pre-brief has provided some background for you, so that you can better analyze the experience that was encountered by Cisco in its implementation of its ERP system. While Cisco’s ERP implementation appears to have been a major success that is not typical for most ERP implementations and you should take that into consideration as you analyze the Cisco case. Thank You.

faculty.babson.edu grossman breeze_erp_erp_printable_version

Technology

olin graduate

conference

human resource

left hand

microsoft

critical success

single integrated

supply chain