Old Paradigms Inhibit New Decisions

I was sitting with a client this last week and we were talking about SAP’s roadmap to S/4HANA.  We were trying to align it with the client’s IT strategy and Reveal’s recommendations for their Supply Chain initiatives.  This was a lively discussion with just a little bit of tension about how they were going to effectively evaluate S/4HANA when the Supply Chain portions did not yet appear to be ready for prime time.

The part of the discussion that really resonated with me was that, as human beings and as organizations, we tend to do what we know how to do.  We can call it operating within our comfort zones or playing to our strengths.  I would submit to you that this is part of a powerful pattern that I have noticed going back 25 years to when I was starting my career in technology.  It is the existence of this pattern that has continued to stifle our collective ability to perform successful transformations (of people, systems, organizations, processes).

Hear me out – I realize that I am referring to the majority of organizations and that there is still the minority (who still amount to plenty) of organizations and humans who have been able to overcome this tendency.  If you are among the minority who have succeeded in transforming yourself or transforming your organization’s Supply Chain or have successfully jumped from one software platform to the next, then this writing probably will not resonate with you.  You will indeed be among the minority who have overcome a powerful paradigm constraint.  For the rest of you:Picture if you will, that we the reader are part of a company in its infancy.  We have multiple processes which, when operating together sell items, manufactures them and ships them – all to a happy new client base.  At some point, these processes are committed to software and we now have this software system running our business.  Well, the software system and human heavy-lifting together run our business.  Over time we learn the software system and we get better at how to get it to do what it needs to do.  We eventually reach an equilibrium with our system – humans know what humans have to do and the software does the rest.  Until we wake up one morning and realize that the software is outdated and the humans are doing the bulk of the work.  The humans are working around the system, which is hindering work, rather than making it easier.  

At Reveal, we call this a classic symptom of low Business Maturity.  So, in order to cut costs and make things run better, we have to look at implementing a new software system.  It does not matter what this software platform is, but the key point is that it is different from the platform that we currently have.

This is where it all goes wrong – we hire someone from the outside to implement our new system and we negotiate the best-fixed price that we can.  These implementers know the software really well – and they probably know a bunch of industry best practices that mostly match how we do business.  The challenge is that they do not know our business because in fairness we cannot expect an outsider to really know how we run our business.  The implementer conducts workshops with us to try and learn our business.  These workshops produce business process documentation.  This documentation becomes functional specifications and these specifications become the foundation for how this new system is going to be constructed.  The problem here is that our people only know how to tell our implementers how the new system needs to work, and what the current problems are, in the context of what they know.  They describe the problems and the wish list based on their knowledge of their current system.  Those descriptions are then taken and added to the wish list for the new system - and that’s where it all goes wrong.  Our implementer is now stuck designing a new system in the paradigm of how the old system needed to work.  This produces a myriad of problems including massive customizations, cost and schedule overruns and a system that is really tough to manage and sustain.

‍The solution to this dilemma is 2-fold:

• Recognize that there will be an issue with translation. Know that the terms and descriptions and problems that are present in the old system are indicators of priorities for a new system.  They are not necessarily things to be taken at face value.
• As an implementer, you have a duty to understand the requirements and the functionality of the new system. Then you have to perform that translation and sell it to your customer.  This part involves change management – not the kind of change management that involves mounting posters and having communication meetings, but in-the-trenches hard-nosed real-world debates with your customer about how to best design this new system.  You are changing a paradigm – this does not come easy.

From my perspective, I cannot see a more pure definition or need for change management - the need to educate and change a paradigm of thinking and singular perspective to accommodate this new system.  This is the key to success.  After all, the reason you picked a new system platform was that it matched your business needs better and was able to leap your organization forward.  Inherent to each software system is a set of rules and paradigms upon which it is designed and according to which it operates.  It is simply not logical to expect that your existing system’s rules and paradigms are going to be aligned with the new system.  It is also not logical to expect your customer to immediately know and understand how to communicate their needs to you in the context of the new system’s paradigms.

So the message here is this: Make sure you want to go to a new software system for the right reasons.  If you do, then select an implementer who you can trust to do the tough change management, know the system and guide you down the correct path.  If you need help understanding if your current SAP system can work better for you, then call Reveal.  We specialize in making your SAP Supply Chain a thing of beauty without chasing new software.