Recently, I've been delivering workshops focused on software-defined infrastructure and IT automation solutions. I'm finding clients to be excited and eager to begin providing IT offerings through self-service catalogs: desktops, servers, databases, web servers, email, storage, backup and recovery, etc. Beyond traditional IT offerings, innovation and imagination are leading to the simplified delivery of complex business offerings such as On-Boarding-as-a-Service, Audit-as-a-Service, Disaster Recovery-as-a-Service, and Dev/Test-as-a-Service (PaaS+).
Exciting times for sure! But it's easy to get distracted by all the shiny new technologies offered by cloud automation vendors. We tend to forget that the most challenging (yet most valuable) assets within IT are the people and processes, not the technologies. It's easy (relatively) to automate the heck out of every manual step that exists today and declare victory, but that's akin to "paving cowpaths."
Next thing you know, you've built an expensive super-highway and bridge (to nowhere?) over a meandering dirt path. Yes, it's a somewhat smoother ride but is it really faster, less complex, and more efficient? Does it provide more value than before? In most cases, clients that simply automate their manual provisioning processes discover they've received little value at a big expense.
So, before you start automating every manual process & decision point within an IT service, take time to reexamine how things are done today. Maybe paving the cowpath is the right thing to do, but more often than not, it's better to consider alternatives to today's processing. How should you go about examining your service provisioning processes? You could use a fancy framework to assess existing processes but I prefer speed and simplicity. To me, reinventing how you provision IT services boils down to examining the process steps (process), decision points, and actions required to deliver services. (This goes for "Day 2" activities as well; such as requesting increased capacity for an existing service.)
In order to understand if a process is needed and valuable, you must asses it (measure it) to determine it's necessity and value. Once you understand the need and "cost" of a process, you can ask questions such as:
- Can/Should we automate the process?
- Is there's a better way to execute the process? (better relative to the process features listed in next section)
- Can the process be re-sequenced within the broader provisioning of the service so that it's more efficient?
- Do we still need this process?
- Should we even offer this service? (rationalization)
When assessing each process within the provisioning of an IT service, I look at the value of five process features (starting from top right of picture):
1. Duration: How long does it take for this process to complete? For example, does a request for increased email storage sit in a manager's inbox for 1 week?
2. Transparency: Is the process visible to all those concerned? If I submitted the request for a new server, can I easily know the status of the request? It the process being logged? Can we audit the execution of process for accountability?
3. Ease of Use: Is the process easy to execute? Can it be performed by an organization and not a specific person? It's hard to believe how often I hear a client say, "Only Jane or John can do that." Tough luck if Jane & John are on leave.
4. Cost: What does this process cost to execute. Cost is of course crucial because it gets calculated into the cost/price of the service offered. Cost in a process is typically labor but can come from other sources such as office materials or shipping costs.
5. Governance and Security: This may apply more towards decision points within the provisioning of a service but often times, there's an over-elaborate process of notifications, sign-offs, and justification. For instance, "write a justification as to why you need an extra 100 GB of storage for you Wiki-Server."
Fairly simple, not perfect. For instance, you may feel it's not enough to measure Duration alone, we need to break it out by Actual Working Time and Wait Time. Fine by me but I prefer to keep it simple. Besides, the impact of Actual Working Time should be reflected in the Cost feature of a process. And, we may revisit process Duration if it takes longer than acceptable. At that point, we may learn that Actual Working Time is a problem to be addressed.
I measure and score each process feature using a simple green, yellow, or red indicator:
- If the features of a process are all green (or mostly green), I tend to leave the process as-is and automate if possible.
- If the features of a process are all red (or mostly red), I try to fix the process or find a better alternative process to automate. Better yet, if possible, I remove the offending process from provisioning.
- And then you have everything in between; the "yellowish" process. Maybe it's all yellow features, maybe some green and some red. Whatever the combined rating, it's unclear as to how necessary and effective this process is within the provisioning of an IT service. To me, this is a judgement call for the IT organization to make. Perhaps the process is very expense but the ease at which it is executed is great. The organization decides to keep the process because ease of use counts the most. These are the tradeoffs to consider. In some cases, just automating the process turns the "red" features to "green" and that's enough to decide to keep the existing process for automation.
Again, simple. But I think it's a great way to venture into automating IT services, especially the provisioning of services to end-users. Certainly there are other aspects to examine such as shared processing across provisioning services, effectiveness of decision-trees, chain-of-command, and even the portfolio rationalization of the services offered in general. All good and well but in my opinion, you need to start simple. You need to start small in scope and gain some quick wins. Most importantly, you need to experiment and learn early on so that you can adjust your strategy as you progress onto providing more services, and more complex services.
..