Home Hygiene A methodology for modeling business processes of an enterprise providing road transportation services in the MS Visio program using the example of the transport company EcoTrans LLC.

Hygiene

A methodology for modeling business processes of an enterprise providing road transportation services in the MS Visio program using the example of the transport company EcoTrans LLC.

Training is conducted on personal computers.

The course is dedicated to describing business processes using the popular business graphics editor Microsoft Visio. which is easy to learn and at the same time allows you to quickly and efficiently create business models.

During the training, the most common methodologies (notations) for modeling business processes supported by Visio are reviewed and practical skills in constructing graphical process diagrams in MS Visio are developed.

The course program is aimed at specialists involved in the description, analysis and optimization of business processes.

Basic Microsoft Visio functions necessary for drawing business process diagrams.
- Working with chart sheets. Using shape sets. Working with sample figures. Adding shapes to a diagram. Drawing dynamic connecting lines between shapes. Gluing connecting lines to shapes. Dynamic and static gluing. Set snapping and gluing options. Using the Auto Connect feature. Changing the size and position of shapes. Change the size and position of the shapes text box. Shape handles: selection, rotation, text field, control, connection point. Formatting shapes. Copying shapes and their format. Automatic alignment and placement of figures. Grouping shapes and combining them into containers. Scaling, changing the size and appearance of the diagram page. Configuring chart page parameters and printing.
Basic rules for constructing process diagrams.
- Building a network of top-level processes. Process decomposition. Determining the objectives of the process description. Definition of process boundaries: inputs, outputs, suppliers and consumers. Construction of process diagrams of upper and lower levels. Rules for displaying process execution logic. Rules for using events and logical operators. Displaying responsible and executing processes.
Methodologies and standards for describing business processes supported by Microsoft Visio.
- The most commonly used methodologies and standards (notations) for describing business processes, supported by the Microsoft Visio software product. IDEF0 process diagram. A typical process flow diagram. Process flow diagram with Swimmer Lanes. ARIS VAC (Value Added Chain Diagram) process diagram. ARIS EPC (Event driven Process Chain) process diagram. BPMN (Business Process Model and Notation) process diagram. Comparative analysis, advantages, disadvantages and areas of application of notations. Displaying manual and automated processes on a diagram. Setting time and cost parameters for processes, time and quality requirements and other necessary data.
MS Visio service functions as applied to the task of describing business processes.
- Decomposition and installation of hyperlinks to nested business process diagrams. Set and edit protection for diagram shapes. Set up chart shapes to link to various external files, documents, and resources. Creating and editing attributes of diagram objects. Adding and editing property fields (attributes) for shapes. Creating and editing shape sets. Generating reports based on graphical charts. Generating an HTML publication of a graphic diagram.

Vladimir Repin

CEO Vladimir Repin Management LLC

Member of ABPMP Russia

Management Consultant

Business trainer

Candidate of Technical Sciences

The article discusses the issues of choosing a notation for describing processes for the purpose of subsequent regulation. Frequently used Work Flow notations are compared, such as: “Simple flowchart” in MS Visio, “Procedure” in Business Studio, ARIS eEPC notation and others. When comparing notations, the main focus is on creating process diagrams that are simple and understandable to organizational employees.

For business analysts of companies, the theses discussed in the article are a serious reason to think about how effective the approaches they use to developing graphical diagrams of organizational processes are.

Introduction

One of the most important goals of creating graphical process diagrams is their subsequent use in the organization’s regulatory documents. These schemes, as a rule, are used by employees who are not trained in complex notations, do not have system analysis skills, etc. The simplicity and clarity of the schemes are very important to them. Complex, confusing diagrams containing many different symbols are poorly understood by people, which makes them difficult to use in practice. Therefore, for practical purposes, it is important to correctly select and use the notation (methodology) for describing processes. What criteria should be used to choose such a notation? How to compare different notations with each other? Let's look at several examples of describing a business process using popular notations and try to answer these questions.

Comparison of notations

For comparison, the following process description notations were chosen:

“Simple flowchart” (displaying the movement of documents, using the “Solution” block);
“Simple block diagram” (without displaying the movement of documents, without using “Solution” blocks);
"Procedure" of the Business Studio system (one of possible options representation);
ARIS eEPC.

A simple and intuitive process was chosen as a test case. The results of describing this process are presented in Fig. 1-4.

