BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 20 June 2017
  5.  Subscribe via email
As this article states, "BPM no longer requires implementation by a person with technical expertise. The days of processes being documented by business analysts and implemented by developers are disappearing." What do you think?
Accepted Answer Pending Moderation
If anything, it seems like Technical Expertise is more necessary for implementing successful BPM solutions, rather than less.
There was a whole generation of BPM suites that provided very simple in-suite tools for the creation of UIs for process tasks, and OOTB "portals" for users to see and act on their tasks, but those UIs don't seem to have provided the UX that's demanded by customers (and many employees).
That's led to BPM being "headless" more often - exposing APIs on top of which applications are built - and building those applications requires traditional UI Development skills.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Anyone who says ‘and using this tool I can remove the programmers’ just became the programmer

- Allan Kelly
Comment
so true
" but those UIs don't seem to have provided the UX that's demanded by customers (and many employees)." Sure they do, just put a whoole bunch of tabs into a single coach and then... ;) #MemoryWhatMemoryWhoNeedsMemory
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
There is a difference between babbling at a so-called high level in meta language about semantics here, ontologies there, tossing a microservice in now and then and creating a useful it system. As said before Coding is defining how your business is going to work. Coding can be done in graphic models like bpmn, a dsl, or for my part in nerdy machine language. Business people that model are developers. (https://bpm.com/bpm-today/in-the-forum/5088-how-do-microservices-relate-to-processes-and-bpm). There is nothing lowbrow or despisable about coding and developing, developers are not the scum of earth that give a form to the brilliant ideas of business people. You need technical expertise.
The days of processes being documented by business analysts and implemented by developers are disappearing. is an ideal of course. With models understandable by business analysts and lets call them just developers, the graphic models in a sense become executable documentation that can be created side by side.
Also read https://blog.bernd-ruecker.com/the-7-sins-of-workflow-b3641736bf5c (Bernd is from Camunda, he knows where he is talking about):
I want to quote the analyst Sandy Kemsley’s report written in 2014 — as it summarizes this sin quite nicely:
“Many BPM experts today will tell you that the key to business agility is business-led, zero-code, model-driven development. In other words, a non-technical analyst creates a graphical process model that generates an executable process application without writing code. In fact, for the past 15 years, vendors have attempted to make business process management systems (BPMS) more user-friendly and analyst-friendly through the use of model-driven design and development. These zero-code paradigms allow non-technical participants to create their own executable process models, typically using the Business Process Model & Notation (BPMN) standard.
Beyond simple, non-integrated processes, however, the reality is that most BPMS projects involve technical developers as well as non-technical analysts. Unfortunately, the proprietary model-driven environments that provide a simple interface to analysts can provide barriers to developer efficiency and code transparency. This paper explores the myth of zero-code BPM in complex projects, and how proprietary design and development tools can hinder — rather than help — skilled enterprise developers. It considers how using standard development tools and coding languages in conjunction with a BPMS can provide a bridge between business and IT without forcing either to use tools that are inappropriate for their needs: business-led functional design paired with efficient development in corporate-standard application development environments”
Comment
  1. Ian Gotts
  2. 1 year ago
  3. #4101
Does the world REALLY need another BPMS? I would use your valuable time and software skills to solve a new problem that business users have
Does the world really need Ian Gotts? :-) Ask your parents why they have produced you. Now don't tell me that's a totally different thing. And uh, what use do you have anyway?
With no code capability the model becomes the executable application not just the executable documentation.....
Christ David, you got me. Witty witty. I'll remove "the" as I'm not a bad person.
LOLOLOL. [choke][cough][hack] I'm dyin' over here. LOL.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I concur with everyone above.

Removal of technical expertise usually leads to even more ossification, because the key first step to agility is getting the ability to make one's business architecture (processes, rules, data) explicit and transparent. And cool-headed technical expertise is needed to nail this.
CEO, Co-founder, Profluo
Comment
That's just crazy talk. ;)
Agree with Bogdan . . . . the first and most important step is to get a solid framework in place to host run-time BPM process fragment templates.

Organizations do indeed need technical expertise - digital plumbers need not apply.

Another point is no amount of technical expertise can be a proper substitute for understanding what the scope of an initiative is.

There is nothing worse than an elegant solution to the wrong problem.
Or, as the great Ansel Adams used to say: "there is nothing worse than a sharp picture of a fuzzy concept".
Which actually works the other way around - many buy shiny expensive IT tools to solve an unclear problem, only to end up in a bigger mess.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Ample evidence across my customer base indicates that whereas ordinary users can map out their processes, put in place manual-select branching decision boxes, design simple data collection forms, set task routings, compile, then test-run their processes . . .

