Bottom line, today the text based notes stored within CRM systems are relatively useless. The time taken to read them during each interaction nullifies much or all of the benefit, depending on the speed reading capabilities of the agent/CSR. I am starting to see the next generation of thinking on this, and its going to be controversial, because of the enormous spend on CRM to date.
Colin's comments come along at the same time as I'm looking at the "Next Generation BPMS" - not BPM 2.0, which when described by Ismael Ghalimi has a central theme of standards based modeling, simulation, analytics and of course process execution. I'm thinking of an all-encompassing business suite that incorporates not just process and all of its supporting capabilities, but also content, integration, collaboration, security, identity, metadata repository and a host of supporting admin and configuration features. Should CRM be a component of a Next Gen BPMS?
James, writing Enterprise Decision Management (EDM) blog often touches on CRM for customer service. A recent post talks about the use of EDM or BPM for call routing in a call center. Both EDM and BPM can make use of customer data or profiles to help decide how to route a call most appropriately. In this environment, the customer data would probably be held in the CRM. It is only the customer data that is used for automated decisions, and many of the facets of CRM including the text-based history of customer interactions are not required. Maybe a relational database schema would have been sufficient to capture this data.
I have tried looking at BPM vendors that have addressed this question in the past. Pega obviously shapes its process offerings around its CRM background. As I understand it they have a strong (although not alway rapid to define) object model that represents the customer data, supported by a process engine. The analysis and definition that is performed is typically approached from this standpoint, rather than the process standpoint that would typically be attacked by other BPM vendors. Activities and display are driven from the data, so this is important, and makes customer data central to their focus.
Way back pre-TIBCO, Staffware acquired a CRM vendor. When I saw it (pre-Vignette, when Tower Technology was a leading Staffware partner in the UK), the CRM component was not really integrated with the workflow and it was hard to visualize how the two were going to work together effectively. Looking at TIBCO's website it is hard to see if the CRM technology exists in any of their offerings. Perhaps some of it was fully embedded into the iProcess engine. If that is the case, it is more of a relational data model that is important, not the full blow CRM capability.
At this stage in my Next Gen BPMS definition CRM is not a component. Instead I'm going with a BPMS that provides flexible case folders supported by definition and access to relational data, internal or external to the system. This BPMS allows me to represent any data I want to within a standard relational DB, or external system, using the data directly for process execution and displaying it seamlessly within a configurable user interface.
I'm open to offers on whether there is any more of CRM than a relational data model that I need. Anyone?
Technorati tags: BPMS next gen BPMS CRM relational data model
4 comments:
That relational data model, if i understand it, makes sense to me. Presumably the firm could collect whatever customer information it needs, in that database, and which could be:
- name, address stuff
- channel usage MIS
- customer preferences
- current holdings
- transactional usage
- etc etc
Colin, as ever you help to clarify my ramblings! Indeed your example shows typical data that could be captured simply in the database, without the need for CRM. This could then be accessed through BPM and rules engines.
It is my feeling that a well constructed database model capturing the appropriate data is cheaper to design and maintain than using a proprietary CRM application. There are many more application developers and DB administrators that could do this than there are people skilled in a particular CRM product.
Specific CRM packages may have more 'click to configure' capabilities, so if the aim is to avoid DB or code development in the enterprise then CRM may be a way to achieve that goal.
For my aims, CRM does not seem to offer enough additional value beyond what could be represented in the data and processing modeling provided in my Net Gen BPMS.
Be careful what you wish for. If the next generation BPMS evolves as you describe, the only vendors who can play will be Oracle, SAP, and Microsoft. Ask them where creating the next gen BPMS falls on their priority list.
BPMS is not an enterprise app. If anything, the next gen will be less monolithic, more of a stack that supports best of breed. Today monolithic suites are the only way to get things to work, but that is probably temporary.
I think you mean to say that next gen enterprise apps like CRM will have to become collections of business services, less monolithic. The app vendors will probably favor their own BPMS but that's a bit different from what you are proposing.
Bruce,
I must admit that I hadn't thought about it like that. I agree that most enterprise apps need to become more service based, including BPM. I also thing that there are parts of many enterprise apps like CRM that could be sensibly incorporated into the capabilities of a complete BPMS. I'm not suggesting putting a whole CRM inside the BPMS, but I think that some of the data modeling capabilities are essential to self-contained business process implementations.
As you are well aware, the current state of affairs is that ECM/BPMS are stacks of products that typically can be used alone, or together with other vendors' components as long as a customer is willing to go through the effort of integration (to my experience even in pre-integrated partnerships). The integrations within a vendor's own stack is typically far more seamless.
In my experience the BPMS has not been considered the system of record for a business, instead always needing to push data out to a separate database at stages of the process. With a sufficiently powerful relational data model in place, the database supporting the BPMS could become a system of record, preventing the need for integrations. At a minimum it could simplify the overall operation of a system needing more than 'workflow' and 'less than BPM+CRM'.
Thinking again of course, maybe this whole thought process is just a reaction to the fact that the CRM has not made it deep into the processes of many organizations. If it were there, and available for access as a reusable service, maybe I wouldn't be trying to represent its data in another system.
Nice discussion. Thanks!
Phil
Post a Comment