On the strategy level, we observed that all of the companies cooperate horizontally with other financial services companies or divisions offering complementary products. Except for the two universal banks, the companies are part of financial services alliances with vertical cooperation, i.e., between product providers and relationship managers (mainly banks). In contrast, the univer- sal banks have their own product-oriented divisions and distribution organizations.
The companies mentioned four strategic objectives of cooperation with partner companies. The two most prevalent ones were ‘comprehensive coverage of financial demands of custom- ers’ and ‘new distribution channels and customers.’ The fact that these objectives were men- tioned for horizontal as well as vertical collaboration illustrates that they can be achieved by either collaboration. They also emphasize the importance of trend 1 (integration on customer side, see Figure 6.1). In addition, LCB mentioned ‘economies of scale’ as a major objective of collaboration with other cantonal banks. The reason is that, as a small relationship manager, LCB can achieve improvements in productivity by using the same CRM systems as other can- tonal banks to support standardized CRM processes. Moreover, LCB sees the standardization of products and processes as a prerequisite to the standardization of systems, which itself is a prerequisite for IT outsourcing (trend 3).
Finally, UBS GAM sees the merging of customer knowledge owned by different divisions of UBS as its major goal, the aim being to create a more complete view of customers to better address their needs and to identify prospects.
Regarding challenges on the strategy level, three companies mentioned overlapping compe- tencies in different partner companies (or business units in the case of UBS GAM) as a major challenge. This can lead to redundantly executed processes (see next section) with inconsistent results. Moreover, in alliances between legally independent companies, data privacy protection can inhibit the exchange of customer knowledge.
On the process level, we analyzed collaboration in the CRM processes (see Figure 6.2) as well as in product development.
Although all companies cooperate with partners in product development, cooperation is often not strategic, but reactive to market demands. For example, HLB and IB offer a compos- ite product in reaction to changing market demands as a result of changing regulations. UBS GAM jointly develops complex products with other business units to address institutional in-
vestors’ demands. In contrast, LCB jointly standardizes commodity products with other can- tonal banks in order to achieve economies of scale by using the same CRM processes and supporting information systems.
Strong collaboration can also be found in marketing. Most partner companies conduct joint market research activities. Some campaign management activities are also performed jointly, especially with respect to composite products.
Cooperation focuses mainly on sales processes, particularly lead management and offer man- agement, where cooperation can lead to direct results in the form of additional turnover. Regard- ing lead management, three companies exchanged customer information—identified only by customer numbers—with partner companies to tap the potential of the partner’s customers. As far as offer management is concerned, most companies also offer their partner companies’ products. There is usually a “preferred provider” status between partner companies; i.e., the partners’ prod- ucts are preferably sold to their own customers.
The least intensive cooperation was observed in service management and complaint manage- ment processes. These processes are mostly handled by each partner company individually for its respective products, because collaboration would require the exchange of extensive customer and product knowledge, which the underlying CRM systems do not support. Consequently, a customer of a financial alliance often has multiple contact persons in the various companies of the alliance. The most prevalent challenges on the process level were:
- Insufficient transparency regarding customer knowledge: Due to legal constraints and bank- focused CRM technology (see next section), product providers have customer knowledge related only to their specific product and do not, therefore, have a complete overview of their own customers, let alone customers of their partner companies. Only banks with direct con- tact with customers can obtain a complete overview of a customer’s characteristics and product use. Strict data privacy protection laws often prevent banks from sharing customer knowl- edge with their product providers.
- Redundant tasks: To obtain or update specific knowledge about customers, product provid- ers and distributors sometimes undertake redundant tasks, for example, changing a customer’s address or determining a customer’s estimated credit rating, financial circumstances, and external exposure.
- Different contact persons for a financial alliance customer (no ‘single point of entry’): Cus- tomers often have different contact persons—sometimes one for every product they own—in a financial alliance. This is especially prevalent in complaint and service management processes.
In conclusion, we observed that all companies cooperated in CRM processes and product development, with a focus on sales processes. Nevertheless, most cooperation is reactive to mar- ket demands or confined to the development and distribution of composite products. More com- prehensive cooperation, especially in service management and complaint management processes, is hindered by insufficient transparency regarding customer knowledge and redundant task distri- bution between partner companies.
On the system level, we observed that in most financial services alliances there is a wide variety of separate analytical and operational CRM systems as well as of different transaction systems that are not standardized or seamlessly integrated.
An exemplary CRM application architecture of one financial alliance we studied is shown in Figure 6.3. Each product provider operates its own application systems—transaction systems and operational CRM (oCRM) systems (Gebert et al. 2003)—containing all relevant knowl- edge about customers (e.g., the contacts and characteristics of a customer’s products). More- over, many product providers have an infrastructure for analytical CRM, including a data warehouse. Various relationship managers (banks), which jointly own a transaction processor (Figure 6.1) in order to achieve economies of scale, are the product providers’ main distribu- tors. The transaction processor operates the transaction systems for all banks. Moreover, it hosts copies of the product providers’ operational CRM systems to give the banks’ customer consultants insight into the customer information owned by the product providers. In one of the financial alliances we studied, a bank’s customer consultants have to cope with its product providers’ approximately 30 different operational CRM systems. In addition, to provide cus- tomer consultants with an overview of the products owned by a customer, each product pro- vider regularly transmits the most important, aggregated customer information to the transaction processor. This information is then integrated into a customer information system, comprising aggregated customer information from all product providers.
In addition to data exchange with the transaction processor, some product providers also ex- change anonymous customer data to support the decentralized lead management processes of each product provider (see previous section). Usually the exchange is informal and achieved via flat files.
The main challenge on the system level is that the wide variety of separate CRM systems and transactional systems inhibits an integrated view of customers. We noted the following shortcom- ings in particular: