Calculation of the number of business application support specialists
Preface
Let’s assume that you became responsible for the support of business applications (application management service, AMS) and your manager set the task of forming a strategy and action plan for the organization of this activity. First of all, you turned to popular frameworks such as ITIL or COBIT. However, it was not possible to find valuable advice for all aspects of the activity. Because most methods tell what to do, but do not describe how.
We decided to structure our experience in building processes and support teams in such a way as to provide a clear and consistent guide for a manager faced with the task of building an AMS.
When organizing a support service and application development, tasks and key issues can be conventionally divided into three areas:
1. Organizational management:

Assessment of the required number, competence and qualification of personnel

Organizational structure of the support unit

Balance of insourcing and outsourcing
2. Relations with clients:

What to include in a contractual support relationship

Pricing model: subscription fee and/or ondemand service
3. Methodology and means of automation

Methodology and business architecture for AMS operation

Means of automating processes of support and development of applications
In the first article, we will try to understand what considerations can guide when estimating the required number of personnel to support applications, what assumptions and limitations should be taken into account.
Problems
Whether you provide support services as a thirdparty contractor or inhouse support organization, the most important indicator of your business is the cost of services. At the same time, we know that 80% or more of the cost of support services are personnel costs. And you need to balance between budget constraints (both internal and according to market conditions) on the one hand, and providing quality services on the other.
It should be noted that staff quantification will affect other issues that need to be resolved later. For example, the organizational structure, the model of provision of resources, provision of equipment and office space.
The most common recommendation offered by framework developers and manufacturers of ITSM systems when estimating the number of support personnel is the use of statistical data on the number and duration of processing requests to the support service. However, it does not work if the business application is only at the start of operation and there are simply no statistics.
Our experience suggests that the factors affecting the number of personnel can be typified as follows:
Number of users, which intensively use the system in their daily production activities. This factor can be used as a basis for calculating the number of support for transactional systems of the ERP, CRM, SRM class of NSM functionality
SLA parameterssuch as:

Service availability. For example, the provision of application support services outside working hours may result in the organization of staff shift work with the corresponding need to increase the number.

Speed of reaction, time to resolve appeals.

Availability among supported VIP users with stricter SLA requirements.
Calculation drivers that do not depend on the number of users, but complicate the task of maintaining the application.
For example, such as:

Number of indicators in reporting, number of reports.

The number of integration flows.

The number of timesheet numbers in payroll calculations.
The number of users is the most understandable indicator. In our experience, on average, one user receives 5 to 7 requests per year, with an average time of 2 to 4 hours per request. In this way, you can calculate the total labor intensity and the need for personnel under several scenarios from negative (maximum values) to positive (minimum values).
The influence of SLA parameters on the size of the support team must be taken into account as correction factors for calculations. For example, service availability can be 8×5, 12×5, 24×7, etc. In this case, we can calculate a correction factor for the calculation of the number of personnel, taking into account the shift work and the terms of payment of rework. If you are placed under strict deadlines for the decision of appeals, this can also be a multiplier for increasing the number and improving the skills of the team.
The situation is more difficult with the estimation of the number of personnel for systems and services, where the number of the support team does not correlate directly with the number of users of the systems. Or the labor intensity of support is affected by factors that are very difficult to lead to the algorithms for calculating the labor intensity. For example, business intelligence systems, data warehouses, integration solutions. In these cases, we can only talk about evaluation drivers that affect the complexity of the decisions, which affects the labor intensity.
With this approach, the number of implemented reports, the number of metrics in them, and the number of showcases, data, and extractors can be used as similar drivers for business intelligence solutions.
For example, in our cases, when calculating the need for resources to support systems based on SAP BW/BI, we used the following input for calculations: no more than 3 business areas, 10 reports of 10 indicators for one support employee.
The number of integration flows and the complexity of data transformation performed directly on the data bus can be used to estimate the labor costs for supporting integration solutions.
In any case, without a clear mathematical algorithm for calculating labor intensity for this kind of services and systems, you will have to base your estimates on expert assessments and your own common sense and experience. As the statistics appear, you can adjust the calculations to be more accurate.
It should also not be forgotten that in the first year after the implementation of the business program, the load on the support service is much greater than in subsequent years, as the solution stabilizes, users get used to work, and the knowledge base is formed. Therefore, we recommend evaluating the need from a negative to a positive scenario during the first year.
In addition, in a number of cases it is necessary to evaluate the technical debt of implementation as another factor of complication of support tasks. If a “raw” solution is put into operation – try to estimate at least approximately the labor intensity of the improvements and determine the limit for their implementation, which can be covered by your team. Usually, for the first year of support, at least 50% of the labor intensity of the total assessment of the labor intensity of functional support should be laid for the elimination of errors and comments.
Thus, even without statistics or a benchmark, you will be able to calculate the number based on several indicators described in this article.
The authors