Flow Chart Definition

A flowchart is a graphic representation of how a process works, showing, at a minimum, the

sequence of steps.
What is Flowchart
Several types of flowcharts exist: the most simple (high level, a detailed version (detailed, and
one that also indicates the people involved in the steps (or matrix).

The flowchart is a means to visually present the flow of data through an information
processing systems, the operations performed within the system and the sequence in which they
are performed. In this lesson, we shall concern ourselves with the program flowchart, which
describes what operations (and in what sequence) are required to solve a given problem. The
program flowchart can be likened to the blueprint of a building. As we know, a designer draws a
blueprint before starting to construct a building. Similarly, a programmer prefers to draw a
flowchart prior to writing a computer program. As in the case of the drawing of a blueprint, the
flowchart is drawn according to defined rules and using standard flowchart symbols prescribed
by the American National Standard Institute, Inc.
Meaning of a Flow Chart
A flowchart is a diagrammatic representation that illustrates the sequence of operations to be
performed to get the solution of a problem. Flowcharts are generally drawn in the early stages of
formulating computer solutions. Flowcharts facilitate communication between programmers and
business people. These flowcharts play a vital role in the programming of a problem and are
quite helpful in understanding the logic of complicated and lengthy problems. Once the
flowchart is drawn, it becomes easy to write the program in any high level language. Often we
see how flowcharts are helpful in explaining the program to others. Hence, it is correct to say
that a flowchart is a must for the better documentation of a complex program.
Flow is a representation of a series of logic operations to satisfy specific requirements. A flow
exists naturally. It can be irregular, unfixed or full of problems. For this reason, it may apparently
be absent in some situations. Lately, members of a team were assigned to investigate the flow of
a business process, and I was told that there were some deficiencies in the flow. The reply from
the person who was in charge of the team was that no flow was shown in part of the business
process. As a matter of fact, it is impossible for a business carried out without a flow. It may be a
flow in an unfixed form, or, may be the person himself whom you investigated does not have a
clear sense about the flow.
Chart, or diagram, is a presentation or a written description of some regular and common parts
of the flow. A chart is conducive to communication and concentration and offers references for
process reengineering.
Flow chart can be seen from the definition that a flow accompanies always with business or
transaction. Not all of the flows, however, are appropriate to be expressed by flowcharts. Flows
that can be expressed by charts follow some fixed routines, and the key links of flows won't be
changed constantly.
When to Use Flow Chart

A flowchart helps to clarify how things are currently working and how they could be improved.
It also assists in finding the key elements of a process, while drawing clear lines between where
one process ends and the next one starts. Developing a flowchart stimulates communication
among participants and establishes a common understanding about the process.
Flowcharts also uncover steps that are redundant or misplaced. In addition, flowcharts are used
to identify appropriate team members, to identify who provides inputs or resources to whom, to
establish important areas for monitoring or data collection, to identify areas for improvement or
increased efficiency, and to generate hypotheses about causes. Flowcharts can be used to
examine processes for the flow of patients, information, materials, clinical care, or combinations
of these processes. It is recommended that flowcharts be created through group discussion, as
individuals rarely know the entire process and the communication contributes to improvement.
Types of flowcharts
High-Level Flowchart
A high-level (also called first-level or top-down) flowchart shows the major steps in a process. It
illustrates a "birds-eye view" of a process, such as the example in the figure entitled High-Level
Flowchart of Prenatal Care. It can also include the intermediate outputs of each step (the product
or service produced), and the sub-steps involved. Such a flowchart offers a basic picture of the
process and identifies the changes taking place within the process. It is significantly useful for
identifying appropriate team members (those who are involved in the process) and for
developing indicators for monitoring the process because of its focus on intermediate outputs.
Most processes can be adequately portrayed in four or five boxes that represent the major steps
or activities of the process. In fact, it is a good idea to use only a few boxes, because doing so
forces one to consider the most important steps. Other steps are usually sub-steps of the more
important ones.
Detailed Flowchart
The detailed flowchart provides a detailed picture of a process by mapping all of the steps and
activities that occur in the process. This type of flowchart indicates the steps or activities of a
process and includes such things as decision points, waiting periods, tasks that frequently must
be redone (rework), and feedback loops. This type of flowchart is useful for examining areas of
the process in detail and for looking for problems or areas of inefficiency. For example, the
Detailed Flowchart of Patient Registration reveals the delays that result when the record clerk
and clinical officer are not available to assist clients.
Deployment or Matrix Flowchart
A deployment flowchart maps out the process in terms of who is doing the steps. It is in the form
of a matrix, showing the various participants and the flow of steps among these participants. It is
chiefly useful in identifying who is providing inputs or services to whom, as well as areas where
different people may be needlessly doing the same task. See the Deployment of Matrix
Flowchart.
More Flowchart Types
Which Flowchart Should be Used
Each type of flowchart has its strengths and weaknesses; the high-level flowchart is the easiest to
construct but may not provide sufficient detail for some purposes. In choosing which type to use,
the group should be clear on their purpose for flowcharting. The table below entitled "Type of
Flowchart Indicated for Various Purposes" gives some indications, but if you're unsure which to
use, start with the high-level one and move on to detailed and deployment. Note that the detailed
and deployment flowcharts are time-consuming.
Guideline for drawing a flowchart

Flowcharts are usually drawn using some standard symbols; however, some special symbols can
also be developed when required. Some standard symbols, which are frequently required for
flowcharting many computer programs are shown.
How to Draw a Flowchart
Make Great-looking Flowcharts in Excel
A Set of Useful Standard Flowchart Symbols
It is not strictly necessary to use boxes, circles, diamonds or other such symbols to construct a
flowchart, but these do help to describe the types of events in the chart more clearly. Described
below are a set of standard symbols which are applicable to most situations without being overly
complex.
1. Rounded box - use it to represent an event which occurs automatically. Such an event
will trigger a subsequent action, for example `receive telephone call', or describe a new
state of affairs.
2. Rectangle or box - use it to represent an event which is controlled within the process.
Typically this will be a step or action which is taken. In most flowcharts this will be the
most frequently used symbol.
3. Diamond - use it to represent a decision point in the process. Typically, the statement in
the symbol will require a `yes' or `no' response and branch to different parts of the
flowchart accordingly.
4. Circle - use it to represent a point at which the flowchart connects with another process.
The name or reference for the other process should appear within the symbol.

Hints for Constructing Flowcharts
Try to develop a first draft in one sitting, going back later to make refinements. Use the "five-
minute rule": do not let five minutes go by without putting up a symbol or box; if the decision of
which symbol or box should be used is unclear, use a cloud symbol or a note and move on.
To avoid having to erase and cross out as ideas develop, cut out shapes for the various symbols
beforehand and place them on the table. This way, changes can easily be made by moving things
around while the group clarifies the process.
Decision symbols are appropriate when those working in the process make a decision that will
affect how the process will proceed. For example, when the outcome of the decision or question
is YES, the person would follow one set of steps, and if the outcome is NO, the person would do
another set of steps. Be sure the text in the decision symbol would generate a YES or NO
response, so that the flow of the diagram is logical.
In deciding how much detail to put in the flowchart (i.e., how much to break down each general
step), remember the purpose of the flowchart. For example, a flowchart to better understand the
problem of long waiting times would need to break down in detail only those steps that could
have an effect on waiting times. Steps that do not affect waiting times can be left without much
detail.
Keep in mind that a flowchart may not need to include all the possible symbols. For example, the
wait symbol ( ) may not be needed if the flowchart is not related to waiting times.
Improving the layout of a flowchart
Create a complex flowchart
Analyzing the Detailed Flowchart to Identify Problem Areas
Once the flowchart has been constructed to represent how the process actually works, examine
potential problem areas or areas for improvement using one or more of the following techniques.
Examine each decision symbol: Does it represent an activity to see if everything is going well? Is
it effective? Is it redundant?
Examine each loop that indicates work being redone (rework): Does this rework loop prevent the
problem from recurring? Are repairs being made long after the step where the errors originally
occurred?
Examine each activity symbol: Is this step redundant? Does it add value to the product or
service? Is it problematic? Could errors be prevented in this activity?
Examine each document or database symbol: Is this necessary? Is it up to date? Is there a single
source for the information? Could this information be used for monitoring and improving the
process?
Examine each wait symbol: What complexities or additional problems does this wait cause?
How long is the wait? Could it be reduced?
Examine each transition where one person finishes his or her part of the process and another
person picks it up: Who is involved? What could go wrong? Is the intermediate product or
service meeting the needs of the next person in the process?




Flowcharts are used in designing and documenting complex processes or programs. Like other
types of diagrams, they help visualize what is going on and thereby help the people to understand
a process, and perhaps also find flaws, bottlenecks, and other less-obvious features within it.
There are many different types of flowcharts, and each type has its own repertoire of boxes and
notational conventions. The two most common types of boxes in a flowchart are:
a processing step, usually called activity, and denoted as a rectangular box
a decision, usually denoted as a diamond.
A flowchart is described as "cross-functional" when the page is divided into different swimlanes
describing the control of different organizational units. A symbol appearing in a particular "lane"
is within the control of that organizational unit. This technique allows the author to locate the
responsibility for performing an action or making a decision correctly, showing the responsibility
of each organizational unit for different parts of a single process.
Flowcharts depict certain aspects of processes and they are usually complemented by other types
of diagram. For instance, Kaoru Ishikawa defined the flowchart as one of the seven basic tools of
quality control, next to the histogram, Pareto chart, check sheet, control chart, cause-and-effect
diagram, and the scatter diagram. Similarly, in UML, a standard concept-modeling notation used
in software development, the activity diagram, which is a type of flowchart, is just one of many
different diagram types.
Nassi-Shneiderman diagrams and Drakon-charts are an alternative notation for process flow.
Common alternative names include: flowchart, process flowchart, functional flowchart, process
map, process chart, functional process chart, business process model, process model, process
flow diagram, work flow diagram, business flow diagram. The terms "flowchart" and "flow
chart" are used interchangeably.
The underlying graph structure of a flow chart is a flow graph, which abstracts away node types,
their contents and other ancillary information.
History

Template for drawing flowcharts (late 1970s) showing the different symbols.
The first structured method for documenting process flow, the "flow process chart", was
introduced by Frank Gilbreth to members of the American Society of Mechanical Engineers
(ASME) in 1921 in the presentation Process ChartsFirst Steps in Finding the One Best
Way.
[2]
Gilbreth's tools quickly found their way into industrial engineering curricula. In the
early 1930s, an industrial engineer, Allan H. Mogensen began training business people in the use
of some of the tools of industrial engineering at his Work Simplification Conferences in Lake
Placid, New York.
A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble
where he developed their Deliberate Methods Change Program. Another 1944 graduate, Ben S.
Graham, Director of Formcraft Engineering at Standard Register Industrial, adapted the flow
process chart to information processing with his development of the multi-flow process chart to
display multiple documents and their relationships.
[3]
In 1947, ASME adopted a symbol set
derived from Gilbreth's original work as the "ASME Standard: Operation and Flow Process
Charts."
[4]

Douglas Hartree explains that Herman Goldstine and John von Neumann developed a flowchart
(originally, diagram) to plan computer programs.
[5]
His contemporary account is endorsed by
IBM engineers
[6]
and by Goldstine's personal recollections.
[7]
The original programming
flowcharts of Goldstine and von Neumann can be seen in their unpublished report, "Planning and
coding of problems for an electronic computing instrument, Part II, Volume 1" (1947), which is
reproduced in von Neumann's collected works.
[8]
Besides describing the logical flow of control,
flowcharts allowed programmers to lay out machine language programs in computer memory
before the development of assembly languages and assemblers.
[9]

Flowcharts used to be a popular means for describing computer algorithms and are still used for
this purpose.
[10]
Modern techniques such as UML activity diagrams and Drakon-charts can be
considered to be extensions of the flowchart. In the 1970s the popularity of flowcharts as an own
method decreased when interactive computer terminals and third-generation programming
languages became the common tools of the trade, since algorithms can be expressed much more
concisely as source code in such a language, and also because designing algorithms using
flowcharts was more likely to result in spaghetti code because of the need for gotos to describe
arbitrary jumps in control flow. Often pseudo-code is used, which uses the common idioms of
such languages without strictly adhering to the details of a particular one.