Chapter 7: Systems mapping and documentation Flashcards
Discuss how systems documentation can help business process redesign and re-engineering.
One way to achieve business process redesign and re-engineering is by understanding and reviewing the systems documentation for the existing process.
Systems documentation provides an overview of the sequence of activities in the business process.
For example, the logical DFD will show the critical process activities that occur, and the data that is needed and generated within each process.
The physical DFD, in contrast, will provide a perspective on who is involved in the process (i.e. the people and their respective functional areas).
Similarly, a flowchart will show the movement of data and documents between functional areas and personnel and allow the analysis of what occurs and who is involved.
Such a perspective is a useful starting point for any re-engineering or systems redesign project.
Studies highlight that an analysis of process documentation as part of process redesign allows for the identification activities running in parallel, where to eliminate paper items, where to remove redundant data and the identification of the same actions performed multiple times.
Each of these represents potential ways of ‘trimming the fat’ from a business process but are possible only through a thorough understanding of process operation, and thus a thorough understanding of the associated systems documentation.
Discuss what an entity is in terms of systems documentation and what the distinction of internal and external entity is dependent on.
An entity is any person or thing involved in the activities of a business process.
We can classify entities as either internal or external.
The distinction is dependent on:
(a) the process that is being documented and
(b) the functions and tasks that are carried out by the entity.
In the systems documentation context, an entity is a person or thing involved in the execution of a process.
Generally, we consider any entity that is not performing activities within the system scope as an external entity while those that perform actions are internal entities.
If the entity’s sole activities involve sending or receiving data, they are considered external.
In contrast, if the entity performs data processing or transformation, it is considered internal.
Can an external entity become an internal entity?
An external entity is any entity that:
(1) provides inputs into, or
(2) receives outputs from a process.
An external entity to the process does not use the data; it merely provides, sends or receives data.
It is therefore essential to document the processes clearly because an entity may be an external entity for one operation but an internal entity for a different one.
In particular, when the supposedly external entity falls into the system scope of another system documentation exercise, it can become an internal entity.
Give at least three examples of data processing or transformation carried out by internal entities.
- Accounting record reconciliation
- Data entering
- Produce and review reports
- Approval of documents
- Update records
Discuss the advantages and limitations of the process narrative technique.
The advantage of the process narrative is that it is readily accessible to anyone.
This accessibility can make it a convenient form for documenting a process.
However, for more in-depth analysis and a better understanding of the process, the process narrative can be subject to limitations.
One limitation is that its preparation and readability are contingent on the writer’s writing style.
Some people may write in a wordy, repetitive manner, while others may be extra brief in their preparation of the narrative.
Additionally, written work can be subject to different interpretations and may lead to two people interpreting the process differently.
Describe the six rules of constructing and reading a structure narrative table.
1. The table follows the chronological order of the process narrative.
Listed entities appear in the order in which they are involved in the process in the column ‘No.’
2. An entity will appear more than once in the table if it performs more than one activity.
E.g. the purchasing officer and the computer perform several activities at different stages of the process.
3. The ‘Activity’ column contains a brief description of the specific action or task.
Represents the ‘doing what’ aspect of the process.
4. The ‘Inputs required’ column refers to the data and documents required to carry out the activity.
E.g. the purchasing officer is unable to enter the purchasing details until they have the purchase requisition.
The paper document is the source of the data being input by the purchasing officer.
5. The ‘Outputs produced’ column refers to the outputs created during the activity, both electronic and paper.
E.g. the computer prints three copies of the purchase order.
These documents are an output of an activity.
6. We should read the rows of the process narrative table together as a whole.
Only reading individual rows might not make sense.
However, when we consider a specific activity, the preceding and following actions provide a clearer perspective.
E.g. three printed copies of the purchase order are input to the next operation (the purchasing supervisor signs the purchase order), creating the output of three copies of the signed printed purchase order.
Describe the six rules to construct and read a process map.
- The functional areas appear down the left-hand side of the diagram.
- A solid line separates the functional areas.
- A dashed line separates the sub-functions.
- The standard symbol is a rectangle for a process or activity.
- Process rectangles describe procedures, not documents.
- The process map reads from left to right, and from top to bottom.
What are the differences between physical DFD and logical DFD?
The logical DFD is concerned with the processes that make up a system and mainly answers the question of WHAT is happening?
In contrast, the physical DFD focuses on the entities that perform these processes and mainly answers the question of WHO is involved?
Therefore, logical DFD bubbles describe the processes and activities that occur within a system, while physical DFD bubbles detail the entities involved in the system.
Another difference is the nature of the labels on the data flow arrows.
Physical DFD labels refer to documents or physical items flowing through the system.
In contrast, logical DFD flows tell us what type of information we are sending.
Both the physical DFD and logical DFD’s contain numbered bubbles.
The logical DFD numbers represent the order in which the processes occur, while the physical DFD numbers indicate the order in which they take part in the process.
Is there a specific order for drawing context diagrams, logical DFDs, and physical DFDs?
Why or why not?
No.
It is not necessary to follow any specific order while drawing these diagrams.
One way to construct the diagrams is to draw the context diagram first, and “explode” the context diagram to logical DFDs and physical DFDs.
Doing so may have the risk of misidentifying the external entities, and the data flows that flow between them and the system, leading to the revision of the context diagram after we do logical DFDs and physical DFDs.
This order is likely when the understanding of the system changes as one proceeds with more detailed modelling.
The other equally valid way is to draw the logical DFDs and physical DFD first and the context diagram last.
This second method “contracts” the logical and the physical DFDs to arrive at a balanced context diagram.
Why do DFDs have less detail than either process maps or systems flowcharts?
A context diagram does not convey the processes within the system of interest but rather the external entities that interact with it.
We can expand context diagrams into physical and logical DFDs.
Physical DFDs show the flow of entities that are involved in a process.
In contrast, process maps and systems flowcharts, identify not only the entities but also highlight what activities they perform.
On the other hand, while logical DFDs show the processes within a system, they do not convey who performs them, which is similar to having a process map without labelling the swim lanes.
What is the primary purpose of each of these forms of systems documentation?
(a) Process map
A process map is a simple graphical representation of a system, detailing:
- The activities that occur.
- The entities that perform the activities.
- The relationship between different activities and entities.
- Any decisions that occur as part of the process.
What is the primary purpose of each of these forms of systems documentation?
(b) Context diagram
A context diagram:
Provides a representation of the system of interest and the external entities that interact with it, by either providing inputs or receiving outputs.
It is an overview of the system of interest’s interaction with the external entities.
What is the primary purpose of each of these forms of systems documentation?
(c) Physical data flow diagram
A physical DFD expands the context diagram to tell us:
- the people, places and things that are involved in the system of interest
- the dataflows that occur between these physical entities
What is the primary purpose of each of these forms of systems documentation?
(d) Logical data flow diagram
A logical DFD:
Expands the context diagram to tell us what sequence of activities or processes occur within the system of interest, and the data flows between them.
A logical DFD shows what tasks a system performs and not the people, places and things that carry them out.
What is the primary purpose of each of these forms of systems documentation?
(e) Systems flowchart
A systems flowchart:
It provides us with both a logical and physical perspective of the system by depicting the entities involved and the processes they perform.
We also obtain details about how to perform the processes (for example, a computer process versus a manual process).
Therefore, a systems flowchart represents a more comprehensive combination of the physical and logical data flow diagrams.
