At last week's BPM and Case Management Summit there was quite a bit of talk about what was ahead for business and BPM. One thing everyone agreed on was the speed of change was accelerating, so do you see the value proposition of BPM for business changing significantly in the next few years?
No, it's still about better, faster, easier, improved business processes. The fact that things are accelerating in the rest of the "digital" world should facilitate orgs' receptivity to doing so if they want to stay in the game.
BPM is just what you do as an organization. Every day. So the value is still "deliver what you promise to your customers"
How you do it, might change of course by new stuff and gadgets on the market to execute, monitor, improve those processes.
But it all starts with "do my processes still make sense?"
So, Why? and What? BPM is about will not change. How you do it, might change every day. Not sure if I would call that a changing value proposition.
Business value is about converting inputs to outputs.
You always need an infrastructure but the amount of work needed and the type of work needed to convert inputs to outputs varies.
We can call all work a “process” – if all of the work steps are ad hoc, Case is the environment of choice, if some of the steps are linked, then Case + BPM. Fully automated processes need automated process control hardware/software (typically modeled using GPSS). Once-thru initiatives (i.e. building a field of houses) need CPM (ES, EF, LS, LF, float).
I don't see the value proposition of BPM changing significantly in terms of its defined niche but we probably need another ten years for corporations to become aware of the capabilities of BPM and to start using BPM.
Sales and marketing opportunity! Sales and marketing can also be about accelerating techno-social change.
I am working on an article on "Resource-Based View" (RBV), whose antecedents go back to the 1950's.
From what I can tell, no one has yet provided a practical solution to "viewing" corporate resources/capabilities - our group is doing this using our 3-D Knowledgebase software which we introduced around 2000.
I suspect we could have had a solution to RBV back then, had we put a focus on this methodology.
The Resource-Based View article has been published at http://kwkeirstead.wordpress.com.
I don't see much traffic on this topic on the Internet - there were critiques issued in 2001 and reading them today, the defenses seem weak to me
i.e. "Barney (2001) . . . admitted that his 1991 VRIN theory has little potential for applicability to the real world"
It seems to me to obvious that if you don't inventory your resources, you cannot to easily make decisions re their potential and actual applicability.
So. for me, the concept made sense, except that the proponents had no way, at the time, to practice VRIN dynamically.
With what I call "3-D free-form search Kbases", we can today do VRIN in real time therefore I disagree with Barney's conclusion and that is why I wrote the article.
I don't expect this to go anywhere but we do still have this gap between operations and strategy
I will not rest until my customers can dynamically consolidate analytics across cases to graphic Kbase so that managers can do more than stare at their KPIs.
Yes, BPM is evolving to something greater. It's not just for internal automation. It will be for full user (inside and outside) engagement. While our aim is still to improve operations (faster, less cost, better experience), we will enable more end-user (external user) interaction through real contextualized user experiences. I'm excited.
I think there are already two sets of value props depending on what you are trying to do with BPM. I don't think a third set will be coming anytime soon, but certainly the evolution of the ones that are already there.
When I am working with our fresh-out-of-college sales associates I usually explain the different value props like this:
Traditional BPM (Automation):
Efficiency - Cutting Costs & Doing More with Less
Agility - Low Cost to Change & Increase Business Responsiveness
Compliance - Avoid Penalties and Violations
Transparency - Provides business traceability and accountability
BPM for Digitalization:
Innovation - Find New Solutions Through Experimentation
Speed - IntroduceNew Products & Services Rapidly
Differentiate - Customer-centric & Context-aware Business (Interactions & Decisions)
Evolve - Proactively encourage rapid change and evolution
I usually find that businesses will start off by dabbling in the traditional BPM area then grow into the second set after they have a few of the traditional processes managed well. It is the sales rep's job to assess the maturity of the organization they are working with to determine which set of value props they should be focusing on.
BPM's value proposition is as strong as it always has been, and I don't see that changing.
Business processes are business processes, and (broadly speaking) neither they nor the desire to improve them has changed a whole lot over the millennia. The technologies we use to make these improvements have changed enormously, however, in terms of both price and capability. So realizing the full measure of that value may be more within reach than ever.
As we already know (see ref1) BPM potentials are huge. Step-by-step, we are unlocking them for
blockchain-based smart-contracts (see the chapter 3 in ref2),
electronic healthcare records (see ref3),
digital which is impossible without BPM,
innovations which are based on automation of existing work to liberate the enterprise resources for addressing unique enterprise challenges,
The BPM value proposition is still the same – bring the systems approach to our work. At present, it is perceived differently by different enterprises.
- Dr Alexander Samarin
- 10 months ago
[url="/bpm-today/in-the-forum/do-you-see-the-value-proposition-of-bpm-changing-significantly-in-the-next-few-years#reply-3851"]Rachel makes a good point[/url] about the apparent divergence of BPM platform value propositions in the marketplace.
It's obviously true that the digitization proposition is taking on increased importance. But the position advocated by Big Analyst—namely, that the efficiency/compliance/agility proposition is no longer relevant—is simply disingenuous provocation.
What is all this “low-code digital application development” about if not agility? In an era of ballooning regulation, does compliance not represent an enormous risk? Does anybody want to suggest that these are solved problems?
Of course not. Digitization represents not a divergence in the BPM value proposition, but rather, an expansion. Customer engagement, supply chain integration, new digital products and services: all of these represent new opportunities for BPM customers (and, of course, vendors). But we disregard the fundamentals—the “wax-on, wax-off”, if you will—at our peril.
The proposition for BPM
[i][quote][b]MUST[/b][/i][/quote] change if the full potential of the approach and technology is going to be realised.
What BPM actually does probably doesn't need to change much, as per the earlier comments. But "BPM" is a tainted term. It is seen as tactical, boring & necessary evil. Just like "CRM" was tainted as it was synonymous with failed Siebel implementations. And the smart CRM vendors are now Customer Success.
BPM needs to become Operational Excellence - strategic, engaging, upbeat. And therefore the propsition (the promise) need to be aligned focusing on outcomes, not activity.
Is labeling CRM as "Customer Success" useful? Here's a test. A term is useful if it has semantic content; otherwise it's just "hype". So, what about "Customer Success"? The opposite is "Customer Failure" - an nonsensical idea. Therefore, "Customer Success" is sort of like saying "breathing is good for you", so obvious as to be lacking semantic content.
"Operational Excellence" falls into the same trap.
The original "Pursuit of Excellence" book is now a touchstone for failed companies and the idea of excellence is itself tainted. For sure a focus on "outcomes", not "activity" -- but by who? Someone has to do the activity. And the activity needs to be celebrated for what it is. Otherwise it's just mystification.
I'm for doubling down on BPM as technology and methodology. And then different organizations will use BPM to deliver outcomes as they can in the market space in which they find themselves.
I, too, cringe when I hear "Customer Success".
"Operational excellence" sounds expensive. Most manufacturers today seem to crank out "beer can" products that fail 3 days after the expiry of the warranty period. Who can afford "operational excellence:.
I would not today advise anyone to get a CRM "solution" other than as part of Case that has BPM as one of its pillars.
The thing with Case (ACM/BPM) is you can accommodate any mix of structured flows and ad hoc interventions
Easy to insert an outreach ad hoc step that posts to a portal at any point along a timeline.
Equally easy to post a menu of services at a portal that allows any customer to make an inquiry and get back a response (phone or portal object).
And, if the nature of customer outreach/inreach is such that you need a BPM template to set in motion a number of linked steps, since BPM steps accommodate routings, nothing special needs be done to post a process/process fragment to a portal as opposed to a normal user RDP or cloud UI.
Do you see the value proposition of BPM for business changing significantly in the next few years? Well, how processes are executed is changing rapidly due to changed customer needs, expectations and rapidly changing Technology. This will require more flexibility and customer focus in executing and improving processes. Also the needs for open collaboration will require a different approach, and related BPM Technology.
I think we are there actually, with facilities in Case that allow outreach to any customer either at an ad hoc Case intervention or at an insert to a structured BPM step.
The way to avoid two implementations is to categorize an ad hoc step as a "process of one step".
We see huge cost savings in the form of a reduction of phone calls to customers and mailings to customers using portals for outreach.
As for inreach, in healthcare, at least, we are holding back as some patients will send 50 inquiries per day to their physicians and this greatly reduces the productivity of the physicians.
The value proposition for BPM
[u]is changing because of a disruptive opportunity[/u].
This disruptive BPM opportunity concerns the delivery of BPM technology which enables
[u]near real-time process changes[/u], including for in-flight processes.
Two factors drive this opportunity:
1. TECHNOLOGY -- BPM technology changes are enabled by executable BPMN and huge improvements in execution engine math, such that arbitrary (i.e. "style") restrictions on process patterns (e.g. cross-lane dependencies) are removed.
2. METHODOLOGY -- And part of the recipe for these changes concern the implementation of Volker Stiehl's "business logic segregation pattern", such that all SOA/ESB technical integration are pushed out of business logic.
What impact will these technology/implementation changes have?
Have a new business idea?
With new BPM technology, business executives can "think" and business analysts can "draw".
And voila! New business processes. And new ways of doing business.
The business impact that achieving such
[u]fast-cycle business model refinements[/u]and changes is hard to over-estimate.
The delivery of executable, un-restricted BPM is
[u]in contrast to roundtrip- and programming-shackled BPM technology[/u]. BPM has great sales propaganda; the experience is more challenging when one wants to evolve processes. (The roundtrip issue and the SOA- and BPM-execution-related programming issues I believe are at the root of any "taint" that is associated with BPM.)
There is one
[u]big business challenge though to the exciting promise [/u]of evolving BPM technology and methodology.
And that challenge is in the executive suite.
Whereas executives are now
[u]trained to expect "wait states"[/u], the new process management regime puts
[u]huge pressure on executives.[/u]
Until now, executives could reasonably expect that any significant proposed change would take weeks to months. And during that "wait time", they could get on with other business.
No longer. In the new fast-cycle organization, "
[u]always-on executives[/u]" will be expected to take ownership of processes, and to evolve them in real time.
This is a cultural step function.
The technology is ready (mostly).
[u]But business doesn't know this yet[/u].
Even if the motivation is there. Evidence for business motivation is found in all the hype we see about new business models and digitalization and servitization and agility etc. etc.
There's a business need. There's BPM technology. And business can step up.
As they say, "first prize is you get to keep your job". There is no second prize.
Who will sell new BPM in all its glory and potential?
[i](OK, the process of cultural change in process management will take time -- Karl says "10 years". This uncertainty related to the BPM opportunity in itself is opportunity for organizations that can embrace the potential.)[/i]
Yes, the no-code crowd have vastly oversold reality.
Yes, low-code is possible (given the right architecture) providing the proponents admit that rule sets can become fairly complicated and beyond the capabilities of most "end users".
The nitty picky inevitable coding IMO lies mostly in the area of building parsers/formatters to allow multiple local and remote systems and apps to talk to each other where the only practical solution is to allow publishers to export data using their own native data element names and where subscribers can import data using their individual native data element names..
A second area requiring coding is special purpose apps needed for industry specific Case/BPM activity. (e.g. diagnostic algorithms in medicine)
We may soon be able to eliminate some of the current "incantations" - See "Blockchain Revolution" Don and Alex Tapscott (2016) - I just picked up a copy yesterday.
The math and software engineering is really hard ("I'm told...").
You hint at this describing very large processes which however are "deterministic". And undergrad math/CSC student can program an agent to navigate a tree, of any size.
But real life is not a tree (or a block). Real life is messy. Business is messy.
Business people want to "repeat work", which means "a loop". There are arbitrary dependencies between processes (which until now means programming variables and checks, or proprietary workarounds).
Business people want to "think" and then "deploy their ideas".
But BPM technology up until now has made the gap between "think" and "deploy" very wide. It's easy for marketing people to come up with BPM propaganda. But the propaganda gets ahead of itself because of the math and processing power and memory restrictions.
So to date, BPM has been successful with high-volume STP where process complexity is comparatively low and where there's a business case to support the programming that is inevitably part of any BPM project.
Now that we are moving into a new world of BPM opportunity, everything will change. BPM becomes democratized. The new challenge is cultural in terms of "process manufacturing discipline". And then -- where does the domain expertise come from? Exciting times.
The huge difference between traditional end-to-end BPM and what most of us are working with today (i.e. Case environments hosting BPM) is that whereas the process was built plan-side before, we now load process fragments into Case and allow users to insert ad hoc steps, skip over plan-side steps, perform steps in a different sequence.
Result: you only get to a "process" at the time you close a Case.
If you do analytics on closed Cases you have an excellent means of improving your processes - too many skips at a step across multiple closed Cases tells you the step should not be part of the plan side process, too may ad hoc insertions tells you the plan side process needs extra steps, etc.
What's new is better BPM execution engines (I know at least one) where the math of the process graph can be resolved fast enough to allow any reasonable workflow. That freedom-to-specify combined with executable BPMN gets rid of the roundtrip and programming issues (which are killers for the business case and for business enthusiasm). And better BPM execution engines work even better still when deployed alongside a Volker Stiehl-inspired infrastructure segregation pattern.
These changes *are all new*. But not yet widely dispersed or adopted. That's a real business opportunity!
I recall back in the 1970s working on two large hydro electric projects where our flowgraphs had 50,000 activities with weekly updates.
The focus in CPM is on predicting time, cost, performance as opposed to detailed execution of tasks (done mostly by contractors) with simulations, updating and re-issue of very-tightly interconnected tasks being routine.
True, there is, in CPM, a "simplifying" factor in that the flowgraphs are deterministic (i.e. no branching decision boxes, all tasks need to be executed).
What was remarkable was that you could summarize (zoom out) to any level of summary (i.e. to where an entire contract could be represented by one start/end task) - this allowed top management to view the project at a convenient (for them) level of summary. Generating summary graphs was easy because projects always had a work breakdown structure.
Any member of a project management team back then (and now) could update and roll out a new project plan on demand.
A reasonable question is why has it taken so long with BPM (a flowgraph is a flowgraph) to get to "near real-time process changes, including for in-flight processes"?
PDCA on steroids.
But don't understand what's new about that? Oh you did change your processes every 5 years... ;-)
- Emiel Kelly
- 10 months ago
I agree with John that only now is the supporting software capability beginning to be recognised which puts power back to business to truly control their processes. Big companies now realising that to undertake true transformation to compete they need to address the front end of business and recognising "digital" needs adds to the pressure. As ever the biggest challenge is the huge investment in legacy and just how this can be delivered. This puts BPM discipline to the fore to get thinking right although this tag may not yet be used?
I think it is now at the beginning as suggested in the question. One associate sees it "as skinning and building new processes that interact with the old"; good visualization building that Adaptive skin around the business. But just make sure not building a new inflexible legacy....!
Again with CPM, pre-software, you had rooms full of draughtsmen/women, generating 20 foot wide project plans by hand (requiring days, at times weeks).
All of that disappeared with the intro of CPM software that had swimlanes, auto-resource allocation, leveling and balancing, plus automatic drawing of the map on flatbed plotters. The technology came on stream 45 years ago and much of what was available then is, in some cases, being touted as "new" today.
Is possible that the BPM journey could have been a lot shorter by borrowing readily-available technology from the construction/aerospace industry?
I very much like "skinning and building new processes that interact with the old"
What this reinforces, if I understand your reference, is the following:
1. build / select a Case environment that can accommodate any mix of structured (BPM) and unstructured (ad hoc) work, Make sure there is seamless connectivitiy between plan-side process mapping and roll-out of "best practices" templates to the Case run-time environment.
2. stop using legacy apps for new processes (i.e. use #1)
3. make sure your choice in #1 can output data to a "generic data exchanger" and can import data from the data exchanger.
4. link up as many legacy apps to the data exchanger as possible, put the rest on a "to be retired" list.
"generic data exchanger" - publishers are able to post data using any data element naming conventions they fancy, subscribers can pull data using their own individual data element naming conventions, subscribers can become publishers (message a device, the device does some processing then returns an enriched message).
I was invited by John to view this thread and I wanted to add my 2 cents on the subject. I have drank the cool aid of BPM value for some time. Last year I decided to take a little turn in my career and work closer in the application space. This helped me take distance and rationalize on a what is the right message and how to construct a value proposition. Clearly, what may be of value for one audience may not be as appealing for another. It is important to understand this as it is very difficult for a single message to capture everyone's attention.
From my experience, the BPM story has been mostly been told and sold to IT and as such, the value proposition has been mostly surrounded with technical benefits. In the end if IT will create and maintain these processes for their business stakeholders, that was probably the right tree to bark at. Luckily for the BPM space, there is more than the CIO office. It is very interesting to hear what the painpoints are from other groups such as Finance or HR for example and how they may see the same problem from a different angle. The same value proposition that may hit the nail on the head for IT may not be as appealing to these other audiences. My 2 cents from this is that one single silver bullet value proposition will not cut it across and perhaps we have to think of multiple ways of tailoring the message to pains beyond IT. While processes are at the center of all these personas conversations, they see things from a different lens.
The other observation I want to make (an inline with Rachael's thinking) is the pressure the "digital" world has on businesses today. Processes that worked well 10 years ago (with assumptions of running processes on premise and working with no millennials) may not work in today's world. Would you have imagined depositing a check using your mobile phone 10 years ago? Transacting in the digital world is nowadays' the new currency and not all BPM solutions have evolved to embrace all these market trends effective and resolve "the new" problems of these days.
Today's expectations are different than 10 years ago and they will be 10 years from now. We need to get less hangup on technical details and be more practical to resolve problems and allow change to take place quickly in a controlled fashion. The BPM solutions coping with embracing with these new trends and allow this new next wave (generation) of workers to do their job more efficiently will be getting the most value out of BPM solutions.
As IoT and AI matures and becomes commoditised, it is not hard to believe that there will be a fundamental reappraisal on the expectations of BPM for an organisation. This is already visible as larger organisations want on premises sensor data to be fed back to the relevant organisational processes. It is only a skip and a jump to then wanting to speed the decisions by using AI algorithms.
Yes, along with this will come come a revaluation of the value proposition of BPM to an organisation, and it will on the plus side for BPM.
One thing nobody seems to have mentioned is that the value proposition for "service design" in comparison to "business process management" is different and more customer and UX-focused.
This means it holds a much stronger position as a value driver for any business that puts a customer first and then designs processes around that. It also has a strong, designer-centric UX focus - which is exceptionally important to any business in today's environment. Our thoughts on this are posted in the link that's attached to this post.
In terms of process improvement (which is only possible if people are following agile processes anyway) - there is a LinkedIn discussion from people in that community around the differences between the two - happy to share the URL if anyone is interested.
Silicon Valley, CA
Nevertheless. I make the claim that *any and all* higher-level domain-specific capabilities instantiated in software *can* be deconstructed into a primitive set of business workflow steps. And that this deconstruction is a useful thing.
Not to able to work directly with the fundamental building blocks of of work automation artefacts means we are at the mercy of the limitations of our higher level development environment. And we associate the descriptor "business process" to these artefacts. For sure, I don't want to go down to code -- that's not helpful. But processes exist and we want to work with them directly, to manage them and to improve them.Choose your business process notation and execution language and then go to work! : )
In addition, is it not linear if steps are dynamically hidden and shown (therein lie the rules). I hope and wish that what we're doing could become a standard, but that's neither important nor crucial to our goal of simply making process building (in a checklist UI) and process tracking (in a real-time dashboard) achievable by a non-expert in 5 minutes.
I also believe that everything in a checklist is a low-order primitive object (a step) with attributes. Hence, it's really just a much better, easier and modern way of modelling a process so that it's actually executable, in my opinion. Adding other simple visualizations like swim lanes is really easy from the primitives.
It's also feasible to convert any flowcharts into a checklist-like UI. We're already doing it, without code. Not sure I understood your comment - but that's my view. Happy to debate further on either the notation primitives or service design (two different/unrelated subjects).
- Amit Kothari
- 10 months ago
- Page :
However, you are not allowed to reply to this post.