Rice. 1. Process diagram in the “Simple flowchart” notation in MS Visio (with the movement of documents, using the “Solution” block)

In the diagram presented in Fig. 1, the sequence of process operations over time is shown using thick arrows, and the movement of documents is shown using thin dotted arrows. Solution blocks are used in a classic way. They display information (questions) on which the subsequent course of the process “depends”. This approach to using “diamonds” is very common. But in fact, the entire logic of decision-making and the formation of certain outputs (documents) should be contained within the operations of the process. If you think about it, the value (meaning) of drawing these “diamonds” is not obvious. What kind of objects are these: process operations, events? It seems to be neither one nor the other. These are rather operators for making a decision based on some condition. But we are developing a process diagram for people, and not writing a computer program in a special language. In a computer program, a “diamond” would be a full-fledged operation for comparing conditions, etc. But the process diagram needs to show real objects - processes performed by people, documents, information systems, etc. Think about whether it is correct to show “diamonds” separately from process operations on the diagram? Instead you can:

Describe the logic of decision making in the form of a sequence of operations on the diagram of the process under consideration;
Describe the logic in the form of a diagram of the steps of the corresponding subprocess, moving to the next level;
Describe the logic in text (in the text attributes of the operation) and subsequently display it in the process execution regulations.

Let us formulate the “pros” and “cons” of the method of using “diamonds” discussed above (Fig. 1).

"Simple flowchart" in MS Visio (with document movement, using the "Solution" block)

In Fig. Figure 2 shows an example of the same process, only described without the use of “Solution” blocks and documents. It is easy to check that this diagram has 24 fewer graphic elements than the diagram in Fig. 1. Scheme Fig. 2 looks much simpler. The graphic elements do not dazzle the eyes, and from the point of view of information content, this diagram is quite understandable and accessible to the end user. If for each process operation you describe the requirements for its implementation in text, then by combining tabular and graphical presentation forms, you can quite adequately describe the procedure for executing the process for company employees.

Rice. 2. Process diagram in the “Simple flowchart” notation in MS Visio (without document movement, without using the “Solution” block)

“Pros” and “cons” of a graphical representation of the process in the form presented in Fig. 2 are shown below.

"Simple flowchart" in MS Visio (without document movement, without using the "Solution" block)

In general, the use of diagrams in a format similar to those presented in Fig. 2 is convenient for both developers and employees working on these schemes.

In Fig. Figure 3 shows a process diagram generated in the “Procedure” notation of the Business Studio modeling environment. The scheme has several features. Firstly, the “Decision” blocks are used in a non-standard way - not as a graphic element to display a question and branching, but as a full-fledged process operation associated with decision making. In Business Studio, the “diamond” has almost all the attributes of a full-fledged process, but cannot be decomposed (perhaps the system developers will make this possible over time). Using a “diamond” (instead of a quadrangle) makes the diagram more visual. At the same time, you can enter any text information into the “diamond” attributes: description, beginning, completion, deadline requirements, etc.

The second feature of the process diagram presented in Fig. 3, is the application of arrows. To display a sequence of operations, you can use an arrow with a single tip - the "precedence" arrow. You can use a double-headed arrow to show document movement. However, in Business Studio you can get by with using only one type of arrows - “precedence” arrows. At the same time, the required number of documents that are defined in the directory of activity objects can be linked to named arrows.

This approach makes it possible:

Significantly reduce the number of graphic elements on the process diagram, and at the same time;
Display in the process regulations the necessary information about incoming and outgoing documents.

Thus, without cluttering the diagram with unnecessary elements, we can nevertheless fully describe the process and upload all the necessary information into the regulations.

The fact that the name of the arrow does not depend on the documents that are attached to it allows you to name the arrows on the diagram in the most understandable and convenient way for employees. For example, a set of specific documents can be linked to the precedence arrow “A set of reports has been prepared.” The name of the arrow in this case indicates to the performer the event that completed the previous operation called “Generate collection report for the day.” (Note that in the methodology of the STU company, the arrow after the process operation is an entity, not an event. After the “Decisions” block, you can show possible results solutions).

Rice. 3. “Procedure” of the Business Studio system (option with non-traditional use of “Solution” blocks)

“Pros” and “cons” of a graphical representation of the process in the form presented in Fig. 3 are shown below.

