BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 06 July 2017
  5.  Subscribe via email
Would you say today's BPM is treated too much like a tech solution rather than a people solution?
Accepted Answer Pending Moderation
BPM has always been "too much tech" -- especially because of the round-trip problem and the intermixing of technical and business logic. It would be tempting to say "focus more on people" -- and indeed any good design and deployment of software should have great UX and user experience and training etc. However, the purpose of BPM technology is the automation of work, which may or may not include people. Starting from the work that needs to be automated is the right focus.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Building on John's comment: "However, the purpose of BPM technology is the automation of work, which may or may not include people"... I've found that most BPM tech projects devolve into Just Another Custom Application Project because they do focus too narrowly on "the automation of work" rather than on being able to "adapt the automation to changing business needs".

BPM tech just simply doesn't work without BPM methodology. Automate, Monitor, Improve - or you just end up with Automate, Trash, Replace.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. John Morris
  2. 1 year ago
  3. #4178
+1 @JohnR -- it's true that "automating work" can too easily become "paving the cowpath"! : )
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Just thinking out loud here, but isn't the purpose of all IT (not just BPM tech) the automation of work of one kind or another?
Comment
I'm just being pedantic, but probably you meant to exclude most consumer IT. :-)
  1. John Morris
  2. 1 year ago
  3. #4182
@Neil -- good comment -- because of course the answer is "yes" -- all IT and software are technologies, the purpose of which is force-multiplication of human brain (or brawn, in the case of robots and machinery) for the execution of work. And there is a continuum from "simple tools" to technology too, thus software is theoretically on a continuum with a hammer.
Now we are left with your second question (so many queries in such a short statement!), which is something like "is there anything unique about BPM and work, if all technology is about work?" This question is a central question to the BPM business and BPM product and service sales!
My answer is absolutely "yes". Per my article series here on BPM.com, BPM is the technology of the work of business because "only in BPM software technology are the concepts of work first-class citizens of that technology". In all other technologies one constructs or one has hard-coded software tools. Thus BPM really is unique. Why not sell it as such? : )
https://bpm.com/bpm-today/blogs/1144-why-bpm-is-unique-important-part-1
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I'd like to provide a slightly contrarian view (and I know it's a risky endeavour doing so against both Johns above ;-) ), but frankly I see BPM more about empowering and enhancing human business users. Yes, automation of work is one main thing by which this is done.

But let's not exclude ability of tech to provide unique insights, to shorten the time between insight and action, to support more quality in decision-making activities.

Yes, it could be argued that this is also sometimes automation, but I tend to perceive automation as a more narrow type of intervention, where activities and rules are being delegated to machines. That to me is just the low hanging fruit (and with the lowest return) of BPM projects.
CEO, Co-founder, Profluo
Comment
+1, "low hanging fruit" buys stakeholders' engagement and sponsorship.
  1. John Morris
  2. 1 year ago
  3. #4181
I agree with everything you've said @Bogdan! Except per my comment below I think BPM will be successful insofar as it isn't subject to "the lure of the generic". :)
@Patrick: low hanging fruits and engagement are ALWAYS highly correlated :-)
RE "ALWAYS highly correlated" except at clients who already understood that "low hanging fruit" is actually low for vendors/consultants.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Neither . . . .

Not about tech, except for those who are selling BPM as tech.

Not about people, at the customer level (although it can impact people at customer sites/installations in multiple ways), as customers typically have a mix of tasks that a) need to be performed by people or b) need or can be performed by devices/local apps/remote apps.

And, it's not about continuous improvement where the focus can sharpen to where the desire to constantly tweak has no ROI justification. (i.e. hammers looking for nails).

BPM is all about providing background orchestration and governance in the area of workflow and workload management and the mix of candidate industry/application areas can go from 5/95% machine-machine to 95/5% people-machines.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
As per the discussion above, today's question concerning BPM-as-people solution versus BPM-as-tech-solution is very much a sales and marketing question. Considering the BPM sales and marketing question then, one is haunted by a fear that BPM software technology adoption may be doomed because of generic marketing and product marketing.

A quick glance at some leading BPM software vendor webpages (at random Pegasystems, Software AG, Oracle) reveals that BPM is about "operational efficiency", "business visibility", "CX", "streamlined operations", "business agility" and "the ability to quickly create and change business applications". (In fairness, my summary list of BPM benefits is not directly quoted from or representative of the listed vendors.)

These BPM business benefits are all true and important! But they can also be said of many other technologies!

