Case Study: How Business Process Mapping Saved an IT Project Garrett Hunter Director, Information Technology Sony Pictures Entertainment [email_address]

Case Study Summary Explore how combining business process mapping techniques with use case development helped to successfully deliver an IT project Review how industry bodies of knowledge such as the Business Process Model Notation specification and the APQC Process Framework were leveraged to provide a common business process vocabulary for both the IT team and the business customers

Explore how combining business process mapping techniques with use case development helped to successfully deliver an IT project

Review how industry bodies of knowledge such as the Business Process Model Notation specification and the APQC Process Framework were leveraged to provide a common business process vocabulary for both the IT team and the business customers

Case Study Key Issues Explaining what a workflow is to business Translating workflows into system requirements Helping our business customers agree on the process Why "Good Enough" is OK

Explaining what a workflow is to business

Translating workflows into system requirements

Helping our business customers agree on the process

Why "Good Enough" is OK

Project Background The “Automated System for Ad/Pub Fulfillment” was to manage the fulfillment of marketing materials for all international offices & agents Marketing materials T-Shirts Keychains One Sheets And anything else a marketer can imagine

The “Automated System for Ad/Pub Fulfillment” was to manage the fulfillment of marketing materials for all international offices & agents

Marketing materials

T-Shirts

Keychains

One Sheets

And anything else a marketer can imagine

Project Background – Scope Primary stakeholders were interviewed to determine system features Online shopping Cart Product Master Receiving Inventory Management Additional interviews were conducted with users to generate use cases for system configuration and customization The new system would be replacing processes executed with spreadsheets, email, and paper Manually intensive processes

Primary stakeholders were interviewed to determine system features

Online shopping Cart

Product Master

Receiving

Inventory Management

Additional interviews were conducted with users to generate use cases for system configuration and customization

The new system would be replacing processes executed with spreadsheets, email, and paper

Manually intensive processes

Project Background – Delivery Methodology Scope and features were defined in an unstructured narrative style High level business modeling included via flowcharts Use cases were used to define development requirements A use case documents the step by step actions a user performs to complete a specific activity Majority of rigor placed upon developers to produce class diagrams and data models

Scope and features were defined in an unstructured narrative style

High level business modeling included via flowcharts

Use cases were used to define development requirements

A use case documents the step by step actions a user performs to complete a specific activity

Majority of rigor placed upon developers to produce class diagrams and data models

Project Background – Primary Deliverables Use Cases Diagrams Narrative Flow Charts

Missed Requirements After several months of analysis and development, the first release date was missed because the customer would not sign off on the system implying IT does not understand our business Further analysis revealed multiple requirements that were missed because business rules were not explored in depth Process for assigning order fulfillment was more complicated than initially thought The number & complexity of business rules was underestimated

After several months of analysis and development, the first release date was missed because the customer would not sign off on the system implying IT does not understand our business

Further analysis revealed multiple requirements that were missed because business rules were not explored in depth

Process for assigning order fulfillment was more complicated than initially thought

The number & complexity of business rules was underestimated

Short Term Corrective Steps Focused on modeling the end-to-end business processes to better understand what we were missing Conducted Bi-weekly meetings with customer to map their processes Helped to both rebuild credibility & capture an accurate understanding of all business rules Required the project to determine how much was “enough” detail to capture Started the process for defining a long term solution to ensure we would do better at understanding the business problem

Focused on modeling the end-to-end business processes to better understand what we were missing

Conducted Bi-weekly meetings with customer to map their processes

Helped to both rebuild credibility & capture an accurate understanding of all business rules

Required the project to determine how much was “enough” detail to capture

Started the process for defining a long term solution to ensure we would do better at understanding the business problem

Process Mapping Success Able to describe the exact steps our customer performed as part of their work This allowed us to better empathize with their current challenges and demonstrate our intent to deliver a usable system Able to call out specific areas within the application that needed customization and which steps would be automated Customer VP personally expressed his gratitude that “IT finally understands what we have to go through”

Able to describe the exact steps our customer performed as part of their work

This allowed us to better empathize with their current challenges and demonstrate our intent to deliver a usable system

