1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 15 December 2016
  5.  Subscribe via email
Do you think it's a mistake to think anyone can design their own process?
Accepted Answer Pending Moderation
Gusteau: What do I always say? Anyone can cook!
Remy: Well, yeah, anyone *can*, that doesn't mean that anyone *should*.
CEO, Co-founder, Profluo
  1. Emiel Kelly
  2. 3 years ago
  3. #2998
Anyone can cook. Not everyone can make tasty and healthy food.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
No, people should design, own and manage their own BPM processes . . . . to an extent.

Some processes have complex decision branching. In some cases the branching can be automated using rules.

Building rule sets can be about as complex as building a complicated spreadsheet, so, if a functional unit does not have resources capable of building such rule sets, they will need help from a BA unit or IT unit.

A second area where assistance is likely to be required is with interoperability where parsers/formatters are needed to enable seamless data exchange.

Clearly, the above applies to processes that are going to be mapped in some process mapping environment, then complied and rolled out to a run-time (RT) environment.

The templates need to be able to be referenced in the RT environment to generate instances where insurance claims, orders, patient data is captured at steps and/or imported and flows along pathways, receiving orchestration or guidance and governance from BPM.

For industrial processes, process control engineers are typically needed to map out processes and specify how equipment is to be interfaced.
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
I know I sound annoying, but statements like this always raises questions to me like:

- What is "the design" of a process.
- Is implementing not important?
- Who is "Anyone"? Also someone not involved in a process? Or the process owner? Or all the roles of a process together?

Assuming a process owner, I think he/she should definitely be responsible for the design of the process. By answering questions like

- What is the problem this process should solve?
- What is the desired process result?
-What are the desired process goals?
- What are important milestones in the process>

And then the design and implementation of the process might be done by different people. Preferably (in my opinion) by people who are really involved in the process, but that might not be possible all the time. Especially when specific technical stuff things need to be implemented. Like camera's that check trash bins ;-)

All is, of course, also depending on the size of the organization. In large corporates the design and implementation is often separated from the shop floor.

But, me and my girlfriend, we are the only 2 working in our child day care. We are completely responsible for the design and execution of the core process "taking care of kids" . Of course we are also responsible for the more boring stuff like registering the hours and sending the bills. We choose to use some cloudy tools for that. Those tools were built with a certain process in mind. We could live with that design. In that case someone else designed it, but we feel still responsible for execution.
Sharing my adventures in Process World via Procesje.nl
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I think it is an ambiguous question by Peter, thus it does not limit (Thanks to Emiel) our answers - thanks Peter!

IF anyone == MANAGER & own_process == a_process_under_his_her_responsibility THEN YES (please design a process template).

IF anyone == WORKER & own_process == his_her_process_instance_or_case THEN MAYBE (if the corporate culture allows this)

IF anyone \= MANAGER & anyone \= WORKER & anyone.age >= 18 & own_process == his_her_personal_activities THEN YES (do not forget to facebook it, please!)

A next group of questions should be “are you capable to design your own process”? Remember that the concept “capable” covers two separate concepts: “able” to do something and "guarantee" the extended outcome.

IF anyone.able == NO then contact BPM.COM

IF anyone.able == YES & anyone.gurantee == YES THEN DIY

IF anyone.able == YES & anyone.gurantee == NO THEN contact BPM.COM

  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
I suppose situation here is exactly as in any other business area. Business typically uses standard tools and solutions but configures and adapts them to own specific. Same situation is with business processes.

As a rule, business does not start from a ground but reuses existing patterns already established for a specific field or industry. In this case we have an implicit use of process templates already utilized by other players.

Business software often ships with ready process templates for various types of business. For instance SAP Solution Manager offers a rich collection of business blueprints prepared for various industries. These simplify and accelerate implementation.

In many situations designing entirely own processes is simply not allowed. Many areas of business have strict government regulations and compliance requirements. A process will not be approved, unless it follows many formal restrictions in this case.

