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 numerous
successes, 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 Resource
Planning
(ERP)
Customer Relationship
Management
(CRM)
Supply Chain
Management
(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
Service
Increased Revenues
Reduced Sales Cost
CRM
Internal
Enterprise
Corporate Efficiency
Reduced Costs
Reduced Inventory
Increased Control
Integrated System
Central Data Repository
Standardized Practices
ERP
SupplierReduced Purchasing Cost
Information Exchange
Collaboration
Reduced 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
&
Business
Process
Redesign
Fit Assessment
& Validation
Rapid
Application
Development
Testing
&
User Training
Implementation
&
Go Live
Information Technology Framework
ERP 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 tools
that 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 overruns
Source: 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 technology
2. Ignoring the importance of requirements
definition
3. Jumping from the requirements definition
to the development phase
4. Not performing sufficient due diligence of
the vendor and the software package
5. Data conversion
6. 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 technology
2. Ignoring the importance of requirements
definition
3. Jumping from the requirements definition
to the development phase
4. Not performing sufficient due diligence of
the vendor and the software package
5. Data conversion
6. Insufficient training
Common Barriers to Success
CULTURE
The 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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (7)

Similar a Faculty.babson.edu grossman breeze_erp_erp_printable_version

Similar a Faculty.babson.edu grossman breeze_erp_erp_printable_version (20)

Último

Último (20)

Faculty.babson.edu grossman breeze_erp_erp_printable_version