Do you think the future of BPM will be the business platform?
BPM (as a trio: discipline, tool and practices/architecture) is the essential component of any Corporate Unified Business Execution (CUBE) platform. Only with BPM it is possible to achieve synergy between diversity of business and uniformity of tools/services. And BPM is digital by definition.
See ref1 about platforms and ref2 about the enterprise pattern which is Platform-Enabled Agile Solutions (PEAS).
Not sure what you mean by "business platform"?
Is this the run-time environment of choice for day-to-day management of the operations of a business?
If so, I would say it is :"Case": for the simple reason that Case is capable of accommodating any mix of structured/unstructured work.
The Case environment I use is capable of handling BPM, CRM, ECM, RALB (auto resource allocation, leveling and balancing), FOMM (figure of merit matrices, for non-subjective assessment of progress toward meeting objectives), data exchange (in/out interoperability with anything you can message and/or get back a message from) and auto-buildup of a Case history to allow users to make better decisions re what to do next.
Missing in my model is predictive analytics (working on this).
The other thing missing is CPM, particularly the ability to manage scarce resources across multiple projects. I can see a BPM flowgraph being exported to CPM software with a ser of durations as the answerback but not incorporation of CPM ES-EF-LS-LF calcs into Case.
For my 2 cents we're certainly presenting BPM as the 'digital-native' business architecture:
Greater agility than packaged apps or ERP and greater capability that rolling your own.
But then I always liked to keep things simple :-)
Maybe, if one is thinking only of managing the steps from task to task... But, I see tomorrow's "business platform" differently. Figuratively, things are only going to run in the cloud and in your hand. Process management is merely one functional component of that total business solution. Other peer components are decision management and analytics of many kinds. Let's not forget all the services that one could leverage from a mobile process. I could go deeper in each area, but you get the point.
BPM itself, process management in businesses, departmental and enterprise-wide will be something we are working on for the next 10 years to catch up. Like internal ESB Integration is ongoing today. But, if we ignore combining in decision management, cognitive analytics, social bots & many other cloud services into our little process solutions, they will be disappointing compared to what users consider contemporary today. Likewise if they do not manifest themselves as role-based mobile apps...
- ECM (including professional networking)
- analytics and reporting
- software factory (covering SOA, API, microservices, ESB if necessary)
- persistent storage
- security (covering identity and authorisation)
Usually CUBE is a multi SaaS, PaaS and aPaaS assembly.
George . . Re: ". . .combining in decision management, cognitive analytics, social bots & many other cloud services"
Agree 100 %
We have and are using "cognitive analytics" but not yet '"predictive analytics".
Examples of "cognitive" are
1) auto-branching decision boxes within BPM flowgraphs (they cause branching on the basis of data on hand, using rule sets).
2) gatekeeper nodes within a BPM flowgraph that block/facilitate advancement based on external data flowing into the environment from external remote systems or apps. (a contractor reporting a shipment made for parts ordered).
An example of "predictive" would be to have several BPM flowgraphs that you export to a Critical Path Method engine that calculates, based on scarce resources, when forward tasks along these flowgraphs can be performed and predicts arrival times at each end node..
I suppose an example of a "predictive analytics/social bot" would be a nurse doing home visits, consulting his/her GPS to predict an arrival time based on traffic and having a phone dialer automatically call the home to provide an expected arrival time.
Yes, the future of BPM is as a "business platform". And the reverse is true too . . . maybe.
======== DETAILS ===========
1. PLATFORM AS SEMANTIC SET -- A software platform is a software system defined by a functional set of semantic constructs for which the platform has been constructed.
2. BUSINESS NEEDS -- The work of business is work. And more successful businesses get more work done with the same inputs.
3. REASON FOR TECHNOLOGY -- The purpose of technology is as a force-multiplier for human effort (physical and mental) to increase productivity, i.e. to get more of that work done.
4. CHARACTERIZATION OF WORK -- Per economics (Ronald Coase et. al.), repetition is necessarily an attribute of how work is organized in business or government.
5. WORK IS PROCESS -- Work in business or government is thus mostly about process, about work characterized by repetition (on a continuum to project, but also including so-called unstructured processes as cases).
6. PROCESS WORK IS NATIVE TO BPM -- BPM is by definition THE technology in which abstractions of process work are first class citizens of that technology.
7. BPM IS
[u][quote][b]A[/b][/u][/quote] PLATFORM FOR WORK AUTOMATION -- BPM is a platform, i.e. a software technology system with necessary semantic support for process work automation.
8. BPM IS
[b] [/b]PLATFORM FOR WORK AUTOMATION -- Therefore, BPM is THE platform for managing the automation of work.
9. BPM WITH BRM ETC. -- Platforms with BPM support will also include other
[u]irreduceable classes of semantic function[/u], such as rules, algorithms, analytics, business logic, UX, data models including documents, identity, SOA/ESB etc., and the same embodied in Systems of Record (ERP etc.) and Systems of Relationship (CRM etc.), but the spine of the system is BPM and work.
10. BPM PLATFORM DEFINITION ALMOST A TAUTOLOGY -- "BPM is the technology platform for work automation; conversely, work automation is achieved using technology in which the artefacts of the semantics of work are constructed using that technology -- which is
[i](The BPM Platform definition is not a tautology if specific BPM software conforming to the BPMN standard is considered, for example as an alternative to directly coding processes with a framework. The idea of "automation platform" is separate from BPM software, platform is a reification of BPM-in-practice, i.e. something emergent, interesting, new and useful. For the first time, BPM technology enables process artefacts to be constructed directly, as opposed to indirectly, via code.)[/i]
11. PROMISE OF BPM-AS-PLATFORM -- W
[u]hether the promise of BPM-as-a-platform is realized[/u]is a separate question outside the system of software and semantics.
[u]Because a platform isn't a platform of interest if no one uses it![/u]The governance, management and sociology of BPM adoption are all challenges.
[u]BPM might be "the greatest"; this is not yet apparent to most management cadres[/u].
[i]But then, it took a few hundred years to get accounting right [/i]. . .
- John Morris
- 1 year ago
I think BPM is a good candidate for the business platform of the future. Neil Ward-Dutton has put together a good presentation around how to tie all the digital threads together to create a great customer experience - and BPM as being one potential answer to the question of how to do it. It isn't the only answer, there are other candidates to the throne.
And as you can read between the lines in above responses, there are many layers of business platform and technology that are already rolled out in organizations. Is BPM going to rip out the existing systems and replace them? probably not. Is it going to overlay them? more probable. Will the solution actually be something that walks like BPM and sounds like BPM but labels itself something else - more probable, in my mind.
The only problem with calling the hosting environment a "BPMs" is why rename an established run-time protocol that has been around for hundreds of years (in medicine, in law, to name two application areas) and call the hosting environment a BPMs?
We want one environment, not one for structured work and another for unstructured work, but we get to a problem if the nature of work in some silo within a particular organization consists only of processes of one step each.
It seems a stretch to call what the silo is doing BPM but we cannot say that the members are not "managing business processes".
The established protocol for Case (gold standard medicine/law enforcement investigation) is:
1) put everything in the Case (no verbal orders).
2) automatically build a Case History (data as it was, at the time it was collected on the form/document versions that were in place at that time, with a date/time stamp and a user "signature" so we know who did what, when).
3) preserve the integrity of the Case History (once in, no changes allowed to the data).
4) refer to the Case History before undertaking any new intervention.
5) be prepared to data share (importing and exporting).
- Karl Walter Keirstead
- 1 year ago
- John Morris
- 1 year ago
BPM is the discipline that focuses on people, machines and their processes which covers all business operational needs. To deliver requires a complete Business Platform and thus yes this is where the future for BPM lies. The issue is just how is this going to happen?
Our 20 years R&D on this very subject established that in reality there are only some 13 generic task types that support that such a platform can use to open a new door for enterprise software to deliver on any operational requirements where people work. As such coding can effectively be eliminated. Sure may still need v clever programmers for complex algorithms etc but all logic should be covered in the Business Platform Software. The following function requirements must be included.
Process engine - to ensure all works to plan.
Rules engine - reflecting real world of compliance.
Calculation engine - automating system work.
State engine - Real time feed back from any point.
Workflow - everything connected in right order.
Audit trail, events, escalations - = control with empowerment.
Rapid prototyping - user involvement in build no need for a final spec
Time recording - supports activity based costing.
Real time reporting - becomes predictive.
Build mash ups - one screen multiple data sources.
Linked intelligent Ajax grids - enter data only once.
Roles and performers - people and machines recognised.
Management hierarchy - see who does what and when to reallocate work
MDM Orchestrating legacy with business processes as required in single environment a - 21st century approach to recognise the past
Call Web Services - wrapped up in a process.
User interface dynamically created linking people, roles, task type and data via forms for specific instances.- supports adaptive capability
Content handler and in memory work capability - to ensure high performance.
Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - recognition of external communications documents etc
Process and task versioning control – ensures minimal disruption, if any, to implementation of changes
The consequences of delivering such relative simplicity to handle all requirements are very profound. Cost is dramatically reduced with v quick build, puts business back into control of their processes, a future proof investment as change readily supported and much more. Such software becomes an asset with long life that could be purchased as with any other asset lease arrangement which will make SaaS “unattractive” financially. IT has job to ensure secure delivery including accessing legacy which could be outsourced?
Quite what this new Business Platform capability will be called time will tell. Certainly should have the Adaptive tag but not sure will have the “BPM” one even if it is that discipline that will determine the requirement It is going to be interesting………!
RE “Is BPM going to rip out the existing systems and replace them? probably not. Is it going to overlay them? more probable.” Such an overlap is very attractive for a BPM-suite tool vendor and dangerous for enterprises which plan to use this tool.
A typical talk from a BPM-suite consultant is “Because we are agile we can deliver very quickly any process-centric solution. Let us select several “quick wins” and we will put them into production. Your users will be delighted! To achieve this we will keep as much as possible your data, users, etc. in our platform to use as much as possible its tremendous functionality. Some time later your team (after passing all necessary trainings and certifications) will be able to integrate data, users, etc. with your corporate environment.”
Sounds great for porotypes, but for production it creates a huge technologic debt – very often those consultants are not available to address properly this debt.
Thus positioning BPM as a business platform creates a serious danger for engaging a “prima-donna”. Think football (soccer) and image a team in this one of the players tries to play alone.
RE “It's interesting to note along this line the on-going "disaggregation" of major ERP platforms, such that individual functions, including individual processes with attendant rule sets etc. are now directly manageable by users (or "subscribers").”
I heard that one of the major ERP platforms has dropped their own BPM tool which was the core of “disintegration” of their monolith. Instead they consider only some processes “between” many tools which they acquired.
One of my clients is going to do "desintegrate" their in-house ERP (170 man x years spent) - seehttp://improving-bpm-systems.blogspot.pt/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html
It is just not easy. It is necessary to create a aPaaS with a lot of business functionality.
As for ERP frankly never believed in it and yes the new Business Platform supporting BPM will start the journey to "retire" ERP.....?
- David Chassels
- 1 year ago
At the moment - communication and instant messaging tools
[b]are [/b]the "business platform" because they are incredibly simple, they work on phones and can be used in 10 seconds flat. You can't argue with 2 billion+ people using such tools to get work done today.
For any process platform to actually become a business platform - the criteria is therefore the same. Given the criteria above, legacy BPM achieves none of them - so it will be impossible for anyone non-IT to use - and will therefore never be "naturally" adopted by any modern company.
Remember that adoption of the easiest tools comes from the ground up - from real people who actually WANT to use these tools and approaches. IT cannot institute "adoption" by ignoring UX and talking in a private room about low-code and process models. Business users are going directly to the app store or the web - to get apps that actually work - circumventing IT with their company and even personal credit cards.
I read a study recently (lost the reference) which suggested that 50% of all IT spending will not go through IT or the CIO within a couple of years. If that really is the case - then the answer to the question of a "business platform" is what non-IT people adopt - from the ground up.
Silicon Valley, CA
> A business process is not a linear checklist, unless you are unwilling to ignore business exceptions. What happens if the buyer says he bought 10 units, but the receptionist only received 9? How do you put that in a checklist? So many cases that are incredibly non-linear and dynamic.
If you saying "we haven't achieved this" - we have already achieved this - through real-time dynamic checklists with conditional rules. See this link - https://tallyfy.com/features where we have all the above, and much more. We even have crowd-sourced process improvement ideas as comment objects that go up to the process owner for moderation. A problem on a step is a first-class object, it's built for real-life problems and conversation. Maybe it's the first time this has ever happened - we don't know. Maybe you can help us figure that out! I have no idea why it wasn't always like this. PS - I'm 35!
In terms of the 5 minutes thing - people are actually doing it, right now. I watched a non-expert codify a simple flowchart with decision conditionals and a loop within 5 minutes.
As for all the rest - time will tell, as neither of us can control this. The one thing that is definite is that the smartphone and the web have changed everything. And that change is exponential and massive, not gradual like in the past.
A business process is not a linear checklist, unless you are unwilling to ignore business exceptions. What happens if the buyer says he bought 10 units, but the receptionist only received 9? How do you put that in a checklist? So many cases that are incredibly non-linear and dynamic.
"In 5 years, IT will be nothing more than vendor management, in any part of the world"... oookay, I'll hold you to it :-)
"The future is that anyone - without any training, can build and run a process."... 5 years, you say? :-) Then I get to choose the "anyone" and the "business process" and have a go, okay?
> I do agree with your point on non-IT user adoption - that is the only barrier to enterprise IT transformation projects, BPM or not.
This is the wrong attitude, and exactly the point I'm making. There's no "barrier to IT transformation". The barrier IS IT. They see users as "the barrier" because users are going to tools they actually WANT to use. Everyone needs to embrace this, not call it a "barrier". A lot more of our thoughts on that:
> properly implemented BPM-centric solutions.
Properly implemented in whose eyes? What IT thinks is "properly implemented" is hardly ever acceptable to users.
> A flowchart is a graphical representation of the application logic
Why can't it be a checklist? Why can't anyone at all (without any training) simply create a process as a checklist in the first place?
> I have yet to find a company in my corner of the emerging world that lets their employees spend away IT money without IT involvement.
This is an illusion of "control". In 5 years, IT will be nothing more than vendor management, in any part of the world. Users can go anywhere - app stores, the web, etc. and get whatever they like, often for free. Since they know IT is trying to control them - this will all be under the radar, as it is everywhere today. If someone wants to get their job done - they're not going to ask IT anyway.
> I don't understand the term "legacy BPM" - could you please expand
IMO - legacy BPM is anything that uses flowcharts or BPMN. This is because it's only for trained process analysts and IT. The future is that anyone - without any training, can build and run a process.
I have to challenge your take, I hope you don't mind:
1. communication + IM tools are heavily used, indeed. That doesn't mean it is the ideal. We can't have a discussion about disruption, if we think large markets are always right. I'd argue that business communication right now is ripe for disruption - it is the most abundant and at the same time least filled with substance way of doing business. That's why many people complain of either communication overload or lack of communication. At the same time!
2. I don't understand the term "legacy BPM" - could you please expand. In my mind legacy is anything that uses entrenched, hard-coded rules and activities in the underlying software. That's barely the case with properly implemented BPM-centric solutions.
3. A BPM approach does not exclude beautiful, meaningful UX. A flowchart is a graphical representation of the application logic, not UX. I'm not asking my users to follow flowcharts - my UX is a tasklist consolidation of all their process activities.
4. I don't know about this 50%. I guess the study focused on specific customers and markets. I have yet to find a company in my corner of the emerging world that lets their employees spend away IT money without IT involvement.
I do agree with your point on non-IT user adoption - that is the only barrier to enterprise IT transformation projects, BPM or not.
Sorry, Amit, we're running out of comment real estate so I moved the discussion one level up :-)
If I understand well (and were to translate what your app does in "legacy BPM" talk), you are creating a proprietary business rules engine.
Nothing that can't be achieved with DMN business rules called out of a simple BPMN workflow.
Also, I can get any non-expert codify a simple flowchart in BPMN in 5 minutes too. Or a simple decision table in DMN in probably less.
Sure, the interface must be simple and suggestive enough to warrant meaningful participation - and we agree here that most BPMS's simply suck at UX.
The other key thing is to bring the BPM vocabulary to people who don't know or care about what it is. Hence, re-framing things as a business problem - the actual process, as opposed to the language of BPM.
Another key thing is real-time tracking of people doing a process. Modelling is useless - unless "doing" it happens within seconds of building it, in real-time, with no training, amongst a group of people.
So those imo - are the first bite-size chunks that we ourselves really care about deeply. There's much more which is FAR more interesting and "disruptive" - but I can't talk about it in a public forum ;)
Yes, we also deeply care about UX and framing all business process matters outside the BPM practitioner's vocabulary. Our user interface is a bit more than a checklist or a tasklist (as usual with BPM cockpits) or a control panel (as usual with heavyweight BPMSs), more centered around clustering the types of interactions a user has with the company he works for.
As for real-time tracking, yes we have that too. Process mining is more than that, it is a whole science by itself. I see it's usefulness outside the run-of-the-mill process tracking (called Business Activity Monitoring in "legacy" limbo). Process mining is useful when you start thinking about process discovery, human tasks "load balancing" etc.
For me, the BPM is a key component of the future business platform. However It won’t be self-sufficient. I think the future business platform will be a platform where business and IT can collaborate to build engaging BPM based applications that can be integrated seamlessly in any complex enterprise IT.
The business and IT will rely on BPM notation, but maybe also DMN and CMN, to design their business applications.
- Page :
However, you are not allowed to reply to this post.