Software driven change.... it must have been a software salesman told you that!!

How does that work? When the MBAs fresh out of business school proudly draw the 5-Forces model they put on it things like Customers, Market, Competition, Regulation as drivers for change.

But at a meeting with a major multi-national today they described “software driven change”. Whilst this is counter-intuitive - surely change drives software not the reverse -
it sounds horribly familiar.

The client decided to outsource its SAP applications management and the global processes that it supports, because it was hopelessly inefficient. They had every flavour and version of SAP, and lots of heavy and expensive customisations to meet local requirements. The way they were managing SAP had become hugely expensive and a significant barrier to business transformation.

They outsourced to a major consulting/outsourcing firm on the premise that their project management methodology and SAP expertise would allow them to upgrade to a common SAP platform supporting common global processes, thereby reducing costs and making the business more agile. So far, so good...

But the change process has been technology-driven. The client is using the re-implementation of SAP as a battering ram for change and the adoption of global processes.

Six months into the project, the teams from the consulting/outsourcing firm are meeting stiff resistance from local business units who are rejecting software-driven change and insisting that their local requirements give them an opt-out and the right to a customised implementation.

So is the client on the way to repeating the mistakes of its earlier SAP implementation with heavy local customisation and associated costs (as well as a transformation programme that will slow to snail's pace)?

How could they have done it differently using a process-focused approach?

They could be using live high-level workshops as a means to stimulate fresh thinking, new ideas and to create the required consensus on the core global processes.

They could be talking with the business unit people about their business processes in an easy-to-understand way, instead of asking them to approve SAP system diagrams and technospeak.

They could be engaging business people in change instead of confronting them.

They could seamlessly reconcile the tension between maximising the use of global processes while at the same time allowing for essential local variations.

They could be integrating process with documents - they are significantly out of step, which makes process seem even more airy-fairy and time-wasting to their business unit customers.

The bottom line is:

Without the user engagement that this approach can create - and without its efficient integration of business process with documents, metrics, roles and competences – the client is going to spend zillions and years moving only very slightly forward from where it was, missing a huge opportunity to embrace sustainable transformation.