Reflections from the trenches - Implementing an ERP system today
I started my life as a business consultant in the heady days of large scale ERP roll-outs. K-rated SAP consultants were the royalty of IT project environments and everywhere large implementations were being planned and implemented. The project leaders were tired and short fused, the sponsors had big dreams and the project budgets often dwarfed the GDP numbers of a few small countries. Big programmes were specified and many contractors and consultants worked in complex work streams. Fortunes were made and reputations were lost.
There is a legend that very few internal implementation leaders of big ERP programmes survived the fruits of their labour and many senior executives faced very hard questions about the return on the fortunes they had spent.
It was a waterfall world - where projects were defined in great detail & then "project managed" and - importantly "change managed" to the holy grail of the "go-live" moment.
Reflecting now on the bravery and boldness of this era it becomes obvious just how much has changed since then. Agile & continuous integration are words mentioned in every IT forum and new specialities like UX and CX focusing on the experience of the user and thus requiring less "change management" have become ubiquitous.
In this era of technology pervading everything traditional ERP vendors have also changed their tune and customisable - app-based interfaces are being proposed as a way of engaging users and making the systems less odious to use. SAP has embraced Design Thinking as a way of correctly ensuring that the final implementation responds to a real set of user needs and personas are created to imagine the journey of end users through the new system.
Against this backdrop I reflected on a few insights in the move from BIG ERP to BIG-small ERP; A few ideas stand out in my attempt to bank some of the learnings from the past and apply them to today's implementations of core IT renewal projects.
- Who pays for the freight?
The waterfall methodology implied that a single - fully empowered top executive or executive team would reflect on the business case for the entire project and keep funding it until the end based on a solid and stable financial payback. This expectation is often dashed as commercial realities change and the market often also imposes changes on the project, especially if it's a long one. The learning here is to differentiate between an investment in purely infrastructural terms and an investment in new functionality that can make money.
In the first case there is no expectation of commercial gain, just risk management and potentially some cost saving (this is a dangerous basis for a business case though). If the board and expo decide to renew the core technology systems of the organisation as a pure "sunk cost" to maintain the capability, then some of the core - invisible to users - features can be funded through a ring-fenced spend.
On the other hand, if the new system is expected to pay for itself in new revenue & reduced operating costs - then a totally different approach to the funding must be taken.
In commercially driven businesses the rain makers have a veto - regardless of the position taken by the board and the executive. There is an implicit deal between the executive and the folks they hold accountable for earnings - "I give you space and you deliver the profits". It is only a very naive programme manager that does not consistently take this "implicit deal" into account.
If any significant percentage of the implementation budget you have is based on enhancing profitability and offering new growth, then the commercial stakeholders needs must be put first and the realisation of real benefits - however small - must be prioritised.
The main reason why agile approaches have become so popular is that they are able to deliver incremental value to the folks who are paying for the project.
Don't let your "solid mandate" from the executive lull you into a false sense of security. Deliver often and deliver real commercial impact from day one!
2. User experience is the new change management:
In the previous decade business systems were sometimes the most sophisticated technologies that people touched. Even the clunky old SAP GUI was a lot more sophisticated than the first mobile phones and even some of the early versions of PC software.
Then the technology train sped up and it become a normal part of life to engage with highly sophisticated, customisable interfaces and technologies. Your car's dashboard probably looks like a computer, you are probably reading this article off a handheld device with a crisp screen and a powerful processor. When you buy a new laptop or tablet, or even phone - the first thing you do is to configure the display and the apps available to you in a way that suits your needs.
No one "trained" you to use Facebook, Twitter or even to trade crypto currencies online. No one had to do "change management" for you to enter all your health details and activities into your medical aid app or website to get your cover and rewards.
Technology today is how we interact with the world and we expect it to be a customisable space we can make our own.
The most pressing and most important piece of expertise you can enlist in an ERP implementation is User Experience - from a creation, governance and optimisation perspective. The better the UX the less the need for change management.
3. Empathy in Design drives buy-in:
We don't often resist our own creations. We are even less likely to reject something that has been custom designed for our needs. If we are able to elicit true user input and react with real empathy to the needs we have discerned in this way we will create a completely different dynamic around the project. People will be much more engaged and willing to help us shape the project through all the agile methods we have to do so if we show a true depth understanding of their needs.
It's important to remember that the internal "users" we engage with are making very significant investments of time and emotional and intellectual energy to help us build something great. We need to show a return on this investment by truly connecting with their needs and making sure the end product is co-created.
A design-thinking approach is a very good way of ensuring that we keep our end-users engaged and that we end up with a tool that "falls nicely to the hand" for them.
4. The big platform is under the waterline:
A core technology renewal project is often a thankless task. So much heavy infrastructure work needs to be done without any apparent benefit to the end users and sponsors appearing. So much of the reasons for rebuilding an ERP system - or launching one to start with - is about "avoiding bad things' like risk, security issues, reducing needs for bandwidth, lowering the cost of ownership and delivering a future proof environment where new functionality can be easily built.
Some of this in unavoidable - but it is a big risk. For a project to get real support and real traction quickly it needs to show visible benefit early on. In line with my comments about who funds the project - it is crucial from a change perspective to balance the "behind the scenes" work with some real visible improvement to the users - and especially the folks at the frontline making money and serving customers.
5. Change management is about people's ability to contribute.
The most intriguing debates being had at the moment about the 4th Industrial revolution centre around the interface between people and machines. "Will robots take our jobs?" "Will artificial intelligence displace human discretion?" "Which jobs are most likely to be automated?".
There is a general sense - in equal measure of trepidation and excitement about this new era of the thinking machines. As sensing capabilities allow for almost every object to "speak" to almost every other object, we no longer design "dumb" products. Chairs will tell you how long you have been seated, how often the boardroom is being used and when it's likely to break.
In this era our change initiatives need to focus squarely on how technology can increase the capabilities of people to better serve other people. Our role as change agents can no longer be to just keep everyone in line and make sure people don't resist the change, we need to become pro-active in partnering with people as to how they can do more, make better decisions and deliver more value using our technology.
Whereas in the past change management was often a debate about what you would no longer be able to to with the new system, it now needs to be about what more you can do with the new tools.
In closing the 80's feel very distant from this vantage point, there does seem to be an opportunity to do things better now. The tools, the software and interfaces have evolved. The users are far more tech-savvy than before and the pressure to build truly enabling applications is higher than ever before.
The question then becomes: "Are we as the programme leaders, project managers and change managers ready for this new world? Or will we be stuck in the trenches of the past?
