BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 19 December 2017
  5.  Subscribe via email
Looking toward the year ahead, what would you say are the biggest challenges facing BPM in 2018?
Accepted Answer Pending Moderation
The challenge maybe as simple as below in Twitter exchange earlier today! Experts love "data" and "digital" as good sound bytes but reality is as I articulated all driven by people and their processes....Why well most do not really understand as computers with their inside out systems lost the basics of how business really works!

Scottish care providers ‘need #data and #digital’. National plan points to need for better workforce data to suppor… https://t.co/8ij6knEfe6
@A_C_Summer @UKAuthority It's about people and processes to deliver data via digital called #BPM see https://t.co/fyO1ybYdou Do research!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
One challenge for BPM will likely be the risk of further slipping into the realm of commodities. Especially, looking at it from BPMS perspective: there are currently many BPM vendors doing roughly the same thing, with little to no real differentiation that matter to the final customer, which in turn will leverage price and services as competitive advantages.
I believe that end-user relevant features in the form of intuitive, low- and no code, cloud based solutions as part of- or as a complement to BPM Platforms, will be the key to achieve a positive differentiation, besides price.
NSI Soluciones - ABPMP PTY
Comment
@Kay
Agree with " . . .end-user relevant features . . will be the key to achieve a positive differentiation"
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
BPM vendors: Finding a profitable niche and getting REALLY good at it.
Customers: Not their problem. They don't care about BPM
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I mostly agree with Kay Winkler

But I would add a point regarding to the change of the BPM Consultant role. We come from many years in which companies were literally unable to implement a complex process using a BPM Suite without the intervention of a BPM Consultant specialized on the specific BPM Suite. One of the things that Cloud BPM are allowing, is to allow business people or IT people without BPM knowledge, to implement and deploy their own Business Processes.

Summing up Zapier and other IFTTT tools, they are also able to orchestrate services and micro services in an easy way, to build more complex processes that talk with different cloud apps, with little or no help from Consultants at all.

Woow, this is a huge change for this historic role, but in my opinion the role will evolve to a "enabler", rather than a "doer".

Best for all !
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
I am with Kay. A commonly agreed reference model and reference architecture as the biggest (and, naturally, grown up) challenges successfully inherited by BPM in the year 2018.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
@Kay
Interesting you mention commoditization as that is what I see as the exciting future for BPM!
Enterprise Software as has evolved as hugely complex and expensive where vendors and their supply chain have thrived. The evolution to commoditization is frankly long overdue. The reality is there are less than 13 generic task types including the UI which support the creation of data by people. Such commoditization opens a new door for future proof customisation with the driver being the BPM discipline thinking. This will be hard for many to understand never mind accept but it is just a question of time. That is the challenge for 2018!

@Juan
Yes you are right that orchestration is vital as is the ability to handle complex processes. Build will be in hands of business people working direct with users and such coordination will be enhanced by BPM knowledge without need to code build is very quick and change readily supported. Salient processes will be recognised as assets giving that competitive advantage. Yes private clouds but not lock in to a vendor cloud which will not be either sensible or cost effective. You are right it is going to be a historic change.....and very disruptive to existing supply chain but great for end user customers...as commoditization always is!
Comment
  1. Kay Winkler
  2. 12 months ago
  3. #4891