Able to call out specific areas within the application that needed customization and which steps would be automated

Customer VP personally expressed his gratitude that “IT finally understands what we have to go through”

Tips for Ensuring Success Get them all in the same room / on the same call Focus on the person actually performing the work Not their supervisor / boss Get agreement on the start and end points of the process Helps to set the scope of the process mapping Get agreement on the inputs & outputs Critical to finding all handoff points and involved parties Be transparent, show them your models

Get them all in the same room / on the same call

Focus on the person actually performing the work

Not their supervisor / boss

Get agreement on the start and end points of the process

Helps to set the scope of the process mapping

Get agreement on the inputs & outputs

Critical to finding all handoff points and involved parties

Be transparent, show them your models

Long Term Corrective Steps Create guidelines on how to link business processes to system requirements Traceability is a powerful control to ensure the team is delivering what the customer expects Develop business modeling as a discipline and not a byproduct Traditionally, we emphasized delivering coding requirements & not process requirements Expand Our business modeling to include the entire business process, end-to-end, and not just discrete steps along the way Focus on automation objectives rather than coding requirements

Create guidelines on how to link business processes to system requirements

Traceability is a powerful control to ensure the team is delivering what the customer expects

Develop business modeling as a discipline and not a byproduct

Traditionally, we emphasized delivering coding requirements & not process requirements

Expand Our business modeling to include the entire business process, end-to-end, and not just discrete steps along the way

Focus on automation objectives rather than coding requirements

Creating a set of Guidelines Projects were using numerous tools and diagramming techniques to document business process models Quality of deliverables too dependent on the whims of the analyst Needed an approach that would appeal to the widest audience Needed something that was widely understood outside of The Company It needed to be compatible with our current development methodology based on use cases

Projects were using numerous tools and diagramming techniques to document business process models

Quality of deliverables too dependent on the whims of the analyst

Needed an approach that would appeal to the widest audience

Needed something that was widely understood outside of The Company

It needed to be compatible with our current development methodology based on use cases

Diagramming Candidates The Business Process Modeling Notation (BPMN) specification Sponsored by the Object Management Group, it offered a way to standardize our diagrams Notation similar to our existing use of swim lane / workflow diagrams Unified Modeling Language (UML) The standard in object oriented development it offered a number of related models for developing requirements Activity diagrams closest to what we would need

The Business Process Modeling Notation (BPMN) specification

Sponsored by the Object Management Group, it offered a way to standardize our diagrams

Notation similar to our existing use of swim lane / workflow diagrams

Unified Modeling Language (UML)

The standard in object oriented development it offered a number of related models for developing requirements

Activity diagrams closest to what we would need

A Best-of-Breed Solution BPMN offered the best combination of flexibility and standardization to link process models to software design Standardized diagram symbols Required the “who” in each diagram Easily understood by non-techies (for the most part) Already had BPM systems in house using the notation UML proved to be too focused on software development and required more training to educate the end consumer We would add additional notations such as inputs & outputs Borrowed from IDEF0

BPMN offered the best combination of flexibility and standardization to link process models to software design

Standardized diagram symbols

Required the “who” in each diagram

Easily understood by non-techies (for the most part)

Already had BPM systems in house using the notation

UML proved to be too focused on software development and required more training to educate the end consumer

We would add additional notations such as inputs & outputs

Borrowed from IDEF0

A Best-of-Breed Solution Use cases would be derived from specific process steps and continue to form the basis for system requirements Data models would be driven by inputs & outputs from the process diagrams We would create a process modeling style guide that would connect all the pieces together

Use cases would be derived from specific process steps and continue to form the basis for system requirements

Data models would be driven by inputs & outputs from the process diagrams

We would create a process modeling style guide that would connect all the pieces together

BPMN from the Start Project analysis would begin with a Level 1 process diagram using the BPMN 1.x specification Short list of core graphical elements meant a short learning curve Just the core set of elements for our initial release were used

Project analysis would begin with a Level 1 process diagram using the BPMN 1.x specification

Short list of core graphical elements meant a short learning curve

Just the core set of elements for our initial release were used

