Business Process Management – If You Have a Hammer

As a trainer and advocate of standard process languages and standards for metrics I frequently talk to companies that don’t do classic manufacturing; services providers like banks, insurance companies, software companies, etc. Their observation is that they like the value of the standard reference models  (SCOR¹, CCOR and DCOR) but they are too manufacturing oriented: “We buy and sell DIY hardware and tools, we don’t make them” and “we provide banking services, we don’t make or ship money”. The question I would like to address here is whether standard reference models can be deployed in non-manufacturing companies.

It was Abraham Maslow who said that when you have a hammer, you treat everything like a nail. My hammer is the SCOR language which I normally use to describe supply chain processes. With this hammer in hand I find that many processes appear to be some form of supply chain process. An organization or function performs supply chain processes if it delivers some type of goods or services. The problem I found is that the language may not match. Let’s take IT as an example. Disregarding who performs your IT processes, you will recognize the following activities:

1. Buying and receiving hardware from vendors;
2. Installing company specific software;
3. Delivering the hardware to the user;
4. Performing periodic upgrades and maintenance.

In the standard language I use to describe supply chain processes the list above would be: 1 = Source, 2 = Make, 3 = Deliver and 4 = Return. This of course is a very straight forward example as this truly is a supply chain. Let’s look at releasing code (i.e. updating software) in your ERP system as this seems less of a supply chain process. My team actually did a project with the SAP support organization of a large corporation and found the similarities stunning. This so called release management can be described using standard supply chain processes. Let me start with describing the steps involved in this IT process.

1. Periodically IT receives updates from the ERP vendor. These may be functionality upgrades, bug-fixes or security patches (or a combination of these);
2. Upon receipt these are evaluated (importance, relevance, etc) and classified;
3. For some types of updates functionality testing maybe performed to ensure the new code will support business and technology requirements. This type of testing is referred to as Unit Testing;
4. The code is archived until needed.

These activities are very similar to the Source processes in SCOR. The source processes address the receipt of goods or services, validating them and putting them away until needed.

1. IT Management and the user community periodically review what new functionality needs to be and can be released.
2. IT work is prioritized and plans are published what functionality or updates will be released when (these are know as ‘release waves’)

To supply chain people this smells like planning (or Plan in SCOR) processes. In supply chain we call this delivery planning (or Plan Deliver in SCOR). This process interacts directly with the actual wave management activities listed below.

1. For each new functionality request a ‘ticket’ is created. Tickets are used to describe and track the status of these requests. Similarly a ticket is created for security updates and bug-fixes (if not already identified as functionality requests).
2. Tickets are validated, consolidated and assigned to a future release wave.
3. The waves consist of two stages, first a ‘test environment’ is created. This normally is a copy of the ‘production² environment’. The code for each ticket in the wave is collected and copied to the test environment. This testing is referred to as integration testing.
4. Secondly, the code is ‘transported’ to the production environment. At this point the user community is requested to test the functionality end sign off on the released code. This testing is referred to as User Acceptance testing (or ‘golden transactions’).
5. Upon completion of the user acceptance testing the related tickets will be closed.

These activities are very similar to order management and delivery processes in supply chain. In SCOR these are grouped in the Deliver process. We describe the steps: Order entry and validation (1&2), order scheduling (2), order picking and staging (3), packaging, loading and shipping (4), and receiving and validating the shipment (4&5).

You may notice from this comparison that the processes appear to be similar but the language is different. For example the concept of a customer order in the supply chain is called a ticket in the IT supply chain. A pick wave is called a release wave. Lines of code in the IT supply chain are stored until final delivery, just like materials and goods are stored until use or delivery. When you have a hammer…

A comparison of the metrics used in release management and SCOR resulted in the same findings:

The release management metrics above were reported monthly to IT management and business groups. At the time no release management specific cost were reported, but the release management team recognized the need.

On our project we initially got some resistance from the IT organizations as they over-amplified the non-IT language used in SCOR:  “We don’t  build trucks and ship goods, we transport code over to the production box”. This is the same problem other non-manufacturing companies run into when they first explore SCOR. “We are a retail business, we don’t manufacture”. But once we sat down and explained the meaning of each process step and created a translation, IT easily and enthusiastically embraced the ITSCOR model. They now have the tools to monitor the performance of their IT supply chain and identify corrective actions when needed.

Todays takeaways? Yes, the standard reference models SCOR, DCOR and CCOR can be deployed in non-manufacturing companies, but some ‘translation’ maybe required. Create your own version of the SCOR framework by changing the words, not the structure. Don’t get stuck on the language, if your line of business or organization calls an order a ticket then change the wording in the standard language to reflect that.  Don’t forget your metrics; this equally applies to metrics. And like always, don’t take my word for it; prove it to yourself in practice.

¹) SCOR, DCOR and CCOR are trademarks of the supply-chain council.²) Test and production environments refer to versions of the software running for different purposes. The production environment is where day-to-day activities are recorded. To prevent disturbance of the day-to-day operations of a company testing generally is performed on a separate server or instance of the software.