Business Models 031307

Business Modeling Overview

Models are constructed based on a collection of information gathered from interviewing business units or by reviewing existing written documentation. This section focuses on the development of business models, specifically business process models that can be utilized in a process improvement initiative. Modeling a business process usually predicates a need to change an existing process or identify problems that need to be corrected.

Business process models are used as an effective way to visualize, organize and document the flow of data through processes that are performed within a business unit. These models display the data that a business area uses and how the processes transform data to produce deliverables. Specifically, business process models are constructed to provide a concise, unambiguous representation of a business in terms of:

the activities that a business performs the order in which those activities take place the inputs/outputs of activities relationships to other internal or external entities

The purpose of this section is to provide simple and easy guidelines for the development business models. The table below lists the model types that are described in further detail in this section.

Business Models Purpose

Business Interaction Scoping model that displays the hand off of deliverables and the interactions between internal and external entities.

Functional Decomposition Hierarchal model that displays the business domain and essential processes.

Data Flow How data is inputted, processed, and stored for a business domain.

Workflow Sequential flow of business activities and which entities will perform the work.

Business Process Management Methodology Page 3-19Section 3: Modeling Techniques Revised 03/13/07

Business Model Benefits

Modeling is an invaluable tool businesses can utilize to map out and change business processes prior to implementation. Although business process models inherit all of the benefits previously discussed in the Modeling Overview section, separate benefits of using process models include:

understand and analyze the current process re-design and improve a business process

blueprint for implementation definition of roles and responsibilities for activities in a process

communication tool to ensure that processes are understood across the organization

establish a link between the processes and the systems that support the processes

To model a business process, all of its details must be defined. A process contains activities in a specific order with a clear beginning and end, and clearly identified inputs and outputs, producing a deliverable to meet the business need. A business process has the following components:

specific inputs specific outputs relationship(s) with external entities activities performed in a specific order uses resources to complete the processes and activities produces a deliverable for internal or external entities

General Modeling Tips

No matter which business model type is developed, the following are some general industry standard rules and tips to consider when developing models:

Condense large models into several smaller ones. Organize diagrams left to right, top to bottom. Draw objects of consistent size. Avoid crossing data flow/workflow lines. If it can’t be avoided, draw one line so

that it “hops over” the other. Avoid diagonal or curved lines. Straight lines are easier to follow visually. Focus on content first, appearance second. Apply common business terminology.


Seek user input from the business area. Show only the information that is needed. Models with too many details are

difficult to read. Don’t be afraid to change the model, it will not be perfect in the first draft.

Completeness Criteria

Businesses contain complex processes. To manage complexity, multiple models are created through hierarchal decomposition, rather then having one large model.

Although there are few industry standards in place that address the question “How do you know when to stop modeling,” the completion criteria in the table below provides a concrete approach to validating and verifying business models that are developed. Determining if a model is complete includes three separate, individual completeness reviews. These reviews include: Internal Verification, External Validation and Standards Review. Many techniques can be used to complete each review to ensure models are complete, accurate, and consistent.

Each type of completion criteria is discussed in further detail below.

Business Process Management Methodology -21Section 3: Modeling Techniques Revised 03/13/07

Modeling Completeness Criteria

•Checklists•Peer review

5. Ensure that appropriate standards were employed in the design of the model (i.e., header & footer formatting).

Standards Review

•Checklists •Peer review•Subject Matter Expert review •Walk-throughs•Reference Model Comparison

3. Identify and incorporate all required inputs and outputs.

4. Review process against high level process goals and known business requirements.

External

•Desk review•Automated tool review•Checklists•Peer review•Subject Matter Expert review

1. Look for internal model consistency. 2. Identify and resolve orphans, black holes,

gray holes, miracle holes.

Internal

TechniqueGoalReview

How do you know when you are through?

Internal Verification

Review of models to ensure they are properly constructed. Examples of questions to ask in reviewing components:

