What are the challenges of automating the approvals of service requests

By ITIL from Experience ©

Generally, when a service request is for system access or that it incurs spending an authorization is required before it can be fulfilled. Such authorizations are good candidates for a workflow1 and most ITSM tools have the ability to automatically send a task to the system owner or the user’s manager for approval. For example, the approver can reply to an email sent by the tool by typing the word "approved", "rejected" or by clicking on a link to record their decision directly in the ITSM tool.

For this to work:

The process must be well-defined with clear business rules so that it can be automated
The workflow tool needs access to accurate information on approvers

This sounds simple from a technology point of view; however implementation challenges include:

Participation and by-in from stakeholders
Clear business rules and conditions for their use
Access to accurate approvers’ data
Handling of various usage scenarios
Tool constraints

The first challenge is to get all stakeholders to agree to invest time and effort working on automating the process. When the process involves multiple groups or divisions, it is usually more difficult. In some organizations for example, I.T. handles the user interaction while Finance coordinates with suppliers the order of new user devices. As such the Service Desk takes the order, ensures that it is complete, authorized and transfers it to Finance for procurement. When the goods are received, I.T. takes care of the installation/release. Approvals for system access tend to be less challenging. System owners or custodians only have to agree to receive and process these notifications and typically do not need to invest a lot of time to this initiative aside from providing requirements and testing the solution. Nonetheless, what is the priority for one group usually is not a priority for another group.

The second challenge is to understand the rules and conditions affecting who approves the request. For starters, each category of requests has unique requirements. For example, requests for hardware/software usually have different rules than a request for system access (e.g. account creation). In addition, rules often change based on the particulars of the request (e.g. ordering a PC vs. a server) or based on the dollar value or type of access requested (e.g. administrator account). This can also include how the goods are used, like when a user requests a second monitor. If it is directly related to a project it might need to be approved by the project manager or the functional manager depending on project funding agreements. Another point to consider is that some managers can approve their own request if it is within their signing authority. Thus, the workflow should have the necessary logic to account for all business rules; otherwise senior managers will receive approval tasks unnecessarily.

Thirdly, having a list of individuals who can approve what and for who is often a challenge. In most organizations the Human Resources (HR) Department is the owner and custodian of the people data and their areas of responsibilities on the organizational chart. It is often stored in the Enterprise Resource Planning system (ERP) or HR Management Information System (HRMIS) along with people’s position, pay rates and employee’s personal information (e.g. emergency contact information, names and age of dependents). HR departments are naturally protective of this data and are usually worried of making it available to other systems. A work around can be to regularly copy the necessary data from the ERP/HRMIS to a staging database where the workflow can access data it needs to process the business rules.

Although other data sources may be available like Active Directory or from an Identify and Access Management (IAM) tool, business processes must be in place to maintain this data. Most maintenance activities involve HR since they usually are the result of a staffing action (e.g. hiring, transfer, promotion, departure). As a workaround to involving HR, some I.T. organizations decides to maintain its own data which is both labor intensive and very difficult to keep accurate and up to date.

These data sources typically do not account for system owners. Thus, they can be modified to include the necessary fields or a separate database can be created to keep a list of systems, their owners and who can authorize access. Again processes must be in place to maintain this data. An easy way to do so without involving HR is to email system owners quarterly or semi-annually a request to confirm that they are still the owners.

Let’s not forget the list of individuals with signing authority, their authorized thresholds and budgetary authority. The typical custodian of this data is the Finance Department, thus similar challenges as described above can be encountered there as well.

A fourth challenge is for the automation to account for the various usage scenarios. For example, the user's manager is away on sick leave and as a result the approval task must be sent to the acting manager or to the project manager if the requester is seconded to the project. The use of the process on a mobile device or when disconnected from the network may also need to be considered.

The next challenge is to make it all work within the constraints of the tool. Limitations might be discovered causing a need to reconsider the process and business rules.

Automation is appealing to I.T. people. Nonetheless, depending on the organization these challenges can be considerable and often are like pealing an onion: additional layers are discovered as progress is made. As some people like to say: “If it would be easy, everyone would be doing it by now.” It is therefore advisable to be very selective in which service request approvals should be automated.

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>