UNIVERSITÀ DEGLI STUDI DI PAVIA

UNIVERSITÀ DEGLI STUDI DI PAVIA FACOLTA DI INGEGNERIA DIPARTIMENTO DI INGEGNERIA INDUSTRIALE E DELL INFORMAZIONE CORSO DI LAUREA MAGISTRALE IN INGEGNERIA INFORMATICA DESIGN E IMPLEMENTAZIONE DI UN MODULO CRM PER UN ONLINE MEDIA PROVIDER DESIGN AND IMPLEMENTATION OF CRM PROCESS MODULE FOR AN ONLINE MEDIA PROVIDER Relatore: Prof. Gianmario MOTTA Prof. Gianluca LOPARCO Tesi di Laurea di ZHANG YAN ANNO ACCADEMICO 2012/2013

硕士学位论文 Dissertation for Master s Degree ( 理学硕士 ) (Master of Science) 在线媒体供应商客户关系管理流程模块的设计与实现 Design and Implementation of CRM Process Module for an Online Media Provider 张 UNIVERSITÀ DI PAVIA 2013 年 09 月

国内图书分类号 :TP311 学校代码 :10213 国际图书分类号 :681 密级 : 公开 硕士学位论文 Dissertation for the Master s Degree ( 理学硕士 ) (Master of Science) 在线媒体供应商客户关系管理流程模块的设计与实现 Design and Implementation of CRM Process Module for an Online Media Provider 硕士研究生 : 张 国 外 导 师 : Gianmario Motta 教授 Gianluca Loparco 教授 国内导师 : 邓胜春教授 实习单位导师 : Riccardo Plata 申请学位 : 理学硕士 学 科 : 计算机工程 所在单位 : 工业和信息工程学院 答辩日期 : 2013 年 09 月 授予学位单位 : 帕维亚大学哈尔滨工业大学

Classified Index: TP311 U.D.C: 681 Dissertation for the Master s Degree Design and Implementation of CRM Process Module for an Online Media Provider Candidate: UNIPV Supervisor: HIT Supervisor: Zhang Yan Prof. Gianmario Motta Prof. Gianluca Loparco Prof. Deng Shengchun Industrial Supervisor: Mgr. Riccardo Plata Academic Degree Applied for: Master of Science Speciality: Computer Engineering Affiliation: Department of Industrial and Information Engineering Date of Defence: September, 2013 Degree-Conferring-Institution: Universitàdegli studi di Pavia Harbin Institute of Technology

Abstratto SMedia èun provider di contenuti di intrattenimento con una grande quantità di clienti e alta frequenza di interazione con il cliente. Al fine di mantenere i clienti esistenti e potenziali, cosìcome attuare strategie di marketing e vendite, Smedia ha introdotto un sistema di gestione della relazione con il cliente (CRM). Con l'espansione della sua attività, Smedia ha deciso di collaborare con DT, un fornitore di servizi di telecomunicazione, che offrirà ai clienti i suoi programmi d intrattenimento. Il sistema CRM esistente ha bisogno di essere migliorato per gestire le nuove esigenze di business introdotte da questa cooperazione. La tesi si propone di descrivere la progettazione e la realizzazione del processo del modulo CRM specificato. Nella tesi due comuni problemi di cooperazione inter-organizzativa sono discussi per descrivere questo progetto di miglioramento del sistema CRM. Il primo riguarda la progettazione del sistema CRM per offrire un migliore servizio di assistenza clienti per i nuovi clienti introdotti dalla cooperazione. Il secondo riguarda l integrazione e aggregazione di dati e processi di business all'interno dell'azienda e tra le aziende. Dalla definizione dei processi che coprono l'intero ciclo di vita del cliente si ottiene il dettaglio dei requisiti di business. Inoltre si descrive l implementazione del database e delle interfacce utente e come queste realizzano la business logic presente nei processi di business. Il sistema èprogettato per interfacciarsi alle applicazioni esistenti in azienda tramite EAI (Enterprise Application Integration) e i web services sono definiti per soddisfare le diverse caratteristiche dei sistemi. Per sistemi interni, una soluzione EAI tradizionale basato middleware viene scelta a causa dei requisiti di tempo reale e di efficienza, mentre per i sistemi distribuiti in diverse organizzazioni la capacità di supporto cross-platform è più importante quindi tecnologia basata su web services èscelta come soluzione di integrazione di sistema. I risultati dei test mostrano che il sistema ha raggiunto la qualitàattesa. I due aspetti - processi di business e di dettaglio tecnologico vengono trattati in termini di analisi dei requisiti, progettazione, implementazione e test. La tesi offre una soluzione generale e pratica per la progettazione di processi e sistemi CRM e della integrazione con i diversi sistemi esistenti. I

Keywords: customer relationship management (CRM); enterprise application integra-tion (EAI); web service; extraction, transformation and loading (ETL) II

摘 要 SMedia 是一家拥有大量客户, 同时与客户有着高频率交互的媒体公司和内容提供商 为了更好的维护已有和潜在的客户群体, 同时有针对性的制定市场和销售策略,SMedia 引入了客户关系管理系统 可是, 随着业务的扩张,SMedia 同电信运营商 DT 决定开展合作, 使 DT 的客户能够收看前者所提供的节目内容 为了应对这一合作带来的新的商业需求, 现有的客户关系管理系统, 需要进行针对性的升级 本文即阐述针对此次合作的客户关系管理流程模块的设计与实现 本文通过客户关系管理系统的升级项目, 描述了对于企业间合作常见的两个问题 一是如何设计客户关系管理系统对合作带来的新客户进行更好的服务 二是如何在企业间和企业内部实现数据和业务流程的集成整合 本文通过对业务需求的详细描述, 设计了一组覆盖整个客户生命周期的客户关系管理流程, 并通过对数据库的修改以及用户界面和逻辑关系的设计实现对此流程的支撑 同时, 通过对企业内和企业间系统的区分, 以商业智能系统和 DT 作为两类系统的代表, 有针对性的设计了基于企业应用集成 (EAI) 和 Web 服务相结合的一套解决方案, 用于满足不同的功能特点的需要, 即针对企业内部系统, 鉴于其对实时性和执行效率的要求, 采用基于中间件的传统 EAI 解决方案 ; 针对分布于不同企业的系统, 鉴于跨平台性的要求, 采用 Web 服务作为系统集成解决方案 经测试, 系统达到预期水平, 能很好的为新的合作项目提供客户关系管理服务, 并且具备一定的可扩展性 本文从商业流程和技术细节两方面, 对系统的需求分析 设计 实现以及测试几个方面, 对整个项目的开发流程进行了详细描述 并通过项目介绍, 对客户关系管理流程和系统的设计以及不同层次的系统集成提供一个通用的具备实践性的解决方案, 希望对类似问题起到参考作用 关键词 : 客户关系管理, 企业应用集成,Web 服务,ETL III

Abstract SMedia is an entertain company and content provider with a large amount of customers and high frequency of customer interaction. In order to maintain existing and potential customers, as well as marketing and sales strategy, SMedia introduced a customer relationship management (CRM) system. But with the expansion of its business, it decided to cooperate with a telecommunication service provider DT, which will offer the customers of DT its programs. In this case, current CRM system needs to be enhanced to handle the new business requirements introduced by this cooperation. The thesis intends to describe the design and implementation of the specified CRM process module. In the thesis, two common issues of inter-organizational cooperation are discussed by describing this CRM system enhancement project. The first one is how to design CRM system to offer a better customer care service for new customers i n- troduced by the cooperation. The second one is how to integrate and aggregate data and business process inside the company and across companies. T he design of a group of CRM processes which covers the whole customer lifecycle is achieved by explaining the business requirements in detail. And by modifying the database and implementing user interfaces and related logical operations, the CRM processes are implemented and maintained. At the same time, by distinguishing internal systems, e.g. business intelligence system, and external systems, e.g. DT, a solution combined with enterprise application integration (EAI) and web service is designed to satisfy different characteristics. To internal systems, a middleware based traditional EAI solution is chosen because of the requirements of real-time and efficiency, while to systems distributed in different organizations, the cross-platform capability is more important so that web service technology is chosen as system integration solution. And after testing work, the system has achieved expected quality. It can properly support CRM for new cooperation project with scalability. According to two aspects, which are business process and technological detail, four stages of project development lifecycle, i.e. requirement analysis, system design, implementation and testing, have been described in detail. And by introducing this project, a general and practical solution for design of CRM process and system and system integration in different layers is proposed for the similar questions. IV

Keywords: customer relationship management (CRM); enterprise application integration (EAI); web service; extraction, transformation and loading (ETL) V

Table of Contents ABSTRATTO... I 摘 要... III ABSTRACT... IV CHAPTER 1 INTRODUCTION... 1 1.1 BACKGROUND... 1 1.2 THE PURPOSE OF PROJECT... 2 1.3 MAIN CONTENT AND ORGANIZATION OF THE THESIS... 4 1.3.1 CRM process module enhancement... 4 1.3.2 System coordination and integration... 6 1.3.3 Customer data processing and analysis... 6 1.4 THE WORKLOAD OF PROJECT... 7 CHAPTER 2 PROJECT FOUNDATION AND STATE OF ART... 9 2.1 DESCRIPTION OF CRM SYSTEM... 9 2.1.1 Introduction of CRM system... 9 2.1.2 Architecture of CRM system... 9 2.1.3 Introduction of Siebel CRM system... 12 2.2 DESIGN OF CRM PROCESS... 15 2.2.1 Define customer lifecycle... 15 2.2.2 Design of CRM... 18 2.3 COORDINATION OF CRM SYSTEM AND BI SYSTEM... 20 2.3.1 Introduction of ETL... 20 2.3.2 Traditional EAI vs. Web Service... 23 2.3.3 Relationship between CRM and BI... 30 CHAPTER 3 SYSTEM REQUIREMENT ANALYSIS... 32 3.1 THE GOAL OF THE SYSTEM... 32 3.2 THE FUNCTIONAL REQUIREMENTS... 32 3.2.1 CRM process module enhancement requirements... 32 3.2.2 System coordination and integration requirements... 47 VI

3.2.3 Customer data process and analysis requirements... 51 3.3 THE NON-FUNCTIONAL REQUIREMENTS... 52 3.4 BRIEF SUMMARY... 53 CHAPTER 4 SYSTEM DESIGN... 54 4.1 BRIEF DESCRIPTION OF SYSTEM DESIGN... 54 4.2 FUNCTIONAL SPECIFICATION AND USER INTERFACE MOCKUP... 54 4.2.1 Sales... 54 4.2.2 Entitlement... 62 4.2.3 Migration from DTH/Cable to Internet... 63 4.2.4 Migration from Internet to DTH/Cable... 70 4.2.5 Automatic upload in campaign... 76 4.2.6 Package upgrade/ downgrade/ change... 76 4.2.7 Data change... 76 4.2.8 Revocation, Cancellation and Revocation of Cancellation... 77 4.2.9 Generate report... 79 4.3 TECHNICAL SPECIFICATION... 79 4.3.1 Sales... 79 4.3.2 Entitlement... 86 4.3.3 Migration from DTH/Cable to Internet... 87 4.3.4 Migration from Internet to DTH/Cable... 89 4.3.5 Automatic upload in campaign... 90 4.3.6 Revocation, Cancellation and Revocation of Cancellation... 92 4.3.7 Generate report... 92 4.4 KEY TECHNIQUES... 97 4.4.1 Siebel customization... 98 4.4.2 System integration... 100 4.4.3 Customer data processing and analysis... 101 4.5 BRIEF SUMMARY... 102 CHAPTER 5 SYSTEM IMPLEMENTATION AND TESTING... 103 5.1 SYSTEM STRUCTURE... 103 5.2 KEY PROGRAM FLOW CHARTS... 104 5.3 KEY INTERFACES OF THE SOFTWARE SYSTEM... 109 VII

5.4 SYSTEM TESTING... 112 5.4.1 Sales... 112 5.4.2 Entitlement... 115 5.4.3 Migration process from DTH/Cable to Internet... 116 5.4.4 Migration process from Internet to DTH/Cable... 118 5.4.5 Automatic upload in campaign... 121 5.4.6 Package upgrade/ downgrade/ change... 121 5.4.7 Data change... 122 5.4.8 Revocation, cancellation and revocation of cancellation... 122 5.4.9 Generate report... 124 5.5 BRIEF SUMMARY... 125 CONCLUSION... 126 REFERENCES... 127 ACKNOWLEDGEMENT... 132 RESUME... 133 VIII

Number of customers Thesis for Master s Degree at HIT and UP Chapter 1 Introduction 1.1 Background SMedia is a famous international media company which operates a direct broadcast satellite and cable pay TV platform in Germany and Austria with a great number of subscribers and very high frequency of customer interaction. According to this two factors, the position of SMedia is shown as Figure 1-1 [1]. Insurances Health care Retailers Public Sector Media TV Content Provider Utilities Finance Telecom Commodities Automotive Transportation Pharmacy High Technology Figure 1-1 The position of SMedia In any case, customers are key and critical resources to compete and grow shareholder value. Increasing the quality of customer care is always what SMedia is chasing for so that it can lead to final profit. So it followed the suggestion and started its Customer Relationship Management System project with company DConsulting (DC). The latter has rich experience in that area and has helped SM e- dia to build a powerful CRM system based on Siebel, which is a product of Oracle. DC configured and customized Siebel to satisfy the business requirements of SM e- dia. And currently the CRM system is running normally and helping SMedia a lot to deal with complicated daily business including sales management, marketing ma n- agement, customer contact center service, field service and supply chain. 1

1.2 The purpose of project Thesis for Master s Degree at HIT and UP As mentioned above, SMedia is a big media company which runs in an open market with a large amount of customers and has to deal with high frequency of interactions every day. Currently, it offers a collection of basic and premium digital subscription television channels of different categories only via Direct-To-Home (DTH) signals of Direct Broadcast Satellite and Cable Television. And it has no cooperation with DTelecom. DTelecom (DT) is a major German telecommunications company which enables their customer to watch content over IPTV. SMedia is intending to enlarge its market. So it plans to start a cooperation with DT and hope to get a win-win consequence. The name of this cooperation project is called SMedia@Entertain (SE). In scope of the cooperation with SMedia, DT is going to deliver Bundesliga Service of SMedia to their Liga Total customers as well as any SMedia content for Entertain customers for the cooperation term of next four years. To SMedia, the target of this cooperation is that it can provide all its content (all current packages and HD service) via the IPTV network of DT with following constraints: 1) Same pricing / packaging as SMedia product via Cable / DTH 2) SMedia national promos being enabled also for DT IPTV platform 3) SMedia being owner of end-customers relationship ( retail deal ) And there are also some benefits supposed to be achieved when this cooperation is running successfully: 1) Increase of net sales through additional subscriptions based on the cooperation with DT 2) Introduction of a new platform for SMedia customers 3) The existing SMedia customers can benefit from SE bundle as they need only one set-top box (STB) for both contents. So the current CRM system cannot meet the new requirements. It has to be modified and configured to add related support to incoming cooperation between SMedia and DT. On the other hand, both SMedia and DT want to know how the cooperation works. They would like to understand the situation of this new program, such as how many customers choose this offer and how they are distributed. So there should also be some new processes included to process and analysis the customer data of SE contracts. 2

Currently, there is no CRM process to handle the sales and migration processes for SE contract which will be introduced by this new cooperation. And when this project is finished, there should be two new processes implemented. The new processes can be referred to Figure 1-2 and Figure 1-3 which are illustrated by CRASO diagram. CRASO stands for Customer, Request, Activities, Organizations and Outcome, which are elements of business process. [2] Customer Apply for subscription Collect customer s information Create contract record Evaluate customer s risk profile Prepare HW Entitle Deliver media content Perform other checks Front-end CRM Risk Management System DT SMC Management System Figure 1-2 CRASO for new sales process Customer Apply for migration Perform checks Input required information Change entitlement Send Letter Change record Start new contract CRM CSR SMC Management System Letter Management System Figure 1-3 CRASO of new migration process And by describing the design and implementing of this project, I want to give the discussion and solution for two major problem. One is how to design a customer relationship management process and use CRM system to maintain the customer relationship, especially for a cross-company cooperation. The other one is how to integrate the different systems inside and outside the company. And an example of the communication between CRM system and BI system will be introduced. 3

1.3 Main content and organization of the thesis The main content of this thesis can be divided into two parts briefly. The first part is the literature review of CRM system. The second part will describe the CRM process module enhancement project in detail. In the first part, there will be an introduction of CRM system, including history, typical architecture and usage. Especially, considering the situation of this cooper a- tion case, the design and usage of customer relationship management process across different organizations, economical firms in this very case, will be discussed. And another key point is the integration between CRM system and other systems. The examples will be presented in this thesis are the communication between CRM system and BI system and that between CRM system and DT. In the second part, all the technical detail of this project will be explained, including the business requirements, design of the system, and the final implementation and testing work. By introducing this specified project, a real example of the situation discussed in the first part will be suggested. And in this CRM process module design and implementation project, there are mainly three parts of requirements, which is CRM process module enhancement, system integration and customer data processing and analysis. 1.3.1 CRM process module enhancement The task of this part, is to configure and customize current CRM system to support new CRM processes of the cooperation between SMedia and DT. And the processes need to be considered can be divided into following four parts: 1) Adaption of entitlement Currently, the entitlements are processed over Smartcard Management System, an external system. Siebel send required messages, including the serial number of customer s smartcard (SMC), to Smartcard Management System, the latter will fi n- ish the rest procedure to complete customer entitlement. Assuming that the entitlements of SE customers will still be processed following this procedure, the activ a- tion and sending of entitlements have to work like now. Since there is no SMC for SE customers, instead of using SMC serial number as unique identifier, the encoded Telecom Online ID (TOID) of customers should be used. 2) Process to migrate current SMedia customers with DTH/Cable to SE and vice versa 4

The receiver of SE is just Internet, while current SMedia offers are using Cable or DTH. Since the type of receiver is quite different between SE and current offers, if current SMedia customers want to change their contracts, it may cause some problems. Generally, there can be two kinds of scenarios: a. Current customer wants a new SE contract b. Current customer wants to change his current SMedia contract to SE And these two different workflows should be maintained properly. So current CRM system should be modified and updated to support these workflows. And the requirement condition is quite similar to the opposite situation. 3) Adaption of the current processes so that they also can be used by contracts that have an encoded TOID As mentioned above, most of current processes need SMC serial number to maintain contracts and offer services since it is a unique identifier of customer and related contract. But in SE situation, there is no such kind of things. But the cu s- tomers of SE have TOID assigned by DT, because they are already customers of DT s IPTV service. And TOID can also uniquely identify customers. So all current processes have to be modified to add the support of the contracts which have and encoded TOID. 4) Recognition of SE customer in Web and IVR IVR stands for Interactive Voice Response. It is used to support customer self-care service. Customers can make a phone call and follow the invoice instructions to complete required operations. SE customers should be enabled to identify themselves on the IVR with their customer number. This step is especially i m- portant for the main portal, but should work on any other IVR as well. It needs to be checked how the identification process can be performed without a smartcard nu m- ber. And currently, the IVR service is organized by an external system that gets the customer information and routes the customer according to his needs. Siebel will not take initiative to communicate with IVR system. But in contrary, it will enca p- sulate related functions into a web service [3] to allow IVR system to call it when necessary. So IVR system should be enabled for SE customers without a smartcard as well. 5

1.3.2 System coordination and integration As mentioned above, CRM system is not an isolated system, not a data island. It has to cooperate with other systems to perform its function and achieve the final goal. In this very case, there are so many systems which should be coordinated properly to work. So it is a really complex but essential process to integrate CRM system with other systems, not only focus on linear process but also data integration, especially that CRM system is regarded as a core of IT part of business process. Since different processes are handled by different systems which are supplied and maintained by different organizations, they may be implemented using different language, different technologies and running on different machines, different pla t- forms. It is difficult to integrate them together in a traditional way. So using an E n- terprise Application Integration (EAI) technology is quite necessary to achieve the goal. And traditional EAI mechanism is a kind of tightly coupled model, and the result of that is that it is not conductive to the readjustment and reorganization of enterprise business process, it is lack of scalability and flexibility, while web se r- vice is a kind of standardized solution with loosely coupled but lower performance [4][5]. So by introducing web service related standards and enabling technol o- gies, EAI can realize service layer oriented. And the EAI combined with web service can realized such a kind of EAI system which is loosely coupled and ma ximize its ability of performance and flexibility at the same time [5][6]. So one focus point of this project is to coordinate and integrate the enhanced CRM process module to other existing systems to support each other to complete all kinds of processes. 1.3.3 Customer data processing and analysis Since this is a totally new cooperation for both side, SMedia and DT, the managers of both side definitely would like to know how everything goes. So there has to be a new function module which can handle this issue and generate report to show the stage of this new cooperation. And the raw data is a completely mess with a large volume. It should be processed firstly to get organized useful data which will require ETL technology and proper data mining methods. Then an intuitive and user friendly report should be generated for managers. 6

1.4 The workload of project Thesis for Master s Degree at HIT and UP The whole project involves two phases. Some emergency functions will be implemented firstly, and the deployed at the end of June, so that the cooperation can be started from July. And then, some other processes will be finished one month later. The schedule of the whole project can be referred to Table 1-1. Table 1-1 Schedule of the project Start Date End Date Content of Plan April 5 th, 2013 April 22 nd, 2013 Requirement Analysis and Feasibility Analysis April 23 rd, 2013 May 10 th, 2013 System Design of Phase I May 13 th, 2013 June 7 th, 2013 System Implementation of Phase I June 10 th, 2013 June 24 th, 2013 User Acceptance Testing of Phase I June 25 th, 2013 June 26 th, 2013 System Deployment of Phase I June 10 th, 2013 June 21 st, 2013 System Design of Phase II June 24 th, 2013 July 5 th, 2013 System Implementation of Phase II July 8 th, 2013 July 19 th, 2013 User Acceptance Testing of Phase II July 23 rd, 2013 July 25 th, 2013 System Deployment of Phase II As the schedule mentioned above, the first period is to analysis business requirements with SMedia and work out the feasibility report. The purpose of the second period is to design the system architecture according to the define d requirements and make system design document which defines all the flows of functions and interfaces of the system. The third period is to implement the system following the instruction of design specification. Then the system should be tested properly following the specified CRM processes. The final step is to deploy the system at SMedia side and deliver all related documents. The whole plan can be r e- ferred to the Gantt chart shown in Figure 1-4. 7

