Process Modeling
Define systems modeling and differentiate logical and physical models.
Define process modeling and explain its benefits.
Recognize and understand basic concepts and constructs of a process model.
Read and interpret a data flow diagram.
Explain when to construct process models and where to store them.
Construct a context diagram to illustrate a system’s interfaces with its environment.
Identify use cases, external and temporal business events.
Perform event partitioning and organize events in a functional decomposition diagram.
Draw event diagrams and merge them into a system diagram.
Draw primitive data flow diagrams and describe the elementary data flows in terms of data structures and procedural logic.
Document the distribution of processes to locations.
Synchronize data and process models using a CRUD matrix.

*
Chapter 9 objectives.

9-*

*
Teaching Notes
This slide shows the how this chapter’s content fits with the building blocks framework used throughout the textbook. The emphasis of this chapter is upon PROCESSES. It also reflects the fact that process modeling may be performed during certain analysis phases and involves not only systems analysts…but owners and users.

9-*
Models: Logical and Physical
Logical model – a nontechnical pictorial representation that depicts what a system is or does. Synonyms or essential model, conceptual model, and business model.
Physical model – a technical pictorial representation that depicts what a system is or does and how the system is implemented. Synonyms are implementation model and technical model.
Model – a pictorial representation of reality.
Just as a picture is worth a thousand words, most models are pictorial representations of reality.

*
Teaching Notes
In some books, the term logical is called a conceptual or essential. The term essential comes from the notion that the model represents the “essence” of the system.
For database-oriented instructors, the term logical in the world of systems analysis is NOT equivalent to the term logical in the world of database. In the database world, a “logical schema” is already constrained by the choice of a database technology, which runs contrary to the systems analysis expectation that a logical model is technology-independent.
In some books, the term physical is called implementation or technical.
Emphasize that there are nearly always multiple technical solutions for any given set of business requirements. In most projects, there is one logical model that represents the mandatory and desirable business requirements, regardless of how those requirements might be implemented. On the other hand, given that one logical model, there are multiple candidate physical models that could represent alternative, technical implementations that could fulfill the business requirements (although analysts rarely draw more than one or two of those physical models).

9-*
Why Logical System Models
Logical models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results.
Logical models allow us to communicate with end-users in nontechnical or less technical languages.

*
No additional notes

9-*
Process Modeling and DFDs
Process modeling – a technique used to organize and document a system’s processes.
Flow of data through processes
Logic
Policies
Procedures

Data flow diagram (DFD) – a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model.
The DFD has also become a popular tool for business process redesign.

*
Teaching Notes
Many, if not most students have drawn or seen process models in the form of program flowcharts.
Unfortunately, flowcharts are control-flow process models as opposed to data flow process models. This can cause some students trouble because they want to illustrate structured flow of control (nonparallel processing) in their early DFDs.
Most introductory information systems books at least introduce, with one or two examples, DFDs.

9-*
Simple Data Flow Diagram

*
Teaching Notes
We have found it useful to walk through this first DFD. Don’t be alarmed if students take exception to some of the oversimplification of the illustrated problem—it can actually contribute to the learning experience.

9-*
Differences Between DFDs
and Flowcharts
Processes on DFDs can operate in parallel (at-the-same-time)
Processes on flowcharts execute one at a time
DFDs show the flow of data through a system
Flowcharts show the flow of control (sequence and transfer of control)
Processes on a DFD can have dramatically different timing (daily, weekly, on demand)
Processes on flowcharts are part of a single program with consistent timing

*
No additional notes

9-*
External Agents
External agent – an outside person, unit, system, or organization that interacts with a system. Also called an external entity.
External agents define the “boundary” or
scope of a system being modeled.
As scope changes, external agents can
become processes, and vice versa.
Almost always one of the following:
Office, department, division.
An external organization or agency.
Another business or another
information system.
One of system’s end-users or managers
Named with descriptive, singular noun
Gane and Sarson shape
DeMarco/Yourdon shape

*
Teaching Notes
It is very important to emphasize the external agents on DFDs are not the same as entities on ERDs (from Chapter 7)—especially if the instructor prefers the more traditional term “external entity.”
This is true even though you could have both an entity (on an ERD) with the same name as an external agent/entity on a DFD. Consider the entity CUSTOMER and the external agent CUSTOMER:
The entity CUSTOMER indicates the requirement to store data about customers.
The external agent CUSTOMER indicates the requirement for an interaction (inputs and/or outputs) with customers.
It is very important for students to understand that external agents are “processes” outside of the scope of the system or business. As such, as scope “increases,” external agents can become processes. Conversely, if scope “decreases,” processes can become external agents.

