As many companies look to replace first or second-generation CRM systems, there are numerous considerations in how to approach the transformation.  The CRM market is highly fragmented; however, most applications subscribe to one of two primary application architectures:

• Data/Screen based, where the primary configuration activity is mapping out data objects and screen layouts and then augmenting those structures with automation and workflow.
• Process based, which requires the buildout of customer processes with the presentation layer being generated after the process build activity is completed.

Selecting the right architecture to support your future state vision is a critical step for updating your CRM tools and ensuring that your future vision is aligned to the fundamental advantages that each of the architectures support.

Data/Screen based CRM systems remain a predominant architecture in the CRM space. 

Starting with Siebel and now including well known vendors like Salesforce and ServiceNow, these systems fundamentally start with data object configuration with automated screen rendering capabilities.  Processes are typically enforced through business rules or robust development toolsets.

Advantages to these types of architectures include the following:

• They work well in stand-alone operations
• They are relatively fast to deploy
• They support a variety of departments who share common data

Typically, these types of architectures are conceived as the system of record for all the data that flows through them.  It is unnatural for these applications to think the customer master is anywhere but resident within their systems. 

As companies wrestle with legacy systems that are extremely expensive to replace, it is often a challenge with a data/screen based architecture to decide who is a master and who is a slave when it comes to data and process management.  This has led to the second class of CRM architectures.

Process or BPM architectures have gained favor over the last 10 years to capitalize on shortfalls of the data/screen-based architectures.

In a process-based CRM architecture, processes are configured first with data objects being defined and ingested as required by the process.  There are two classes of these types of architectures; general purpose BPM tools like Pega and Appian, or application specific tools like SAP CRM whose function supports processes within their suite of products.

A process-based tool offers several advantages over the data/screen-based designs:

• They provide for improved cycle time and user efficiency improvements as compared to screen/data-based CRM architectures
• They are easier to train agents because they guide calls and processes inherently through their design
• They make it easier to route work in and out of different departments as a customer request crosses from a service center to other areas of the company like finance or warehouse operations

While the advantages of process-based CRM tools are clear, they come with some considerations that a company must plan for as part of a deployment.  There is a generally a longer deployment time, and they are more dependent on legacy system interfaces as compared to their data and screen-based approach.

There is no single answer for your CRM architecture.

Both architecture types will and have worked at many companies successfully.  When trying to decide which architecture is right for your environment, consider the following:

• Is the primary objective of the project to reduce handle and cycle time? If so, we would recommend a process-based architecture.
• Does your organization have interfaces to support your CRM program? If you expect to operate in a more stand-alone mode, general purpose tools will likely be more cost-effective.
• Do you feel every customer interaction is different? In these cases, trying to define your process inventory will be challenging and will require up-front planning and blueprinting.
• Is the future vision of your CRM program to manage cross-enterprise processes and experiences? For these types of programs, we have found BPM and process-based CRM to be better aligned with that enterprise approach.

Making the right architectural decision for your CRM tool is often overlooked in lieu of focusing on do the applications deliver specific function points.  Ultimately both architectures can deliver the features. 

The underlying architecture drives how the features are delivered and will be a large driver of your long term TCO as you transition from initial implementation to continuous improvement and management of changes as the business evolves.  Time spent evaluating the architecture of your next generation CRM tool will save you money and aggravation down the road and lead to a better customer and asset owner experience.

Similar Blogs