Business Processes: How everything is started and confused. Chapter Three General BPM Classification and BPMS Philosophy

BPM "As is" and "How not to eat"

We continue to think about “what is BPM”, which is “Business Process Management” and what they are. Paradox: so many decades have been written about him - books, articles, discussions, but what it is - today remains a mystery, and: the more they write - the more mysterious it becomes.



Neither books from the “For Dummies” series, nor the CBOK precepts, nor the magic squares from Gartner (BPM: BPA, BPMS, iBPMS, etc.), in which, as in the black squares of Malevich (and he has only black there were several "different" options) - everyone tries to see something great and mysterious, driven only by him.

')

The chapter proposes a classification option for BPM-like entities. In the information war with the "alchemy of the 21st century" we continue to debunk the popular myths about Business Process Management, Enterprise Architecture (EA) and others like them. We are making another step towards the development of BPM as an ordinary (everyday, ubiquitous, trivial) engineering discipline: process technology, “process engineering”.







Reconnaissance



In the first chapter, “Business Processes: How Everything Is Launched and Confused,” we looked at BPM through the eyes of marketing and revealed its key myths. On the pages of cnews (see comments on the article) they discussed on the topic “BPM - EA - Alchemy”.



In the second chapter, they tried to separate the “flies from cutlets” and showed extremes (heads and tails): BPM is not about business management (there is rather something “from the operas” of BIZBOKs, BABOKs, etc.) and not about "IT chips" (SOA, ESB and their ilk). BPM is not even about automation, which is in classical programming languages ​​(from “si”, to “java” under control of SWEBOK-i), that on “newfangled” tools - based on BPMN or even on “nothing” (“no code” where supposedly code is not needed). Discussion of the second chapter with the participation of "The Alchemist Level 80" on bpmsoft.org



When half of the “smart book about BPM” is devoted to SOA, ESB, etc., you think: if they are not in the company, then BPM in the company is also impossible? Or: will BPM live in a company with no (little) automation? On this topic is a fragment from the book Business Process Management. Practical guide to successful project implementation



Chapter 2 What is business process management?

This question must be answered at the very beginning, especially since every supplier, analyst, scientist, teacher, journalist, and client has his own answer.

I would like to clarify right away that, in our opinion, BPM does not equate to technological tools or an initiative project in the field of business processes. Our experience suggests that a significant improvement in business processes can be achieved without the use of automation technology.



Message "Kettles" from IBM .

What revelations did the blue giant tell us in his Business Process Management For Dummies, IBM Limited Edition?



Introduction and first chapter: written in the style: “Happy owners of BPM”, “Only BPM can help your organization to become ...” (higher, further, stronger, etc.) ... super-duper, etc. Moreover, in the advertising style of the book, this suggests the substitution of the consonant term “BPM” by “IBM”, without any change in the semantic content (more precisely, advertising): “If you have read the chapter before this point, then it is now clear to you that BPM (more precisely, IBM ) - this is cool . "



Actually, an entire chapter was devoted to this approach: “Business Processes: How Everything Is Launched and Confused. Chapter one". In a word, after reading “BPM for dummies”, it should become clear to all “teapots” that they really need BPM (this is “cool”), but they don’t need to know this (I did not find the answer in the book). The remaining chapters echo the same thing and, of course, further comes the “ingenious” conclusion that “IBM offers the widest range of BPM solutions”. Not surprisingly, “correct BPM” = IBM BPM. I will say secretly that IBM has no real BPM at all.



Message "Teapots" from the new owner of ARIS. You need to sell BPM, therefore not only vendors, but also salespeople make books for Dummies: BPM Basics

For Dummies Software AG Special Edition



In these “fundamentals”, everything is collected: adaptive and flexible processes, visualization and control of end-to-end processes in real time (even orchestration and choreography of processes in real-time and cross-functional visibility), “automation - simulation - optimization”, connection using the formula { people, information, services, systems, processes}.

