BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Wednesday, 30 May 2018
  5.  Subscribe via email
If there were a list of worst practices for BPM implementations, what do you think should be on it?
Max Young
Blog Writer
Accepted Answer Pending Moderation
1. Processless BPM
2. Solutions without a to-be
3. “Black Box” bpm
4. Non-standard compliment BPM
5. Ignoring the current microserivces landscape, and it’s implications for non-monolithic solutions.
References
  1. Http://www.capbpm.com
Comment
@Max.. . . What is "“Black Box” bpm"?
  1. Max Young
  2. 6 months ago
  3. #5389
I think of a blackbox BPM (engine) as
1. A system that offers limited access to application\process engine,
2. a BPM engines that uses uses non-standard, non-open mechanisms for integrations, UI, and KPI gathering.
  1. John Morris
  2. 6 months ago
  3. #5393
I think of a "black box" as a work process that is not understood by management. In other words, management does not "own" the contents of a process. That might be OK -- indeed a cost saving -- for non-core processes. However, for core processes of your business, you must take responsibility for what's "in the black box". You must continually improve quality and cost. There are lots of examples -- notoriously the US car industry in the 60's -- where executives took a hands-off "Nike" attitude -- "Just Do It" -- or maybe a "Captain Picard" approach -- "Make It So No. 1". This is fine when things are stable. But in a day of evolving processes, a black box culture predicts failure to adapt.
Our automobiles are, for most of us, "black boxes". We used to be able to fix them, now they have to go to the dealership. There are AI devices seemingly coming onto the market that you will plug in and get an immediate diagnosis. This will avoid repairs that are not needed and perhaps highlight problems the dealership might otherwise skip over.

All unimportant, as we are poised to go driverless (hopefully not with "AI' driven cars). My recommendation all along has been to model a train, with proximity detection loose coupling. You key in the destination, you get on the highway, everyone other than ambulances/police goes at the same speed, you get offloaded automatically and then you drive locally. Who needs to pass, weave in and out? And, why the rush, you can work in the car if you like?

Folks will be able to text full time, or play internet games, enjoy the scenery, or be stoned out of their minds (until they get to their destination) - all of this will not result in increased accidents.

And, to finish off this rant, why not electric, one color, one model in small, medium, large?

Once the US bans all luxury imports (CNN today, no need to look it up, it's too silly) and Europe bans all exports to their area, the auto industry will have to put on their thinking caps, they might as well get the notion that most folks no longer need to "own" cars.
  1. John Morris
  2. 6 months ago
  3. #5400
@Walter, a whole can of worms. Legal liability, provenance, transparency, IP, privacy all related to black box processes and black box decisions.
@John, We might need to do a few rounds on this.

We built back in 1995 a bubble sort that took symptoms/signs and generated a prioritized list of candidate poisons. The product was called RapidTox and it failed because the machinery at the time took too long to process the data. Most of the patients would have died.

Anyway, part of the marketing was to go around the world visiting Poison Control Centers. We gave them a copy of Dr. Robert Driesbach's "Handbook of Poisoning", asked them to go to any page, give us the name of two or three symptoms and we then we were able to tell them what page they were on. They were impressed.

The algorithm, for them, was a pure black box, they had no clue how it worked, it just worked.

I am quite happy today to ping an object and if it
a) lets me message it
b) tells me if my request is OK and then
c) gives back a response,

I have sniffers that check the validity of the response. If my request is within the cluster of previous requests and my sniffer passes the return, I have reasonable confidence that I am not beyond the boundary conditions of that object.

What else do I need?

I have a nice story re "Handbook of Poisoning". I carried it around everywhere for years.
I once got on a plane, in no mood to chat. The lady next to me said "That is a rather unusual book to be reading"
My response - " I am having trouble with my mother-in-law".
The lady flattened herself against the window and did not engage me in any further conversation for the duration of the flight.
  1. John Morris
  2. 6 months ago
  3. #5406
