Rule based CRM, an architecture: step 1, Information Domains (1)

In a post from July 2011 I wrote about Rule Based CRM. Seperating your ever changing business rules from your CRM system in a seperate rule engine as a means to create more flexibility and better business owner control over CRM systems, Business Rules and a simple, single brain for your Enterprise Applications. Realising a Rule Based System sounds easy enough, a number of challenges exist however in realizing a rule based architecture. This post provides an outline for a rule based CRM architecture.

What is it we want to achieve?

Implementing a rule based CRM application, or any rule based application serves a number of business goals:

1. Centralised, easy to maintain rules. No need for IT to release new software for a rule change.

2. A consistent customer experience, no matter what the channel.

3. Lowering cost of application maintenance and a more rapid response to changes needed by the business. Adapting the speed of IT to the speed of the competitive / customer environment.

The image below is simple enough. We want a single rulebase that we can use to provide rule based reasoning for all our channels and CRM Applications.

Rules at the heart of your CRM Landscape

Rules at the heart of your CRM landscape

The first question that needs to be answered, when defining a rule based CRM architecture is: Where do we store what? What kind of information do we store in each application?

Information types and rule based CRM

The following types on information can be discerned:

Structured data: data that is stored in a database and contains entities with attributes. Structured data is often used to reason over, to use in CRM processes and to deliver products or services. An example of structured data is your customer data: who is he, where does he live and what kind of relationship does he have with you (what does he buy / use).

Customer: John Johnson, 1 Mainstreet, Smallville, USA, 212-555-678.

Contracttype: More Minutes 250.

Question: Bill related service request

Structured data is always stored inside your CRM system (Such as Oracle Siebel CRM, Oracle Fusion CRM or Oracle CRM on Demand) as it is used to deliver products or services and to answer customer related queries. Structured data often poses data quality issues, we therefore want to limit the possibility to store free text in structured data systems.

Unstructured data. Data that is contained in non structured form, such as documents, emails etc, received from your customer and sent to your customer. Non-structured data may contain relevant information, but it’s hard to store this data in a relational database. Typically Unstructured data is used for communication with your customer, research into solutions and as background information. Unstructured data for John can be the e-mails he has sent with questions about his contract renewal. Unstructured data is typically stored in an Enterprise Content Management System (such as Oracle Universal Content Management), where it can be easily retrieved by the CRM system or through searching for information.

– Process and integration streams. Within todays enterprise multiple systems are used to serve customers and provide services or products. These systems are integrated through Enterprise Service Bus or Business Process Management Solutions, to ensure a seamless integration and ease of use for the end user. An example of a BPM process integration stream would be the process with which a CRM system retrieves billing information from your billing system, in this case, Johns’ previous bills and his payment status. BPM applications and integration streams are used to support business process through integrating applications and are mostly functional representations of underlying technical integration processes in a BPM language, such as BPEL. BPM integration streams are stored in BPM solutions, such as Oracle Soa Suite.

– Business rules. The rules that govern how your company operates, such as: all bills must be paid within 30 days, or: an extension on payment by a customer must always be provided by a mid level manager or higher. Business rules can also be complex product structures or order approval processes. Business rules can be simple, or complex rules such as complete contract structures. As outlined in my previous post, business rules govern the way your company does business. Business Rules are stored within a Business Rules Management Solution such as Oracle Policy Automation, or Be Informed Knowledge and Rule Management.

The image below depicts the information types and where they could be placed within a rule based architecture.

Information types and their place within a CRM Architecture

Information types and their place within a CRM Architecture

What’s next?

The next post will describe what the principles are for integrating the different information types and applications used.

This entry was posted in CRM, CRM 2.0, Customer Experience Management, Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s