Of course, Continuous Process Improvement (CPI), Real-time monitoring (BAM), KPI-BSC, etc., as well as those recently “attached” to BPM: WYMIWYR and DMAIC, are not forgotten.



Typical error in the book, where it is said that "BPM is a wide discipline." BPM should be a “narrow”, specific and understandable discipline. Only this will make it a practical and universally applied engineering discipline. Take out contiguous areas, invent lofts and basements for BPM, make a clear stack of BPM (by analogy with network protocols), but you don’t need to interfere in one heap under the sign of “broad discipline”.

In the meantime, we are being presented with “too much BPM, so that it can be understood” (too big to eat).



If they first said that BPM is a “business infrastructure” (this is true), then apparently this needs to be followed, rather than mixing the infrastructure with business entities and not considered in BPM “The BPM Business Architecture”.



3 General BPM classification



3.1 Popular Views on BPM Classification



Some say that BPM is just a management philosophy that allows you to focus on processes or leadership strategies for successful business transformation, others that this is a kind of many-sided discipline: either documenting, developing, implementing, or something else, but under the universal term "discipline of management". Others (artists apparently) claim that this is something that lies next to SOA and Web 2.0 and they like to mention orchestration and choreography.



Most often: BPM is presented in "three persons", where the business process:

- documented and analyzed (design & analysis tools);

- simulated and modeled (simulation engine);

- deployed and executed (execution engine).

Nearby is the "servant": dashboard, repository, etc., and in the VIP-box: CPI, BSC-KPI, etc.



Popular, but "slanting" views of pros on BPM classes (directions and relevant tools) suggest a color picture from a set of numerous and well-known marketing terms.

A good example of entanglement and not “simple and clear” BPM is shown in Fig. 3.1. A look at BPM from KPMG

There are many similar architectures and ideas about BPM, just like this one: a bright, beautiful picture (there are five for designers - presenters), but incomprehensible.







Fig. 3.1 A look at BPM from KPMG



In Fig. 3.2 shows a picture from www.what-is-bpm.com , which reflects a more understandable (albeit less “artistically”) approach to the classification of BPM tools.







Fig. 3.2 A look at BPM - tools from what-is-bpm.com



The picture reads like this (a little with irony, in order to better convey its essence):



1) from Understanding - understanding your processes (“know your process”), which is supported by process mapping (Process Mapping) and documentation tools;



2) to the improvement of processes - through Analysis (where is it then without analysis?) And simulation modeling (not to be confused with just “modeling” = “documentation” in the context of Understanding);



3) to automation / modernization (they were almost made synonymous with them) through BPMS variants, with integration through SOA and the development of “applied hybrids and composites”;



4) and certainly, all this is “constantly optimizing” and reengineering, again optimizing and again “rethinking fundamentally”, i.e. looping the process to continuous - “eternal” perfection. I don’t understand why it is needed this way - apparently, there are no “brakes” in this BPM (they forgot to foresee), but in many books it is written that way.

Moreover, what is the difference between p. 4 and 2?



A small addition: if EVERYTHING is needed for a “small party” (workgroup), then all of the above is “a rash little by little”, and if for a “cool” Enterprise-Wide - then a lot of them (the “Scope” vector shows “Scale”), plus we need a repository (o) of processes and some kind of “interaction of processes” (the topmost “bun”).



3.2 Simplified classification of BPM systems



Considering the diversity of BPM areas, we will exclude from the consideration of BPM components that are not directly related to the description of processes, such as: improvement (CPI), optimization, all kinds of not clearly formalized "management", etc., and concentrate only on the description of processes and their simplest analysis (without the "business component").

Those. BPM in terms of “process level”, “process engineering”, shown in the second chapter of this cycle.



There are three directions:

- basic BPM, “BPbase”, which is based on:

- - formalization of BP, "BPdoc" and

- - secondary processing and analysis of formal entities, BPana;

- BP simulation, “BPsim”;

- performance of BP, "BPexe".



