It’s all because of Adam Smith! Wasn’t he the one who introduced the division of labor? What, he didn’t invent it but simply described it? Anyway, it’s the phenomenon that we are going to talk about, not the person.
It happens all the time: as soon as we find a solution for a problem, the solution becomes a problem itself. The division of labor is not an exception: it increases the productivity indeed, but it also decreases in other cases. » read the rest
No, it’s not about processes start and end event, it’s about what should be named as process and what shouldn’t.
A few quotes showing the range of opinions -
Paul Harmon comments the “Process and Capabilities” discussion at LinkedIn BPTrends group:
One of the major differences in the field is between people who use “process” to refer to a diagram, or even more narrowly to the pattern of activities and flows, and those who use “process” to refer to everything that is involved in producing specified outputs. I am definitely in the latter camp… for me, the idea of separating “recourses” or “people” or “managers” from “process” is simply to take a very narrow view of process… The “capabilities” the Army cites are small processes - activities if you would - that get assembled into larger processes when necessity requires. One capability is landing by rubber raft. Another is hiking 10 miles very quickly, etc. Once a specific hostage situation arises a process (project?) is assembled of many discrete activities and executed.
As we can see, Paul tend to name “process” literally everything - activities and combinations of activities of any scale, and makes no difference between processes and projects. » read the rest
The term “process” has different meanings depending on the context, confusing BPMN beginners. This brief note should help.
E.g. “Company closure” is not a process because it may be executed only once. (Of course if you do not provide liquidation services for others. )
A process may take different paths depending on data or events, it may run in parallel etc., but it is assumed that we know all the gateways in advance - not at the execution but at design time.
This is a strong assumption that doesn’t match everything we call processes in everyday life. For example it’s hardly possible to predict the route of patient’s treatment at the hospital from his admission to the emergency room. The same applies to a case in court: the opposing party may submit a document that will turn the course of the process by 180 degrees from what we’ve planned in advance.
Such unpredictable scenarios should be treated as projects or cases depending on the context.
If a it can’t be decomposed into tasks then it’s not a process. A process is a set of related tasks and/or sub-processes i.e. it’s not atomic.
A subprocess is non-atomic too. The difference between a process and a subprocess is that a process is associated with external events (it responds to an event at start and initiates an event at completion) whle a subprocess is triggered not by an external event but simply by a control flow in the parent process or subprocess.
A BPMN process has a well-defined start event, a predetermined flow of actions and defined set of completion states.
“Budget process”, by contrast, isn’t a BPMN process. From BPMN perspective it’s a set of related processes (e.g. “Budget approval”, “Budget execution reporting”) plus tasks belonging to processes from other domains like “Check budget availability” in the “Purchasing” process.
Similarly, “Promotion process” isn’t a process but a family of related processes in terms of BPMN. “Manage something” probably stands for a process family, too.
If there is a flow in your process that returns it to the very beginning e.g. after an approval task then consider an altenative option - to end the process with a negative status having in mind that another instance may be started any time.
E.g. if a hiring process didn’t succeed then it’s better to end it with appropriate status than to loop. It can be started over again, probably with different input (with a more generous salary offered).
It’s better in terms of monitoring and analysis: we honestly admit that the process is not always successful. The process duration data becomes more trustable, too.
The common view of a process is something processing inputs into outputs - here inputs and outputs are resources.
BPMN processes are different: they respond to inputs and generates outputs, i.e. inputs and outputs are events. I’ts also possible to model input and output resources in BPMN but these are optional while start and end events are obligatory.
Process start is a handler of some external event, process end initiates an event in the external environment. A particular but quite common case is “none start” (free will) event and “none end” event that produces no effect to the environment.
Do not attempt to use BPMN for things like “employee’s working day”.
The right approach is to model processes like “Client’s order end-to-end”.
BPMN process starts when someone is willing to initiate a certain sequence of activities or when an external event (e.g. a client’s order arrived) triggers it and it doesn’t end until the very end, i.e. while there are things to do (e.g. a customers service called a buyer after shipment) .
“Here the sales process ends and accounting process begins” is a bad idea - it’s a single cross-functional process, not two separate ones.
Treat a process as end-to-end, ruled not by business units boundaries but by the customer’s view (external customer’s, ideally): start from the customer’s request and continue until valueable result is delivered.
Switching from traditional “inside-out” view isn’t easy so use the following method: instead of modeling the saless process consider the process of buying by your customer; the process of submitting a complaint and obtaining response instead of internal complaint processing and so on. Find out what is the optimal process from the customer’s perspective.
Internal consideration’s should be taken into account at some stage of process design too but it’s better to start from the customer’s view of the process.
It’s possible to use BPMN for detailed regulation of a single workplace activities but it’s not why we love it. If employees are not trained then it’s a problem indeed but it’s a functional rather than process problem. And there are many solutions for it apart from BPMN.
The process problem is this: employees are functionally competent (i.e. are able to do their jobs) but the whole process is complicated as it requires precise coordination of efforts of business units separated by the hierarchy and geographically. The responsibility for the handoffs and for the end result is unclear, resulting in poor overall performance.
BPMN is the tool of choise for this kind of problems because it makes the interaction between participants explicit and equally clear for all stakeholders - top management, business units and “process engineers” (including IT) responsible for the process implementation.
It ain’t a classic blog post but rather a rolling-out story. No one knows how it will go neither who is the killer 
The reader of this blog Crisitan submitted a comment asking how to model “state machine”-like processes:
Here is my made-up story: we are trying to model and implement a computerized system for handling the lifecycle of some licence obeying the rules below.
The Ministry of Energy of some country issues licences for oil exploration and production to applying oil companies. Oil companies must get a licence before they may legally produce or explore for oil in that country. When companies get a licence from ministry, they are said to own the licence. In order to get the licence, a company must first apply for it via ministry. Any licence application gets reviewed by ministry staff and, if application is approved, it results in the issuance of the licence. A licence has an Issue Date and an Expiry Date. Every time Expiry Date is moved forward, it does so at most one year at a time, but it may be moved forward repeatedly thru the Renew Licence function of the system.
Depicting process interactions with external stakeholders is a standard stumbling block for BPMN newcomers.
A typical example:
Fig.1
There are a whole bunch of errors: » read the rest
Sorry, this entry is only available in Русский.
Occasionally I get BPMN diagrams like this:
This is the “Payment process” composed of interacting “Accounting department process”, “Business unit finance department process” and “Corporate finance department process.” » read the rest
From time to time we are approached by prospects requesting task control automation by BPM.
The idea is simple: someone assigns tasks by setting goals, responsibles and terms. It’s easy enough to develop a system automating terms control, due dates reminders, statistical analysis, etc.
In short, we want to make a profession out of BPM.
The current issue of BPM market in Russia and worldwide is the lack of a common ground - a core set of concepts, techniques and technologies that would be accepted by all stakeholders.
Process management is a discipline with a long history: TQM in the 70’s, re-engineering in the 90s, BPM in the 2000s. Lean and Six Sigma also have process aspects. Apart from this mainstream, there is a number of esoteric doctrines shared only by the author or a small group of followers.
How does it look from a potential customer perspective? He/she sees a number of gurus, each evangelizing his own way. They cannot agree with each other. They aren’t helpful beyond the relatively narrow scope. The natural question “where can I read about it?” doesn’t meet a clear answer. Besides, BPM is not widely presented in universities and MBA courses. Sub-disciplines (e.g. modeling or automation of processes) are available but BPM as a holistic discipline is not offered in a significant scale.
Not surprisingly, only the most self-confident customers get into it - those who have intellectual resources to pave their own route in a rough sea of BPM. Hence the predictable result: today, 10 years after the birth, BPM is still at the Early Adopters stage of the Technology Lifecycle.
BPM is a fun for practitioners yet that’s what scares off potential customers - they’d prefer something more simple, common, boring if you like.
Can this situation be changed? We believe it’s not only possible - the time for the change is now.
Thanks to the efforts of BPM pioneers we now have practical experience in methodology, technology and implementation. A number of organizations have achieved spectacular success in BPM. The community of BPM enthusiasts in Russia develops a common view of process management issues for more than 5 years. We have matured to develop a consensus on BPM basics. (Just basics - it’s not about eliminating diversity and creativity in the whole BPM domain.)
And it’s easy to do because there is no need to invent the basic platform. For 10 years there is an organization called ABPMP (www.abpmp.org) - The Association of BPM Professionals - comprising more than 6,000 members around the world. And it isn’t just a club: ABPMP published and further develops (the third edition to be released soon) the BPM CBOK (Common Body of Knowledge) and certification system called CBPP (Certified Business Process Professional) based on BPM CBOK.
By creating the ABPMP Russian Chapter we want to assist the transformation of BPM into acknowledged discipline and eventually to add dynamics to the BPM market.
Is it real? Looking at the project management state of the art, there is every reason to say yes. PMBOK there vs. BPM CBOK here. A system of certification here and there. Yet unlike BPM, there is no need to explain what a project management is. The reason is obvious: BPM is younger. But it will pass with age.
Another encouraging example is ABPMP Brazil Chapter. I was surprising to hear from American colleagues that BPM ideas in Brazil are more widespread than in the US. No doubt there is a contribution of the local ABPMP Chapter and its president Gart Capote who advised me on establishing the chapter in Russia (thanks, Gart!) Why not achieving a similar success here? Russia has endless opportunities for process management and BPM.
So far, the initiative group has created a Russian Chapter (www.abpmp.org.ru) and registered it with ABPMP International. The next important milestone is the kick-start meeting - the registration is opened.
Planned Chapter activities are: Russian BPM glossary, BPM CBOK translation into Russian, CBPP certification, seminars, workshops etc.
Get involved now!
Copyright © 2008-2024 Anatoly Belychook.
Thanks to Wordpress
and Yahoo.
Content
Comments