Figure 1-4 Gantt Chart of the whole project 8

Chapter 2 Project Foundation and State of Art 2.1 Description of CRM system 2.1.1 Introduction of CRM system CRM, stands for Customer Relationship Management, is a model for managing a company s interactions with current and future customers. It involves using technology to organize, automate, and synchronize sales, marketing, customer service and technical support [7] that aims to increase customer satisfaction, loyalty and value. The history of CRM is shown as Figure 2-1. Sales Force Automation ERP Integration Internet Customer Sales and Support (CSS) Call Center Automation Customer Dynamics Marketing Automation CRM E-Sales E-Marketing E-Service 1985-1990 One or two CRM providers emerge 1995 Emergence of integrated from office suites 9 2000 CRM becomes accepted term Figure 2-1 History of CRM Today Internet forces customer issues to the boardroom CRM systems support customer management processes throughout all phases of marketing, sales and service, optimizing efficiency and effectiveness. And the objectives of each process are shown as Table 2-1. 2.1.2 Architecture of CRM system To achieve the goals, CRM system must fully manage customer interactions across all channels and touch points in a consistent and coherent way. The challenge is to develop an integrated CRM platform that collects relevant data input at each customer interface and simultaneously provides knowledge output about the strategy and tactics suitable to win customer business and loyalty [8]. By receiving and analyzing customers responses from multiple contact channel, such as call center, Internet, field sales and so on, the company which has deployed CRM system can

understand and operate customer care better, so that its sales department can expand the market scale and its marketing department can make more accurate marketing strategy [9]. The normal architecture of CRM system is shown as Figure 2-2. Table 2-1 The objectives of CRM system processes Process Marketing Objectives Market and customer analysis and assessment Marketing strategy development Products and services strategy development Customer leakage reduction Increase margin per product and/or customer Customer loyalty program execution Assign and manage customer value Customer incentive strategy development Sales Sales or usage trends tracking of profitability of each product bundle Product-matching based on current demand levels as measured by current sales trends Product mix optimization models development to suggest which products best match together Customer feedback gathering of existing and potential products and functionalities through market research Service Logging, routing and tracking of customer-reported issues, problems, and complaints through resolution Prioritization and escalation of customer requests Product and service contract and warranty support Customer self-service and direct support across multiple interaction channels Parts replacement management and Field Technicians dispatch 10

Back end Front end Channels ETL Thesis for Master s Degree at HIT and UP Customer & Prospects Operational CRM Call Center Reps Web Site & E-mail Partner Field Reps Fax & Mail Analytical CRM Marketing Automation Sales Automation Service Automation Customer Insights & Reporting CRM DB Service Mktg Enterprise Application Integration Sales Pricing/... Billing Credit Mgmt Contract Mgmt Other Applications Federated Data Mart DB Pricing Mgmt DB... Enterprise Data Warehouse Figure 2-2 CRM Architecture Of course, the necessary first step to complete CRM solution is the constru c- tion of a customer database or information file [10]. The Operational CRM gathers information via multiple channels. It cooperates with back-office and legacy applications to support front-office, which has always been considered synonymous of CRM. But when considering the entire customer lifecycle, the distinctions between front-office and end-office are disappeared, since they are both elements of an overall customer-facing system. The components of the Operational CRM consist of the user application view, the business process view and the organization view [11]. The Operational CRM organizes operational database, which stores normalized data and is optimized for transactional operation including insert, update, delete, small query and so on. And there is no aggregated or derived data stored in operational database. It calculates summary information on-the-fly. Then after ETL procedure, which stands for Extract, Transform and Load, the data becomes denormalized and stored in Enterprise Data Warehouse (DWH). The data stored in DWH has already been optimized for huge query. And it can use Dimensional Fact Model (DFM) [12] to graphically present the concept. Facts tables store business measures, and dimensions control how data can be categorized and presented to the user [12] [13], which is what Analytical CRM does. The Analytical CRM takes the mass of relationship data throughout the relational enterprise and puts it into a form that can be used to add proactive value. A variety of multivariate 11

statistical methods ranging such as cluster and discriminant analysis have been used to group together customers with similar behavioral patterns and descriptive data which are then used to develop different product offerings or direct marketing campaigns [14]. After that, it uses reporting tools to generate intuitive dashboard of customer insights and reporting. The structure of this procedure can be r eferred to Figure 2-3. The components of the Analytical CRM consist of the user application view, the analytic process view and the decision structure view [11]. Presentation Layer (Database or Flat File) Logical Layer Metadata (Database or Flat File) Browser Configure Tool Physical Layer (Database) HR CRM Finance Operational Systems Figure 2-3 The architecture of DWH 2.1.3 Introduction of Siebel CRM system Siebel was mainly known for sales force automation products at first, then it expanded into marketing and customer service applications, the broader C RM market. And the late 1990s, Siebel Systems was the dominant CRM vendor, peaking at 45% market share in 2002 [15]. Then it was acquired by Oracle in the year of 2005. Now, according to the statement of Oracle, Siebel is the world s most complete CRM solution. It delivers a combination of transactional, analytical, and engag e- ment features to manage all customer-facing operations to help organizations di f- ferentiate their businesses to achieve maximum top-and bottom-line growth [16]. Siebel CRM is typically deployed as a single application with broad functio n- ality and supports multiple communication channels. Technically, it uses a single database to allow all users access to the same set of data and ensure changes to data 12

are made once and only once. A typical Siebel Web architecture is shown as Figure 2-4 [17]. Siebel Web Client Enterprise Server Web Server Siebel Gateway Name Server Siebel Server(s) Database Server Siebel File System Figure 2-4 Siebel Web architecture At a high level, the Siebel Web architecture consists of: 1) Siebel Web Clients that access and display the business data 2) A Gateway Name Server that stores configuration information 3) A Web server that handles interactions with the Web Clients and distributes requests to the Siebel Servers 4) Servers that manage the business data and provide batch and interactive services for clients 5) A relational database and file system that store business data In a physical view, the Siebel Gateway Name Server, Siebel Server, database server, and File System can be implemented on one machine or spread across mu l- tiple machines. And the Siebel Server(s) should have a high-speed LAN connection to the database server. The physical architecture of Siebel Web can be referred to Figure 2-5. Siebel applications use common business entities during CRM operations. A business entity is something of business interest in the real world. And Siebel a p- plications refer to these business entities as business components. Table 2-2 shows some business components which are keys to CRM process and used quite frequently. 13

Siebel Gateway Name Server Enterprise Server High-speed LAN Siebel Server Firewall Web Server Firewall Siebel File System Siebel Server Database Server Figure 2-5 Physical architecture of Siebel Web Table 2-2 Examples of Business Components Name Accounts Description Are businesses external to your company Represent a current or potential client, a business partner, or a competitor Are associated with a team Contracts Are people with whom you do business Can be public or marked as personal Are associated with a team (public contacts) or a user (personal contacts) Opportunities Are potential revenue-generating events Have the following characteristics: o A possible association with an account o A probability of completion o A close date Are associated with a team 14

Continued Table 2-2 Name Service Requests Description Are requests from customers or prospects for information or assistance with your products or services Have the following characteristics: o A status o A severity level o A priority level Are associated with a single owner Assets Are instances of purchased products Have the following characteristics: o An asset number o A product and part number o A status level 2.2 Design of CRM process 2.2.1 Define customer lifecycle CRM can be defined as a set of tools, processes and technologies which intends to help a business to attract, retain and develop high-value customers. And there are two key concepts, or can be regarded as two laws of CRM, identifying the high value customers and the management of entire customer lifecycle from entry into relationship, and departure. [18] In the area covered by cusomter relationship management, customer lifecycle is a terminology which is used to describe the progression of steps that a customer goes through from considering, purchasing, using and finally to a maintaining loyal status to a product or service. At the core of customer relationship management is the development and maintenance of long-term relationship with customers, rather than simply a series of discrete transactions, achieved by creating superior customer value and satisfaction. The curve in Figure 2-6 illustrates the customer lifecycle profit. [19] 15

Figure 2-6 Accelerating profit per customer Continuous cash flows And there are different stages in customer lifecycle with various methods to define them [20]. It is necessary to define, characterize and categorize the current and anticipated future status of customers in terms of acquisition, retention and profitability. And Figure 2-7 shows a flowchart of the method for categorizing a customer relationship, according to an embodiment of an invention [21]. Market analyst Jim Sterne and Matt Cutler developed a matrix that breaks the customer lifecycle into five distinct steps: reach, acquisition, conversion, retention and loyalty [22]. The lifecycle model of Sterne and Cutler can be referred to Figure 2-8. In this model of customer lifecycle, each phase is described as following. 1) Reach: refers to the potential to gain the attention of target people. Its goal is primarily one of awareness, i.e. let your target market aware what you are selling. 2) Acquisition: attract and bring the reached person into the influence sphere of the organization. Its goal is customer participation. 3) Conversion: is looked at as the point at which a sale has been made and the prospect has been converted into a customer. But, in the online area, depending on the goals of the particular site, it can have varieties of meanings. 4) Retention: means taking every effort to secure a purchase order now into an investment in encouraging repeat purchases. 5) Loyalty: the customer becomes more than a customer, who are not only loyal to products but also loyal to company. They are willing to promote your firm and even act as references to other prospects. 16

A proactive CRM should look at the entire customer experience from the advertising, which is customer s first hearing about the company, to post -sales service, even what they say about the company once they have left. Select customer(s) to be CATEGORIZED Network Select LIFECYCLE measure: Number of orders; Quantity of purchase or revenue, for example Customer Transaction Database Select LIFECYCLE calculator period: Month; Quarter; Semi-annual or Year Select first LIFECYCLE period (e.g. Specific month) Select comparison method: Period over period or Year over year by period Compute LIFECYCLE factor (LCF) LCF = (Absolute measure difference) * (Percentage measure growth) Define criteria for each LIFECYCLE stage (e.g., New; Growing; Stable; Declining; Defected and Insignificant...) Selectively apply criterion to selected customer(s) to CATEGORIZE customer(s) Figure 2-7 Flow chart of a method for categorizing a customer relationship 17

2.2.2 Design of CRM Figure 2-8 The customer lifecycle from introduction to loyalty Several scholars studying buyer-seller relationships have proposed relationship development process models. Building on that work, Atul Parvatiyar and Jagdish N. Sheth developed a four-stage CRM process framework which is comprised of four sub-processes [8] : 1) A customer relationship formation process The formation process refers to the decisions regarding initiation of relational activities for an organization with expectation to a specific group of customers or to an individual customer which the company wishes to engage in a cooperative or collaborative relationship with. 2) A relationship management and governance process Once a CRM program is developed and rolled out, the program must be ma n- aged and governed. So are the individual relationships. Several issues must be a d- dressed no matter the responsibilities of management and governance process are independently or jointly undertaken by relational partners. 3) A relational performance evaluation process In order to evaluate if the programs meets expectations and if they are su s- tainable in a long term run, periodic assessment of results in CRM is needed. And performance evaluation also helps in taking corrective action in terms of relatio n- 18

ship governance or in modifying relationship marketing objectives and program features. 4) A CRM evolution or enhancement process The customer relationships with individuals, and CRM programs are likely to suffer evolution as they mature. Some evolution paths may be planned in previous stage while some others evolve naturally. Figure 2-9 describes the important components of the process model. Figure 2-9 A CRM process model As mentioned above, CRM is regarded as a combination of tools, processes and technologies. In Patrick Lambe s opinion, both the law of CRM and main activities are infused by the use of two tools, technology and knowledge management. [18] About the technology part, Hee-Woong Kim proposed a process model for successful CRM system development. [23] He classified factors into five groups: 1) Organizational commitment It refers to the company s supporting activities and factors for target system development. 2) Project management It includes the project team and managing activities. 3) Strategy and process 19

It factors express the target information system (IS) s strategic direction and business and functional processes. 4) Technology It implies system design and realization activities. 5) Consequences It refers to the results of system development. Figure 2-10 shows the process model with specifying important process factors, their sequence and the relationship among them. Figure 2-10 An IS development process In the past time, a lot of CRM writing focuses on technology applications, but now the critical role of knowledge management begins to be recognized. Figure 2-11 illustrates the dimensions of knowledge in CRM. 2.3 Coordination of CRM system and BI system 2.3.1 Introduction of ETL ETL stands for Extraction, Transformation and Loading. It is an architecture pattern used in data integration and SOA area [24]. ETL is responsible for retrieving the data like relational data and flat data files from outside heterogeneous data sources to a temporary middle layer, then following a serial process of cleaning, transformation and integration. Afterwards, it loads the data into data warehouse or data marts and let it become the basis of online analytical processing (OLAP) and data mining. 20

Figure 2-11 Four dimensions of knowledge in CRM It is a very important part of data warehouse. It is a necessary step to link between past operations. Comparing to relational database, the technology of data warehouse doesn t have a strict mathematical theory basis. It is more practical engineering application oriented. So from the point of view of engineering application, loading and processing the data following physical data modeling is related to e x- perience. And this process will directly affect the quality of the data in data warehouse, and thus affect the quality of OLAP and data mining result. The word of ETL is quite often appeared in data warehouse related technology, but the operating objects of ETL are not limited in data warehouse domain. Intuitively, an ETL process can be thought of as a directed acyclic graph, with activities and record sets being the nodes of the graph and input-output relationships between nodes being the edges of the graph [25]. The ETL processes can be illustrated as what Figure 2-12 shows [26]. 1) Extraction It is the first part of an ETL process, which involves extracting the data from the source systems. Since the correctness of extracting data decides how su bsequent processes can go further, this step is often considered to be the most cha llenging aspect of ETL. The source systems are often separated and may use different data organizations or formats. And normally, ETL process use an intermediate data storage to store the result of each step. But it can also be implemented in a strea m- ing way which extracts data source and loads on-the-fly to the destination database. 21

In general, the purpose of this extraction phase is to convert various data into a si n- gle format which satisfies the transformation processing needs. Operational sources Extraction, Transformation, Loading Extraction Integration Aggregation Data warehouse Schema extraction and translation Schema matching and integration Schema Implementation 1 2 3 4 5 Data Staging Area Data warehouse Instance extraction and translation Instance matching and integration Filtering, aggregation Scheduling, logging, monitoring, recovery, backup Legends Metadata flow Data flow 1 3 Instance characteristics (real metadata) 2 Translation rules 4 Mapping between instance and target schema 5 Filtering and aggregation rules Figure 2-12 Steps of building a data warehouse: the ETL process 2) Transformation The transformation stage uses a sets of rules or functions to perform some operations on the extracted data from first phase and then export the data for loading into the final target. And depends on different scenarios, the manipulation can be a lot or very little even nothing need to do. And the required transformation types can be selecting only certain columns to load, translating coded values, encoding free-form values, deriving new calculated values, sorting and so on. 3) Loading The task of loading phase is to load the processed data into final target, usually the data warehouse. And depending on the different requirements of different o r- ganizations, this process may vary quite widely. Some data warehouse may need to overwrite existing information with cumulative one each time. And the frequently updating extract data will be done on daily, weekly or monthly basis. While some other data warehouse, or even other parts of the same data warehouse, may append new incoming data to a historical form. And since this phase interacts with a data- 22

base, the constraints defined in the database schema will apply on it also, which will affect the overall data quality. 2.3.2 Traditional EAI vs. Web Service Standing on a view of the whole company IT architecture, CRM system is just one part of the whole big system which supports all the running tasks of company s business. So it should be integrated to cooperate with other systems to finish all transactions. The goal of enterprise integration is to make organizations to become more agile and flexible. And agility and flexibility are described as the ability to continuously monitor market demand; quickly respond by providing new p roducts, services and information; quickly introduce new technologies; and quickly modify business method by Nagel and Dove. [27] The software and hardware integration, which also called technical integration, is only one aspect of integration [28]. The biggest challenge may be the behavioral integration. [29] Two of most popular integration technologies, EAI and web service, will be introduced and compared. 2.3.2.1 Introduction of EAI EAI, which stands for enterprise application integration, is an integration framework composed of a collection of technologies and services. It is a business computing term for a combination of plans, methods and tools aimed at modernizing, consolidating and coordinating the overall computer functionality in an enterprise. And in a technical view, EAI solutions generally include following integr a- tion methods. [5] [30] [31] 1) Message-oriented middleware (MOM) MOM products provide connectivity between applications by message passing. All the messages are sent to a queue and then will be forwarded to the destination application for further processing. This method is known as store-and-forward messaging. 2) Application servers This method also provides connectivity between applications, but compared to MOM, the client sends a request directly to a server and waits for the server to r e- spond, instead of using a message queue. So this method is known as request/response. 3) Adapters 23

Nowadays, most EAI solutions provide standard connectors for the most common packaged applications and databases. These adapters reduce much of the manual coding required to map data formats and object models between applications. 4) Adapter development frameworks The adapter development frameworks are enhancements of previous simple adapters, which are tools that allow developers to build adapters into applications where a standard adapter does not exist or where a large amount of customization of the packaged application is demanded. 5) Workflow and process management tools One of the key principle of EAI is that transaction process should be executed automatically. Workflow and process management tools allow the developers to define, implement, test and monitor transaction flow which associates with specific business processes. Figure 2-13 shows the comparison between EAI integration and traditional integration. Web Applications Application Servers Web Applications Web Applications Integration Middleware Legacy Applications Database Systems Legacy Applications Legacy Applications EAI Integration Traditional Integration Figure 2-13 EAI integration vs. traditional integration An advantage of EAI solution is that it can be presented in various forms of various levels. An appropriate level of EAI depends on many factors, including company size, the industry category, the application integration degree, or the com- 24

plexity and budget of the project and so on. [32] And in general, the integration of EAI solution includes mainly four levels [5][29] : 1) Integration of data layer The goal is to expand traditional data integration within a common framework. It happens in the level of database and data source inside the enterprise. It means to achieve the orientation and transmission of the data used by application via extraction and related transformation process of integrated data, i.e. ETL solution. Data integration is the most common way of EAI solutions. 2) Integration of application layer It means to link business processes and data at the application interface layer. The framework uses the technologies like communication messages, API and so on to make applications interact and integrate at application layer. Normally, this method is usually used in a synchronous mode, which is based on the request/response mechanism in C/S or B/S structure. The schematic diagram of this level s EAI can be referred to Figure 2-14. Request API Java RMI CORBA DCOM RPC... Application A Response Application B Figure 2-14 Application layer integration 3) Integration of business logic layer It means to share business logic throughout the enterprise at the component level. Although data integration has been proved to be a popular way of EAI. However, data integration still exists many problems if we focus on security, data 25

integrity and business process. The EAI solution in this layer will use distributed business objects and reusable component technology in or der to deploy and integrate business process to satisfy the requirements of business processes of enterprise. A higher level explanation of an open business process can be referred to Figure 2-15. Open Business Process Application A Application B Figure 2-15 An integration based on open business process 4) Integration of user interface layer EAI solution can leverage the user interface as the basis for integration. This technology can use a simulation way, for example, to simulate the key pressing of users to communicate with legacy systems, to access existing applications via user interface or I/O point. It is a kind of user-oriented integration. It maps the original termination to a standard user interface. This could be very useful to the legacy systems or proprietary systems which do not have other I/O, such as have no APIs or cannot access data, yet needed to be integrated. 2.3.2.2 Introduction of web service According to the definition of World Wide Web Consortium (W3C), which is the main international standards organization for the World Wide Web, A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable 26

SECURITY Base Technologies: XML, DTD, Schema Base Technologies: XML, DTD, Schema MANAGEMENT Thesis for Master s Degree at HIT and UP format (specifically WSDL). Other systems interact with the Web service in a ma n- ner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [33] The design work of web services can be divided into two parts, the run time protocols and the descriptions of services [34]. About the run time protocol, a web service is normally based on HTTP transport of XML-encoded messages, using the Simple Object Access Protocol (SOAP), which is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment [35]. In one mode, the XML message is used to encode the parameters to call a remote operation in a way which is quite the same as remote method invocation in. In the other mode, SOAP will carry an XML document, and the task of the receiver is somehow regarded more as a document processing operation. And the latter one is getting the most traction in the ecommerce stack. About the descriptions of services, they are made at quite various different models and different levels of abstraction in different specifications proposed as part of the stack. But there is still an agreement on Web Service Definition Language (WSDL) as the modeling of the lowest level which describes the message or request/response interaction and the binding to the specific HTTP port at which it happens. WSDL is an XML format description language used for describing network services as a set of endpoints operating on me s- sages containing either document-oriented or procedure-oriented information [36]. And the architecture stack of web service can be referred to Figure 2-16. Processes Discovery, Aggregation, Choreography... Descriptions Web Services Descriptions (WSDL) Messages SOAP Extensions Reliability, Correlation, Transactions SOAP Communications HTTP, SMTP, FTP, JMS, IIOP,... Figure 2-16 Web Service Architecture Stack 27

