From bpmNEXT to this forum, there have been distinct rumblings about BPM needing to rebrand and rename itself. So if BPM had a new name, what do you think it should be?
The new name for BPM is whatever you have domain expertise in, and are able to build credible line of business "applications". So if you are experts in pharma R&D then call it a name those guys will recognise and relate to. If you are great at Customer Experience then pick a name that makes sense to CX or CS (Customer Success) managers.
If you look at the big BPM players such as Pega they call themselves "CRM evolved" and all their marketing reinforces that message including Alan Trefler's recent book.
If you are a generalist, then you are in trouble. In that case look at markets where your platform could be a player, and then go and find some partners (business consultants, not technical consultants) who have the domain expertise and can help you build a product offering.
I think it would make things easier if we go for 2 names separating the management aspects from the automation aspect.
Something like eg "Business Management" for all business related aspects: Modeling, BPA, BPR, change management etc.
And something like eg "Process Automation" or "Workflow Automation" refering to the act of creating software support for processes using a BPMS.
I believe it would resolve a lot of misunderstandings if we stop using the same name to refer to these distinct aspects.
We always referred to BPM in the "PRIDE"-ISEM methodology as Phases 3-7,
Phase 3 - "Sub-System Design" (includes preparation of testing criteria)
Phase 4-I - "Administrative Procedure Design" (writing people procedures)
Phase 4-II - "Software Engineering" (includes preparation of testing criteria for software)
Phase 5 - "Software Manufacturing" (includes unit testing) - Note: a separate Phase 5 is conducted for each program in the Sub-System.
Phase 6 - "Software Testing" (a string test of the programs in the Sub-System)
Phase 7 - "Sub-System Testing" (a complete test of the business process)
As to a sexy new name for BPM, I'll stick with what I know.
Workflow. It should have never been changed to BPM.
Although, I must say I 100% agree with Ian which begs the question - "who cares?" If your business model is a generalist business model, it doesn't matter if you are selling workflow, bpm, case management, adaptive case management - it will still be difficult to sell because you will not be directly solving the pain of the buyer. I think everyone in the industry knows this by now.
DWYP Do what you promise. What else do you need processes (and maybe some management of it) for?
But indeed; BPM is a very vague term. Actually every company is managing it's processes each day. Only some suck in it and think they have to buy stuff to it better. And many end up with a cupboard full of drills, whil the only thing they needed was a hole.
Actually process management itself is strange. You don't manage processes; you manage cases and you execute a process for those cases.
But in the end I don't care about the name because it should be, as said above by some, brought into the context of an organization. 'We build cars' 'We repair legs' etc. That makes sense to people.
So every company does BPM. But they don't care about BPM; they care about the cases for which they execute THEIR processes.
How about Modernization of Business Operations?
There are so many instances of BPM being utilized to replace something that fails to meet modern standards. Process doesn't need to be "managed." It needs to be modernized. And that includes streamlining/automation/simplification, etc., taking something that might be clunky, but passably functional, and turning it into a shiny, newer, more useful product.
Of course the acronym MBO could be confused with the term "Management by Objectives," but those concepts still hold up and jibe nicely with the tenets of BPM, so why not?
I like the idea of Ian in terms of marketing approach. However, to support this idea I suggest first identify the real customer pain, and then create a business solution in which we can articulate many concepts whenever necessary, as BPM, GRC, EA, etc.. In my opinion, the key is not sell each of these isolated concepts in a vendor perspective, but master them and know how to use them to solve concrete problems of each particular client, showing added value for his business.
BPM is boring, it's fact. Rebranding may help.
Besides it isn't very accurate. The word "business" isn't appropriate for e.g. government agencies. "We don't have any business here" - I was told exactly this at US Embassy.
Geary Rummler called himself "Performance Consultant" and he's good the point.
Some respectful process consultant position themselves as Business Transformation Experts. This makes sense, too.
iBPMS was a step too short to make a significant difference.
Digital Transformation overlaps with BPM on probably 90% and it seems to be more attractive to potential users. On the other hand, "Transformation" is associated with a one-shot project rather than a strategy.
Split it by verticals like CX or CRM? Interesting idea but I believe BPM is a horizontal disciplne. We are involved in very different projects in very different industries and corporate cultures but they all are BPM projects.
Workflow? Something from the last millenium. Even more boring than BPM ;)
The bottomline: BPM is bad term but current alternatives aren't better.
Let's remember that BPM is really a discipline with its origins in BPR not a software technology. Unfortunately the confusion, probably deliberate, has indeed caused some legitimate concern hence the question? I think the real issue is now to describe the supporting technology that will now be required to deliver at enterprise level yet keep BPM as the required thinking to establish the needs.
So we need a new "TLA" that says what the supporting software actually does. First A for Adaptive a tag in play and some definitions with ACM. Then reality is Digital is now high up in profile and need for businesses and of course is people centric. Then a "P" for either Process making the link to BPM or perhaps Platform recognising the needs to be complete in capability to build or maybe both....? So my suggestion is ADP or ADPP.
I really enjoyed Ian Gott’s comment about specialization and segmentation. Since the book ‘Crossing the Chasm’ was published, the idea of implementing study cases in particular industries seems to be a formula for success.
However, I don’t think that BPM should be renamed at all. It is the appropriate name because it summarizes and describes the discipline. And it is a common mistake, especially among vendors, to think of it as a technology. Are data bases industry related? No. And what about operative systems? Also no. Does their name specify what solution they offer? No. Specialization must come from every company and in addition to BPM.
Every BPM Suite can have a specific industry, but it should not be limited by it. An example which I am very familiar with is INTEGRADOC, a BPM product specialized in document-based business processes. It’s specific enough but it is not industry-limited. It’s specialized and it offers really short implementation times.
All in all, what’s really important is to find a specialization, whether it is by industry or process type to reuse knowledge, reduce implementation costs, gain future references and spread the use of BPM. Without changing any names J
Re-branding the current mess is like putting old wine in a new bottle.
I think that the best way to “un-boring” BPM is to start changing ourselves first as the BPM community – have a commonly-agreed reference model, reference architectures, set of practical patterns, strong user community, etc. If this work then we may consider re-branding.
In the great tradition of finding acronyms that depict a departure from an established norm just to find ways to plug it back into the same norm years later, I would call the new BPM:
NoBPM (Not-only BPM)
1. This would make acronyms like iBPM, SPA, ACM, CJM, CRM, SCM, HRM etc immediately obsolete. They're all not-only BPM!
2. This would give everyone freedom to continue to safely mix business processes, technical processes, systems, methodologies and architectures.
3. Max will finally say yes to this one type of BPM.
4. Years later people not adopting this acronym will be regarded as the few wisemen that envisioned that the mainstream world, tired of long acronyms, will go back to simply "BPM"
5. Years later there will be rebel factions deploying NewBPM, NuoBPM, NoBPM-done-right, No-BPMN and other poisonous gifts to the unsuspecting customers.
Have a great weekend everyone :-)