“Procedure” of the Business Studio system (option with non-traditional use of “Solution” blocks)

When using Business Studio, the Procedure notation can be used in slightly different ways. The author of the article is inclined to the approach presented in Fig. 3.

In Fig. Figure 4 shows a diagram of the process under consideration, developed in the ARIS eEPC notation. Note that some process operations did not fit on the diagram. This partial diagram of a simple process, written in ARIS eEPC notation, contains four logic statements and eight events! The person reading the diagram must be able to correctly interpret all of these logical operators. Without special training and some skills in reading such diagrams, an ordinary employee is unlikely to be able to understand the logic of the process in question without a detailed text description or the help of a qualified business analyst.

Note that the process diagram in the ARIS eEPC notation takes up significantly more space than the diagrams presented in Fig. 1-3. The complexity of forming such a scheme is also significantly higher.

Rice. 4. Process diagram in ARIS eEPC notation (built in Business Studio)

Process diagram in ARIS eEPC notation (built in Business Studio)

In general, if you are not going to buy SAP R/3, then choosing and using the ARIS eEPC notation is not, from the point of view of the author of the article, the optimal solution. It is worth paying attention to notations for describing processes that are more visual and intuitive for performers. However, some may find the ARIS eEPC notation more visual and understandable. To a certain extent, this is a matter of taste.

Description of the process for subsequent automation purposes

It is interesting to consider the above example of a business process description if it is presented in BPMN 2.0 notation. This notation is intended to describe “executable” processes, i.e. processes that the BPM system supports.

Your opinion about using BPMN 2.0. A. A. Belaichuk, General Director of the Business Console company, shares:

"In Fig. Figure 5 depicts the same process in BPMN notation. As we can see, this figure is similar to Fig. 1: in BPMN notation, tasks are depicted as rectangles, forks as diamonds, and data as an icon similar to a document. Control flows are solid lines, data flows are dotted.

It should be taken into account that this diagram only involves small part BPMN notations: only one type of fork out of 5 available in the palette, one type of task out of 8. In addition to a wider palette, this notation is distinguished by the ability to model not only an isolated workflow, but also several processes interacting with each other through messages or data. In addition, this notation is more strict: it defines not only icons, but also the rules by which they can be combined with each other. The need for such rules is dictated by the fact that the BPMN notation is focused not only on the fact that people will read it, but also on direct execution by special software— “engine” of the BPM system.

At the same time, as this example shows, when using a limited subset of the palette, BPMN turns out to be no more complicated than a conventional flowchart. Well, for those who want to master BPMN professionally, we recommend specialized training bpmntraining.ru.”

Rice. 5. Process diagram in BPMN 2.0 notation

Life practice

In Fig. Figure 6 shows a fragment of a process diagram developed by business analysts of a very specific company in the notation they invented. The diagram is built using the principles of the “Simple flowchart” - the “Solution” block is used in its classic version. In addition, the diagram shows many other symbols used in a non-standard way.

Rice. 6. Examples of a process diagram for one of the companies

When forming the diagram Fig. 6, business analysts obviously “struggled” for clarity and maximum understandability for the average user. They sought to minimize, or even eliminate, textual commentary on process diagrams. The performers were simply printed with an A3 format diagram, upon reading which everything immediately became clear: what to do, how, what documents to use, etc.

The scheme under consideration is not, of course, an example of simplicity and clarity. But it was formed to convey maximum useful information to those involved in the process.

conclusions

So, it is obvious that when describing processes you need to strive for simplicity and clarity for employees.

The use of complex, formalized notations when describing processes leads to:

Difficulties in using (interpreting) diagrams by ordinary employees;
The impossibility (difficulty) of organizing work to describe processes by employees of departments who have not undergone special training;
A significant increase in the labor costs of business analysts for the formation of schemes;
Additional difficulties when documenting circuits (large volume, etc.).

Therefore, you should not clutter the process diagram with various graphic elements. But if you use them, it is better that they carry useful information for employees, rather than being simply a consequence of the formal application of modeling notations.

http://finexpert.ru/ - communication environment for professionals http://bpm3.ru/ - processes, projects, efficiency

Workflows are an important and almost mandatory component of a SharePoint portal; they are the basis of document flow and many other business processes. It's not surprising that there are systems like Nintex that try to extend and complement the capabilities of standard workflows.