The task of BPdoc is to formalize processes (show images of real processes in the form of diagrams). BPsim - “revitalize” processes through a dynamic process model or reflect process characteristics on static models (not description and regulation).



BPexe - needed to get executable program code, i.e. "Make the process a program." “Light dream” of any automation (dream No. 1), including BPexe “to make a fairy tale come true”, is when ALL logic is “sewn up” in the executable code and all the work of the computer operator (participation in the business process of the contractor) is reduced to one click “big red button.







Fig. 3.3 Simplified classification of BPM systems

In original quality



The classification is explained by the following “tank” analogy:

- BPdoc - image of the tank as a drawing or drawing. In the case of a sketch or sketch made with strokes (impressionism), it is understandable only when viewed from afar (bird's-eye view, high-level). In the case of a working drawing (i.e. by which you can work) - as a set of design documentation (tank in AutoCAD): any detailing is possible, up to all sizes and cuts (process cuts), “process turning” (you can “twist” the processes ), etc., a picture of the process in 3D (more precisely in n - dimensions, planes), etc. These are “design documentation” for a process (in terms of ESKD), process documentation “in paper”, a working draft for a product “process”, a process specification, etc.



- BPsim is a smaller model of a tank with a remote control: it seems to be a toy, but "moves and shoots plastic bullets." Such a tank looks like a real one - all the details are exactly the same (replica), you can even make a mass-dimensional model, but you will not send it to the front (only as a false target). Another example is toys with “cool physics” like World of Tanks or professional air / car / tank simulators. Also, everything is almost like the present, but the input data (height, speed) are fictional (calculated) and health (the real process) does not harm "if something goes wrong."



- BPexe is already a real tank, obtained from drawings (BPMN 2.0) loaded into a 3D printer (BPMS). Download the drawing, print the product (publish the processes in the execution environment) and “to the front line” (deploy the program to the industrial environment). Printing real tanks is still in the future (not far away), but the real small arms are already printed: The evolution of 3D-printed weapons



Approximately, as in today's BPMS: simple things are made in executable BPMS (and implemented), but for complex ones they use traditional technologies (classical programming systems, ready-made ERP / ECM, etc.). The capabilities of modern BPMS are still very limited, but progress does not stand still.



The term “BPMN” can be referred to other “executable” notations, including the original sets of icons (figures) from our “se one” and bourgeois “ke two” (1C & K2). No matter how much they took directly from the BPMN 2.0 standard outlines, as a rule, the essence is the same: “printing processes on a BPMS 3D printer” (some Process Blueprint).



3.3 Details of “BPbase - Bpsim - Bpexe”



BPdoc is based on a graphical representation of formalized processes (modeling in graphical notations). A process in diagrams is usually represented in terms of the workflow (workflow), rules (branching logic), and information flow (dataflow) and documents (docflow).



BPdoc tools are usually defined as the Business Process Modeling (also BPM) Tool. But in the understanding that "modeling" is not "simulation", i.e. A “model” is simply as a scheme with connections of objects of its objects and stored in a common repository (archive). Connectivity as with other schemes, reference objects (processes and other entities).



BPdoc does not include:

a) the entire regulatory framework of the company or even a complete set of textual regulations, because only textual and graphic “process inclusions” (process regulations) are implied;

b) the structures in the composition (it is terrible to pronounce) Enterprise Architecture not directly related to the processes.



In the extreme case of BPdoc, there is a “big” Processes Map, although I don’t understand how a complete description of the process is possible without textual descriptions. More precisely, BPdoc is an operating model of a company, by which we mean a related description of processes (functions), positions (roles), documents (processed information) and tools (information systems, information systems).



As a rule, a detailed description of the org structure and IP for this is not required, but only a hierarchy (hierarchical reference book) with objects involved in the “lightweight EPC” class circuits is sufficient. In the “lightweight EPC” of the whole variety of EPC (Event Chain of Processes), besides “function” and “event” are limited to 5-6 types of objects: role, document, information system.