Getting these users motivated to carry out these tasks is a major hurdle. (not our job, too busy, don't want top management nit-picking our processes).

Reality is, getting to this level can greatly reduce corporate BI time or outside consultant time, but, by itself, it is about as effective as jumping halfway across a chasm.

Ninety-nine pct of such users cannot build forms that "score" forms (i.e. do 5 of A, then 3 of B OR all of C, then D) and cannot replace manual-select branching decision boxes with auto-exec branching decision boxes.

And, even if these users have an internal analyst who can do the above, what good is it to have a BPM run-time environment that cannot take in data from local and remote 3rd party systems?

Bottom line, there typically is a need to get assistance from BI / outside consultants and get IT involved.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The question of whether BPM technology "still" requires technical expertise in order to be used effectively can be answered at a micro level or a macro level. I will engage with the question at the macro level. Specifically, let's compare BPM software technology (again) to accounting.

BPM practitioners and champions can learn something from accounting concerning how technologies are used and governed:

Accounting is a business technology that requires lots of technical expertise. Accounting directly concerns business semantics. Accounting is ubiquitous. All business managers know something about accounting. Bookkeepers do day-to-day accounting work. In-house accountants and financial analysts perform more complex accounting-related work, including changing policies and procedures. Outside accountants are hired periodically for specialized tasks. And all this is performed on top of accounting software technology. This is the rich social and technical ecosystem of accounting and finance, evolved over a very long time. There is a division of labour according to expertise and type of work.

I predict that the use of BPM software technology will evolve to a socio-technical model similar to that of accounting. (Obviously the end-point model will not completely match accounting because accounting is more regulated, and for other reasons.) The evolution of the use of BPM software technology to this predicted state depends on several factors: (1) how fast BPM technology improves, especially re: the roundtrip issue on one hand and (2) the professionalization of business analysis on the other. And (3) a key roadblock to such evolution is the role of IT and the difficulty (both technical and concerning governance) of freeing process semantics from the straight-jacket of IT, per the Volker Stiehl recipe.

It is possible that BPM software technology could be stuck in a permanent sub-optimal adoption state. BPM technology is revolutionary and revolutions are never universally welcomed. Let's hope that the economic payoffs from BPM usage are sufficient leverage. And that BPM technology vendors can really sell the breakthrough that is BPM technology.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Fortunately or unfortunately, the full use of BPM potentials (especially, with a commercial BPM-suite tool) requires complete transformation of your legacy IT department.

If such a transformation has not been done then a few highly-paid gurus will agilely implement a few of your processes in the selected BPM-suite tool and nobody else can change/improve/repeat those implementations (no agility any more).

If such a transformation has been done then you are properly equipped for your digital transformation.

Thanks,
AS
Comment

Sure.

Good example of how to move from agile to "not agile".

Many IT departments have elaborate protocols for requiring that new executables be first installed on a test server.

Not unreasonable.

Vendors are typically not allowed to make changes to MS SQL data tables on test servers or on production servers for fear of creating "problems".

However, after weeks of testing, five minutes after porting a new app to the production servers, users log in and make changes to process templates that impact processing.

"Who's on first?" becomes the question.
RE "Vendors are typically not allowed to make changes" - Exactly, we understood with one of modern BPM-suite tools deployed as PaaS that the customer is not allowed adding some "custom" code to this tool (which is a normal development practice) because of the PaaS deployment! This is more dangerous that "not agile".....
@Alexander - I had to look up PaaS

"Platform as a service (PaaS) or application platform as a service (aPaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app."

Clearly, the vendor in question is putting out marketing bafflegab because the system does not qualify for 2 out of 3 criteria (i.e. the customer cannot develop, nor can they manage.

I guess the vendor is not pitching to healthcare and some other industry areas where customer "customization" is important.

The product(s) fail, for sure, on "agile".
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
I think the individual quoted in the article is a dummkopf and I would not want that consultancy on my door step.

Off all the hyperbolic panaceas that semi-regularly get dredged back up, this one - IT isn't necessary, whether it's no/low code, citizen designer or whatever - is the most offensive because it completely ignores (doesn't even acknowledge?) or account for complexity, much less scale. When was the last time you saw:

1. A user designed process app with much complexity, much less scale? At the end of the day, on any BPMS or any platform, there's still a database somewhere and that, coupled with the idiosyncrasies of a given platform (and they ALL have them) makes for a poorly performing, rigid, inflexible app. Worse, a bad app that goes into production and nukes all the other apps on the shared infra. BTDT.
2. A user designed process app that was easily modified, extended, much less 'adaptive?' Most business users know their little piece of the pie very well and that knowledge does have value, but the vast majority of business users (including management) do NOT know process design and are piss-poor at decomposing the big picture, much less assembling a better one.
3. A user designed process app that doesn't try to hang every imaginable piece of metadata they could ever want or need on the work object under the hood (even though they don't know that's what they're doing)? That's object design and they suck at it, much less understand it.

Just my tuppence, but all that being said, if what the article purports were true a lot of us would be out of jobs shortly, wouldn't we? But we're not gonna be. Whether they know it or not, everybody does process even if they don't explicitly acknowledge or address it, and some do it better than others.
Comment
Do not worry... the world will always need folks who can walk and chew gum.
  1. John Morris
  2. 1 year ago
  3. #4119
+1 processes have real inescapable content for complexity, scaleability and more . . . and the image of "hyperbolic panaceas that semi-regularly get dredged back up" is frightening, we could call it a "BPM Zombie idea".
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
With no code platforms as indicated coders not required other than if complex manipulation of data eg algorithms. The skills required would include understanding database structures and generally analyst skills in engaging with users which will dominate skill set. For non technical people the technical aspects minimal and couple of days training will see first build ready for user feed back. As ever secure deployment requires the technical infrastructure support.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
BPM itself doesn't need technical expertise, but when you like to support it with tooly things (you all know BPM is a lot more than that) that often integrate all kind of data sources, it is definitely needed.

Not that I like it... http://procesje.blogspot.nl/2016/09/i-have-to-confess-i-really-hate.html

Btw, what is "being technical"? Some call a BPMN picture technical....
Sharing my adventures in Process World via Procesje.nl
Comment
I call it a 'BPMN model.' :D
Developing a bpmn model requires technical expertise i would say, what do you mean "BPM itself doesn't need technical expertise"? And eh, tinkering on a 50cc motorcycle or welding on your car or for my part painting your fence is not per definition working on a higher level than working with a screen in front of you.
  1. Emiel Kelly
  2. 1 year ago
  3. #4106
@Stefan: but to me it's on a more satisfying level ;-)
  1. Emiel Kelly
  2. 1 year ago
  3. #4107
And "BPM itself doesn't need technical expertise". Because it's "managing" (what's in a name) . When you'd like to support it with automation and other technical stuff, to do it better/easier/cheaper you probably need some expertise to build it.

  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
I would divide the BPM adoption in 2 phases:


  • The first phase does NOT necessarily require to be implemented by someone with tech skills. In my experience, it is better if this convincing phase is performed by someone out of the IT Department. This is needed to get the support from the manager, and of course from the IT Department of the need of a BPM solution.

  • The second phase, that only comes if the first was successful, will probably need tech skills, to integrate the business process with your legacy systems using Web Services, Zapier, etc; to refine the UI; to implement complex business rules, and so on. This second phase ends with a fully working BPM system, so I needs tech skills.


The ideal scenario is when you have a tool easy enough to configure a simple process for the first phase, but also flexible and powerful to support the second phase. The magic resides in this balance.
CEO at Flokzu Cloud BPM Suite
Comment
  1. Ian Gotts
  2. 1 year ago
  3. #4102
well said
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
There are great viewpoints expressed by the contributors above. In general terms, it's quite important of course, to not underestimate or even to ignore the role of IT, including programmers, in any BPM related initiative. Having that said however, I do think that there's an important but gradual shift of the role of programmers and system - as well as infrastructure architects in such projects. Low code features in many of the modern BPM suites did have allowed that non-programmers can go further than ever before to actually create a working process solution that exceeds a mere flowchart. That naturally requires a very specific set of technical knowledge and domain expertise within the realm of BPM. From what we could observe so far, it does seem be intuitive for business people to obtain BPM specific know-how in order to produce working, low-code based process solutions.
PaaS, SaaS or even process architecture as a service (on premises and cloud based) are starting to represent viable options for businesses to host their process solutions with, which in turn lessens the “individual” burden and workload to ensure scalability and performance. That, of course, does not eliminate the need for technical specialists either but it shifts their role away from being an absolute requirement for each company wanting to implement BPM.
NSI Soluciones - ABPMP PTY
Comment
  1. John Morris
  2. 1 year ago
  3. #4120
+1 BPM-specific [higher-level or business semantic-related] technical knowledge plus domain expertise.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
This question slants one towards a binary answer. I think of BPM as a discipline and a set technologies that leads organizations to create a collaboration around tools & techniques that leverage business and technical skills in a shared environment. A shared environment that promotes experimentation and incremental agility that leverages the combined strengths of all from business folks through deep technology folks and everyone in between.
References
  1. http://jimsinur.blogspot.com/2015/06/bpm-at-cross-roads-digital-vs-rapid.html
  2. http://jimsinur.blogspot.com/2016/05/to-model-or-not-to-model-that-is.html
  3. http://jimsinur.blogspot.com/2016/02/setting-digital-principles.html
  4. http://jimsinur.blogspot.com/2015/12/enabling-incremental-business-with.html
  5. http://jimsinur.blogspot.com/2015/11/innovation-through-experimentation.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
LOL . . . I think I see why @Patrick got riled up over the “Business process management more essential than ever” article.

The main quote “A lack of process governance managed centrally through BPM disciplines and technology could have significant consequences for businesses” probably is the source of frustration.

Not clear when the quote was issued?- it would have been a valid projection back in the 1950’s.

How so?

Process governance is important for highly automated processes such as cement, steel, and pulp & paper manufacturing.

I don’t think Forrester Research had in mind industrial processes in their 2015 Global Business survey nor is it likely that Mr. Munthrie was commenting on processes that need to be designed by chemical, mechanical and electrical engineers.

The problem in the quote is with the term “governance”.

In b2b, we don’t need/don’t want process governance (i.e. preventing extreme unwanted deviation away from a process). Facts are we want the opposite (i.e. to be able to deviate from rigid processes).

What we need for b2b from processes is orchestration and it is Cases (hosting process templates) that benefit from governance.

Governance at the Case level prevents extreme unwanted deviation away from a) corporate policy/procedure and from b) Case objectives.

