This article is the last part of a series of articles. The first part of the article provided an introduction to why current state mapping is critical and started exploring the capabilities of an automated algorithm that can help automate aspects of current state evaluation. We continue and conclude that discussion in this second part.

Though you don’t have to publicly acknowledge it, the fact is that most current state gap identifications, when looking at functions from a strategic level, are pretty much evident when it comes to analysis. Costs, volume, flow lanes-discrepancies are not very challenging to identify. As they say, visualizing your supply chain’s flows can help you identify non-optimal flows. The gist is it is not difficult to build an “expert knowledge” repository of “non-optimal” that an algorithm can use to reconcile.

The choice of algorithm is on you (and the knowledge of your data scientists). The grasshopper optimization algorithm was an example highlighting that it can be done. Options are plenty. The key is if you can build an always-on evaluation solution, the evaluations of your end-to-end supply chain cease to be periodic.

As you can see in the high-level sketch above, there is not much complication associated with designing and implementing a solution like this. If you want, you can use the solver of any network optimization tool you may have invested in to recoup some of the investment. The most challenging part of building something like this is the business rules. Evaluation needs to happen in two areas. One is where you can evaluate optimality based on pure math. For example, does it make sense to ship from a faraway DC when a DC may exist close to the demand location? Shortest paths, lowest cost, etc.

The other area, and the more challenging aspect, is the business rules engine. You do not want this solution to list a hundred flows as non- optimal if they happen due to a business rule. After being examined and approved, these rules need to be incorporated into the business rules engine. The solution can then reconcile what it considers non-optimal with this business rules engine. In addition to that, it will also use these rules when flagging non-optimal or non- business-friendly transactions.

It should not be difficult to imagine why this business rules engine is challenging to build. And that is not because of technical challenges. The challenges will be more around people and processes. Employees in companies link the tribal knowledge in their heads to job security. Asking them to document everything is challenging. Then comes the evaluation process of what is actually an exception vs a temporary band-aid. Then, a method is established to periodically evaluate the rules in the engine. This is critical since we ask the solution to ignore non-optimal transactions that need to happen because of a business rule in the “flag list”.

Evaluating the current state of supply chains after a long duration is obsolete in a world where we love to harp on supply chain agility and resiliency. While control towers (theoretically) monitor tactical flows continuously, the same can not be said for strategic analysis. A solution like this is an imperative. It can sit within your control tower and link with your tactical and operational planning tools. You can schedule regular runs as shown above and run this analysis on one sub-function or the end-to-end supply chain. Obviously, an end-to-end analysis is always the right approach.