(248) 735-0648

Let’s look upstream of your Configuration Management Data Base (CMDB)/Asset repository. How does the data enter the system? Think it’s a streamlined process?  Think again.

 

Asset provisioning has always been a process IT professionals love to hate. Stories are frequently heard of six to nine-month lead times for obtaining something as pedestrian as servers. How is an organization expected to compete in the digital world with those kinds of timelines?

 

For some years, large IT organizations have been implementing “service catalogs” that formalize request management, such as requests for new IT assets or resources. Asset provisioning, as a requested process, results in a new CMDB record. Formalized service request management has helped with consolidating this type of work and understanding the overall demand for IT services, but complaints persist of IT slowness.

 

Implementing a service request process is only part of the problem. Many people do not realize that any formalized process like Asset Provisioning represents a queue.

 

Long line of diverse professional business people standing in a queue in profile isolated on white

There are certain ways in which queues behave. For example, if there are 10 people in line, and each person takes 10 minutes to serve, you will have to wait 100 minutes if you are the 11th person to join the line.

 

This may seem obvious, but things get more complicated when:

 

  • People are arriving in the line at different times
  • People’s requests take different amounts of time
  • People’s level of urgency and priority can be different (e.g. a different line for those with platinum airline status)
  • You can “open new windows” for service

 

Lean Product Development specialist Don Reinertsen believes that queues are often overlooked as a root cause of delays in product delivery, where “Product” is an IT service. Probably the biggest issue seen in IT service request processes is queue overload.

 

This is discussed in the well-known DevOps novel, The Phoenix Project. Understanding and managing work in process is a theme throughout this highly recommended book. They realize that if work must pass through a series of highly-used queues, the amount of time spent waiting in queue explodes.

 

Much of the delay seen in Asset Provisioning processes can be traced to overloaded queues; too many approvals, too few people working them. The work waits far more than it is acted upon. Customer satisfaction declines severely, and people start looking for alternatives. If the Asset team is being bypassed, your CMDB or Asset repository will suffer the consequences.

 

Do you know how your Asset process is functioning, in terms of being one more queue within your organization’s overall IT delivery operating model? Are you managing for “efficiency,” at the cost of imposing weeks or months-long delays on your customers? Enterprise IT organizations have long had a reputation for being slow. Sometimes this is blamed on bad culture, poor leadership, or even poor process.

 

But even the best Asset process will bog down if it is not understood as a queue, and in the enterprise, it’s actually a system of queues that comprise the digital operating model. Providing capacity for the digital product team is a critical task, and understanding queuing theory will help the Asset team support an organization’s value journey. Understanding the process in this way will also help to deploy automation in a valuable and intelligent manner. Ultimately, this will result in a well-regarded Asset process, and improved process quality will lead to improved CMDB and Asset data quality. This is just one aspect of having accurate, quality data within the CMDB. The value of other downstream operational benefits can be found in this Blazent whitepaper on the top 5 costs associated with poor data quality.

 

Next: What happens when queues are unmanaged? Your Cost of Delay goes up. What’s Cost of Delay? Stay tuned.

 

For an introductory discussion of these issues in the context of a great novel, read The Phoenix Project by Gene Kim (see especially chapter 23). For a deeper dive, see Don Reinertsen’s Principles of Product Development Flow.