Just as mentioned above, web service architecture involves many layered and interrelated technologies. So there can be many ways to present these, just like there are many ways to establish and use web services. And Figure 2-16 is just one illusion of these technology families. In generally, the process of engaging a web service can be roughly described as following steps: 1) The requester and provider entities become known to each other a. Service provider publishes the web service description (WSD) and functional description (FD) to a discovery service. In fact, it doesn t care how the discovery service obtains the WSD and FD. The discovery service can be implemented as a search engine, then it can seize the web and collect what it needs automatically, while there is no need for service provider to have knowledge about it. And the discovery service can also be implemented as a service registry, such as Universal Description Discovery & Integration (UDDI), which focuses on the definition of a set of services supporting the description and discovery of web services and their technical interfaces [37], then the service provider may need to publish WSD and FD actively directly to the discovery service. b. The requester entity, or called Service Consumer, consults the discovery service to select a WSD according to its associated FD, capabilities and, potentially other characteristics. c. The discovery service then returns one or more WSDs which satisfy the specified requirements of requester. If several WSDs are returned, the requester will select one based on additional criteria. 2) The requester and provider entities have an agreement on the semantics of the desired interaction. Commonly, it is decided by the provider entity. The latter one often defines the semantics and offers them on a take-it-or-leave-it basis to the requester entity. But the goal of this step can be also achieved in other ways. For example, both sides will follow the same rules which defined by some industry standards. Or in some case, the requester may have the opportunity to define the semantics. But all in all, the most important point is that, both parties must agree on the semantics, regardless of how that is achieved. 3) The requester inputs the WSD and semantics to, or embodies in the requester agent. And so does the service provider. 28

4) The requester and provider interact with each other via exchanging their SOAP messages between their agents. The process described above, can be referred to Figure 2-17. Criteria 1.b Requester Entity 1.c WSD Discovery Service 1.a. FD + Provider Entity WSD 2. 2. Sem Requester Human Provider Human + 3. 3. + Sem WSD Sem WSD Requester Agent Interact 4. Provider Agent Figure 2-17 The general process for engaging a web service With the help of web service, the applications running on different machines can directly exchange data or integrate without an additional specific software or hardware from third party. And the applications implemented following web service standard can directly communicate with each other, no matter what language, pla t- form or internal protocol they use. And because they are based on some normal industry standards and existing technologies, like XML and HTTP, web services are easy to deploy and reduce the cost of application interfaces. All in all, web service supply a general mechanism for the business processes integration of an entire company or even among many organizations. 2.3.2.3 Comparison between traditional EAI and web service Like Johanna Ambrosio said, EAI and web services are different answers to the same problem. [31] The differences between these two technologies are as following [5]. 29

1) Different function scope EAI more focuses on the purpose of enterprise application integration. It just takes care of how to combine different kinds of methods, technologies and tools. It doesn t force to use specified technologies and methods. It can covers a wide range of enterprise application integration topic. Different from EAI, web service cares on a specific area. It offers a standard and independent way to solve the problem facing on World Wide Web. And because of its own standard, it can achieve the technology independence of web service implementation. So comparing to other methods, web service has a better flexibility and adaptability. 2) Different integration layer Just like discussed above, EAI can support four layers, i.e. data, application, business logic and user interface, while the integration of web service is based on service layer. It uses object-oriented technology to wrap data and access different web applications via SOAP. And of course, both of them have their own pros and cons. To web service, it has a much better ability to solve the problem cross-platform and satisfy the distributed systems requirements because of its usage of object-oriented and XML related technologies. But since it is a loosely coupled integration mode, the performance is poorer and lack of communication ability with database. And to EAI, its final goal is to offer a unique data exchange center for existing applications. There is no limitation of the integration method to be used. So that it can support a wide scope of integration. Developers can choose different integration method and tools according to different applications, which means it can realize an integrated system with good performance. But most of them are in tightly coupled mode, so that it is hard to be maintained and updated, and lack of extensibility and flexibility. 2.3.3 Relationship between CRM and BI Business intelligence systems combine operational data with analytical tools to present complex and competitive information to planners and decision makers. [38] And BI can be defined as the process of turning data into information and then into knowledge. [39] One of the data source is operational CRM. But in general, CRM is a broader concept than BI. [40] Julie Hall said that within the context of CRM, business intelligence is the process of leveraging detailed cu stomer-behavior infor- 30

mation to best manage relationships for maximum customer satisfaction, loyalty, retention and profitability [41]. This definition basically addresses the fact that BI s function of using data to make predictions is synonymous with the analytical CRM stage of data analysis used for marketing and customer-centric decisions. However, when we talk about CRM, we usually mean operational CRM. Nowadays, most enterprises connect CRM applications with BI systems to satisfy customer requirements and ensure their loyalty. CRM system provides source data to BI system. BI system will give back an operable insight. By possession of full information about all transactions and customer s experience, companies can increase t he delivered value. The key of BI success is data. The more data you have the more analytical processes you can apply and the more analytical processes available, the more information you can extract from the data. And which will lead to the better function. [42] But if the data of CRM hasn t been optimized to the level which BI system requires, the latter would be inefficient and not effective, that is what Garbage In, Garbage Out says. Once CRM and BI are coordinated, they become a part of business strategy. Complementary use of CRM system and BI system provides a holistic approach to customers which includes improvements in customer profiling, simpler detection value for customers, measuring the success of the company in satisfying its customers. [43] 31

Chapter 3 System Requirement Analysis 3.1 The goal of the system The expected goal of this project is to fulfill all the requirements from client side which are defined in this document. 1) The CRM system is enhanced and configured properly which can work following CRM processes and meet all the requirements of the cooperation between SMedia and DT so that it can help SMedia to improve its quality of customer care and achieve the new level of customer service. 2) All the system are coordinated and integrated well so that each process can work as it is expected to do, effectively and efficiently. 3) The reports are generated correctly which can present the real situation of this cooperation. The goal of the system is to achieve the goal of each stakeholder. In general, there are mainly three stakeholders of this system, customer, CSR and manager. The duty of CSR is just to execute related processes according to customers willing. So it is depends on the requirements of customer. The goal of customer is to enjoy the service offered by SMedia. And the goal of manager is to manage the cooperation project properly. Figure 3-1 uses SCANPIO diagram to illustrate the goal and requirements of each stakeholders. SCANPIO stands for Structure, Content, Access, Navigation, Presentation, Interaction and Operation, which are classifications of actions [44] [45]. 3.2 The functional requirements 3.2.1 CRM process module enhancement requirements In CRM process, the core element is customer. It has to provide services around customers. And in this instance of SMedia, the emphasis of customer care process is to focus on the customer who has already had a contract or is going to have a subscription immediately. In generally, a customer can get fully service only after the check of entitlement. Then, he can apply to change his receiver type, which includes DTH, Cable and Internet. He can also apply to upgrade, downgrade or change his service package. If there are some personal data changed, customer can 32

contact customer service representation (CSR) to modify his data stored in the sy s- tem as well. If customer is not satisfied with the service SMedia provided or some other reasons happened, he can ask to cancel the contract. As an important part of customer care, the system should allow authorized customers to login the web portal of SMedia to get self-service. And this should be the same when customers call the number of call center. Customers should have the ability to be recognized by IVR system and follow the voice instruction to get service. And because of the incoming introduced service of SMedia@Entertain, the customers are divided into two groups, the ones with current SMedia contracts and the ones with SE contracts, since they have different use cases which should be handled. To the customers using DTH or Cable to get media contents currently, as mentioned in the first chapter, they maybe would like to join SE plan. They may want to subscribe a SE separately so that they can have both kinds of service or they may want to directly change their current contracts to SE. And the same situation can be happened also in SE customers. In some cases, the SE customers may want to change their contracts to the ones with DTH or Cable. The whole use cases and the relationship between customers can be referred to Figure 3-2. Change Package Create Contract Customer Manage Contract O O Modify Contract O Upgrade Package Enjoy Media Content O Get Entitlement O P Modify Data O Change Receiver Type Cancel Contract O O Downgrade Package Cancel Contract View Personal Data Modify Address O Revoke the Cancellation Migrate Contract Generate Reports O Manage Project P View Reports Manager Figure 3-1 SCANPIO diagram of system stakeholders 33

Get Entitlement Customer Upgrade/Downgrade/Change package Modify personal data Cancel contract SMedia@Entertain Customer DTH/Cable Customer Create new SE contract Change SE contract to DTH/Cable Change current contract to SE Figure 3-2 Use cases of SE related CRM process 3.2.1.1 Get entitlement As mentioned in the first chapter, assuming the entitlements for SE customers still will be processed over Smartcard Management System, the activation (and sending of entitlements) over the following service requests (SR) shown in Table 3-1 has to work like now with the only adaption being that instead of using the SMC serial number as unique identifier the encoded TOID should be used. SR is the basic unit of Siebel operation. A service request is a customer s request for information about or assistance with products or services. Every operation in Siebel, internal and external, will be based on one SR. An SR record can be created by CSR manually to handle some manual operations. It can also be created by system automatically in some cases, which intend to run some automatic process, such as automatic activation and so on. 34

Table 3-1 Service Request of First Activation Category Subcategory Activity Plan Activity TECNIQUE ACTIVATION First activation with validity check Activation In case a second entitlement is necessary, the following SR shown in Table 3-2 should also be adapted for SE. Table 3-2 Service Request of Second Activation Category Subcategory Activity Plan Activity TECNIQUE UNLOCK Unlock second Smartcard Send activation Currently, the message sent to Smartcard Management System for activation process needs two pieces of information, the contract number and related device number. Since SE contracts only will have one encoded TOID we may have two options to solve this problem: a. choosing the contract in the field Contract Number without the need to choose a serial number or b. the encoded TOID has to be displayed in the field Device Number The function of Smartcard Check should also work like now but instead of checking the entitlements for the SMC of course the entitlements for the encoded TOID has to be checked. And for SE customers who apply to activate the contract, according to different sales processes, there can be two kinds of situations happened: a. customer already has an active Entertain contract b. customer hasn t had a SE hardware yet For the first one, SMedia will trigger the entitlement directly. But for the second one, the contract will stay in status Pending until SMedia get a notice from DT to activate customer. And also for this situation, the current automatic activation process for DTH/Cable should be excluded. Current automatic activation process will check the status of delivered device. If status come from courier partner shows that the device has been delivered successfully, SMedia will activate customer s contract automatically with no need of customer to contact CSR. 3.2.1.2 Upgrade/Downgrade/Change packages The service request related to this use case is shown in Table 3-3. 35

Table 3-3 Service Request of Package UG/DG/Change Category Subcategory Activity Plan Activity CONTRACT Package Device Package Device Package Device MODIFICATION UG/DG/Change UG/DG/Change UG/DG/Change As agreed with DT in the first phase of this cooperation between DT and SMedia, the package UG is only handled over SMedia. Therefore the process can stay as is but of course has to work also for SE customers that don t have a SMC but instead have an encoded TOID. Currently, it s possible to filter package UG/DG/Change promotions either over the receiver type DTH / Cable or over Contract Type. This functionality has to be enhanced for SE customers, so that either several Contract Type (DT Entertain Customer) or the receiver type/ operator/ platform ( INTERNET/ TE L- ECOM/ ENTERTAIN ) can be defined (or both). 3.2.1.3 Modify personal data As agreed with DT, for first phase of the cooperation, customers have to contact DT to change their data for the Entertain contract, and contact SMedia to change the data for the SMedia contract. Therefore the processes to change the a c- counting information, address or name in general don t need to be changed. The only adaption that has to be made is the following: When the customer changes his address (over the service request shown in Table 3-4) currently there is an automatic check with a pop up message that says if a system change is necessary for the new location. In case of SE the message should always be positive (same message as for DTH customers). Table 3-4 Service Request of Personal Data Modification Category Subcategory Activity Plan Activity Customer Data Customer Data Modify Customer Data Modify Customer Data 3.2.1.4 Cancel contract Like the other cases, also for the cancellation of the SMedia part of a SE contract, the customer has to contact SMedia. Therefore the cancellation and revocation of cancellation has to work exactly the same as currently. 3.2.1.5 Create new SE contract There are two different types of customers related to this use case: a. Existing Call & Surf customer 36

b. Existing Entertain customer Call & Surf is another kind of subscription of DT. And the only difference between these two customer types is that, as mentioned in the use case description of Get entitlement, Entertain customers already have DT hardware and could be activated by SMedia immediately. For Call & Surf customers, they have a TOID, but no hardware. For this reason, SMedia has to set this type of customers in status of Pending, until the technical set up is completed. 1) Existing Call & Surf customer subscribes SMedia and DT Entertain The customer who already has a TOID, will subscribe Entertain in DT CRM, and in the meantime, subscribes SMedia in SMedia sales frontend. After a positive risk check on DT side, the customer data will be transmitt ed with encoded TOID to SMedia CRM immediately after subscribing. In parallel, DT will ship the SE har d- ware to the customer. Then, SMedia will perform a risk check and check if the cu s- tomer already has a SMedia contract as well. After that, SMedia will inform DT about the contract conclusion. a. After a positive result, the customer s status will be set as Pending. DT will inform SMedia as soon as the customer has an activated Entertain product. Then SMedia will change the status to Active and trigger the entitlement immediately to DT. SMedia will send a welcome letter to customer and start the billing actions. b. After a negative result, SMedia will inform DT as well as the customer. The process described above can be referred to Figure 3-3. And the document notation linked with the process means that the listed information should be tran s- formed between processes. 2) Existing Entertain customer subscribes SMedia The customer who already has the unique identifier (TOID) and DT hardware, will subscribe SMedia at DT side using SMedia sales frontend. And the customer data will be transmitted to SMedia immediately. Afterwards, like the situation di s- cussed above, SMedia will perform a risk check and simultaneous check which intends to see whether the customer already has an existing SMedia contract or not. a. After a positive result, SMedia will set the customer s status as Active. Then SMedia will inform DT and trigger the entitlement to DT. DT will entitle the customer s content manually within 12 hours maximum. And SMedia will send a welcome letter and start the billing actions. 37

Subscription flow of existing "Call & Surf" customer Customer DT SMedia Suscribes to SMedia and DT Entertain Registration Contract in Sky sales frontend Registration in Siebel Deliver hardware - Encoded TOID - Flag for existing Entertain customer - Personal data - Address - Contract data - Promotion information Information contract not possible Contract confirmation Technical set up complete Entitlement Negative - Encoded TOID - Information about packages (Asynchrony information) - Encoded TOID - Information about packages - Encoded TOID - Encoded TOID - Entitlement of affected packages Deduplication check Risk check Positive Pending for activation Activation Triggering entitlement Start billing Welcome letter Information to customer Negative Figure 3-3 Subscription flow of existing "Call & Surf" customer b. After a negative result, SMedia will inform the customer and DT. The process described above can be referred to Figure 3-4. The same as previous scenario, the document notation linked with the process means that the listed information should be transformed between processes. 38

Subscription flow of existing "Entertain" customer Customer DT SMedia Suscribes to SMedia Registration Contract in SMedia sales frontend - Encoded TOID - Flag for existing entertain customer - Personal data - Address - Contract data - Promotion information Registration in Siebel Information contract not possible Negative Deduplication check Risk check - Encoded TOID Positive Contract confirmation (Asynchrony information) - Encoded TOID - Information about packages Contract registered Activation Entitlement Triggering entitlement - Encoded TOID - Entitlement of affected packages Start billing Welcome letter Information to customer Negative Figure 3-4 Subscription flow of existing "Entertain" customer 3.2.1.6 Change current contract to SE If the customer wants to change his current contract to SE, according to current process, after he selects the service on the web portal, he has two options to choose: a. Login with the customer number and PIN of SMedia, so that in the next page, his personal data will be prefilled automatically but editable or b. Skip the login, so that in the next page, he has to fill in the necessary data manually. After all required fields being filled, an E-mail will be generated which includes following data: a. Encoded TOID 39

b. Commissioning data for DT c. Customer number (optional) d. All values the customer filled in Due to the related rule, the E-mail will be forwarded to a certain team, which has to contact the customer for further information then. The CSR will the process the existing SMedia contract like Figure 3-5 described. Since in this situation, customer not only upgrade/downgrade/change his co n- tract, but also change to a totally different kind of service which should be served by both companies, the origin service request of Package Device UG/DG/Change is not suitable any more. A new service request shall be implemented with the parameters shown in Table 3-5. Table 3-5 New Service Request Category Subcategory Activity Plan Activity CONTRACT MODIFICATION Contract Change Contract Change Contract Change And for this service request, a new group of scripts should be introduced to handle the following processes: 1) Necessary checks The system checks shall be performed in the background and shall only be visible when the result is negative. The logic is the same as currently implement a- tion in Package Device UG/DG/Change. And the checks should include: a. Country (only German customers can execute this kind of change to SE) b. The status of current contract should be Active c. All the current packages should be in status of Active d. There are no logistics processes in progress e. The type/ operator/ platform of receiver should be correct f. The pricelist should be correct g. The customer is not in dunning status h. The contract includes a 2nd TV package or not 2) Choice of contract change In generally, only the kind of contract which customer is enabled to switch to can be selectable. And in this case, CSR has to choose SMedia@Entertain - Contract, since this type of contract is the only possible one with receiver type/ oper a- tor/ platform as INTERNET/ TELECOM/ ENTERTAIN. And so that there is no need to provide a further page to let CSR to select related receiver information. 40

Process of change contract to SE Customer CSR Customer has an existing Sky contract and wishes SE Choose migration type: SMedia Standard -> SE Does a new cotnract already exist? Yes Enter/ Search contract number of new contract No Assign encoded TOID Enter DT data Package promotion Generate confirmation letter Customer migrated to SMedia standard contract Summary page Figure 3-5 Process of change contract to SE 3) Ask if a new SE contract already exists Since the SE contracts will be included in the duplicate check, there may be a kind of issues happened that customers weren t flagged within the sales frontend 41

but later are recognized as existing customers. Therefore also these customers will be able to change their old DTH/Cable contracts to SE. In this case, system shoul d provide a page which allow CSR to choose whether a new SE contract already exists or not. a. New SE contract already exists In the next page, CSR has to input the contract number of the new SE. The encoded TOID and the commissioning information of the new SE contract has to be switched to the old DTH/Cable contract which the customer wants to change, so that it can be transmitted to DT later. b. No new SE contract exists An E-mail will be generated by DT. CSR will follow the following process to handle this kind of situation. 4) Input encoded TOID Currently, in this case, there is no available automatic process to assign the encoded TOID to the contract. CSR has to insert it via copy and paste in the field manually. System can only provide basic check like the length of the string to try to avoid mistakes. The encoded TOID will replace the SMC serial number for a SE customer. 5) Input DT commissioning data It is similar to the step of inputting encoded TOID, the CSR also has to finish this part via copy and paste manually. And the system will only check the length of the string again. This data should not be visible within the customer portal. It s not used and has no impacts for SMedia and shall only be transmitted back to DT. 6) Package changes The following changes have to be executed: a. Change to newest pricelist b. Contract renewal c. Ceasing of services that are not compatible with SE And in this step, it has to ensure that all the packages customers should stay as they are as well as the free visions and discounts, not to restart of the date. 7) Summary page The summary page shall display all changes that executed during previous steps including: a. Contract duration 42

b. Receiver type/ operator/ platform c. Promotion d. Service that were not compatible and therefore ceased 8) Outcome The final outcome of this process should be: a. Change of receiver type/ operator/ platform b. Generate a record for logistic processes c. Add the encoded TOID to contract d. Change package if necessary and cease not compatible services e. A new record in the table of Contract Modify History f. A new record in the table of Offer History g. The termination entitlement for the SMC has to be send h. Restart of the start date of the offer 3.2.1.7 Change SE contract to DTH/Cable In case the DT part of SE is terminated due to cancellation, downgrade, revocation or relocation, the SMedia part will not be ceased. Therefore the customer needs to have the possibility to change his SE contract to DTH/Cable. The expiring date of customer s DT Entertain contract will be transmitted to SMedia. This date shall be written in a field named Cooperation Termination Date automatically. And if the customer revokes his cancellation or changes his relocation date, DT will send a new file to SMedia and the date has to be updated or deleted. Shortly before the termination, the affected customers should automatically be uploaded to a campaign list, so that the CSRs of SMedia can contact them and try to persuade them to change their contract to DTH/Cable. Therefore, the CSRs should also ask them to clarify which receiver type and hardware they want. The type of the service request to handle this process can be the same as Change DTH/Cable contract to SE. But the group of scripts of course is different. And according to the different hardware the customer wants, it may have three different processes: a. SMedia hardware including STB (A) b. Only SMedia SMC (B) c. Customer already has hardware from another party (C) The process can be referred to Figure 3-6 below. 43

Flow of changing SE contract to Cable/DTH Customer Customer migrates to standard SMedia contract CSR Choose contract change type: SE -> SMedia Standard Subscription Select target reception type/ operator/ platform Hardware from SMedia required? SMC only Select STB and SMC from SMedia No hardware required Select platform of customer s STB (Nagra, NDS) Select hardware attributes (if necessary) Fill in data of customer s hardware (SMC, STB No.) Select hardware promotion Choose delivery method / installer service Confirm address Choose additional address Generate confirmation letter Change date Customer migrates to SMedia standard contract Summary page Figure 3-6 Flow of changing SE contract to Cable/DTH 44

1) System checks The behavior of this step is quite similar to the one of Change Cable/DTH contract to SE. The checks should include: a. Contract is in status Active b. Receiver type/ operator/ platform c. An encoded TOID is included in the subscription d. Pricelist e. Customer is not in dunning process 2) Choice of package Customer can choose which kind of contract he wants to change. And several other options will be display later, which only the ones for which the customer is enabled can be selectable. Furthermore, the customer will be asked which hardware he wants: a. SMedia hardware b. SMC only c. No hardware And the following pages will depend on the chosen kind of contract and hardware. In this case, the CSR has to choose the option of SMedia Standard Contract. 3) Choice of receiver type/ operator/ platform The customer has to choose the target receiver type and operator. In this case, only DTH and Cable can be available since the customer wants to change to a standard SMedia subscription. The platform will not be displayed because it will be chosen later or set automatically. 4) Hardware Depending on what the customer has chosen in the first page, there three different possible flow: a. Customer wants SMedia hardware If the customer wants SMedia hardware, the platform should be set to the newest one depending on the chosen operator automatically. The logic is the same as current implemented script for technical upgrade. The only difference is that in this case the platform is not visible within the page. Since the workflow that follows for these cases is the same as current in the technical upgrade process. It can be implemented in the same. 45

