Traditional Culture Encyclopedia - Traditional customs - UML Modeling (II) - Flowcharts

UML Modeling (II) - Flowcharts

This article will contain several pieces of content:

Flowchart = Process + diagram.

Process: Flow, is a series of operations with a specific logical relationship between a particular subject in order to meet a specific need, the process is naturally there. But it can not be standardized, can not be fixed, can be full of problems. So it can result in seemingly no process.

Chart: Chart or Diagram , is the basic solidification of the process has a certain rule of manifestation and written, which is conducive to the dissemination and precipitation, the process of reorganization reference.

As can be seen from the definition, as long as there are things and tasks, the process will be there, but not all processes are suitable for the way to express the flow chart, suitable for the flow chart to express the process is a certain degree of fixed regularity, the process of the key links will not change.

Participants: Who is in the process? It could be the system, it could be a printer, it refers more to what role - usually someone with a certain type of job. For example, customer service has both A and B at the same time, but if their job nature is exactly the same, then you only need to write one customer service role in the flowchart.

Activity : What was done, such as ordering, checking out, etc.

Activity : What was done.

Order : What is the order in which these things happen, and which task is a precondition for the others? For example, if the guest doesn't check out, the activity of giving him a discount card won't occur.

Inputs : What kind of inputs or data does the start of each activity depend on, e.g. the chef who cooks needs to be given a specific order form when he starts cooking.

Output : At the end of each activity, what kind of document or data will be input to pass on to the next party, for example, after the chef has finished cooking, how to let the person in charge of passing the food know that the food is ready?

Standardize: Use a standardized set of symbols to communicate your flowchart so that your audience understands it more quickly.

Common flowcharts are Transaction Flow, Page Flow.

At work, as a UED, you may find that PDs often talk about business processes, while as interaction designers, we produce more page flow diagrams. What exactly is the relationship between page flowcharts and business flowcharts? Who comes first, and who comes second?

First tell a story: Suppose your dream is to open a high-end national chain of restaurants, then the first thing you think of should not be how to go to the site, but why to open a chain of restaurants this thing, as well as your positioning, core competitiveness to think clearly. Is fast food, or a la carte, chain or franchise? Located in the community or busy shopping district? Is it Sichuan or Zhejiang seafood? Is it for the middle-aged and elderly or young people? Is it a family theme or animation theme? Who are the competitors? What kind of investment is required? What are the possible risks? These are thought out clearly, the questions are answered, the so-called strategic layer to be clear. Then suppose you now analyze to analyze, and the main investor decided a direction: for young people's fashion animation cafes, chain, but first in Hangzhou to start the first, the site is located in the young people dating, sweeping the streets of the region, such as scenic areas, the famous shopping district, next to the cinema ......... ...and so on and so forth, so what's next?

The next step is to figure out how to make this happen, right? So what do you need to do? The first thing you need to do is to choose a location? Pull investment? Getting the decorations? Choosing a catering menu? Hire staff? How do you go about each step and at what point in time? The task breakdown as well as the planning for all of this and more goes to the tactical level.

The execution of these things always requires hiring people, right? First of all, the core team division of labor to deploy the construction tasks, when the restaurant opened up, it is necessary to organize a stable operations team, such as service, health, kitchen, procurement, personnel, etc., the kitchen inside the division of labor, white case, hot dishes, cold dishes, etc., right? Each department needs to have management and reporting lines, right? So your organizational structure is born.

So how does each role work together to accomplish the day-to-day, stable, and unexpected tasks? For example, when a customer comes in, who guides the guest to their seat, who orders the food, and how do you get the order to the kitchen quickly and distribute it to the wine room, the cold food room, and the hot food room? And ensure that the guests can eat the ordered dishes as soon as possible? You have to consider the collaborative processes of various people to optimize efficiency, so business processes come into play.

The human resource has been operating for a while, without the help of any ordering system, and you find that it's okay. When a guest orders, the server hand-copies and writes down the guest's request, and because of the copy paper, the server is able to send the copy into the kitchen while writing down the table number. The kitchen was small, so the staff in charge of assigning tasks looked at the menu, wrote down what they needed to handle on the board at the cold food area, and ran to the board in the hot food area to write down the dishes to be handled, as well as going to the wine room to report the name of the item. However, with the expansion of the operation, the above human way appeared a lot of problems, first of all, the efficiency of hand copying is too low, customers change dishes frequently, the response is too late, hand copying errors, resulting in often report the wrong dish. Kitchen is very chaotic, had to recruit a few more people specializing in running the hall. And once customers want to add dishes, withdrawing dishes is even more troublesome, you need to find out what they ordered at that time, and then manual annotations and modifications, at the same time to modify the kitchen back-end of the various blackboards ......