In general, question about design own business processes is roughly equal to the question of design own business. As a rule, it is very risky to devise something entirely new from the ground. Normal practice is an adaptation of already existing patterns, which proved to be positive and beneficial.

It is equally relevant both for amateurs, who can hardly design own processes due to limited awareness, and for process professionals who, by virtue of experience and education, use own patterns accumulated in their previous career.

Having well established base of documented and implemented processes, anyone can design and discuss its further improvements. Moreover, it is essential that ordinary workers of organization were involved into this process of process improvement, apart from business architects. This guarantees higher involvement and acceptance of process management among all workers and better effect on implementations.
@Boris... Good point re "Many areas of business have strict government regulations and compliance requirements. "

What works well is to let units design (typically map existing) processes but a gatekeeper/process librarian is the only person who can roll out a processes, thus taking care of compliance.

@Karl, Thank you for comment. Question is about design. So, I think design should be maximally involving for all workers. Of course, these original designs should be then reviewed by experts for relevance and compliance. Centralized roll out follows after.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Yes and No if we are thinking about business users redesigning / capturing the way they work at a high level (Quote to Cash) and then drilling down to an executable level.
- Mistake 1 - they use a BPMN or single level diagramming tool rather than BPA tool
- Mistake 2 - they draw huge flow charts or swimlane diagrams
- Mistake 3 - they don't have enough detail in the diagrams (processes without connecting lines, lines without text)
- Mistake 4 - they don't got down to a level where they describe the execution in enough detail

They should certainly be very involved and own the processes. But them may need help to understand how to design and document the processes so that they are understandable, executable and sustainable.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
The answer isn't just a simple no.
My complete answer would be, "NO, it is not a mistake. The big problem is if he can't !"

Of course, you also have to solve other issues, as complex logic (parallelism, mutually excluding conditions), integration with other systems (WebServices, APIs), etc, that could exceed business users capabilities.

But, in my experience there's a lot of processes that can be completely designed and automated by a business user, without IT help (there are simple, SaaS, BPM Suites that allows that, see reference below).

This practice is extremely healthy for the organization of course, but also for the business person, who gains autonomy and recognition for his work. This credibility leverages automating more processes, becoming a traditional continuous improvement cycle for business processes. Because of this, it is so important to enable business people to design and automate their business processes :)

Best regards !
  1. http://www.flokzu.com/
CEO at Flokzu Cloud BPM Suite
  1. Emiel Kelly
  2. 3 years ago
  3. #2999
(end of advertorial)
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
It totally depends on how it's being designed. Flowcharts and BPMN? Hopelessly and needlessly complicated.

If a constrained way of building a process is presented which is simply impossible to mess up - there's no need to ask this question.
Big difference between "Flowcharts and BPMN" versus "Flowcharts" , "BPMN"

My input is that a To-Do list is a very poor substitute for the representation of a set of steps where you have decision branching (especially automated decision box branching) and sub-paths.

Anyone who contests this needs to explain how, in the absence of a flowchart, you would manage to get user "system' to execute a step when that step becomes current in a Case environment.

As for BPMN, some of the folks at this forum have a customer base that is quite happy to let consultants help them put their processes in line. The consultants are comfortable with BPMN, they like it, and, for them, it is neither 'hopelessly" nor "needlessly" complicated.

1. BPMN has 4 basic shapes and is being used by business professionals to apply it to business actions and data.
2. The international traffic sign system has 10+ shapes, countless localizations and types of symbols and is being used daily by billions of people with basic education, across an immense array of topological, geographical and meteorological conditions - all of this with an astonishingly low rate of error.
BPMN is anything but complicated, as proven every day by my basic, small, customers. They don't want to use it for modelling (they leave this to me), but they understand it after 2 minutes of explaining what the symbols mean and they want to be able to have access to the process cockpit so they can monitor - and I did not expect that. It IS worth to get out of the building.
I do agree with your second line.
  1. Amit Kothari
  2. 3 years ago
  3. #3016
