Why are ERP consultants needed?

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.

Mid-market ERP is regional

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.

Is SAP implementation time realistic?

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.

Does high project failure require "professionalising" IT?

Two recent blogs by Michael Krigsman discusses how high IT project failure rates are, and some of the key reasons.

Study: 68 percent of IT projects fail
Requirements and failure: Interview with CA’s SVP of IT Governance

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?

Another story about complex systems

Following from an earlier blog, yet another story of a big complex system that has been delayed beyond its plan – SAP Business By Design delayed by 18 months.

ERP pricing

Vinnie is fond of asking why ERP vendors, and especially implementers, don’t lower their pricing. Take a recent post, SAP’s Egosystem (nice play on words), where he asked

Why is systems integration still so expensive after 35,000 SAP customers and countless upgrades?

Maybe SAP’s value is not based on price, but instead on customer intimacy or product excellence. Here I am referring to the three value disciplines advocated by Treacy and Wiersema, The Discipline of Market Leaders.

If a company wants to get ERP at a low price, they should be considering some of the open source offerings, or the low-end accounting/ERP packages. However, if a CEO wants an ERP system that he knows will work, and can work for his type of company, perhaps he should consider those vendors for whom price is not the driving value.

Design and implementation of complex systems mis-understood

Having worked on a number of ERP projects, and seeing how they so often seem to run over time and over budget, I was heartened by some news:

• - the late delivery of the Boeing 787 Dreamliner
• - the problems one of our customers has in delivering their designs and builds on time
• - stories from engineer friends of mine who are struggling to keep projects on track and on time

The common thread to me is that these are all projects involving the design and implementation of complex systems, much like ERP projects.

The more I deal with manufacturing companies making complex products, the more I begin to think that sponsors and managers have unrealistic expectations about projects before they start. There also seems to be a general human problem that prevents people from grasping just how complex a system will become, especially where there are multiple points of integration.

Perhaps to be fair, Michael Krigsman’s IT Project Failures should also cover project failures in other industries. I’m sure the list would be just as good as the top 10 IT failures.

Can ERP implementations be fixed-price?

A couple of bloggers experienced with ERP projects are making the claim that ERP implementations could be done as a fixed price product:

Roberto Galoppini’s Commercial Open Source Software
Projectfailures.com

I’m sorry guys but I must disagree.

The example used is that of the US hospital group that has ‘productised’ (awful word, by the way) some of its heart surgery procedures. The extrapolation being that if it can be done for heart surgery, why not ERP implementations.

While they are both complex procedures, one of them (heart surgery) is governed by physical rules – physics and chemistry – but the other is subject to the far more complex and vague rules of people and social interaction. It’s the same reason why sociology and economics aren’t considered sciences – because when you deal with interactions of people, things are far harder to understand and predict.

When I was one of Microsoft’s Dynamics NAV implementers, we tried very hard to push fixed price implementations with a packaged solution set called RIM (Rapid Implementation Methodology) because it was supposed to appeal to smaller companies. But once you got into a project you uncovered complexities that the customer didn’t even realise where there, and so variation orders had to be added to the fixed price. Perhaps for a basic financial system a fixed price project might suffice, but not for other areas of business; for manufacturing implementations specifically, Microsoft recommended that a fixed price project should never be quoted.

SAP’s Business One pushes fixed price implementations, but we heard from companies who have gone that route that they get a basic system which then costs them real money if they want the system to run like they need it.

The day I hear a lawyer offer fixed price court proceedings, or an accountant offer fixed price auditing, then I will consider fixed price ERP implementations.