By Lisa Werner on October 13 2018 09:58:55
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.
Each flowchart should ideally begin with a Terminator shape, from which the next step should be linked. Each shape should be indicative of a specific stage in the process and there are conventions for each of these, the most common being the rectangular "Process" shape. Many others exist, however, including shapes representing Data, Documents and Decisions. Decision shapes are diamonds, each of the four corners (or nodes) being either a link from the preceding shape or action to be taken in the next stage depending on the decision.
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.
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.
Well, flowcharts can be used to analyze, design, document or manage a process in a wide variety of fields. Examples could include a Recruitment or Accounting process, the logical procedure within a piece of software, or a process in an organization such as Health & Safety, Equal Opportunities, Conciliation & Arbitration or Social Services. There are several derivatives of the basic flowchart including the Workflow Diagram,