What is the purpose of the epc schema. Description of business processes in IDEF, EPC, Aris notations
Live Journal
Facebook
TwitterMOSCOW STATE TECHNOLOGICAL UNIVERSITY "STANKIN"
LABORATORY WORKS
ON
DISCIPLINE "TOOLS OF CALS-TECHNOLOGIES"
Moscow 2009
LAB #1
Objective: Formation of skills for developing a business process model using an EPC diagram.
Work tasks:
1. Studying the rules for constructing an EPC diagram;
2. Development of an EPC diagram of a business process in accordance with the task.
Rules for constructing an EPC diagram
Chart objects:
| An object | Description |
| Functions are elementary actions aimed at the implementation of a business process | |
| A department or a separate state unit that performs a function | |
| Position (including multiple) in the organizational structure, performing the function | |
| Information carriers, both material form (paper documents, etc.), and electronic representation of information: files, emails, Internet resources, etc. | |
| A product or service that results from or is required to perform a business function | |
| Information flows providing process inputs and outputs | |
| Qualitative or quantitative situation (state), the achievement of which is important for the company | |
| Regulations |
Relationships of chart objects:
|
1. To build a diagram of an event-driven process, the objects specified in the "Objects" section and the relationships between them specified in the "Object Relations" section are used.
2. The diagram defines the sequence of actions and events required to complete the process. Each EPC model must begin with at least one start initiating event (state) and end with at least one resulting event (state). Events and functions in the course of the process must alternate (change each other) (Fig. 1).
Rice. 1. Functional-event sequence of the business process
- All functions must go in the correct sequence. It is necessary to consider whether they are parallel or sequential.
- Events and functions should have only one incoming and one outgoing relation showing the progress of the business process.
If there are branches, then it is necessary to use the branching operator, while showing all possible options for the flow of the process and the results of the execution of functions. The branching always starts after the function.
On the eEPC diagram, the following use cases for branch/merge rules are allowed:
1) Conditional branching of the process using the "exclusive OR" operator (when the function is executed, only one of the possible events occurs) (Fig. 2).
Rice. 2. Branching with the XOR operator
2) Conditional branching of the process using the “OR” operator (during the execution of the function, either one event occurs, or the other, or both at once) (Fig. 3).
Rice. 3. Branching with the "OR" operator
3) Conditional branching of the process using the "AND" operator (when the function is executed, both events occur) (Fig. 4).
Rice. 4. Branching with the "AND" operator
4) The function will be executed if both events have occurred (Fig.5).
Rice. 5. Connection with the "AND" operator
5) The function will be executed if either one event or the other has occurred, but not both at once (Fig.6).
Rice. 6. Connection with the XOR operator
6) The function will be executed when at least one of the events has occurred (Fig.7).
Rice. 7. Connection with the "OR" operator
- The same operators must be used at the input and output of the branch (Fig. 8).
Rice. 8. Using Operators on Entry and Exit
- The previous and subsequent processes are determined and displayed in the interfaces (Fig. 9). If there are no previous and subsequent processes within the company, then the “Process Boundaries” object (“Process Start”, “Process End”) is used.
Rice. 9. Functional-event sequence of a business process with interfaces, indicating the boundaries of the process
- All the necessary information and resources needed to perform the function, as well as the results of the function execution, are determined and displayed. It is necessary to accurately display incoming and outgoing information. For such documents as: Order, Memo, Application, etc., it is necessary to indicate their purpose. Information that is transmitted orally, as well as unstructured information on any media, is displayed with an information icon (Fig. 10).
Rice. 10. Functional-event sequence of a business process with interfaces, incoming and outgoing information
- The executor of each function is determined and displayed (Fig. 11).
Rice. 11. Functional-event sequence of a business process with interfaces, incoming and outgoing information, regulatory documents and performers
- The possibility and necessity of function decomposition is determined. If necessary, the functions are described in more detail on the EPC diagram and reference is made to it.
1. An EPC function diagram must begin with at least one start event (the start event may follow the process interface) and end with at least one end event (the end event may precede the process interface).
2. Events and functions in the course of the process must alternate. Decisions about the further course of the process are made by the functions.
3. The recommended number of functions in the diagram is no more than 20. If the number of functions in the diagram significantly exceeds 20, then there is a possibility that the processes at the top level are incorrectly identified and the model needs to be corrected.
4. Events and functions must contain strictly one incoming and one outgoing connection, reflecting the progress of the process.
5. Events and operators surrounding the function on the overlying diagram ( Fig.16) should be the start/result events and statements in the function decomposition diagram ( Fig.17).
| Figure 16. Process diagram showing Function 1 | Figure 17. Decomposition diagram of Function 1 |
6. The diagram should not contain objects without a single connection.
7. Each merge operator must have at least two incoming links and only one outgoing one, a branching operator - only one incoming link and at least two outgoing ones. Operators cannot have multiple incoming and outgoing connections at the same time.
8. If an operator has an incoming connection from the "event" element, then it must have an outgoing connection to the "function" element and vice versa.
9. A single event must not be followed by "OR (OR)" or "XOR (Exclusive OR)" operators.
10. Operators can merge or branch only functions or only events. It is not possible to merge/branch a function and an event at the same time.
11. The operator branching the branches and the operator combining these branches must match. The situation is also allowed when the branch operator is "AND", the union operator is "OR".
Examples of acceptable situations ( Fig.18, Fig.19, Fig.20, Fig.21):
| |  |  |  |
| Figure 18 | Figure 19 | Figure 20 | Figure 21 |
An example of an invalid situation ( Fig.22).
Abazhur Group specializes in the implementation of diverse construction projects based on EPC / EPCM contracts ... But for those who are in search and do not yet know what EPC and EPCM are, we offer a collection of materials that, we hope, will be of help to our Partners and clients when work with such relatively new instruments for domestic practice as EPC-, EPC(M)-contracts.
Structuring, conclusion and execution of EPC and EPC(M) contracts
Abazhur Group specializes in the implementation of diverse construction projects based on EPC / EPCM contracts, as well as other construction contracts with individual conditions. , applies system solutions in construction using BIM modeling, creates building projects that achieve low capital intensity.
EPC/EPCM contracts are the most common type of contracts in the construction industry.
When choosing one form or another, it is important to remember that the type of contract can lead to a significant change in the level of costs and risks that are associated with the construction of large and large structures. The level of costs is proportional to the risks assumed by the customer. With the reduction of commercial risks taken by the owner, the costs of building the facility and its management increase. In any business, this is logically confirmed by the risk-reward link.
The obligations assumed by the general contractor most often include the provision of four types of services:
- Engineering– survey work, project creation, documentation approval;
- Procurement– selection, purchase and supply of equipment and materials necessary for the performance of all works;
- The construction of the object (Construction)– construction, assembly and commissioning;
- Management of all construction processes (Construction Management).
Contract strategy in the implementation of large construction projects
Reducing construction time is often possible due to the fact that the EPC contractor, being the only person responsible to the customer, can develop and issue design and working documentation in parallel with the purchase of materials and equipment, as well as the implementation of construction and installation works.
for example, the EPC contractor may not wait for the development and approval of all project documentation in order to start contracting equipment for a long manufacturing cycle.
The effective use of parallel design in a number of cases makes it possible to seriously reduce the overall construction time. This is especially true for some gas projects, in particular associated petroleum gas processing/treatment projects, where there may be a peak in production, by which time a gas treatment plant must be built, otherwise the overall profitability of the project is seriously impaired. In such cases, the use of the EPC model of project implementation is justified, which, despite the higher cost, allows the construction to be completed in a shorter time.
Each contract strategy is a "traditional" model of managing the forces of the customer and the EPC model has its own strengths and weaknesses. For comparison, we provide tables that systematize the negative and positive aspects of each strategy.
EPC(M)-contract
The EPC(M) structure is a contractual solution that, in terms of risk sharing, lies in the middle between the multi-lot and EPC contract models. It should immediately be noted that there is no single and unambiguous understanding of what is considered an EPC (M) contract. Such an agreement may be understood, for example, as a situation where the EPCM contractor acts solely as a consultant and does not enter into any subcontracts on its own behalf.
Similarly, an EPC(M) contract can be called a full cycle general contract, but in which the price is determined on the basis of an “open book” (open book) or “reimbursement” (cost + fee, reimbursable)*. The complexity of the terminology is also introduced by the fact that none of the leading international organizations (FIDIC, ICC Orgalime) has issued a proforma of the EPC(M) agreement.
* In our opinion, it is more correct to call such contracts
EPC open book and EPC reimbursable or cost plus fee respectively
EPC(M) is the English abbreviation for Engineering Procurement Construction Management. At the same time, the correct translation of this abbreviation into Russian is "Design, Supply, Construction Management". In the EPC(M) model, the word management most often refers specifically to construction in the narrow sense of the word, i.e. to perform construction and installation and other works on the site.
Subject to the previously made reservations about vagueness in terminology:
An EPCM contract is most often understood as such a structure when the EPC(M) contractor, on its own or by a subsidiary company, carries out design, independently contracts equipment and materials, but in terms of construction and installation works, it only manages, i.e. does not hire construction and installation contractors on its own behalf, but only on behalf of the customer manages the contractors hired by the customer.
The fundamental difference between the EPC(M) contract and the EPC contract is that the EPC contract is an agreement on the "acceptance of responsibility and risks"
By entering into an EPC contract, the customer largely shifts the risks and responsibility to the EPC contractor which must provide this responsibility with liquid property. The EPC(M) contract is a professional services agreement the customer "buys" competencies, the responsibility of the EPC(M) contractor for the timing and budget of the project is absent or negligible in comparison with the cost of the project and, therefore, is of an exclusively stimulating nature.
There are various options for structuring the price in the EPC(M) contract, but it is never firm. Often the price is a combination of time rates (for those functions that the EPCM contractor performs personally - design, procurement management, construction management) and the "open book" principle.
This principle means that
- subcontracting is carried out in a transparent way for the customer and with the participation of his representatives;
- the contractor discloses the structure of its own overheads, as well as the amount of the expected profit, and such overheads / profits are either fixed at a certain amount or added as a percentage surcharge to the cost of each supply contract.
As already noted, the liability of the EPC(M) contractor is very limited and more closely resembles the liability of a consulting engineer (who is only responsible for the dishonest or incompetent provision of his own services) than the liability of the general contractor.
At the same time, quite often in EPC(M) contracts there are incentive mechanisms for the contractor using the principles bonus/malus (so-called gain sharing / pain sharing).
for example, the contract may provide that when the facility is put into operation at an earlier date, the contractor receives additional remuneration; in case of delay, the contractor, on the contrary, loses part of the profit.
Similarly, incentives can be built in relation to the total: the parties can set a certain target budget, and if, by effectively managing the construction, the contractor achieves savings, then such savings are divided between the parties in an agreed proportion. However, the EPC(M) contractor, when agreeing on a bonus/malus, is usually not ready to risk all the reward and therefore this mechanism does not give the customer complete comfort in terms of the cost and construction time, but is only aimed at creating a material interest in the contractor in the successful implementation of the project .
One of the advantages of the EPCM contract compared to the EPC model is the important fact that the tender for the selection of the EPCM contractor can be prepared and conducted much faster than the tender for the award of the EPC lumpsum contract. The fact is that in the first case, the customer is required to have a lower level of certainty regarding the scope of work, delivery boundaries and risks; and the contractor only needs to prepare a quotation for time rates, overheads and own profits - he is not required to prepare a firm quotation for the total cost of the project.
When tendering according to the EPC lumpsum model, on the contrary, the customer needs to prepare detailed terms of reference and requirements (if the level of elaboration is insufficient, contractors may either refuse to submit proposals with a fixed price at all or assess the risks in a very large amount); likewise, the contractor needs an order of magnitude more time to prepare a proposal with a fixed price that takes into account all the risks.
Modern construction methods, high quality materials and technologies, building control and general contractor functions, industrial and commercial buildings, installation of prefabricated structures. Construction of objects of any complexity!
Terms:
EPC Contractor- this is the one that performs the bulk of the work of the investment project for a fixed price and assumes all the risks of its implementation from the moment of design and until the transfer of the finished object to the customer (including the fulfillment of warranty obligations), for which he is financially responsible to the Customer.
It is used, as a rule, in those projects where it can estimate the amount of its expenses, as well as the degree of risks, with a sufficient degree of accuracy.
The EPC contract involves that the EPC contractor performs the bulk of the work on its own, therefore no special remuneration for organizing and managing the work of involved lower-level counterparties.
EPCM contractor may enter into contracts with subcontractors on its own behalf or manage contracts concluded by the customer with specific contractors.
The EPCM contract provides and the total cost of the project, taking into account the remuneration of the EPCM contractor, and a fixed term for putting the facility into operation, achieving the main technical parameters of the facility. The EPCM method (approach) allows you to manage the project, and not specific works. Specific work is carried out by professionals. The task of the EPCM is to assess the required properties (capabilities, professionalism, resources, etc.) of the selected contractors/suppliers, to correctly distribute work and areas of responsibility between them. Further - to coordinate their actions, resolve controversial issues, plan the general scheme of the project, change plans in case of critical changes with minimal consequences, and then with all the stops.
The world practice of implementing investment projects highlights EPC and EPCM contracts as the most promising strategies for the implementation of complex industrial projects, which account for about 80% of projects being implemented.
For more details, read the publication prepared.
If you have any questions or comments, you can - all of them will be gratefully considered.
event-driven process chain.The purpose of EPC is the planning and description of workflows, the lower (operational) level, business processes. The main elements for building diagrams are events and functions. Business processes, in the EPC diagram, are depicted as sequences of alternating events and functions.
Scope of EPC
The EPC diagram is a standardized graphic diagram for modeling business processes, applicable for:
- Modeling and documenting business processes as is (as is)
- Description of possible improvements to existing business processes (to be)
- Identification of all participants in the process
- Identification of all information systems, resources and documents involved in the process
To get a better idea of the EPC diagram, we advise you to visit the links:
Introduction to EPC
The link leads to an introduction to the EPC. Suggest to visit the link first.Elements and Structure of EPC Charting
The link leads to the description where the most important graphical elements of the diagram are presented. The presentation of the elements and their use is perfectly structured, it will be very convenient for you to navigate.Examples of rules for constructing EPC diagrams
The link leads to a document where examples of diagramming are described. P.S. In this case, we are only interested in the information presented in the fourth chapter from page 86.
Other useful materials:
- The link leads to a collection of training materials on the ARIS methodology.
Every thing is a form of manifestation of infinite diversity.
Kozma Prutkov
Introduction to eEPC notation
Currently, there are many different principles of graphical representation of business processes, called notations. Why are there many? This question has been asked for decades by everyone who is faced with the need to describe business processes. Let's look at the reasons. There are three (in my opinion):
- -Miscellaneous tasks. Not all notations are equally convenient for solving various problems. For example, a notation can be convenient for a top-level business process and not at all convenient for describing a workflow.
Different developers of such notations. At different times, different developers tried to come up with new principles for describing circuits. They did this out of good intentions, when in practice they encountered a situation where the notation they used could not reflect the necessary subtleties (or not clearly). Sometimes, in the process of evolution, such notations have become, as it were, parallel, i.e. look different, but solve the same tasks.
The desire to stand out. This is when, for unknown reasons, a new notation suddenly appears, which does not have anything outstanding in itself, but, for some reason, is promoted by its creator as the most perfect know-how. This is still happening.
The purpose of this article is not to consider all kinds of notations (I deliberately do not name them), but to dwell on a detailed description of the notation that I chose for my projects in the process of a long search for the most optimal option.
If anyone is interested in knowing what other notations are and what they are used for, I plan to do this in another article, which will be called "Let's talk about notations", but this is still in the plans.
It's time to start our story about a very interesting, simple and practical eEPC notation (in translation: an extended description of the event chain of processes). In its literal translation, the main purpose is also revealed: a description of the chain of business processes. The main "trick" of the notation is in its principle of "eventfulness", which we will consider in detail.
What are the advantages of eEPC notation:
- Firstly, this is not quite a pure notation. Those. if in some notations there is a rigid set of elements and rules for their use (otherwise everything will get confused), then the eEPC principle allows you to add your own elements. How is it provided? Of course, there is a certain "core" around which everything is built, i.e. a set of clear rules by which the scheme is built and by which it is then read. In addition, you can add your own element, include the rules for its use in your own corporate standard (to exclude amateur activity that can confuse the scheme and complicate its readability) and that's it! This is a very important point. In addition, you can set any other restrictions and rules in your corporate standard.
- eEPC contains elements of logic. This allows you to build schemes with conditions that are necessary to describe the activity (“if the contract is agreed, then ...., otherwise ...”)
- The simplicity of the elements allows you to draw diagrams both in software products and in any other way, even on paper, you will not get confused.
- eEPC is so easy to learn and understand that it can be used in real life, not just gathering dust in a closet. It will take about 2 hours to learn the rules (if the student wishes).
Of course, like everything in this world, it has its drawbacks. But rational use reduces them to a minimum. The main drawback, in my opinion, is the fact that if we use simple tools (ie programs for drawing diagrams, and not for modeling business processes), then we do not have a single database of objects. In addition, it is difficult to control inputs and outputs (it is necessary to control them, that is, to come up with a way of such control, if necessary). But, on the other hand, the use of complex business process modeling tools costs quite impressive amounts, and the project with their use is measured in millions. And so we have a very economical and understandable tool. To be more precise, this shortcoming refers specifically to the method of description I am considering, i.e. using MS Visio or similar software. If you use specialized systems for describing business processes that support object databases, then this drawback can be avoided. Well, it's time to start...
The main "core" of the eEPC notation
As I already mentioned, in the literal translation of the abbreviation eEPC lies the concept of eventfulness. This is a very important point on which the whole principle of constructing a circuit is built. So, there are two key concepts: "Event" and "Function". When someone first tries to draw their process in the form of an eEPC diagram, the question often arises, what is the difference between an event and a function? This must be clearly understood, otherwise you will get an unpredictable result. So: an event is a fact of accomplishing something, and it does not have a duration in time, or this time tends to zero (or does not matter). Moreover, the event always causes the need to execute the function, and the execution of the function always ends with the event. Let me explain with an example. The phone rings. The manager picked up the phone. In this case, "The phone rings" is an event. Phone conversation is a function. The conversation is over (hung up) - again an event. Thus, an event chain is observed: Call - conversation - end of the call. And the end of the call will most likely require the execution of a new function: recording the result of the call, etc.
Let's try to draw it. First you need to figure out how the "Event" and "Function" elements are displayed.
These two simple elements form the basis of the rules for describing business processes in the eEPC notation. I think I need to say a few words about the colors used. If you came across the description of processes in other notations, as a rule they were black and white. And this is correct, there should not be an explicit dependence of the content on the color, because the diagram can be drawn with a pencil on paper, printed on a black and white printer, etc. In this case (in the eEPC ntation), it has historically developed that the elements have certain colors. Not to say that it was necessary, but the habit is developed, and the perception in electronic form is better - you can immediately see what is what. These colors can be considered as a recommendation. Why are they like this? I'm not sure exactly, but it seems to me that ARIS, when it made support for the eEPC notation in its product, gave them such colors, they "took root". By the way, sometimes this notation is also called "ARIS", "ARIS EPC", which is not entirely correct, because ARIS did not invent this notation, but made support for it in their business process modeling program. In general, I recommend using colors. The main thing is that the very form of the elements should not be the same (i.e. differ only in color), because in black and white, this can be confusing. There are other rules that allow you to give "slenderness" to the eEPC diagram, we will talk about them.
So, there is an event, there is a function. How are they related?
We see that event1 led to the need to execute a certain function, which ended with event2. If applied to the example with a phone call, then it will be like this:
The link event - function - event is usually displayed from top to bottom in one line or from left to right. The direction of the chain is indicated by connecting lines with arrows. In order to make the scheme more visual, the notation provides a few more standard elements:
- Position (performer). The one who performs this function
- Information. Any information used to perform a function other than documentary information. For example, a phone call, instructions for performing an operation, etc.
- Document. The "Document" element is designed to display information media (paper or electronic). Those. presentation of information in a certain structure.
- Program (application). The software used to perform the function.
All other elements are auxiliary, and are practically not regulated by the requirements of the eEPC itself. However, there are no barriers to adding your own elements. The main thing is to fix this in the internal standard so that there is a common understanding of how they look and why they are used. Such an extension does not violate the requirements, if the event-function-event connection is not violated, and is intended only to improve the perception of information or adapt the description rules to some industry specifics. I added my own set of elements, which I will discuss below.
You still need to figure out how the considered elements should be located. All of these elements must somehow be related to the function. It's a general rule that no element other than a function is associated with an event. Those. all these elements must be connected with arrows to the function. As for the arrows and their directions: it is generally accepted that if there is no direction for transmitting information, then just a line is displayed instead of an arrow. If information enters (enters the input), then the direction of the arrow is from the object to the function, if it exits, then vice versa.
A few more words about the location of these elements on the diagram and we can redraw our diagram, specifying the execution of the call processing function. There are no strict requirements for the arrangement of elements, but it is customary to display them in all diagrams in the same way (for the uniformity and harmony of the diagram). To unify the external view of graphic diagrams of business processes, such rules must be fixed in the internal standard and followed. A little later I will give some recommendations about this. Now let's redraw our diagram:
We see that the operator is processing an incoming call, acting in accordance with the rules for processing incoming calls and using the CRM program for this. Neither incoming nor outgoing documents are used.
As I already mentioned, one of the strengths of the notation is the elements of logic. At the same time, this is one of the most difficult moments to understand. Therefore, first I will give an example, and then we will separately deal with the elements of logic.
Let in our example be like this: if the client is interested, the sales manager conducts further work with him and puts up a commercial offer, which he sends by mail using the MS Outlook mail client. If there is no interest, then the call processing is completed. In real life, it would be nice to use call termination rules, but this is me, by the way, while we simplify it. Here's what happens:
Elements of logic in eEPC notation schemas
The elements of logic are simple, but there are some peculiarities and rules for the scheme to be logical and unambiguously interpreted. The most important rule to adhere to 100%: logical decisions can only be made when a function is executed. Those. after some event there can be no branching. Why? Because in this case it contradicts the very concept of an event - it is simple and instantaneous, without execution time. For example, if the phone rang, and a person is sitting thinking whether to pick up the phone or not, theoretically this will already be a function where he makes a decision. But in practice, including from common sense, he violates the rules for processing calls, tk. he is paid a salary to process these calls, and there is nothing to argue here (in general, as shown in the diagram).
In total, 3 elements of logic are distinguished:
- I. When two or more events happen at the same time;
- OR. When one or more events can occur, but at least one must occur;
- EXCLUSIVE OR. Either one or the other. Those. two options are not possible at the same time.
As you can see, there are two options for graphical representation of logic elements. They are no different, completely different. I brought both of them, because. In practice, both options can be seen in various sources. Which one to use is up to you. I like the first one more.
Now we need to deal with the use of logic elements. First, let's look at the options encountered, then move on to an example. Let's analyze each element separately.
Logical element "AND". When a function requires multiple events to execute at the same time:
Example: If the reporting period is closed (event 1) and the deadline for submitting a report to the manager (event 2) has come, the employee prepares a monthly report.
The connection of elements, if several events occur during the execution of the function:
Example: Some work with a customer has been completed. Two events were recorded simultaneously: mutual settlements were reconciled (event 1), the act was signed (event 2). In practice, this is rarely used. As a rule, if many actions are combined in one function
Connection of elements, if during the execution of several functions, an event occurs:
Example: The storekeeper collected the order (function 1), the operator wrote out the documents (function 2), the goods are ready for shipment (event).
Connection of elements, if the occurrence of one event leads to the execution of several functions:
Example: A consignment of goods has arrived (event). At the same time, the shipment of goods previously ordered by customers and the placement of the remaining goods in the warehouse begin.
Logical element "OR".
Connecting elements if one of the events can cause the function to be executed:
Example: An application received by phone (event 1) or an application received by e-mail (event 2) will result in the need to process it.
Connecting elements if one function can fire at least one event:
Example: An invoice has been prepared and sent to be sent to a customer. The invoice could be sent by mail (event 1), by fax (event 2).
Logical element "EXCLUSIVE OR".
Connecting elements when one and only one of the events is needed to execute a function:
Example: A customer came to the store in person (event 1) or made an order via the Internet (event 2). You need to ship the goods (function 1).
Connection of elements, if at least one of the following events occurs as a result of the function execution:
Example: A decision is either made or not.
Connection of elements if the event occurs after one and only one of the functions has been executed.
Example: Goods were delivered (event 1) either by own transport (Function 1) or by a transport company (function 2)
The correct application of logic elements requires some practice. But it's not difficult. It should be noted that not all of the considered combinations are widely used in practice (in general, this is determined by the analyst's way of thinking). Try to apply elements of logic in practice. If there are difficulties, write to me, I will try to help.
Extending Notation with Your Own Elements
As I said, eEPC is not exactly a notation, but description rules. And these rules do not prohibit adding your own elements to the scheme. The main thing is that these elements are understandable, and there is a document where such element extensions are fixed. For example, I use the following additional elements that have emerged gradually in the process of describing real processes for various tasks, from a simple description to setting tasks for automation.
Data file. Used when a data file is created as a result of an operation, or a file is used to perform an operation.
Database. Used to describe information flows between automated systems.
File cabinet. Used to display a paper filing cabinet or archive.
material flow. Used to indicate the incoming and outgoing material flows, as well as the resources consumed during the execution of the process. The material flow is displayed to the left of the accompanying documents.
information cluster. Used to denote structured information (entity representation). The diagram can be used to refer to documents generated programmatically using custom applications. In this case, the "Cluster" element is located to the left of the corresponding document. Those. indicates that the user not only created a paper document, but also created an instance of it in the program.
Conventions on the rules for placing shapes on a diagram
The eEPC notation itself does not impose strict requirements on the arrangement of elements relative to each other, although it is customary to draw a diagram from top to bottom or from left to right. If this is not unified in the case of the work of several specialists, then a kind of “vinaigrette” may turn out. To avoid this, it is recommended to develop and approve your own rules for the arrangement of elements. I adhere to (and recommend) the following rules:
- The sequence of events and functions is arranged from top to bottom (better) or from left to right (if there is not enough space);
- Elements denoting performers are located to the right of the functions;
- Incoming documents at the top left of the functions; arrow direction from documents to function;
- Outgoing documents at the bottom left of the functions; arrow direction from function to documents;
- The "Information" element is located at the bottom right of the function. If there is not enough space, an arbitrary arrangement is allowed, as close as possible to the function;
- The "Application" element is located at the top right of the functions. (if file storages that are not reports are used for this, they are displayed similarly). Communication without an arrow.
- Elements "Database" and "Card file" are located arbitrarily;
- The "Material flow" element is located to the left of the documents accompanying it with reference to the document by a line without an arrow;
- The "Cluster" element, when used in combination with the "Document" figure to designate a document in electronic form, is located to the left of the corresponding document.
For example: Payroll Calculator calculates wages based on the documents "Brigade Outfit" provided to him. At the same time, he is guided by the document "Regulations on wages", the calculation is made in the program "1C: ZiK". The result of the calculation is the document "Vedomosti".
Identifying Elements in a Diagram
As you know, a competent approach to the description of business processes involves their identification, i.e. when each process has its own code name. Accordingly, individual functions within a process also have their own names and identifiers.
Figures "Document" and "Function" are subject to mandatory identification in the diagram.
The document is identified by indicating the code of the report or document in the upper left corner in accordance with the register. Documents received from suppliers of goods and services (incoming) are identified only by name.
A function is identified by indicating the ordinal number of the function for a given process group. Those. the function number always starts with the process group code. The issues of identifying process groups are beyond the scope of this article, we will consider them separately. Moreover, you should learn how to identify processes before you begin to describe them, otherwise there may be a desire to describe all the activities of the company in one diagram, as they sometimes try to do.
Therefore, now I will only show with an example how this can be represented in a diagram. Let's go back to the call handling example. Let's assume that we have assigned the code "04" to the sales department, the code "VK" to the process of processing the incoming contact. Then the scheme will take the following form (identification is highlighted in red for clarity). The document code at the same time indicates the serial number of the document in the general register of documents (we will also consider this separately when we get to the survey of the document management system).
Feedback display
When building models, it often becomes necessary to cycle through the process according to some condition or the need to display the activities of decision makers. In this case, we are talking about feedback. To display control feedback, the principle of "direct inclusion" in the process of an additional control function is used, followed by branching (using the XOR logic element). For example:
Text description of processes
No matter how hard we try to display the business process on a diagram, it will not be possible to achieve full detail, otherwise you can get bogged down in endless chains of elements and conditions. To avoid this, as well as to add information to the description of the process that cannot be displayed graphically, the description is supplemented with text accompaniment. For this, various text templates are developed, which are filled in during the description process. The forms of such templates can be different, include separate sections describing inputs and outputs, resources consumed, software used, etc.
In the simplest case, a business process description template might look like this:
| Buisness process: | Handling an incoming contact | 04.VK |
|
Process functions: |
||
| Name | Description | Number on the diagram |
| Incoming call handling | When an incoming call is received, the operator processes the call in accordance with the rules for processing incoming calls. Identifies the interest of the client, provides information about the services | 04.VK.01 |
| Formation of a commercial offer | If there is a client's interest, the operator transfers the contact to the sales manager. The sales manager prepares a commercial offer and sends it to the client by e-mail | 04.VK.02 |
|
Process indicators: |
||
| Name | Evaluation/measurement method | |
| Number of failures | database statistics | |
Such important topics as collecting information, highlighting business processes, decomposition, and highlighting indicators remained outside the scope of this article. We will definitely study these issues in future issues.
- How to order a Sberbank bank card with an individual design A bank card with your own image
- How to open a special account in Sberbank business online
- What is a savings account in Sberbank?
- Day of employees of Sberbank of Russia
- Was the page helpful to you?
- How to find out a credit history in Sberbank online
- Forward contract (Forward)