Are there processes or data/workflow lines that are not connected to anything?

Are the data flows properly labeled? Are gray holes resolved? Does the information going in make sense to

produce what’s coming out of the process/activity? Are miracle holes resolved? Does a process have nothing going in, but all

outputs? Are the black holes resolved? Does the process have all inputs, but no

outputs identified? A good rule of thumb is that a diagram shouldn’t have more than 7 +/- 2

processes. Models should fit on one page. If the model is two pages and can not be

separated into smaller models, are the page connectors clear? Is the model leveled? Leveling ensures no new components, like external

entities and data/workflow lines, that are not already represented on the high-level model are added in the detailed models.

External Validation

Review of models to ensure that the business unit processes are accurately captured. Examples of questions to ask in reviewing components: Does the model accurately represent the business area? Is the model technically correct? Have all the inputs and outputs to a process been identified? Have all business unit interactions been identified?

Standards Review

Ensure the appropriate standards adopted by the Agency are applied. Specific Agency standards are discussed in the next section. Examples of questions to ask in reviewing components:

Does the title specify As-Is or To-Be? Is the model version included? Is the business unit name included? Is the date the model was created included?

Additional completeness criteria for specific business models are included under each model heading on the following pages.


Business Models

Previous sections have described a standard approach to Business Process Management (BPM) initiatives taken at the Agency. This section further expands that approach by outlining each type of standard business model that can be incorporated and used in reengineering projects. Utilizing the models described below becomes an important component to a successful BPM project.

Business Interaction Model

1.1 Purpose A Business Interaction Model provides a strategic view of the business and its interactions with respect to its suppliers, customers and business interfaces.

1.2 DescriptionA Business Interaction Model is a high level model that describes a business area environment with respect to the communication that occurs and the hand off of deliverables produced.

1.3 Key Model Components

Component Name Description

Internal/External EntitiesA source (supplier of a deliverable) or destination (customer

who receives information)

Business DomainThe functional area of the business used as the scope of a

process improvement project

DeliverableA work product produced as a result of business processes or

activities within a business domain

1.4 Usage Provides a strategic view of the business Profiles and scopes the business showing organization boundaries Displays a business area’s interactions with internal and external entities

1.5 Best PracticesBusiness Process Management Methodology Page 3-23Section 3: Modeling Techniques Revised 03/13/07

Avoid crossing lines on the model. If lines must cross, draw one line so it “hops over” the other.

External entities should be either internal or external in regard to the business domain, but not both.

Organizations that appear in the business domain may be both sources and recipients of deliverables.

Multiple deliverables between entities can be reflected in a high level single interaction.

1.6 Completeness Criteria Ensure that all resources that are needed to produce a deliverable are

included on the model

1.7 Model Example

The model below represents an example of a Business Interaction model.


Functional Decomposition Model (FDD)

1.1 Purpose

The Functional Decomposition Model provides a graphical representation of processes and activities necessary to satisfy a specific function within a business area or proposed solution.

1.2 Description

An FDD model is a hierarchal identification of processes and activities that exist within a business area. The model decomposes a businesses unit or specific function into sub-processes and individual activities that accomplish the business process. These levels of decomposition ensure all significant processes and sub-processes are covered. The structure of a FDD closely resembles an organization chart, the top level function or business unit appears at the top of the model and identifies the relationships between processes, sub-processes and activities. FDDs are technology independent, not implying how the process is completed and do not show the sequence of processes.


Component Name Description Naming Conventions

Function Highest level function, usually the business area, which are on-going and never complete.

Title case capitalization

Process

A set of activities that when completed will create or deliver a product or service. Essential processes must occur in order to satisfy the function

Verb-object structure

Activity

A specific low-level task performed by the business unit that needs to occur in order to satisfy a process. Also referred to as “elemental processes”



1.4 Usage

Define scope of business process improvement initiative Identify all essential processes that comprise the business function Feed into the development of a data flow diagram Communicate with business unit regarding their processes