Business Modeling as a Discipline Using BPMN we started at a macro level and methodically decomposed any step in the process that was unclear Divided into three levels, increasing in detail Level 1 = Handoff Level Level 2 = Milestone Level Level 3 = Logic / Task Level We took our guidance from the book Workflow Modeling: Tools for Process Improvement and Application Development (A. Sharp, P. McDermott, Artech House, Inc. 2001) This rigor enabled the team to document the processes without becoming lost in unnecessary details

Using BPMN we started at a macro level and methodically decomposed any step in the process that was unclear

Divided into three levels, increasing in detail

Level 1 = Handoff Level

Level 2 = Milestone Level

Level 3 = Logic / Task Level

We took our guidance from the book Workflow Modeling: Tools for Process Improvement and Application Development (A. Sharp, P. McDermott, Artech House, Inc. 2001)

This rigor enabled the team to document the processes without becoming lost in unnecessary details

Level 1 – Handoffs Map enough of the processes to understand what we missed Keeps us focused on what happens Start at a level where you can focus strictly on the handoffs between people participating in the process 1 Organize daily service order fulfillment schedule Explored in Level 2

Map enough of the processes to understand what we missed

Keeps us focused on what happens

Start at a level where you can focus strictly on the handoffs between people participating in the process

Level 2 – Milestones Next we selected a process step & focused on documenting milestones within that step Illustrates decisions that affect the flow in a significant way The process shown here is derived from a single step 1.1 Create Distribution List Explored in Level 3

Next we selected a process step & focused on documenting milestones within that step

Illustrates decisions that affect the flow in a significant way

The process shown here is derived from a single step

Level 3 – Logic / Tasks Depending on complexity we would further break down each step to get to the how This is the first time we get to the procedural level This level of modeling maps closely to the steps within a use case Naming convention tells the reader this was derived from a higher level model 1.1.1 Create Shipping List from Premium Orders

Depending on complexity we would further break down each step to get to the how

This is the first time we get to the procedural level

This level of modeling maps closely to the steps within a use case

Naming convention tells the reader this was derived from a higher level model

Process Step Naming Conventions Avoid using ambiguous terms such as process or manage The diagram being created is the process Always use a verb – noun combination Create distribution list Pick order Pack order Use only one verb at a time Using multiple verbs can hide your meaning an complicate the diagram

Avoid using ambiguous terms such as process or manage

The diagram being created is the process

Always use a verb – noun combination

Create distribution list

Pick order

Pack order

Use only one verb at a time

Using multiple verbs can hide your meaning an complicate the diagram

Connecting to System Requirements Our process diagrams became the agreement (aka requirements) between project and our customer Each step in the process diagram had the potential to be a use case Use cases continued to be the requirements between business analyst & developer Use case packages (in keeping with UML) were driven by how we organized our process models

Our process diagrams became the agreement (aka requirements) between project and our customer

Each step in the process diagram had the potential to be a use case

Use cases continued to be the requirements between business analyst & developer

Use case packages (in keeping with UML) were driven by how we organized our process models

A Style Guide to Bind Them All To be truly successful this needed to be a sustainable process Tool agnostic process modeling style guide developed to reduce complexity by limiting which elements from the BPMN spec would be used Our team lacked experience modeling processes and needed guidance before descending into analysis paralysis Topics covered include Acceptable graphical elements Diagram naming conventions Process step naming conventions

To be truly successful this needed to be a sustainable process

Tool agnostic process modeling style guide developed to reduce complexity by limiting which elements from the BPMN spec would be used

Our team lacked experience modeling processes and needed guidance before descending into analysis paralysis

Topics covered include

Acceptable graphical elements

Diagram naming conventions

Process step naming conventions

Traceability USE CASE Basic Flow Do this Do that Stop here Data Models Process Models

USE CASE

Basic Flow

Do this

Do that

Stop here

Explaining Our Approach to the Customer Never used technical terms such as BPMN, use case, or activity diagram Interchangeably called our BPMN diagrams “process maps”, “workflow diagrams”, and “process models” Explained the diagrams as step-by-step pictures of who in their organization does what Kept the diagrams as uncluttered as possible to keep the discussions focused on the work being performed

Never used technical terms such as BPMN, use case, or activity diagram

