Part 3: Having the right approach and attitude to an ERP implementation
(cross-posted from SYSPRO Smarter ERP blog)
“Change is not made without inconvenience, even from worse to better.” Samuel Johnson
Do you know how complex Microsoft Word and Excel are?
Because Word and Excel look so easy, people under-estimate how complex other standard systems, like an ERP, can be. If business users knew how complex those two Microsoft applications really are, they would be more thoughtful and careful when embarking on a complex software project.
The statistics on ERP project failures are staggering. However you measure it, the figures don’t look good when it comes to software project success. There is a blog dedicated just to software project failures and a recent Harvard Business Review article highlighted the unexpected risks of major IT projects. Ironically ERP project failures keep occurring despite research that started more than 10 years ago on the critical success factors of ERP implementations, and which has been repeated several times since then.
While an ERP implementation is an IT project, it is also much more. Its main drivers and objectives are business-related, and it has a major impact is on people, processes and culture. Some important non-technical aspects of ERP projects were recognized early on:
“…large, complex projects, involving large groups of people and other resources, working together under considerable time pressure and facing many unforeseen developments.”
The way, therefore, to ensure that an ERP project is successful is not just to focus on IT issues but to have the right approach and attitudes. (Having the right people in the right place during the implementation is the topic of another blog series). The following are critical attitudes and approaches for a successful ERP project:
- Top management support
- Clear goals and objectives
- Management of expectations
- Change management, communication and user education
- Project/program management
Let’s look at each of these briefly.
Top management support
While top management initiate an ERP project, giving it their blessing to start, the tendency to delegate the project once it is underway should be challenged. Top management needs to remain not only accountable but also responsible for the project. The question of who in the executive team should be the ERP guardian is debated on numerous projects. One commentator has a strong argument that the CEO is the only proper person to be custodian of the ERP system.
Clear goals and objectives
Too many software projects use the metric of ‘on-time, on-budget’ to measure project success, but as a recent ERP project failure showed, if you only use those metrics other important objectives can get omitted, such as customer or user satisfaction. At the outset of the project, before software selection is done, success should be truly and clearly defined. How do we know the stakeholders will be happy? What specific measurable benefits should the system deliver? Put another way – what does DONE look like?
Management of expectations
One reason why a senior executive should be in charge of the project is so that it is ‘owned’ by the business, rather than by the implementation consultants who often develop the project plan. The project’s scope, planned deliverables and schedule have a significant influence on setting expectations.
Deciding on deliverables and schedules without sufficient executive and staff buy-in can produce an environment where legitimate concerns are ignored and distrust is created. When determining the scope, focus only on what is ‘in scope’ (which only implies what is excluded), but also make explicit what is ‘out of scope’ – this aims to avoid those difficult conversations of “but I thought XX was going to be included.”
Change management, communication and user education
There’s a saying in change management:
“Old organization + New technology = Expensive old organization”
An ERP project can succeed or fail through the commitment of the people who use it. Therefore it makes sense to communicate with employees – early, often and in-depth.
I mentioned in a previous blog that one of the aspects of managing an ERP project is how to handle business process changes. A Forrester Research comment on change management was:
“Any business process change is strongly related to personal change — that means your people — and this is often the component that gets shortchanged.”
The change management and training programs should commence in the early stages of the ERP project, not, as is often the case, near Go Live date.
When it comes to training, there are some basic mistakes to avoid.
- Training should not be considered a secondary, optional aspect of the project
- Users need to be educated (taught the inner workings and reasons) as well as trained (how to complete a task)
- Training should be planned for the long term
- A variety of training methods need to be employed
Project and program management
ERP projects can be complex and long; organizations therefore need to invest in a project management capability. This means they need to understand the principles of project management relating to software projects, and be prepared for the challenges of managing a project.
Projects costs money. Don’t spend the money? Then, as Dr. Phil says, “how’s that work’in for ya?”
Finally, since an ERP project has long-term consequences, businesses need to develop a program mentality when it comes to their ERP application. This is to ensure that the system receives ongoing attention, oversight and support throughout its life cycle.
Part 2: Changing the system as business realities change
(cross-posted from SYSPRO Smarter ERP blog)
Hands up all those who have started implementing an ERP system and not had to deal with changes as the project progresses. No one? I am not surprised. Has anyone gone live with an ERP project and never had any changes afterwards? The reality of any ERP project is that scope changes occur during the project, and after going live it is guaranteed that there will be more requirement changes.
In my previous blog, I discussed how integrated BPM (business process management) and ERP could provide a visual representation for designing and building an ERP, referring to my personal experience of having built a house. The second part of the story is about changing the plans when new ideas or new realities come up.
With my house we had extensive discussions with the architect during the design phase and we were confident that everything had been covered. But when we spoke to the builder he made additional suggestions and noticed some things that had not been considered. Using the blueprint drawings, we could decide on the changes needed, assess the effects on the building and the costs, and then make alterations to the drawing that everyone agreed with. It was a clear and understandable approach to taking on new ideas and changing plans even after everything had been agreed.
The same process happens in ERP implementations. Organizations often spend a good deal of time working on the design of the ERP application using skilled (and expensive) consultants to help them. This they believe will ensure they have got it right before the implementation starts. However, no matter how good the team, the fact is that issues can be over-looked, or valid change requests suddenly appear which had not been considered earlier.
In the past this was a problem because the ERP planning process assumed stability, and ERP systems were geared towards controlling data and automating processes. Flexibility and handling change were not priorities. Of course the world has changed and we now expect our software to be adaptable. For enterprise software, with its high level of inter-connected functionality and degree of complexity, this has been a challenge … until the advent of integrated BPM and ERP. With this integrated process toolset, new ideas and issues can be raised after planning is finished, and re-planning, review, approval and documentation can be managed more easily and clearly.
This concept of a model-driven ERP system is now possible using SYSPRO Process Modeling (SPM). Model-driven architecture has been around for 10 years, and is recognized as the most effective way to manage and optimize business processes, especially in a volatile environment. SPM helps in process management from high-level ‘Core Processes’, to actual ‘End-to-end’ processes, right down to activities and screens. For each level, this is integrated with the organizational structure, technology, data, and SYSPRO’s supported business processes.
This allows the organization to see how everything is inter-connected, and also to see how changing one element impacts on other areas of the model.
Hopefully the days of referring to ERP software as ‘monolithic’ are coming to an end. Changes to an ERP system should be expected and planned for because there are many aspects that can change. If you have been through more than one ERP implementation, particularly from the user perspective, what was your experience of making changes to the system? What would have made it easier?
In the next part of this blog series: Having the right approach and attitude to an ERP implementation.
Part 2 of a series on enterprise information systems
Building a house on a solid foundationThis blog has been cross-posted on the SYSPRO corporate blog.
You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse fail, are appearing on many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.
Eric Kimberling’s Panorama Group identified this similarity at the same time I was building the house. The critical requirement for construction is the blueprint; the drawings of what the house will look like, what its parts will be and how it will be constructed.
The problem with projects, especially complex ones (like a house or an ERP project), is how to communicate the varied components, interactions, hierarchies and responsibilities to all parties concerned. You need a representation that will capture all these elements in a way that is clear and easy to understand, even if you are not a professional in the field. This will ensure that the various parties involved can achieve alignment in terms of common understanding of business needs and technology capabilities.
You also need a way for the plans to develop as your ideas and perspectives evolve. When you start planning a house you don’t go straight into the details. You may have some thoughts (even a vision), but you need guidance from an architect on what is possible, feasible and within budget. So you start with drawings that help you decide on the appearance of the house, then move into the technical and architectural details, and finally the construction and engineering specifications.
Until recently there was no easy way for ‘ERP novices’ to see the business in terms of how it would look after an ERP implementation. But now, with the integration of business process modeling (BPM) and ERP, those visual representations (the drawings) can be done. For an ERP implementation, the functional requirements and business processes are like the rooms and materials of a house, and a business process model is the equivalent of an architect’s drawings. The Business Process Modeling tool can be used in the same way that you start a house with some initial sketches. It allows you to view the business from a high level to make sure executives agree with the ‘look’ before going into more detail.
This graphical way of representing an ERP project can replace the mountains of design documents that were the staple of past ERP projects. This pile of paper used to be the main documentation a business had to describe its strategy, plans and processes. The sad fact was that only a few people ever probably read them, and even fewer understood them.
It’s about time that “the big freakin’ requirements document must die”. What is needed is one tool which can capture scope at different levels in one place, which provides traceability between business requirements and IT capabilities, and which uses better means of communication to illustrate than the common legal-style text of many project documents.
If you are an ERP implementer, how did you experience communicating via traditional project management tools? If you’ve experienced an ERP project as a business user in the past, what did you think of the project documents that you had to use?
At SYSPRO, we now provide a tool that can replace the big project document, which is graphical and shows how integrated BPM and ERP functions: SYSPRO Process Modeling (SPM). Analyst Brian Sommer described the combination as “A Key Mid-Market Need”. With SPM we believe that our customers will get more value, and have a far lower risk of problems in their ERP implementation projects.
In the next part of this series: changing the system as business realities change.
Last year I wrote about the problem with the billing system that Johannesburg City Council had implemented. The project, a SAP-based implementation internally called Project Phakama, is in the news again for all the wrong reasons. According to one report, the project has cost the City over R800 million (over $100 million). The situation has reached such a bad state again that there was a report that central government was considering stepping in.
This is obviously a highly strategic and visible project, and it’s not uncommon for these kind of ‘heroic’ projects to have very public bugs. As I mentioned in my previous blog about this project, SAP had won a quality award for it, but has readers of Michael Krigsman’s Project Failure blog will know, the software is only one part of the issue.
In the ‘Billing Crisis’ news report, an opposition spokesman says the problem is that it is a complex system
“…and people have not been properly trained for the system”.
‘The city’s head of finance, Parks Tau, said implementation of the IT project had been completed and that problems with it were “interface-related”.’
So here we have two issues which need to be addressed – people-related, and external systems.
On the one hand, the project owners (City officials) seem to be saying that the project is nearly done. On the other, they don’t appear to have the complex IT project experience to know “What ‘Done’ Looks Like”, to use Glen Alleman’s phrase.
SAP is fortunate that it is not their name that is being publicly criticised, as has happened in other municipal projects.
One thing I am glad about – that I am not the vendor or implementation partner project manager on that project.
Update #1: SAP have distanced themselves from the project – ‘Don’t blame us‘
Update #2: The story behind the project chaos is revealed – The connections that disconnected Joburg
This is the first of some blogs I will be repeating from my previous site - this blog from January 2006.
Anyone who has implemented business management software – whether ERP, CRM, BI etc – knows that the success of the application doesn’t depend on the software, but the way it is introduced and adopted in the organisation deploying it.
I know of two companies that deployed the same ERP system from JD Edwards, on the same hardware, at the same time, but one became a reference site within 2-3 years whilst the other was still struggling and complaining about the system.
A new article from MIT’s Sloan Management Review (subscription required), has the following comments:
“New tools must first be integrated into a system that’s already in place. It is important to remember that tools are embedded both within the organizations that deploy them and within the tasks the tools themselves are dedicated to performing. Moreover, each organization’s approach to how people, processes and tools are integrated is unique — a result of formal and informal routines, culture and habits. All too often, companies spend millions of dollars on tools that fail to deliver on their promise, and the culprit is typically not the technology itself but the use of the technology.”
… as my kids would say, ‘Duh’!
In my experience of ERP implementations, I’ve noticed how a major ERP application, to which a company has committed significant budget and resources, starts losing its value in the organisation sometime after the system is implemented. I call this application entropy (after the thermodynamic effect that energy degrades to heat, or noise); SYSPRO calls it ‘application erosion’.
The process works like this. When an ERP project starts, people are often keen, committed and involved. But not long after implementation, those ideals and attitudes begin to diminish until a point is reached when the comments start: “ this ERP isn’t giving us value anymore, why are we still using it?” This eventually kicks off an ERP evaluation or re-implementation project, and the process begins all over again.
When executives invest similar large amounts in capital equipment, however, they are usually insistent that the equipment is used optimally and people are properly trained and kept up-to-date. When it comes to enterprise software, that drive is not applied with the same vigour. It seems that continual training on IT-related aspects is not often company policy in many businesses – people are supposed to “get it”, absorbing knowledge and expertise by osmosis, usually from others. This approach commonly leads to the growth of poor practices.
What are the solutions?
One is training – obviously. It probably needs only 1-2 days training per year per person for a typical user to keep up-to-date and proficient on a particular area of an ERP system.
Another solution is to make IT part of the executive board’s responsibility. In South Africa, The King III code of corporate governance seeks to make IT a mandatory item on the board’s agenda. King points out that IT is now essential for the modern business and the board should understand the issues and strategic importance of IT. The recommendations include that the board be responsible for:
- strategic alignment of IT with the business,
- improving the value of IT,
- optimising knowledge and IT infrastructure.
This leads to a third solution – what SYSPRO calls the “Seeker of Value”. The role of the Seeker of Value is to prevent the disconnect that occurs in the ERP system of an organisation. This person, or group of people, is identified as being responsible for bridging the gap between the ERP supplier and/or implementer, and the organisation, thereby reducing costs, optimising ROI and giving the organisation greater control over its destiny. The kind of issues that a Seeker of Value should take responsibility for are:
- having some knowledge, and keeping up-to-date with, the ERP;
- balancing and scaling the software;
- aligning the ERP with the strategy of directors and management to prevent disconnect between the high-level business processes and operational processes, and to ensure the software is meeting the strategic business requirements of the organisation;
- ensuring the board is aware of new business models that the software could accommodate;
- using the ERP system to improve or implement methodologies such as Six Sigma, Lean and Balanced Scorecards.
Getting value from an ERP system is never going to be one of those activities that can be left to proceed automatically. In order to keep entropy (or erosion) from occurring, continual intervention is required. Individuals and groups in the organisation need to make a conscious decision to ensure this happens. As Elliot Ross points out:
anything you have implemented, but have never revised is probably an obsolete silo that is sucking the life out of your organization.
Like so many IT projects, success or failure does depends more on people issues than technical ones. If your organisation managed to avoid ERP entropy, what are the policies and factors you dealt with to combat the erosion of value?
Update: I should have checked, but it has been brought to my attention that this topic has also been covered by TechnologyEvaluation.com – Application Erosion: Eating Away at Your Hard Earned Value and Application Erosion: More Causes and Cures.
Other links related to this subject: The Problem with Mature ERP Systems (ComputerWorld)
What Does a “Successful” ERP Implementation Actually Mean? (CIO.com)
In a blog on the ITtoolbox site, Steve Phillips comments that companies are moving away from using external ERP consultants in favour of using in-house expertise – Why ERP Software Consultants Cannot Save The Day.
His view is:
The ownership philosophy is about controlling your project destiny and built on some fundamental principles. … 1) It is possible to take internal responsibility for project management. 2) It is possible to develop and/or acquire internal software expertise to the point outside application consultants are rarely needed. 3) It is possible to become much more educated and less reliant on the false sense of security an army of consultants can bring. 4) It is possible to realize ERP benefits by developing better software and business process solutions with fewer outside consultants. 5) It is possible for internal personnel to do up to 70% of what many pay consultants to do.
Except for item 4, in my experience, I haven’t found any companies that can do what he suggests. I suspect it is a function of certain factors – a primary one being the size of the organisation. But I also believe that business maturity, and the availability of knowledge and experience play a significant part.
In the South African market, most businesses fall into the small-to-medium (SMB) category. Employees in SMB companies tend to take on more than one role (debtors and creditors, pre-sales technical and sales, production planning and management) which leaves them little time to focus on issues which are not directly relevant to the job they must do. So finding time to acquire software expertise is difficult or requires after-hours learning. In time, and if a person stays in the same job, they might become “more educated and less reliant.” However, given their time constraints, it is highly unlikely that people will have the time or knowledge “to do up to 70%” of what a consultant will do.
Also skills and expertise are in short supply in this country, so someone who develop technical skills may easily find themselves moving out of their business job and into a technical or consulting role. Similarly, project management requires experience and time to spend on it, which senior staff in SMBs (e.g., finance managers and directors) rarely have. Companies will tend to have a less senior person overseeing the project, but all the details and work that goes into project management has to be done by someone with the background and time allocation to do it – in other words, a consultant.
In the South African context, therefore, most average companies (not large ones over 1000 people) do not have the people, skills or time to take on an ERP implementation themselves. The cost of bringing in consultants outweighs the risks of failure in trying to do the project in-house.
Reading bloggers and analysts reviews on ERP solutions sometimes makes me cringe. Often, these writers are US-based, and they seem to think that their experiences in the ERP industry, especially in the mid-market, can be extrapolated elsewhere in the world. I beg to differ.
An example of regional differences comes from a report by the Panorama Consulting Group, which shows that US and European mid-market companies are comfortable with an implementation period for, and an investment on an ERP system which, from this South African’s view, is extravagant.
One of the reasons that mid-market ERP vendors are regionally strong is because, for the mid-market, relevant customer references and industry knowledge in their specific area is important. A recent set of articles about Mistakes Sales People Make points out that creating credibility and lowering the customer’s view of your riskiness is a critical issue.
Another reason why I believe the ERP mid-market is regionalised is because of the markets and the requirements are different. It’s no point a big US software maker talking about their US or European sites to a South African or Indian business, because the worlds and the cultures are so different. This is where I think the ERP vendors should be taking lessons from the consumer packaged goods (CPG) companies.
The CPG companies often have the same product sold in different countries, but the branding, packaging and marketing is specific for those countries. A CPG company in a region will have its own marketing program – from research through to campaign – which could be quite different to the same company in another region. I have not seen that approach adopted yet by any ERP company – where the marketing plan and decision-making is centralised in one developed country.
In my un-researched opinion, based on personal information, these might be some major regional ERP dominances:
UK - Dynamics GP, Sage
Northern and Eastern Europe – Dynamics NAV
Sub-Saharan Africa – SYSPRO, Sage
Middle East – Oracle
I am not familiar with India, Asia or Australia, but would be interested to hear what others think are the situations for those regions.
So, my recommendation to:
- the northern analyst organisations – by all means keep up what you are doing but be more explicit about regional differences,
- the major ERP vendors – break out of your centralised marketing mentality and create teams in separate countries/regions who are allowed their own discretion on what to market, how to package (modularise) it, and how to sell and price it.
From an SA online news article, SAP claims that its Kick Start and Go solution for SMEs can be implemented in two days; and its Fast Start pre-configured CRM, financials and hardware solution in 8 weeks.
Comment from a local SAP consultant is that it takes 2 days to configure SAP – so how does Kick Start and Go work? We are implementing at a large manufacturing company (target segment for the Fast Start program) and the complexity of an organisation like that makes an 8 week timetable look totally unrealistic.
I assume that SAP comes in and tells the company how its financials will be structured and how its processes will operate in future.
Two recent blogs by Michael Krigsman discusses how high IT project failure rates are, and some of the key reasons.
I am friends with a number of professional engineers – civil, mechanical and electrical – and I don’t believe they would dare to operate if the failure rates of their projects was anywhere near as high.
Michael identifies issues relating to lack of skills, knowledge and competency as the key factors leading to failure. Skills, knowledge and competency are what training and education programs are supposed to develop. People go to university to acquire skills and knowledge. But for professionals like doctors (my wife being one) and engineers, a university degree only starts the process. The engineering companies I know expect to train young engineers for several years before they are ready to be let loose.
But when it comes to IT, customers often think they have the in-house capacity to for projects. I think many people also look at software like Microsoft Office and think that implementing and using software is easy.
Many years ago in South Africa, there was a debate in the Computer Society about whether IT should become a profession. At the time, the proposal was defeated. After reading Michael’s blog, I am wondering whether we should re-look at the proposal. The next step would be where do you start, and would IT vendors, consultants and users see this as beneficial?
In engineering, aircraft engineers must be a relatively recent addition as a profession. So how did they go from being a bunch of techies to having their own professional status?
BTW, I suspect that the information Michael uses comes from projects in the more well-resourced developed economies, so I wonder how the projects perform for those of us in developing countries?