CRC DSS: Customer Requirements Capture

Introduction

The Customer Requirements Capture Decision Support System is designed to assist telecommunications salespeople in their negotiations with clients. The system helps in identifying the communication needs of customers in order to provide the best solution satisfying the global communication requirements of an organisation. The need for such a decision support tool stems from the complexity of service provisioning today: an increasing range of services, each of which may be configured for individual customers. This complexity makes it very difficult for individual salespeople to maintain an overview of current service portfolios and to make a correct mapping between the customer's requirements and available services.

The CRC DSS helps to bridge the gap between the business world of the customer and the telecommunications world of the service provider. Telecommunications requirements capture thus moves away from the technical style of current approaches to the more appropriate context of business analysis. The CRC DSS plays a supporting role in the primary sales dialogue between salesperson and customer. In addition to assisting the sales representative in the analysis of requirements through a secondary dialogue, the system can be used to present information to both parties in the negotiation, helping to ensure a common understanding of the customer's situation:

.

Figure 1: The DESSERT requirements capture situation

Customer Requirements Capture Process

The overall process consists of six steps:

These service requirements may be transtaed to network requirements.

Building the Business Activity Model

The first step is to gather administrative and business details on the customer: customers are engaged in activities, and these activities give rise to telecommunication needs. A Business Activity Model (BAM) is constructed in negotiation with the customer. The business activities are represented in a tree and at the end of the negotiation, a subset of the leaves of the tree are marked as interesting activities for the provision of telecommunications services. This subset represents those parts of a customer's business which may be supported by services.

Generating a Reference for Customer Services

The next step is a translation from customer activities, as specified in the BAM, to associated telecommunications needs. First, the activities are structured into a template identifying relevant information: the action part of the activity, the objects transferred and the parties involved. Then, a Reference for Customer Services (RCS) is built, consisting of nodes (representing parties) and links (representing telecommunication paths between those parties). Usage of the service is also captured and used to influence the choice of service provided to the customer.

Building a Required Service List

The subsequent step entails forming the actual service requirements associated with the customer's needs. This involves describing the requirements in an identical way to the description of services, so that a direct match may later be made. Services are described as of combinations of building blocks, named service elements, which are categorised as either communication, information, management or processing service elements. The RCS built in the previous phase leads directly to identification of the communication and information service element. The service provider's expertise further improves the identification of other elements, which can be edited to bring them in line with the customer's requirement. At the end of this matching process we have a list of services which describe the customer's service requirements: the Required Service List.

Generating a Reference for Customer Services

These required services are matched with the actual services available in the provider's portfolio, and the resulting list is prioritised to identify a Global Solution List. Customer preferences, such as costs and quality are used during this prioritisation to identify the best match for the customer's business. Finally, costs are presented to the customer using the charge overview tool, where installation, subscription and usage charges are shown for the solutions.

Conclusions

The CRC DSS supports both customer and user in following a stepwise progression from the world of business activities and needs to the world of services and costs. The various types of information needed during service requirements engineering are made explicit so that both parties are aware of the context of negotiation. In this way, the chances of finding the correct match between needs and services are raised, benefiting both client and service provider.