9-*
Data Stores
Data store – stored data intended for later use. Synonyms are file and database.
Frequently implemented as a file or database.
A data store is “data at rest” compared to a data flow that is “data in motion.”
Almost always one of the following:
Persons (or groups of persons)
Places
Objects
Events (about which data is captured)
Concepts (about which data is important)
Data stores depicted on a DFD store
all instances of data entities
(depicted on an ERD)
Named with plural noun
Gane and Sarson shape
DeMarco/Yourdon shape

*
Teaching Notes
Emphasize that a data store contains all instances of a data entity (from the data model). That is why data store names are plurals (as contrasted to data entity names that are singular).
Although we don’t prefer it, some analysts designate a data store to contain all instances of several entities and relationships from a data model. For example, an ORDERS data store might include all instances of the data entities ORDER and ORDERED PRODUCT, and all instances of the relationship between ORDER and ORDERED PRODUCT—We prefer the simplicity of representing each data entity from the data model as its own data store on the process models.
Emphasize that because data stores are shared resources available to many processes, it is acceptable to duplicate them on several DFDs—The duplication does NOT indicate redundant storage (on logical DFDs); it merely represents the sharing of the data store by several processes.

9-*
Process Concepts
Process – work performed by a system in response to incoming data flows or conditions. A synonym is transform.
All information systems include
processes – usually many of them
Processes respond to business
events and conditions and transform
data into useful information
Modeling processes helps us to understand the interactions with the system’s environment, other systems, and other processes.
Named with a strong action verb followed by object clause describing what the work is performed on/for .
Gane and Sarson shape

*
No additional notes.

9-*
The System is Itself a Process

*
No additional notes.

9-*
Process Decomposition
Decomposition – the act of breaking a system into sub-components. Each level of abstraction reveals more or less detail.

*
No additional notes

9-*
Decomposition Diagrams
Decomposition diagram – a tool used to depict the decomposition of a system. Also called hierarchy chart.

*
Teaching Notes
Decomposition is a top-down problem-solving approach.
It might be useful to point out the numbering scheme. This scheme is common, but we do not like it because if the system is restructured, it forces renumbering all processes.
Some instructors like to do a quick example using a small but realistic problem.

9-*
Types of Logical Processes
Function – a set of related and ongoing activities of a business.
A function has no start or end.

Event – a logical unit of work that must be completed as a whole. Sometimes called a transaction.
Triggered by a discrete input and is completed when process has responded with appropriate outputs.
Functions consist of processes that respond to events.

Elementary process – a discrete, detailed activity or task required to complete the response to an event. Also called a primitive process.
The lowest level of detail depicted in a process model.

*
No additional notes

9-*
Common Process Errors on DFDs

*
Teaching Notes
Idea: Correct this diagram as an in-class exercise.
3.1.1: To correct the diagram, a data flow, ACCOUNTING DATA, should be added from the data store, MEMBER ACCOUNTS, to process 3.1.1.
3.1.2: To fix the black hole, we might add an output data flow called NEW MEMBER ACCOUNT from process 3.1.2 to the data store MEMBER ACCOUNTS.
3.1.3: To fix the miracle, you would need to at least add a data flow such as ACCOUNTING DATA from the data store, MEMBER ACCOUNTS, to process 3.1.3. In all likelihood, you also need some type of triggering data flow, such as ACCOUNT FREEZE AUTHORIZATION, from a new external agent, such ACCOUNTING DEPARTMENT, to process 3.1 3.

9-*
Data flow – data that is input to or output from a process.
A data flow is data in motion
A data flow may also be used to represent the creation, reading, deletion, or updating of data in a file or database (called a data store).
Composite data flow – a data flow that consists of other data flows.
Control flow – a condition or nondata event that triggers a process.
Used sparingly on DFDs.
Data Flows & Control Flows
Data flow name
Control flow name

*
Teaching Notes
Most books do not teach “control flows.” The were initially proposed by Paul Ward in his books that extended structured analysis techniques to cover real-time systems. They are especially useful in contemporary information systems analysis because they are as close as structured analysis gets to illustrating “messages” in an object-oriented world.
Make sure students do not confuse data flows with flowchart arrows. Flowchart arrows are not named because they merely indicate “the next step.” Data flows pass actual data attributes to and from processes.
CRUD is a useful acronym from the database world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete.
One of the most common uses of composite data flows is to combine many reports into a single data flow on a high-level DFD. They can also be used to combine similar transactions on a higher level DFD before differentiating between those flows on lower-level DFDs.
Use case diagrams, an object-oriented analysis tool that also describes interfaces are taught in Chapter 7.

9-*
Data Flow Packet Concept
Data that should travel together should be shown as a single data flow, no matter how many physical documents might be included.

