I have no clue what is a CRM technology.
CRM is a set of business processes and practices. The technology that supports them varies wildly.
Specifically, BPM itself needs to be steered towards Case Management in order to support such a non-linear and data-heavy set of business processes as CRM.
Agree with Bogdan here... CRM technology? BPM, again is IMO a great and fundamental base where *a lot* of acronyms and performance / quality improvement methods can benefit from... CRM is (just) one of those acronyms.
So... the best Customer Service can be delivered when you have your BPM in a healthy shape. But the same then can be said of your Product Development or HR recruiting technology. We need to distinguish technology from a management discipline or even from a mindset. And I regard BPM as a management discipline / mindset :-).
BPM should drive the discovery to build the required custom CRM using a comprehensive BPP software allowing business to drive build. The now recognised adaptive capability is of course essential so the BPM input should be a continuous exercise. This is a challenging education exercise but must happen to take enterprise software out of the "dark age".....
Agree with previous responses, and will add this: it ain't just CRM. Organizing your data in systems of record isn't the same as acting on that data. Many of the "non-value" interactions Ian refers to have a single cause: the required information exists, but can't easily be accessed by customers in a context that is meaningful for them. BPM, supported by the type of customer-centric thinking that Ian recommends, can solve this problem by packaging and delivering information between customer and vendor in a timely and context-appropriate manner.
BPM should partner with CRM Technology under any of the following scenarios:
In other words, not all client-related processes should be stored using BPM and CRM. But despite which one you use,all processes must be integrated (via Web Services under SOA paradigm) so the client feels that he/she is interacting with a single organization.
I've been giving this some more thoughts which I'd like to share, but this requires I go a bit off the leash, so I apologize in advance.
I don't claim to be right, but I enjoy throwing the occasional wrench into the running engine. So here goes.
tl;dr: CRM as a practice is an increasingly inapropriate way to build a sustainable business.
CRM as an acronym (and as a current practice, also implemented in sw packages) keeps people focused on the transactional bits that make up the so-called "relationship". A run-of-the-mill CRM process is basically a monitoring of customer events (meetings, visits, calls, product usage, service appointments, surveys etc) in the hope that those many events will sufficiently approximate a reliable funnel that drives revenue for the seller. But the basic focus is still on atomic transactions that push both businesses, hopefully in sync.
And I know people are incrementally innovating this space, with CRM being sometimes replaced by CXM or CSM or other mumbo-jumbo, or that people think of reverse funnels and hourglasses and whatever better mousetraps they can figure out. But all this is minor and incredibly shortsighted.
Nowdays, since the advent of the electronic "membership economy" (just finished reading the book, a solid cold shower), we all aim for the "forever transaction", where we stay constantly engaged with the customer throughout his lifecycle and drive revenue. Yet we still think of it in terms of multiple small transactions, not really a relationship.
Even relationship as such is a limiting concept. Is this what customers want from us (that we are so keen in managing...) - a relationship? What - are we marrying them?
How about we think of a partnership that drives the customer's business - isn't this something they are more likely to need from us?
Almost 20 years ago, when I joined Procter & Gamble, their Sales department was already re-named as CBD - Customer Business Development. For those unaware, P&G names as Customers its Sales Channels (KA's, National Accounts, HFS, distributors etc) through which they are selling products to their Consumers (end-users). The job of a Salesperson in P&G is not to push products but actually to implement a joint business plan with those channels (joint targets including, but not limited to, joint investments into the store presentation, promotions, materials, special actions - with the most critical ones they actually build joint P&L's!) via which they create demand for consumers and pull the P&G products through the channel. P&G is so adamant about this that you can lose your job if you try to do channel stuffing at quarter-end. There is a huge integrated (from plant to store) weekly demand planning process that ensures the value chain is not distorted by excess inventory or out-of-stock occurences.
Now, contrast this to the typical enterprise software salesperson's week before quarter-end - just sayin'.
So it still blows my mind that, after 20 years, P&G's approach (basically a very deep B2B2C) still sounds incredibly innovative to an industry like IT.
The only converging explanation that I could find is that, at its core, IT is still very much an immature industry - there are many signs of that - the machismo and the gender imbalance, the employee poachings and the subterranean employer cartels, the IP lawsuits, the ego- and eccentricities of the leaders, the obsesive-compulsive behaviors taken as leadership traits, etc.
I know that there is a lot of talk about B2B2C models in the IT industry, but it's still just the rara avis, the exception.
So I can only dream about a software platform that does a serious B2B2C as a way to drive customer success (and, ultimately our success as tech vendors) - this is so much more than just BPM and ACM.
So much opportunity, so little time :-)
Bogdan’s comment is an excellent business case for applying the power of coordination: several interdependent businesses are working TOGETHER to work TOGETHER with an independent customer to better serve each particular customer WITHOUT the authority over all participants!
Certainly, jointing of efforts CRM (as one of the domains involved) and BPM (as enterprise-wide management discipline, tooos, practices and architecture) is mandatory for such a collaboration.
Unfortunately, it is not sufficient because of
1) continuous misalignment between classic BPM and ACM (as two extremes of coordination continuum) and
2) absence of commonly-agreed understanding of BPM – thus BPM is, potentially, different at each of participants.
So far, the BPM community is the main stumble block for BPM to catch that B2B2C opportunity.
Working together, the BPM community will achieve more.
Simple question. Revealing answers. The original blog posting is worth reviewing, because the question of "relationship friction" or "relationship cost" comes up.
Suggests to me the "economics of business processes". Push information costs onto customers and lose (the blog posting calls it "non-value demand"). And too often our response is "machismo" (per @Bogdan's word). This forum has discussed in several places why BPM is essential to CRM. Today's discussion takes it a step further to social costs or what I've called the question of information economics. Failure to get this right will, as the post says, result in a failure of the programme.
In my note above, I highlighted the view that the BPM/CRM issue could be seen as really being about the cost of information, specificallly pushing information costs onto business partners.
Here's an example in a field that might seem very different, but which also shows the dangers of ignoring tacit process costs and by whom they are incurred: #EIPP(Electronic Invoicing Payment & Presentment).
FYI, EIPP is very BPM-driven; and the related procurement part can or should be very BPM-driven. Readers will also be familiar with the related term "B2B", in the sense of meaning "electronic gateway" for commerical transactions, and for which there used to a Gartner MQ. Again very BPM-driven.
EIPP and automated procurement concerns the upstream relationship between buyer and supplier. The most successful EIPP-driven ecosystems have been EDI-based; a key reason for the success is the economic power of the buyer, think Walmart and GM. Some large anchor buyers have their own systems, but many transactions flow through consolidators such as Ariba, now owned by SAP.
Through the history of EIPP and automated procurement, typically big "anchor customers" forced all their smaller upstream suppliers to engage in administratively and technically complex invoice submissions to an EIPP/procurement platforms (I'm familiar with EIPP for oil and gas exploration). Either get on board or we won't buy from you.
From 10,000 feet this position makes sense, especially for the buyer. But there are signficiant tacit costs that get pushed to "the other guy", in a way that is similar to what happens in the CRM example highlighted at the beginning of this forum discussion. EDI has a reputation for complexity and brittleness, even given the obvious and real benefits once it is in place. (A good business case can more easily be made with high transaction volumes.)
EIPP sounds like a good idea; but the whole thing would be much more successful if the upstream administrative staff in multiple suppliers didn't uniformly feel that such systems are terrible (poorly designed, repetitive data entry, difficult to manage). Even CEOs and CIOs in the past have been known to be reluctant to move on EIPP because of the cost.
#Information is not free and the economics of relationship management cost needs to be considered in systems design. Better design and better #economics contributes to network success!