CHAPTER 13: THE USD AND BACK OFFICE DEPENDENCIES
Proper handling of customer questions requires a demarcation between USD and back office processes. The USD exists only because of a back office, and a successful USD depends on the working of the processes between the USD and back office. The processes within and between the USD and the back office should be recorded and often secured in contracts (external customers) and/or agreements. These contracts/agreements in turn should be based on the way in which requests are to be handled.
After reading this chapter, the reader should better understand how processes between request and delivery come into being, the relationship and mutual dependency between the USD and back office, and the various means of designing processes between the USD and back office.
13.1 The USD and the back office
When developing a USD, applying the front office to back office principle is the accepted means of organising the demand process (from customer request to implementation and fulfilment). The USD is responsible for the reception and management of the customer request, and the back office is responsible for the proper integrated processing of the demand. Efficient organisation of the relationship between the USD and the back office is based on ‘Thinking in processes’.23
The starting point is organising products and services into groups of activities that can then be dealt with within the USD and the back office. Therefore, it is essential to have an overview of all activities that are needed to produce a specific product or service. A process consists of the consecutive activities required to handle a product or service request. After the customer request has been received, it is decided whether the product or service can be handled within the USD (entirely or partially), or if it must be passed on.
The request might be forwarded to other departments, or external parties, including the back office. In the back office there should be staff that are responsible for certain products and services (experts/specialists), coordinators, implementers and project generalists. Tasks that are carried out include project management, more detailed advice, management, control, execution of work (catering, technology, transport, etc.).
In most cases, a settlement process based on the front office to back office principle consists of a fixed structure. This structure is shown in Figure 13.1.
Figure 13.1: A ‘standard’ delivery process from customer demand to delivery
During this process, the USD (if this is part of the agreed demarcation) remains responsible for the proper functioning of the entire chain and the monitoring of the correct handling of the customer demand (depending on the mandate or the authority that the USD has received). Consequently, the USD tasks are not limited to the intake of demand or to passing on requests when necessary. USD tasks also encompass:
• Monitoring progress;
• Reporting on performance and quality;
• Controlling the process of transference to the appropriate party;
• Ensuring progress and performance;
• Ensuring compliance with customer agreements;
• Ensuring the correct provision of information from within the enterprise or third parties; and
• Informing the customer where necessary (for example, in the event of a delay in the delivery process).
13.2 Designing and setting up processes and activities
Processes can be analysed, designed and arranged in various ways. A common approach was created by Obers and Achterberg. They define a process as a coherent set of activities, people and resources, with which one or more products or services are generated; this is also described as a work process. However, it often happens that one or more additional processes are needed to realise the final product or service for a customer; these multiple processes then form a process chain. A work process comprises various activities with each activity being one step in the process. Obviously, to perform activities, actions must be performed. This process is summarised in Figure 13.2.
Figure 13.2: Definitions associated with a process chain (Obers and Achterberg)24
This terminology has significance for the USD with regard to products and services like a renovation or room reservation. A renovation comprises various processes, such as clearing a construction site, preparing work, dismantling walls, installing IT and electrical equipment, and delivering and cleaning. Subsequently, the process can be divided into activities and underlying actions that have to be carried out in order to realise the process (see also chapter 3). An application for a room reservation for a meeting involves a reservation process, providing catering, possibly checking whether there are additional facilities, ensuring that the seating arrangement is good, and so on. This is shown in Table 13.1.
Table 13.1: Examples of the Services for Renovation and Room Reservation
Service: Renovation |
Service: Room Reservation | |
Process Chain |
Home improvement |
Meeting |
Process (working process) |
Move the wall |
Reserve room |
Activity |
Remove the wall |
Book the reservation |
Action |
Demolition and construction |
Enter the relevant data |
Example: Perfection?
In practice, there is a tendency to fixate on the correctness of the processes and on establishing a unanimous agreement among all involved. The danger is that a lot of time may be lost in discussing the ideal solution. Often it is wise not to dwell on the processes for too long, but instead to define and implement the main processes and optimise them later.
For this reason it is a practical step to weigh up the implementation of new SMS or Help desk systems: is the pre-programmed standard ‘out of the box’ process sufficient? If so, choose that as it saves a lot of time and money. Of course this is not always possible, for example where critical processes or links to other business systems are present. Ultimately, the quality of the USD is not judged on the quality of the execution of the processes, but on the quality of the service provided by enthusiastic and expert employees.
There are different ways in which processes can be published. A simple way is to create a ‘cheat sheet’ with an accompanying process diagram. In chapter 2, an example was given of a process chain for a report, including a diagram. Table 13.2 contains an example of a cheat sheet for a ‘standard room reservation’ product in which the activities and actions have been named.
Table 13.2: Room Reservation Processes
13.3 Mechanisms to connect processes between the USD and back office
The USD activities are not limited to the confines of the USD, they continue in the back office. The USD acts on the enterprise’s behalf in cooperation with the back office. In other words, there are organisational processes that run across departmental boundaries. The work processes vary from regular processes within a domain to the application of integrated systems. There are several situations in which the responsibility of the USD affects the work processes between the USD and the back office. The following situations can be distinguished:
a) Regular processes within a domain
b) Regular processes across multiple domains
c) Coordination through the USD
d) Integral systems
a) Regular processes within a domain
These situations concern the handling of products and services within one department in which the USD is also located. Settlements can be performed either directly within the USD or through colleagues within the department (for example, issuing laptops and creating ID cards). External customers might need to confirm deliveries or respond to emails about service support. The USD is fully responsible for the process.
b) Regular processes across multiple domains
The handling of customer demand also goes through other departments, and USD staff must make agreements about time and planning. The handling can be standardised for regular customer questions. For project-based services, the agreements must be specified (for example, for meeting services and relocations). USD staff will have to inform colleagues in the event of non-compliance with agreed processes. If necessary, the responsible line manager is contacted. The USD depends on others for the effective course of the process.
c) Coordination through the USD
The handling is coordinated by the USD. The USD is authorised to coordinate the delivery of specific products and services (for example, testing business continuity plans with IT) and to monitor progress. If incidents occur, they can escalate to account management or to a higher level. The settlement authority lies with account management. Account management often has the authority to operate across departmental boundaries. The USD is responsible for the entire process but it only has a partial mandate to ensure the process’ course.
d) Integral systems
The systems and processes for handling customer questions are integrated. Such situations can be created with ERP (workflow) systems or a generic system for handling different types of customer questions (for example standardised work orders). In practice, it appears that the integration of systems for reasons other than technical is not always possible. The assurance of the process is then set at a higher level than the USD and back office through management agreements.
13.4 Separation between the USD and back office: handling levels
A process between customer demand and handling is a series of activities and actions that lead to the production and delivery of products and services. The ITIL and other service management principles are based on the same process principles. The difference between the USD approach and the IT related approaches is one of scale; focusing on IT infrastructure is limiting but relatively easy to scope. Extending ‘service management’ to include generic facilities management makes a lot of sense because of the opportunity to use new technologies to join up many processes and, therefore, many types of requests.
Because the USD is usually at the forefront of the processing of all activities following the customer request, it is necessary that an inventory is made and catalogued for all products and services that can be requested. This should contain information on:
• How the customer request comes to the USD, whether via the service portal, telephone, email, the physical counter or account management; and
• Whether it can be handled immediately, can be forwarded directly to the back office or whether it still has to undergo some form of assessment in the USD.
The cooperation between the USD and other organisational units and third parties requires a great deal of attention. The cooperation must be focused on optimal service to the customer. In order to achieve this, the USD needs knowledge of the tasks, expertise and skills of the other parties that may be involved, or a comprehensive database of information about these other parties.
To begin with, the fulfilment processes should be focused on standard delivery of most commonly needed products and services. Depending on the nature of specific products or services, a process may need to be redesigned or specific agreements have to be made with regard to coordination between the USD and the back office. Management must ensure mutual coordination between the appropriate business units and the responsible department heads.
It is important to consider whether a user request made to the USD (i.e. via intranet, telephone, email, post, desk or account management) needs to be assessed for action first, or whether the question must be passed on directly to the back office or account management. This question must be approached both within the philosophy of a USD and at the level of product or service. The choice determines the specific functions of the USD and how it is organised (skills, numbers, information database(s)). In practice, the term ‘handling level’ is often used. A level of handling indicates how the delivery process of a product or service must be organised. Four levels of handling are defined in Table 13.3.
Table 13.3: Handling Levels in the Service Management and Facility Environment
The desired service quality is based on the ideal level of ‘ready while you wait’ service. However, this is not always feasible because there is usually an agreed delivery time for a service or product in place; things are further complicated when the request for the service must be handled by the back office or a third party. The following handling levels can be used: |
1. ‘Ready while you wait’ – simple products and services are delivered immediately (for example, an ID card). |
2. Handling by the USD –simple products are requested, but a production time exists eliminating the prospect of immediate delivery. |
3. Request intake USD with handling in the back office – the basic customer information can be collected by the USD for the application of a product. Using this information, it is possible to refer the request to the back office, a specialist will discuss the details with the customer. |
4. Immediate reference to back office or account management the product is so complex or so rarely requested that direct contact with a specialist or account manager is necessary. |
If account management is a function within the enterprise, but it is managed outside the USD umbrella, then it is logical to define an extra level of handling. |
With regard to some products or services, the request may not be acceptable within USD policies. In these cases, the most customer-friendly solution is to provide the customer with the best possible information, to refer them to colleagues, or to run the question through account management. The USD should of course register these cases. On the basis of these requests, it might be necessary to revisit their policies.
Therefore, the process from intake to processing in support of each product and service is important for the final design of the USD. This means that the following questions must be answered per product and service:
• How is the customer demand for a product or service made (what is the agreed level of service?
° How does the request arise? Via the Internet, intranet, call centre, physical, account management?
• How is a product or service delivered and at which level of agreed service?
• What is the level of handling for each product or service?
• Which mechanisms are used for each product or service (automation, manual, combinations or other) to arrange the coordination between the USD and the back office?
Table 13.4 contains an example in which the various questions per product and service have been answered. A distinction has also been made between basic service or basic-plus service. This information is important in assessing whether there are authorisations needed or costs. If this information is available, the first four steps of phase two, from design to realisation, are fully complete. The USD organisation can be designed in combination with phase one (ambition and objectives) and with the basic principles of design and coordination. This will be discussed in the next chapter.
Table 13.4: Process from Intake to Processing per Product and Service:
13.5 Reconciliation and coordination between the USD and back office
The coordination can be secured in the following three ways:
1. Organisation and authority
2. Processes and methods
3. Collaboration
By working with an organisational classification of USD employees and account managers in the USD, a good demarcation between competencies and responsibilities can be realised. This demarcation has another advantage: it offers the possibility of a guided transition from segmented services to demand-oriented services. In this, the role of the account managers is crucial. These account managers often originate from the various operational units and can function as a connecting link between the colleagues from the various back offices and the ‘new’ colleagues at the USD. In addition, they can take care of the transfer of knowledge from the disciplines (where they once worked) to the employees of the USD. Usually this process involves the transfer of knowledge from a specific back office ‘field’ to USD employees who have the most affinity with this field, or originate from the same back office.
2. Processes and methods
The second method involves processes and methods, and the products and service catalogue can offer a solution here. After all, every service is described in this catalogue (which is why the concept was swiped by IT). The back office has the functional responsibility to update the product descriptions. There is therefore agreement within the enterprise about the nature and content of the products. These products or services are linked to information that strengthens the alignment between the USD and the back office. Describing the work process and the level of handling should be a mandatory task, so that no misunderstanding can arise about the task demarcation lines between front and back office. Information can also be kept on production numbers, key indicators on processing times and lead times. The required staffing of the USD can also be linked to the work quantities. This also applies to the software tools needed by the USD, the quality of the personnel deployment and suggestions from the back office for the streamlining of the service delivery.
When product and service descriptions are adjusted by back office staff, the service management must ultimately have the final responsibility for the USD to assess the consequences of all alignment aspects per service or product, if product and service descriptions are adjusted by back-office staff. For example, the consequences for the organisation of the USD if the service level is substantially increased for customer groups. Management must also monitor the services provided e.g. what does it mean for staffing in the USD if the enterprise’s number of employees grows?
The link between product descriptions and organisational preconditions creates a covenant – sometimes called an operational level agreement (OLA) – between the front and back office concerning the nature and scope of the service to the USD. Procedures and working methods must be recorded in agreements, perhaps both in manuals and automated systems. This covenant or OLA is an important tool for the service and the service manager to manage the enterprise and make the relationship between the USD and various back office units explicit to ensure timely delivery of services.
Location managers and the USD
In an enterprise with various locations spread across the globe, customers can and should report their notifications via the service page of the enterprise Internet and/or intranet. A notification enters the system and, depending on the agreements made, is automatically passed on to the suppliers. If the approval of the customer is required, the quotation is sent electronically and can then be approved, and upon approval, delivered. The operational responsibility for delivery lies at the location. The location manager may be supported by multiple building or warehouse managers. The latter are responsible for ensuring correct fulfilment by suppliers, addressing problems, and they also form a point of contact for the customers in the building.
The local delivery regime is highly regulated by automation and standardisation. Only the services that are included in the products and service catalogue may be delivered; exceptions to the agreed service are primarily solved by the location manager.
3. Collaboration
Not everything has to be initially documented as instructions. Employees of the USD and back office must work together and learn from each other. It can be good for working relationships to share information/tips between back office and front office staff. This can be done in various ways:
• Exchanging experiences;
• Running internships for each other, in which back office staff serve as interns in the USD and USD employees in the back office;
• Conducting joint analyses and improvement proposals;
• Jointly filling out the FAQs in the SMS;
• Jointly drafting a handbook to support the handling of requests; and
• Jointly drafting and managing the products and service catalogue (whether a PDC or an iPDC).
Additionally, you may want to collaborate regarding consultation structures, policy frameworks and intake protocols.
23 Hardjono, T.W. & Bakker, R.J.M., Management van processen. Identificeren, besturen, beheersen en vernieuwen, Deventer: Kluwer, 2006; Obers, G-J. & Achterberg, K., Grip op processen in organisaties. Analyseren, ontwerpen en inrichten van bedrijfsprocessen, Zaltbommel: Van Haren Publishing, 2014.
24 Obers, G-J. & Achterberg, K., Grip op processen in organisaties. Analyseren, ontwerpen en inrichten van bedrijfsprocessen, Zaltbommel: Van Haren Publishing, 2014.