Good question Peter.
BPM has traditionally encouraged the adoption of Structured Processes to improve overall efficiency. Customers don't care about your overall efficiency, they only care about your efficiency in interacting with them.
This renewed focus on Customer Interaction Efficiency is going to send a lot of existing (and very efficient) business processes to the dust bin.
Agreement on why our current standard processes are lacking for the first leg of the digital Journey (customer delight).
While processes may be optimized for businesses, they do not consider the customers view and desired touch points. Organizations act like they are in control. No longer. The customer is in the drivers seat, so organizations have to perform real customer journey mapping not just process mapping. Secondly customers need to control theri own options within that journey by collecting more customer preferences and let the customer change the rules of play where possible and helpful. Thirdly customers will demand better visibility into those processes in a way that meets the speed and convenience of their needs. Now a bonus would be if that visibility included some fun or kewlness :)
Remember the mantra "outside in" view for process design and execution !!!!!!!
I do believe in mass customization as a significant trend in service delivery and from that standpoint service design will take many shapes and routes, as seen fit by the end customers.
So that future golden standard may not exist anymore.
So processes will evolve to cope with every new service design idea.
This question, concerning as-is customer service processes versus future to-be customer service processes, gets to the heart of "why BPM".
First of all, what's special about customer service? And how does that map to BPM?
1. BOUNDARY CROSSING -- Customer service (and we could expand the topic to include the closely-related world of IoT-driven field service too) is distinguished in large part by the fact that a customer service process crosses boundaries (firewall, organizational, legal). And as such customer service is central to business value creation, because by definition business value is very much about collaboration between specialists.
Technically, legally and experientially, boundary crossing is among the most challenging of domains. For multiple reasons, including the fact that BPM is already at the core of inter-organizational commerce known as "B2B", BPM is the technology of choice for boundary crossing applications.
2. PROCESS ORIENTATION -- And customer service, as Mr. Sinur has mentioned, is also about "customer journey". I would add to this the related terms of "customer experience" ("CX") and "narrative and story" all of which are mapped ideally to business process technology, or BPM.
And so what about from "as-is" to "to-be"?
Today, CX and customer service are often bound up in ERP systems or field service systems or customer support systems, where processes are hard-wired as product features (even if there is often some customizability, although at considerable consulting expense). Especially the boundary-crossing parts of customer service are often hard-wired.
If the needs of future customer service providers and their users are to be met, then customer service technology will need to move far beyond current application platforms.
Only BPM technology, by definition, offers the possibililty of working with customer service-oriented abstractions directly as first-class citizens of a technology platform. The result in initial time-to-live and on-going adaptation is an order of magnitude better than any technology where ideas must be mediated by code and/or analysts.
Insofar as business futures are about winning-through-better-processes, BPM is the technology for future customer service enablement. (And OK, add a few other irreduceable technologies of business semantics, including business rules, UX, data stores etc.)
Win with BPM!
CRM, like security and governance, should be baked into a business process from the ground up. Not all people have done it to-date, even though the business process itself should be customer-centric whether inward or outward facing. This really isn't a now and then question, it's a do or do not question. Always has been, always will be and is one of several potential differentiators.
"Customer delight" does not always align with cost cutting objectives that some process solutions have and they don't, won't always drive the bus. Benjamins do. If customer delight aligns with that, customers are golden. If it doesn't, not so much.
Just my tuppence.
Let us look at the video at ref1. Obviously, only some of “corporate process” interacts with “customer process”. The latter must be made explicit (for example, the process in this video was reverse engineered from an end-customer contract). Then the former must be aligned with the latter. Then some other “corporate processes” must be adapted as well.
It is normal to rework your processes (hope that your implementation of BPM does allow this easily) to satisfy some business drivers. Just add “customer processes” in your process architecture and consider them as one of the business driver.
We have for some time recognized that the only customers organizations can hope to retain are “delighted” customers.
Automated processes have, for decades, been sufficient in terms of providing service to customers for the simple reason that no customer service has been needed at steps along such processes. Automated processes ensure that products conform to pre-published standards. The output of such processes goes to inventory. Distribution then takes place to distributors/ intermediaries/ end customers. Any CRM system can handle calls/responses to calls re a) the status of shipments b) questions re the use of products, c) returns, d) …
Contrast this with e.g. custom-build housing where builders are well-advised to initiate and maintain frequent contact with the customers as work proceeds. Here, the builder recognizes the positive contribution of structured processes to the bottom line but realizes that rework can dramatically negatively impact the bottom line. For these types of processes, the ideal setup is to include customer outreach steps at key process points and to accommodate customer inreach at ANY stage of the processing, in other words at any process step. If a customer calls to inquire re the status of work in progress and indicates they would like a site visit with a right to comment on such progress and the builder does not accommodate, the builder runs the risk of re-wind/re-work. Clearly, you don't want a BPMs with a separate CRM for this type of work.
Whereas “traditional” BPM may not be able to handle custom-build housing (or job-shop manufacturing), we have had, for several years, ACM/BPM where a “case” is capable of accommodating any number of outreach/inreach interventions that can impact engaging or disengaging process fragments.
Already committed steps. Action: put a hold on current work, re-wind to some point and re-process.
Current steps: Action: Modify the scope of the step, complete the step using new time, cost, performance criteria.
Not-yet-current steps: Action: Put a hold on future steps, engage alternative sub-pathways as and when it is time to remove such holds.
Conclusion: Today’s processes (given currently available methodologies/tools) are capable of providing the high level of customer service that is/will be considered standard in the future.
The key to delivery of customers services is engagement allowing real time interactions with relevant data/information to deliver exactly what the customer wants = the business outcome. The future will see intelligent processes allowing the customer's need to evolve as taken through options and thus giving a good user experience.
Delivery of this capability will require that vital "outside in" fresh approach and new build using the silo legacy as required. Build of such processes should be undertaken as designed ready to execute in days not months! Whatever change will be inevitable so important such flexibility is incorporated into the BPM supporting software platform. This makes it vital to understand just how the software works to deliver on these future requirements; before embarking on this important move to next generation process support.
Seeing as it's been about 24 hours since I started this reply, perhaps I should try and get it done. :)
A word on the premise of the question. I would argue that most processes are stunningly insufficient to the levels of service customers currently expect. The real question for BPM is not whether it will help us preserve our advantage, but rather, whether it will help us gain one in the first place.
I hate to be in the position of disagreeing with so many smart people who posted previously, but all of this stuff about the “structure” of BPM-driven solutions as an obstacle to providing the flexibility demanded by customers is hooey. Two reasons:
On this second point: I'm a huge fan of the sanctuary formerly known as San Diego Wild Animal Park, not far from my office. The park has created an environment in which the animals appear to be roaming freely across very large areas of terrain. With a few exceptions, there are no individual enclosures. Touring the periphery of this pseudo savannah, one might be puzzled at the way the keepers manage the animal population without walls, and with little evidence of the red-in-tooth-and-claw reality of wilderness life.
The magic is not that there are no barriers, but rather that park patrons simply do not see them. If BPM can help you erect fences that are invisible to your customers (but important to your business), it will more than pass the test suggested by the question.
@Scott . . . re "BPM, especially when seamlessly integrated with a case management framework, is capable of supporting incredibly flexible applications"
I agree.. demonstrating this simply involves taking all key steps in structured processes and posting these one by one at a "services menu" that users are able to access.
You end up with a set of "processes of one step each", allowing you do take any action at any step along any structured process.
Of course, you need case-level rules to "rein-in" extreme, unwanted, deviations away from structured interventions, otherwise no point having structured processes.