9-*
Composite and Elementary
Data Flows
Junction indicates that any given order is an instance of only one of the order types.
Elementary flows
Composite flow

*
No additional notes

9-*
Data Flows to and from Data Stores

*
Teaching Notes
Some DFD methodologies suggest that data flows to and from data stores not be named. We think this confuses the end-users when they try to read the diagrams. Also, we believe that it is easier to have DFD errors of omission if the rules state that some flows are named while others are not.
Some DFD notations actually use the CRUD letters only to name flows to and from data stores. We consider this an acceptable alternative. CRUD is a useful acronym from the database world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete.

9-*
Rules for Data Flows
A data flow should never go unnamed.
In logical modeling, data flow names should describe the data flow without describing the implementation
All data flows must begin and/or end at a process.

*
No additional notes.

9-*
Data Conservation
Data conservation – the practice of ensuring that a data flow contains only data needed by the receiving process.
Sometimes called starving the processes.
New emphasis on business process redesign to identify and eliminate inefficiencies.
Simplifies the interface between those processes.
Must precisely define the data composition of each data flow, expressed in the form of data structures.

*
No additional notes.

9-*
Data Structures
The data attributes that comprise a data flow are organized into data structures.
Data flows can be described in terms of the following types of data structures:
A sequence or group of data attributes that occur one after another.
The selection of one or more attributes from a set of attributes.
The repetition of one or more attributes.
Data attribute – the smallest piece of data that has meaning to the users and the business.

Data structure – a specific arrangement of data attributes that defines an instance of a data flow.

*
Conversion Notes
Many structured analysis books do not specifically use the term data structure, but the relational algebraic notation is very common in both books and CASE tools.
Some books refer to data attributes as data elements. Some also call them data fields, but some would argue that field is a very technical-, implementation-, or physical-oriented term (that is not consistent with our emphasis on logical DFDs).

9-*
Data Structure for a Data Flow

DATA STRUCTURE
ORDER=
ORDER NUMBER +
ORDER DATE+
[ PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER]+
SHIPPING ADDRESS=ADDRESS+
(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+
QUANTITY ORDERED+
PRODUCT PRICE+
PRODUCT PRICE SOURCE+
EXTENDED PRICE } N+
SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD NUMBER+EXPIRATION DATE)
(QUOTE NUMBER)
ADDRESS=
(POST OFFICE BOX NUMBER)+
STREET ADDRESS+
CITY+
[STATE, MUNICIPALITY]+
(COUNTRY)+
POSTAL CODE
ENGLISH ENTERPRETATION
An instance of ORDER consists of:
ORDER NUMBER and
ORDER DATE and
Either PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT NUMBER
and SHIPPING ADDRESS (which is equivalent to ADDRESS)
and optionally: BILLING ADDRESS (which is equivalent to ADDRESS)
and one or more instances of:
PRODUCT NUMBER and
PRODUCT DESCRIPTION and
QUANTITY ORDERED and
PRODUCT PRICE and
PRODUCT PRICE SOURCE and
EXTENDED PRICE
and SUM OF EXTENDED PRICES and
PREPAID AMOUNT and
optionally: both CREDIT CARD NUMBER and EXPIRATION DATE
An instance of ADDRESS consists of:
optionally: POST OFFICE BOX NUMBER and
STREET ADDRESS and
CITY and
Either STATE or MUNICIPALITY
and optionally: COUNTRY
and POSTAL CODE

*
Teaching Notes
Bring several “physical” business forms to class. Transform one form into its relational algebraic data structure. Then, divide students into teams and ask them to perform the same exercise on a form and present their solutions to the class.

