I have been in this business for 27 years and somehow never managed to do any supply chain work. So when a client asked me what I knew about the Supply Chain Operations Reference-model (SCOR1 ), developed and endorsed by the Supply-Chain Council (SCC), I had to admit “nothing.” So, being a good consultant, I set about familiarizing myself with SCOR: I did some reading, downloaded some PDFs, and attended a workshop. Admittedly, this does not make me an expert. It does not even make me particularly knowledgeable. It only makes “familiar” with SCOR. That said, I do have quite a bit of experience documenting business processes using any number of techniques and tools. Consequently, the concepts were not that difficult to comprehend.
One thing that I noticed in the SCOR 8.0 Overview Booklet2 is that the scope of SCOR is described as spanning “All customer interactions, from order entry through paid invoice.” It further states that “SCOR does not attempt to describe every business process,” which prompts me to ask “But can it?” If we think of every value stream as a supply chain, why not use SCOR to capture the related processes in a standard form? In this article I describe my approach to applying SCOR to any set of business processes across the enterprise.
Level 1 Process Definitions
The same five core management processes (i.e., Plan, Source, Make, Deliver and Return) apply to any business process.
A process comprises three components: input, transformation, output. I equate these three components to the SCOR processes Source, Make and Delivery, respectively. Considering the Claims Processing function of a healthcare payer, one value stream might be Claim-to-Benefit. The input is the claim and it is sourced from the member. The claim is processed to determine the benefit. The benefit is paid to the member, or the member’s provider, and the explanation of benefits (EOB) is delivered.
All of the processes imbedded in this value stream must be managed. The manager, therefore, must have a Plan. And we must also allow for the unlikely event that the member does not agree with the EOB and asks that the claim be reprocessed; that constitutes a Return.
Level 2 Process Categories
SCOR identifies three “types” of processes: Planning, Execution and Enable.
If we think of the Claims Processing function in terms of classic process modeling, we think of Execution: the process is triggered by the submission of a claim, the claim goes through a series of steps to “transform” the claim into an EOB and a benefit, and the EOB and benefit are delivered to the member and the member’s provider.
There are also Planning processes at play. The resources required to process claims must be planned for and managed. There are peaks based on the time of year and there are disasters that must be planned for. Planning the execution is a set of processes all their own that can not be ignored.
Finally, there are processes, like HR and IT that I refer to as “support” processes, that Enable the Execution processes. Without effective and efficient enabling processes, planning and execution become increasingly difficult and unpredictable.
Plan• P1 Plan Claims Processing• P2 Plan Claims Submission• P3 Plan Benefit Determination• P4 Plan Benefit and EOB Delivery• P5 Plan Disputed EOB
Source• S1 Source Claim from Member• S2 Source Claim from ProviderMake• M1 Determine (Make) BenefitDeliver• D1 Deliver Benefit/EOB to Member• D2 Deliver Benefit/EOB to ProviderReturn• DR1 Return Disputed EOB• SR1 Return Disputed EOB
Level 3 Process Element Information
At level 3 we get to the details: process flow, inputs and outputs, sources of inputs and destinations for outputs. This is where SCOR appears to take a more classic approach to process definition. How many steps are there to this process? What is the sequence? And how is the process measured; as I have said before, if you are not going to measure a process don’t bother documenting it.
At this level we incorporate any known best practices into the process definition as we identify a to-be state that we believe is an improvement over the current process. We would not be engaged in this exercise if we were happy with the status quo.
As we define the to-be state we identify inputs and their sources. Keep in mind that inputs are not only sourced from applications. Inputs can come from other processes, particularly from enabling processes and planning processes. They can also be the outputs from other Execution processes.
We also identify outputs and their destinations. The same logic holds true for outputs that we applied to inputs. The destination might be an application of some sort but it is likely another process. It is imperative that every process “know” what it is getting from whom and what it is delivering to whom.
Level 4 and Beyond
After level 3 we are ready for implementation. At this point each level-3 process element is broken down by classic process modeling techniques to whatever level is necessary to achieve procedural elements that take into account the many nuances of the business.
If I were to compare SCOR to UML, I would equate Level 2 to Use Case models and Collaboration diagrams, Level 3 to Use Case descriptions, and level 4 and beyond to Activity diagrams and Sequence diagrams.
Conclusion
This was my attempt to determine for myself the scalability of SCOR. To me, a supply chain is really nothing more than a process on steroids. That being the case, I should be able to scale SCOR to any process or value stream in the enterprise. Quite honestly, I don’t see any value in using one set of techniques to model my supply chain and another technique altogether to model the rest of my business processes. If I am wrong or if you disagree with anything I have written here, please feel free to email me; I will view it as a learning experience.
1 SCOR is a registered trademark in the United States and Europe2 SCOR 8.0 Overview Booklet2 © Copyright 2006 Supply-Chain Council
