1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 11 October 2018
  5.  Subscribe via email
From Keith Swenson: Have you experienced situations when it cost more to re-use a process than to start from scratch? How could one recognize these situations? How common are these situations?
Accepted Answer Pending Moderation
Most business processes cost more to re-use, because the overall architecture is usually neglected. Yes, there are time/budget constraints - no single customer is willing to fund your R&D into designing generic-enough patterns that could be re-used. They only care about you fixing their specific problem.

However, the real cost stays with maintaining custom processes across your architecture. Since you will have essentially built everything from scratch, you need a lot of manpower to keep the ball rolling. Combine this with a super-diverse customer tech data center landscape, custom integrations and, voila: unified testing, unified DevOps are incredibly hard (if not impossible) to do.

That is why most business process companies are still essentially consulting companies, as they need to keep selling that manpower to their customers.
And since that manpower is engaged in new projects/ change requests / maintenance, not many companies have the strategic discipline to allocate some of that manpower to refactoring their architecture.

So younger companies have a better shot at starting right - directly in the cloud, directly containerized, properly modularized. They may have a problem with engaging economically in large projects, but their overall maintenance costs will be a fraction of those of the the bigger companies.
CEO, Co-founder, Profluo
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Looking strictly from the technological point of view, and given that many companies are still supported in legacy systems, without an architecture that allows componentization and reuse, the idea of ​​starting from scratch instead of reusing usually has more followers.
However, we often confuse business processes with technical processes that run in applications, BPMS or others, which must be viewed at a higher level, and which are usually executed from start to finish supported by various application systems.
In this sense, it seems advisable in any situation to always analyze the current processes in an end-2-end vision, in order to clarify exactly where the investments of improvements from the point of view of the business should be made, which will allow to select with greater rigor the technologies to be used in the future, and will also allow measuring the benefits to the business, comparing the current performance situation with the performance after the solution is implemented.
Otherwise, there is a serious risk of spending money on the dark, and then most of the times the results will go less then what is expected or desired.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Yes, I have experienced a situation (most situations) where it costs more to re-use a process than build it from scratch.

Taking the top 40 police departments as an example, each has around 200 protocols covering "a" to "z", with little in common across protocols/PDs at the step-by-step level.

It is much faster/easier/less expensive to have a facilitator build the customer's "as-is" process in real time by simply asking them " . . . and then what do you do next?".

In healthcare, there are industry standards but, again, the individual healthcare facilities have over time evolved their own written policy/procedure. So, it seems best to interview.

One big time saver when mapping is to get, in advance, images of all forms the customer has and as the mapping is being done, attach one or more images to the process steps as these are being deposited on the mapping canvas and linked.

When you piano play a mapped process, it is very helpful to stakeholders to be able to see their forms posting - the setup for this is a simple form with one picture field and one comments area so that the facilitator can record such comments as "wrong form at this step, missing fields, fields not needed, layout needs to be improved, etc".

As more and more customers want to do their data entry at smartphones, most forms typically need to be re-done so they are less "busy" - OK to have a narrow vertical scrolling form but not one where the user has to both scroll left-right and up/down.

And, forget about expecting someone in the field to type in, verbatim, a witness account of an accident using their thumbs unless you plan to hire a child or teenager to do the data entry.
  1. http://www.kwkeirstead.wordpress.com

Our metrics are 10-20 steps per hour - this includes mapping, rollout, piano play, minor fixes, rollout, piano play. Clearly, no rule sets, but OK to document in narrative terms what is supposed to happen at branching decision boxes.

Not a good idea to leave any of the steps in this cycle to be completed another day - users want/expect immediate gratification; not a good idea to do more than a one-hour session with any one group because of attention span limitations.

If you are on site, do one hour, then bring another group in and do one hour with the new group.

We rarely go on site these days, GoToMeeting works well because you can have stakeholders logging in from different offices/cities.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Reusing a process? What does that mean? I can understand reusing a piece of software,document templates, but reusing a process?

Could it mean something like adopting the same way of working in a different situation?
Sharing my adventures in Process World via Procesje.nl
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Re-using a process you say? It's rather like how object-oriented programming was sold to business people a generation ago (see a US BusinessWeek cover with a baby and the headline "Software Made Simple", circa September 1991).

Apparently the world is messier than we know, and what we think we know is less we need to know ( see "tacit knowledge" ), and also our skills at modelling and abstraction are limited, and re-purposing scantily documented functions is hard. And then of course costs -- always costs. Specifically the costs and ownership and governance of re-usable frameworks (of objects or processes or whatever) is not really figured out yet. @Bogdan says it well: there's an argument for starting from scratch.
  • Page :
  • 1

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