If that's all we say about BPM, then we are saying that there's really nothing special about BPM software technology, nothing special that's worth talking about in public. There's "no BPM here". BPM is just another twist on RAD ( "rapid application development" ). (And selling RAD is not a great business to be in. There's rarely much of a business case for infrastructure.)

I wrote about this kind of problem back in 2009 in a post entitled How Not To End Up On A Level Playing Field With The Competition. The post references the idea of the "lure of the generic". The "lure of the generic" is the idea that all technology is used in support of such common business cases as for "faster time-to-market" or "lower operational costs" or "increased flexibility and agility" etc, etc. The problem with this list is that it is a set of generic benefits for generic business cases. If that's all your selling and you're a small vendor, you're in trouble. Because big vendors can say these generic business benefits 100X or 1000X louder than you can. If you're a big vendor, you're still in trouble: BPM adoption rates and the evolution of BPM vendor positioning are evidence of this.

The secret to technology sales is being able to make the business case AND the technology case together. Don't hide your light! BPM vendors often hide their light because they don't believe that there's anything special about BPM. If you want to have successful BPM marketing and product marketing, your customer-facing staff must really know what BPM is all about -- and not be shy about sharing that message.

Per my recent article series here on BPM.com, BPM is an absolutely unique and important technology - not just another generic flavour of RAD. And this uniqueness is powerful! BPM software technology is the technology of the work of business because, by definition, "only in BPM software technology are the concepts of work and process first-class citizens of that technology". In all other technologies one hard-codes from primitives the functions which define the work-capability of a given software tool. Thus the distance from management idea to useful artefact is immeasurably greater than with BPM.

Why hide one's light? Why succumb to the lure of the generic? Why not sell BPM as the revolutionary technology that it is? Across the globe businesses are turning away from financial engineering and realizing that long-term business success comes from taking responsibility for "what's inside the black box of work". BPM is the technology that is needed now.

BPM.com article series, No #01: Why BPM Is Unique And Important
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
The line between people and tech is thinner every day. You may not differentiate a tech solution than a people solution because the second nearly always, involves a lot of tech.

In the same line, BPM is a discipline involving methodologies (people centered) and technologies. But the first, relays heavily on the second (for example to specify you use a diagramming tool, to analyze and improve you use a BI module...). The effect is that the line between people and technology gets even thinner.

In sum, I think the phenomenon is positive, BPM initiatives becoming an extension of our business live, where tech and people coexists with increasing transparent integration.
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
@John M. “BPM Is Unique And Important” – but it still didn’t manage to deliver all its promises. Why?

Who/what is guilty today? BPM technology? BPM methodology? Technology? People? BPM vendors? BPM consultants? All of them together?

Who/what can save BPM today? BPM technology? BPM methodology? Technology? People? BPM vendors? BPM consultants? All of them together?

It seem that the today’s bet is technology. But, may be something else?

Thanks,
AS
Comment
  1. John Morris
  2. 1 year ago
  3. #4183
@Alexander -- really excellent questions! I will try an answer -- first BPM technology is inherently challenging and until recently has been much more difficult to use -- but now with executable BPMN and the possibility of deployment via the Volker Stiehl business logic segregation pattern, there is the possibility of much better results and lower costs.
Second however, there is the whole "commitment question" -- or we could say the "sociology of work automation". I hint at this above with my comment re: "the black box of work". BPM is about structured thinking about the application of technology to the work of business. This puts a lot of pressure on executives to think in systems terms. (It's also the subject of the next Paper in the series.) At least the technology is ready now!
There's a world to win for the vendor or community that figures out how to get great BPM technology married to embedded business practices. I have often referred to the adoption of accounting technology, which is now deeply embedded in business. There is a lot to learn from that social process.
@John, shall we move from enterprise thinking (we are special) to systems thinking (we are a unique mixture of common and specific) to advance with BPM?
John
I think we are on the same page....great BPM (supporting software) married to embedded business practices" that is the key...and in previous question I lay out those "practices"/ tasks which is proven to cover all operational business requirements. Just highlights business is actually quite simple when analysed into sequential actions ...and has not nor will ever change! All far too simple for IT but then again suppliers make a lot of money out of complexity....
@Alex: "shall we move [...] to systems thinking" yyyup.
@Bogdan, Thanks. May have a look at https://www.slideshare.net/samarin/smart-cities-from-the-systems-point-of-view "Smart Cities from the systems point of view"
  1. John Morris
  2. 1 year ago
  3. #4189
@Alexander, per your comment above , I agree with @Bogdan that systems thinking is the target for the work-of-management, However the question of systems thinking (and/or enteprise thinking) is orthogonal to BPM software technology. I keep emphasizing the separateness of BPM technology; without acknowledgement of the unique power and importance of BPM software technology, sales are much more difficult and adoption is impaired.
@John, the best solution is not always the best political or sales solution.
  1. John Morris
  2. 1 year ago
  3. #4192
@Alexander, true enough that the best technology doesn't always win . . . except (a sales person must be both cynical and enthusiastic at the same time) in a reasonably free market, over a longer period of time, one can have some measure of confidence that the good which is new will win. Modern life is proof of this. The fact that BPM is not yet ubiquitous and that the promise of BPM is as of yet unfulfilled is explainable -- but as we have discussed otherwise, circumstances are changing which make real BPM sales growth possible now. (It won't happen magically!)
@John Agree well said just a question of time.....
  1. John Morris
  2. 1 year ago
  3. #4195
@David, thanks. And, per "just a question of time" for great BPM technology adoption - we both agree this desired state is probable, for the reasons mentioned. But (as has been discussed elsewhere on BPM.com) probability is not uncertainty and there is always the possibility of a "sub-optimal steady-state of BPM technology adoption and BPM technology market". Markets, especially markets for infrastructure technologies, don't always work very well . . . it's up to practitioners, champions, vendors and users to make the change. There's a role for "will". And "will" translates into sales -- especially for sales that is about "why BPM" and not only "why-ROI and why faster-time-to-market and go-business-transformation"...
@John, RE "markets for infrastructure technologies, don't always work very well . . . it's up to practitioners, champions, vendors and users to make the change." - Infrastructure is strong associated with standards and, considering the current standardisation efforts in BPM, "just a question of time" may be rather optimistic.
@Alexander Yes you are right so it is going to take a new approach and serious money! The core code needs to be readily available globally not open source more a "collaborative" approach all work together to keep advancing capabilities ....and be taken seriously by genuine independent analysts and standard makers. However it will the significantly lower costs to deliver which will win the day in longer term and staying out of clutches of big vendors......!
@David, unfortunately, it is not a new approach and a lot of money will be saved. I had recently a small calculation about implementation cost - smart cities with standardisation vs smart cities without standardisation - the ration is 1:3
@Alexander...it depends what you "standardise" ....I suggest recognition that there are less than 13 generic standard tasks (as previously noted) and believe me this dramatically reduces costs both implementation and operational running costs. See example here
http://data.parliament.uk/writtenevidence/committeeevidence.svc/evidencedocument/public-administration-and-constitutional-affairs-committee/inquiry-into-government-accounts/written/38055.html. Less than £2m over 15+ years for complex case management ...and recognised as most efficient. Other similar UK Government systems £300m+ and loads of issues..let's say 10% of Old IT ways....? Now you begin to see why current supply chain resist......as do internal self interests....Just a question of time for Accountability.
  1. John Morris
  2. 1 year ago
  3. #4200
+1 @David "13 generic standard tasks" . . . although if one goes further up the stack to sector- and function-specific business process patterns you will find a proliferation of patterns. Nevertheless, that's what industry-specific boutiques and business partners are for . . .
  1. John Morris
  2. 1 year ago
  3. #4201
+1 @Alexander "standardization efforts" . . . although I submit that there's a big difference between standardization around technical infrastructure and standardization around business patterns. The EDI and electronic commerce patterns are examples of higher-level standards -- but to your point, progress and complexity have been challenging even in this highly structured space. Nevertheless I say that it's better to be building standards around business content than building standards without business content -- at least from the business executive's point of view. Until now the immaturity of the first (technical standards) has made the second (business standards) less of an opportunity.
@John....you "got it" yes domain knowledge will see specialist pre built tasks/subprocesses created by those that deliver. With this new "standard" approach there should be no "lock in" as buyer customers will have access to the build environment to use themselves or switch supplier..this ensures they own not just their data but their processes which become tangible assets and so suitable for lease buy much more attractive than SaaS....?
RE "big difference between standardization around technical infrastructure and standardization around business patterns." - Excellent point. The former is used as a service (i.e. as-is at the design and execution/run time) and the former is used as a template to be adopted and adapted at design time. Thus, the former needs some "flavor" of systems engineering and it is different from product standardization. See http://improving-bpm-systems.blogspot.ch/2017/02/systems-level-standardisation-example.html
@David RE ".it depends what you "standardise" .." Sure. And, how you "standardise", e.g. patterns must be treated differently from services and interfaces.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
I have always seen BPM as the discipline in thinking how information is created which of course takes you straight to people and process. In the '70s I was mapping processes talking to people who did the work with objective to spot weaknesses where audit could focus. So nothing new in thinking. I believe it was late 90s that "BPM" tag evolved from those involved with "IT" recognising the emerging gap between people and the silo inside out systems. Mapping processes is easy the challenge was how to translate into a working application and it inevitably ended up up in hands of IT coders etc and with "disappointing" results...and therefore seen as a tech project with associated high failure rates. As ever became over hyped with good marketing but in reality poor delivery.

So some 20 years on where are we? Yes big vendors still over sell capabilities but there are new challengers emerging with the software which does now fully support the BPM thinking. The Digital Business Platform DBP is now the answer where coding can effectively be eliminated and yet deliver on all business requirements with direct input from users. This now makes it a "people solution" where tech is in support for secure delivery and handling the legacy mess. Before business can try push for this new capability they need to be educated on how this actually works and remove the cynicism of being another complex IT tech solution! Once business understands then the door opens for genuine business objectives to be addressed with confidence.

I see empowerment for users with support for ready change to their processes as a strong driver. Real time feed back on activity for better decision making with audit trails for the ever increasing world of compliance. As I have said the key to the empowerment door is understanding how the DPB actually works and the move to people from tech will be complete. This will change the world of enterprise software in a very disruptive way....and that is the real challenge....!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
@David...

I say the real challenge is to understand why there is a challenge, other than normal resistance to anything new, different or "not invented here".

You say

" "BPM" tag evolved from those involved with "IT" recognising the emerging gap between people and the silo inside out systems. Mapping processes is easy the challenge was how to translate into a working application and it inevitably ended up in hands of IT coders etc and with "disappointing" results."

Engineering consulting/construction companies in the late 1950s faced the problem of mapping (I would not rank 10 years of necessary mechanical engineering experience to be in a position to know what to map as "easy" but these folks were designing as well as rolling out and using their workflows).

IT was around and they did not seem to have any problem understanding what was needed.

The results were not "disappointing", rather the opposite.

So, a big question that comes up is whether there really is that much of a difference between:

a) a once-through construction process that crosses silos and has a heavy content of outside suppliers who need to perform work and report progress.