Interchangeably called our BPMN diagrams “process maps”, “workflow diagrams”, and “process models”

Explained the diagrams as step-by-step pictures of who in their organization does what

Kept the diagrams as uncluttered as possible to keep the discussions focused on the work being performed

Business Process As Release Driver 10/22 11/26 11/19 11/12 11/5 10/29 10/15 10/8 10/1 10/22 11/26 11/19 11/12 11/5 10/29 10/15 10/8 10/1 Release 1.4.0 (Clients) Release 1.5.0 (Work Orders) Release 1.6.0 (Pick / Pack & Logistics)

When is “Good Enough” OK? Good enough is OK when… Lives are not at risk Financial statement accuracy is not at risk Business processes are vaguely defined The business is undergoing radical change The very act of implementing a new system and automating numerous manual processes would change the business in ways we could not predict Better to release early and often if possible

Good enough is OK when…

Lives are not at risk

Financial statement accuracy is not at risk

Business processes are vaguely defined

The business is undergoing radical change

The very act of implementing a new system and automating numerous manual processes would change the business in ways we could not predict

Better to release early and often if possible

Organize and Baseline the Models We used the APQC Process Classification Framework to organize our business processes The taxonomy provided us a structure to catalog each process such that we could baseline them against other business units within The Company For example, the distribution of DVDs in our Home Entertainment division © 2006 APQC (www.apqc.org)

We used the APQC Process Classification Framework to organize our business processes

The taxonomy provided us a structure to catalog each process such that we could baseline them against other business units within The Company

For example, the distribution of DVDs in our Home Entertainment division

After Applying the APQC PCF 4.0 Deliver Products and Services 4.4 Deliver Product Service to Customer 4.4.3 Provide the service to specific customers 4.4.3.1 Organize daily service order fulfillment (Level 1) 4.4.3.1.1 Create Distribution List (Level 2) 4.4.3.1.1.1 Create Shipping List from Premium Orders (Level 3) Notice the concept of levels is subjective This challenge never goes away Always important to pick your perspective and be consistent

4.0 Deliver Products and Services

4.4 Deliver Product Service to Customer

4.4.3 Provide the service to specific customers

4.4.3.1 Organize daily service order fulfillment (Level 1)

4.4.3.1.1 Create Distribution List (Level 2)

4.4.3.1.1.1 Create Shipping List from Premium Orders (Level 3)

Notice the concept of levels is subjective

This challenge never goes away

Always important to pick your perspective and be consistent

Benefits of a Classification System Standardizing process names enables us to compare processes across the enterprise Enables us to see repeating patterns across business divisions Helps to normalize technology portfolios by consolidating systems when possible Allows us to compare ourselves to external organizations

Standardizing process names enables us to compare processes across the enterprise

Enables us to see repeating patterns across business divisions

Helps to normalize technology portfolios by consolidating systems when possible

Allows us to compare ourselves to external organizations

References Sharp, A. & McDermott, P. Workflow Modeling: Tools for Process Improvement and Application Development , Artech House, Inc. 2001 BPMN 1.0 , BPMI.org, 2004, Object Management Group, 2006, ( www.bpmn.org ) Rational Unified Process , IBM, 2006 ( www.ibm.com/rational ) National Institute of Standards and Technology, Integration Definition For Function Modeling (IDEF0) , NIST FIPSP183, 1993 ( http://www.itl.nist.gov/fipspubs/idef02.doc ) APQC, APQC Process Classification Framework v4.0.0 , APQC, 2006 ( www.apqc.org )

Sharp, A. & McDermott, P. Workflow Modeling: Tools for Process Improvement and Application Development , Artech House, Inc. 2001

BPMN 1.0 , BPMI.org, 2004, Object Management Group, 2006, ( www.bpmn.org )

Rational Unified Process , IBM, 2006 ( www.ibm.com/rational )

National Institute of Standards and Technology, Integration Definition For Function Modeling (IDEF0) , NIST FIPSP183, 1993 ( http://www.itl.nist.gov/fipspubs/idef02.doc )

APQC, APQC Process Classification Framework v4.0.0 , APQC, 2006 ( www.apqc.org )