So you want to develop a set of intelligent systems, to replace a lot of human work, you have invited the system development team, who, after an assessment. judged that starting with ordering and continuing with passing the food could be solved with a system. Handheld terminal, can quickly pass the customer ordering needs to the printer, the printing system can be based on the type of customer ordering automatic sub-order printing, so the hot food room to see their own hot menu, cold food room to see their own cold menu, and the wine room to see the hotel menu. When they are prepared and sent out, the ushers can pass out the dishes according to the name of the dish with the printed slip and check it against the customer's order slip. This system must also be equipped with a billing system, the final confirmation off the menu and consumer prices to the billing front, the cashier can quickly operate.

This system is ultimately required to show, so how to design the interface of the handheld terminal? Waiter can use less clicks to complete a dish order? What about the clearinghouse interface?

With the above story, do you better understand the relationship between strategy, tactics, and business flowchart to page flowchart? To summarize:

● First, there is a business need and business goal, i.e., what is our vision? (Strategy)

● Then it was born what kind of tasks do we need to break out and how do we execute the tactics? (Tactics)

● Then comes the birth of what departments and positions need to be structured to divide up the work? (Organizational Structure)

● Then came the business process of how different departments work together to accomplish a task? (business process)

● After the business process is basically stable, it is often considered to optimize the efficiency, so the system will be born to support the process, to reduce the human link, and to promote data collection (system vision)

● In order to design the system, PD needs to think about what functions can replace a certain part of the human work (functional requirements, system process)

● No matter what the How about the function will eventually be presented in the way of interface, designers will pay attention to the user's task flow in the system, the behavioral path, so that the user can complete the task more efficiently and pleasantly. (

Of course, in addition to business processes, system processes, page processes, there are also data processes that get attention.

We usually work, but also often hear people talk about swim lane diagrams, task flow charts and other concepts, in fact, what is the relationship?

In the work, we can often see two kinds of business process diagrams, from the presentation, a very good distinction, commonly known as the "swim lane diagram" it, in the look of it is really like a swim lane, there can be horizontal swim lanes, there will be vertical swim lanes. A swimlane diagram is referred to in some documents as an "activity-based flowchart", where each activity floats in the swimlane.

There are a few key points in a swimlane diagram: the two dimensions, the flow of activities, and the flow elements.

Another type of flowchart is the department and position-based flowchart. The circles in the figure below represent departments or positions. The rectangles represent activities. This type of flowchart focuses on the logic of how things get done, but is weaker in reflecting the responsibilities of each department. If someone in a certain position looks at it, it's hard to see their department's responsibilities and tasks at a glance like a swim lane diagram. So it is less used now.

A flowchart provides a simple and concise "thumbnail view" that helps the viewer quickly understand how the business works. It contains several keywords: who, when, under what conditions, what is done, what is input, what is output, and to whom ......

Unlike a system process, a business process focuses more on how the business itself works, tells a business story, and contains business rules. business rules. The system process is to meet the business process, to achieve part of the process or all of the process information and systematization.

So the business process is the precondition for all the links - software requirements analysis, information systems construction will also be the first to carry out business process sorting.

The following shows how business process mapping works in three main scenarios:

1. Training

In this scenario: process mapping provides a quick view of how the business works. Through business process mapping, a new employee quickly understands what the end goal of the business is, what roles are involved and their responsibilities, and how they connect to each other. how they are connected to each other.

In addition to training new hires, in employee rotation and transfer scenarios, employees need a business process map to understand how the new work is being done, where they are, who they are upstream from, who they are downstream from, and what they need to deliver.

2, process optimization and restructuring

Business Process Reengineering (Business Process Reengineering) of the existence of a clear rebuttal: the existence of a reasonable. In fact, the existence of the business process is not reasonable, may be involved in multiple roles accustomed to a certain approach, may be the change has not yet affected the end of the operation, there may be a lack of insight into the operation of the business process problems and a strong push for change - because to promote business process change, not a department, but a variety of departments in the process. It may also lack insight into operational business process issues and a strong change driver - because driving business process change is not a departmental task, but requires the cooperation of all departments in the process.

More often than not, business process optimization is top-down, but bosses don't necessarily know the actual business processes that work so well, and business process mapping can be a good way to represent this "operating model". By looking at the business process map, looking for key nodes of people to visit, can cut directly into: why do this, why not do this? This leads to deeper questions than: what are you doing now?