Absolutely, each challenge also represents an opportunity. BPM as a commodity, in that sense, should also entail a broader user base. The trick of harnessing the implicit opportunity, would be, as you stated, evangelizing BPM methodologies, frameworks and architectures - or - new, breakthrough features and technologies, to stand out of the crowd. There however, I haven't seen anything of real impact for 2018.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
@Kay - not sure if BPM slipping into commodity is not actually a desirable goal. I've seen plenty of claims of how BPM is dead, how BPM has not taken off despite its promise.... and then when we see a lot of small vendors doing BPM we complain that it's getting commoditized. I frankly want to be part of this small vendor wave doing BPM that actually builds this whole industry towards critical mass. :-)
But building on your point though Kay, the danger is not commoditization, but the dilution of the BPM promise ( aka "bridges business design and IT execution" ) which drives frustration at customers. And this is caused by two types of "new BPM consultants":
1. There's so many of them that have zero business experience - they couldn't spot a bad business process design to save their lives. These people use "BPM" as a hook to just code apps for customers, using very little process design, and the rest of the app logic is buried in cron jobs, stored procedures, and morsels of code spread around the stack etc. They cause havoc at the customers and they destroy the concept of BPM.
2. The low-code dudes. Couple of months ago, I was a speaker at a regional BPM conference and there was this dude, a partner of a large BPMS player (not saying names because quadrants and whatnot), that was outright claiming he can build an app in 5 minutes. Me being me, couldn't resist calling him out. Turns out that in 5 minutes you could actually just drop a form with two fields and a button - that's not an app. So these lies are incredibly toxic to the customers' expectations of the value of a process solution - if it only takes you 5 minutes to solve my very complex business problem, there must be very little value in your delivery.
CEO, Co-founder, Profluo
Comment
  1. David Chassels
  2. 12 months ago
  3. #4890
So true about App hype. An App is only one UI in an enterprise system. It's time analysts get a grip of capabilities and how not relying on the vendor marketing hype! Accountability is becoming even more important with the clamp down on corruption see this example! https://translate.google.com/translate?depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=ar&sp=nmt4&tl=en&u=http://almasalah.com/ar/PrintNewspage.aspx%3Fnewsid%3D120853
All front line i.e. BPM systems need full audit trail and record who did what when....and where the money actually goes!
As for build time in no code I am sure many variations but our guide is every UI represents a man day to build the end to end application ready for first feedback from users. By removing the traditional complexity to build with custom coding the emphasis switches to the process knowledge requirements. I see future BPM Vendors having that skills set to help business and with domain knowledge have pre built templates ready to customise for each customer. The customer should have access to the build environment to allow them to implement changes themselves but our experience indicates once trust established the external help becomes a valued relationship for all.
  1. Kay Winkler
  2. 12 months ago
  3. #4892
Great input. As to the low code, no code wave/hype - I am a skeptical believer (very oxymoronic, I know). I do believe, that being able to express and more importantly to instrumentalize a fully functional, optimized and to some degree automated business process without or only very little code, favors the cause of BPM. It reduces the dependency of the programming middleman, hence "language barriers" and bottlenecks. Sure, there always will be a remnant degree of coding involved - but, in my opinion, its a good thing, when programming doesn't become the prevalent aspect of any BPM initiative one undertakes.
I am a skeptic when people equate low/no code with "easy", "simple" or "fast". I firmly believe that currently each BPM implementation is defined by 2 sets of languages (or domain expertise, if you will) - the language of code (including all aspects that can be contributed to HW/Architecture) and the language of processes. While the "language of code" is just a current means to an end, the language of processes in BPM IS the end. So, reducing or eliminating programming, should indeed make any BPM project easier but not easy nor necessarily a 5 minutes affair. If anything, it should give expert consultants the space to enrich the prose of their process lyrics :)
I'm with you, Kay. I'm all for increased coding productivity, and this is something BPM benefits greatly from, when properly implemented. However - a couple of years I would have strongly agreed with you that the "language of code" is just a means to an end. I now tend to believe this is not true. In today's world, just as the medium is morphing the way content is consumed (e.g reading on mobile constrains most types of content), in the same way the choice of the language of code has a major impact in the ultimate BPM goal.
Not all programming languages are created equal, and not all development tools yield similar outcomes. Believe me, I have seen quite a few Petri net monsters implemented by people who were adamant at using Ruby on Rails only :-)
  1. John Morris
  2. 12 months ago
  3. #4901
@Bogdan your comments about #fakeBPM (I think this is a reasonable summary) reminds me of #fakeWebsiteDesign. If you look at WordPress or Drupal "themes", there are literally thousands of them, all sort of looking the same ("beautiful"), but the number of themes that are founded on good graphic design and typography is very small. This phenomenon is comparable to pretending to do business process management while slinging code. But not understanding business. There is real domain knowledge in both graphic design and in business process management.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
The biggest challenge for BPM will be transitioning from a sharp focus on efficiency to a focus on meeting objectives of initiatives.