b) a "business" process that serves as a template to generate multiple instances.


One (unimportant) difference is that in CPM you perform all tasks, including the ones you forgot to include, so we have ad hoc steps in both CPM and BPM.

There are loopbacks, where you do some work, the result is unacceptable and you have to loop back and do the work over again. Common to both.

Time is of the essence, in both methodologies, resources are scarce, there is a need for periodic reviews, different approaches cost more than others. Nothing different here.

For repeat work (building a field of houses), there is a lot of repetition and workload management (scheduling, leveling and balancing) plus an opportunity to learn and improve the process.

So, no wonder Alexander asks what the big deal IS with BPM and why we have fails?

I don't get it!
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Yes, most of the times it indeed is. Whole schools of thought and bodies of knowledge have been created around the idea that BPM is a discipline that entails BPMS, rather than being a technology that manages to stand on its own.
Being a discipline opens the window for BPM to provide solutions that connect people as well as technologies, end-to-end, as the ABPMP CBOK stresses.
One of the reasons for BPM being treated more as tech solution, is directly related to funding and budgeting BPM implementations. Aspects that would lead to a people solution, beginning with people driven discovery workshops, are all too often shrugged off as an unnecessary expense.That in turn provokes a BPM solution to be very narrow in focus, catering only to the IT stakeholders that have been tasked with "automating processes with some BPM tool".
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
@Karl
Where innovation challenges an existing market with significant benefits for buyers but with also significant negative impact on existing suppliers the "challenge" becomes a threat and believe me many vested interests, internal and external, will protect themselves in variety of ways. It is called the Innovators Dilemma and many good technologies have been held back .......but this could soon change with global initiatives to seek out such technologies and see properly funded.....for the better good of all not the few!

The IT enterprise software industry has an interesting dichotomy it is "mature" yet has immature product set unlike hardware which is at commodity level. I see the delivery of the no low code Platform Software driven by BPM thinking at fraction of cost will at last bring commoditization to this sector with significant impact on the way the current market works. That is the "real challenge" !

In terms of where this sits think of a "greenfield" of this new adaptive software surrounding the "brownfield" of legacy. This over time will see many legacy systems "retired" as the new systems create one version of the truth yet use functional legacy e.g. accounting records as required...all the slave to the new people driven software. As such many current gaps are closed including the one you mention This removal of need to code was a dream of the 80s but now could soon be a reality....watch this space...!

Not sure what you do not get? If it is do all those tasks in previous debate actually deliver the answer is yes...and even we were surprised at capability. Indeed early adopters saw capabilities we did not think of so it was a very steep learning curve for all! The next decade in going to be interesting and in enterprise software BPM is going to have important role....supported by next generation Adaptive Software built using a DBP.
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.