Through research, analyzing business process maps, and introducing more roles, you can analyze the current business process problems: missing, duplication, risk, efficiency, etc.. From there, the corresponding optimization plan can be developed.

3, the basis of information technology

As mentioned above, the case of restaurant dreams, information systems, a task is to free the hands and feet of the staff to replace some of the repetitive human labor work. After the system, not that the business process is not needed but after some adjustments, in which one of the participants into the system, or handheld devices, or printers only.

So when doing the functional design of the system and system process design, is it necessary to first understand how the current business is operating? And thus better analyze the analysis and better illustrate at what point the system replaces what type of human work?

So the PRDs we see also tend to start with a business process diagram to illustrate, and the narrative of the benefits of building a system can be compared with the previous business processes versus those that will occur after the system is up. Based on the analysis, the functional points of the system that need to be behind the new business process map in the vision are written clearly.

First of all is there a process in mapping the business process itself? There must be. In software engineering you hear the saying that everything is an object. So in process science, everything is a process. The first thing that you need to do is to get to the point where you can see what's going on in the process. In terms of the action of eating, there is a process: chopsticks - food - entry - chewing - swallowing.

So, is there a process to follow for mapping business processes? I suggest you can start with the following 4 steps.

1, research

How to quickly understand the truth of business operations? Is there a research technique to put in place?

2, sorting and presentation

Can you quickly turn the words and questions from the research into a business process map?

What is the standard diagram for a business process map?

How do you evaluate whether a business process diagram is good or bad?

3. Review and validation - can the business process map really reflect the reality of the business?

4. Archiving and maintenance - how quickly can a business process map respond to constant process changes?

Thinking about how beautiful, how to interact, and what tools to use should not be the focus before mapping business processes.

The real focus is to gather the key elements of a business process map. Don't start mapping until you've tried to answer the following questions:

In addition to the questions at the beginning of this section, The research process is still about who, what, why, how, and where: who, in what context, did what, what did it take, and what was the output, and where did it go? What was the output, and where was it accomplished?

The performance of the flowchart to answer these questions:

1, Who - who? Department, role, position

2, What - what things?

3. Where - Where is it done? In the business process map I combed, where indicates more whether it is a document or a variety of systems, used to indicate the degree of information technology. For example, when we combed found that there is a registration, is to use excel rather than business systems to carry out, then here where can be expressed as: excel document.

4, Document - that produces the name of this document? Also written out, on behalf of the delivery of documents, and later to carry out information technology, this human document is also required to be eliminated and replaced by the system. (On the contrary, if this work is operated in a system, where it can be written as "personnel system", the document can continue to exist, that is, the name of the form in the system: "Employee Registration Form")

5, Condition - condition. In this condition, the next activity can continue, that is, the way the logical link line to indicate the inputs and outputs of an activity, pointing to an activity of the arrow that indicates the pre-input conditions of this activity.

6. Dicision - decision making. Some activities will produce a conditional judgment , according to the results of different judgments so as to take different branches of the process. For example, when entering employee information, you can choose a different process based on whether or not the employee has been employed before, for those who have been employed before, use the previous job number without generating a new job number.

Let's take an example (if it's not appropriate, please understand). Suppose you are tasked with investigating the business processes of two restaurants with the goal of providing them with the most cost-effective ordering system.

In the research:

You can start by asking someone who is well versed in the business process to explain the system to you.

Research the specific operation of the person to verify that he explains to you whether the comprehensive and deviation.

Observing and documenting in the field (taking the time to walk through the business process)

All three approaches are used in conjunction with each other. The first approach allows you to first develop a systems view and understand the broad branches, but it is difficult to cut through to the details of what might be going wrong. The second approach relies too much on the quality of the questions and the scenario in which they are asked. There are a lot of incorrect conclusions that are actually due to asking the wrong person or asking the question in the wrong way. Then it is necessary to resort to the third, and then verify it in observation.

In these questions, it's about "ordering", "cutting", "choosing", "cooking", "passing", and "serving". ", "passing", "serving" several activities, but also involves the "waiter", "chef The roles of "waiter", "chef", "assistant", "cutter", and "server" are also covered. The order of the activities is also clearer.

The following question may not be understood by the chef, ask the orderer.

Your research and observations have given you the raw materials you need to "cook".

The next task is simple, yes, like a fill-in-the-blank. Fill in the boxes with activities/events according to certain rules determined by two dimensions: department and time.

This stage is paper work, where you need to present the raw material collected during the research phase in a more visual way. This allows for better review and validation. It also prepares the process for review and optimization later.

It is not possible to put all the activities into one diagram.

