From Supply Chain IT to IT Supply Chain

We are all well acquainted with the story of “the cobbler’s son,” whose father can’t keep his own children shod. Likewise, there is the saying “Physician, heal thyself,” which suggests the problems a doctor faces when he or she undertakes self-diagnosis. Then there’s the advice: “When going into a barbershop, always choose the barber with the worst haircut: He’s the one who’s been giving the other barbers their great haircuts.” And so on and so forth. In business we have our own funny stories. HR has problems with staffing and IT has problems when it seeks to automate its own services. Finance, remarkably, is immune; I’ve never heard of controllers being not able to manage their own budgets. At HP, we had the experience of “Physician heal thyself” when applying business analysis (read supply chain management) to IT processes, with some good results, and I’ll share with you the way we approached this.

Our first step was to step back from IT. Within an IT department, we at HP were quite used to well-defined processes and procedures from a technology point of view – writing and deploying software, installing and managing servers, helpdesk support, datacenter management, and so forth. With our one step back, we considered IT as a business—one using a supply chain frameworks of SCOR to characterize operations. We began to reconsider what IT people actually do. At first, considering IT as a business (being part of the internal service) seemed unnatural, but experienced Supply Chain process teams had no difficulty in creating a framework for describing IT and beginning service optimization. Here are the basic steps:

  • Consider IT as a business in a business: What are the products and services?
  • Adopt SCOR process frameworks and “IT”ize the process language, integrating IT metrics, and IT best practices into the model in addition to supply chain (and sales and so-forth) elements.
  • Model (i.e., document) the process streams, performance, and practices implemented using the framework.
  • Analyze the process performance and capability benchmarks to identify gaps and opportunities according to competitive comparisons.
  • Design new IT process streams according to changes in performance, practice, or structure.
  • Implement changes according to graded benefit/risk profiles.

When we looked at IT, we found that there were basically 10 major “product lines” we could group together according to a scan of published definitions:

  • Solution maintenance and enhancement – all the small IT changes which teams manage, usually called MRO in supply chain terms (maintenance, repair, and overhaul), including things like upgrades and breakfix repair. To us, this looked liked a build-to-stock, build-to-order supply chain.
  • Solutions development – creating customized solutions, including software and hardware – engineer to order supply chain processes.
  • Data center – provisioning and management of datacenter services – backup, monitoring, service management, escalation, and business continuity management.
  • Data storage – selection, installation, and maintenance of storage capability, whether it means shared or private storage, secure or public – all the forms.
  • Desktops – selection, installation, and maintenance of desktop processing capability. It may nor may not include office automation resources, but definitely is about the standard footprint companies must manage.
  • Help desk – From our “CCOR” framework, this was the same as post-sales support combined with SCOR returns and repair event management . It links to solutions, hardware, and networking.
  • IT asset management – return, repair, redeployment, retirement, performance measurement of hardware assets – things like printers, monitors, as well as desktops, servers, and so on.
  • System retirement – services supporting consolidation, archiving, and removal of IT solution. It most resembles “end of life” processes in supply chain and product design.
  • Voice and data networks – selection, installation, and maintenance of network capacity, including hardware like routers, and switches, and software like monitoring systems and security controls

Many sources identified chargeback management as a core IT activity along with vendor management, but we later considered these to be sub-processes (SCOR Deliver, and SCOR source) of the main 9 activities.

For several reasons, we selected desktops as a first program to see how applying IT supply chain optimization would work. First, in gaining sponsorship for the program, we had some difficulty convincing people that we can consider “IT” as a supply chain, but when we spoke of desktops they could begin to see clearly how it was a supply chain which delivered desktop processing capability. Second, we had a fair amount of existing SCOR process documentation from the HP-Compaq merger that we could re-use to simplify the program activities. Third, because of the internal spend on desktops, it was clearly an area where we could identify immediate advantages. So we got programs sponsorship for an IT Supply Chain optimization program for desktops.