1.5 Best Practices

Function should be the highest level shown on the model (top box) Second level should represent the essential processes Lowest level should represent elemental processes Technology independent Contain only processes specific to the business area Processes are named with verb/object. Avoid using “process” or “activity” in

the names.

1.6 Completeness Criteria

No more then 5 to 9 processes across and 5 to 9 process down Stop decomposition when displaying “how” the process/activity is

accomplished, rather then “what” is done Stop decomposition when displaying the technology used to complete the

process/activity


1.7 Model Example

The model below represents an example of a Functional Decomposition Diagram (FDD).


Data Flow Model

2.1 Purpose

To display how data is inputted, processed and stored for a business area.

2.2 Description

Data flow diagrams provide a graphical illustration of the movement of data between external entities, the processes and data stores within a business domain. They represent “what” the business area does, not “how” it does it.

Data Flow diagrams provide a visual representation of: External Entities that provide data to or receive data from Processes Data stores that store the data for later retrieval Data flows that move the data between external entities, processes and data

stores

The highest level of a data flow model, known as the context diagram, establishes the basic components of the business area. It identifies the business area as a single process with data flows coming from and going to external entities in which it interacts with. This single process also represents the boundary of a BPM project. A data flow model does not show the sequence that processes occur. The context diagram is then decomposed into additional diagrams that display additional levels of detail. Levels of decomposition include:

Context Level- overview of function, displays the inputs and outputs and how it interacts with its external entities. Scope of BPM project.

Level 1- Displays the major processes that comprise the overall domain, data flows and the addition of data stores.

Level 2- Displays additional detail by breaking down a higher level process from Level 1 into sub-processes/activities. Level 2 is normally sufficient for BPM projects.



The data flow diagram is comprised of the following elements:

Components Name Description Naming Conventions

Data Flow

Represents the movement of data from between the process, entity and data

store. The data flow is named to reflect the data used. Also referred to as “data

in motion.”

Lines are labeled with a description of the data being moved, by using a noun phrase.

Usually lower case

Data Store

A holding place for information for later retrieval. Also referred to as “data at rest.” Data stores do not imply the physical medium in which the data is

stored (i.e., database)

Plural noun Capital letters

Process

Work that transforms the data it receives as an input and generates

different data as an output.


External Entity

A source (provide information) or destination (receive information) of a

data flow which is outside the business area in study. Representing business

units, systems, roles, etc that the business area interacts with. External entities can be sources or destinations

of the data flows.

Singular Noun or noun phrase

2.4Usage

Understanding of the range of data in a business domain Clarification of boundary between the business area and the outside environment

it interacts with Validation of all data inputs and outputs of a process Validation of functional requirements in lower level diagrams


Communication tool Input for workflow modeling

2.5Completeness Criteria

No more than 9 processes should appear in one data flow diagram The diagram should fit on one page Technology independent Only one process is included on the context level diagram Decomposed data flow models inherit all data flow lines from the context level

2.6 Best Practice

Data flows represent the inputs/outputs of Processes should have at least one input and one output Data store should have at least one input and one output Data flows cannot flow directly between a data store and another data store Data stores are not shown on the context level External entities should not have data flows directly to a data store Data flows between external entities are out of scope and should be represented

with another line style, if it is necessary to display on the model

2.7 Model Example

The model below represents an example of a context level data flow diagram.


Approved IR

Wor

k R

eque

sts

BP

I Ser

vice

sP

ropo

sals

Forms and Procedures

"Request for BAServices"

Proposals

OCI BPI

Business UnitsGovernanceCouncil

Help DeskThe Zone


Workflow

3.1 Purpose

Workflows are beneficial in representing the As-Is environment as well as identifying improvements to be incorporated into an envisioned To-Be processes. Workflows display the following:

how work is accomplished how various tasks interact with each other how information flows through the business area how actors are involved with each activity

3.2 Description

