|
||||||
|
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! This is the first in - more than likely - a series of predictions we’ll be making here on SCM2.org. Prediction #1: The Death of SCM At least as we know it today. There are two viable paths forward for SCM: ERPII or SCM2. But a standalone point-solution or a suite of loosely coupled SCM point-solutions are not going to be around ten years from now. The vendor with a single point-solution is already an artifact from the past. If it hasn’t happened yet, at best it will be gobbled up by a bigger vendor in the foreseeable future, only to have its point-solution become part of a suite of loosely related peers. At worst, it may still be acquired only for its install base, or it will simply go out of business. In either of the worst case scenarios, as a customer you are stuck with an unsupported and stagnant product, or will be required to go through another expensive project. The status quo currently are the vendors that provide a suite of loosely related point-solutions. These vendors do provide a way forward after a first solution has been successfully implemented, and therefore are in general faring much better than the single solution vendors. The exceptions to this broad sweep statement are those vendors that sell a truly unique product. And these vendors will continue to do well until a more encompassing solution hits the market that covers their uniqueness, whether it be an SCM suite or a SCM2 solution. Our prediction is that the suites of SCM point-solutions will disappear over the next ten years just like the single point-solution vendors have over the last ten years, as more and more ERPII and SCM2 solutions hit the market. → → → Continued Here! There is an incredible amount to write about SCM2. In my previous article the focus was on how the future of SCM relates to the future of ERP. The latter already has an enormous amount of publications to its name, but whenever I read anything about the future of SCM it either is gobbled up inside this ERP II (and doesn’t actually get much attention within that bigger scope) or it is limited to the near future of SCM as whole, not the far future of SCM software in particular. That gap is the main reason I started this blog. That the notion of SCM2 seems to conflict with that of ERP II was something that I wanted to get out of the way before getting to the meat of SCM2 to not scare the ERP II believers away before I even got started. This article will be a first very high level overview of what I think it takes for an application to be SCM2. Let’s take a step back from the last article where I already got into some technical detail about the database behind the application, and forget about that for the time being. I will still compare SCM to ERP since the latter has evolved much further in my opinion. Where the SCM domain is currently still split in many subdomains each with its own small point-solution applications, most current ERP systems are truly one coherent system. SCM has a long way to go before it can match ERP on that front. This second posting on our new blog continues the description of where SCM stands now. It is necessary in my opinion to write these postings on the status quo before I can start with the forward-looking articles that this blog is really about. This particular posting is part 2 of the article Supply Chain Management: what is it? In the first part I delineated SCM within the enterprise application landscape at a macro level. I gave a broad definition of SCM and what is in and out of its scope in general terms, and how it is related to other enterprise domains such as ERP, CRM and MES. In this second part I intend to be more specific as to which known functional areas fall under the SCM umbrella. A warning to the casual reader: this will unfortunately involve quite a number of acronyms again. Let’s make a short journey across the supply chain starting at the demand side and work our way towards to supply side. Along the way I’ll discuss the functional areas that exist at each step. → → → Continued Here! This is a first posting on our new blog on Supply Chain Management 2. I thought it would be a good idea to first set the premise, so everyone can put the discussions on where we are heading into a shared perspective of where we are now. I think this may become a multiple posting topic, since there is just so much to say. This topic also does run the risk of running amok with acronyms and buzzwords. Given that the industry is riddled with them, there is no easy way to avoid that when describing the status quo. I can imagine that all the acronyms that are going around in the enterprise software space are confusing to many people. It gets confusing to me sometimes, and I am deeply immersed and have been for well over a decade. What is SCM? How does it relate to ERP, CRM, SRM, EPM, EAM, BI, SaaS, cloud computing, Web 2.0, sustainability? How about Value Chain Management or demand-driven supply chain? How are these different from SCM? These are just a few of the buzzwords going around. It is impossible to give a straight answer that will make everything perfectly clear, once and for all. If it were, someone would already have done it. Worse, I believe that at least a few of the buzzwords were introduced with the specific purpose to confuse matters; some of the more powerful vendors out there have in the past introduced terms for the simple purpose of hiding the fact that they lacked functionality and making the market believe that they had more, rather than less. Some of them stuck, and are here to stay to confuse an already confusing jumble of terms. In this article I will try to clarify as much as possible. I’ll take a 2-step approach. First,I’ll introduce an overly simplified approach with which you may determine for yourself where SCM fits in your systems landscape, if at all. Then I will provide more generalized background and definitions. I find that it helps to take a step backward to more general concepts that apply to any process that we want to do well, and continuously improve upon. You may already be familiar with the schematic on the left-hand side of figure 1 below:  Figure 1: Concepts landscape versus an example of a systems landscape To achieve continuous improvement of a process you need to plan it, execute the plan, measure the effects, analyze the measurements, and use the outcome of the analysis to plan better next time around. → → → Continued Here! |
||||||
|
Copyright © 2010 SCM2 - All Rights Reserved |
||||||
Recent Comments