Without going into the mind-numbing details (for those who are interested, using our standard SCOR techniques we ended up with 6 volumes of definition on the process), our first pass at identifying how IT looked as a business for desktops created the view illustrated in Figure 1.


Fig. 1: Desktop Provisioning Functional Areas

Fig. 1: Desktop Provisioning Functional Areas

Starting with the lower right quadrant, we were able to recast most of the desktop fulfillment activities in the SCOR Supply chain framework with some overlap in request management with CCOR and the customer chain. In the lower left hand quadrant, we looked at most of the desktop “image” or design activities in terms of product design frameworks. In fact, IT architecture management is for the most part identical to product design which was handy. In the upper left hand quadrant, we found congruence between classic market analysis, market offering, and lifecycle management (demand management and generation) and how you should plan the IT offerings. (What does the business need? What are other companies offering and managing?) Lastly, examining the upper right hand quadrant we found that most IT activities managing end-users were essentiallythe same as customer-management activities (selecting products, pricing, postsales support), which is no surprise, of course; end users are the IT customers. With this “level-1” view, we went, in turn, to identify level-2 and level-3 processes and, further, to describe 100% of IT processes as classical business. Of course, the vast majority of process, cycle time and cost were embedded in the “IT supply chain section,” where we focused on the next stage of the program, our analysis.

Based on the balanced scorecard and focus areas from our sponsors, we began to analyze the “supply chain,” and, in particular, the relationship of supply chain performance to “product design” (or desktop capability and image) and “sales” (user desktop selection and support). The “scorecard” we used was a combination of SCOR metrics, CCOR, DCOR, and MCOR metrics. Without showing internal benchmarks, this is the type of scorecard approach we took:

Fig. 2: IT SCORcard

Fig. 2: IT SCORcard

Within roughly 12 weeks, we captured our desktop deployment across three regions (HP’s Americas, EMEA, and Asia-Pacific) consisting of 6 basic supply chains. Using the frameworks, we were able to quickly and unambiguously link each process element to its contribution to the program measured goals, and create a like-for-like benchmark of high-level performance of the “desktop” supply chains. Likewise, we captured best practices for benchmarking cross-supply chain to industry standards. We identified process gaps and process waste (lean analysis), which resulted in roughly 50 opportunities, with millions of potential savings per region for optimizing the desktop deployment for cost and asset management. In SCOR terms, fairly “off-the-shelf,” but, in IT terms, well, almost unheard of. (I have only seen some basic capability around this articulated as Six-Sigma for IT.)

Lastly, we articulated the most complex change for asset optimization– a structural change of asset ownership to move from asset deployment (a configured desktop) to one of capability deployment (centrally managed desktop computing capability linked to staffing management). It was a significant change in the structure of IT delivery, but one that looks very much like an outsourced model where the provider owns the assets, and provides per-event services to the primary customer. That change was “high-risk” and complex, but had the most interesting benefits. For the other opportunities, the sponsors, using a self-funded program model, drove many programs (high-value opportunities) and proceeded at a regionper- region basis over time, with results of both significant ROI (generally 2x-6x program cost), but also significant cycle time reductions and quality improvements.

Nothing was unusual for the BPM team in this exercise; our standard, scalable methodology uses open standard frameworks and easily understood metrics. What was unusual was looking out of the box—”the business within a business.” We recommend that any time you are looking at your IT in terms of improvements, consider it as a “supply chain,” and apply supply chain re-engineering process techniques. You will be more than pleased at the result.


This entry was posted in IT and tagged , , , , , on by .
Joseph Francis

About Joseph Francis

Joseph Francis is a former Managing Director of PCG with over 20 years of experience in Supply Chain and IT Management. He served as Executive Director of Supply Chain Council and is co-designer of OpenReference's emerging global standard in supply chain strategic business management, and recognized worldwide as an expert in supply chain operations management.