Marvelous stories @Walter. As for "sniffers" am I correct to interpret this as a statistics-driven feedback loop? What might get labeled now as going in the direction of machine learning?

Concerning the idea of "black box" though, I think you are suggesting that sometimes technical functionality should be a black box -- and sometimes not. Clearly there's no need for constant second guessing basic functions, where compute power is performing obvious but laborious data processing. A cost that should not be incurred. However, when we rely on algorithms and data science for major policy decisions, transparency is required. For many reasons. This second case is the case that I advocate should not be a black box for managers.
@John. "Sniffers" (outbound side of an app) check out black box processing needs and abort if all is not in place so as to avoid processing fails that cost time/money/bad outcomes.

As for the inbound side of an app, they similarly check out returns to make sure the results of processing are within reasonable expectations and abort so as to again avoid time/cost/bad outcomes i.e. what is the wait time for getting onto the freeway ? (usually 0 - 10 min) but the response is 1000 minutes.

Most of this comes from industrial process control but in software I suspect the origin is work done by Dr Bertrand Meyer (Eiffel) on pre/post conditions (i.e. design by contract).
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Overselling the benefits of BPM

1. mainstreaming BPM as the tool for workflow/workload management when there are several equally-important tools needed (i.e. RALB, FOMM).

Remedy: Getting organizations to understand that BPM is the core provider of background orchestration at run-time Case platforms in conjunction with other methods like RALB (Resource Allocation, Leveling and Balancing) and FOMM (Figure of Merit Matrices) is the route to operational efficiency and effectiveness.

BPM+RALB+FOMM -> operational efficiency and effectiveness

2. proposing BPM as a tool for strategic planning - strategic planning is not about performing tasks in a certain sequence- it is more of a 'connect-the-dots" exercise

RBV (Resource Based View) is a top runner for strategic planning (i.e. building, sustaining and improving competitive advantage).

See "The Theory of the Growth of the Firm" [Edith Penrose, 1995]

http://www.oxfordscholarship.com/view/10.1093/0198289774.001.0001/acprof-9780198289777
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Brian Reale
Blog Writer
Accepted Answer Pending Moderation
1) Not defining KPIs and Outcomes first
2) Not getting stakeholder buy in both "above" and "below" the implementation level
3) Implementing outdated, over priced solutions from a "preferred" vendor that cannot show previous success that relates to your particular situation
4) Not following the 5 Steps to BPM SuccessSIR methodology
References
  1. https://goo.gl/m4McWm
Comment
@Brian - Very nice writeup on SIR!
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Just some examples:

1) Sell technology instead of business transformation,
2) Implementation of processes by department, maintaining the islands and soon killing the concept of E2E process,
3) Automate current processes without improvements,
4) Implementation of technological transformations, for example ESB / SOA, without any support of business processes analysis
5) ....
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Only one is enough - "manage business processes instead of managing business by processes" because this is the root of all BPM evil.

Thanks,
AS
Comment
@Alexander... Sure, because if your exclusive focus is on "continuous" tweaking process maps as opposed to managing cases using BPM process templates, you never get around to using your BPM processes.

Back in 2011, looks like I had the impression that many stakeholders mapped out processes, posted the flowgraph diagrams on the wall and expected workers to manage their tasks by staring at the paper process maps.

I think that time is past but your comment reinforces the importance of the run-time use/benefits of BPM.

See "When a picture is not worth 1,000 words"
https://wp.me/pzzpB-9X.

  1. John Morris
  2. 6 months ago
  3. #5394
+1 Dr. Alexander for "the root of all BPM evil". BPM.com is a forum for exploring every ramification of process technology and practice. But this comment is pioneering in extending the domain to theology. Well done! :)
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The list could be long... so I'll focus on the "today" with 3 Do Not's:

  • Don't reinvent the wheel. There are thousands very useful web apps that users love. Integrate them into your processes instead of reinventing them. Use Zapier, Web Services, etc, and make them part of the process.
  • Don't oversell BPM including trending technologies if you haven't the experience/tech, only because they are sexy (RPA, AI, microservices, etc)
  • Don't be too much wide. Stay focused on the process and the business value it is designed for. We see amazing project from Amazon, Google, etc, and sometimes we forget about our budget restrictions. Avoid being tempted with cool extensions and side projects that could make you lost your focus on the core of the BPM discipline: modeling the processes, automating, measuring and improving. That's the success criteria.