b. Customer wants SMC only If the customer wants SMC only, he only needs to choose which platform he wants. The further pages are the same as in the technical upgrade process, but it shouldn t be possible for customer to choose an installation service. c. The customer already has hardware from third party In case the customer already has hardware from a third party, the CSR has to enter at least the serial number of the SMC and the one of STB if necessary. Then a plausibility check has to be performed. The logic is the same as currently impl e- mented in the sales process. If the serial number is not compatible with the receiver type/ operator, an error message will be displayed and the CSR shall have the possibility to go to the previous page and change it. 5) Change date Customer can have the ability to choose when he wants to change the contract to standard SMedia contract. There will be two options: a. Today b. Expiring date of Entertain contract This means that all changes including receiver type/ operator/ platform and package changes will only get active at the date the customer selects. But according to agreement between DC and SMedia, since this function will pay too much effort, it may not be implemented in the first two phases of this project. It can be regarded as an optional requirement. 6) Summary page The summary page should display all changes executed in previous steps: a. Contract duration b. Receiver type/ operator/ platform c. Hardware that will be shipped 7) Outcome The expected outcome of this process should be: a. The value of Contract Type changes to the standard value b. Change of receiver type/ operator/ platform c. Generate shipping order for hardware if required d. Cease/hide the encoded TOID e. Generate new hardware items if necessary f. Add hardware fees if necessary 46

g. A new record in the table of Contract Modify History h. A new record in the table of Offer History i. When the new SMC is associated, the termination entitlement will be sent j. Change package. 3.2.2 System coordination and integration requirements As mentioned in Section 1.3.2, in this project, the integration between different systems is essential. Since the CRM process module will be modified and enhanced, it has to ensure the communication and coordination between enhanced CRM pr o- cess module and current existing systems work well. And the relationships which may be affected by the modification of CRM process module are shown in Table 3-6. Table 3-6 The description of related system System/Stakeholder Siebel Description Customer Relationship Management system. The core of entire processes, used for maintaining transaction and customer data. Web Frontend The frontend of entire system, used for CSR and customers to interact with system to perform all kinds of operations. Smartcard Management System Billing System IVR System An external system, used for verify and entitle smartcard of customers. Used for control billing and dunning processes. IVR stands for Interactive Voice Response. An external system that gets the customer information and routes the customer according to his needs. Letter Management System Supply Chain Management System Used to generate letter to communicate with customers and partners using defined letter template. Used to manage the supply chain process for SMedia hardware including Cable, STB and SMC. 47

Continued Table 3-6 System/Stakeholder DTelecom Description The cooperation partner of this project. Be responsible for TOID generation, SE hardware delivery, contract confirmation of DT side work and so on. Risk Check System An external system, used for evaluating the profile of customer and newly inserted order and give a result of risk. Courier A cooperation partner of SMedia. Be responsible for SMedia hardware delivery and the feedback of delivery status. The interaction architecture can be referred to Figure 3-7. Internal External Letter Management System Web Frontend SMC Management System IVR System Siebel DT Risk Check System Billing System Supply Chain Management System Courier Figure 3-7 Interaction architecture of CRM related processes systems 3-7. The relations between each system and stakeholders can be referred to Table 48

Table 3-7 Relationships between systems/stakeholders Interacted Systems/Stakeholders Siebel and Web Frontend Relationship Description Web Frontend is the user interface of system, which allows customers and CSRs to execute operations in an intuitive way. And the backend operations are performed by Siebel. Siebel and Billing System Billing System refers customer data from Siebel, like contract type, price list, expiration time etc. When a contract is created successfully, Siebel will inform Billing System to start billing process. And if customer doesn t pay fees in time, Siebel will inform Billing System to start dunning process. Siebel and Letter Management System Siebel uses Letter Management System to generate all required letters using defined letter template to inform customers or partners. For example, if an SE contract is created successfully, Siebel will generate letters to inform both DT and customers. Siebel and Supply Chain Management System Siebel will refer the SMedia hardware information from Supply Chain Management System, like hardware type, inventory etc. And when a contract creates successfully, Siebel will inform Supply Chain Management System to prepare customer required hardware. Siebel and SMC Management System Siebel will send SMC serial numbers, or TOID in SE case, to SMC Management System. And then the latter system will verify it and send the response back to Siebel. And if the check passes, SMC Management System will entitle the customer so that they can enjoy the services they have ordered. 49

Continued Table 3-7 Interacted Systems/Stakeholders Siebel and IVR System Relationship Description Siebel doesn t interact with IVR System actively. When the latter system requires customer data and other transaction data, it will invoke functions defined in Siebel to read and write data. Siebel and DT Siebel needs TOID which is generated by DT s system to create SE contracts. And during SE contract related processes, Siebel often needs to inform DT current status and the confirmation of latter side. Siebel and Risk Check System Siebel gathers required information of customer and the newly inserted order. Then it invokes the risk check function of Risk Check System remotely via web service. Risk Check System will perform risk check according to some rules and then reply the outcome to Siebel. Siebel and Courier It is related to automatic activation and customized delivery date processes. About automatic activation process, Siebel will retrieve the delivery status of customer s hardware every two hours, and when courier reports that the hardware has been delivered successfully, Siebel will automatically start entitlement process. And about customized delivery date process, it can allow customer to select when he would like to receive the hardware and via which type of express. The time and express options will be retrieved from courier side, and when the contract is created successfully, Siebel will inform courier side to deliver the hardware according to what customer chose. 50

Continued Table 3-7 Interacted Systems/Stakeholders Billing System and Letter Management System Supply Chain Management System and Courier Relationship Description Billing System also needs Letter Management System to generate letters when billing or dunning process starts. Supply Chain Management System interacts with Courier to complete the delivery process. The integration mechanism must satisfy the requirements of all t he relationships described above. 3.2.3 Customer data process and analysis requirements As mentioned in Section 1.3.3, managers of both SMedia and DT sides would like to know how this cooperation project goes. So transaction reports are needed. And since this cooperation will start only from July 1st, forecasting report is too hard to implement and quite infeasible and inaccurate without enough historical data. So for the beginning stage of this cooperation, only summary reports of current stage and past month are needed and feasible. 1) The number of created SE contracts every day of past month It needs to summarize how many SE contracts created everyday which is one of the most are convincing data represents the level of the attractiveness of SE service. And the report will be shown in not only grid form with accurate information but also in a line chart which can show the trend intuitively. 2) The number of SE contracts converted from Cable/DTH customer This dimension represents the attractiveness level of SE service to Cable/DTH customer. Since the price is the same, the only difference is the hardware it used. Standard SMedia contract needs Cable or STB and SMC, while SE contract needs DT hardware and can be accessed directly from internet. So the latter one is more convenient for the customer who has only one STB and would like to order second contract. The report will also be generated in both grid form and line chart. 3) The number of contracts converted out of SE service This dimension shows the opposite aspect of the second report. It shows how attractive the media content of SMedia is. Since SMedia offers some other kinds of services which can only be accessed via standard SMedia contracts, the customer of 51

SE contract may prefer these services. This report will be generate in both forms the same as the two reports described above. The report category may be increased depends on the efforts required to pay during the development of this project. And all the reports already mentioned should be generated automatically on the first day of each month and will describe the situation of last natural month. All the reports should be in Excel format so that it can be easily stored and organized. The flow of this process is shown in Figure 3-8. CRM System ETL Data Mining Chart Manager Figure 3-8 Flow of report generation From the figure, we can see, CRM system manage all the customer and transaction data, and save the data into a large database. Then an ETL process is required to gather the data and then process them. Afterwards, some proper data mining will be invoked to get the useful information. At the end, a report in both chart and grid form will be generated automatically to present to mangers. 3.3 The non-functional requirements In general, there are some basic guidelines for customer service which have to be followed for the development mentioned in this project. They are not functional issues, but they are also quite important for the achievement of project success. They affect the spheres of interest and responsibility of customer service. The main objectives to be achieved by defining standard and minimum requirements are: 1) Controlling/reducing the average processing time and complexity depending on the relative frequency of a given process. 2) Ensuring intuitive understanding and user guidance in the CRM system and connected systems for both researching and processing customer and contract data. Grid 52

3) Integrating control and security mechanisms to prevent and identify processing errors in all processes. 4) Guaranteeing basic ability of process for customer service of all customer and contract data in every area of application of the CRM system. 5) Integrating/taking into account an authorization concept based on defined roles for individual CRM system users. 6) Establishing efficient interface management between the various systems used in customer service to guarantee exchange of key information (in particular between the CRM system, correspondence management system and telephone sy s- tem). 3.4 Brief summary In this chapter, the business requirements of the whole project was described. In functional requirements part, mainly three modules have been mentioned, i.e. CRM process module enhancement, system integration and customer data pr o- cessing. And among this three, the first one has the most requirements since it will directly communicate with final users. Afterwards, some non-functional requirements were discussed. 53

Chapter 4 System Design 4.1 Brief description of system design In CRM process module enhancement project, there are mainly two kinds of work. On one hand, there are several new processes needed to be implemented, and at the same time, on the other hand, some existing processes should also be adjusted to meet the new scenarios. In this chapter, the whole design of the system will be divided into two parts to be explained according to each requirements. Functional specification will explain the functionalities of each requirement module. It will present how the process works, how the UI would be looked like and the flow of process execution. Technical specification will explain the detail of how to achieve all the functions in a technical view, like what should be configured, what should be enhanced, what should be created, how the database and communication interfaces would be designed. 4.2 Functional specification and user interface mockup 4.2.1 Sales To fulfill the requirements, the new logic will be implemented in the sales process of new subscription. 4.2.1.1 BPMN of sales process According to the requirements, a series of new business scenario should be designed to describe the process of how to create SE contracts. The scenarios are listed in Table 4-1. Table 4-1 Business scenario list of creating SE contract Scenario Scenario 1 Scenario 2 Scenario 3-1 Scenario 3-2 Brief Description Describe the process from subscription created to risk check Describe the process from which the outcome of risk check is Positive to duplication check Describe the final steps of sales for DT Call & Surf Kunde (Call & Surf Customer) Describe the final steps of sales for DT Entertain and DT Liga Total Kunde 54

As it is described in the requirements part and the list above, there are two different types of DT customers who would join the SE program. And the most i m- portant difference between these two types of customers which would affect the processes is that, DT Entertain and DT Liga Total Kunde already has required DT hardware and can be activated immediately by SMedia when they pass all the checks of creating subscription. And for DT Call & Surf Kunde, they have only TOID and no hardware. In order to describe these processes clearly, we use Business Process Modeling Notation (BPMN) to model and present all the business scenarios listed above. BPMN, as the Object Management Group (OMG) [46] described in BPMN 2.0 standard document, its primary goal is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. [47] Since the newly introduced processes are a combination of business rules and technical implementation, using BPMN is a good way to design and present them. And as listed above, there are 4 business scenarios related to newly introduced sales process need to be designed: 1) Scenario 1 After CSR insert new subscription for DT customer, CRM system will enter risk check process. The Risk Check System is an external system, which will perform risk check according to some specified constraints. CRM system will call the function of Risk Check System remotely via web service. And then, the process will be suspended until CRM system received the response which contains the risk check result from Risk Check System. If the information of the new subscription and the customer fail the check, the new order will be rejected. And CRM system will inform DT side. Then this process ends. If the check is passed, the process will be forwarded to Scenario 2. And all the steps described in Scenario 1 belong to Confirmation Process. The description BPMN of Scenario 1 can be referred to Figure 4-1. 55

DT Risk Check System CRM System SMedia CSR Thesis for Master s Degree at HIT and UP New Subscription Confirmation Process Positive Invoke Risk Check Receive Response Negative Order Reject Scenario 2 Receive Request Check Risk Reply the result Receive Message Handle Rejected Order Figure 4-1 BPMN of Scenario 1 2) Scenario 2 After CRM system got Positive flag of risk check, the whole process will enter duplication check stage. And there could be three kinds of conditions: a. There are no other contracts (SAT or CABLE) with the same bank code for the customer. In this case, the outcome of duplication check will be Positive and the order entry process will be continue. b. There is at least one contract (SAT or CABLE) with the same bank code for the customer already presented in DB and the outcome of duplication check is Positive. In this case, the order entry process will be continue as well. c. There is at least one contract (SAT or CABLE) with the same bank code for the customer already presented in the DB and the outcome of duplication check is Negative. In this condition, the order entry process will be blocked. And this contract will be marked as duplicated order. As the process described above, if the duplication check is failed, this order will be forwarded to duplicated order handling process. And if the check passed, the order will be accepted and go to the following scenario. CRM system will also inform DT side the acceptance of this order. In Scenario 2, the duplication check steps 56

DT CRM System Thesis for Master s Degree at HIT and UP are belong to Confirmation Process. And the steps after Positive outcome start to belong to Mastership Change. The BPMN of Scenario 2 can be referred to Figure 4-2. Confirmation Process Positive Mastership Change Risk Check Positive Duplication Check Negative Duplicate Order Process Order Accept Scenario 3 Receive Message Scenario 3 Figure 4-2 BPMN of Scenario 2 And according to different customer type of DT, there are two branches in the following scenario. 3) Scenario 3-1 This scenario describes the following steps of DT Call & Surf Kunde. As it mentioned above, these customers do not have DT hardware. So there should be two parallel processes executed after the Positive flag of duplication check. In SMedia side, the CRM system will set the status of the contract to WARTE AUF SERIENNUMMER (WAITING FOR SERIAL NUMBER), and then the contract will be in pending status. At the same time, at DT side, the hardware has been sent out to customer. When customer received the hardware, DT will inform SMedia. And the CRM system of SMedia will set contract status to AKTIV (ACTIVE). And both sides start to proceed the entitlement process. The whole process of Scenario 3-1 is belong to Mastership Change. The BPMN of Scenario 3-1 is described as Figure 4-3. 4) Scenario 3-2 This scenario describes the following processes for DT Entertain and DT Liga Total Kunde. For these customers, the process is much simpler since they already have required hardware. Comparing to Scenario 3-1, the difference of Scenario 3-2 is that there are no steps for delivering and receiving hardware. It means that after the Positive flag of duplication check, the CRM system will set contract status to 57

DT CRM System Customer DT CRM System Thesis for Master s Degree at HIT and UP AKTIV immediately. And then, both SMedia and DT sides enter entitlement process. The steps described in this scenario belong to Mastership Change as well. Duplication Check Positive Set Contract Status WARTE AUF SERIENNUMMER Mastership Change Receive Signal Set Contract Status AKTIV Entitlement Process of SMedia Receive Message Send hardware Receive Signal Inform SMedia Entitlement Process of DT Receive hardware Figure 4-3 BPMN of Scenario 3-1 The BPMN of Scenario 3-2 is described in Figure 4-4. Mastership Change Duplication Check Positive Set Contract Status AKTIV Entitlement Process of SMedia Receive Message Entitlement Process of DT Figure 4-4 BPMN of Scenario 3-2 4.2.1.2 Order entry process of DT cooperation 1) Step 1 Back office operator starts order entry in the on behalf of mode with several new dummy dealers created for DT according to the type of contract to be created. 58

According to the requirements, the new dummy dealers that perform the su b- scriptions of new commercial offer for DT are: a. Personalverkauf DT Cooperation (Sales Staff) b. TelekomShop DT Cooperation (Telecom Shop) c. Outbound CC DT Cooperation d. Inbound CC DT Coopertaion e. Internet DT Cooperation f. Handelspartner DT Cooperation (Trading Partner) g. Kundencenter DT Cooperation (Customer Center) System will distinguish dealers according to different dealer number. The UI mockup of this page can be referred to Figure 4-5. Figure 4-5 UI mockup of selecting dummy dealer 2) Step 2 Operator is required to input the address and device information of customer. And because SE contract has its own special constraints, some of current fields need to be modified to adapt to the new process. The impact fields are as Table 4-2 shows. Table 4-2 Impacted fields of Adresse page Field Default Value Action Land (Country) DEUTSCHLAND (GERMANY) Will be grayed out. No change should be possible Empfangsart (Receiver Type) INTERNET Will be grayed out. No change should be possible Betreiber (New Operator) TELEKOM (TELECOM) Will be grayed out. No change should be possible Platform (New Platform) ENTERTAIN Will be grayed out. No change should be possible Hardware des Kunden EIGENE INTERNETGERÄTE Will be grayed out. No change (Customer owned hardware) (OWN INTERNET DEVICE) should be possible 59

Continued Table 4-2 Field Default Value Action Externe Kundennummer (External Customer Number) - Will be grayed out. No change should be possible. No default value Kundenkategorie (Customer Category) STANDARD Change should be possible. The new values requested of the this field will be available Vertragstyp (Contract Type) DT Entertainkunde (DT Entertain Customer) Change should be possible. The new values requested of this field will be available There are also some fields needed to be added for this very condition. The new fields are as Table 4-3 describes. Table 4-3 New fields of "Adresse" page New field Description Gerätekennung It shows the encoded TOID owned by the customer and it is a mand a- tory field. No default value. Externe Vertriebsnummer VO-number. For the pay out of commission of DT sales partner. No default value. The UI mockup of this page is shown in Figure 4-6. Figure 4-6 UI mockup of "Adresse" page 60

In this page, back office operator has to select a value of the Kundenkategorie field. And new logic will be created in order to allow the choosing of new values for Vertragstyp field according to the rules described in Table 4-4 below. These new values of the Vertragstyp field have to be only available for DT cooperation. Table 4-4 Combination constraints of "Kundenkategorie" and "Vertragstyp" Kundenkategorie (Customer Category) Vertragstyp (Contract Type) STANDARD DT Entertainkunde (New value) DT Call & Surf Kunde (New value) DT Liga Total (New value) DT Mitarbeiter (DT Employee, new value) DT Entertainkunde DT Call & Surf Kunde DT Liga Totala VIP DT Entertainkunde DT Call & Surf Kunde All other cases All values except: DT Entertainkunde DT Call & Surf Kunde DT Liga Total 3) Step 3 After previous steps, the back office operator has to input the information of this new contract. Comparing to current process, there are also some fields need to be modified to meet the new requirements of SE sales process. The impacted fields are listed in Table 4-5. Table 4-5 Impacted fields of "Vertrag" page Field Default Value Action Gerätetechnologie (Device Technology) should be possible PVRHD Will be grayed out. No change Service Typologie (Service Type) PVRHD It is a mandatory field. It is possible to change to PVR value Hardware Angebot (Hardware Offer) ONLY PRO- Will be grayed out. No change GRAM should be possible Gewünschte Installationsart (Preferred KEINE Will be grayed out. No change Installation Type) (NONE) should be possible 61

The UI mockup of contract information page is shown as Figure 4-7. Figure 4-7 UI mockup of "Vertrag" page From the UI mockup, we can see, in this page, the operator is asked to fill in the detail of the contract, including subscription type, program package, contract duration and so on. 4) Rest steps After confirming the contract detail, the operator is required to input the personal information of customer, the bank account information of customer which will be used for billing process, the delivery address (if it is different from customer s living address) and confirm the whole contract information in the overview page. 4.2.2 Entitlement Activation service request will be adapted for SE contracts in order to send the activation command to Smartcard Management System for the asset TOID in contract consistency. The impacted Service Request is as Table 4-6 shows: Table 4-6 Service Request of entitlement Parameter Value Translation Category TECHNIK TECHNIQUE Subcategory AKTIVIERUNG ACTIVATION Activity Plan Erstaktivierung ohne Validitätsprüfung First activation without validatity check 62

Continued Table 4-6 Parameter Value Translation Activity Aktivierung Activation The activity for the 2nd entitlement will also be adapted. The field of Gerätenummer (Device number) will contain TOID asset number. The mockup of this activity can be referred to Figure 4-8. Figure 4-8 UI mockup of sending request to Smartcard Management System After pushing the button Signal an Smartcard senden (Send a smartcard si g- nal), the activation request for the inserted TOID asset number will be sent to Smartcard Management System. And the impacted Service Request can be referred to Table 4-7. Table 4-7 Service Request of second smartcard activation Parameter Value Translation Category TECHNIK TECHNIQUE Subcategory FREISCHALTUNG UNLOCK Activity Plan Smartcard Freischaltung 2 Unlock 2 nd Smartcard Activity Freischaltung versenden Send activation 4.2.3 Migration from DTH/Cable to Internet A new CRM process will be designed and implemented in order to allow a DTH/Cable SMedia customer to migrate to SE structure. 4.2.3.1 Service Request configuration The new SR will be introduced as Table 4-8 shows. Table 4-8 Service Request of new migration process Parameter Value Translation Category VERTRAGSÄNDERUNG CONTRACT MODIFICATION Subcategory VERTRAGSWECHSEL CONTRACT CHANGE Activity Plan Vertragswechsel Contract change Activity Vertragswechsel Contract change 63

4.2.3.2 Preliminary checks There are some preliminary checks shown in Table 4-9 should be performed before the first page shows. Table 4-9 Preliminary checks description Property Constraint Translation Country DEUTSCHLAND GERMANY Contract Status AKTIV ACTIVE Package Status AKTIV ACTIVE Pricelist not in blocked list - Customer Status not in Dunning - In case the preliminary checks are not passed, the first page should show the reason why the SR is not available for customer (in German) to CSR. The UI mockup can be referred to Figure 4-9 below. Figure 4-9 UI mockup of error message showing page From the figure, we can see that in this example, the fail reason is that the contract status is in UNTERSCHRIEBEN (SIGNED) and package status is ZU AKTIVIEREN (TO ACTIVATE), and both of them are not in the status AKTIV. 4.2.3.3 Initial page If all preliminary checks are passed, then a welcome page will be shown and tell CSR that he is now in contract change process. The UI mockup can be referred to Figure 4-10. 4.2.3.4 Contract choice The next page will allow CSR to choose the migration type: 1) Standard SMedia Abo (Standard SMedia Subscription) 2) SMedia@Entertain Vertrag (SMedia@Entertain Contract) 64