To read (describe) the final process without an org-staffing (role-playing) structure, without a set of tools (wood) and without incoming / leaving (in / out of the process) documents is inefficient (uninformative). Exceptions are schemas showing branching logic. Therefore, we need a “binding” of the “Function” element (“environment of the function”) and a summary of these bindings in a simple structural diagram (at least an org-regular and structural diagram of the IC). See details in the “Modeling Agreement” of any ARIS project.

The emphasis above is on notation for fixing processes (led by EPC), but BPdoc uses any other, including the class “executable” (BPMN).



The BPM "executable" (BPexe) contains at least the designer (application development module) and the "execution environment" (engine, BPM-Engine) and is actually a kind of programming system. Namely, the direction “programming without programming” by means of the visual designer of programs (although often a lot of code is required to add to the BPMS). This process, although it concerns BPM, is closer to the programming environment with graphical language in the form of BPM notation (BPMN) and with the “source code” in the form of a process diagram and screen forms. Today, BPMS vendors convince us that this is the "real" BPM ", but it was the theft of the BPM brand (" false BPM ", see Fig. 3.4).







Fig. 3.4 Counterfeiting the term BPM



Developers and salesmen of “new wave compilers” (BPMS, where “graphics to code”) took away the brand “BPM” from system engineers (SE), and instead they threw “bone” - BPA. Business Process Analysis



The substitution was carried out according to the scenario: “they will give a finger, we will bite off the hand”. The “surrender” (without a fight) of the BPM brand to the “grace to the coders” (SWE) was accompanied by the compromising of the initial ideas of BPM - as a management methodology and high-level components of the “Enterprise Architecture”, which are either not needed or slightly significant in software engineering (more precisely, the winners have their own EA ").

It was a remark to the history and philosophy of the BPMS in the context of the “as is” vs contradiction “as really is”.



The result was a “false BPM” with dubious benchmarks for classic BPM, since BPMN 2.0, like BPMN and other executable notations so far:



a) ineffective for business analysis (in comparison with BPA),

b) are questionable for programming by business users.