It’s possible that 35% of Forrester Research (b2) participants are thinking about replacing BPM with, say, ACM/BPM. It’s possible that less than one-third are considering implementing BPM, again, because they may be moving to ACM/BPM.

Nothing wrong with Mr. Munthrie’s quotes up to the one that reads “It (lack of process governance) results in people across an organization doing the same task in different ways . . .”

No, the presence/absence of process governance has nothing to do with people performing the same task in different ways (i.e. a set of “how – to” instructions is not “governance” in the normal use of the term).

The quote “BPM no longer requires implementation by a person with technical expertise” does not fly for the reasons I and others here at this forum have detailed higher up in this list of responses.
Comment
My work here is done. What's next?
  1. John Morris
  2. 1 year ago
  3. #4121
+1 @Patrick "my work is done".
As for @Karl and not wanting "process governance" (btw the original article is off-line as I write this) may I suggest you are defining governance rather narrowly? If we consider a business process as "an intangible business asset", then governance of that asset reasonably includes ownership (i.e. responsibility) and decision-rights.
@John.. Agree I am defining it narrowly. The dramatization is purposeful.

Reason is to get away from the notion that processes are, in the main, end-to-end.

When you move from processes to process fragments, you no longer have "objectives" plan side (unless you say that reaching the end node of a process template counts as an objective).