Figure 4-10 UI mockup of welcome page The first option means allow customer to migrate from SE contract to standard DTH/Cable subscription, while the second one means the opposite migration dire c- tion. The UI mockup of this page is shown as Figure 4-11. Figure 4-11 UI mockup of choosing contract page In this chapter, we only discuss about the migration from DTH/Cable contract to Internet. So it means CSR should choose the second option, and he can only allow to choose this one when he operates a standard SMedia contract. And then some additional checks will be performed: 1) No shipment orders are in open status for this contract 2) No installation orders are in open status for this contract If one or more checks are not passed, an error page will be presented to CSR to describe the fail reason why it is not able to go ahead with this SR. The UI mockup of this page can be referred to Figure 4-12. Figure 4-12 UI mockup of system check error message 65

In this example, the fail reason is that there is still open shipping order. If all check are passed, the receiver type/ operator/ platform will be changed into the combination of INTERNET/ TELEKOM (TELECOM)/ ENTERTAIN since it is the only possible change. And in that case, no further page for system change will be shown for CSR. 4.2.3.5 Existing SMedia@Entertain contract check After system checks, the next page will allow CSR to select if a SE contract already exists for the customer or not. If the customer already has a SE contract, then these two contracts should be linked, otherwise, a new SE contract will be cr e- ated. Because in further step, system will perform a duplication check to see if there are other contracts with the same bank code for the customer. If the customer has other contracts, then the promotion for new customer is not suitable for him. The page will show question Existiert bereits ein neuer SMedia@Entertain Vertrag? (Does a new SMedia@Entertain contract already exist?) with two choices Ja (Yes) and Nein (No). The UI mockup can be referred to Figure 4-13. Figure 4-13 UI mockup of selection page Then the following page will depend on the selection. 1) Existing SE contract In case the CSR selects Ja in the previous page, a page will provide the possibility to allow CSR choose the number of existing SE contract. The CSR will have to expand the field Vertragsnummer (Contract number) to invoke a dialog which contains the list of all the contracts associated to the customer. And then, the CSR will have to choose one. The UI mockup of this step can be referred to Figure 4-14. 2) No existing SE contract In case the CSR selects Nein in previous page, the process will be directly forward to the page which allows CSR to insert TOID number and the commissioning data. 66

Figure 4-14 UI mockup of associate existing SE contract 4.2.3.6 TOID and commissioning data In this page the CSR will insert the TOID associated to the customer manually. TOID is a string of 14 characters and a check on the length of the inserted string will be performed. And then CSR will be required to insert commissioning data. There is also a check on this field in order to avoid the inserted string longer than 50 characters. The third field requires CSR to choose the sales channel for the customer from a pickup list. And if there is an existing SE contract selected previously, these fields will be automatically filled according the consistency data in the old contract. The UI mockup of this page is shown as Figure 4-15. Figure 4-15 UI mockup of TOID and commissioning data insertion page 4.2.3.7 Migration promotion New technical promotions will be created for the SMedia customers who want to be migrated to SE. And in this page, the CSR will have the chance to expand the list and select the technical promotion that will be applied to the contract. The UI mockup can be referred to Figure 4-16. After choosing the new promotion, some following actions will be performed in the backend: 1) Change the pricelist 2) Contract renewal 67

3) Ceasing of services that are not compatible with SE Figure 4-16 UI mockup of choosing migration promotion 4.2.3.8 Letter page The next page should allow CSR to choose if the confirmation letter will be sent to customer or not. The UI mockup of letter page can be referred to Figure 4-17. Figure 4-17 UI mockup of letter page There are two options in this page: 1) The first one means that the No. 411 letter which describes the detail information of migration contract will be sent automatically. 2) The second one means the letter will be suppressed. 4.2.3.9 Summary page The last page will be the summary page which will include following information: 1) Promotion name 2) Contract duration 3) Receiver type/ operator/ platform: in this migration, this combination will be INTERNET/ TELEKOM/ ENTERTAIN 4) List of services that are not compatible with SE and that will be ceased The example can be referred to the UI mockup shown in Figure 4-18. 68

Figure 4-18 UI mockup of summary page 4.2.3.10 Finish After Finish button in summary page being clicked, the SR will perform following actions: 1) Change the receiver type/ operator/ platform to INTERNET/ TELEKOM/ ENTERTAIN 2) Cease the technical items (SMC, STB, HDD etc.) in contract consistency 3) Generate a record for logistic processes 4) Add the encoded TOID, commissioning data and sales channel to the contract 5) Cease not compatible services in contract consistency 6) A record with process name VERTRAGSWECHSEL will be inserted in table Historie Vertragsänderungen (Contract Modification History) 7) A record will be added in the view Angebotshistorie (Offer History) 8) Activation commands will be sent to the Smartcard Management System and Bill System with TOID value 9) The termination entitlement for current SMC will be sent to Smartcard Management System immediately 69

10) The Abo-Beginndatum (Subscription Start Date) will be updated with current date 4.2.4 Migration from Internet to DTH/Cable The migration from SE contract to standard SMedia contract will use the same SR as the migration of the opposite direction, i.e. from DTH/Cable to Internet as described above. 4.2.4.1 Preliminary checks This step is exactly the same as the one in the opposite migration process. And also the behavior is the same. If the system checks are not passed, the first page will show the error message to CSR, otherwise it will show a welcome message. 4.2.4.2 Migration process choice The contract choice page is also quite similar to the one of the migration pr o- cess from DTH/Cable to Internet, except the available option. In this process, since the receiver type of SE contract is INTERNET, the only available option is Standard SMedia Abo (Standard SMedia Subscription), the other one, i.e. SM e- dia@entertain Vertrag (SMedia@Entertain Contract) will be visible but grayed out. The UI mockup can be referred to Figure 4-19. Figure 4-19 UI mockup of contract choice page After choosing the contract type, some further checks will be performed: 1) Validity checks on customer s main phone number 2) Checks on address in order to inform the customer about the HDTV receiver via cable. In case these checks are not passed, the error message will be shown to CSR. 70

4.2.4.3 Hardware choice The next page will allow the CSR to choose which kind of hardware should be sent to the customer or even the customer doesn t need hardware. Including no hardware, the options can be selected are: 1) HD STB 2) SMEDIA+ STB 3) CI Plus Modul (CI+ Module) 4) Nur Smartcard (SMC Only) 5) Keine Hardware von SMedia (No Hardware from SMedia) The UI mockup can be referred to Figure 4-20. Figure 4-20 UI mockup of hardware choice page 4.2.4.4 Receiver mode change In this page, CSR will be required to select the target receiver type, operator and platform. The UI mockup of this page is shown as Figure 4-21. Figure 4-21 UI mockup of selecting receiver mode page According to cooperation agreement, the selection rules and allowed system combinations will follow the constraints shown in Table 4-10. 71

Table 4-10 Combination constraints Hardware Receiver Type Operator Platform KBW KBW-NDS KDG KDG-NDS HD STB/ CABLE PREMIERE SMEDIA-NDS SMEDIA+ STB TELECOLUMBUS SMEDIA-NDS UNITY KBW-NDS SAT PREMIERE PREMIERE-NDS CI+ MODULE CABLE PREMIERE SMEDIA-NDS SAT PREMIERE PREMIERE-NDS KBW-NDS KBW OTHERS-NAGRA KDG-NDS KDG KDG-NAGRA KDG-NAGRA-V7 SMEDIA-NDS SMC ONLY/ CABLE PREMIERE OTHERS-NAGRA NO HARDWARE SMEDIA-NDS TELECOLUMBUS TC-NDS UNITY-I-NAGRA UNITY UNITY-U-NAGRA KBW-NDS PREMIERE-NAGRA SAT PREMIERE PREMIERE-NDS And in this part, according to different chosen hardware, there will be a branch here. The process will follow different flows: 1) If customer needs HD STB or SMEDIA+ STB hardware, Step 5A will be executed to allow CSR to select hardware attribute. 2) If CI+ Module or SMC Only option has been selected, the process will be directly forwarded to Step 6 to allow CSR to choose migration promotion. 3) If customer doesn t need hardware, the next step will be Step 5B which requires CSR to input the serial number of customer s hardware. 72

4.2.4.5 Hardware attribute selection In case HD STB or SMEDIA+ STB has been chosen, the CSR is allowed to choose hardware attribute as it is currently in place for technology upgrade process. The UI mockup of hardware attribute selection page is shown in Figure 4-22. Figure 4-22 UI mockup of hardware attribute selection page The next step on this flow will be the promotion selection page, i.e. Step 6. 4.2.4.6 Owned hardware serial number If the customer already owns hardware, and the option Keine Hardware von SMedia is chosen, the CSR will required to input the serial number of SMC which is owned by the customer. And after this step, customer owned hardware serial number will be associated automatically in the system records. The UI mockup of this page can be referred to Figure 4-23. Figure 4-23 UI mockup of serial number insertion page Compatibility checks on serial number will be performed in order to check that the inserted hardware serial number is compatible with the receiver type/ operator/ platform selected in previous step. If the compatibility check is failed, an error message will be shown to CSR to alert CSR to reset the information. If checks are OK, the following step will be promotion selection. 4.2.4.7 Promotion selection At this step, it will be possible to allow CSR to choose the migration promotion for both branches, with hardware and without hardware. But only the promotion related to the selected hardware will be displayed. The UI mockup of promotion selection page is shown as Figure 4-24. 73

Figure 4-24 UI mockup of promotion selection page And some actions will be performed by the new promotions at the end of the process: 1) Change the pricelist if needed 2) Contract renewal if needed 3) Add hardware fees if needed 4) Add the services that are compatible with SMEDIA structure 5) Cancel the Entertain contract type According to different hardware choice, there will be another branch in the following steps. If HD, SMEDIA+ or CI+ has been chosen, the process will be forwarded to Step 7A, which will allow CSR to choose delivery and installation options. Otherwise, the process will directly forwarded to Step 8 to ask CSR to choose if the confirmation letter should be sent to customer or not. 4.2.4.8 Delivery and installation option For all the types of hardware, except SMC Only, it will be possible to choose the delivery method. The customer who wants to get hardware sooner can pay additional fee to choose express method. And according to current rules, customer can also choose if he wants field agents to help installation or not. And there is also three levels of installation options, from light installation, which only covers r e- ceiver connection and setup, to full installation, which also covers reinstalling satellite system. The UI mockup of this page can be referred to Figure 4-25. According to the chosen delivery method, the flow will continue exactly like it is currently in place for technology upgrade process, including installation pages, delivery address confirmation, etc. 4.2.4.9 Letter page The behavior of this page is exactly the same as it is in the migration process from standard SMedia contract to SE contract. It allows CSR to choose if the notification letter will be sent to the customer or not. 74

Figure 4-25 UI mockup of delivery and installation option page 4.2.4.10 Summary page The last page will be the summary page and will include the following information for this new flow: 1) Promotion name 2) Contract duration 3) Receiver type/ operator/ platform 4) List of services that will be added 4.2.4.11 Finish After clicking the Finish button in the summary page, the SR will perform following actions: 1) Change the receiver type, operator and platform of the original contract 2) Set the status of TOID to BEENDET (FINISHED) and it will be ceased and de-associated as soon as the new SMC is activated. And if SMC is owned by the customer, i.e. Keine Hardware von SMedia option has been chosen previously, TOID in contract consistency will be ceased and a command will be sent to the Smartcard Management System. 3) Create shipping and installation order if needed 4) Create hardware items if needed. And in case of hardware is owned by customer, the related hardware information and associated serial numbers will be added in Weitere Hardware (Other Hardware) section. 5) Add compatible services that are currently missing in the package 6) A record will be inserted in the table Historie Vertragsänderungen (Contract Change History) 75

7) A record will be added in Angebotshistorie (Offer History) 8) Vertragstyp (Contract Type) will be changed into KEIN KOOPERA- TION (NO COOPERATION) 9) The Abobeginn-Datum (Subscription Start Time) will be updated to the current date if the customer chose the migration type with renewal option 10) Notification letter will be sent if the option has been checked 4.2.5 Automatic upload in campaign A new campaign will be created X days after the termination date for an SE contract and the customer will be automatically uploaded into it. The X can be set and stored in DB. A new workflow will be created in order to handle it. 4.2.6 Package upgrade/ downgrade/ change Activity Paket & Geräte UG/DG/Wechsel will be enhanced in order to allow only subscription package for SE customers since they don t have SMC related d e- vices, there should be no technology upgrade activity for them. The SR of this function can be referred to Table 4-11. Table 4-11 Service Request of package upgrade/downgrade/change Parameter Value Translation Category VERTRAGSÄNDERUNG CONTRACT MODIFICATION Subcategory PAKET - GERÄTE UG/DG/WECHSEL PACKAGE DEVICE UG/DG/CHANGE Activity Plan Paket & Geräte UG/DG/Wechsel Package & Device UG/DG/Change Activity Paket & Geräte UG/DG/Wechsel Package & Device UG/DG/Change When the process recognizes the contract as a SE contract, all technology u p- grade options should be grayed out. And after this selection, the following processes will work with exactly the same logic for SMedia contract with receiver type SAT or CABLE. And the promotions will be visible in the following page for promotion selection will be filtered only for receiver type INTERNET. The UI mockup of this change can be referred to Figure 4-26. 4.2.7 Data change The activity Änderung Kundendaten (Modify Customer Data) allows CSR to change the customer s address. It will be enhanced in order to skip the check on the 76

existence of the new address in the CABLE DB. The check, triggered by button Änderung speichern (Save changes) in the view Kundendaten (Customer Data) after the insertion of a new address and currently skipped in case of DTH contract, will be skipped also in case of receiver type INTERNET. Figure 4-26 UI mockup of contract modification The SR that will be enhanced is as Table 4-12. Table 4-12 Service Request of customer data modification Parameter Value Translation Category KUNDENDATEN CUSTOMER DATA Subcategory KUNDENDATEN CUSTOMER DATA Activity Plan Kundendatenänderung Customer Data Modification Activity Änderung Kundendaten Modify Customer Data 4.2.8 Revocation, Cancellation and Revocation of Cancellation Revocation means customer wants to revoke the process or subscription he has already done. Cancellation means customer wants to cancel all the contracts and exit SMedia. Revocation of Cancellation means customer wants to revoke his Cancellation process. SE customers will be allowed to run the following activity shown in Table 4-13 for revocation process. 77

Table 4-13 Service Request of revocation Parameter Value Translation Category KÜNDIGUNGSMANAGEMENT TERMINATION OF MANAGEMENT Subcategory WIDERRUF REVOCATION Activity Plan Widerruf - Neukunde Revocation New customer Activity Vertrag widerrufen Contract revocation Through this revocation activity, it will be possible for CSR to set termination date and detail revocation reason as it is currently for other DTH/CABLE subscri p- tions. But revocation batch will be adapted in order to retrieve the TOID from SE contracts and send messages to Smartcard Management System invoking the new interface. TOID status will be changed into NEU (NEW) and TOID will be de-associated with the contract. Cancellation and Cancellation Revocation will work as usual also for SE cu s- tomers. And the following activities described in Table 4-14 will be involved. Table 4-14 Service Requests of Cancellation and Cancellation Revocation process CANCELLATION Parameter Value Translation Category KÜNDIGUNGSMANAGEMENT TERMINATION OF MANAGEMENT Subcategory KÜNDIGUNG CANCELLATION Activity Plan Kündigung zu sofort Cancel immediately Kündigung zum Monatsende Cancel at the end of this month reguläre Kündigung Regular cancellation Kündigung Sonderkunde Special customer cancellation CANCELLATION REVOCATION Category KÜNDIGUNGSMANAGEMENT TERMINATION OF MANAGEMENT Subcategory KÜNDIGUNGSRÜCKNAHME TERMINATION REDEMPTION Activity Plan Kündigungsrücknahme Termination redemption Activity Kündigungsrücknahme Termination redemption And just as revocation process, Cancellation batch will also be modified in order to process SE contract, retrieve TOID and send the correct message to Smartcard Management System. TOID status will be changed into NEU and TOID will be de-associated from the contract. 78

4.2.9 Generate report Thesis for Master s Degree at HIT and UP A new module and scheduled task should be created to support this function. A report will be generated automatically every season. The report is in EXCEL format and including detail data and intuitive chart. A line chart will be used to present a trend of this cooperation while a pie chart will be used to present the market share of each type of contract. A mockup of the report is shown as Figure 4-27 and Figure 4-28. 4.3 Technical specification 4.3.1 Sales Figure 4-27 Mockup of report with line chart 4.3.1.1 Database configuration In order to satisfy the new process of sales, current database needs to be enhanced. New columns are needed to be inserted into current tables to handle the new information of SE customers. The enhancement can be referred to Table 4-15. 79

Figure 4-28 Mockup of report with pie chart Table 4-15 New columns for sales related tables Table Column Description WEB LOG SALES CONTRACT COMMISSIONING X_TOID_DT X_VO_NUMBER X_TOID_DT X_VO_NUMBER X_VO_NUMBER X_ENT_END X_ENT_END_REASON X_COOPERATION_PARTNER STATUS PROCESSED_DT External attribute, used to record the encoded TOID owned by customer in the web log External attribute, used to record the VO number for the pay out of commissioning of DT sales partner The same as described above The same as described above The same as described above External attribute, it shows the date of termination for a SE contract External attribute, it contains the termination reason for a SE contract External attribute, record the name of SMedia s cooperation partner The status of commissioning The date of process 80

Continued Table 4-15 Table Column Description COMMISSIONING STATUS_UPGRADE The status of upgrade UPGRADE_DT The date of upgrade Since there is a new kind of contract introduced, the current log table cannot handle this. In that case, a new table named CX_ENTERTAIN_LOG as Table 4-16 shown will also be created to be used to log all the web service calls between SMedia and DT while current log table will only be used to log the issue inside SMedia. Table 4-16 Columns of new log table Column Data Type Description X_SMEDIA_TYPE Varchar(255) External attribute, it records the type of data flow, can be: ORD_REJECTED, order rejection ORD_ACCEPTED, order confirmation TECH_SETUP, technical setup CANCELLATION, order cancellation X_SMEDIA_CONTRACT_NUM Varchar(50) External attribute, it records the contract ID X_SMEDIA_OUTCOME Varchar(50) External attribute, it records the outcome of this call, OK or KO X_SMEDIA_OUTCOME_DESC Varchar(255) External attribute, it records the description of the outcome, e.g. fail reason X_SMEDIA_TOID Varchar(14) External attribute, it records the TOID involved in this call At the same time, several configuration values must be introduced to the system. Firstly, in order to add the new values of the operator, platform and receiver type, three new LOVs (List Of Values) will be configured as following Table 4-17 shows. Table 4-17 Configuration for receiver type/operator/platform Type Value Country Active PREM_OPERATOR TELEKOM GERMANY Y PREM_PLATFORM ENTERTAIN GERMANY Y PREM_RECEIVER_TYPE INTERNET GERMANY Y 81

Continued Table 4-17 Type Value Country Active PREM_RECEIVER_TYPE INTERNET AUSTRIA N PREM_RECEIVER_TYPE INTERNET N Since there are several dummy dealers should be created, following LOVs will also be inserted in the table. The configuration detail can be referred to Table 4-18. Table 4-18 Configuration of cooperation dummy dealers Type Name Value Active SMEDIA_COOP_DT Telecom-Shop TBD Y SMEDIA_COOP_DT Handelspartner TBD Y SMEDIA_COOP_DT Outbound CC TBD Y SMEDIA_COOP_DT Kundencenter TBD Y SMEDIA_COOP_DT Internet TBD Y SMEDIA_COOP_DT Inbound CC TBD Y Another new logic should be handled is the combination of customer category and contract type. In order to allow this possibility, a new constraint will be added to the field. Following LOVs shown in Table 4-19 will be created. Table 4-19 Configuration of customer category and contract type Type Value Customer Segment Active COOP_PARTNERS_PAYBACK DT Entertainkunde STANDARD Y COOP_PARTNERS_PAYBACK DT Call & Surf Kunde STANDARD Y COOP_PARTNERS_PAYBACK DT Liga Total STANDARD Y COOP_PARTNERS_PAYBACK DT Entertainkunde DT Mitarbeiter Y COOP_PARTNERS_PAYBACK DT Call & Surf Kunde DT Mitarbeiter Y COOP_PARTNERS_PAYBACK DT Liga Total DT Mitarbeiter Y COOP_PARTNERS_PAYBACK DT Entertainkunde VIP Y COOP_PARTNERS_PAYBACK DT Call & Surf Kunde VIP Y 4.3.1.2 Interface between Siebel and Risk Check System During the work flow of order entry, the contract information will be sent to Risk Check System to perform some risk checks. Since this cooperation will introduce a new partner, the existing interface between Siebel and Risk Check System should be enhanced with a new parameter Distributor at contract level. The new parameter can contains one of the following values: 1) TELEKOM : value for all SE contracts 82

2) SMEDIA : value for all other contracts. The existing parameter Distribution Channel will be kept as-is. No new values will be added. But the meaning of distribution channel code will changes to Table 4-20 shows in case the distributor is TELEKOM. Table 4-20 New meaning of distributor channel code Meaning of Distributor channel Distributor channel Distributor= SMEDIA (AS-IS) Distributor= TELEKOM (new) 1 Retail Telekom-Shop 2 Teleselling Inbound Inbound CC 3 Teleselling Outbound Outbound CC 4 Web Internet 5 Installer Handelspartner 6 Door to Door Kundencenter 4.3.1.3 Interface between Siebel and DT Since the core of this cooperation is the communication between SMedia and DT, and during the order entry process, SMedia side should inform DT whether the contract is created successfully or not, in that case, a new interface between Siebel and DT is definitely needed to be designed and implemented in order to send to DT the outcome of the new subscription. And according to different conditions of customers, there would be several kinds of communication message as Table 4-21 shows. Table 4-21 Communication list of DT and Siebel for sales related process Message Type Description Order rejection for new custometomer The message sent to DT if the order is rejected for a new cus- Order confirmation for new The message sent to DT if the order is accepted for a new customer customer Technical setup complete The message sent to SMedia from DT if the hardware for call & surf customer is ready 1) Order rejection for new customer An order rejection message will be sent only if the risk checks fail. And in this case the following information shown in Table 4-22 will be sent to external DT system. 83

Table 4-22 Parameter list of Order Rejection method Parameter Data Data Description Type Length TOID TEXT 14 Encoded TOID of the customer status TEXT 30 Status of the contract Fixed: REJECTED orderreceipt TEXT 14 Timestamp of order creation E.g. 20130416235959 (YYYYMMDDHH24MISS) datetransfer TEXT 14 Timestamp of data transfer E.g. 20130416235959 (YYYYMMDDHH24MISS) salechannel INTEGER 1 Sales Channel received from DTAG 0= POS (Telekom-Shop) 1= POS (Handelspartner) 2= Inbound CC (DTKS) 3= Outbound CC 4= Internet (telekom.de) 5= Kundencenter PremiumReference TEXT 50 Information received from DTAG, i.e. VO number filled during the order entry process 2) Order confirmation for new customer The order confirmation message will be sent to DT after the Mastership Change process shown in BPMN of sales process in case of a contract has been activated. This means that the confirmation of the order will be sent to DT when the contract status is changed to AKTIV, i.e. DT Entertain customer or DT Liga Total customer, or WARTE AUF SERIENNUMMBER i.e. DT Call & Surf customer. In this case the following information shown in Table 4-23 will be sent to external DT system. Table 4-23 Parameter list of Order Confirmation method Parameter Data Data Description Type Length TOID TEXT 14 Encoded TOID of the customer status TEXT 30 Status of the contract Fixed: ACCEPTED 84

Continued Table 4-23 Parameter Data Data Description Type Length orderreceipt TEXT 14 Timestamp of order receipt E.g. 20130416235959 (YYYYMMDDHH24MISS) datetransfer TEXT 14 Timestamp of data transfer E.g. 20130416235959 (YYYYMMDDHH24MISS) salechannel INTEGER 1 Sales Channel received from DTAG 0= POS (Telekom-Shop) 1= POS (Handelspartner) 2= Inbound CC (DTKS) 3= Outbound CC 4= Internet (telekom.de) 5= Kundencenter PremiumReference TEXT 50 Information received from DTAG, i.e. VO number filled during the order entry process package TEXT 100 The name of SMedia package E.g. SMEDIA STARTER, WELT, WELT + FILM flaghd TEXT 1 Y = HD service, i.e. at least one HD service required N = otherwise flagpending TEXT 1 Y = call & surf customer, i.e. no DT hardware N = entertain customer, i.e. has DT hardware flagliga TEXT 1 Y = Liga Customer N = otherwise ExistingCustomer TEXT 1 Y = Existing SMedia Customer N = otherwise 3) Technical setup completed In case of a new SE customer is still waiting for the DT hardware, i.e. DT Call & Surf customer, the contract on Siebel is created with the status in pending, i.e. WARTE AUF SERIENNUMMER. And the contract will be unblocked only when DT send the confirmation of technical setup completed to SMedia. So a new interface is needed. And the information of this IO is shown in Table 4-24 below. 85

Table 4-24 IO parameter list of Technical Setup Completed method Input / Property Name Mandatory Data Data Description Output Type Length Input TOID Y TEXT 14 The encoded TOID of customer. It is a string with combination of letters and numbers. Input Timestamp Y TEXT 14 Timestamp of this call. E.g. 20130416235959 (YYYYMMDDHH24MISS) Output Result Y TEXT 15 Outcome of the invocation OK or KO Output ErrorCategory N TEXT 15 Error Category Output ErrorCode N TEXT 15 Error Code Output ErrorDescription N TEXT 200 Error Description And in case to handle the activate process of this pending SE contract, two checks should be performed when Siebel received the message from DT. On one hand, the input parameter should be checked to avoid lacking of mandatory information. On the other hand, the contract status should also be checked to ensure it is a contract in pending. The information of these two check functions can be referred to Table 4-25. Table 4-25 Checks for technical setup completed message Check Name Description Error Category CheckInputParameter Checks if all the mandatory A input parameters are passed in input correctly CheckContractStatus Checks if the contract status is B pending Error Description Error [Error Code] - Missing input parameter Error [Error Code] - Contract status doesn't allows the activation 4.3.2 Entitlement All the interfaces between Siebel and Smartcard Management System will be reviewed in order to allow the correct management of the TOID instead of the SMC 86

serial number for SE customers. And the technology and environment parameter values will be changed in case of TOID and the following fixed values will be used: 1) technology = T (TELEKOM) 2) environment = I (INTERNET) The commands that should be reviewed are listed in Table 4-26. Table 4-26 Should be reviewed command list Command name Command code Description Activation related commands AddAuthocode ADDAUT Activate a list of products EnableProduc ENBPRD ProductsForcedEntitlement ENBAPD Activate all products ProductDeletionAndForcedEntitlement ENBDEL DeleteAuthocode DELAUT Deactivate a list of products Suspend SOSPSC Deactivate all products ClearSmartCard CLRSMC ExecuteProductRefresh REFPRD Refresh all product ResetSmartCard RSTSUB Resend all products TempProdEnable ENBTMP Activate products with an expiration date Additional commands will be used InsertSmartCard INSSMC Insert TOID QueryBOX QRYBOX Retrieve the activated authocodes from Smartcard Management System 4.3.3 Migration from DTH/Cable to Internet 4.3.3.1 New functions In case to complete the newly introduced migration process, several fu nctions are needed to be created to handle all kinds of jobs when the migration process is finished. The functions can be referred to Table 4-27. 87

Table 4-27 New functions for migration to Internet Function name Description CreateHistoryRecord This function will be invoked in order to track all needed information on history table. And process name which has to be written in the history table has to be provided. MigrationToDT This function will be invoked to change receiver type, operator and platform to INTERNET, TELEKOM, ENTERTAIN. A query will be pe r- formed according to contract ID and new values will be set in Platform, Operator and Receiver Type fields. CeaseItems It will be used to cease the technical items in contract consistency, i.e. SMC, STB/CI and HDD. A query will be performed in order to retrieve all the hardware items in status different from BEENDET and ANNULLIERT and cease them. Manage Commands function will be invoked in order to send the deactivation command to Smartcard Management System CreateExpectedReturn method will be invoked in order to create an expected return for each ceased item. ApplyPromotion It will be invoked to apply the new migration promotion to the contract. The services to be deleted will be configured at promotion level and will be automatically ceased when the promotion is applied. A new entry in Angebotshistorie (Offer history) view will be created in order to track promotion change. Sendletter It will be created in order to trigger the new letter if the CSR has chosen the sending option. The IDs of the contract and activity, and activity name, letter code will be passed as input parameters. 4.3.3.2 Interface between Siebel and Smartcard Management System There are two parts of functions which need to communicate with Smartcard Management System when the migration process is finished. 1) Add the encoded TOID The TOID should be added under the contract consistency when the migration process is finished. And it should be activated. In that case, a Confirmation 88

method will be invoked to activate the TOID and send related commands to external Smartcard Management System. 2) Cease already existing SE contract If the customer already has a SE contract, and associate it with his standard SMedia contract during the migration process, in that case, the SE contract needs to ceased. And according to the status of the SE contract, there are two possible scenarios: a. The existing SE contract is not active. In this scenario, the contract status will be set to ANNULLIERT (CAN- CELLED), and no commands for hardware cancellation has to be sent. b. The existing SE contract is active In this scenario, a CeaseContract function will be invoked to send commands to external Smartcard Management System for the hardware cessation. And contract ID and cancellation reason are needed for input parameters. 4.3.3.3 Interface between Siebel and DT A confirmation message will be sent to DT after the migration process. The same function as which is used for new customer, shown in Table 4-23, will be invoked. And the information sent to external system will be the same except for two parameters. 1) ExistingCustomer flag will be fixed to Y to mark it as an existing customer. 2) FlagPending flag will be fixed to N, since the migration process is only possible for customers who already have the DT hardware. 4.3.4 Migration from Internet to DTH/Cable 4.3.4.1 New functions There are some functions which already created in the opposite migration process can be reused, such as ApplyPromotion for applying new migration promotion and ceasing incompatible services, and SendLetter for sending notification letter when process is finished. But there are still several functions which are this migration process specified needed to be created. The detail can be referred to Table 4-28. 89

Table 4-28 New function for migration to DTH/Cable Function name Description CeaseTOID It is used to cease entitlement TOID in the contract consistency. A query will be performed in order to retrieve TOID number. If there is no TOID in status AKTIV or ZU AKTIVIEREN, an error message will appear CreateHWItems It will be invoked to add hardware items under contract consistency if har d- ware has been chosen during the migration process. ManageAssets It will be invoked in case the customer already owns hardware. It will create and associate SMC serial number under contract consistency and associate STB to the customer. 4.3.4.2 Interface between Siebel and Smartcard Management System When a new SMC is associated or the new SMC is owned by the customer, TOID will be ceased and related commands will be sent to Smartcard Mana gement System. 1) A new method called SwapTOID will be created. It will be used to swap TOID and SMC, and de-associate TOID only when the new SMC is activated. 2) Confirmation method will be invoked to confirm the process just like what it does in the migration process from DTH/Cable to Internet. 4.3.5 Automatic upload in campaign 4.3.5.1 New workflow to be created A new workflow will be created in order to handle this process. And two new functions are needed to be implemented. 1) CreateCampaign This function will check if a campaign list for the same day has already created. If no campaign is created for that day, it will be automatically created. 2) UploadCustomer This function will be invoked after the campaign list created. If the customer has not been uploaded yet, this function will insert the customer into the dedicated campaign list. This workflow will be scheduled in order to run X days after the termination date of the SE contract. The X value can be configured and stored in a new LOV called SMEDIA_DT_CAMPAIGN_DAYS_WF. 90

4.3.5.2 Interface between Siebel and DT If the contract is terminated from DT side, there should be a message sent to Siebel to notice SMedia side of the contract termination, since different cancellation reason may affect the operation to be performed for this automatic process. If the termination is because the death of the customer, the contract will be ceased directly and no further operations will be performed. Otherwise, the customer will be uploaded in campaign automatically. The communication between Siebel and DT external system will include following information as Table 4-29 listed. Table 4-29 IO parameter list of contract termination Input / Property Name Mandatory Data Data Description Output Type Length Input Type Y TEXT 21 Used to mark the service type. Fixed: Termination Entertain Input TOID Y TEXT 14 TOID of customer Input ExpectedTerminationDate Y TEXT 8 Record the expected termination date of the contract. E.g.: 20130426 (YYYYMMDD) Input CancellationReason Y TEXT 1 Cancellation reason flag. Y = cancellation reason death N = other reason Input Status Y INTEGER 1 The status of the process. 0 = process is ongoing 1 = process is terminated 2 = process is cancelled Input Timestamp Y TEXT 14 Used to mark the timestamp of this call. E.g. 20130416235959 (YYYYMMDDHH24MISS) Output Result Y TEXT 15 Outcome of the invocation OK or KO 91

Continued Table 4-29 Input / Output Property Name Mandatory Data Type Data Length Description Output ErrorCategory N TEXT 15 Error Category Output ErrorCode N TEXT 15 Error Code Output ErrorDescription N TEXT 200 Error Description 4.3.6 Revocation, Cancellation and Revocation of Cancellation The interface between Siebel and Smartcard Management System should be adapted to handle the revocation, cancellation and revocation of cancellation tasks for SE contract. Two methods will be enhanced in order to manage the new TOID information in SE contracts. 1) CeaseContract As already mentioned above, it will be invoked to send commands to Smartcard Management System for cessation. TOID will be considered as SMC serial number and all hardware return management logics will be skipped in case of SE contract. 2) DisableSMC It will be used to disable the SMC of customer s contract. And in the case of SE contract, the information of TOID will be passed as input parameter. And as a l- ready mentioned in the parts of entitlement, the parameter technology and env i- ronment will be set to T and I. 4.3.7 Generate report The process of generating report includes two sub-process in fact. First one is ETL process. It is used to retrieve the required data from CRM database. It should transfer the raw data into organized view. The second one is generating operation reports automatically. 4.3.7.1 ETL process Since the database of CRM system is designed to handle massive data, and focus more on efficiency not saving space, it doesn t achieve a high level of normal form. In case to retrieve the required formatted data, an ETL process is needed. And according to the requirements of Key Performance Indicators (KPIs), the target data model can be presented in DFM diagrams. A KPI is a type of performance meas- 92

urement [48]. It is used for organizations to evaluate the success of a particular activity, in this very case, to evaluate the success of this cooperation project. And it is also what the final report should present to managers. To this cooperation, we are mainly interested in two parts: 1) The sales situation of SE contracts. For example, daily sales quantity, quantity for each type customer and so on. In order to handle these KPIs, the data model will be designed as Figure 4-29 shows. Previous Contract Type Day Sales Month Quarter Contract Type Year #Quantity Figure 4-29 DFM of sales 2) The comparison between SE contract and standard SMedia contract. For example, daily sales quantity for these two types of contracts, the rate of migration from standard SMedia to SE and vice versa, and so on. The DFM diagram of this fact can be referred to Figure 4-30. Customer Category Day SE Contract Sales Month Quarter Sales Channel Year #Quantity Figure 4-30 DFM of SE contract According to DFM, star schemas can be designed to implement the intermediate database for further operation. Star Schema is used instead of Snowflake Schema because of the scale of data and queries. Only when dimension table is relatively big in size, snowflake schema is better as it removes the redundancy and reduces space. The intermediate data storage model can be referred to Figure 4-31. 93

The outcome of ETL process is a CSV file. The output data structure is divided into two parts. The first part is the same no matter which type of chart is expected to be generated. The detail for the first part can be referred to Table 4-30. Table 4-30 Structure of the first part of CSV file Line No. Content Description 1 Chart type Clarify the expected chart type, can be Line, Pie and Bar 2 Chart title Declare the title of this chart The second part can be different depends on different type of chart. If pie chart has been chosen, the following data will be organized in the structure shown in Table 4-31 Contract Contract_Type Date PK ID PK ID PK ID FK Type_ID Type_Name Day FK PreviousType Month FK Date Quarter SE_Contract PK FK FK FK ID Customer_Category Sales_Channel SE_Customer_Category PK ID Category_Name Year SE_Sales_Channel PK ID Channel_Name Figure 4-31 Database model for intermediate storage Table 4-31 CSV data structure for pie chart Line No. Content Description 3 Number of categories Described how many categories will be presented in this chart 4 Category names The name of each category. The number should be the same as previous line indicated, and the strings will be splitted by ;. E.g. SMedia; SMedia@Entertain 94

Continued Table 4-31 Line No. Content Description 5 Quantity of each category Describe the quantity of each category. The number should be the same as previous line indicated, and the strings will be split by ;. E.g. Total; 532145; 245135 If other types of chart have been chosen, i.e. line chart or bar chart, the data structure will be different from the one of pie chart. It can be referred to Table 4-32. Table 4-32 CSV data structure for line chart and bar chart Line Content Description No. 3 The name of X, Y axis Described the measure names and will be shown in X, Y axis of the chart, split by ; E.g. Month; Quantity 4 Number of categories The same as it is in pie chart 5 Category names The same as it is in pie chart 6 to n-1 Sector name and the quantity of each category in that sector Describe the quantity of each category. The number should be the same as previous line indicated. The first string will be the name of this sector. The strings will be split by ;. E.g. January; 45314; 39214 n (opt.) Total quantity of each category An optional sector. If this sector is written, a pie chart will also be drawn to present the total share of each category. E.g. Total; 532145; 245135 4.3.7.2 Report generating process According to one of the principles of Object-Oriented design, software designs with low coupling and high cohesion can lead to products that are both more reliable and more maintainable [49] [50] [51]. This generating report module is designed to be an independent module, which the only function is to generate Excel report with chart and table. Since the target working environment of the whole CRM system server is based on IBM AIX system, which is an open, standards-based operating system that conforms to The Open Group's Single UNIX Specification Version 3 [52], Java language will be used to implement the module. And external libraries will be used to operate Excel files in Java. In this case, two open source libraries will be used, 95

JFreeChart and JExcelApi. JFreeChart is a free Java chart library that makes it easy for developers to display professional quality charts in their applications [53]. It will be used to generate a variety of charts. The latter one, JExcelApi, is a mature, open source java API enabling developers to read, write, and modify Excel spreadsheets dynamically. [54] And it will be used to import the charts created by JFreeChart and export them with tables to target Excel file. The brief class diagram of generating report module is shown as Figure 4-32. ReportGenerator -chart : Chart +loadfile() +drawpiechart() +drawlinechart() +drawbarchart() +exportexcel() Chart -title : String -categorylist : String[] -datalist : float[][] JFreeChart JExcelApi PieChart LineChart -Xaxis : String -Yaxis : String -sectorlist : String[] BarChart -Xaxis : String -Yaxis : String -sectorlist : String[] Figure 4-32 Class diagram of generating report module The explanation of functions in ReportGenerator class is listed in Table 4-33. Table 4-33 Function list of ReportGenerator Function name Description loadsource Used to load source CSV file which is the outcome of ETL process transformdata Used to transform the data loaded from CSV file to target chart object drawpiechart Used to draw a pie chart according to the transformed data drawlinechart Used to draw a line chart according to the transformed data drawbarchart Used to draw a bar chart according to the transformed data exportexcel Used to export a Excel report In order to achieve a good performance and easier to manage, the ETL process will be encapsulated into different archive files according to different statistical frequencies of different KPI. For example, all the KPIs should be included in monthly report will be encapsulated together. So are the KPIs for quarterly report, yearly report and so on. 96

4.3.7.3 Automatic process As described above, the ETL process and report generating process should be executed every some time. For example, a monthly report should be generated at the beginning of next month, a quarterly report should be generated at the beginning of next season. In order to generate report, ETL process should also be executed to retrieve the updated data. Since the execution interval is fixed, there is definitely no need to manually execute the process each time. An automatic process is quite efficient and can obviously reduce the workload of operators. The automatic process can be achieved by using the API of Java own. The most common way is using java.util.timer component. The Timer object will check the status every millisecond. When the pre-set interval is achieved, it will invoke the run function of the target object which already extended the TimeTask class [55]. But there is one big disadvantage of this way, which is the Java program should be already running. This could not be a problem, if the frequency of interaction is high. But in this very case, the interval is quite big, it could be one week, one month, one season, even one year. In this way, the program has to be running 24x7 hours even in idle time. This is effective, but totally inefficient. The source of the server is wasted. And every time the server restarts, the program should also be restarted again manually. Considering the actual situation of this program, including execution interval and runtime environment, there is another solution. The mechanism of UNIX sy s- tem named cron can be directly used to handle this scheduled task. The software unity cron is a time-based job scheduler in UNIX-like operating systems. It typically automates system maintenance or administration like connecting to the Inte r- net and downloading email at regular intervals [56]. Cron can executed pre-set shell command automatically following the schedule. In order to run the program correctly, it has to be packaged as a jar file. Then a shell script should be created with the contents describing how to execute this jar file. The final step is to configure cron with scheduled time and shell address. 4.4 Key techniques To different people, CRM can have different meaning. For some small comp a- nies, CRM means direct e-mails. And for others, CRM means a mass of customization or developing products that fit individual customers needs. For IT consultants, 97

like DC, CRM is translated into complicated technical theory which relates to terms like OLAP, which is an approach to answer multi-dimensional analytical (MDA) queries swiftly [57], and CICs (Customer Interaction Centers). It means that it should be designed and implemented according to the specified requirements of client. Just like mentioned in Section 2.1.2, CRM system is implemented in a 3-tier model. And it is also using B/S architecture, which simply uses browser as a client terminal to present information. And between CRM system and other connected systems, such as Smartcard Management System and IVR system, all the functions are implemented into web services as interfaces used to communicate with each other. And the customer data process and analysis part can only be finished after the completeness of first two parts. 4.4.1 Siebel customization In a conceptual view, Siebel applications are implemented in 3-tier model, which is said Siebel applications can be divided into three layers, UI layer, business layer and data layer. The logical architecture and relations between different types of principal objects belong to each layer can reference to Figure 4-33. UI Layer List Column or Control Applet View Screen Application Business Layer Field Business Component Business Object 1 or Many Data Layer Column Table References Figure 4-33 Logical architecture of Siebel application According to the figure, the detail of each layer can be referred as following: 1) Data Layer Data layer object definitions specify the logical structure of the physical database. And there are two principal data object definitions in this layer, table defin i- tions and column definitions. All the definitions are metadata, not data. 2) Business Layer In this layer, there are business object definitions specifying the business logic for the application. And there are two types of principal objects: 98

a. Business component (BC) As mentioned previously, business component represents one fundamental business entity in the enterprise. It represents a logical grouping of data from one or more tables. It always refers to a base table, but it can also include data from additional related table. It consists of multiple fields that characterize the business component by referencing columns in base or related table. b. Business object (BO) Business object is a collection of related business components. It represents a major functional area of the enterprise. It contains specific details about the rel a- tionships between BCs. 3) User Interface (UI) Layer UI Layer defines UI objects, which are used to represent data and accept operations from users. There are five principal UI objects within the user interface. a. Control and List Column Object It provides the ability to display and manipulate data. b. Applet Object It is a section of view, such as a list or form. It references one business component whose data can be viewed and edited through the list or form. It consists of list column or textbox control object definitions which refer to fields in the a p- plet-referenced BC and specify how the data for the fields is displayed in the list or form. c. View Object Definition It specifies a view in a Siebel application, which is somehow similar to a form in desktop application. And it contains several applet objects. d. Screen Object Definition It specifies a screen in a Siebel application. A screen is an aggregation of mu l- tiple view objects that usually refer to the same BO and is associated with a major functional area of the enterprise. e. Application Object Definition It specifies a particular collection of screens available in a Siebel application. So one of the main contents of this topic is to create or modify the definitions of all kinds of principal objects and add related supporting scripts in Siebel to sa t- isfy the requirements of SE. 99