Often, the usual automation of processes by “unusual” software development tools - “executable BPMS” is positioned as a “successful BPM project” (laurels of “someone else's victory”). It has already been stressed: there is no direct link between BPM and automation. Implementing “executable BPMS” and building a program with it is “type BPM”, and building a CRM, ECM, ERP in the built-in BPM editor (designer) of the same process scheme in a similar or the same notation is not considered a BPM implementation. Why? This is just Embedded BPM. Almost all modern CRM, ECM, ERP have workflow designers, at least “similar to BPM”. Business processes of the company: ECM, CRM, BPM - what's the difference?



The implementation of a new application assembled in the BPMS designer and launched on the BPM engine is not much different from the classic automation. There are many visual programming systems and program designers (including the website master and the children's Scratch), where the “programmer” may not see a single line of code, which formally also BPMS is “no code”.



The basic principles of automation of modern BPexe (BPMS) are a twenty-year-old analogue of SCADA systems used in the automation of technological processes (in BPexe - administrative, management processes). The same visual designer of programs, with the difference that instead of documents there are electrical signals, and “live performers” (roles) are latches (actuators in the process control system) or sensors.



In many of today's “already long-term elderly” SCADA, including the domestic TraceMode, initially there was a BPMS-like visual editor [for a “programmer” who did not know programming], a flowchart, his Business Activity Monitoring (BAM) - monitoring, showing in real time limit (control) and real values ​​of temperature, pressure, velocity, volume, etc .:



The system allows you to create complex process control systems without any programming at all - in special graphic editors using the terminology familiar to the process engineer .



Somewhere already heard something similar, but about the "business technologist"?The visual design of the company's workflow (BPM) is similar to the visual design of a technological process (APCS).



BPM simulators (BPsim) - in most cases, is a kind of intermediate category between BPdoc (real BP policy) and BPexe (real program, that is, automated BP and documented, for example, through BPMN). Simulators allow you to "feel" the dynamics of the process (dynamic modeling), run the "simplified" instances of the process.



Unfortunately for BPsim, as well as for BPdoc, the term “modeling” is used (simulation - as simulation modeling), and modeling of “business processes” is possible both in “real” BPA-BPMS (ARIS Simulation, PBexe) and in universal ones ( classical) modeling systems. Modeling is possible both by means of graphical notations recognized by the BPM community and in “unrecognized” or in general by means of non-graphic abstractions, including modeling languages, for example, GPSS: Business process simulation modeling

BPmon is a means of “process monitoring”.



3.4 The reasons for the popularity of BPMS or “on the way to the great goal of mankind”: the creation of programs without programmers

When describing processes by means of BPdoc, BPsim, BPexe, the keyword is “graphical process diagram”. Although the process can be described not only by small squares or by the power of the Russian language: the process description in letters is also a textual process regulation.

For the formalization of processes and events, there are specialized languages, especially common in simulation systems, but they are more likely invented for programmers and not for analysts, methodologists and other "fixers and surgeons of business logic from business." Even though some languages ​​contain the cherished word “business process” in their name, for example, Business Process Execution Language (BPEL).



This also applies to the “greatest” BPM notations: The abbreviation BPMN is rather deciphered not as a Business Process Execution Language, but as “Business People May Not understand”, that is, “business people may not understand” this notation (Jim Sinur )



Over the years, the desire (dream No. 2) has not faded away - to find a simple way of modeling processes directly by their participants (involved in the process) without involving BPM specialists “in drawing squares and circles”, as well as performing the processes constructed in this way. Hence, strong craving (hope) for the BPMS format (BPexe).

Unfortunately, it still remains a dream, although periodically people recall about it, for example, it was under this idea that BPMN started. But BPMN loses much to the same EPC for the purpose of fixing and analyzing algorithms at the level of business users (intuitive criterion) and “tops” and did not reach the goals that were originally set.



The hard-to-readability of BPMN is also influenced by the forced high details of the process being described: if the EPC can be sent for details to the textual regulations, then in the case of the executable BPMN, one has to “carry everything with him”.

The next turn is being made by the “new modern challenge of BPM”: S-BPM, the paradigm of “subject-oriented BPM” from the next Moor (also a German professor).



Another myth is that once BPMS is used, the output is “efficiency multiplied by optimality”. For the Shaitan-BPMS process designer immediately creates an “efficient process” (apparently through the stealth library of hyper-cognitive analysis), and the BPMS runtime environment makes the business logic of the process optimal and on the fly.



"Ears grow" from the hypothesis that most programmers write programs not for humans, but for "their own kind." It is believed that its programs are convenient (understandable) only to the same programmer, and not to the target consumer-user (business unit). The popular concept of providing "packaging" of the program algorithm is not in the code, and intuitive nonprogrammer (methodology, the user) graphical notation and, accordingly, the absence of both the code and the effect of "broken telephone" during the development process: the cold hard truth of any atypical project ( swing)



Moreover, there is a desire to ensure the work of the received program (execution) without the participation of the IT service (“publish” in the “prod” button by the user). As we can see, the implementation of the concept is still far from ideal, but progress also cannot be denied in this rather ancient direction of “Programming WITHOUT PROGRAMMING”.



The above aspirations are in “trends”: BPMS, “low-code”, no-code "(programs with a zero amount of code, it may even appear “with a negative code.”) In reality, everything is simpler: “Nothing personal, just marketing.” For example, they do not accept us into the ranks of “real BPMS”, because, for example, BPMN- is not supported notation means we call it “low-code” (including “one se” and “ke two”). Or we want to “open” Marketing market (in fact the same), the first "jump" in sneakers «code.net».

The same “one form” (1forma.ru) is positioned both as BPMS and as a Workflow class management system, and it doesn’t deny “low-code” - if the buyer likes it more.



Often sales are made like this:

- Buy this wonderful puppy! (soft)

- And what size will it grow?

- Do you need a big dog? Yes? Of course, our puppy will grow and become a huge dog! (BPMS)

- Ah, no? Do you need a tiny dog? So you misunderstood us: our puppy will no longer grow - it will remain the same (“low-code” & “no-code”)! Just buy it from us!



The key "trick" of the "low-code" systems is the creation of an application by dragging the necessary functions from the libraries of functions and building the application logic without the need for coding using the visual configurator.



While modern BPMS is not very friendly with “human-like developers” (non-programmers), therefore, like any other programming systems (starting from C), they still require a lot of code, and also “chaos automated” is easily made from “just chaos”. The latter is even more dangerous.



Were and remain in vogue (often a dream) “code-making” systems (including “no-code”), languages, notations and other abstractions (including languages ​​for describing business, processes and life in general) for methodologists of business units of the company, those. Tools not for IT services and programmers, but for ordinary users. The latter should at least easily read their processes on these notations and abstractions. Sometimes this is called “formalization in the language of business”, and by “Business user” (non-technical users).

Notations and abstractions should be practical, standard and understandable even to non-programmers (child), but to allow the construction of models (description) that are adequate to the actual processes.



Interestingly, the direction “programming for children” is developing in a similar way, for example,My experience of teaching children of 8-10 years of programming on Scratch



BPexe (BPMN, "low code", etc.). Considering that BPexe supports at least the stages: modeling, implementation (actual implementation of the program) and its deployment, the models under “exe” (execution) - in fact ALWAYS adequate to the real process, and automated. BPMS Leader Review



BPana, process analysis is a “broad” direction for creativity. An example of a trivial analysis can be a query to a database: how many and where does this process (object) occur, or in what processes is division A or document B involved? By the way, many queries can be done in the drawing class systems, for example, in Visio (there are also objects used and there is a search system), and if an Excel or Access file with process data is attached to the process diagram in Visio, then the possibilities for trivial analysis can be comparable to “cool” BPM, i.e. BPA and BPMS (in the established classification).

In any case, BPana is “secondary” and requires a “primary” - BPdoc. At the same time, a thoughtful look at the process map (BPdoc) already implies “analysis” (BPana), therefore the edge is sometimes conditional.



3.5 Forests, trees, leaves



Processes have different granularities. At a minimum: top level and detailed. The BPexe class diagrams (models) are all detailed, otherwise the program will not work. This is “by definition” because - “exe” = “execution”.

But the detailing is far from always good: “there is no forest behind the trees”, therefore BPdoc can be divided into two tasks (categories): the task of describing “forest” (processes in a “large cell”, a bird's-eye view) and there are enough detailed “processes - trees”, but, as a rule, not yet such detailed ones as in BPexe (BPMN), where each “nut” is formalized (otherwise “it will not take off”). Means BPMN can describe not only the "leaves" (nuts), but also the "trees", but not the "forest".



On the one hand, for the details (detailed processes - “trees” in the EPC and “leaves” in BPMN), the overall picture of the entire process landscape of the enterprise (forest) is lost. On the other hand, to describe all the “processes - trees” (not to mention the “leaves”) is as difficult as drawing, at least schematically, all the trees, even in a small forest.

On this topic - an analogy of process maps with a geographic map: A meticulous description of business processes - is it good or bad?



A complete description of the business processes of a large company is a utopia. In any case, by means of modern technologies describing business processes: what in the form of multipage textual regulations, what in the form of squares and circles (models, notations).

In the first case, multivolume talmuds will be without connections and visual scaling (from high-level to “send notification by email”).

In the second, EPC schemes (BPMN, UML, etc.) will have to be drawn for a very long time and with a large composition of draftsmen (business modellers / fashion designers) and anyway without a guarantee to get "as it is in reality" (see the picture in the article title ).



Even if all processes are automated using BPMS (PBexe) and there is a complete set of schemes (models) of processes in BPMN, then in order to understand the “picture” as a whole (show “forest”) they will have to be generalized, integrated, systematized, etc.

In addition, the original “workflows” (extremely detailed processes) in the BPMN format, as already noted, will be incomprehensible to the majority of business unit employees. In general, BPbase is a science both in the description and analysis of forests and trees. And the basic notation for BPbase is not BPMN, but rather EPC (in the past IDEF). There are many EPC vs BPMN comparisons in the internet .



In general, if “forest” - high-level processes - is fairly simple to describe (VAD, EPC, but not BPMN) and the value of such work is the highest, then detailed ones are “trees” (EPC, for BPMN, not as “performance”, but only as “Illustration”) is a tremendous amount of work with already lower value (in BPA tasks), if only because these schemes duplicate (should) the text of instructions (regulations).



Describing "processes for direct execution" using executable BPMN-type notations is to formalize elementary operations, i.e. all those that do not require a more detailed description, because the compiler can already pass them on to the code. If the “stupid” compiler can shift the scheme to the working code, then this is an unequivocal “finish” of detailing (the limit for a machine, a person is sometimes difficult to stop and he is ready to detail infinitely by repeating).



Externally, the BPdoc (EPC) and BPexe (BPMN) modeling processes have a lot in common: there are few visual differences — almost the same squares and circles. In many ways, this has allowed borrowing (straightforwardly - to steal) the promoted term “BPM”. Although BPexe partially solves the same problem - documenting the process (in Fig. 3.3, the result is “by-product”, BPdoc '), but they still have fundamentally different purposes and “their own philosophy”.

The first is to show the person how the management process works approximately (“as a whole”, and for many details see the text of the regulations, therefore, there is a lot of books in it).

The second is to give a clear instruction to the compiler (even if through graphic images) “what to do” (and many details are still present only in the code).



Over time, the line between BPexe (BPMS) and BPdoc (BPA) should gradually fade. Perhaps, from the modern BPexe, which is still “for the programmer”, a separate class of systems will stand out that will be for the “person”: for a business analyst who does not know at all “scary words from the IT world”. In other words: BPexe will become a full-time tool for a business specialist, not a programmer (IT service).

I hope that BPdoc will wait for the same fate: it will not be necessary to have a staff of “fashion designers” (or hire EPC consultants) to draw process diagrams, and process models will be generated from standard regulations, perhaps even imperceptibly for the user.



In the very distant future: automatically - directly from the process itself by analogy: topographic maps from satellite images (“aerial photography” of the company's processes) or network disclosure (OpenView Network Node Manager, etc.). At least learn how to count the number of company processes, like sheep through NASA satellites, as in the famous parable about consultants (“A helicopter lands near a flock of sheep ...”).



Formalization of processes (BPdoc) has different tasks: from the trivial regulation of individual operations in graphical form to building the Enterprise Processes Architecture. Sometimes BPdoc is carried out under the subsequent automation of formalized processes, i.e. is the first stage of the Business process automation (not to be confused with “BPA”, where “A” = analysis). As it was emphasized: the description of processes exists by itself, regardless of whether it is “automated process” or manual and “whether it will be automated” or not.



With “automation by schemes” (BPdoc), prepared in EPC (IDEF, etc.), this approach is opposed to the approach “one shot of two birds with one stone” (PBexe), when the schemes for automation are developed initially in executable BPMN notations and the like, . "Execution". The choice between BPA (EPC) or BPE (BP execution) in favor of the latter (BPMN) is not as obvious as it may seem at first glance: the difficulty of perception by “businesses” (not from the IT world) of the performed notation (BPMN and similar), imperfection of the technology itself (BPMS tools).



BP-BP(Business Process - Best Practice) are not BPM CBOK type books, but practical templates and prototypes (including just replication examples, sample sets of processes with a detailed description), reference models from a specific area, process classifiers (for example, APQC PCF Process Classification Framework), etc. In general, this is the basis on which efficient production of goods (services) can (should) be built, and not a conveyor of speculations. This is a separate global topic of discussion about the future of BPM (well forgotten past): Global BPM.



3.6 Related concepts



With reference to BPdoc, BPsim, BPexe, many of the terms “Process [X]” can be attributed, where X =

- Model / Repository & Design / Documentation (somehow processes need to be formalized and put them somewhere). It is not so important to develop a process for the future (to be) or document an existing one (as is). Sometimes they call it Process Understanding from the series - “know your process” (compare: “know your client”);

- Portal / Publisher (publishing processes, working together, “share your own processes,” etc.);



BPdoc often uses a “Process Map” / “Process Mapping”, expressed as either a hierarchical tree or a graphic. Further Process Map can be used as a “substrate from processes”, on which certain metrics are applied. If you apply data to YOU ​​on a substrate, then you get a mosaic of indicators on the background of the “process map”. Related names Process Dashboard, BI Dashboard, Process Measurement and others.



BPana - many of the Business Process \ Performance Improvement, all of the “most continuous” improvements and just reengineering, can “sit at it”. But it is already outside the "pure BPM".



3.7 Overboard "pure BPM"



In order to “not break the spears”: “BPM is or not”, we single out the BPMextra category (extraordinary, “extraordinary”) as a separate category, and “merge” everything that is not included in the understanding of “pure BPM” (see Figure 3.3) and BPexe .

The first set of applicants is most of the terms (fashionable "chips") from "Hype Cycle for BPM" ("cheating curve"). The



second is all that "stuck" to BPM (s) through IT ("tails"), including the heterogeneous "BPM integration "type integration-centric BPM, focused on the integration of business process management systems



In the BPextra category, we will include obscure and "stellar" terms and processes for them: all BPM-environments associated with the "Strategy" (Business Strategy), "Management Governance" ("Governance", Governance Mgmt., Process Governance), "tracing strategic business development goals ”,“ general corporate rules for management ”, including business processes. According to the terminology of the second chapter of this cycle, it is “Business-acetone” (“heads” in the BPM distillation process).



Anyone who can’t tear off all “the very thing” progressive and take it as BPM can include it in BPextra: Kaisens, total quality management (TQM, QMS), “most” lean manufacturing, “all sigma” (Six Sigma and seven sigma, ie which are + Lean), and other “perfect” technologies of general improvement, including the improvement of business processes, but which are not based on documenting, regulating and standardizing specific business processes of a company.

Classification of the methodologies of "transformation", "improvement" (the most advanced "improvement"), "Toyota", etc. See Business Process Management Methodology (BPM)



. “Very-most” progressive and “like BPM” are also mixed in:

- Business-driven development, this is the methodology in which IT solutions are developed that directly meet the requirements of the business (apparently all other programs built outside of BDD do not respond to this and, therefore, are useless);



- x_BOK-and, especially, where "x" includes the cherished word "Business":

- - BIZBOK (Guide to the Business Architecture Body of Knowledge)

Note that there is a lot of things - both from BPM and EA;

- - REBOK (Requirements Engineering Body Of Knowledge), requirements engineering, there are the same Business Strategy, Business Case, Business Rule, Business Process, etc.),

- - BABOK iiba.ru/category/babok(Business Analysis Body of Knowledge), also requirements engineering, but is positioned as a business analysis "in order to identify requirements"), by the way, there is a decent library on this site, including in the BPM section;



- Service-oriented modeling + "x", where

"x" = "and architecture", then it is SOMA,

"x" = "framework", then SOMF, there is a service-oriented analysis and design (SOAD), there is a Service- oriented modeling sub-ontology (SOMsO) and of course BPM sub-ontology (BPMsO) and a lot of similar things in books like this: "Service-Oriented Computing ICSOC / ServiceWave 2009 Workshops";



- and many, many similar things: sometimes it seems that any technology can be brought under the "multi-faceted" (many-sided) BPM. To BPextra (“like BPM”) we put the “architectural pictures” from the EA world and everything else “correct and similar” to BPM, but that is not included in “pure BPM” (Natural BPM). Bringing order to BPextra itself will be another time and probably already outside the plane (layer) of BPM.



Your,

bipiem