How MLP Realized the Four Recommendations

By | February 9, 2018

With its business model and supporting IT architecture, MLP has realized the four recommenda- tions mentioned in the previous section:

 

  1. Distribute disjoint CRM competencies among partners of an alliance: Each subsidiary com- pany of MLP AG focuses on specific tasks as its core In particular, each subsidiary focuses on one role in the value chain: product provider or relationship manager. For example, MLP Bank is responsible for the provision of banking products, whereas MLP Finanzdienstleistungen is responsible for the integration of products for customers.
  2. Establish single point of entry for customers: Each MLP customer has one customer consultant responsible for every aspect of the customer’s personal financial manage- ment. Consultants and customers are supported by the finance pilot, which realizes an integrated view of a customer.
  3. Establish transparency regarding customer knowledge among partner companies: Cus- tomer data that are important to different MLP subsidiary companies are consolidated and stored in a central database (broker pilot). Contract- and product-related data are stored at the respective MLP product provider but can be merged with customer master data—by the finance pilot—using a unique customer ID and contract IDs.

 

  1. Integrate CRM systems of different partner companies: Operational CRM systems (con- sulting and contracting applications), analytical CRM systems (data warehouses), and transaction systems (broker platforms) are tightly integrated to support CRM processes in an integrated way.

To realize the recommendations, MLP uses a supportive application infrastructure with the following characteristics:

  • Highly modular application systems: CRM systems and transaction systems are not mono- lithic, but highly modular and distributed to ensure flexibility and short time-to-market for new products.
  • Central database for customer master data: Customer master data are stored centrally in the broker pilot database to ensure consistency.
  • Joint data model with unique customer ID: To integrate customer master data, contract data, and transaction data related to a specific customer, MLP uses a joint data model and a unique customer ID with which each customer can be identified in any application system.
  • Integrated processes across applications: Contracting and transaction processing are car- ried through via integrated processes over several different application systems.
  • Customer data integration via views: Customer master data from the central database, con- tract data, and transaction data from the broker platforms are integrated in the finance pilot using an integrated view of these different data sources.

 

With this state-of-the-art architecture, MLP can serve as ‘best-practice’ example for financial services alliances that face the abovementioned challenges regarding collaborative customer management.

 

CONCLUSIONS AND FURTHER RESEARCH

 

The emergence of financial services alliances has led to challenges related to an integrated approach to CRM among partner companies. Whereas, on the strategy level, the elimination of redundant competencies among partner companies has the potential to provide opportunities for improvement, the main inhibitors of integrated CRM can be found on the process and systems level.

Both product providers and relationship managers often have customer-oriented business pro- cesses with incomplete customer knowledge. Moreover, redundant tasks are undertaken by more than one company in an alliance, for example, the detection of a customer’s external exposure. Having different contact persons for each product, some alliances have still not implemented the idea of one-stop finance for customers. This is especially evident in after-sales service manage- ment and complaint management processes.

Most challenges in interorganizational CRM processes can be traced to the limitations of the information systems infrastructure. An incomplete standardization of the CRM processes and systems inhibits the exploitation of economies of scale as well as inhibiting systems integration. Consequently, a limited integration of systems containing customer knowledge, such as opera- tional and analytical CRM systems as well as transaction systems, complicates the process of obtaining a comprehensive view of a customer relationship. An increased integration of these systems suggests an opportunity not only to improve the quality of customer consultancy, but also to improve the exploitation of a customer’s potential. We derived the following recommen- dations from our analysis of financial services alliances:

  • Distribute disjoint CRM competencies among partners of an alliance.
  • Establish a single point of entry for customers.
  • Establish transparency regarding customer knowledge among partner companies.
  • Integrate the CRM systems of different partner companies.

 

Finally, we presented a best-practice case study of MLP to show how these recommendations can be realized using state-of-the-art technology. The MLP application architecture has the fol- lowing characteristics: It has highly modular application systems, a central database for customer master data, a joint data model with unique customer ID, integrated processes across applications, and integration of customer data via views. MLP can serve as “best-practice” example for finan- cial services alliances that face challenges regarding collaborative customer management.

Our study provides the initial basis from which CRM application architecture should be de- signed in financial services alliances. However, to develop detailed guidelines for such an archi- tecture, it is necessary to conduct further research. Our objective is to analyze financial services alliances’ CRM application architectures to derive guidelines in the form of a reference applica- tion architecture that can overcome the shortcomings observed. Using additional case studies and quantitative empirical research, we shall try to develop and validate such an architecture.

NOTES

An earlier version of this article was presented at the 2004 Americas Conference on Information Sys- tems (AMCIS 2004). (Geib et al. 2004)

  1. For an assessment of current research on CRM, see Romano and Fjermestad (2003).
  2. We are aware that, especially in Europe, data privacy protection laws play an important role in the exchange of customer data between different partner companies. Nevertheless, in this paper we do not contribute to this discussion, as this topic has been extensively For a detailed discussion see Bennett (1997), Fjetland (2002), Klosek (2000), Smith (2001).
  3. In certain instances, confidentiality rules do not allow us to specify the financial network and the details of the architecture to which we
  4. For a detailed discussion of the effects of EAI technology, see Linthicum (2000), Ruh et al. (2001).

 

Leave a Reply

Your email address will not be published. Required fields are marked *