Method Flowchart

By Vanessa Richter on October 19 2018 23:11:02

Flowcharts can be quickly created in many computer software programs; even recent versions of Microsoft Word and PowerPoint contain Smart Shapes that allow users to rapidly insert a flowchart into a document of presentation. Specialist Flowchart Diagramming software also exists but for sheer versatility and the ability to connect data to shapes I would put my money on Microsoft Visio. It has a huge range of ready-made stencils containing all the shapes you could possibly need (and the ability to create your own if you wish), and very slick automatic connection features. Visio also allow a flowchart that dexcribes one process to become part of a larger process and to integrate with it via a hyperlink from a button on the drawing page.

Such drawings basically consist of boxes and arrows. Boxes (be it squares, rectangles, polygons, circles, etc.) represent tangible objects and lines represent relationships between such objects. Flowcharts are similar; here, boxes represent specific types of processes or decisions or objects such as inputs/outputs/files, and lines represent dependencies between them (comes from/goes to).

As a process mapping consultant, it is imperative to get everyone to see not only their own procedures, but how they interconnect into the organizational structure. Once in place and agreed upon by all the contributors, you begin to be able to challenge the current way of doing business and assist them in finding inefficiencies that could be costing the business thousands of dollars.

If your organization is looking for ways to reduce costs, the purchase order chain is one area that can be made more efficient. If the purchasing department learns how to draw a flowchart depicting the as is for each department, the overall effort could help reduce costs by eliminating redundant approval processes and mistakes.

This is not easily done, especially in a large room with multiple experts who know only a small portion of the entire process. Each contributor who works within the team can identify their specific areas they deal with on a daily basis, but do not necessarily understand or know the linkages and dependencies that exist outside of their general areas.

I guess what I`m driving at is that despite all of this peripheral activity, and to refute my Business Analyst friend, the principal thrust of the engineer or architect is to produce and maintain a reliable set of drawings. It all comes down to boxes and lines. Interestingly, today`s analysts and programmers think drawings are "old-hat" or passé. I don`t care whether you draw it with pencil and paper or by computer, documentation is an inherent part of the design process. Failure to recognize this is to deny reality.