So when you implement an ERP system, what do you expect from it? To improve your business performance? To make your employees’ jobs easier? During our research, we have found that, besides business or process improvements, some companies implement ERP at the request of their customers or in hopes of cutting redundant labor costs. However, as is the case with many tings in life, things don’t always go as planned.
An ERP implementation is accompanied by enormous risks to the organization. Risks can vary based on different phases of the ERP life cycle. It is important to be fully aware that an ERP system doesn’t simply mean an IT project.
Many times, when the ERP project is over, you find:
You didn’t get what you expected from the ERP system
Employees resisted the new system
There were no operational improvements
There were no significant costs saving
The new ERP system doesn’t align with your business processes.
I can go on and on about a variety of risks which might impact your business, but I think you get the idea with the sample listing.
Besides the risks associated with an ERP implementation, you might also wonder whether your ERP scope meets your current needs? Do you need to switch to a different deployment or a different system so as to lower your operating costs? No doubt at some point you realize that you need a system and process audit on your existing ERP software package.
By participating in Panorama’s 2010 ERP Benchmark Survey, you will have the opportunity to be selected for a complimentary, two-week Enterprise Systems & Processes Audit Program. We will provide a full review of your current ERP system’s deliverables and processes, summarize lessons learned, and advise you on how to make continuous project improvements.
Just spend 10 minutes to take the survey and you may very possibly get help to improve your enterprise system!
Blog entry written by Haoyan Sun, Research Analyst at Panorama Consulting Group.
Ever since Panorama started in 2005, frequent blogging has been one of our keys to sharing insights and client experience with the ERP community. Over the years, we have focused on sharing best practices around topics ranging from ERP software selection, ERP implementation best practices, and organizational change management. This year, we’ve upped the ante by expanding our author base to include more of our 25+ employees.
Since we have posted so many good blogs and articles this year, I thought I would share a few of my favorites so far:
The Marathon Man of ERP Implementations – I’m a fan of sports analogies and this entry from Cliff Simms, our Director of Organizational Change Management, highlights the ways that ERP implementations require conditioning, focus, and effort that isn’t unlike training for a marathon.
Are ERP System Customizations Starting to Feel Like a Build-a-Bear Workshop? – Written by Haoyan Sun, our Research Analyst, this is a good article highlighting the realities and dark side of ERP customization, a topic on the minds of most executives and project managers about to embark on an ERP implementation.
When Jumping into an ERP Project, It’s Sink or Swim! – Our clients often struggle with how to mobilize resources for an ERP project, and this entry provides some tangible tips on how to best prepare your team.
Six Steps for Executing Successful ERP Requirements Workshops – Another good entry with very tangible and real examples of how to define ERP business requirements, whether your are in the process of selecting, designing, or implementing a new ERP system.
Winning in 2010: The Goal Line – Another good analogy of how ERP implementations are like sports, this one focused on how to focus your end-goal on tangible and measurable business benefits.
ERP Software Clash of the Titans: SAP vs. Oracle – Of the blogs that I have written so far this year, this is easily my favorite. I can’t even keep track of the number of times clients ask me to summarize the strengths and weaknesses of SAP and Oracle, so I wrote a blog to address some of the key points.
Powell’s Message: Insights on ERP Software – One of our more recent blogs, this is a good one because it relates leadership messages from Colin Powell and applies them to leading a successful ERP initiative.
In addition, below are the top five most-read blogs on our web-site so far this year:
We will publish a more comprehensive year-end list later in the year, but we hope that these blogs provide some good summertime reading in the meantime.
Like most things in life, the more prepared you are for something, the better the outcome. That same principle applies to conducting a successful ERP software demonstration. By following the tips below in preparing vendors and participants, you will already be on the path to a successful ERP demo.
Tips for Preparing the ERP Software Vendor
Explain the ERP Requirements: You spent relentless hours gathering ERP requirements, so make sure the software vendor understands them! An ERP vendor can’t demo what they don’t understand. Don’t get caught letting the actual demo be the time of clarification.
Set Expectations: Not only should you explain ERP requirements, but you should also explain what the software vendors can expect during the demo. At Panorama Consulting Group, it is best practice to have the vendors spend the first hour of the day with all SMEs in the room addressing cross-functional requirements (i.e. dashboards and workflow) so they don’t waste time on these requirements during the functional sessions.
Dual Stream and War Room: Capitalize on the ERP vendor’s time! If possible, try dual streaming the demo to make sure all material gets covered. If questions are taking over a minute to address, set up a parking lot for later discussion. It is also ideal to set aside a “war room” as a chance for these parking lot items to be answered while vendors are on site.
The Early Bird Gets the Worm: Provide the software vendors with an early morning start to test their equipment. Nothing is worse than a room full of anxious participants staring at a blank screen.
Not only should you prepare the vendor before the demo but you should also do the same for the participants as well.
Tips for Preparing the Participants
Be Informative: Provide information such as the demo agenda and invites ahead of time. Business must continue as usual, so make sure the participants have time to cover their basis. Also, don’t forget to explain the scoring process so participants can properly gauge the sessions. Using demo scripts to write comments as they go will help jog their memory when inputting their scores digitally.
Set Guidelines: The ERP demos are the finale of the requirements gathering process. Attendees should be on time and attend the same sessions for each software vendor. If participants aren’t consistent with attendance, they can’t provide a reliable score.
Last but not least, remember these helpful reminders through the process to keep you on track and increase your chances for a successful ERP software demonstration.
Helpful Reminders
Remember to evaluate the ERP software based on requirements as apposed to vendor performance. When all is said and done, your daily life will revolve around the software, not the best performing vendor.
Designate a timekeeper to make sure sessions stay on schedule. Once the demos start to venture off track, it becomes very difficult to make up for the lost time. Remember, set up a parking lot for questions and even speak with the vendor before hand about the potential for WebEx follow-ups.
If you would like expert assistance with your ERP software demonstrations, visit our ERP selection page and learn more about our service offering.
Blog entry written by Jacqueline Gardner, a Senior ERP Consultant at Panorama Consulting Group.
As recently outlined in our white paper on executing a successful SAP implementation, we recently compiled client feedback on key functionality of the two leading manufacturing software packages: SAP and Oracle eBusiness Suite (EBS). These metrics, which are based on our database of client employees’ quantitative rating of the two packages as they relate to their business requirements, identify the key strengths, weaknesses, and tradeoffs of the two packages. The data was compiled exclusively from our manufacturing clients that short-listed both SAP and Oracle EBS as part of their ERP selection process.
The data reveals a number of interesting facts. First, SAP and Oracle rate very closely in a number of functional areas, with a statistically insignificant difference of .1 or less:
Logistics
Customer Service
Production Operations
Quality Control
There are some modules and functional areas, however, where SAP scores higher than Oracle:
Product Scheduling
Regulatory Compliance
Human Resources (HR)
On the other hand, Oracle scored higher in a number of areas as well:
Sales and Marketing
Product and Manufacturing Engineering
Product Configurator
e-Portals
Finance and Accounting
Obviously, these are just averages of much more detailed client evaluation metrics, but they provide a general sense of where the perceived strengths and weaknesses of each of the software packages lie. It is important to note that a client’s evaluation of a software’s functionality is likely to vary based on it’s unique business needs and requirements. However, this is one of several data points that can be considered during an evaluation of potential manufacturing software packages such as SAP and Oracle.
Manufacturing Software Functional Comparison of SAP vs. Oracle
Functionality
SAP
Oracle
Sales & Marketing
2.7
3.0
Production Scheduling
3.3
3.1
Quality Control and Lab
3.0
2.9
Regulatory Compliance
5.0
3.0
Finance and Accounting
3.4
3.7
Logistics
3.5
3.4
Human Resources (HR)
4.9
3.9
Customer Service
3.3
3.3
Production Operations
3.0
3.1
e-Portals
3.1
3.3
Product and Manufacturing Engineering
3.0
3.2
Product Configurator
2.5
3.1
Want to view more independent research related to SAP and Oracle? View our ERP video that highlights additional data comparing these two ERP systems. In addition, visit our resource center for the SAP white paper on the topic and watch for additional research from other leading manufacturing software providers.
When flying into Dallas-Fort Worth, the cities seem to shoot up out of nowhere from a giant prairie. Looking closely at the ground you will see many of the roads leading into the cities curve and bend, following no discernable logic at all. Why are they like this? Because back when Dallas was primarily a ranching town those were the paths the cattle would follow as they were driven into town. They would walk the long way around hills, cross rivers only at the low points, and follow a path of least resistance the whole way there. Over time people started following the same paths, and eventually they paved them and made them permanent. So now the town has a bunch of inefficient roads just because that was the way they had always been.
During my twelve years in the ERP software realm, eight of which have been spent customizing ERP software, I’ve heard many times that “All ERP installations require customization”. While I believe this to be true, I also know that it is vitally important to know the difference between customizing ERP software to improve a vital business process and ERP customizations done which only entrench a poor process. So, to use an old adage, be careful with customizing and “don’t pave the cow paths”.
Anything that is customized has an inherently higher value, whether it is automobiles, furniture, or jewelry. ERP Software is no different. Customizing the software always adds significant costs to an ERP solution. Customization must be done as a last resort to solve a problem with the software, which addresses a key business process. To customize a bad process is a sure guarantee of runaway costs and potentially ruining an otherwise successful ERP implementation.
Three Key Reminders About ERP Software Customizations
“But my business in unique” – Understand the reasons behind the customization. Are you adding significant value to the ERP solution by writing custom code or are you just entrenching a poor process that’s always been done that way. If it’s the latter, then change the process and re-visit the customization. Take a lesson from the companies who understand that the more standardized their processes are, the better the ERP software will meet their needs. Just because your product is unique, doesn’t mean every business process needs to be. Take the time to learn the difference and make the best use of the standard processes in the ERP solution.
Pay a lot now or pay a lot more later – Find a top-level programmer with significant coding experience. Ask to see their work and have it reviewed by other programmers. Finding, and paying for, a top-level coder up front, will save money down the road. Finding this person after you’ve already had a solution customized by an inexperienced person will be at a far greater expense and may even result in a failed project in the end.
Plan the work and work the plan – a little cliché perhaps, but a good programmer will gather requirements, analyze them, design and even test, to some extent, his solution in iterations many times before writing one line of code. The coder who writes code first is doomed to fail. The requirements will not be met, the solution will not be robust, it will be full of bugs and may not even work at all.
So as you enter into your next ERP selection or ERP implementation project, remember the cows, my story, and your ultimate project goals and ERP strategy.
Blog entry written by Kevin Cahill, an ERP Consultant at Panorama Consulting Group.
One of our recent blog posts outlined The Seven Deadliest Sins of ERP Implementations. A related poll question asked which of the seven variables were the biggest challenge for ERP implementations, and the results are interesting.
To recap, there are seven critical challenges that can disrupt an ERP implementation if not addressed appropriately:
Program management
Business process and workflow definition and improvement
Organizational change management and communications
Business and technical integration
Globalization and localization
Independent oversight of technical resources
ERP benefits realization
Unlike data captured in our 2010 ERP Report and other research we’ve conducted in the past, inadequate focus on benefits realization scored low in our online poll, with only 9% of respondents citing that as the biggest challenge. On the other hand, insufficiently defining business processes and workflows was the biggest challenge, according to 39% of respondents. Poor program management and not enough focus on organizational change management both followed close behind, with each gathering 26% of the votes.
The fact that business process and workflows are such a potential land mine for ERP implementations is not surprising for a number of reasons. There are six main reasons why this presents such a challenge for organizations:
Unrealistic expectations. We find that many of our clients expect that implementing a new enterprise solution will simply transform their business overnight, without carefully defining and engineering “to-be” business processes and workflows. This unrealistic expectation helps explain why, according to our 2010 ERP Report, most ERP projects take longer than expected.
Vendors often oversell and oversimplify. Many vendors oversell and oversimplify their software’s use of industry best-practices and streamlined business processes. While their software will inevitably improve business processes, they still need to be defined in the context of the implementing company’s operations and business policies and procedures.
There are often complex processes outside of the ERP system. Business processes may entail activities to be completed in the ERP system, but chances are, there are also processes that touch other systems or manual processes. These non-ERP processes need to be incorporated into the overall workflows in order for employees to better understand them.
Most ERP systems are very flexible. Most modern ERP solutions are extremely robust and flexible, so even a simple business process such as creating a sales order is likely to have multiple variations. It cases like this and hundreds of other business processes, it is not enough to say that you are going to simply adopt the software’s processes; even those workflows need to be defined, which takes time and resources.
Business processes are a source of competitive advantage. While some business processes, such as general ledger or financial reporting, are not sources of competitive advantage, other core functional areas are likely to differentiate your organization from competitors. For this reason, it is not always advisable to simply adopt vanilla functionality that can be easily replicated by others in your industry.
Employees need well-defined processes. Processes and workflows need to be clearly defined so employees can be adequately trained. Software developers and implementers have very different process definition needs than employees, who will ultimately be responsible for performing the tasks. Organizational change management, communications, and training activities are effective only with well-defined business processes.
ERP software is not implemented by simply plugging it in and assuming business processes and workflows will fall into place. Instead, organizations need to carefully define and re-engineer their processes. By keeping the above points in mind, your organization will be less likely to overlook a key, but often overlooked, component of an effective ERP implementation.
What do you think? Take the poll or review the full results from other readers.
When you select a ERP consulting company to manage your ERP implementation, they should essentially become the mother to your enterprise software.
Like mom, they are your allies. They represent you, stand by you, become the peacekeeper and support all your company’s idiosyncrasies. The management team supports your needs and helps with developing best practices.
Like mom, they are your teacher. The experience they have gained defines your education, guiding you along the path to a successful and smooth ERP implementation. They guide your decision making, train you to look to the future, and to make better decisions. They help you learn to read, write, document, and form decisions that support success.
Like mom, they are the go between. Conflict resolution between team members, between ERP software and processes, between conundrums and solutions, between nice to haves and absolute requirements, between spending your money wisely and over-spending, are the daily activities they provide throughout your project.
Like mom, your ERP project team is the “soccer mom”. They drive your ERP project forward; they pick your company up and deliver you to success. They attend your meetings, arrange for conferences, pat you on the back when you do well, and remind you to “pick it up” when your focus wanes. They monitor your homework and push you when you fall behind. They form the conduit between your users, steering committees and software developers.
And like mom, they are there when you need them. The management team is dedicated to you, dedicated to your project, intent on providing you with the tools that insure success.
Moms, don’t you love ‘em?
Blog entry written by Jeanne Hedman, an ERP Consultant at Panorama Consulting Group.
An ERP implementation is the implementation of a business solution. In order to be effective there must be alignment between business and their IT partners (internal IT organization, implementation partners, etc.). Collaboration is a key enabler for alignment. However, being in the same meetings or having the latest collaborative technology does not ensure collaboration. It must first begin with have a common understanding between the parties. Consider the following illustration:
First, we need to understand that business, IT, and the implementation partner are coming from different perspectives. All parties have strengths and weaknesses. Business best understands their existing business model and the underlying success drivers. The implementation partner understands the ERP software package and has multiple years of ERP implementation experience. IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies. Alignment is generated only when a common understand of the business model, ERP, and technology capabilities is shared by all three parties. When this alignment occurs there is effective communications and faster decision-making. Decisions move implementations forward. Now, let’s spend some time defining activities that we can do to expedite alignment.
Recommended Steps to Develop a Common Understanding for Effective Collaboration
Document Existing Business Processes. It is an area that I see many ERP implementations lack. The typical challenge is hear from business is “Why document my existing business processes if I know they are changing?” Here are my reasons:
Business users usually do not have a consistent understanding of their business model. Going through the exercise of documenting business process will highlight these differences and drive understanding.
Documenting the existing business model will enable you to highlight the exact organizational changes that will occur. How can you manage organizational change when you do not have a clear understanding of what’s changing.
Business process maps can be a key source of information to quickly educate IT and the implementation partner on the existing business process model.
Educate IT and the Implementation Partner on the Existing Business Model.Business should take a formal, iterative process to educate IT and the implementation partner on the existing business model. The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level.
Conducting Training
Level
Description
Suggested Duration
Business Solution
Provide an executive overview of the existing business processes, systems, and organizations that make up the existing business solution.
Four Hours
Business Process
Provide a work flow of business activities that result from a business event. Key variations and exceptions should be noted.
Two Hours for Each Business Process
Business Activity Grouped by Role
Provide a “day in the life” experience for key roles that support the business solution.
One Hour for Each Role
Complete ERP Training Before the Implementation Partner Arrives. Just as it is important for your implementation partner to understand your business model and your language it is important that you have an understanding of the ERP software and its language. Effective communication is a two party effort. Taking the required ERP training before the arrival of your implementation partner will enable you to more effectively work together.
Have the Implementation Partner Conduct Supplemental ERP Training. Education is an iterative process – you will never learn everything you need to know for support ERP in one class. I always say that the implementation partner completes your ERP training. Implementation partners have hands-on experience with configuration and maintenance of ERP solutions.
Implementation Documentation Should be Business-oriented. Nothing encourages alignment more than being able to think like your end customer. Too often we create project documentation that focuses more on technology than business reasoning and justification. There are times were I am guilty of moving too quickly from what needs to be done to how will it be done with fully understanding why does it need to be done. At the end of the day we build ERP software to drive a business result – not a software result. IT and the implementation partner should partner with business to develop business-oriented project documentation.
Business to IT alignment is a strategic goal that can only be reaching by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust. Implementing ERP is an opportunity to generate greater alignment by developing a common language for effective collaboration. When alignment is achieved then decision-making is effective resulting in a more successful implementation.
As we outlined in a blog post earlier this year, ERP implementations fail for five key reasons. Unfortunately, some of these failures lead to heads rolling, millions of dollars of budget overruns, and in some extreme cases, lawsuits against software vendors. In fact, the number of inquiries we have received to act as expert witnesses in ERP lawsuits has increased dramatically in the last twelve months.
When working with clients, we often hear the perception that most ERP failures or lawsuits must pertain to SAP implementations . After all, Hershey’s, Waste Management, and a host of other high-visibility failures involved SAP’s ERP software. However, our research shows that there is no pattern to ERP failures and lawsuits, other that they happen more often than they should and no one ERP vendor appears more or less likely to experience failure than the others.
For example, two new lawsuits were announced in the last 30 days: one against Oracle and another against JDA’s i2 unit.
In fact, we looked at the most recent lawsuits to see if there was a pattern among vendors and software solutions. As you will see in the table below, there is no apparent pattern to the vendors named in recent legal matters. If anything, when expressed as a percentage of total client base, SAP and Oracle probably have a lower lawsuit rate than other vendors on the list. However, because large and high-visibility companies are more likely to embark on Oracle or SAP implementations, those organizations are more likely to receive attention when something goes awry.
Lawsuits Againt ERP Vendors
ERP Vendor
Year
ERP Customer
Reason for ERP Lawsuit
Article Link
Epicor Software Corporation
2009
Ferazzoli Imports of New England
Epicor's system never worked as intended or promised. Initially paid: US$184,443.61. To date: US$224,656.42 (included the additional software and services meant to make the system operate properly).
ERP software giant Infor is taking legal action against customers as it seeks to recoup license fees it claims it is owed. An attorney for the tool company, which sued Infor in this case, confirmed that his client paid Infor something.
Hospital chain sues Lawson Software over retiring ERP apps, a breach-of-contract. Its agreement with the ERP vendor requires Lawson to provide -- for just a small fee -- replacements for two software modules that will be decommissioned next year.
The company sued Infor over a disputed $451,000 invoice Infor sent Carver in August 2008 for allegedly using the Maxim ERP package without a license since 2000. Carver says it received a perpetual license from CA (which acquired Maxim's original developer, NCA) in 1998 as part of a Y2K upgrade, and claims it stopped using Maxim anyway in 2006. The companies settled out of court in November.
Scientific Components sued Infor in U.S. District Court in New York over a dispute concerning temporary license fees needed to access MAPICS running on a secondary iSeries server connected via iTera's high availability software. The companies settled in December 2006.
The Company sued Infor over allegations by Infor that the company owed it more than $100,000 for exceeding the number of sessions in its license agreement; Western Textile claims its original license with CA was measured by concurrent users, not sessions. They settled in March 2007.
A faulty installation of the company's ERP applications. The lawsuit charges PeopleSoft with breach of contract and negligent misrepresentation, among other counts, and claims PeopleSoft's solutions for managing student applications amounted to little more than "vaporware."
Dexter asserted twelve claims: breach of the Software Agreement and the Consulting Aggrement, two claims of breach of express warranties, breach of implied warranties, fraudulent inducement of the Software Agreement and the Consulting Agreement, fraud, negligence, constructive fraud, statutory deception, and unjust enrichment.
Sky has alleged that EDS dishonestly exaggerated its abilities and resources when bidding for the contract, resulting in late delivery of the project and lost benefits that make up the the £709m in damages it is claiming
Considered possible legal action against Oracle and KPMG Consulting for a faulty computer system that the university estimates it spent $13 million installing, with the aid of the two companies.
The company claimed that a botched SAP R/3 implementation in the mid-1990s ruined the company, driven the company to bankruptcy. Six years later the bankruptcy trustee and Accenture settled out of court and the lawsuit was dismissed on August 8, 2002.
The National Federation of the Blind of Arkansas had sued the state in 2001 claiming the AASIS system was not fully accessible to blind persons. The state, in turn, filed a third-party claim against SAP, blaming the vendor for the accessibility problems. SAP agrees to fix Arkansas ERP system.
Alleges PeopleSoft sent in unqualified consultants to do the job, forcing Gore to rely on PeopleSoft's customer service hotline to set up the program after major problems occurred when the system went live.
Alleging fraud, negligent misrepresentation, malpractice, and breach of contract. TVG claimed that the database giant failed to fulfill its contract to modernize the company's production and management systems using its ERP applications.
The suit alleged that OneWorld was "defective and failed to operate and function as promised by the defendants." Failed and refused to fulfill its obligations under its agreements" and with IBM failed to install the OneWorld software "such that it is operational.
So what are some of the best ways to avoid becoming wrapped up in an ERP lawsuit? There are five key factors that can help you stay out of trouble during your ERP selection and implementation process, regardless of which software you are considering:
Ensure functional and technical fit of the software you select
Have realistic expectations about how long the implementation process will take and how much it will cost
Ensure adequate executive buy-in and support
Where possible, avoid customizing software rather than leveraging standard functionality
Ensure sufficient internal and external ERP software implementation expertise on your project team
It is common for companies to jump into an SAP project without first conducting the due diligence and planning required to make the project successful. Often times, organizations select an SAP solution simply because of SAP’s longstanding, prestigious reputation and its broad industry focus. However, before the SAP implementation begins, it is necessary for an organization to analyze who they are, what they want to be in the future as well as pinpoint their strengths and weaknesses, core competencies, and areas in need of improvement.
An SAP implementation project can take a very long time, and if not managed properly, can cause the project to consume unnecessary resources. Based on the experiences of Panorama’s ERP consultants, only clear SAP requirements can guide you through the selection process and help with conducting an effective ERP implementation. By the same token, clear requirements cannot be defined until business processes are defined, and to establish the clear business processes, a clear sense of strategic direction is required.
Although a smooth SAP implementation is completely feasible, most projects face numerous challenges. In our white paper, we summarized five major challenges encountered during SAP initiatives based on our annual benchmark studies. This white paper also includes ten tips for a successful SAP implementation.
Loading ...
