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.
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 subcases 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. Customer
Client
Help-line
Telephone enquiry
Briefing «extends»
Publication
request «extends»
Query «extends»
Escalation «» «»
Fulfilment
Advisor Client Advisor
Bureau Advisor Dedicated Advisor 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 openended 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 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.
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.
Reduce scope for industry crime.
1. To successfully manage the transition of service from
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 4. To provide a contact centre to handle a typical monthly
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 7. To provide and maintain a product knowledge base. 8. To ensure staff are confident of their boundaries and of
the remit of our client. 9. Provide reporting on Exceptions to day-to-day enquiries. 10. Provide details of customer complaint calls 11. Provide escalation process where any possibility of
fraudulent activity is identified within a contact. We may extend this purpose hierarchy4 further, to include the use-cases (processes) identified in the previous section. Every process has a purpose; we 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.
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.
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. a. All outstanding calls to be completed within one
month. b. The IVR must be updated within 4 hours of a relevant
client briefing. c. Test calling around new industry issues. d. Where call volumes are up to agreed daily levels;
85% of calls to be answered within 15 seconds. 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. h. 85% of customer orders to be fulfilled within 10 days. i. Stock changes to be available within 4 hours of client briefing.
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).
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.