From my experience with Nintex I can say that this system is not without its drawbacks: high cost, periodic errors, general slowness of the system (although this is typical for all SharePoint) - all this forces me to use the standard workflow mechanism. However, Nintex has important advantage- visualization of the diagram and current state process. Thanks to this, the creation of workflows is simplified, and they can be created even by people who are quite far from programming (content managers, business analysts, etc.). SharePoint 2010 has similar opportunity Create a workflow based on a visual diagram using Visio 2010 and SharePoint Designer 2010.

Create a diagram in Visio

Visio 2010 has a new template - Microsoft SharePoint Workflow (present only in the Premium edition of Visio). The diagram obtained from this template can be exported to Designer for further work.
So, open Visio and look for a template in the Flowchart category.

After opening the template, the elements of the diagram will be located on the left - conditions, actions, beginning and end (the screenshot shows only “quick” actions, in general there are many more of them):

Now we think through the logic of the business process and draw up a diagram using the necessary elements. For example, I made a simple business approval process:

there are 2 lists - “Inbox” and “Responsible”
in the “Responsible” list there are categories of requests (suggestion/question/complaint, etc.) and the corresponding responsible persons
user creates an item in the Inbox and specifies a category
the workflow finds the person responsible for this category and creates a task for him
the person in charge reacts to the task, and the status of the request in the Inbox list changes

Of course, it’s hard to perceive this in words, so I’ll immediately give you a ready-made workflow diagram:

There is nothing complicated in creating a diagram; you just need to imagine the logic of the business process. The labels for the elements are quite clear, the icons prevent confusion. After creation, export the process to a file for SharePoint Designer:

Binding a process to data in SharePoint Designer

Open Designer, connect to the desired site, go to the Workflows folder. On the ribbon, click the “Import from Visio” button and specify the file with the saved diagram. We write the name of the workflow and the list to which we bind it (in in this case- “Incoming”). Designer itself will generate the code and comments for it; all we have to do is indicate the fields from which to get the data (specifically, in this case, I had some minor problems due to the use of a Lookup type field, but usually everything is simple):

After finalizing the workflow, go to settings. We indicate there necessary condition launch (launch automatically when an item is created), and also check the “Show workflow visualization on status page” option (you need to activate SharePoint Server Enterprise capabilities on the site collection). This is exactly why it is worth creating workflows in Visio. Now let's go to the site, create any item in the Inbox list, go to the task list and complete the task, and then open the workflow status window:

So, we see a fairly nice workflow diagram, which marks all the completed stages. If the process had stopped at any stage (for example, it was waiting for approval from us), then this would also be noted on the diagram. Thanks to this, each user will be able to see at what stage of approval his request is.

Conclusion

As a result, I will cite the positive and negative sides using Visio to create workflows (in my subjective opinion).
Pros:

Easy to create, no need to be a programmer
The user can easily view and understand the status of the request

Minuses:

Requires SharePoint Enterprise Server and Visio Premium

When comparing notations, the main focus is on creating process diagrams that are simple and understandable to organizational employees.

Introduction

One of the most important goals of creating graphical process diagrams is their subsequent use in the organization’s regulatory documents. As a rule, these schemes are used by employees who are not trained in complex notations, do not have systems analysis skills, etc. The simplicity and clarity of the diagrams is very important to them. Complex, confusing diagrams containing many different symbols are poorly understood by people, which makes them difficult to use in practice. Therefore, for practical purposes, it is important to correctly select and use the notation (methodology) for describing processes. What criteria should be used to choose such a notation? How to compare different notations with each other? Let's look at several popular notations and try to answer these questions.

Comparison of notations

For comparison, the following process description notations were chosen:

“Simple flowchart” (displaying the movement of documents, using the “Solution” block);
“Simple block diagram” (without displaying the movement of documents, without using “Solution” blocks);
“Procedure” of the Business Studio system (one of the possible presentation options);
ARIS eEPC.

A simple and intuitive process was chosen as a test case. The results of describing this process are presented in Fig. 1-4.

Rice. 1. Process diagram in the “Simple Flowchart” notation in MS Visio (with the movement of documents, using the “Decision” block).

