Brokering IT Services Internally: Building the Order Process
Dick Benton, a principal consultant for GlassHouse Technologies, has worked with numerous Fortune 1000 clients in a wide range of industries to develop and execute business-aligned strategies for technology governance, cloud computing and disaster recovery.DICK BENTON
In my last post, I outlined the fourth of seven key tips IT departments should follow if they want to begin building a better service strategy for their internal users: advertise the Ts and Cs. That means developing a simple and easy-to-read list of the terms and conditions under which IT services are supplied. Now we will address actually building the order process, so that services can be provisioned in an automated way that can satisfy today’s on-demand consumers. One of the major cloud differentiators is its ability to support self-service selection followed by automated provisioning; in other words, being able to offer services on a Web page which will trigger scripts to automatically provision the selected resource.
Historically, the largest roadblock to an expedited provisioning process is the “legacy” approach to service fulfillment. Typically, when the busy consumer seeks access to a resource, he or she is faced with a daunting obstacle course of approvals. Usually, this will involve a lengthy form to complete (sometimes even an online form) with an explicit rationale for the request, along with minute detail on the amount of resources to be consumed and information like peak loadings. Some organizations include an additional section for risk management covering the impact or association the resource may have with various compliance legislation and internal compliance regulation. Other sections will provide space for approval of active directory additions, network access, storage utilization, backup protection and even disaster recovery. Often there will be a section covering the data to be used with the resource and a questionnaire on this data covering its corporate sensitivity and the need for encryption.
Although the process seems to place every conceivable obstacle between the consumer and the resource sought, the process is typically one that has been built over time. Each checkpoint probably developed in response to some painful, embarrassing or uptime-impacting event in the past. The process is designed to specifically eliminate the possibility of those past events recurring. The “cover-your-backside” process is not uncommon in IT procedures.
Just-in-case provisioning is designed to ensure that the risk of any inappropriate or unauthorized allocation or usage is reduced to near zero. In the past, this has been the foundation of provisioning time frames lasting weeks and even months. Also, it’s why IT is often seen as an impediment rather than an enabler of the business. These forces have also driven an evolution in the defense mechanisms of the resource requestor. The resource requestor learned what the “right” answers were in order to get their request through the process with only a three- or four-week delay. Again, typically there is no detection mechanism nor any procedure for withdrawal of a resource found to have been used in a manner that is different from its “planned” purpose.