By Lisa Werner on October 15 2018 21:03:35
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.
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.
A flowchart could be defined as a pictorial representation of a process in which the steps are symbolized by shapes - in other words a diagram that explains the steps in a procedure. Each shape should link to its neighbour by a connector line, and often these have arrow heads to describe the direction of flow.
Creating purchase requisitions is a standard function in every business. Unfortunately, the manual paper purchase order or requisition is one of the most frustrating areas of every business because the constant approval issues and long turnaround times that can occur.
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).
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.