In the diagram fig. 1. The sequence of process operations over time is shown using thick arrows, and the movement of documents is shown using thin dotted arrows. Solution blocks are used in a classic way. They display information (questions) on which the subsequent course of the process “depends”. This approach to using “diamonds” is very common. But in fact, the entire logic of decision-making and the formation of certain outputs (documents) should be contained within the operations of the process. If you think about it, the value (meaning) of drawing these “diamonds” is not obvious. What kind of objects are these: process operations, events? It seems to be neither one nor the other. These are rather operators for making a decision based on some condition. But we are developing a process diagram for people, and not writing a computer program in a special language. In a computer program, a “diamond” would be a full-fledged operation for comparing conditions, etc. But the process diagram needs to show real objects - processes performed by people, documents, information systems, etc. Think about it: is it correct to show “diamonds” separately from the process operation on the diagram? Instead you can:

a) describe the logic of decision-making in the form of a sequence of operations on the diagram of the process under consideration;
b) describe the logic in the form of a diagram of the steps of the corresponding subprocess, moving to a lower level;
c) describe the logic in text (in the text attributes of the operation) and subsequently display it in the process execution regulations.

Let us formulate the “pros” and “cons” of the method of using “diamonds” discussed above (Fig. 1).

"Simple flowchart" in MS Visio (with document movement, using the "Solution" block)
"Pros"	"Minuses"
A visual display of the “logic” of selecting certain process outputs. Focusing the performer's attention on the decision point/process branching depending on the conditions.	Moving the decision-making logic “outside” the process operation (incorrect from the point of view of formal process decomposition). It is inconvenient to document the process (you have to duplicate the “diamonds” with text when creating a text description of the operation). The process diagram becomes information overload. "Diamonds" are often used too formally, without real need.

In Fig. 2. shows an example of the same process, only described without the use of “Solution” blocks and documents. It is easy to check that this diagram has 24 fewer graphic elements than the diagram in Fig. 1. Scheme Fig. 2. looks much simpler. The graphic elements do not dazzle the eyes, and from the point of view of information content, this diagram is quite understandable and accessible to the end user. If for each process operation you describe the requirements for its implementation in text, then by combining tabular and graphical presentation forms, you can quite adequately describe the procedure for executing the process for company employees.

Rice. 2. Process diagram in the “Simple flowchart” notation in MS Visio (without document movement, without using the “Decision” block).

“Pros” and “cons” of a graphical representation of the process in the form presented in Fig. 2. are shown below.

In general, the use of diagrams in a format similar to those presented in Fig. 2 is convenient for both developers and employees working on these schemes.

In Fig. 3. A process diagram is presented, formed in the “Procedure” notation of the Business Studio modeling environment. The scheme has several features. Firstly, the “Decision” blocks are not used in a standard way - not as a graphic element to display a question and branching, but as a full-fledged process operation associated with decision making. In Business Studio, the “diamond” has almost all the attributes of a full-fledged process, but cannot be decomposed (perhaps the system developers will make this possible over time). Using a “diamond” (instead of a quadrangle) makes the diagram more visual. At the same time, you can enter any text information into the attributes of the “diamond”: description, beginning, completion, deadline requirements, etc.

The second feature of the process diagram presented in Fig. 3., is the use of arrows. To display a sequence of operations, you can use an arrow with a single tip - the “precedence” arrow. You can use a double-headed arrow to show document movement. But it is in Business Studio that you can use only one type of arrows - “precedence” arrows. At the same time, the required number of documents that are defined in the directory of activity objects can be linked to named arrows. This approach makes it possible:

significantly reduce the number of graphic elements in the process diagram, and at the same time:
display the necessary information about incoming and outgoing documents in the process regulations.

Thus, without cluttering the diagram with unnecessary elements, we can nevertheless fully describe the process and upload all the necessary information into the regulations.

“Pros” and “cons” of a graphical representation of the process in the form presented in Fig. 3. are shown below.

Rice. 3. “Procedure” of the Business Studio system (option with non-traditional use of “Solution” blocks).

When using Business Studio, the Procedure notation can be used in slightly different ways. The author of the article is inclined to the approach presented in Fig. 3.

Rice. 4. Process diagram in ARIS eEPC notation (built in Business Studio).

Description of the process for subsequent automation purposes

It is interesting to look at the process diagram in question if it is described in the BPMN 2.0 notation. This notation is intended to describe "executing" processes, i.e. processes supported by the BPM system.

Your opinion about using BPMN 2.0. shares A.A. Belaichuk - General Director of the company "Business Console":