So, objectives move from plan-side to run-time side and need to be parked at the case level along with most of "governance". we keep the governance at process steps that picks up on such things as "end time" earlier than " start time, but we can no longer rely on any process fragment step having what it needs to allow engagement of processing.

Two remedies: a) in line key process control points that check case level data to decide if OK to proceed and b) pre-conditions at the start of each process fragment to decide if OK to engage processing.

Since users can "jump" into any step along a process fragment, it follows that, in theory, you need pre-conditions at each step, rules at steps and, just in case the rules at steps are deficient, you might as well say you need post-condtitions on exit from each step.

This makes for a lot of checking and is probably not practical for other than industrial process control where an entire cement plan can go off-line if one key process parameter is allowed to go out of bounds.

There are lots of older concepts that have to go out the window - if we allow users to deviate from process fragments (skipping steps, re-visiting steps already committed, inserting ad hoc steps, recording data at steps not yet current, jumping forward, exiting from a process fragment template), you can no longer rely on upstream logic connections as you arrive at a task to contribute governance.

For these reasons we need Bernard Meyer's "design by contract" pre-processing and post-processing and we also need "smart-option menus" to hide options that make no sense for users in a particular set of circumstances and a particular point in time.

I agree governance is needed everywhere but there is great difficulty trying to get everyone understanding the fine distinction between orchestration/governance.

I like to think of governance as being more strategic than operational, but we all know it permeates strategy and operations.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
  • Page :
  • 1


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