SCM2

In my last article, I illustrated why an SCM2 system should be one holistic solution, and touched on the modularity of such systems. In this article I will dive a little deeper into the modularity aspect. The first half will discuss why it will be modular, the second half will discuss how this modularity will need to be structured.

As I mentioned in the previous article, there are two main reasons a holistic SCM2 system will and should be modular. First, it will be modular, simply because departmental boundaries exist and each department focuses on subareas within SCM. It is usually a single department within a company that has a compelling need for a SCM solution that triggers the search for a vendor that can address that need. The point-solution vendors for that area and the SCM2 vendors that provide a module dedicated to that area will be considered for purchase. Any vendors that only have larger solutions than the problem area will typically be considered overkill and will be ignored. Hence, SCM2 will be modular due to the vendor’s requirement to survive. Second, it should be modular, to allow incremental implementations of more encompassing solutions. From the customer’s perspective it is much more difficult to get project approval for a single 2 year project that costs $800K than it is for 8 smaller projects that build upon one another and each take 3 months and cost $100k. In the former scenario all the project risk is accumulated upfront, and the return will start no sooner than 2 years. In the latter case, the risk is limited to the smaller upcoming project and each project can be fully or partially funded by the return of earlier projects. The remainder projects can even be abandoned if earlier projects fail to deliver on promise. This provides significant risk mitigation and a much reduced impact on cash flow. → → → Continued Here!