"It's old and it gives me a job - so it must be right".
"It's new and it gives me a job - so it must be right"
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Such a big question. Can anyone design their own processes? And should they? Great answers above. A few of my own:

1) BUSINESS KNOWLEDGE VERSUS PROCESS TECHNOLOGY KNOWLEDGE -- It's magical thinking and disrespectful of the domain content of business process technology to imagine that naive business people can "just do it". A knowledgeable business person still has to learn accounting, or industrial engineering, etc., regardless of how well they know a given business. Same thing with BPM. And like accounting, anyone can do basic things (in BPM, add a new case or instance, or in accounting add a new vendor). Specialists are required for more complex and risky (and useful) things. And in between a spectrum.

2) IDEOLOGICAL, PRACTICAL OR CYNICAL COMMITMENT TO DEMOCRACY -- Today's question is "in the air", for sure. Because "democracy is in the air". We see a lot of explicit hype about democracy and technology. The word "empowerment" is used. Sometimes the commitment is genuine -- and sometimes it's a fig leaf for other agendas, like cost savings (not a bad thing for sure, though). Perhaps the chief challenge of process automation is acquiring and maintaining formal domain knowledge for instantiation in business processes. Building and evolving business processes is expensive and difficult. And the tacit is the elephant in the room. Democracy, or empowering actors-at-the-edge, can be very practical and worthwhile if done right. The cynical part comes in if the edge actors are not compensated for their efforts.

So, BPM software technology keeps improving, and thus there are now use cases for "user-defined processes". There could also be business cases for empowering some business side actors for BPM software technology. Risks can be identified and managed. Governance is critical.
"Empowerment" comes up a lot during discussions about plan side design/mapping, even more so when talking to prospective customers about what their run time experience is going to be like.

Resistance to "rigidity" immediately becomes an non-issue when you explain that BPM templates are present to make life easier and that users (because of governance) are free to skip steps, insert steps, re-visit already committed steps, post data to not-yet-current steps and that they can, on top of this, micro-schedule tasks that have posted to their InTrays. ("breakfast meds" being an exception in healthcare).

We explain to supervisors that they can, at the same UI, level and balance workload across Cases/knowledge workers, so all stakeholders feel "empowered".

All of this is possible, in our case, because of Dr Bertrand Meyer's "design by contract" that we borrowed from Eiffel, where you can have preconditions to user tasks along a Case timeline and "system" gatekeeper tasks that facilitate/encumber/block attempts to engage processing. See https://en.wikipedia.org/wiki/Design_by_contract

I cannot see how anyone trying to sell ACM getting far without some mechanism like Design By Contract.

Civerex's parent company, Jay-Kell Technologies, hosted seminars for Dr Meyer in Singapore and, later on in Montreal, for a number years. I can't remember how we got introduced to Eiffel and Dr Meyer.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Maybe I'm just old, but I've seen this movie 1000 times, and it always ends the same way. Everyone can have their own Access database. Everyone can have their own Excel macros. And on and on...

And what happens? At some point, some poor idiot (me, to be precise, several times over the course of my career) has to root out all that homegrown, non-compliant, functionally opaque “automation” and replace it with something that, you know, works.

People confuse personal task management with workflow management all the time. Feel free to use your Franklin planner or Google Tasks or Outlook Calendar to keep track of your life in a way that suits you. But if you expect your company to move forward, you kinda wanna make sure that everybody with an oar is pulling in the same direction.
Scott's opinions only. Logo provided for identification purposes only.

Re: 'you kinda wanna make sure that everybody with an oar is pulling in the same direction."

At "Singapore International Software Services" we had a "no verbal orders" rule.

Time sheet hours had to match hours on each staff member's work orders.

No work orders -> no match -> go_to_audit.