This will only happen if, as, and when management and BPM practitioners come to realize that the contribution of efficiency to building / improving competitive advantage is less than the contribution of operational effectiveness. (i.e meeting objectives).

Proof: "There is nothing worse than an elegant solution to the wrong problem"
References
  1. https://kwkeirstead.wordpress.com/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
The start of the biggest challenge for BPM in 2018 is to continue the process which several correspondents have highlighted above, which is the process of commoditization.

But can we take the process of commoditization even further?

Specifically, we are concerned with commoditizing "business process management automation software technology". As I have noted elsewhere on BPM.com, the technical improvements in BPM software technology are very important for BPM software adoption. Particularly, math- and software engineering-based improvements make using BPM software much easier. This improvement shows up in the "WYDIWYE" acronym ( "what you draw is what you execute" ), where there are few if any restrictions on sensible workflow patterns that you can draw. (The penalty for having artificial restrictions, artefacts of immature technology, on what business analysts can draw are enormous. Customers start with enthusiasm for BPM based on sales presentations, but in the past have typically run into roadblocks where workflows one wants to and expects to be able to do can't be done without clumsy workarounds. And after a few months, the project stalls.)

What has the continuing improvement of BPM software technology have to do with commoditization?

Commoditization means that BPM is "becoming a product" as opposed to a "framework". And this means that BPM can be sold to business side (at least business analysts). Commoditization only is possible for products or productized services, not frameworks used by consultants. Of course commoditization may be a challenge for organizations which have a stake in the game for pre-commodization consulting services. And former BPM market leaders who have de facto abandoned BPM-as-BPM may come to regret their strategy of burying BPM in a Swiss Army Knife software package.

But let's go further. This won't happen all-of-a-sudden in 2018, but the increasing productization and commoditization is the gateway to the future of BPM. I have compared BPM technology to accounting technology. Accounting technology (double-entry data model, ledger workflow, accounting software etc.) is wrapped in a whole world of business and social support, some of that discourse being professional, but not all of it. All business people know debits and credits and cash flow. I believe that BPM and workflow technology is both a distinct and important business technology that over time will follow the same path. (One can debate whether BPM and accounting stay distinct from each other.) But for BPM technology champions there's a big upside to technological maturity; adoption on a much broader scale into business departments is now possible. The use cases and the business cases are there. Now to build the capabilities. BPM can "cross the chasm".

In 2018, the challenge and opportunity is too stay the course with BPM-as-unique-technology, as BPM software itself productizes and commoditizes. Work to build bridgeheads with business analysts especially. And build the professional practices around the use of BPM. The technology keeps improving. Time to put it to work.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
John makes good point about accounting and the path which BPM could follow. As a Scottish CA I have been concerned at the lack of focus since the 80s by the profession on the source creation of new data which we know is about people and their processes. Until then audit tracked activity "bumping and ticking" book keeping entries and latterly mapping out processes to look for weaknesses in the activity which created information. But then IT took over the responsibility as software driven by inside out thinking took over giving the false impression that just because the books squared with computer processing all was well!

We are now seeing with "digital" a need to focus on delivering that vital front line software capability to allow all people to create new information to deliver on outcome objectives. I see with the supporting software to the BPM thinking will deliver greater reassurance with full audit trails of activity than the centuries old thinking in double entry accounting! I am raising this issue with my professional body and I hope this may trigger a rethink on the accounting profession recognising the underlying power of BPM to give that vital assurance and bring true accountability to all operational activity.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Some great insights here. I'd offer this: that BPM in 2018 isn't the "what" - it is the "how". (those who don't leverage BPM will be consigned to hard-coding those processes in code, databases, or implicit user behavior... )
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
The biggest challenge to Business Management is complexity. Complexity obviously results in higher costs. This complexity is only going to get worse, not better as the number of bpm applications, formally and informally sourced, within an enterprise increase.
Kritika Pandey (Software Analyst)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.