"Business processes are hierarchical, and this hierarchy is reflected in the logical relationship from top to bottom, from whole to part, from macro to micro, from abstract to concrete. Such a hierarchical relationship is in line with people's thinking habits and is conducive to the establishment of the enterprise business model Hierarchical Relationships Between Enterprise Departments Table. In general, we can first establish the overall operating process of the main business processes (which includes the overall enterprise's broad strategy), and then refine each of these activities, implement the business processes of each department, and establish relatively independent sub-business processes as well as auxiliary business processes that serve them."

-- Quoted from the Baidu Encyclopedia Business Processes entry

For many newcomers, the hardest part of business lies in delineating the hierarchy of the business process map.

First, define the scope of the business process you're trying to sort through -- the top-level business process map that tells the story of what's going on in the scope of that business process in terms of big, rough key nodes. Your top-level business process map is a simple representation of the business big picture story, but note that the business big picture here doesn't have to be the overall business big picture of the company as a whole, but rather the scope of the business that you have defined. For example, if you define the scope of your business as the customer-facing ordering and checkout process, then this is the top-level business process map. But if you're defining the entire restaurant's operational business processes, then this is clearly still a subset - it doesn't include the restaurant's purchasing, vendor management, first-level inventory management, and so on.

Next, start with the top-level business process decomposition, going from coarse to fine. The grooming principles for the top-level business process map:

1. Define the global story of the business within the scope.

2. Include the key nodes in the scope. And, when challenged about how so-and-so doesn't exist, make yourself clear that it should be included in that key node in the next level of decomposition. For example, giving away a 10th anniversary coupon should be in the checkout node breakdown. And printing a split order would be in the ordering node decomposition. And preparing child seats should be in the reception seating session.

3, the top flow chart decomposition out of the key nodes may not be refined decomposition down to generate the second level as well as the third level of the flow chart. This depends on the node involved in the "activities" and "role" is complex.

Look at a case study of the decomposition of a traditional manufacturing company's main business process of purchase, sale, and inventory. The orange color represents the decomposition point, which can already be decomposed into four layers. When we decompose to the fourth level, and found that further down the activities and roles involved have been very few, there is no need to decompose, but the fourth level of key nodes can be directly as the third level of the business process "activities", rather than sub-process maps.

Of course, this depends on your goal of organizing your business processes. If you're looking to profile and optimize the "proofing" process, you can continue to break it down.

This step will help you create a clear process catalog structure, as shown in the image below, which is an excerpt from a just-completed process grooming project. You can see that the whole diagram is the top key nodes, as the boss, may just look at this layer is enough. The following will do more detailed disassembly of the top layer.

"H3.Sample Certification" is just an "activity" in the top-level business process diagram, and in this level of its own refinement, it will contain detailed sub-activities of the first level of participants.

I often use the first two rows of "Activity", "Judgement", "Logic Line", "Start and Stop ", and in the second line "sub-processes", and "documents/forms". If you're not a symbol person, I'd suggest that these are sufficient.

Among them, the "sub-process" this illustration is to help you break down the process to get the sub-processes can be linked, for example, when the "A process" in the "A process" involves further decomposition of the "A1.1", it can be broken down to "A1.1". process", you can use the sub-process symbols in "Process A" to represent "A1.1". Then your readers will understand that they should refer to another flowchart for further understanding of "A1.1″.

The common structure of a flowchart:

Some examples:

A flowchart that basically contains most of the diagrams:

A simple flowchart that uses only a few diagrams (called a program diagram in the Taiwanese documentation - but the program here is not a computer program, it's a process, it's a process, and it's not a computer program. computer program, but process, just reflects the processing flow between tasks, so the use of very simple symbols is not strange):

The above two flowchart cases, in terms of the complexity of the symbols, one is a complete flowchart, the other is a basic flowchart, but in terms of the form of expression, both belong to the "Swimming Path Diagram" - Swimming Path Diagram (SWP). But in terms of presentation, they are both "Swimlane" - Swimlane, which is one of the most commonly used forms of presentation. Swimlane diagram can well reflect the responsibilities of departments or roles in the process as well as upstream and downstream collaboration. And the flowchart itself is easy to grasp the standard, and it is much easier to reach *** knowledge.

What's the best way to verify that you've done the DOs above, and that you've circumvented Donnot?

It's easy to do, in time for a review with all of you. Get all the various people involved together and show them what you've sorted out.

This will reveal some interesting things, and in addition to reviewing your process maps to see if they are realistic, it will also review the current business processes to see if they are ideal. Representatives of different departments and positions will be in this review, to confirm the current, but also to each other's views, and even quarrel, which is not a good opportunity to do process optimization. For the time being.