As I recall, our accountant was not very user-friendly - I suspect if we had thought to give her an oar, she would have used it.
Scott, agree with you - and I've written along these lines before here.
That is one of the reasons why I believe low-code is interesting, but as a tool for increasing productivity of developers and architects, and for increased and focused collaboration between them and end-users. I do not believe in companies accepting that their application landscape will be crowdsourced by their employees, with 100% freedom (or 0% IT-mandate).
Crowdsourcing is a great weapon, but you cannot wield it in any war.
I - for one - wouldn't want to live in a house that's been 3D printed by myself.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
This question is a bit tricky and the answer depends on how we understand the definition of our "own processes".
My own process from the perspective of another team could be also part of their process, however, sitting in my own silo I either can't or don't want to see other participants because life is more convenient (and also more painful) that way.
The other issue is my view angle. The shoemaker's son always goes barefoot so I'd personally prefer to ask someone else to help me design, or at least audit, my own processes. The third party perspective should help me better capture tasks performed through habits and shortcuts that could be engrained in the work I am used to doing on a daily basis.
There are different types of processes, as well as different types of tools that can support such task. The "personal workflow" approach through tools like Microsoft Flow seems like a far cousin of a business process but is it really that far? There are so many DIY tools that support database design, data modeling, UX design so why should process design be different? Process design is a skill that can be acquired. Most professional certificate programs these days include process modeling in the Business Analysis/Business Architecture curriculum.
The short answer is yes anyone should be able to design their processes although not everyone will have skills and experience required to link such work with value producing activities.
"There are so many DIY tools that support database design, data modeling, UX design so why should process design be different?"
BJ, I did give a lot of thought about this and I think the key difference is that process design, out of the 4 mentioned above, is the only discipline that needs to include a collaborative context - a business process that has only one player is something that can be a low-code personal automation hack (as I do right now with Excel macros and Tasker automation), but a business process that has more than one player (either human colleague or enterprise machine service) needs already to become architecture-aware. And this requires one-up thinking.
  1. John Morris
  2. 3 years ago
  3. #3011
Good distinction BN between *personal* automation hacks and *collaborative* automation systems. I like to compare BPM technology to accounting technology, for the purposes of learning about adoption. Your distinction (group automation complexity) is applicable to this comparison exercise. Accounting, like BPM, is very much about collaboration and the organization. (Although I do have my own personal expense tracking hacks . . .)
Bogdan, you are right - most processes usually require collaboration to fully define their scope. However, there is a number of tools on the market that make this task as easy as database modeling. I.e Bizagi modeler or Nimbus. I am sure there are other tools as well. All I was saying is that with the right level of support, process definition can be performed by users to some extent. Many users who consider themselves database experts have no idea what a 'third normal form' is but that doesn't stop them from designing databases.
IMHO demystifying activities surrounding BPM would drive more adoption of the practice. I see more value in having 10 business users creating imperfect models that describe their work than 1 specialized consultant creating one perfect model. Yes, the imperfect work will require rework but business users will get it right on their 2nd or 3rd attempt. Democracy gets to it's state of perfection through repeated exercising of users rights with some centralized support.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Yes they can BUT and big one is the reality all individual processes need to joined up to achieve the business goals and strategic objective. User input is very valuable but needs to be coordinated and do not forget compliance may want a say in how information is created.

The only solution we have found across our customer base to "joining up" individual processes (especially process fragments which are way more common than processes that have objectives at their end nodes) is to present to each user a "menu of services" where they pick what they like, including individual steps (i.e. processes of one step each).

If an organization performs all work in a Case environment and parks Case objectives at each Case, taking care to ensure that no Case accommodates work that is not supportive of strategic objectives, then all is good.

Compliance is taken care of by pre-conditions at the 1st node of any "process" - these basically ask "where are you coming from?", "what have you done?" and "are you sure you processing at this node should be engaged?".

The practical example we refer to is someone attempting to ship a custom manufacturing product that has not gone through QA. The "ship" step will not engage, but you can, of course, always do a supervisory override.
  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.