CEOs’ misunderstandings about ERPs
Updated: May 21, 2020
No one wants to buy an ERP just for its own sake. Rightly so. Just like a helicopter in outer space, it’s irrelevant to have corporate software that’s unsuitable for its environment. What management WANT is change and improvement in a company. For this change purpose, software should facilitate. Buying an ERP first is the tail wagging the dog.
In pursuit of change, CEOs know well that it is very easy to get misguided about ERPs. Without spending years around corporate software installations, one can easily be misled by simplifications. Promotional efforts for ERPs talk about increased efficiency and modernisation. These might be very desirable but they describe only a minority of the factors in company change!
In many cases, companies start a big IT project in the hope that the ERP will somehow automatically solve all sorts of problems within the company. However, a stupendous percentage of unsuccessful IT projects suggest otherwise.
If you listen carefully to top managers' IT failure stories, they often follow a definite pattern. They illustrate a typical decision process along these lines:
1) Management were unhappy about aspects of the company. They sought change. 2) Suggestions were made that a new corporate software system could help. 3) Since software is categorised as IT, the project went to the IT department or some IT-savvy personnel in management. 4) Quotes were collected, a budget set aside, and the software system was ordered. 5) The IT project was tracked with occasional project progress-percentage reports. 6) Finally there came a point, way after the deadline, possibly over-budget, when employees around the company got so unhappy that the project had to be cancelled or stopped before full completion.
This pattern of sad stories is no laughing matter, since it testifies to loads of wasted resources and plenty of grey hair all round.
Change success pattern
By comparison, the stories of successful ERP-related projects also show a distinct pattern. It has much the same beginning, but the “paths” then diverge.
1) Management were unhappy about aspects of the company. They sought change. 2) Suggestions were made that a new corporate software system could help. 3) The company reform being the central focus, a software house or system was selected to provide SUPPORT of the reform as a SUB-project. 4) A budget was set aside to implement the reform, of which the IT project was a substantial but not an overwhelming part. 5) The team responsible for the reform included key decision-makers from affected areas, also often including the CEO. 6) Change Management needs were acknowledged and included in planning. 7) Here too, sadly, deadlines were often missed, budgets possibly over-ran, and the final picture of software and company was somewhat different from the original vision. 8) HOWEVER, because the reform was successful and the company was in a better state, no one looked back.
The key difference, it seems, was how the project was perceived by top management. The first group treated it as a stand-alone IT project. The second group looked at it as a BUSINESS CHANGE PROJECT with some IT involved. So even if, in some cases, the supporting software house proved inadequate, that was only a setback which did not bring the whole project down.
Perceiving the complete change
Companies can still be highly successful in spite of IT failures. Those companies and change-succeeding companies may both have fine CEOs who attend well to their diverse responsibilities.
However, looking at CEOs’ essential responsibilities, two sets can also be identified. Both groups will have -
- Identified the goals of the organisation - Convened senior managers with specialist skills in different departments - Set budgets for the project - Controlled project reviews
Only the “succeeder” group extended top management roles to the project by having -
- Worked with managers to create the change strategy - Identified non-IT challenges for the project - Paid special care to how changing conditions may affect the business - Monitored and controlled staff engagement and kept clear lines of regular communication - Worked alongside technology teams to introduce new technology
The main difference was not the abilities of CEOs or how tech-savvy they were. The key to success, it seems, was the way they perceived the project as a complete corporate reform and applied their skills, knowledge and experience accordingly.
There’s also a useful insight by looking at a three-layered pyramid of decision-making - strategic, tactical and operational layers. The strategic level sets out the vision, the goal and the main strategy. At the tactical layer it’s broken down into parts treated as individual sub-projects supporting the whole. Then operationally, reality meets theory - ideas are tested in real-life scenarios.
Because all interlocking details of a whole business change project are overwhelming, breaking it down to manageable parts does enable individuals to cope. People focus on their particular, complementary roles in the change project. Strategists oversee tacticians who themselves oversee the operational personnel. This can ensure that there are no misunderstandings and help and guidance are available where needed.
This diagram shows the layers for a hypothetical corporate reform, where four departments are affected. The CEO would perhaps spend 100 hours in strategic meetings and monitoring tactical and sometimes operational work. The four departments’ key decision-makers might each spend 100 hours in meetings with the CEO and operational staff, plus monitoring operational work. Operational key users could each spend 100 hours understanding what is expected of them, communicating details with the software house and testing system functionality against real-life requirements.
Note: the hours needed for each individual can greatly vary depending on many factors, but it shows the need to spread the work to allow specialisation and to avoid serious bottlenecks and loss of focus.
Business changes supported by corporate software are usually very complex and require the three layers. Ideally, the main decision-maker is involved with the strategic level. Able and motivated key personnel should be responsible for tactical segmentation. At the operational level, key users should provide the detailed descriptions for the software house and do the testing of main functionality.
Key responsibilities at Strategy, Tactics and Operations Levels
- Vision - business aspects to be improved - Extent of change - Business-wide workflows - Project’s guiding principles - Monitoring departmental plans and execution
- Departmental workflows supporting business-wide workflows - Delegating tasks to the Operations Level - Segmentation and sharing of vision with Operations Level - Monitoring operational plans and execution
- Explaining Use Cases to software house - Incorporating new procedures into daily work - Testing functionality of the system
Note: business changes which include installing a new ERP might require thousands of hours. If not apportioned well, overwhelming pressures can jeopardise success, so everybody should focus on their particular layers. As work spreads out downwards, it is important that the CEO does not get drawn into the operational layer too much.
As a sidebar, let’s add that different management styles are also worth considering. People who can be caricatured as “control freaks” do want to be closely involved with everything that’s happening! On the other hand, “pass it on” delegators want other people to do jobs for them. With far-reaching business changes, both those extreme ends of the spectrum come up short. If you try to control everything, you won’t cope, since the extent of change is just too big. If you want to delegate everything, the project will not have an overseer’s keen eyes.
Companies’ change agendas must now also cope with Covid-19’s continuing risks and aftermath. In doing so, some may have to introduce digital solutions quickly, adapting their organisations to new operating models. This further challenge magnifies the risks and rewards of company change.
Well-orchestrated strategy, tactics and operational planning can never have been more important.
ERP software is best understood as ONE SECTION of the orchestra, never to be mistaken as either the music’s composer or the whole band of musicians!
Mike Harsanyi woodpeckersoftware.co.uk