9-*
Data Structure Constructs
Data Structure Format by Example
(relevant portion is boldfaced English Interpretation
(relevant portion is boldfaced)
Sequence of Attributes – The sequence data structure indicates one or more attributes that may (or must) be included in a data flow.
WAGE AND TAX STATEMENT=
TAXPAYER IDENTIFICATION NUMBER+
TAXPAYER NAME+
TAXPAYER ADDRESS+
WAGES, TIPS, AND COMPENSATION+
FEDERAL TAX WITHHELD+… An instance of WAGE AND TAX STATEMENTS consists of:
TAXPAYER IDENTIFICATION NUMBER and
TAXPAYER NAME and
TAXPAYER ADDRESS and
WAGES, TIPS AND COMPENSATION and
FEDERAL TAX WITHHELD and…
Selection of Attributes – The selection data structure allows you to show situations where different sets of attributes describe different instances of the data flow. ORDER=
(PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER)+
ORDER DATE+… An instance or ORDER consists of:
Either PERSONAL CUSTOMER NUMBER or
CORPORATE ACCOUNT NUMBER; and
ORDER DATE and…

*
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures.
We have never found any form or file structure that could not be described using this notation!

9-*
Data Structure Constructs (continued)
Data Structure Format by Example
(relevant portion is boldfaced English Interpretation
(relevant portion is boldfaced)
Repetition of Attributes – The repetition data structure is used to set off a data attribute or group of data attributes that may (or must) repeat themselves a specific number of time for a single instance of the data flow.
The minimum number of repetitions is usually zero or one.
The maximum number of repetitions may be specified as “n” meaning “many” where the actual number of instances varies for each instance of the data flow. POLICY NUMBER+
POLICYHOLDER NAME+
POLICY HOLDER ADDRESS+
0 {DEPENDENT NAME+
DEPENDENT’S RELATIONSHIP} N+
1 {EXPENSE DESCRIPTION+
SERVICE PROVIDER+
EXPENSE AMOUNT} N An instance of CLAIM consists of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS and
zero or more instance of:
DEPENDENT NAME and
DEPENDENT’S RELATIONSHIP and
one or more instances of:
EXPENSE DESCRIPTION and
SERVICE PROVIDER and
EXPENSE ACCOUNT

*
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures.
We have never found any form or file structure that could not be described using this notation!

9-*
Data Structure Constructs (concluded)
Data Structure Format by Example
(relevant portion is boldfaced English Interpretation
(relevant portion is boldfaced)
Optional Attributes – The optional notation indicates that an attribute, or group of attributes in a sequence or selection date structure may not be included in all instances of a data flow.
Note: For the repetition data structure, a minimum of “zero” is the same as making the entire repeating group “optional.” CLAIM=
POLICY NUMBER+
POLICYHOLDER NAME+
POLICYHOLDER ADDRESS+
( SPOUSE NAME+
DATE OF BIRTH)+… An instance of CLAIM consists of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS and
optionally, SPOUSE NAME and
DATE OF BIRTH and…
Reusable Attributes – For groups of attributes that are contained in many data flows, it is desirable to create a separate data structure that can be reused in other data structures.
DATE=
MONTH+
DAY+
YEAR+
Then, the reusable structures can be included in other data flow structures as follows:
ORDER=ORDER NUMBER…+DATE
INVOICE=INVOICE NUMBER…+DATE
PAYMENT=CUSTOMER NUMBER…+DATE

*
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures.
We have never found any form or file structure that could not be described using this notation!

9-*
Data Types and Domains
Data attributes should be defined by data types and domains.
Data type – a class of data that be stored in an attribute.
Character, integers, real numbers, dates, pictures, etc.

Domain – the legitimate values for an attribute.

*
Teaching Notes
The same concepts with the same names were used in chapter 8.

9-*
Diverging and Converging
Data Flows
Diverging data flow – a data flow that splits into multiple data flows.
Indicates data that starts out naturally as one flow, but is routed to different destinations.
Also useful to indicate multiple copies of the same output going to different destinations.

Converging data flow – the merger of multiple data flows into a single packet.
Indicates data from multiple sources that can (must) come together as a single packet for subsequent processing.

*
No additional notes.

9-*
Diverging and Converging
Data Flows

*
Teaching Notes
Different CASE tools use different notations to illustrate converging and diverging data flows. In fact, some CASE tools do not even support this concept.

9-*
When to Draw Process Models
Strategic systems planning
Enterprise process models illustrate important business functions.
Business process redesign
“As is” process models facilitate critical analysis.
“To be” process models facilitate improvement.
Systems analysis (primary focus of this course)
Model existing system including its limitations
Model target system’s logical requirements
Model candidate technical solutions
Model the target technical solution

*
Teaching Notes
This is a context slide only. In this chapter, our demonstration of DFDs is exclusively for “systems analysis,” specifically “requirements modeling.”

9-*
Classical Structured Analysis
Rarely practiced anymore because cumbersome & time-consuming
Draw top-down physical DFDs that represent current physical implementation of the system.
Convert physical DFDs to logical equivalents.
Draw top-down logical DFDs that represent improved system.
Describe all data flows, data stores, policies, and procedures in data dictionary or encyclopedia.
Optionally, mark up copies of the logical DFDs to represent alternative physical solutions.
Draw top-down physical DFDs representing target solution.

*
Teaching Notes
It might be best NOT to show this slide to students. It is primarily intended to help instructors understand the differences between original structured analysis and contemporary structured analysis (the latter is shown on the next slide).
This approach to systems analysis is rarely practiced and is no longer recommended even by its original evangelists, Tom DeMarco and Ed Yourdon. Yourdon officially updated the methodology based on the seminal work, Essential Systems Analysis, by McMenamin and Palmer. The revised approach is shown on the next slide.

9-*
Modern Structured Analysis
(More Commonly Practiced)
Draw context DFD to establish initial project scope.
Draw functional decomposition diagram to partition the system into subsystems.
Create event-response or use-case list for the system to define events for which the system must have a response.
Draw an event DFD (or event handler) for each event.
Merge event DFDs into a system diagram (or, for larger systems, subsystem diagrams).
Draw detailed, primitive DFDs for the more complex event handlers.
Document data flows and processes in data dictionary.

*
Teaching Notes
Although this process may not be as familiar to some adopters as the top-down, fully leveled, classical “physical-logical-logical-physical” approach in the 1976 DeMarco methodology, this is the more contemporary approach and is taught in our book. The original approach is rarely, if ever, practiced because it is so labor intensive and time consuming.

9-*
Structured Analysis Diagram Progression (1 of 3)

*
Teaching Notes
The numbers in red correspond to the numbers on the previous slide.

9-*
Structured Analysis Diagram Progression (2 of 3)

*
Teaching Notes
The numbers in red correspond to the numbers on the slide 33.

9-*
Structured Analysis Diagram Progression (3 of 3)

*
Teaching Notes
The numbers in red correspond to the numbers on the slide 33.

9-*
CASE for Process Modeling

*
No additional notes.

9-*
Context Data Flow Diagram
Context data flow diagram – a process model used to document the scope for a system. Also called the environmental model.

Think of the system as a “black box.”
Ask users what business transactions the system must respond to. These are inputs, and the sources are external agents.
Ask users what responses must be produced by the system. These are outputs, and the destinations are external agents.
Identify any external data stores, if any.
Draw a context diagram.

*
Teaching Notes
This may be review from chapter 5.

9-*
SoundStage Context DFD

*
Teaching Notes
Emphasize that a context DFD does not have to show every net data flow. For most systems, that would overwhelm the reader. Trivial or less common flows can be omitted until later diagrams, and composite data flows can be created to combine multiple flows. As a result, and in the strictest sense, not all primitive data flows may “balance” up to the context DFD, but we sacrifice that balancing to improve readability and validation. All data flows on the context DFD will balance down to the lower-level DFDs (although composite data flows will be replaced by their separate component data flows).

9-*
SoundStage Functional
Decomposition Diagram
Break system into sub-components to reveal more detail.
Every process to be factored should be factored into at least two child processes.
Larger systems might be factored into subsystems and functions.

*
No additional notes.

9-*
Events and Use Cases
External events are initiated by external agents. They result in an input transaction or data flow.
Temporal events are triggered on the basis of time, or something that merely happens. They are indicated by a control flow.
State events trigger processes based on a system’s change from one state or condition to another. They are indicated by a control flow.
Use case – an analysis tool for finding and identifying business events and responses.
Actor – anything that interacts with a system.

*
Teaching Notes
Events are very similar to use cases in object-oriented analysis.
Events are represented on DFDs as data flows (for external events) or control flows (for temporal and state events).

9-*
SoundStage Partial Use Case List
Actor/
External Agent Event
(or Use Case) Trigger Response
Marketing Establishes a new membership subscription plan to entice new members. New Member Subscription Program Generate Subscription Plan Confirmation.
Create Agreement in the database.
Marketing Establishes a new membership resubscription plan to lure back former members. Past Member Resubscription Program Generate Subscription Plan Confirmation.
Create Agreement in the database.
(time) A subscription plan expires. (current date) Generate Agreement Change Confirmation.
Logically delete Agreement in database.
Member Joins club by subscribing. New Subscription Generate Member Directory Update Confirmation.
Create Member in database.
Create first Member Order and Member Ordered Products in database.

*
Teaching Notes
Walk through this so that students understand what goes in a use case list for DFDs.
This is an abbreviated list from what is shown in the text.

9-*
SoundStage Partial
Event Decomposition Diagram

*
Teaching Notes
Most event decomposition diagrams will require multiple pages (or one very large plotter-style page) because most systems are required to respond to many events (possibly dozens or hundreds).

9-*
Event Diagrams
Event diagram – data flow diagram that depicts the context for a single event.
One diagram for each event process
Depicts
Inputs from external agents
Outputs to external agents
Data stores from which records must be “read.” Data flows should be added and named to reflect the data that is read.
Data stores in which records must be created, deleted, or updated. Data flows should be named to reflect the update.

*
No additional notes.

9-*
Simple Event Diagram

*
No additional notes.

9-*
Event Diagram (more complex)

*
No additional notes.

9-*
Temporal Event Diagram

*
No additional notes.

9-*
System DFD

*
Teaching Notes
Most system DFDs will not fit on one or two pages—too many event processes. Instead they must be illustrated in a series of system diagrams that correspond to the structure originally depicted in the functional decomposition diagram.

9-*
System DFD (concluded)

*
No additional notes.

9-*
Balancing
Balancing – a concept that requires that data flow diagrams at different levels of detail reflect consistency and completeness
Quality assurance technique
Requires that if you explode a process to another DFD to reveal more detail, you must include the same dta flows and data stores

*
Teaching Notes
Discuss balancing with the class, the concept that requires that data flow diagrams at different levels of detail reflect consistency and completeness.

9-*
Primitive Diagrams
Some (not necessarily all) event processes may be exploded into primitive diagrams to reveal more detail.
Complex business transaction processes
Process decomposed into multiple elementary processes
Each elementary process is cohesive – it does only one thing
Flow similar to computer program structure

*
Teaching Notes
It is important to recognize that not all events require a primitive DFD to be drawn. This is especially true of most report-writing and inquiry response event processes. Drawing detailed DFDs for such processes is usually little more than “busy work.”

9-*
Primitive DFD
(see book for more readable copy)

*
No additional notes.

9-*
Specifying a Data Flow
Using a CASE Tool

*
Teaching Notes
The screen capture demonstrates the dialogue box used to insert the data structure for a data flow on a DFD. Each data flow would require a similar data structure to be specified.

9-*
Process Logic
Data Flow Diagrams good for identifying and describing processes
Not good at showing logic inside processes
Need to specify detailed instructions for elementary processes
How to do it?
Flowcharts & Pseudocode – most end users do not understand them
Natural English – imprecise and subject to interpretation

*
No additional notes.

9-*

Source: Adapted from Matthies, Leslie, The New Playscript Procedure, (Stamford, CT: Office Publications, Inc. 1977)
Problems with Natural English
Many do not write well and do not question writing abilities.
Many too educated to communicate with general audience
Some write everything like it was a program.
Can allow computing jargon, acronyms to dominate language.
Statements frequently have excessive or confusing scope.
Overuse compound sentences.
Too many words have multiple definitions.
Too many statements use imprecise adjectives.
Conditional instructions can be imprecise.
Compound conditions tend to show up in natural English.

*
Conversion Notes
The text on this slide has been shortened for the sake of readability. Refer to Figure 9-6 in the text for fuller explanations and examples.

9-*
Structured English
Structured English – a language syntax for specifying the logic of a process.
Based on the relative strengths of structured programming and natural English.

*
Teaching Notes
On the diagram, we recorded the Structured English inside the process box to reinforce the fact that the Structured English specifies the underlying procedure being executed by the process. In practice, the procedural specification is recorded in a data dictionary/encyclopedia that is separate from the actual diagram (but linked to/associated with the process “name” on the DFD).
If students are familiar with pseudocode, point out the similarities and differences between Structured English and pseudocode.

9-*
Structured English Constructs
(Part 1)

*
No additional notes.

9-*
Structured English Constructs
(Part 2)

*
Teaching Notes
Decision tables are useful for simplifying very complex combinations of conditions. They replace complex, nested if-then-else selection structures.

9-*
Structured English Restrictions
on Process Logic
Only strong, imperative verbs may be used.
Only names that have been defined in project dictionary may be used.
Formulas should be stated clearly using appropriate mathematical notations.
Undefined adjectives and adverbs are not permitted.
Blocking and indentation are used to set off the beginning and ending of constructs.
User readability should always take priority.

*
No additional notes.

9-*
Policies and Decision Tables
Policy – a set of rules that govern show a process is to be completed.

Decision table – a tabular form of presentation that specifies a set of conditions and their corresponding actions.
As required to implement a policy.

*
No additional notes.

9-*
A Simple Decision Table

*
No additional notes

9-*
Describing an Elementary Process Using a CASE Tool

*
No additional notes.

9-*
Data & Process Model Synchronization CRUD Matrix

*
No additional notes.

9-*
Process Distribution

*
No additional notes.

Concepts in Enterprise Resource Planning
Fourth Edition
Chapter Seven
Process Modeling, Process Improvement, and ERP Implementation

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Concepts in Enterprise Resource Planning, Fourth Edition
*
Objectives
After completing this chapter, you will be able to:
Use basic flowcharting techniques to map a business process
Develop an event process chain (EPC) diagram of a basic business process
Evaluate the value added by each step in a business process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Concepts in Enterprise Resource Planning, Fourth Edition
*
Objectives (cont’d.)
Develop process improvement suggestions
Discuss the key issues in managing an ERP implementation project
Describe some of the key tools used in managing an ERP implementation project

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Introduction
Tools that can be used to describe business processes
Flowcharts, event process chains
Not specific to ERP
Can help managers identify process elements that can be improved
Role of process-modeling tools in ERP implementation projects

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Process Modeling
Business processes can be quite complex
Process model: any abstract representation of a process
Process-modeling tools provide a way to describe a business process so that all participants can understand the process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Process Modeling (cont’d.)
Advantages of process models
Graphical representations are usually easier to understand than written descriptions
Provide a good starting point for analyzing a process
Participants can design and implement improvements
Document the business process
Easier to train employees to support the business process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Flowcharting Process Models
Flowchart
Any graphical representation of the movement or flow of concrete or abstract items
Clear, graphical representation of a process from beginning to end
Uses a standardized set of symbols
Process mapping
Often used interchangeably with flowcharting
Specifically refers to activities occurring within an existing business process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Flowcharting Process Models (cont’d.)
Figure 7-1 Basic flowcharting symbols
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Fitter Snacker Expense Report Process
Maria, Fitter Snacker salesperson
Completes a paper expense report after travel
Makes a copy for her records
Attaches receipts for any expenses over $25
Mails it to her zone manager at the branch office
Kevin, zone manager
Reviews expense report
Approves report or mails it back to Maria asking for explanation, verification, or modification
After approval, mails it to corporate office

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-2 Partial process map for Fitter Snacker expense-reporting process
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Fitter Snacker Expense Report Process (cont’d.)
Process at corporate office
Accounts payable (A/P) clerk
Process boundaries define:
Which activities are to be included in the process
Which activities are considered part of environment—external to process
All processes should have only one beginning point and one ending point
Decision diamond asks a question that can be answered with “yes” or “no”

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Extensions of Process Mapping
Hierarchical modeling: ability to flexibly describe a business process in greater or less detail, depending on the task at hand
Modeling software that supports hierarchical modeling
Provides user the flexibility to move easily from higher-level, less detailed views to the lower-level, more detailed views

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-3 Hierarchical modeling of Fitter’s expense-reporting process
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Extensions of Process Mapping (cont’d.)
Deployment flowcharting
Swimlane flowchart
Depicts team members across the top
Each step is aligned vertically under the appropriate employee or team
Clearly identifies each person’s tasks in the process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-4 Deployment, or swimlane, flowcharting of the Fitter’s expense report process
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Event Process Chain (EPC) Diagrams
Event process chain (EPC) format
Uses only two symbols to represent a business process
Matches the logic and structure of SAP’s ERP software design
Two structures: events and functions
Events: a state or status in the process
Functions: part of the process where change occurs

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Event Process Chain (EPC) Diagrams (cont’d.)
Figure 7-5 EPC components
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Event Process Chain (EPC) Diagrams (cont’d.)
EPC software
Enforces an event-function-event structure
Standardized naming convention for functions and events
Three types of branching connectors
AND
OR
Exclusive OR (XOR)
Basic EPC diagram can be augmented with additional information

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-6 Basic EPC layout
Figure 7-7 AND connector
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Event Process Chain (EPC) Diagrams (cont’d.)
Figure 7-8 OR connector
Figure 7-9 XOR connector
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-11 Possible connector and triggering combinations
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-12 Splitting and consolidating paths
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-13 EPC diagram with organizational and data elements
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Process Improvement
Value analysis
Each activity in the process is analyzed for the value it adds to the product or service
Value added is determined from the perspective of customer
Real value: value for which the customer is willing to pay
Business value: value that helps the company run its business
No value: an activity that should be eliminated

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Evaluating Process Improvement
Disrupting the current process to make changes can be costly and time consuming
Dynamic process modeling takes a basic process flowchart and puts it into motion
Uses computer simulation techniques to facilitate the evaluation of proposed process changes
Computer simulation
Uses repeated generation of random variables that interact with a logical model of the process
Predict performance of the actual system

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
ERP Workflow Tools
Workflow tools
Software programs that automate the execution of business processes and address all aspects of a process, including:
Process flow (logical steps in the business process)
People involved (the organization)
Effects (the process information)
ERP software provides a workflow management system
Supports and speeds up business processes

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
ERP Workflow Tools (cont’d.)
Workflow tasks: links that can include basic information, notes, documents, and direct links to business transactions
SAP system can:
Monitor workflow tasks
Automatically take various actions if the tasks are not completed on time

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-14 SAP ERP Workflow Builder screen
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-15 Create notification of absence screen
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-16 Manager’s Business Workplace with workflow task
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
ERP Workflow Tools (cont’d.)
Workflow provides a number of useful features
Employees can track progress of workflow tasks
System can be programmed to send reminders to employee(s) responsible for a task
For sporadic processes, workflow tools are a powerful way to improve process efficiency and effectiveness

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementing ERP Systems
Late 1990s: many firms rushed to implement ERP systems to avoid the Y2K problem
Since 2000: pace of implementations has slowed considerably
Most Fortune 500 firms have implemented an ERP system
Current growth is in the small to midsized business market
Implementation of ERP is an ongoing process

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
ERP System Costs and Benefits
ERP implementation is expensive
Usually ranging between $10 million and $500 million, depending on company size
Costs of ERP implementation
Software licensing fees
Consulting fees
Project team member time
Employee training
Productivity losses

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
ERP System Costs and Benefits (cont’d.)
Companies must identify a significant financial benefit that will be generated by ERP system
Only way companies can save money with ERP systems is by using them to support more efficient and effective business processes
Companies must manage transfer of data from old computer systems to new ERP system

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation and Change Management
Key challenge is not in managing technology, but in managing people
ERP system changes how people work
To be effective, change may have to be dramatic
Business processes that are more effective require fewer people
Some employees may be eliminated from their current jobs

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation and Change Management (cont’d.)
Organizational change management (OCM): managing the human behavior aspects of organizational change
People do not mind change, they mind being changed
If ERP implementation is a project that is being forced on employees, they will resist it
When employees have contributed to a process change, they have a sense of ownership and will likely support the change

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation Tools
Many tools are available to help manage implementation projects
Example: process mapping
SAP provides Solution Manager tool
Helps companies manage implementation of SAP ERP

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation Tools (cont’d.)
In Solution Manager, ERP implementation project is presented in a five-phase Implementation Roadmap:
Project Preparation (15 to 20 days)
Business Blueprint (25 to 40 days)
Realization (55 to 80 days)
Final Preparation (35 to 55 days)
Go Live and Support (20 to 24 days)

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Figure 7-17 Implementation Roadmap in Solution Manager
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation Tools (cont’d.)
Project Preparation
Organizing technical team
Defining system landscape
Selecting hardware and database vendors
Defining project’s scope
Scope creep
Business Blueprint
Produces detailed documentation of business process requirements of the company

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation Tools (cont’d.)
Realization
Project team members work with consultants to configure the ERP software in development system
Final Preparation
Testing the system throughput for critical business processes
Setting up help desk for end-users
Setting up operation of the Production (PROD) system and transferring data from legacy systems
Conducting end-user training
Setting Go Live date

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Implementation Tools (cont’d.)
Go Live and Support
Company begins using new ERP system
Monitoring of system is critical so that changes can be made quickly if performance of the system is not satisfactory
Important to set a date at which the project will be complete

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
System Landscape Concept
SAP recommends a system landscape for implementation
Three completely separate SAP systems:
Development (DEV)
Quality Assurance (QAS)
Production (PROD)
Transport directory: special data file location on DEV server

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
System Landscape Concept (cont’d.)
Figure 7-18 System landscape for SAP ERP implementation
Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
System Landscape Concept (cont’d.)
Development (DEV) system used to develop configuration settings and special enhancements using ABAP code
Changes recorded in transport directory
Changes imported into QAS system
QAS system: changes are tested
All settings, programs, and changes that pass testing are transported to PROD system
PROD system: used by company to run its business processes

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Summary
Business processes
ERP systems are designed to provide the information, analysis tools, and communication abilities to support efficient and effective business processes
Process modeling: fundamental tool in understanding and analyzing business processes

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Summary (cont’d.)
Process mapping: process-modeling tool that uses graphical symbols to document business processes
Other methodologies: hierarchical modeling, deployment flowcharting, event process chain diagramming, value analysis, and business process improvement
SAP’s Solution Manager: set of tools and information that can be used to guide an implementation project
Included in SAP ERP to help manage the implementation of ERP software

Concepts in Enterprise Resource Planning, Fourth Edition

*

Concepts in Enterprise Resource Planning, Fourth Edition
*
Summary (cont’d.)
SAP’s system landscape was introduced to show how changes to ERP system during implementation (and beyond) are managed
Most challenges to ERP implementation involve managing personnel and their reactions to the change, rather than managing technical issues

Concepts in Enterprise Resource Planning, Fourth Edition

*

Subject: Enterprise IT Application and Integration

609 Assignment 8

Assignment Description

Read reputable articles and briefly describe what is Business Process Modeling?

350+words APA format and two references please.

609 Discussion 8

Discussion Topic

Read reputable articles and discuss what is ERP Change Management?

200+words APA format and two references please