Workflow models are also referred to as process maps or activity diagrams. They show the sequence of activities in a process along with inputs, outputs and decisions that affect the flow of work along the way. Workflow models assist in visualization of a complex variety of relationships and dependencies in a process.

Workflow models are initially created at a high –level and decomposed into detailed workflows pertaining to a specific activity from the larger process. By creating several layers of models, different workflows can be created to handle different types of problems instead of one complex workflow with multiple decision points.

Workflow models are tools that can be used to locate areas of process improvement in BPM initiatives. When comparing models, As-Is vs To-Be, the workflow models should be a same level of detail. Example of questions that could identify areas for process improvement are:

Are there too many actors involved? Are there unnecessary loops in the process? Are there too many handoffs? Are the process steps value added? In other words, would someone pay to

have this completed? Could steps occur in parallel? Are there bottlenecks in the process?



The workflow diagram contains the following elements:

Component Name Description

Decision PointRepresents a fork in the process where the flow of

work can proceed in two or more separate or concurrent work flows

Sink Flow ending point(s)

Source Trigger(s) to start flow of work

Activity

Individual tasks need to be completed in order for entire business process to be completed. Should be

named using the active voice.

Workflow Lane Horizontal divisions that represent who is responsible to perform the activities. Also referred to as swim

lanes. Displays handoffs.

Work Flow Arrows that display the sequential direction of work

Junction Multiple workflows join together or one workflow splits into multiple paths

Roles The job functions, external entities involved with the business process. Roles are the performer of the

activities that are named in the workflow lanes. Also called “actors”

3.4 Usage


Analyze areas for process improvement Redesigning business processes to formulate a To-Be design Correct inconsistent processes Verification of processes Support of re-designed business processes by documenting and analyzing

processes to find opportunity for process improvement

3.5 Best Practices

Show sequence of activities from left to right, top to bottom List activities/tasks in sequential order Swim lanes should be in a logical order Each swim lane should identify who performs the activities. Therefore, activities

do not need to mention who is performing the task. Workflows should start with “sources” & end with “sinks” Decision points can be binary(yes/no) or multiple decisions coming from 1 point Avoid loops in workflow process Activities can be either sequential or simultaneous Avoid crossing workflow lines The model title should identify if the As-Is or To-Be process is represented Enter a key if additional symbols other then components listed above are used

3.6 Completeness Criteria Less then five swim lanes for one workflow model


3.7 Model Example

The model below represents an example of a workflow model.

PMO

Leadership

Knowledge Managers

Supervisors

Business Analysts

Business Units

CompletedInvestment

RequestApproved Work Effort Assigned Task

Draft Proposal

Yes,

App

rove

d Pr

ojec

t

No, Rejected

Yes, Approved Enhancement

No, Sent for Rework

Assign to BA

Review IR InterviewBusiness Unit

Evaluate IR andprioritize

Draft ProposalDocument

ValidateProposal

Present forFinal Approval

Conduct QA

Approve

Prioritize andAssign

Prioritize andAssign*

GovernanceRepository

Determine NextSteps


Additional Models

4.1 Other Business Models

Depending on the business process improvement initiative, additional models may need to be developed to show the business from different perspectives. The table below includes secondary models that may also be used, if necessary.

Additional Business Models Description

Organization Identifies entire or portion of the reporting structure of an organization

Location Hierarchal model that displays goals and associated metrics for a business area

Use Case Identifies how organization components and systems interact with a business process/activity in order to receive a deliverable

StateChart Depicts the lifecycle of instances for a particular business object and the steps it takes to transition from state to state

Rule Hierarchal model that displays business area rules

Goal Hierarchal model that displays goals and associated metrics for a business area

Opportunity Hierarchal model that displays recorded opportunities and their associated cost/benefit information

Problem Hierarchal model that displays problems experienced for a business area

Entity Relationship Diagram Representation of a data structure and the many rules that govern a particular business area.


Business Models 031307

Documents

Transcript of Business Models 031307