In Fig. Figure 5 depicts the same process in BPMN notation. As we can see, this figure is similar to Fig. 1: in BPMN notation, tasks are depicted as rectangles, forks as diamonds, and data as an icon similar to a document. Control flows are solid lines, data flows are dotted.

It should be taken into account that this diagram uses only a small part of the BPMN notation: only one type of fork out of 5 available in the palette, one type of task out of 8. In addition to a wider palette, this notation is distinguished by the ability to model not only an isolated workflow, but also several processes , interacting with each other through messages or data. In addition, this notation is more strict: it defines not only icons, but also the rules by which they can be combined with each other. The need for such rules is dictated by the fact that the BPMN notation is focused not only on the fact that it will be read by people, but also on direct execution by special software - the “engine” of the BPM system.

Rice. 5. Process diagram in BPMN 2.0 notation.

Life practice

In Fig. Figure 6 shows a fragment of a process diagram developed by business analysts of a very specific company in the notation they invented. The diagram is built using the principles of a “Simple Block Diagram” - the “Solution” block is used in its classic version. In addition, the diagram shows many other symbols used in a non-standard way.

When forming the diagram in Fig. 6, business analysts obviously “struggled” for clarity and maximum understandability for the average user. They sought to minimize, or even eliminate, textual commentary on process diagrams. The performers were simply printed with an A3 format diagram, upon reading which everything immediately became clear: what to do, how, what documents to use, etc.

The scheme under consideration is not, of course, an example of simplicity and clarity. But it was formed to convey maximum useful information to those involved in the process.

conclusions

So, it is obvious that when describing processes you need to strive for simplicity and clarity for employees.
The use of complex, formalized notations when describing processes leads to:

difficulties in using (interpreting) diagrams by ordinary employees;
the impossibility (difficulty) of organizing work to describe processes by employees of departments who have not undergone special training;
a significant increase in the labor costs of business analysts for the formation of schemes;
additional difficulties when documenting circuits (large volume, etc.);

Therefore, you should not clutter the process diagram with various graphic elements. But even if you use them, it is better that they carry useful information for employees, and are not simply a consequence of the formal application of modeling notations.

, Ph.D., Associate Professor, Executive Director of LLC "", Head. Department of Business Process Management of the National Educational Institution of Higher Professional Education “IEF “Synergy”, founder of the portal www.FineXpert.ru

- communication environment for professionals

posted in the section:

find more articles

From my experience working with Nintex, I can say that this system is not without its drawbacks: high cost, periodic errors, general slowness of the system (although this is typical for all SharePoint) - all this forces me to use the standard workflow mechanism. However, Nintex has an important advantage - visualization of the diagram and the current state of the process. Thanks to this, the creation of workflows is simplified, and they can be created even by people who are quite far from programming (content managers, business analysts, etc.). SharePoint 2010 has a similar ability to create a workflow based on a visual diagram using Visio 2010 and SharePoint Designer 2010.

Create a diagram in Visio

Now we think through the logic of the business process and draw up a diagram using the necessary elements. For example, I made a simple business approval process:

there are 2 lists - “Inbox” and “Responsible”
in the “Responsible” list there are categories of requests (suggestion/question/complaint, etc.) and the corresponding responsible persons
user creates an item in the Inbox and specifies a category
the workflow finds the person responsible for this category and creates a task for him
the person in charge reacts to the task, and the status of the request in the Inbox list changes

Of course, it’s hard to perceive this in words, so I’ll immediately give you a ready-made workflow diagram:

Binding a process to data in SharePoint Designer

Open Designer, connect to the desired site, go to the Workflows folder. On the ribbon, click the “Import from Visio” button and specify the file with the saved diagram. We write the name of the workflow and the list to which we bind it (in this case, “Inbox”). Designer itself will generate the code and comments for it; all we have to do is indicate the fields from which to get the data (specifically, in this case, I had some minor problems due to the use of a Lookup type field, but usually everything is simple):

After finalizing the workflow, go to settings. There we indicate the necessary launch condition (launch automatically when an element is created), and also check the “Show workflow visualization on status page” option (you need to activate SharePoint Server Enterprise capabilities on the site collection). This is exactly why it is worth creating workflows in Visio. Now let's go to the site, create any item in the Inbox list, go to the task list and complete the task, and then open the workflow status window: