VEDLEGG INF5120 Side 1 av 8 Problem Example Mobile phone after-sale services The problem example is based on a real life situation involving system interactions between ERP and CRM applications, in the context of a Telco Company selling telephone related products through two kinds of distributors, franchisees and dealers. The goal in this exam is to create a platform independent architecture model showing the necessary interfaces between the involved ERP system and CRM systems in the dealer situation for the post-sales service phase described below. The organisation of the Telco Company is the following The main branch of the Telco Company (called franchisor in the following) owns several ESA (Enterprise Software Applications, such as (ERP, CRM, WMS, etc.)) to manage its activities and centralise data about end-customers, products, warehouses, etc. In order to distribute its products and services the franchisor has set up a network of distributors playing the role of front end for end customers. Two kinds of distributors exist mainly: franchisees and dealers. The franchisees are distributors with an exclusivity contract with the franchisor: they can only propose products and services related to the Telco Company to end-customers. In order to manage their activities, the franchisor provides the franchisees with ESA (Retail system, CRM, etc. but with limited functionalities) compatible with the ones of itself. The problem is then to define interoperability between the applications especially between the local versions of the CRM and Retail System and the franchisor s ERP and CRM. The dealers are distributors which can contract with other companies than Telco. They may have their specific ESA, and therefore, the problem is to define the interoperability needs and make the dealers applications interoperable with the ones of the franchisor within a heterogeneous context. Franchisor ERP CRM WMS Other INTRANET Retail CRM System Lim. Franchisee (Store) Retail CRM System Lim. Franchisee (Store) Specific Retail Specific System CRM Dealer (Store) Customers Figure 1 Interactions between Franchisor and Franchisee/Dealers VEDLEGG INF5120 Side 1 av 8
VEDLEGG INF5120 Side 2 av 8 In this exam we will focus on a subset of the interactions between these systems, in particular on the Franchisor (ERP/CRM) and Dealer interactions (CRM) for after-sales.as shown below. Figure 2 Main focus: After sales process between Franchisor and Dealer In After Sales services we have the following electronic interactions: Create Customer Record into the CRM on Franchisor side Receive Customer data from Retail/Franchisor system Transfer electronically the repair request to the Franchisor Transfer the dealer invoice In general, the interoperability needs are described as follows: VEDLEGG INF5120 Side 2 av 8
VEDLEGG INF5120 Side 3 av 8 The after sales service deals mostly with customer service requests and repairs. Regarding repairs, their handling is mostly performed from the CRM application due to the fact that the procedure is executed from front-end personnel (e.g. Employees in a department store, etc.), who use the CRM application. Interoperability needs cover the following: Update CRM with customer transactions: This information is useful because it provides input to the CRM users about the customer s behaviour to the enterprise. For example, in order to define a Service Level Agreement, the company needs to know how active the customer was in terms of sales, support, etc. so it can define its support strategy. This kind of information will also be helpful to the sales personnel in terms of definition of a sales campaign, promotion strategy, etc. Creation of ERP documentation from CRM: CRM needs to send the appropriate set of data to the back office application (ERP) in order to produce the necessary documentation (Packaging slips, invoices, etc.). Update CRM with customer transactions, as described above. VEDLEGG INF5120 Side 3 av 8
VEDLEGG INF5120 Side 4 av 8 Figure 3 Enlarged version of figure 2 - for enhanced readability of the interface VEDLEGG INF5120 Side 4 av 8
VEDLEGG INF5120 Side 5 av 8 Measurement unit Warehouse 1..* Currency primary UoM product currency secondary UoM 1..* Product product code product classification conversion coeff supply type VAT code 1..1 1..* account of general accounting Product price list product code product price 1..* Commercial actor types 0..* Price list price list code description commercial var start date end date Customer code name address CCIA fiscal code phone 1..1 fax RIBAauth RIDauth VAT number 0..* Order Bank VAT codes Payment conditions Payment methods Figure 4 Customer and Product Information model The information model above shows some of the typical information handled by the ERP and CRM systems, related to products (such as phones and services) and to the customer, and which will be subject to transfer of information between the systems. VEDLEGG INF5120 Side 5 av 8
VEDLEGG INF5120 Side 6 av 8 OMG CORBA _- Common Object Request Broker Architecture The interactions between two or more systems and services can be supported through the CORBA architecture, which supports the description of the interfaces of these through the OMG IDL (Interface Definition Language). Application Objects Vertical CORBA Facilities Horizontal CORBA Facilities Object Request Broker (CORBA) Interfaces described in CORBA Services CORBA IDL (Interface Definition Language) The CORBA IDL works similar to the Web Services WSDL, by describing the interfaces of the available applications and services. We can view the ERP and CRM systems as two interacting application objects in this case. IDL EXAMPLE //OMG IDL example File //Object Management Group, Inc. // // //Example IDL syntax interface definitions // interface B { attribute A mya; // Will support a get_mya and a set_mya operation }; interface TestInterface { struct TestStruct { string Member1; }; attribute string MyStringAttr; attribute TestStruct MyStructAttr; VEDLEGG INF5120 Side 6 av 8
VEDLEGG INF5120 Side 7 av 8 // attribute is a virtual attribute, representing corresponding get/set operations }; void MyOp1( in string str, inout TestStruct t); boolean MyOp2( inout TestStruct t); interface PrettyPrint { string print(); }; OMG IDL (Interface Definition Language) Syntax Simplified BNF grammar specification > (1) <specification> ::= <import>* <definition>+ (2) <definition> ::= <type_dcl> ; <interface> ; (4) <interface> ::= <interface_dcl> (5) <interface_dcl> ::= <interface_header> { <interface_body> } (7) <interface_header> ::= [ abstract local ] interface <identifier> [ <interface_inheritance_spec> ] (8) <interface_body> ::= <export>* (9) <export> ::= <type_dcl> ; <attr_dcl> ; <op_dcl> ; (10)<interface_inheritance_spec>::= : <interface_name> {, <interface_name> }* (42) <type_dcl> ::= typedef <type_declarator> <struct_type> <union_type> <enum_type> native <simple_declarator> <constr_forward_decl> (43) <type_declarator> ::= <type_spec> <declarators> (44) <type_spec> ::= <simple_type_spec> <constr_type_spec> (45) <simple_type_spec> ::= <base_type_spec> <template_type_spec> <scoped_name> (46) <base_type_spec> ::= <floating_pt_type> <integer_type> <char_type> // similar for all basic types (deleted here) (48) <constr_type_spec> ::= <struct_type> <union_type> <enum_type> (49) <declarators> ::= <declarator> {, <declarator> } VEDLEGG INF5120 Side 7 av 8
VEDLEGG INF5120 Side 8 av 8 (50) <declarator> ::= <simple_declarator> <complex_declarator> (51) <simple_declarator> ::= <identifier> (52) <complex_declarator> ::= <array_declarator> (53) <floating_pt_type> ::= float double long double (54) <integer_type> ::= <signed_int> <unsigned_int> ///.. and similar for all basic types..(deleted here) (80) <sequence_type> ::= sequence < <simple_type_spec>, <positive_int_const> > sequence < <simple_type_spec> > (81) <string_type> ::= string < <positive_int_const> > string (82) <wide_string_type> ::= wstring < <positive_int_const> > wstring (83) <array_declarator> ::= <identifier> <fixed_array_size>+ (84) <fixed_array_size> ::= [ <positive_int_const> ] (85) <attr_dcl> ::= <readonly_attr_spec> <attr_spec> (87) <op_dcl> ::= [ <op_attribute> ] <op_type_spec> <identifier> <parameter_dcls> (88) <op_attribute> ::= oneway (89) <op_type_spec> ::= <param_type_spec> void (90) <parameter_dcls> ::= ( <param_dcl> {, <param_dcl> } ) ( ) (91) <param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator> (92) <param_attribute> ::= in out inout (95) <param_type_spec> ::= <base_type_spec> <string_type> <wide_string_type> <scoped_name> (98) <value_base_type> ::= ValueBase (99) <constr_forward_decl> ::= struct <identifier> union <identifier> (104) <readonly_attr_spec> ::= readonly attribute <param_type_spec> <readonly_attr_declarator> (105)<readonly_attr_declarator >::= <simple_declarator> <raises_expr> <simple_declarator> {, <simple_declarator> }* (106) <attr_spec> ::= attribute <param_type_spec> <attr_declarator> VEDLEGG INF5120 Side 8 av 8