The non-Euclidian horror has emerged from the depths of the company IT systems. Staring too long at the non-Euclidean horror may result in a permanent loss of sanity.
Problem: over the years, the company has set up many different systems. They now have an ERP, a WMS (warehouse management system), a CRM (customer relationship management), a BI cube (business intelligence), an e-commerce platform, etc. In between the implementations of all these systems, in-house components have also been developed to perform more specialized tasks. The complexity of the IT landscape has sharply increased over the years, as every single additional app needs to communicate with every other app already implemented by the company. Every division is impacted, but supply chain, sitting between sales, purchasing, finance and production, is affected the most. Changes are sluggish, and nearly all supply chain initiatives are failing to meet their deadlines. Nobody really understand any more what is going on within the company systems.
Anecdotal evidence: Physically moving from one warehouse to another one nearby could be done in two weeks. However, as far software goes, the actual IT migration necessary for integrating the new warehouse is going to take more than 6 months.
Context: a long time ago, each company division had started off with their own software solution. Integration was poor, and finally it was decided that an ERP system would be set up to “rule them all”. The ERP system was implemented, but it didn’t manage to keep up with the rapid pace of change in the software industry. As far as supply chain was concerned, a WMS (warehouse management system) was set up to improve productivity and reliability; and this did work out relatively well. Other divisions made similar moves by setting up their own domain-specific apps that were a better fit than the original ERP. However, business is changing faster than ever, and today, having smarter supply chain operations involves a myriad of interactions between all these different apps.
Supposed solution: Every time a new challenge arises, IT systems are adjusted at a minimal level to deliver the expected results. For supply chain purposes, an ad-hoc integration with the CRM has been set up to collect inputs from the sales team, and another ad-hoc integration has been set up with the BI cube because it’s the only way to have figures that are consistent with the ones used by finance. Logistic services and suppliers have required quite a few integrations of their own. As a result, the supply chain team has learned that the bigger the IT change, the more likely the initiative will slip out of budget and fail to meet the deadlines. Hence, narrow incremental changes are now strongly favored over any substantial evolutions.
Resulting context: The subway map of Tokyo looks simple when compared to the representation of the different IT interactions within the business. There are hundreds of subtle dependencies between all the systems within the company. The big picture of the IT landscape is very fuzzy at best. For the supply chain, there is a constant struggle to get access to all the relevant information such as new products, promotions, purchase orders that are “almost” finalized, history of stock levels and stock-outs, etc. Each small revision of the supply chain operations, where a process is to be improved by taking advantage of an extra piece of information, seems to drag on forever. Data inputs are inconsistent, systems keep failing and there are exceptions that need to be manually managed all over the place.
Seductive forces: The company has learned the hard way that the bigger the IT initiative, the more likely the initiative will fail. Thus, all practices gradually evolved towards smaller and more focused initiatives, which are easier to roll out while keeping budget and timelines under control. The company managed to achieve early successes precisely through such small-scale initiatives, with positive outcomes being obtained on tiny budgets.
Why this leads to failure: Each incremental change increases the cost and the complexity of all further changes. Since the company practices favor changes that are as small and as incremental as possible, there is a constant lack of concern about the “bigger picture”. In a way, this is a case of the “tragedy of the commons”, where the individual interests (the separate divisions of the company) are not aligned with the common interests of the company as a whole. The problem is made more acute because the negative effects are typically observed only a long time after the change takes place. While each change appears to be profitable, the company keeps accumulating “technical debt”, turning short-term profits into losses over time.
Positive patterns to address the problem: Fundamentally, implementing incremental changes is a reasonable approach to take. However, each change should be executed in such a way that every subsequent change becomes cheaper or simpler; the two properties being highly correlated in practice. This implies that every initiative needs to pay the tax of the commons where not only the primary goal of the initiative has to be fulfilled, but also the secondary goal, which consists of making things smoother for the changes to come.
Example: Contoso is a national e-commerce leader in Germany in a specific B2C segment. The company started operating in the early 2000s, developing a bespoke front-end at the time; the front-end being the “app” that allows people to buy online. In the company’s early years, nearly all its IT needs were solved through an ever-growing front-end. However, managing suppliers and purchase orders was simply too much for this bespoke app. Consequently, Contoso decided to invest in a mid-market ERP and to offload all the back-office processes to this ERP system, including the bulk of the nascent supply chain practices. For a while, stock levels were managed both within the front-end and within the ERP, but since this proved to be messy, Contoso ultimately managed to successfully strip the front-end from its overreaching responsibilities.
The ERP fulfilled its function initially, but as the company keep growing, and despite the best efforts of the technical team in charge of the ERP developments, the ERP wasn’t keeping up with all the requirements of the business. Reporting was insufficient, and finance decided to set up its own BI (Business Intelligence) portal, with most other divisions rolling out similar apps of their own. Supply chain launched a series of EDI integrations to send their purchase orders to their suppliers, but piping everything into the ERP was feeling increasingly frustrating because the ERP could simply not capture all the subtleties of Contoso’s supply chain operations.
As Contoso has grown to be a national leader, it now had access to a wide range of sourcing options. The local German distributors that had initially played a key part in the early success of Contoso were now proving to be increasingly expensive as Contoso’s competitors were driving the prices down. The days when customers were willing to pay “extra” for online purchases were long gone. As a result, Contoso had to gradually integrate alternative sourcing options into their workflow, typically using the services of more distant, sometime overseas suppliers. After a few months of unsuccessful struggle trying to cram the multi-sourcing logic into their ERP, the supply chain team decided it was time to set up their own system, separate from the ERP. The supply chain team chose to go for an advanced sourcing app, but the set-up took a lot longer than expected. The new solution wasn’t at fault, it was the integration with the ERP which led to a series of unexpected difficulties. For example, three months after the launch of the new solution, the supply chain teams realized that the shipping delays displayed on the customer website were not managed by the ERP but still by the front-end. Therefore, these “displayed shipping delays” were flowing from the front-end towards the ERP, but nothing had been done to support the reverse. As a result, injecting revised shipping delays - dynamically updated based on the supplier selected to provide the product – into the ERP had no impact on the figures displayed on the website. The ERP had already grown into a fairly complex set-up, and as Contoso’s IT team was feeling much more comfortable with the front-end which had been developed internally, the supply chain and the IT teams jointly decided that the sourcing solution would inject the revised shipping delays directly into the front-end.
The approach proved somewhat messy, and while it was originally planned to deploy the sourcing app within 3 months, it took a whole 9 months to get it to go “live”. Yet, it was worth the investment, as multi-sourcing resulted in lowering the average purchase prices by 15%, which was a considerable boost for the business.
Fast forward to the present day. Contoso’s purchasing team, now separate from the supply chain division, has negotiated favorable, but unfortunately complex agreements with its largest suppliers. For example, the supplier might return substantial amounts of money at the end of each quarter if certain quotas are met, typically involving a combination of sales volumes in euros and quantities of units purchased. 12 months ago, the supply chain team has launched an initiative to take such agreements into account when selecting the most profitable supplier for each purchase order. However, the initiative is largely stalled. The supplier’s contractual terms are located in the purchasing system, the finance elements can only be found in the BI systems, while some other supplier-related information remains in the front-end, and no internal upgrade has ever been completed to piece the different parts of this jigsaw together. The amount of change actually needed is small, but it seems that every single system within the company is getting involved. Morale is low, and people are getting increasingly focused on their next assignment, as there is no positive outcome in sight.