People, Process & Tools: that is the triad that I’ve become accustomed to over my past seven years managing I/T implementations. People are most important, then comes Process, and finally Tools (or Technology, if you prefer). And I’ve used that illustration to paint the picture to others that it’s not all about the Tool. When implementations fail, rarely is it solely because of the Tool.
However, I would like to offer up a slightly different Triad.
In my experience, there is another critical element missing in this illustration: Data. In fact, I would suggest that you can make just about any Tool work as long as you have the rest of the equation—People, Process, and Data—sorted out. Now, a lot of people out there will argue with me on that statement but let me point out one big data point: Up until 2014, The Dow Chemical Company was running its entire enterprise on a Tool developed in the 1980’s…and it worked! Why? Because over the previous two decades, the People, Process and Data were all sorted out. If The Dow Chemical Company could run a $60B enterprise on a 30-year old tool, then the tool cannot be the cause of woe. I have even seen examples of those IBM mainframe systems still in use today at other multi-billion dollar corporations. How can that be? The answer is simple; People know exactly how to use it, the Processes have not changed, and the Data is good.
What do we mean by Data?
What I mean by Data (especially as it relates to business planning systems) is Master Data and Transactional Data. Master Data includes Product and Customer and all of their associated attributes and characteristics. Is there a sound strategy for how this data is going to be created, maintained, and syndicated to all Tools? Transactional Data includes Net Revenue, Price and Volume. Is there alignment on which book of accounts this data will be sourced? Who owns this data? I’ve seen several implementations where the data strategy was not a critical element of the project, and those projects struggled. Not immediately, but usually three months to two years after the initial implementation.
Data is a common planning system challenge. I’m always amazed at how software providers promote their data integration services as being “plug-and-play.” In my opinion, there is no true plug-and-play solution for data integration. It’s complex. The key to successful data integration is having a sound strategy going in.
Let me share an anecdote to better illustrate this point. An S&OP system had been implemented at my company and had lots of issues. The symptoms of this system were data discrepancies and data latency, all while having two full-time resources maintaining the data. Demand couldn’t be entered because codes did not exist. Incorrect attribute data generated faulty results. Volumes data did not match with other systems. All of this resulted in a system that users did not trust.
In diagnosing the issue, a major cause was a strategy that included an MS Access middleware to translate and prepare data for loading into the system. A lot of the data was manually edited within this middleware, which created a whole slew of issues. As we prepared for the next system, we made a very simple decision on our data strategy: syndicate data. Do everything to prevent replicating data and use it from the source systems.
Be sure and map out your journey
What did this entail? First, data mapping was done to connect the source and target systems. We needed a map before heading out on our journey. In our implementation, over a hundred attributes were needed. For each attribute, we took the time to identify the source system(s), the maintenance roles, and how the attribute would be transformed and loaded. I won’t sugar coat this exercise; it was tedious. But in the end, we had a fantastic map and awareness of any data gaps.
Second, we had to acknowledge that data interfaces would become more complicated. When syndicating data, the interface has to do the heavy lifting. Additional resources were deployed in the interface areas to address.
Finally, change management was necessary, as end users would address data issues differently. Rather than send an email to the system admin, they would need to reach out to the data owners directly. The data maps previously generated were used to communicate to the end users who the data owners were.
The payout was better, up-to-date, consistent data in the system that users could trust.
So, make sure and keep Data as a fundamental need for any planning system.