By Ursula Wirtz on December 05 2018 03:08:47
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.
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.
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.
Usually, this exercise takes place during an e-procurement project as part of the analysis phase, but can be done at any time. As long as there is a resource who has the proper skills and knows how to draw a flowchart to help the various departments identify their current procedures and potential problem areas within the purchase order approval process.
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.
I recently overheard a Business Analyst say there was more to systems architecture than drawing boxes and arrows on a piece of paper. This may be true to a degree, but the ultimate deliverable of any engineering/architectural practice is a set of drawings from which to build a product. Architects and engineers do not spend all of their time drawing diagrams; for example, they have to specify requirements and analyze such things as the stress of components to determine the suitability of materials for use in design. But aside from this, the end result of engineering or architecture, their deliverable, is a set of drawings, be it a blueprint, a floor plan, wiring diagram, plumbing, or a set of flowcharts.
flow chart example with explanation