The very first step is to modify and customize Siebel database. The underlying database is based on Oracle. CRM system covers marketing, sales and service. There are a large amount of entities covered by vary business scenarios, which makes the information of entities and the relationships between each other really complicated. And all these data are designed and then organized and stored in the central database of Siebel. Since this CRM process module enhancement work i n- troduces many new types of contract, hardware, service requests and so on, the needs of database customization work appears to be obvious. The next steps is to create or modify the principal objects mentioned above. Inside Siebel, developers can define all the objects and what the web page would be like using Siebel Tools. Siebel has its own mechanism to maintain run time events and other capabilities. But developers can also use Cascading Style Sheets (CSS) to design the detail user interface presented in browser according to actual demands. And furthermore, if current mechanism cannot satisfy what developer needs, Siebel does also provide another auxiliary mechanism. Developers can use a script language called escript which is provided by Siebel to implement all other complicated dynamic run-time functions in a heavy customization situation. escript is a kind of script language that is quite similar to JavaScript but has its own function libraries to handle Siebel specified environment, such as the functions to operate Business Components and Business Objects mentioned above. 4.4.2 System integration Just like Section 1.3.2 and Section 3.2.2 said, the enhanced CRM process module should be integrated with other existing systems to cooperate to finish all the processes. And the main mechanism which will be used in this project to solve integration problem is EAI combined with web service. Because the whole integr a- tion task can be divided into two parts, on one hand, it has to deal with the relationships with internal systems, which are running on the same infrastructure pla t- form, using EAI would increase the efficiency; on the other hand, the enhanced CRM process module should also communicate with external systems which are taken charge by other organizations and running on different platforms with diffe r- ent technologies. Using web service method can achieve loose couple and a convenient way to communicate with each other. 100

4.4.3 Customer data processing and analysis In this part, ETL process will be implemented firstly to make useful data structural and organized for further analysis. In case to get the data with high quality, a DFM modeling method will be used in the design phase. The first step is to identify a series of KPI according to the rules defined by managers. And starting from KPI, the required information can be grasped in a graphical conceptual way using a DFM diagram. Then the DFM diagram can be transformed into Star Schema to be implemented into database. A star schema consists of one or more fact tables referencing any number of dimension tables. It is an effective way for handling simple queries [13] [58]. After all data are prepared well, some proper data mining technologies may be implemented to dig out some hidden patterns from the large amount of data. The final step is to generate the reports. Since Excel files are most used for data presentation these days, and they also provide many powerful charts to present the intuitive views of data, the final reports will be exported to Excel. Furthermore, an Excel file is very suit for being stored and organized in a document management system for sharing or historical analysis. Currently, there are two ways to achieve this goal to export Excel files with line charts and grid. The most traditional one is to invoke Marcos mechanism which is supported by Microsoft Office using Visual Basic for Applications (VBA). VBA is an implementation of Microsoft s event-driven programming language Visual Basic. It is mainly used to extend the functions of Windows program, especially Microsoft Office series. It is convenient to be used to build some automatic process. But the problem is that it lives inside Excel, and it is hard to invoke from the program written Java or other languages other than C#. Another workaround way to implement it is using some free libraries like JFreeChart to generate a chart firstly then directly save it as a picture into Excel file. But this workaround solution also has its own disadvantage that users cannot modify the data in Excel files. But according to the actual situation of this project, managers need only to read reports, they don t need to modify the data in common cases. So that the latter way seems to be a practical solution currently. In order to achieve the goal of automatic process, a software unity of UNIX system named cron should be appropriately configured. It can execute the shell script of the task according to pre-set schedule. 101

4.5 Brief summary In this chapter, the design specifications was explained clearly by divided into functional and technical parts. And each requirement mentioned in system requirement analysis chapter has been presented and discussed. Firstly, the BPMN was used to describe the new workflow of sales process. Then several UI mockups were shown to explain the detail operation flow of each process. Afterwards, the tec h- nical details were also discussed including the functions need to be created or enhanced. 102

Web Service Handler Thesis for Master s Degree at HIT and UP Chapter 5 System Implementation and Testing 5.1 System structure According to the requirements and the design specification, considering the actual situation of existing systems, the final structure of the whole system is implemented as Figure 5-1 shown. Internal External BI System CRM System SMC Management System Data Layer CRM DB IVR System DT Middleware Risk Check System Billing System Web Frontend Supply Chain Management System Courier Figure 5-1 Architecture of the whole system From the diagram, we can see that, in general, all the systems are divided into two categories, internal systems and external systems. The boundary is the SMedia company. It means that, all the internal systems are controlled inside SMedia, although the further steps may involve the operations of external companies, for e x- ample, the supply chain management system obviously needs the resources from other factories. And, also, external systems mean that they belong to other comp a- nies, for example, the other partner of this cooperation, DT. It is necessary to distinguish the system category since it will be maintained in different technology for achieving system integration. For the systems inside SMe- 103

dia, the most important aspect that should be considered is execution efficiency because some operations even need real time response. The goal is to aggregate process. To achieve this, some sacrifices in flexibility can be accepted. In that case, traditional EAI structure can be chosen to solve the integration problem of internal systems because of its high efficiency and good performance but somehow a little tightly coupled. And for the communication with external system, the consideration aspect is different. The challenge which the aggregation of inter organization faces is the requirement of distributed systems, especially the ability of cross-platform. The technology to solve this problem should have better versatility and compatibi l- ity and should be standardized. In that case, web service is a good choice because of its loosely coupled integration mode although it has a lower performance. To implement EAI structure, a middleware is maintained to handle the data integration intra organization. CRM system will expose its dedicated read and write API, so are other systems. And for inter-organizational communication, a web service handler will be used. Each system will register itself and publish the web services to this handler. And each participant can also to discover others on it, too. And it is easy to notice that BI system is to be implemented in a unique module. Because it has its particularity. ETL process, which is the basis of BI, needs to collect required data from broad sources. So it should communicate with CRM database directly. And the data flow is unidirectional. The data can only flow from database to BI system and not the opposite direction. It means the data layer, i.e. ETL process, and BI system can only read data from CRM database and cannot write into it. This is following the actual requirement and usage of BI system. 5.2 Key program flow charts To review the whole system from a high level view, the lifecycle of customers can be referred to Figure 5-2. From the schematic diagram, we can see. In general, there are three status of customer regarding to his contract status. The customer without a SMedia contract is the one should be listed in campaign and shot for by salespeople. And for the people who would like to subscribe an offer, a sales process is needed to complete the required information. After that, a raw contract status will be achieved, which means the contract is just created and not activated yet. And then, an entitlement process will be invoked to active the subscription of customer. When the contract is 104

entitled and active, a series of CRM operation may be performed, such as data change, package upgrade/ downgrade/ change and so on. And each operation may be revoked by performing revocation process. And if the customer decides to exit SMedia, a contract cancellation process would be followed. And this process can also be revoked by a process called revocation of cancellation. If we look inside the contract, there are two types in detail. The first one is the already existing one, i.e. standard SMedia contract. The other one is the one introduced by this cooperation with DT and which meant to be taken care by implementing a new group of CRM process which this thesis described, i.e. SE contract. And each one of these two contracts can be migrated to another. Revocation of Cancellation Campaign No Contract Sales Raw Contract Entitlement Entitled Contract Data Change Package UG/DG/Change Process Revocation... Cancellation Migration to Internet Standard SMedia Contract SE Contract Migration to DTH/Cable Figure 5-2 Statuses of contract Look inside the process in a low level view, a typical flow of sales and entitlement for a DT Call&Surf customer with self-service subscription is as Figure 5-3 shown. From the diagram, we can see that the customer input required information from the web site of SMedia. Web frontend communicate with Siebel via dedicated Write API which just encapsulated the same operation which CSR performed d i- rectly in Siebel. After gathering required information, Siebel wi ll send the parameters to Web Service Handler which will forwarded the invocation to Risk Check System. And after the checks performed by Risk Check System, the result will be returned to Siebel via the same path. If the result is positive, another duplication check will be performed. And if the result is positive again, the contract status will be changed. And an order confirmation message will be sent to DT, via Web Service Handler also. At the same time, a notification mail will be sent to customer as 105

well. When the DT hardware is ready at customer side, DT will send a technical setup complete message to Web Service Handler to invoke the notification oper a- tion remotely. Siebel will send response to DT via the same path again. Afterwards, the entitlement process will be taken possession. Siebel will inform the Smartcard Management System by sending commands, and via Web Service Handler again. The latter will perform the activate process and entitle the contract so that the cu s- tomer can start to enjoy the services. And the notification message will be sent to DT by Siebel as well. Customer Web Frontend Siebel Web Servce Handler Risk Check System DT SMC Managment System Input Info Write API Positive Risk Check Risk Check Positive Checks Duplication Checks Orde Confirm Order Confirm Notification Email Record Contract Prepare HW Technical Setup Complete Entitlement Activate Success Entitlement Info Technical Setup Complete Entitlement Activate Success Entitlement Info Activate Figure 5-3 Sequential chart of sales and entitlement process for DT Call&Surf customer Another most important process of this project is the contract migration pr o- cess. In this project, there are two types of migration processes. The customer who has a standard SMedia contract, i.e. with DTH or Cable, can choose to migrate to SMedia@Entertain contract, i.e. with DT Internet device. But considering the economic efficiency and maintainability, to maximize the reusability of scripts, the two migration processes can be combined as one big flow which has the same e ntrance and same exit. The work flow and the relationship between each pages of this process is shown as Figure 5-4. From the flow chart we can see, the entrance is the preliminary page. If preliminary checks are passed, the migration selection page will be shown, otherwise, the process will be forwarded to an error page, and the process will be end. After the migration selection page, another group of checks will be performed. And also, 106

if the check is failed, another process error page will be displayed and end this process. The following step will be a branch according to different migration direction. Preliminary Page PassPreliminaryChecks(N) Error Page PassPreliminaryChecks(Y) Migration Seletion KO Process Error Page Migration to SE Migration to standard SMedia Existing SE Contract Question Hardware Selection OtherContract(Y) OtherContract(N) No Hardware HD, SMEDIA+ Contract Selection TOID_VO Insertation Owned Hardware Info SMC Only CI+ Hardware Attribute Selection Migration Promotion No Hardware SMC Only Migration Promotion Installation(Y) Delivery & Installation Option Send Letter Field Service Option Installation(N) Additional Address AddressConfirm(Y) Summary New Address AddressConfirm(N) Address Confirm Figure 5-4 Flow of migration processes 1) If the migration is from DTH/Cable to Internet, the next page will ask if customer already has an existing SE contract. If yes, the next page will ask CSR to select the associated SE contract. And then the TOID and commissioning data of the selected SE contract will be filled in the TOID commissioning data insertion page. If customer doesn t have an SE contract, this insertion page will be directly shown to ask CSR to input required information. After that, a migration promotion sele c- 107

tion page will be displayed to allow CSR to select promotion for this contract. After that, a page will be shown to ask if notification letter will be sent. 2) If the migration is from Internet to DTH/Cable, then the first page after the branch will be a hardware selection page. Then according to different hardware s e- lection, there will be another branch here. If the customer has his own hardware, the next page will require him to input the serial numbers of his hardware. If HD STB or SMEDIA+ STB has been selected, then hardware attribute selection will be required. If SMC Only or CI+ has been chosen, the process will be directly forwarded to migration promotion selection page. And if no hardware or SMC only option has been chosen in hardware selection page, then after promotion selection, sending letter page will appear. Otherwise, a delivery and installation option page will a p- pear. If installation option has been chosen, then the following page will ask the detailed requirements of field service, such as the available time for appointment. Otherwise, there will be an address confirmation page to ask if the hardware will be sent to the preset address of customer. If no, new address is required. No matter what the choice is, an additional address page will be displayed to ask if customer would like to input an additional address as a backup. No matter which branch has been followed, the process will be forwarded to sending letter page to ask if notification letter will be sent. And afterwards, the final page of the whole migration process will be a summary page. And the last important process is the report generating process. According to design, it includes two sub-processes. The first one is ETL process whose responsibility is to retrieve and gather data from sources and then store in the intermediate database, at last, generate CSV files following the predefined format according to required KPIs. The other one is the report generating process. It will load formatted CSV files and reorganize the data inside to draw dedicated charts, and then to export them in Excel files. And all these processes are automatic and driven by task scheduler mechanism of operating system. The flow of these module is shown as Figure 5-5. From the sequential chart, we can see. When the scheduled time comes, cron will automatically perform a pre-set task, i.e. to start the ETL process. The latter will retrieve and gather required data from CRM database. After some transformation operations, the processed data will be stored in an intermediate storage. A f- terwards, ETL module will load required data from the intermediate storage again 108

and generate CSV files which contains formatted data. The next step, which is to generate Excel reports with charts, is also activated by cron. It will firstly load CSV files. And then, it has to understand which type of charts is expected to be drawn and call related functions to export Excel files at last. Cron ETL module CRM DB Intermediate Storage File System Report Generator Acitvate Gather Data Reuired Data Transform Data Store Data Retrieve Data Required Data CSV file Activate Load File Generate Report Export Excel Report Figure 5-5 Sequential chart of report generating process 5.3 Key interfaces of the software system After the implementation, the main UIs of sales, migration process and others are more or less the same as they have been designed as mockups shown in the functional specification part. Since the target users are German, all the strings have been translated into German. For example, the summary page of migration process is shown as Figure 5-6. Besides the user interfaces, another core development point of this project is the integration of different systems. In the help of web service technology, the communication between systems can be easier to be implemented. And according to the interface design described in the technical specifications, parameters should be combined and written in XML files. The example XML file for order rejection notification is shown as Figure 5-7. 109

Figure 5-6 Summary page of migration to Internet Figure 5-7 Example XML file of order rejection notification Just as the design part mentioned, order confirmation notification is also needed to inform the DT side that all the checks during the sales proess are passed, and the contract is ready to be activated. The example XML file can be referred to Figure 5-8. 110

Figure 5-8 Example XML file of order confirmation notification And just as the typical flow of sales process for DT Call&Surf customer mentioned above, DT side should tell SMedia when the hardware of customer is ready. The notification called Technical Setup Complete is shown as Figure 5-9. Figure 5-9 Example XML file of technical setup complete notification And another important function module is customer data processing and analysis. One of its key function is the implementation of automatic process. Just like discussed in technical specifications, the task scheduler mechanism of the operation system will be used to achieve the goal of automatic process. The example of deploying the automatic process can be referred to Figure 5-10. Figure 5-10 Example of automatic process configuration 111

Figure 5-10(A) shows the shell for running ETL process for monthly report. First two lines are the configuration for java runtime environment. Figure 5-10(B) shows the shell file for generating Excel report. The dependent libraries, i.e. JFreeChart and JExcelApi, are included also for running the java file. Figure 5-10(C) shows the added records of crontab file for automatic process. The first group of the parameters describes the execution frequency following the constraints shown in Table 5-1. Table 5-1 Explanation of crontab configuration parameters Index Meaning Limitation 1 Minute 0 59 2 Hour 0 23 3 Day 1 31 4 Month 1-12 5 Weekday 0 6 P.S. * means no constraint So the meaning of added records is that on the first day of each month, process monthly report at 3 a.m., and generate Excel report at the same of the next day. And the configuration for the reports of other frequency is quite simila r, the only difference is the time setting. 5.4 System testing Before the final deployment and project delivery, test work is quite necessary for the quality control of software. In this part, a series test scenarios will be designed according to different function processes. Since it is user acceptance testing [59], all the test scenarios are based on black box testing [60] using equivalence partitioning [61] testing technology. 5.4.1 Sales The newly introduced sales process for SE contract is definitely one of the focuses of testing work. The performance of the adaption of risk checks, duplication checks for SE contract should be tested. And the behavior of different types of cu s- tomer is another key point in the testing work of sales process. The test scenarios and result of sales process can be referred to Table 5-2. 112

Table 5-2 Detail of testing work for sales process Test scenario Expected result Actual result Select a DT dealer in tab Handlerauswahl. Telekom-Shop Handelspartner Inbound CC Outbound CC Kundencenter Internet Personalverkauf Keep the field for TOID empty. Confirm the subscription. Insert a TOID number with length less than 14 character. Insert a TOID number with length of 14 character. But the TOID already associated to another contract. Insert a TOID number with length of 14 character. The TOID is not associated to another contract. Default values are correctly set and field behavior rules are correctly performed An error message appears during the confirmation process. An error message appears and the value entered is not saved. An error message appears and the value entered is not saved. The entered value is checked and it is saved since it is correct. The same as expected result. Pass. Bitte legen den Wert der 'Gerätekennung:' Feldes (Please set the value of Device number field) message appears. Pass. "Die Telekom-ID muss 14 Zeichen lang sein" (The Telekom-ID must be 14 characters long) message appears. Pass. "Die Telekom-ID ist nicht korrekt" (The Telekom-ID is not correct) message appears. Pass. The same as expected result. Pass. 113

Continued Table 5-2 Test scenario Expected result Actual result Change the value of customer category to STANDARD Change the value of customer category to VIP Change the value of customer category to DT Mitarbeiter Change the value for field Kundenkategorie to any value other than STANDARD, VIP or DT Mitarbeiter Enter the values shown in the Black list administration view. Insert a new bank account. Confirm the subscription Enter the values not shown in the Black list administration view. Insert a new bank account. Confirm the subscription The values available in field Vertragstyp are: DT Entertainkunde DT Call & Surf Kunde DT Liga Total The values available in field Vertragstyp are: DT Entertainkunde DT Call & Surf Kunde The values available in field Vertragstyp are: DT Entertainkunde DT Call & Surf Kunde DT Liga Total The values available in field Vertragstyp are all the already existed values without: DT Entertainkunde DT Call & Surf Kunde DT Liga Total The outcome of risk checks is negative, the order entry process is blocked. The outcome of Risk Checks process is positive, the order entry process can continue. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. 114

Continued Table 5-2 Test scenario Expected result Actual result Set the same bank account of an already existing contract. Confirm the subscription. Set the same bank account of an already existing contract. Confirm the subscription Insert a new bank account. Confirm the contract. Select DT Call & Surf Kunde as contract type and confirm the contract. Select a contract type other than DT Call & Surf Kunde and confirm the contract. 5.4.2 Entitlement If all the existing duplication checks are positive, the order entry process can continue. If the duplication checks are not passed, the contract enters duplicated contract handle process and marked as duplicated order. The duplication checks are passed, the order entry process can continue. The confirmed contract is in status WARTE AUF SERIEN- NUMMER. (Waiting for serial number) If all the existing checks are positive and the confirmed contract is in status VOLLSTÄNDIG, the contract is automatically activated and became "AKTIV". The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The workload of entitlement process testing work is not too much since it is an adaption work of current process. But it should also be tested properly to see the compatibility of TOID and adapted entitlement process. The detail of testing for this part is shown in Table 5-3. Table 5-3 Detail of testing work for entitlement process Test scenario Expected result Actual result Perform the following service request with a SE contract: TECHNIK/AKTIVIERUNG/ Erstaktivierung ohne Validitätsprüfung/ Aktivierung Activation command is sent to Smartcard Management System for the asset TOID in contract consistency. The same as expected result. Pass. 115

Continued Table 5-3 Test scenario Expected result Actual result Perform the following service request with a SE contract TECHNIK/FREISCHALTUNG/ Smartcard Freischaltung 2/ Freischaltung versenden. Click on Signal an Smartcard senden button Activation command is sent to Smartcard System Management for the inserted TOID asset number. The same as expected result. Pass. 5.4.3 Migration process from DTH/Cable to Internet The migration process is one of the newly implemented process of this project. And it is one of the core processes of this cooperation project. The key point of the testing work for migration process is to cover all the branches may be happened during the process. The detail of testing for migration process from DTH/Cable to Internet is listed in Table 5-4. Table 5-4 Detail of testing work for migration process from DTH/Cable to Internet Test scenario Expected result Actual result Preliminary checks Perform the migration service request for a DTH/Cable contract. Country is ÖSTER- REICH Contract status is not AKTIV, e.g. ZU AK- TIVIEREN Package status is not AKTIV, e.g. ZU AK- TIVIEREN It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. Der Wechsel auf Entertain ist nur für deutsche Kunden möglich. (The change to Entertain is only possible for German customers) message appears. Pass. Ungültiger Vertragsstatus: ZU AKTIV- IEREN. (Invalid contract status: To Activate) message is displayed. Pass Ein Programmpaket befindet sich im Status: ZU AKTIVIEREN Dies ist nicht erlaubt. (A program package is in status: To Activate. This is not allowed.) message is displayed. Pass. 116

Continued Table 5-4 Test scenario Expected result Actual result Customer is in dunning status. Contract pricelist is in the blocked list. Contract with open warehouse request. Contract with open installation order. Perform the migration service request for a DTH/Cable contract. Preliminary checks are OK. Customer does not have another SE contract, but CSR chooses Ja when the system asks. Preliminary checks are OK. Customer does not have another SE contract, and CSR chooses Nein when the system asks. Insert a TOID number that is not 14-character long. It is not possible to continue, an error message The same as expected result. Pass. is displayed. It is not possible to The same as expected result. continue, an error message Pass. is displayed. It is not possible to Offener Versandauftrag continue, an error message vorhanden. (Open shipping order) is displayed. message is displayed. Pass. It is not possible to The same as expected result. continue, an error message Pass. is displayed. Migration process Migration process is The same as expected result. blocked, since no existing Pass. SE contract can be selected. Error message is shown Die Telekom ID muss 14 Zeichen enthalten. (The Telekom ID must contain 14 characters) message is displayed. Pass. 117