Best regards,
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
I agree the most what has been said. Though one vital and very common bad practice is missing and that is not starting to design of the process by asking: "Who is the customer?" and "What is the customer's process?".... Here I don't mean only outside customers who pay for and use the services (outputs) but also inside users of the services which internal processes produce and deliver. Without customer there is no need for the process.

I would also add that most BPM related business transformations die because of not defining process KPIs…. you lead what you measure. In the long run the KPIs should support understanding of the value creation.

br. Kai
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Great questions and responses on the "Don'ts" for BPM as a methodology! From my perspective, I would pointing out the following aspects:

1. Skipping on a comprehensive methodology when it comes to implementing new or enhancing existing processes. Sadly, still to this date do we witness users trying to automate, before optimizing the process or even before defining in detail the process as-is. In short, avoiding the very fundamental steps, while trying to obtain the lowest possible budget by excluding the theoretical portions of a BPM project (design documentations, customer journey etc.).

2. Overburdening a BPMS with aspects that it wasn't designed to accomplish. Here, we have the classical culprits - for example trying to force an ECM, CRM or ERP into a Business Process Platform, which usually results in over-time and over-budget projects that are unnecessarily heavy on the custom-programming end of things.

3. In that category falls also BPMS <> BRE. I put that as an extra point, since it occurs in almost all automation initiatives that one faces. While there are some few, very big BPM players out there that combine a TRUE BRE (not to be mistaken with the simple routing capabilities all BPMS nowadays sport), most providers lack an independent, embedded Rules Engine. That, in turn, requires the end user to either program their process rules by code or to integrate to an external solution.

4. Failing to structure the BPM implementations in to short and iterative "sprints" but rather producing 20+ process step "monsters" that can take a year or more to implement.

5. Failing to execute a first BPM project, end-to-end, as a stand-alone and linear effort. Failing to do that prohibits the user from creating a validated baseline for future implementations (a BPM SOA, basically).

6. The all-time classic: Failing to NOT automate the exception and not focusing on the rule (ignoring the Pareto principle).

7. Lastly, failing to include all the end users during the process as-is and to-be definitions.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Worst practices where BPM implementations are concerned? What about ignoring "externalities"? BPM process implementation externalities include things like UX and bad customer journeys, and bad process designs that under-fit reality etc.

These particular externality anti-patterns are all in some sense cost-related. The cost of better UX design. The cost to users and customers of bad work journey design. The faux-cost savings of truncated process model designs. And cost-related externalities are in turn a failure of both IT and business management to fully own responsibility for business processes.

To fully own a process is to understand what is required to build and maintain process automation artefacts that work in a real, uncertain, messy world.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Just a few thoughts based upon our experiences with early adopters.

1 Failing to do research on the supporting enterprise level software to deliver the working custom applications and ensuring support for the inevitable future changes

2 Failing to engage real users (not just the managers!) in build of their processes.

3 Start small to prove delivery works which will also give user confidence that their input and views really do matter

4 Failure to think horizontally as opposed to vertical silo which cross traditional boundaries

5 Wasting too much time on detailed specifications as new approaches allow quick build and change with user feed back on early iterations

6 Avoid any lock-in and ensure access to the build environment in recognition that good process are assets and they should be owned by the buyer

7 Failure to recognise BPM driven projects are business driven not IT who should be ready with infrastructure support for secure delivery
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Perhaps, one of the worst and most deeply rooted practices in BPM is doing it without established methodology.

On most primitive level, BPM often begins as a set of diagrams drawn in a standard office package. When there accumulates significant amount of diagrams and process descriptions, the magic word BPM comes in mind and a company begins thinking on the best BPM tool to choose for its process management.

