Let's move on to an example diagram that can be used to investigate slow invoicing problems. For this example, suppose you have just joined a company that creates semi-custom web applications for US and international markets. You are in charge of the engineering, quality assurance, and operations teams. The company offers customized applications in a software-as-a-service (SaaS) model and hosts the applications on the company's servers. International customers want the application to be translated into the appropriate languages and want to use graphics that appeal to people in the host country.
Your boss tells you that your company has been having difficulty invoicing customers in a timely fashion and asks you to investigate. She also tells you that some finger-pointing is going on between sales, operations, and accounts payable about who's to blame for the problem.
You start by drawing a high-level diagram of your company, showing the main interactions between the functional areas. Your sketch looks like Figure C-2. With this drawing as your initial reference point, you can mark it up with the specific workflow that you are investigating. In some cases, you can zoom in on specific details of a group and prune away functions that are not relevant to your problem.
To continue your investigation, you interview people involved in the complete order-build-invoice workflow. As you are talking to individuals, you sketch out the workflow in steps and ask each of them if you have properly captured each step.
First, you talk to the sales team; they tell you that they receive orders from the customer and send a copy of the order over to finance, the accounts billable group, engineering, and operations.
Next, you talk with engineering and learn that they receive the orders and then create the web application, working with other teams. To complete an order, the engineering team needs to use the services of a translation vendor and the graphics team. Engineering also works with QA to complete the website. Engineering has to ask purchasing for translation vendor support. The translation vendor gets requests directly from your purchasing group in finance while finance's accounts payable team looks for payment.
Next, you talk to QA. QA tests the website and requests corrections from engineering. When QA determines that the website is acceptable, they send the information to operations for deployment.
Next you talk to operations team members, whose jobs seem cut and dried. Operations receives the website from QA and deploys it. Operations also lets accounts billable know when a website goes up, but because no particular order number is used in the process, operations sends over a general description of the site and a date deployed. As you are leaving the operations area, the operations manager also tells you that he gets no advance notice of orders and really has to scramble to schedule deployment work.
Finally, you talk with the accounts billable and accounts payable groups in finance. They tell a different story. Too often the accounts billable team has to ask sales for an order when it comes in. They also have difficulty understanding whom to bill when operations puts up a website, because they don't have a purchase order number from operations. So they have to call sales, operations, and sometimes engineering to figure it out.
All of this information is too confusing in the abstract, so you revise your high-level diagram to focus on the specifics of this workflow. You revise your sketch to remove groups not involved and to add specific subgroups when appropriate. Then, you add actions to each group to illustrate what they do in the workflow. Your diagram looks like Figure C-3.
From the diagram, you can follow the workflow of the purchase order. With the diagram, it is easier to see that the gap occurs between sales, accounts billable, and operations. The diagram also makes it easier to experiment with potential solutions.
One approach is to get agreement from sales always to send order information to both accounts billable and operations. Operations now has the reference order number and some notice of the order being completed by engineering. Operations is then required to attached the order number to the deployment notice given to accounts payable. Operations will also be the backup check if it finds a web deployment but no corresponding order from sales—operations can talk to sales directly to request the order and have enough information to identify the appropriate order. Figure C-4 illustrates the addition of sales supplying the customer order to operations not shown in Figure C-3.
Although this is a simple example, workflow diagrams can also be used to resolve more complex workflow issues. They are useful while training new employees, as well.
Simple workflow diagrams are easy to construct and provide a method for visualizing and improving workflows in your company.