Business Process Analysis

A business process is “a set of logically related tasks performed to achieve a defined business outcome." (Tom
Davenport). Work is organized and coordinated to produce a product or service. Examples: developing a new product;
ordering goods from a supplier; processing an insurance claim or loan application. Involves process steps, decision
steps, workflows and paths of material, information, and knowledge through these steps.
Single vs. Cross-function: Single function (e.g., accounting, insurance claims, sales, etc.). Cross-function (e.g., order
fulfillment).
Business Process Model (BPM): Visual representation of a business process (Cross Functional Flow Chart: Function
and Phase). If complex BPM, use sub-processes and include a master diagram to show all sub-processes.
Importance: System will automate 1 or more business process -> common ground with clients and get them to sign of
on it. BPM develops a vision of the work looking ONLY the business aspects of the process. Starting base
Standards BPM: OMG’s (Object Management Group) BPMN (Business Process Management and Notation, v2.0.2)

BPM Main Symbols Used in this Class BPM Main Symbols (Cont’d.)
• Terminator: start and end points in a process – start S ta rt
• Parallel Processing: use these to branch out into multiple
symbols have no input and exactly 1 output; end parallel flows or to merge them into a single flow.
symbols have one or more inputs and no output. End

• Process step: a specific step in the process – it can Note: Recent versions of Visio have eliminated the parallel
have one or more inputs, but it can ONLY have one processing symbol, but you can search for Transition
output (if more than one output are needed, use a symbols (forks and joins)
decision or fork symbol) • Off-Page Reference: use it to link to another page P.2

• Pre-defined process step: like a process steps but it • On-Page Reference: use it to link to other parts of the
actually incorporates multiple steps. They are useful to diagram within the page to avoid line crossings and A

simplify the diagramming of complex processes complex flows U s e t h is s y m b o l t o

• Decision: a question or a branching in the process flow Q u e s tio n ? Yes
• Annotations or callouts: used for comments m a k e a n n o t a t io n s
in y o u r B P M

it MUST have one input and one labeled output for each
possible decision outcome N o
• These are older legacy symbols frequently used in
flowcharts, which you can also use in BPM’s, but I suggest
• Process flow: a directed arrow that specifies the adding notations for these symbols for a non-technical or
process sequence younger audience :
• Functional bands or swim lanes: show which
F u n c tio n A

departments, units or functional roles are associated M anual

P ro c e s s
M a n u a l In p u t
P rin te d O u tp u t
S c re e n D is p la y D a ta D a ta

with different parts of the process

A
U
• Phase separators: use to differentiate different phases
of the process sequence A
U
• More BPM symbols:
http://www.breezetree.com/article-excel-flowchart-shapes.htm
21 22

Business Process Analysis (BPA): The study of the process steps, decisions and workflows in current BP w/ goal of
conceptualizing and recommending improved target process. Goal-address issues in business case (Problem &
solutions regarding cash flow, revenues, profitability, competitive, client satisfaction, product/service quality)
5 Steps to BP Redesign: (1) Develop biz vision & process objectives (cost-reduction, quality improvement), (2) Identify
process to be redesign (high impact focus), (3) Understand baseline processes (bottleneck), (4) Identify IT levers
(automation, analytics, tracking), (5) Design & develop target process.
BPA this class: (1) Develop a BPM baseline to understand how things are done, (2) Analyze to identify which steps &
workflows can be eliminated, add, merged, combined, split, re-organized, (3) Create target BPM.
Target BPM: (1) Existing process improvements: deliver the same type of process outcomes, but do it faster, more
efficiently, with less redundancy or waste, with better product/service quality, etc. (2) Process extensions: deliver new
or enhanced outcomes, by implementing new aspects to the process (e.g., premium services, customer loyalty
programs, new service lines, etc.). (3) Enhance process analytics: you can’t evaluate if there is a problem or if your
recommendations are efective unless you measure and analyze key process indicators (KPIs)
Analyze current process: Are there more than one step that could be merged? Can steps or paths be re-ordered, re-
assigned to other individuals or functional bands to make things more efficient? Can workflows be re-organized or re-
routed better? Sometimes the improvements are in the movement from one step to another, rather than the steps
themselves Are there steps in which efficiencies could be leveraged from IT?
Sequential vs. Parallel steps: Paths that process diferent units of analysis (batch of applications and a once-a-day
process) are modeled as parallel paths. Sequential paths analyze the process time for each step (For example, if a
company receives 80 applications a day P1 (apply for loan); P2 (Evaluate application) takes 1 hour; and P3 (Book loan)
takes 30 minutes, how many applications can you process in 1 day? How would you improve this process? How many
persons do you need?)
 Business Process Analysis
