By Katrin Freeh on October 28 2018 01:07:54
Helping an organization map out processes can be a challenging task unless you know how to create sample flowcharts. When attempting to get subject matter experts to redefine their business processes, it is imperative to help them identify gaps or redundancies in their current as-is process.
Although drawings typically consist of geometric shapes, it is not uncommon to include tables or indices to represent decisions or to provide a cross-reference. Nonetheless, boxes and lines represent the principal means to visualize and communicate a design regardless of the structure to be built, and have been used since time immemorial.
A flowchart can enable the process analyst to effectively document the information given to them by the subject matter experts. With a defined list of symbols, directional arrows and flow diagrams, flowcharts can help the team find gaps and or problem areas that have been known for awhile but have never been visually mapped out in an as-is process map.
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.
In terms of the Information Systems industry, flowcharts have been used for years, well before the introduction of the commercial computer in business. Originally they included process diagrams; later they were used by programmers as a convenient means to document program logic. Such flowcharts typically made use of ANSI standard flowcharting symbols. But as the Structured Programming movement flourished in the late 1970`s, ANSI symbols were considered archaic, and many new types of diagramming techniques emerged, including Bubble Diagrams, Data Structure Diagrams, E/R Diagrams, HIPO, VTOC, etc. (anybody remember Nassi-Schneiderman Charts?). I could argue the pros and cons of the various techniques but that is not the point. What is important is that all of these diagramming techniques acknowledged documentation as an inherent part of the design process.