Continued Table 5-4 Test scenario Expected result Actual result Preliminary checks are OK. Customer does not have another SE contract, and CSR chooses Nein when the system asks. Insert correct TOID and other information. Choose promotion. Send letter. Finish the process. Preliminary checks are OK. Customer already has another SE contract with matched bank account. Select existing SE contract and promotion. Continue to finish the process. Customer already has another SE contract but bank account does not match. Select existing SE contract and promotion. Continue to finish the process. Customer already has other SE contracts which the bank accounts of only some of them match. Select an existing SE contract and promotion. Continue to finish the process. TOID and VO-Number pages are shown. Only dedicated migration promotions are shown. After Finish button is pressed, migration process is correctly performed SE contracts associated to the same bank account are shown. Migration process is performed correctly. Associated existing SE contracts are shown with the check based on last name, first name and address. Migration process is performed correctly. Only SE contracts with matched bank account are shown. Migration process is performed correctly. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. 5.4.4 Migration process from Internet to DTH/Cable This process is just the opposite direction of previous process. The importance of this process and the key point of testing work are the same as previous one. The 118

detail of the testing work for migration process from Internet to DTH/Cable can be referred to Table 5-5. Table 5-5 Detail of testing work for migration process from Internet to DTH/Cable Test scenario Expected result Actual result Preliminary checks Perform the migration service request for a SE contract. Country is ÖSTER- REICH Contract status is not AKTIV, e.g. ZU AKTIVIEREN Package stauts is not AKTIV, e.g. ZU AKTIVIEREN Customer is in dunning status. Contract pricelist is in the blocked list. Contract with open warehouse request. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. It is not possible to continue, an error message is displayed. Der Wechsel auf Entertain ist nur für deutsche Kunden möglich. (The change to Entertain is only possible for German customers) message appears. Pass. Ungültiger Vertragsstatus: ZU AKTIV- IEREN. (Invalid contract status: To Activate) message is displayed. Pass Ein Programmpaket befindet sich im Status: ZU AKTIVIEREN Dies ist nicht erlaubt. (A program package is in status: To Activate. This is not allowed.) message is displayed. Pass. The same as expected result. Pass. The same as expected result. Pass. Offener Versandauftrag vorhanden. (Open shipping order) message is displayed. Pass. 119

Continued Table 5-5 Test scenario Expected result Actual result Contract with open installation order. Perform the migration service request for a SE contract. Preliminary checks are OK. Operator is INTERNET. Invalid phone number Valid phone number. Invalid address. Valid phone number. Valid address. Choose Standard SMedia Abo on the Vertragswechsel page. Choose HD STB. Continue the process and finish it. Choose SMEIDA+ STB. Continue the process and finish it. It is not possible to continue, an error message is displayed. Migration process The second page allows the CSR to choose the migration process: Standard SMedia Abo SMEDIA@Entertain Vertrag Option Standard SMedia Abo is selectable; the other option will be visible but greyed-out. An error message is displayed. An error message is displayed. No error message. Process can be continued. The next page, after Vertragswechsel page, will be the Hardware Choice page. Only the valid system and technology combinations are displayed. Migration process is correctly performed. Only the valid system and technology combinations are displayed. Migration process is correctly performed. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. 120

Continued Table 5-5 Test scenario Expected result Actual result Choose CI Plus Modul. Continue the process and finish it. Choose Nur Smartcard. Continue the process and finish it. Choose Keine Hardware von SMedia. Continue the process and finish it. Only the valid system and technology combinations are displayed. Migration process is correctly performed. Only the valid system and technology combinations are displayed. Migration process is correctly performed. Only the valid system and technology combinations are displayed. The serial numbers of customer are checked properly. Migration process is correctly performed. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. 5.4.5 Automatic upload in campaign This process is necessary for customer campaign. A company should take every opportunities to shoot for customers. The process is simple but useful. The detail of the testing work for this process can be referred to Table 5-6. Table 5-6 Detail of testing work for automatic upload in campaign process Test scenario Expected result Actual result Cancellation SE contract is communicated. Cancellation reason is death. Cancellation SE contract is communicated. Cancellation is other, i.e. not death. The customer will not be loaded under campaign. The contract will be ceased directly. The customer will be loaded under campaign. The same as expected result. Pass. The same as expected result. Pass. 5.4.6 Package upgrade/ downgrade/ change This is another process adapted in order to handle SE contract. Comparing to other processes, the testing of this process is also simpler. The detail of the testing work for package upgrade/ downgrade/ change process is listed in Table 5-7. 121

Table 5-7 Detail of testing work for package UG/DG/change process Test scenario Expected result Actual result Perform the following service request with a SE contract: VERTRAGSÄNDERUNG/ PAKET - GERÄTE UG/DG/WECHSEL/ Paket & Geräte UG/DG/Wechsel/ Paket & Geräte UG/DG/Wechsel Only Paket & Geräte UG/DG/Wechsel Option is selectable. Package changes are correctly performed. The same as expected result. Pass. 5.4.7 Data change The position of this process is somehow a little similar to the process of package upgrade/ downgrade/ change. It is also an enhancement for current process. The detail of this testing is shown in Table 5-8. Table 5-8 Detail of testing work for data change process Test scenario Perform the following service request with a SE contract: KUNDENDATEN/ KUNDENDATEN/ Kundendatenänderung/ Änderung Kundendaten Change address. Save the changes. Expected result A result message is displayed. Actual result Änderung durchgeführt, es ist keine neue Hardware erforderlich (Change is made, there is no new hardware required) message is displayed. Pass. 5.4.8 Revocation, cancellation and revocation of cancellation This group of processes will affect the termination of customer s SE contract. It will also affect the impression of customer to SMedia. Customer should have the ability to cancel the process he just made and can decide to terminate the contract at any time. The test scenarios and results for this group of processes are shown in Table 5-9. 122

Table 5-9 Detail of testing work for revocation, cancellation process Test scenario Expected result Actual result Revocation Perform the following service request with a SE Smartcard Management contract: System is invoked KÜNDIGUNGSMANAGEMENT/ WIDERRUF/Widerruf Neukunde Run revocation batch. through the new interface. TOID status is changed into NEU (NEW) and de-associated from the contract Cancellation Perform the following service request with a SE contract: KÜNDIGUNGSMANAGEMENT/ KÜNDIGUNGSRÜCKNAHME/ Kündigung zu sofort (Cancel immediately) Run cessation batch. Perform the following service request with a SE contract: KÜNDIGUNGSMANAGEMENT/ KÜNDIGUNGSRÜCKNAHME/ Kündigung zum Monatsende (Cancel at the end of this month) Run cessation batch Perform the following service request with a SE contract: KÜNDIGUNGSMANAGEMENT/ KÜNDIGUNGSRÜCKNAHME/ reguläre Kündigung (Regular cancellation) Run cessation batch Smartcard Management System is invoked through the new interface. TOID status is changed into NEU (NEW) and de-associated from the contract Smartcard Management System is invoked through the new interface. TOID status is changed into NEU (NEW) and de-associated from the contract Smartcard Management System is invoked through the new interface. TOID status is changed into NEU (NEW) and de-associated from the contract The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. The same as expected result. Pass. 123

Continued Table 5-9 Test scenario Expected result Actual result Perform the following service request with a SE Smartcard Management contract: System is invoked KÜNDIGUNGSMANAGEMENT/ KÜNDIGUNGSRÜCKNAHME/ Kündigung Sonderkunde (Cancellation of special through the new interface. TOID status is changed into NEU (NEW) and customer) de-associated from the Run cessation batch. contract Revocation of Cancellation Perform the following service request with a SE Cancellation is correctly contract: revoked. KÜNDIGUNGSMANAGEMENT/ KÜNDIGUNGSRÜCKNAHME/ Kündigungsrücknahme/Kündigungsrücknahme The same as expected result. Pass. The same as expected result. Pass. 5.4.9 Generate report This process is the final one of the whole project. The function is simple but essential. And the mechanism inside is somehow quite complex. The comparison work between output report and the actual data in the database should be very carefully. A difference comparison tool should be used in the testing work for this process. The detail of test scenarios and actual results are listed in Table 5-10. Table 5-10 Detail of testing work for generating report process Test scenario Expected result Actual result Create some contracts, including standard SMedia and SE contracts. Run ETL process manually. Load a CSV file to generate Excel report with line chart. The increased number for each type of contract should be reflected in the new output CSV file. The data shown in Excel file is correct. The line chart reflects the data properly. The same as expected result. Pass. The same as expected result. Pass. 124

Continued Table 5-10 Test scenario Expected result Actual result Configure the cron configuration file to set the frequency as every five minutes. 5.5 Brief summary The ETL process and report generator will be executed automatically every five minutes. The same as expected result. Pass. In this chapter, the implementation of the whole system was described. At the beginning, the whole structure of the system and the integration between CRM system and other systems were captured and presented. Afterwards, the flow charts or sequential charts of each module have been discussed and explained to show how this system works finally. In the third part, some examples XML files which are the communication interfaces between Siebel and DT are shown. And another example is shown also, in order to explain how to deploy the automatic process for genera t- ing reports. After the implementation, testing work should be performed. And se v- eral test scenarios for each segment have been designed to assure the quality of the whole system. 125

Conclusion In this CRM system enhancement project, mainly two problems have been solved. On one hand, a new CRM process and related system module should be designed to handle the customer care for new type of customers. On the other hand, the system should be integrated with other systems, including internal systems and external systems. In this thesis, a CRM process which covers the whole customer lifecycle was designed. It considered not only new customers, but also existing customers. And these two types of customers have been united, there are no isolated situation. Current resources can be reused maximize. And for the second problem, considering different performance of EAI and web service, a solution which co m- bines both of them was proposed. For the communication between internal systems, efficiency and real time are what they chase for. Therefore, EAI is a good choice although it sacrifices the flexibility. On the contrary, versatility and the ability of cross-platform are the basic requirements for the communication between external systems. In that case, web service technology is more suitable because of its loose coupling but which leads to the consequence of poor performance. Currently, the CRM enhancement project only focuses on some urgent business functions that are the basic requirements for starting the cooperation. In further steps, some parts can still be improved. For example, firstly, the user interfaces can be redesigned to support different languages. Because in nowadays, more and more labor-intensive work is outsourced to the regions with lower human cost. For e x- ample, an American customer calls the phone number of customer care, and he may be answered by an Indian guy. That is because the work of call center is outsourced to a third party company. This kind of thing will become more and more common in the future. Considering this, the UI which supports multi language and can be localized is definitely necessary to increase the work efficiency. Secondly, more powerful data mining technologies can be introduced into customer data processing and analysis module. As mentioned in the requirements part, since the cooperation just started, the technologies like forecasting are impractical. These kinds of data mining need a large quantity of data to be referenced. But once it had enough resources and was implemented, it can be very useful. It can help to making marketing and sales strategies for different area during different period. 126

References [1] Winer R. S., A Framework for Customer Relationship Management[R], California Management Review, 2001 [2] Motta G, Pignatelli G, Barroero T, et al. Service level analysis method-slam[c], Computer Science and Information Technology (ICCSIT), 2010 3rd IEEE International Conference on. IEEE, 2010 [3] W3C Web Sevice Architecture Working Group, Web Service Architecture[S/OL], http://www.w3.org/tr/2004/note-ws-arch-20040211/, 11/02/2004 [4] Johanna Ambrosio, EAI vs. Web services: Different answers to the same prob-lem[r/ol], http://searchoracle.techtarget.com/tip/eai-vs-web-services-different-answers-t o-the-same-problem, 2001 [5] Zhou Jintao, Wang Mingwei, Web Services Vs. EAI: Comparison and Analy-sis[R/OL], http://www.ibm.com/developerworks/cn/webservices/ws-wseai/index.html [6] TechMetrix Research, Web Services and EAI Partners or Rivals?[R/OL], http://www.ebizq.net/topics/eai/features/1555.html, 2002 [7] Robert Shaw, Computer Aided Marketing and Selling : Information Asset Man-agement[M], Butterworth Heinemann, 1991 [8] Atul Parvatiyar1, Jagdish N. Sheth, Customer Relationship Management: Emerging Practice, Process, and Discipline[J], Journal of Economic and Social Research, 3(2) 2001 [9] Weina Guo, Weihua Liu, Business Process Reengineering based on customer rela-tionship management strategy[c], IEEE Information Management and Engineering (ICIME), 04/2010 [10]Rashi Glazer, Winning in Smart Markets[J], Sloan Management Review, Summer, 1999 [11]Joseph O. Chan, Toward a Unified View of Customer Relationship Manage-ment[J], The Journal of American Academy of Business, Cambridge, March 2005 [12]Matteo Golfarelli, Stefano Rizzi. Data Warehouse Design - Modern Principles 127

and Methodologies[M], McGrawHill, 2009 [13]Ralph Kimball, et al.. The Data Warehouse Lifecycle Toolkit[M], Wiley, 2008 [14]Michel Wedel, Wagner A. Kamakura, Market Segmentation: Conceptual and Methodological Foundations, 2nd edition[m], Kluwer Academic Publishers, 1999 [15]Alorie Gilbert, Rivals vie for Siebel's customer spoils[ol], http://news.com.com/rivals+vie+for+siebels+customer+spoils/2100-1017_3-9 59878.html [16]Oracle, Siebel Customer Relationship Management (CRM) Applications Over-view[OL], http://www.oracle.com/us/products/applications/siebel/overview/index.html [17]Wayne Hywari, Siebel 8.0 Essentials[S/OL], Oracle, 2007 [18]Patrick Lambe, Knowledge-Based CRM: A Map[R], 2011 [19]Paul D. Berger, Nada I. Nasr, Customer Lifetime Value: Marketing Models and Applications[J], Journal of Interactive Marketing, Volume 12, Number 1, Winnter, 1998 [20]J-P De Clerck, Understanding the Customer Life Cycle and Calculating its Val-ue[R/OL], http://www.fusionmarketingexperience.com/2009/09/understanding-the-custom er-life-cycle-and-calculating-its-value/, 2009 [21]Chingwei Peter Cheng, Lee Sang, Methods and Systems for Customer Lifecycle Definition and Categorization[P], United States Patent, Dec. 19, 2006 [22]Jim Sterne, Matt Cutler, E-Metrics, Business Metrics For The New Economy[R], NetGenesis Corp., 2000 [23]Hee-Woong Kim, A Process Model for Successful CRM System Develop-ment[C], IEEE Software, 2004 [24]Chang Chih-Huang, et al., An Experience of Applying Pattern-based Software Framework to Improve the Quality of Software Development[J], Journal of Software Engineering Studies, 2008 [25]Panos Vassiliadis, Alkis Simitsis, Extraction, Transformation and Loading[R], Encyclopedia of Database Systems, 2008 [26]Erhard Rahm, Hong Hai Do, Data Cleaning: Problems and Current Approaches[C], IEEE Computer Society Technical Committee on Data Engineering, 2000 [27]Roger N. Nagel, Rick Dove, 21st Century Manufacturing Enterprise Strategy: 128

An Industry-led View[M], DIANE Publishing, 1991 [28]Zoonky Lee, Jinyoul Lee, An ERP implementation case study from a knowledge transfer perpective[j], Journal of Information Technlogy, 15, 2000 [29]Jinyoul Lee, Keng Siau, Soongoo Hong, Enterprise Integration with ERP and EAI[J], Communications of the ACM, Vol.46, No.2, 2003 [30]TechTarget, EAI and Web Services Overview[R/OL], http://www.bitpipe.com/eai/eai_overview.jsp [31]Johanna Ambrosio, EAI vs. Web services: Different answers to the same prob-lem[r/ol], http://searchoracle.techtarget.com/tip/eai-vs-web-services-different-answers-t o-the-same-problem [32]Chai Xiaolu, EAI and Webs Service Easy to Perform Enterprise Application Integration[R/OL], http://www.ibm.com/developerworks/cn/webservices/ws-eai/cxl/?s_tact=105 AGX52&S_CMP=tec-cto, 2001 [33]Hugo Haas, Allen Brown, Web Services Glossary[S/OL], W3C Working Group Note, http://www.w3.org/tr/2004/note-ws-gloss-20040211/#webservice, 2004 [34]Tim Berners-Lee, Web Services: Program Integration across Application and Or-ganization boundaries[r/ol], http://www.w3.org/designissues/webservices.html, 2009 [35]Martin Gudgin, Marc Hadley, et al., SOAP Version 1.2 Part 1: Messaging Frame-work (Second Edition)[S/OL], http://www.w3.org/tr/soap12-part1/, W3C Recom-mendation, 2007 [36]Erik Christensen, Francisco Cubera, et al., Web Services Description Language (WSDL) 1.1[S/OL], http://www.w3.org/tr/wsdl, 2001 [37]Tom Bellwood, et al., UDDI Version 3.0.1: UDDI Spec Technical Committee Specification[S/OL], http://uddi.org/pubs/uddi-v3.0.1-20031014.htm, 2003 [38]Solomon Negash, Business Intelligence[J], Communications of the Association for Information Systems, Volume 13, 2004 [39]Matteo Golfarelli, Stefano Rizzi, Iuris Cella, Beyond Data Warehousing: What s Next in Business Intelligence? [C], DOLAP '04 Proceedings of the 7th ACM interna-tional workshop on Data warehousing and OLAP, 2004 [40]Neil Kokemuller, What Are CRM and BI Systems? [R/OL], 129

http://www.ehow.com/facts_6873225_crm-bi-systems_.html [41]Hall J. Business Intelligence: The Missing Link in Your CRM Strategy[J]. DM REVIEW, 2004 [42]Rick Cook, A Step Beyond CRM: Integrating Business Intelligence[R/OL], http://www.insidecrm.com/articles/crm-blog/a-step-beyond-crm-integrating-bus iness-intelligence-55344 [43]Aida Habul, Amila Pilav-Velic, Emir Kremic, Customer Relationship Management and Business Intelligence[M], Advances in Customer Relationship Management, InTech, 2012 [44]Bolchini D, Paolini P. Capturing Web Application Requirements through Goal-Oriented Analysis[C], WER. 2002 [45]Motta G, Sacco D, Barroero T. A SME-oriented extension of Agile development process[j]. CERSI, 2012 [46]About OMG [OL], http://www.omg.org/gettingstarted/gettingstartedindex.htm [47]OMG, Business Process Model and Notation (BPMN) Version 2.0[S], http://www.omg.org/spec/bpmn/2.0, 2011 [48]Carol Taylor Fitz-Gibbon, Performance Indicators: BERA Dialogues[M], Multi-lingual Matters, 1990 [49]Norman E. Fenton, Shari Lawrence Pfleeger. Software Metrics: A Rigorous and Practical Approach, 2nd Edition[M], Course Technology, 1998. [50]Allen Macro, John Buxton. The Craft of Software Engineering[M], Addi-son-Wesley, 1987. [51]Douglas A. Troy, Stuart H. Zweben. Measuring the Quality of Structured De-signs[J], Journal of Systems and Software, Vol. 2, 1981. [52]About AIX[OL], http://www-03.ibm.com/systems/power/software/aix/about.html [53]JFreeChart.org, Welcome To JFreeChart![OL], http://www.jfree.org/jfreechart/ [54]Java Excel API - A Java API to read, write, and modify Excel spreadsheets[ol], http://jexcelapi.sourceforge.net/ [55]Oracle. Java Platform, Standard Edition 7 API Specification[S/OL], http://docs.oracle.com/javase/7/docs/api/ [56]Matthias Kalle Dalheimer, Matt Welsh. Running Linux, 5th Edition[M]. O'Reilly Media, 2005 [57]Codd E.F., Codd S.B., Salley C.T., Providing OLAP (On-line Analytical 130

Pro-cessing) to User-Analysts: An IT Mandate[M], Codd & Date, Inc., 1993 [58]DwhWorld, DWH Schemas[R/OL], http://www.dwhworld.com/dwh-schemas/, 2010 [59]Davis F D, Venkatesh V. Toward preprototype user acceptance testing of new infor-mation systems: implications for software project management[j]. Engineering Man-agement, IEEE Transactions on, 2004 [60]Beizer B. Black-box testing: techniques for functional testing of software and systems[m]. John Wiley & Sons, Inc., 1995. [61]Reid S C. An empirical analysis of equivalence partitioning, boundary value analysis and random testing[c], Software Metrics Symposium, 1997. Proceedings., Fourth International. IEEE, 1997 131

Acknowledgement Finally, the written work of my thesis is coming to an end.i am so proud and honored that I could have the opportunity to be a student under Prof. Deng and Prof. Motta s supervision. Prof. Deng gave me so many advises during my thesis written period. You provided me a clear direction which I should follow and concentrate one. And Prof. Motta, your lectures made me first time to try to think about problems in another view point. Hereby, I want to thank you both very much. Thank you a lot Prof. Loparco. You provided me the opportunity of internship in Deloitte which lead to the choice of this topic of my thesis. Your lecture of CRM is also one of the theoretical basis of this thesis. Thank you very much Andrea and Paolo. You helped me choose the project and review my thesis again and again. There would be no this thesis without your effort. You know how much I appreciate. Thank you very much Riccardo. Thank you for giving me a position in your team. Although you were quite busy, you still responded me very promptly every time. And also thank to my colleagues. Your patience and kindness help me a lot during my internship period. Thank you very much, Daniele and You Linlin. You helped me a lot during my life in Italy. And especially to You Linlin, thank you for your effort in my thesis also. And thank you, Lin Fengfeng, for helping me review my thesis proposal and giving me many suggestions. Thanks a lot to my relatives and friends, my parents, grandparents, and my classmates. No matter when, your supports are my courage to move on. 132

Resume Personal Data Name: Zhang Yan Gender: Male Birthday: December 12, 1988 Address: Via de Carlo, No. 28, Pavia, Italy Mobile Phone: +39-3276242750 Email: zhangyan19881212@163.com Education Background 2012.9 to present Computer Engineering, UNIPV Master 2011.9 to present Software Engineering, HIT Master 2007.9 to 2011.7 Software Engineering, HIT Bachelor Computer Knowledge Level Proficient with C# and Java programming. Familiar with C\C++ programming. Familiar with Android application development. Familiar with SQL. Familiar with SilkTest automation testing tool. Familiar with software engineering, object-oriented analysis and design principles, and UML. Foreign Language Level Passed CET4, 6, have a good English ability Very basic French and Japanese reading ability Work Experience 2010.7-2011.6 Autodesk China Research & Development Position: QA Intern 2013.2-2013.8 Deloitte Consulting Srl Position: Analyst Intern 133