Six Sigma: Set of techniques and tools for continuous process improvement  more application n manufacturing and
aims to achieve zero-defect products. Improve quality by removing the causes of defects (reduced process cycle time,
reduced costs, increase customer satisfaction, increased profit) by collect and analyze process metrics.
KPI’s: Customer wait time, avg project time, time to process loan, loan approved rate, avg time to resolve a support
ticket. Collect lots of process data items, indicators and metrics (process time stamps, counts, frequencies, quantities,
volumes, classifiers (product types, customer categories, service levels)).
Process Object: Time to complete a group of steps / Time to complete a focal path in the process / Efficiencies within
a function lane / Efficiencies within a process phase / Avg time to complete a cycle.
System Requirements Analysis
Notation: to describe the symbols to use in models and other analysis artifacts UML (Unified Modelling Language)
Process: to define the sequence of activities and then design and implement the system UP (Unified Process)
UML: Main purpose is communication  describe object-oriented analysis (OOA) and design models (OOD).
Use Case: describes how actors interact with the system in specific functional scenarios. Use Case Diagrams: a visual
model that shows how all actors that interact with the system. Activity Diagrams: BPM-like that explain use case
workflows
Type of Requirements: Functional – behavioral (what the system needs to do), Non-functional – non-behavioral (The
qualities of the system (Speed, reliability, capacity, look and feel, usability, performance, operational, maintainability
and portability, security, cultural and political, legal). Analyst spend 70-80% on Functional.
Use Case Modeling: purpose to capture, document and communicate requirements

Use Case Diagram I llustration

System
Boundary A T M S y s te m Inside the Outside the
Definition System System
(External)
W it h d r a w s F u n d s M o n ito r s A T M S ta tu s
Human
A Use Case: “a sequence of transactions in a Actors

system whose task is to yield a result of measurable M a k e s D e p o s its R e p le n is h e s C a s h

value to an individual actor of the system” (J acobson, A T M S e r v ic e R e p

1995) (External)
C u s to m e r
M anages A ccount System
U p lo a d T r a n s a c t io n Actor
i.e., a collection of scenarios that describe actors D a ta

using a system to support a goal In q u ir e s C u s to m e r

A c t iv it y
Use Cases C u s to m e r A c c o u n ts S y s te m
i.e., a behavior of the system that produces a result
of value to the actor Bank M anager

Note how some arrows in this diagram have different direction than in the context
diagram because arrows have special meaning in use case diagrams!!
3 6

Use Case Model Definition
A Use Case Model: a set of artifacts, elements and
diagrams that describe the functionality of a system
as a collection of use cases
Use Case Model Artifacts: actors, use cases, use
case diagrams and any other diagram, model or text
item describing the system
7 9
Actors
• An actor is “anything outside of the system that
exchanges information with it, including users and
other systems” – Armour et. al. 2001
• An actor is “an entity that interacts with the system for
the purpose of completing an event” – J acobson 1992
• Actors play roles (e.g., client, salesperson, etc.)
• An actor is not a person, but the role the person plays
• A person can have many roles (e.g., user, manager)
• Or a role can be played by many persons (e.g., clients)
• An actor can be human or any (non-human) external
entity (e.g., external system, device, external service
organization) that the system will interact with

I mportance of Actors
• Systems need to provide value to actors
– i.e., identifying actors help find use cases
• Or actors need to provide service to the system
Actor Types
What is the type of actor based on its role in the system?
Primary Actor: one who obtains value from, and has
specific goals for the system
(e.g., an ATM customer needs to withdraw cash)
– As a first step, you need to identify all primary actors upfront because
the goal of your system is to deliver value to these actors

• Actors help analysts focus on how the system
will be used, not how it will be implemented
• Actors are external to the system, so they help
define the boundary of the system
10
Secondary Actor: one who provides service to the
system in one or more use cases, but does not have
specific goals for the system
(e.g., the bank’s customer accounts system)
– i.e., they are needed to provide value to primary actors
– i.e., they would not exist without primary actors or system
– You can discover these later  they don’t have goals 
they are secondary
11

Primary vs. Secondary Actors Meaning of the Direction of Arrows

Ø The distinction between primary and secondary actors only
matters while developing the use case model. Use
Case
Ø During modeling, you “identify” the primary actors, analyze Arrows have a DIFFERENT
their goals, and use this the information source to develop use meaning in Use Case
Diagrams than in context Actor triggers
cases (to fulfill those goals). diagrams the use case
Ø Secondary actors are “discovered” as you develop your use
cases.
Ø When the use case model is finished, primary and secondary Direction of arrows DO NOT Use
represent information flow Case
actors are “indistinguishable”.
Ø So, follow this use case discovery sequence: The system triggers
Instead, they indicate WHO the use case
ü Primary Actors Use Secondary INITIATES the use case
Check e-mail 
üTarget BPM Cases Actors
Incoming call ß

12 23

Arrows and Actor Types & Kinds Main Use Case Model Artifacts
Human Actors External System Actors • Use Case Diagram: shows the system boundary,
actors and all use cases involved
H S
Use Use • Use Cases: text descriptions that describe all
Case Case
possible scenarios of how actors interact with the
User initiates External system initiates use case: system to deliver the required system functionality
use case rarely happens  external system (i.e., functional scope).
must have this capability
• Activity Diagrams: use cases are text artifacts; an
H S
Use Use activity diagram (a UML artifact) is similar to a BPM
Case Case and can be used to describe a use case visually  if
a use case describes how the system handles a
Internal system Internal system initiates use case:
initiates happens often  the use case needs
group of process steps, you can think of it as a sub-
use case describe how to interact process. Activity diagrams are useful for use cases
with the external system with very complex logic and to diagram test cases.
24 18
1. Car Dealership
a. Improvement goal: reduce delivery transaction time
b. Recommendation: Have the customer (rather than the admin staf) fill out the application form in parallel with the
admin filling out the title form. Justification: Whether the Admin Staf or the Customer fill out the application form, it
is the Customer who needs to provide the loan application information. So, it would be more efficient to have the
Customer fill out the loan application, which he/she could even do online before coming to the dealership.
c. Student: What some financial institutions do is to pre-qualify applicants. For example, financial organizations will
pre-approve you up to a certain amount and cut you a blank check valid up to that amount. Once you enter the
amount and the dealer cashes the check, the loan is finalized.
a. Extension goal: Improve customer retention
b. Recommendation: notify existing customers when new vehicles arrive. Justification: If customers are satisfied with
their vehicle, they are likely to purchase the same brand again. It would help to have a communication program
notifying customers when new models arrive, and perhaps ofer other incentives and discounts. P5.11 (Order vehicles
to factory)  P5.12 (Summarize new models received)  P5.13 (Notify customers of new models).
a. KPI goal: Measure your improvement recommendation
b. Place time stamp before P6.1 (Notify customer that vehicle is ready) and after P6.4 (Sign paperwork). Justification:
since the goal is to reduce delivery transaction time, the diference between these two time stamps would give us the
total time it takes from the moment the customer is notified that the vehicle is ready, until the time the paperwork is
signed.

2. E’s Wheels
a. Improve Functionality: UC-07 Process Financing
b. Recommendation: Filling out the loan application forms in UC-07. The customer logs into the system via the web,
opens the financing form, completes all the required entries and submits the loan application for evaluation and
processing. The system does a pre-qualification and notifies the decision and the required supporting documentation
to the customer. When the customer furnishes the necessary supporting documentation, the admin marks the
application complete and the loan is finalized.
c. Justification: To make the customer an actor with a web interface to have the customer fill in the finance application
form. There is really no need to do this at the dealership, when the customer can do this before they come to the
dealership to finalize a purchase. The same thing is possible with the title form, which the customer can fill out the
relevant customer entries online, with the Admin filling in all the entries pertinent to the Admin.
a. Extend Functionality: To notify existing customers when new vehicles arrive. Customers can be given a log in ID and
password to connect with the dealership system online and sign up for notification of new vehicles arrivals, special
ofers for upgrading options, etc. Another possible extension would be to allow the customers to make their service
appointments online to install the optional features purchased, or even order new options for their existing vehicles
(roof rack, remote start). When goal of actor change (provide insurance, new vehicle announcements)
c. Justification: The customer does not use the dealership system in the original application. But there is no reason
why we can’t give the customer a log in ID and password and give them access to all kinds of information regarding
their potential purchase (vehicle searches, vehicle orders, availability of option parts in the service department,
promotion and coupons) and post-purchase (service scheduling for option installation, financing).
a. Analytics Capabilities: To measure the improved efficiency in processing customer applications for loans is simply to
time stamp when the customer applies for a loan online, when they start the finance paperwork in the Admin’s office
and when the transaction is concluded. This would make it very easy to compare processing times between customers
that let the Admin fill out the financing paperwork against those of customers that arrive to the Admin’s office with
the application already filled in online.
b. Second KPI: Once we give customers access to the dealership system online, the possibilities for data collection
grow rapidly. The web is ideal for gathering customer behavior data. You can count and time stamp any search for new
vehicles and whether the browsing of new vehicles notifications is associated with future purchases. When a customer
buys a new vehicle, you can trace their entire browsing history on the system’s site.

3. Music
 Relational Database Design I mplications about Rules 1 and 2
• For a database to be truly relational, it must comply A relational database must have:
with 12 rules defined by its inventor (Dr. E. F. Codd). • Tables: or “entities”
• No commercially available database complies with Every table has a unique name
the full set of rules, but the 12 rules are used as Ex. Students, Courses
guidelines for sound database design. • Fields: or “columns”, “attributes”
Every field has a unique name within the table
• Rule 1 states that data should be presented in tables
Ex. Students (StudentID, StudentName, Major, Address)
• Rule 2 states that data must be accessible without Ex. Courses (CourseNo, CouseName, CreditPoints,
ambiguity Description)
• We will talk more about other rules later (i.e., about • Records: or “rows”, “tuples”, “instances”
Every record is unique (has a unique field that identifies it)
entity integrity and referential integrity – stay tuned).
Ex. {“jdoe”, “John Doe”, “CS”, 5000 Forbes Ave.)
Ex. {“MGMT-352-001”, “MIS”, Fall 2002, “A great course”}

4 5

Entity I ntegrity
Relationships
• Is ensuring that every record in each table in the database can
be addressed (i.e., found) – this means that there each They describe how two entities relate to each other
record has to have a unique identifier that is not duplicate
or null (i.e., not blank) • Relationships in a database application can be identified
• Examples: every student has an AU ID; every purchase order following the VERBS that describe how entities are
has a unique number; every customer has an ID
associated with one another
Primary key (PK)  enforces Entity Integrity:
• Field or combination of fields that uniquely identifies a record • Examples:
in a table (e.g., AU user ID) students enroll in courses
• Entity integrity PK is not duplicate & not blank countries have cities, etc.
• PK can be:
– A single field (e.g., UserID), or
– Or more than one field (e.g., OrderNo, LineItem)

14 15

Referential I ntegrity Cardinality

• Is ensuring that the data that is entered in one table
is consistent with data in other tables
• Examples: purchase orders can only be placed by
valid customers; accounting transactions can only be
posted to valid company accounts
Foreign key (FK) enforces referential Integrity:
• Cardinality is an important database concept to describe how two
entities are related
• The Cardinality of a relationship describes how many instances of
one entity can be associated with another entity
• The cardinality of a relationship between two entities has two
components:
– Maximum Cardinality: is the maximum number of instances that
can be associated with the other entity – usually either 1 or many
(the exact number is rarely used)

• A field in a table that is a PK in another table – Minimum Cardinality: is the minimum number of instances that
can be associated with the other entity – usually either 0 or 1
• That is, a field that “must exist” in another table – Symbols:
• This is how referential integrity is maintained 0 or 1 0 or Many
1 and Only 1 1 or Many

17 21