But any most advanced tool, however rich in options it is, will never bring ready methodology, which de facto exists in an organization. As a result, a company in most cases sacrifices its already existing, although not well formalized, methodology for the sake of external, foreign and artificial methodologies offered by various tools.

Ironically, with nearly every BPM tool lion's share of effort goes to tedious and often futile attempts of embedding existing business practices into ready modeling framework. Instead, implementation should pursue exactly opposite goal of easily adopting tool's methodology and facilities to the existing business practice. Alas, not many tools have a goal of adopting to business.

BPM should always start with discovery of corporate methodology, not ending with it. This may save from many mistakes and failures in digital transformation of an organization.
Comment
  1. John Morris
  2. 6 months ago
  3. #5404
Deep insight @Boris. 1. BPM methodology "exists". 2. You already have your own process methodology de facto for your domain and organization, 3. It can be formalized. 4. Tools should support your way of doing business. 5. Doing it the other way around (adapting your way of doing business to the tool) is likely to be extremely costly. I will add "to the point of failure" (see history).
  1. John Morris
  2. 6 months ago
  3. #5405
What is the cost of not building from one's own native understanding of business processes? I suspect that the costs are higher than we know. For existing business models, the low-hanging fruit of BPR ("re-engngeering") has been harvested. What's left are margins painstakingly built on tacit and/or specialized and unique approaches to a given business. How easy is it for careless or inattentive management, professional managers as opposed to domain specialists, to lose this edge? Cookie-cutter management is not friendly to differentiation. My view is that domain-expert business analysts are the cadres that can lead the way outlined by Dr. Zinchenko. As long as there is real support from the executive suite.
@Jonh Morris, thank you. Ironically, every organization already has a methodology. Just, many organizations do not suspect on it. In our consulting practice we run an automated discovery of existing methodologies from process artifacts. It should not be confused with process mining. Rather, it might be called "method mining". Technically, it is remarkably fast and easy to do. Alas, not many tools or consultants take care to explore this simple but essential step towards process transformation.
  1. David Chassels
  2. 6 months ago
  3. #5409
@Boris I think you are hitting a key issue about being "simple". Fact is business is actually simple once you understand the core business logic. By sticking to this simple principle process transformation in business language opens that door aided by the BPM thinking. Sadly the way "IT" has created silo and segmented solutions has made such simplicity "difficult" as you articulate trying to embed illogically such existing processes. Thinking green field with BPM but recognising the use of the brown field legacy is a sound way forward.
@John As we know BPR predates BPM indeed process mapping goes way back...I was doing as auditor in the 70s and it was both fun and very effective. Given that business logic is simple and universal across all organisations the core domain knowledge of the business analysts becomes the BPM discipline but having that domain knowledge can bring in new ideas all as you rightly point out aided by executive suite support. This support readily gained if they understand in their language exactly just "how" all outcomes could be achieved?
@Boris. Indeed, "every organization has a methodology" (i.e. a set of methods). It's how they do their work.

Unfortunately, as with BPM tools, methods can be picked without concern as to their appropriateness to maximize competitive advantage and without concern as to how compatible a proposed new method is with existing methods.

In the area of BPM, we try to onboard clients to the notion of run-time Case management platforms that

1. accommodate background BPM.
2. support resource allocation, leveling and balancing across Cases as Case priorities change (i.e. in law enforcement, - new evidence, new witnesses, etc).
3. provide some non-subjective means of measuring and assessing progress toward reaching Case objectives (i.e. continue investigating, apply for a search warrant, arrest, send to trial, tag as cold Case).
@David, thank you. Definitely, IT, especially legacy one, creates an artificial over-complication layer above basic business logic. However, it is equally correct to say that this legacy IT is already an indispensable part of the running business. This makes a discovery of methodology so important. It allows to establish a vocabulary, on which any subsequent implementation should operate.
@Karl Walter, as you precisely pointed out, case management is one of the most adequate and flexible practices to embrace existing methodology of an organization.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
  • Page :
  • 1


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