Reader Question: How can we implement a Request Catalog in our organization?

Third Sky Expert Answer:

Kai Holthaus, Director of Consulting, Third Sky

You've heard a lot about the Service Catalog. How we are all supposed to have one, containing the details of all operational services, and those about to become operational. I would argue that one of those details described for a service should be defined service requests that users can submit. For instance, the Email service should have requests defined such as "New public folder" or "New distribution list". Ideally, users should be able to fill out a simple form to start the request fulfillment process from right there.

This idea can be implemented with a Request Catalog. Such a catalog categorizes all these defined requests, and provides users with the ability to start the fulfillment process, and ideally also with the ability to track the progress of the fulfillment. To make this happen on the IT side, the Request Catalog tool will need a front-end (if not already integrated in a Service Catalog tool), and a workflow engine to manage the fulfillment process.

When implementing such a Request Catalog, one needs to define a list of requests that should be contained in that catalog. For each of those requests, the following will need to be defined:

• Description of the request. This typically includes a short and a long description, as well as a picture. The description should be adequate for users to understand what it is they are actually requesting, and what they can expect to happen once they start the fulfillment process. If there is cost associated with the request, it should clearly be spelled out, including a separation of one-time and recurring charges. Finally, the description should also include contact information, similar to the service definition page in the Service Catalog.
• Request form. This is the form users would have to fill out in order to start the fulfillment process. Common fields on such forms would include requester name and employee ID, but other fields may be necessary that are specific to the request at hand. For instance, the request for a new laptop might require the user to provide a business justification for a laptop (instead of a desktop). When defining these request forms it is important to make them as simple as possible for the users. Whenever data can be derived from already received information, it should not be necessary for the user to type that information in. If a field only has a limited amount of valid answers, present the field as a drop-down menu instead of a free form text field. The more the form can guarantee accurate information about the request, the easier it will be to fulfill the request (either automatically or manually), because the need for contacting the user about missing or inaccurate information will be minimized.
• Fulfillment process. Since one of the benefits of a good Request Catalog is the tracking of the fulfillment process, that process needs to be designed for each service request. When designing the fulfillment process, it is important to strike a balance between the need for detailed information and the additional work necessary to fulfill more detailed requests. For instance, if the workflow is asking the same resource to complete five separate steps in a row, it may be more economical to combine those steps into a single workflow task. If they are left separate, the resource will have to tell the workflow engine after each task that the task is complete. This may represent unnecessary overhead which would slow adoption of the tool.
• Workflow engines can be integrated with a lot of other data sources. Good workflow engines can not only facilitate manual fulfillment tasks but they can also orchestrate automated tasks.  The more advanced engines can integrate with a wide variety of tools and data sources.  Furthermore, the workflow can be configured using easy-to-use flow chart like features with little to no programming.  A good example of these capabilities is PMG.
  Another benefit of such a workflow engine is the possibility to request additional from users, or have users confirm successful completion of the fulfillment requests.
  Finally, since the workflows are tracked by a workflow engine, there is a record for each request fulfillment, and performance measurements can also be derived from the engine.

Naturally, the Request Catalog should be integrated with the Service Catalog. At the very least, this should include a list of all defined Service Requests on a service entry page in the Service Catalog, with a link to the request form, should a user want to request the fulfillment of a particular item.