Dears,
In this concluding part of the article lets investigate little more on the Integration of Collaborative, operational and analytical functions for CRM Excellence
The distinction between the collaborative, operational and analytical functions is clearly recognized in CRM, where all three need to combine in a closed-loop approach for business success. Collaborative functions support the communication with the customer via Web-chat or, more traditional, e-mail, telephony, face-to-face or intermediary support applications. Operational functions provide (ideally the single point of) access to customer data and are the basis for automating customer or product marketing and servicing tasks. These are the 'systems of record' or 'legacy systems' (where the definition of legacy seems to be that the system has achieved production status!). Analytical functions provide data consolidation for analytics, mining for segmentation, trends and predictions in customer behaviour, often using complex mathematical models. Analytical functions can also provide measures on the effect of CRM initiatives, thus closing the loop.
It is easy to see that the potential for poor integration of these three dimensions is huge. It starts within one category, for example, contact tracking and reporting being separate for the different channels, and extends to systems across different functions. As a result, the enterprise often has no consistent view of its customers along all three dimensions, which is often obvious to the customer. Moreover, poor integration of analytical and operational systems may break the controlling and learning loop described above.
These dimensions clearly apply not only to CRM but to other, if not all, areas of the business. Collaborative applications extend to process flows between front, middle and back office within the enterprise as well as flows between the enterprise and business partners, service providers or suppliers, respectively. Analytical functions extend, for example, to risk management applications. Operational functions cover all tasks being automated within the enterprise.
An enterprise cannot afford to use more than one architectural approach, as its systems would otherwise remain disconnected, or to have disjointed processes (as an example) for customer and risk management.
For example, channel integration is threatened by poorly integrated collaborative and operational applications serving different channels, like call centre, e-mail, Web transactions, face to face and intermediated customer contact. Channel integration requires the delivery of current, accurate, and consistent data from (typically many) operational to (one or more) analytical systems. Automation turns collaborative into operational tasks, requiring a flexible and seamless integration of collaborative and operational systems.
Capabilities
In the CRM systems market, several vendors offer integrated (or suite) packages that contribute to more than one dimension, and sometimes all three dimensions. However they still do not provide a complete and integrated solution for a complex enterprise. Where packages do not fulfil the integration capabilities discussed below, the reliance on a single vendor makes it harder to enhance the application landscape with products from other vendors or with custom-developed components over time, as new business requirements and priorities emerge.
Most vendors and service providers suggest an enterprise application integration (EAI) platform to solve the complex integration issues found in complex enterprises, while simpler solutions can be relevant to smaller businesses. An EAI is needed to integrate applications from different vendors that have not been designed specifically to communicate with each other or with pre-existing and future systems.Applications to be integrated must provide some functional service interfaces. These interfaces should be 'transaction-enabled' or, technically speaking, support a 'two-phase-commit' protocol, so they can be safely combined with other 'industrial strength' application functions. Ideally, these interfaces should follow SOA standards and IBM's IAA or IFW in financial services. Second, application components must notify interested parties of relevant changes or, at least, provide customizing facilities for adding such notification capabilities. This is particularly important if data in separate systems has to be up-to-date and consistent - an increasing requirement of real-time business operations with personalized customer management capabilities.
Today, many systems are integrated via batch updates, violating the data currency requirement for some critical business purposes. Finally, if application components are candidates for integration into people-based processes and workflow, or simply integration on the desktop of a single user, they should provide user interfaces that can be controlled on the level of elementary activities (or functions), such as 'create a new customer', or 'approve loan'. If this capability were absent, integration of application components within a more global workflow would require the custom development (or redevelopment) of user interfaces. The first and second capabilities are found with many application systems on the market; the final one is currently rather rare, but is becoming more common with the penetration of Web or portal interface components, allowing single access points to multiple systems for employees, partners and customers.
As far as the overall application and system architecture is concerned, the major capabilities are multi-channel enabling, and the separation of largely context-independent activities as the basic granularity of application components. Multi-channel capability, in turn, is mainly enabled by a clean separation of logical activities and physical user interface. Activities should be modelled in a way that does not anticipate which user interacts with which activity. This provides the flexibility to have an activity executed by a client via different channel devices, by call centre staff, or also automatically. (Note again the point made above that the trend is towards automating more manual activities.)
From a data architecture point of view, integration will rarely be seamless. Attempts to move towards an enterprise-wide, redundancy-free data model have mostly failed, since the data architecture gets too complex if it tries to address all different aspects of the enterprise. It is therefore advisable to have local data architectures for different domains, probably introducing some well-managed redundancies, defining which application component is responsible for managing which data, and defining a proper mapping between these models to allow consistency of key data across the architecture.
Industry data models play an important, central and intermediary role in supporting effective customer management. The most obvious, and now proven, uses for industry data models are:
- Development of a 'single customer view' (in fact a single business view, of all customers, products, channels, alliances etc) for analytical uses. This is normally known as a Customer Analytics or Warehouse, and provides the base for providing consistent views and extracts (data-marts) of the same core data for various marketing, risk, profit, finance, measurement and scorecard applications.
- Development of a 'single customer view' (in fact a 'party' view of customer and eventually all other personal and business relationships relevant to effective customer management) for operational (system of record) and collaborative (integrated multichannel) purposes.
- Development of data mappings for data interchange (eg XML formats) and other integration standards, including combined portals and portlets.
Industry data models provide the required common ground for consolidating shared data and sharing data dynamically as required. Industry data models also provide the shared home for data content that enables customer risk and profitability insights to be combined with offer and response information. Without this additional industry profit and value data, and without the integration of analytics, operational and collaborative function, isolated CRM application components may be deployed to target responsive customers of any value and fail to deliver the anticipated ROI ,The Diagram shows a typical high-level architecture for successfully integrating analytical, operational and collaborative processes, functions and systems in this manner for BFSI Function
Issues
There are various styles of system in use today that have been implemented over many years. First we have systems that work in batch mode: that is, the input data is pre-batched and processing tasks are run sequentially within a defined time frame, for example overnight, weekly or monthly. Second, there are systems that take immediate input requests, process those individual tasks immediately (eg credit risk control system or dialogue applications) and respond in real time to the requester or user.Many businesses require these previously disparate systems to be integrated to form a single business process. Some operations previously implemented as batch need to be carried out in real time due to a business requirement for an immediate response. A financial services example could be that funds are transferred between accounts immediately and made available for the next transaction to take place. 'Straight through processing' is a term now commonly used to represent immediate data validation and update.
Capabilities
The integration of the activities (functions) of the business process chain must be implemented using both mechanisms, by synchronous as well as asynchronous operations. Synchronous operations are applicable if the operation result can be delivered immediately. The asynchronous method may be appropriate if the calculation of the result requires additional input that requires some time, so the result cannot be delivered immediately. Asynchronous activity may be preferred if the action must be carried out in near real time (the results made available almost immediately, perhaps in seconds or even minutes).
In each case the synchronous and asynchronous activities (functions) of the process value chain have to be connected. For integration of these activities a uniform system model is needed that brings the different styles together. This might be a (work) flow-oriented approach that retains the sequence, consistency and rigour of the process value chain, for example ensuring completion of multiple update stages for various sources of customer data. Thus, this integration can be accomplished using appropriate workflow management systems.
Another approach is the use of enterprise application integration methods. Here, an integration broker allows a bus-like topology for connecting different activities and a minimal number of interfaces and connection between the components. The integrator itself (Fusion Middleware Suite) can enrich data and transform them into another data format. Compared with the workflow management system approach, this method has the disadvantage of fixed process chains and the necessity of implementation of some control and data flow between the activities.
An easy way to connect systems is message queuing, allowing the integration on a synchronous and asynchronous systems basis. Such connections are characterized by guaranteed delivery within defined time intervals and without delivery duplication. However, these systems have traditionally not included control-flow management and have required a unique data format between sender and receiver. These combined requirements have now been addressed by the most recent integration developments of newintegration product suite.
Integration performance needs to be considered, because more functionality (as in the case of the use of workflow management systems) requires a significant overhead of (system) management operations. So in cases with high performance requirements it makes sense to implement a special process management system, based on defined (fixed) process flow criteria and a state machine.Many integration methods are able to satisfy the requirement of the on-time execution of activities. However the best integration methods and tools can rapidly and flexibly combine analytical, operational and collaborative systems for effective customer management AKA CRM Excellence. The same integration methods can also integrate existing systems ('legacy' or operational), current systems purchases (such as CRM components or suites) and future systems elements, so far unknown.
Summary
Integration of analytical, operational and collaborative systems is needed to deliver substantial ROI from enterprise and closed-loop customer management projects. Current integration methods and tools can deliver the function needed to consolidate past, present and future systems within a single consistent architecture. Industry data models are essential for managing customers for profit, through integrating analytical and operational customer databases and supporting consistent data sharing for integrated channel management and closed-loop operations. Although integration issues are tough to tackle, and need to be addressed in a prioritized business transformation programme, it is now possible to balance accelerated delivery of short-term business requirements with delivery of a flexible, shared infrastructure for cost reduction and operational resilience. Good Luck and Happy Integration..
Loving P&C
DC*
No comments:
Post a Comment