Applying BPM Methodology to Tackle the Complexity

MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.All other product or service names are the property of their respective owners. © Motorola, Inc. 2008

Tom JuddSr. Director, Product Development Quality

Master Black Belt, SSPDCorporate Quality Office

Applying BPM Methodology to TackleApplying BPM Methodology to TackleComplexity of theComplexity of the

Product Development ProcessProduct Development Process

Business Process Management SummitOctober 27-30, 2008 – Las Vegas


2

2008 BPM Summit

Mobile DevicesGlobal Leader in the Personal Communications Industry

MOTOZINETM

ROKRTM

RIZRTM

RAZR2TM MOTO QTM

H15TMS9-HDTM


3

2008 BPM Summit

Broadband Mobility Solutions

Home & NetworkMobility

Home Connectivity

IP-BSC-DO

Tower Base Stations & Broadband “Hot Spots”

EnterpriseMobility

POS & HandheldScanners

EnterpriseDigital Assistants

Government &Public Safety

IP Wireless Networks/Services

Tiered Subscriber Products


4

2008 BPM Summit

Business Process Management

BPMBPM

Disciplines/Functions

EngineeringSupply ChainMarketing FinanceHRIT...

Methods/Tools

Six SigmaLEANStage GatesStandards...


5

2008 BPM Summit

Product Development ProcessProduct Development is a Complex, Multi-Organizational Process

Engineering

Marketing

Mfg

Supply Chain

IndependentOrganizations

with a CommonGoal of Creating

a Product

But Also haveTheir “Silos” ofProcesses andManagement

ComplexityCompounded

By GlobalLocations &

Cultures

No Single Owner of the

ProductDevelopment

Process


6

2008 BPM Summit

The Notion of Different Architectural Structures

Applying an Architectural Approach to BPM

“Architecture” is Usually Thought of as the Aesthetics of the Building’s Exterior

But There are also other “Architectures”…

The Structural Steel(Shape & Size)

Deliveries, Parking,Services, etc.

(I/O Interfaces)

Internal Dynamics of the Residents

(Information Flow)

HVAC, Plumbing,Electrical Wiring(Performance & Functional)


7

2008 BPM Summit

Applying the Software Architecture Approach to BPM

Module Structure Assigns Areas of Functional Responsibility Defines Hierarchical Relationship between Functional Areas

Different Process Structures

Component-Connector Structure Maps the Process Flow thru the Multiple Areas/Components Identifies How Components and Areas Interact

Allocation Structure Mapping of Functional Areas to External Elements Defines Deployment & Implementation Environments


8

2008 BPM Summit

A View of a Structure Depends on the Intended RecipientViews Represent Structures:

Modular Views Decomposition View Input/Output View(s)

Component & Connector (C&C) Views Time Line View(s) Interaction View(s)

Allocation Views Deployment View Implementation View

Process Structure Views

Intended Recipients: Direct/Internal Stakeholders (Functional Leads, SLT, Process Members, etc.) Indirect/External Stakeholders (Customers, Suppliers, Wall Street, etc.)


9

2008 BPM Summit

Process Structure Views - 1st Level Company Level

Marketing

Manufacturing

Engineering

Program

Management

Supply ChainSales

HR

LegalFacilities

Sr. LeadershipTeam

Info Tech

Security

FunctionalServices

Interaction View(C&C Structure)

Implementation View(Allocation Structure)

Decomposition View(Module Structure)

Customers

Government

Banks

Suppliers

Standards

Wall Street


10

2008 BPM Summit

Process Structure View- 1st Level Company Level

RequirementsDocument






Deployment View(Allocation Structure)

Banks

Customers

Government

Suppliers

Standards

Wall Street

FunctionalServices

Marketing

HR

LegalFacilities

Sr. LeadershipTeam

Manufacturing

Engineering

Program

Management

Supply ChainSales

Info Tech

Security


11

2008 BPM Summit

Product Development Process

Combination of Several Company Functional Areas

Marketing

HR

LegalFacilities

Sr. LeadershipTeam

Manufacturing

Engineering

Program

Management

Supply ChainSales

Info Tech

Security

Identify Customer Needs

Concept Selection

Detailed Design

Optimize Design

Test Product

Launch Product

Marketing

Marketing

EngineeringSupply Chain& Program

Management

Collaboration of Functional Areas…No Single Owner…


12

2008 BPM Summit

Process Structure View- 2nd Level

MarketingEngineering

Program

Management

Supply Chain

Product Development








Customers

Suppliers

Standards

OEM’s

Sales

Mfg

Security

HRITSLTLegal

External

Internal


13

2008 BPM Summit

Process Structure View- 3rd Level Engineering Functional Area








R & D

Software

Systems

Engineering

Doc Control

Hardware

Tech Pubs

Config Mgmnt

External

Internal

Customers

Supply Chain

Mfg

Security

HRITSLTLegal

Marketing

Program Mgmt

Standards


14

2008 BPM Summit

Input/Output View

P-Diagram Method

ModuleInputs Main Outputs

Risks

ControlsSecondary Outputs


15

2008 BPM Summit

Input/Output View Engineering Module Analysis

EngineeringModule

• Marketing Req’mnts• R&D Technology• Concept Selection

• Design Practices• Analysis Methods• Process Standards

• Manufacturing Specs• Vendor Requirements• Technical Doc’s

• Design Unknowns• Key Personnel Leaving• Global Communication

• Engineering Drawings• Knowledge Gains


16

2008 BPM Summit

Time Line View – Product Development

Marketing Engineering Manufacturing

Supply Chain

Program ManagementModule Structure

Component- Connector Structure

Product Development Process Time Line

Allocation Structure


17

2008 BPM Summit

Time Line View – Engineering Module

Process Time Line

Systems Engineering

Process Configuration - Waterfall Design Method

PrototypeBuild & Test

Software Design

Architecture

Integration& Test

Design & Code

Hardware Design

Elec.Design

HardwareBuild & Test

Mech.Design

SUPPLY

CHAIN

PROGRAM

MGMNT


18

2008 BPM Summit

Time Line View – Engineering Module Process Configuration - Spiral Design Method

Final Release

StartDesign

SUPPLY

CHAIN

PROGRAM

MGMNT


19

2008 BPM Summit

Definition of a System

A System is Comprised of Three Fundamental Components:

People

SoftwareHardware

Interactions Need to be Identified & Managed


20

2008 BPM Summit

Hardware Team(s) Software Team(s)

Sub

syst

ems

System Hierarchy Allocation

System Requirements are Allocated toPhysical Subsystems & Functional Teams

Sys

tem


21

2008 BPM Summit

Software Team

Sub

syst

ems

Hardware Team

System Hierarchy Interactions

Discover Interactions by Decomposing Requirementinto Subordinate Functional/Performance Contributors

Sys

tem


22

2008 BPM Summit

Architecture Convergence Cycle

Views & Structures of an Architecture Provide Clear Communication for Stakeholders to Revisit the Requirements

Architecture Influences

Stakeholder Goals

Product DevelopmentOrganizations Goals

Process Environment

Requirements Process ArchitectureViews of Structures

Requirements may beRevised Based on

Reviews of the Views


23

2008 BPM Summit

Summary of Structures & Views

Mapping & Analyzing a Process using MultipleStructures & Views Minimizes Risks of Oversights

Primary Structures are: Module, Component-Connector & Allocation

Multiple View Types Associated with Each Structure

The View of a Structure Depends on the Intended Stakeholder

Views of Structures Define both the Statics & Dynamics of a Process

Documentation of Structures are Transferable & Reusable

Views Enable the Architecture Convergence Cycle


24

2008 BPM Summit

Product Development ProcessVarious Process Improvement & Governance Methods Exist

Process Improvement LEAN Six Sigma CMMI (Software) Change Management

Process Governance Stage Gates Technical Review Milestones Work Flow Management ISO/TSO/QS9000 Government & Industry (FDA, FCC, Mil Specs, etc)


25

2008 BPM Summit

Product Development Improvement – LEAN

LEAN is All about Removing Non-Value Add Process Steps, But… Requires a Stable, Repeatable, Disciplined Process


26

2008 BPM Summit

Product Development Improvement – Six Sigma

Six Sigma Removes Variability from a Process and Identifies Process Areas Ripe for Optimization

The DMAIC Problem Solving Method:

DDefineefine

MMeasureeasure

AAnalyzenalyze

IImprovemprove

CControlontrol

Identify the Problem Set & Stakeholder Requirements

Determine the Current Stateof the Process & Deliverables

Implement the Improvementswith Governance & Metrics

Determine the Root Causes forProcess “ilities” (Variability, Instability, etc.)

Use Methods & Tools to ReduceThe High Impact Process “ilities”


27

2008 BPM Summit

Product Development Improvement – Not Just Process A Perfect Process Alone will not Ensure Product Quality

Shift Defect Distributionvia Process Improvementusing DMAIC Six Sigma

Reduce Defects viaProduct Improvement

using SSPD

Pro

duct

Def

ects

Launch

Product Development Time Line


28

2008 BPM Summit

Product Development Improvement – SSPDSix Sigma Product Development Improves Product Quality

A set of Methods & Tools Integrated with the Product Development Process and

Functional Roles to Enable Improved Product Quality and Customer Satisfaction

ProductPrograms

Platform Programs

Hardware Design for Six Sigma (HDFSS)Software Design for Six Sigma (SDFSS)

Product Marketing for Six Sigma (PMFSS)

Portfolio Development for Six Sigma (PDFSS)

Technology Development for Six Sigma (TDFSS)Hardware & Software Design for Six Sigma (H&SDFSS)



29

2008 BPM Summit

Voiceof

Customers FocusGroups

Gemba

Interviews

Ethnography

CPM

Pugh

DFMEA

DesignSpecsQFDKJ

Surveys

(Consumers,Carriers,Business,

Technology)

TransferFunctions

DOE’s

RSM

ReliabilityAnalysis

MSA

Kano



A set of Methods & Tools Integrated with the Product Development Process and Functional Roles to Enable Improved Product Quality and Customer Satisfaction

“The CriticalFew High RiskRequirements”


30

2008 BPM Summit

Sr. Director, MD Mass Market ProductsThe DFSS program paves the way for improved quality and cycle-time of decision making during product development, resulting in improved product-cycle times and launch quality. Using the DFSS methods and tools on … programs were key contributing factors in enabling these programs to achieve their drive-to-schedule dates with NO hardware RASAs (Risk Assessed Ship Acceptance).

June, 2006: "This might sound trite, but the design philosophy behind DFSS (Design for Six Sigma) is simply what engineers are supposed to do. If you do the job right the first time, the probability of problems becomes smaller. Execution is easier." September, 2007: "Our investment in improvements on our core processes and using DFSS on new products is paying off."

Sr. VP, G&PS Engineering

8/06 9/06 10/06 11/06 12/06 1/07 2/07 3/07 4/07 5/07 6/07 7/07 8/07

Pro

duct

Lau

nch

Suc

cess

Met

rics



31

2008 BPM Summit

Tom JuddSr. Director, Product Development Quality

Master Black Belt, SSPDCorporate Quality Office

(847) [email protected]