Goal oriented service management Deb Cooper Steve Battle Contact24 Ltd Hewlett Packard Laboratories 100 Victoria St, Bristol BS1 6HE. Filton Rd, Bristol, BS34 8QZ. deb.cooper@contact24.co.uk steve_battle@hp.com Abstract: This paper explores the relationship between aims, objectives, and business (or strategic) goals. In a study in Customer Relationship Management (CRM) we see these ideas as drivers of systems analysis and service management. This paper explores the initiation of a business-to-business relationship between a client wishing to establish a customer help-line, and an outsourced contact centre solution companyi. The case study has been anonymized to respect client privacy. The study calls for a multi-channel solution (telephony and internet) with print fulfilment, involving data and knowledge management. Operational context This study looks at the outsourcing of a significant portion of a client’s business. The resulting business processes spans a number of enterprises including the client and contact organizations, and a print fulfilment house. They are packaged as services that can be exposed to managers, business partners, or indeed customers. Through business process modelling, these services are identified as tangible assets that can be offered for sale and explicitly managed as web-services1. Additionally, the solution supports a high degree of collaboration through which internal processes and data (the stuff of workflow) are exposed to the client. The client is able to reconfigure call-scripts and other operational parameters, supporting a high degree of agility in response to the changing needs of the industry. The client is also able to remotely monitor calls and retrieve operational reports online. Initially, we will identify the different participants who may interact with the system. The Client instigates the development of the system that is to be outsourced. For the purposes of this exercise we consider only the briefing function of the client by which up to date information may be uploaded to the system. The Customer is a member of the public who requires help with one of the products covered by the service. Front-line help is provided by the Contact Centre, in the form of either a Bureau Advisor, for simple brochure requests, or by a Dedicated Advisor, who is part of a team that has received advanced product and customer service training, to help with customer queries. There is a i Contact24 Ltd. 1 Goal oriented service management team of Client Advisors based at the client organisation with access to additional data and information, and to whom some of the more obscure cases can be escalated. Where additional information or support material is required by the customer, the print Fulfilment house is requested to send the required publication(s). For use-case driven methodologies using UML, the Unified Modelling Language2, the process of requirements capture and analysis begins with the creation of use-case diagrams. Each use-case identifies a business process3. Figure 1 outlines a number of use-cases that comprise the customer help-line service. Overall, the enquiry is a cross-enterprise process spanning multiple organizations. It involves outsourced advice and fulfilment, with an escalation path back to a member of the Client Team. We find it helpful to develop sub- cases to the point where they represent activities that can be managed by a single organization. Briefings by the client are uploaded directly to the system. Help-line Publication «extends» request Fulfilment Telephone enquiry Bureau Advisor Customer Query «extends» Advisor «extends» Briefing Dedicated Advisor Escalation «» «» Client Client Advisor Figure 1: The help-line service The system illustrated in Figure 1 describes the help-line service. The processes within this service can be thought of as conversations between the actors indicated. The term conversation is deliberately chosen so as to emphasize the exchange of value between the various participants in the process, rather than focussing on more prescriptive process models. It may range from an open- ended dialogue between humans to an automated transaction. The service we have described combines internet and telephony based communication. For example, the query is (an optional) part of the telephone enquiry, representing a scripted conversation between the customer and the advisor. The conversation with the fulfilment house is via IVRii, by which the user selects a publication by pressing the appropriate numbers on the telephone keypad, this choice being summarised in an electronic message to fulfilment. ii Interactive Voice Response 2 Goal oriented service management During subsequent development we refer back to these use-cases during implementation, testing, and documentation phases. However, additional information in the form of aims and objectives is typically available from very early on. This material may be used to justify particular use-cases, in much the same way as use-cases are a reference point for later work. Aims and Objectives The process of tendering for new business begins with a request for quotes (RFQ). The use-cases outlined in Figure 1 form part of the functional requirements captured from this document. In addition, the RFQ may set out a number of high-level aims and objectives. The primary distinction between aims and objectives is that while aims are relatively fixed, the objectives are open to negotiation during the set-up of the business relationship, and are likely to develop over time. Strategic aims are distilled into a set of more tactical objectives that are campaign specific. In Table 1 below, the objectives are grouped to emphasise their common aims. One reading of this is that the purpose of a given objective is the associated aim. In other words, we understand purpose as a directed relationship, in this case between an objective and an aim. Client Corporate Aims Campaign Objectives Maintain confidence in the 1. To successfully manage the transition of service from industry incumbent supplier 2. To provide flexible messaging, routing and telephony switching through a dynamic IVR system. Must be capable of instant routing changes to cope with industry events/crises 3. Ensure all public information is up to date Promote public understanding 4. To provide a contact centre to handle a typical monthly of the business volume of 12K-15K with agreed staff numbers 5. To provide specialist staff familiar with the industry services and products 6. To provide fulfilment for domestic & industry-requests for brochures/printed information. Volumes around 45K requests per month Ensure the protection of 7. To provide and maintain a product knowledge base. consumers, whilst helping 8. To ensure staff are confident of their boundaries and of them to recognise their own the remit of our client. responsibilities. Reduce scope for industry 9. Provide reporting on Exceptions to day-to-day enquiries. crime. 10. Provide details of customer complaint calls 11. Provide escalation process where any possibility of fraudulent activity is identified within a contact. Table 1: aims and objectives We may extend this purpose hierarchy4 further, to include the use-cases (processes) identified in the previous section. Every process has a purpose; we 3 Goal oriented service management wish to make this more explicit by saying that every process has a clearly identified purpose. In Table 2 we list each use-case and the purposes (objectives) that it serves. Note that we have not exhausted the list of objectives, some of them will feed into non-functional requirements. Others, (such as 3) may indicate that use-case capture is incomplete (as indeed it is). Conversely we may see a need for a use-case for which no objective can be identified. In this case either the objectives are truly incomplete, or the use-case really has no purpose. Either way, one benefit that arises from tracking use-case objectives is the ability to cross check one against the other. Use-case Objectives Telephone enquiry 2 Publication request 6 Complex query 4, 7, 10 Escalation 11 Briefing 3 Table 2: objectives by use-case With explicitly labelled aims and objectives the client can immediately see which of these have been taken into account in the system specification, and where. The specification should be signed off against agreed objectives, and new objectives should not be introduced ad-hoc, without appropriate change control. Goals An objective (or aim) is an informal description agreed by the client and the service providers. It has little internal structure other than a useful description and a label. Without introducing some concrete criteria it can be hard to verify that an objective has been achieved. We elaborate on aims and objectives by adding specific business (or strategic) goals. They are an objective measure of the success of a business process, not of an individual process instance. These goals also form part of the Service Level Agreement (SLA) with the client, and they play an important role in reporting, management information and in process monitoring. In Table 3 below, we list goals by objective, demonstrating that a single objective may have many goals associated with it. Most of the goals listed may be concretely evaluated against an enterprise database, although we also see non-functional goals such as (c) and (e) which may be outside the scope of the management system. In addition, crime related objectives (9-11) prove harder to quantify over a short time scale, requiring further analysis at the year’s end. 4 Goal oriented service management Objective Goals 1 a. All outstanding calls to be completed within one month. 2 b. The IVR must be updated within 4 hours of a relevant client briefing. 3 c. Test calling around new industry issues. 4 d. Where call volumes are up to agreed daily levels; 85% of calls to be answered within 15 seconds. 5 e. All staff to be qualified to stated levels within 6 months. f. Less than 5% of queries unresolved per month. g. At least 75% of queries resolved at first hit. 6 h. 85% of customer orders to be fulfilled within 10 days. 7 i. Stock changes to be available within 4 hours of client briefing. 8 j. Quality monitoring to be performed on 8 calls per agent/ per month. k. Less than 10% repeat callers per month. l. No more than 10% of queries to be escalated. Table 3: goals by objective In order to evaluate these goals, we must be able to collect measurements at appropriate stages in the process. The use-case diagram in Figure 1 can help us to identify these key points. Typically these occur on entry to, or exit from a process, and where a new actor joins the conversation. We find it helpful to signify the introduction of a new actor in a conversation with a sub-case. The system will begin collecting telephony data when the initial enquiry is routed through the IVR on entry to the telephone enquiry. The time difference with the start of the conversation with the advisor would be used to evaluate goal (d). Similarly, the escalation path represents a client advisor joining the conversation, and the number of occurrences of this event informs goal (l). On exit from the call we would be able to determine whether the call was resolved or unresolved, feeding into goals (f) and (g). Table 3 appears to show a direct relationship between objectives and goals, but we see from the discussion above that goal evaluation is intimately tied up with the business process model. If the process model were to change, then the goals would be invalidated. This may occur in emergency situations where business continuity is offered. This represents a fall back position where radically simpler (often manual) procedures can temporarily meet the same objectives. In these cases, goal evaluation on the same basis as before may become impossible. 5 Goal oriented service management Summary Taken together, this study illustrates the complex inter-dependencies that may exist between business process (use-cases), (aims and) objectives, and goals. Business processes are designed to meet identified objectives, and goals are put in place to provide concrete evidence that these objectives are being achieved. In this way, goals provide evidence that these processes are working. Our approach to goal-based management is pragmatic, based on experience with business process modelling in the area of customer relationship management, an area rich in cross-enterprise collaboration. The immediate problems of business in coming to grips with collaboration are in finding ways to design and manage these integrated business processes. The techniques we have described help focus attention on the aims, objectives and goals of the organization; what the business is about. 1 Naresh Apte, Toral Mehta, Web Services, Prentice Hall, 2002. 2 Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modelling Language User Guide, Addison-Wesley, 1998. 3 I. Jacobson, M. Ericsson, A. Jacobson, The Object Advantage: Business process reengineering with object technology, Addison Wesley, 1994. 4 Chris Marshall, Enterprise Modelling with UML: Designing successful software through business analysis, Addison Wesley, 2000. 6