PMISV Symposium Presentation

Copyright ©2010 by Ivars Lenss, PMP, CSM

Business Process

Implementation Challenges in

Large Enterprises

Presented By

Ivars Lenss, PMP, CSM

[email protected]


THE “SILO EFFECT”

• The “Silo Effect” is an impediment to

communication because it isolates

individual processes.

• The “Silo Effect” can produce multiple

interpretations of the same requirement.

• Process improvement can break down the

walls that are erected by the “Silo Effect”.


• An enterprise is a set of related elements that perform functions not performable by the elements alone.

• A system produces things (products or services) that are delivered to elements in the enterprise.

• A business process is a set of activities that respond to a business event and produces a business response.


PURCHASING A BOOK ONLINE

BUYER

SELLER

PLACE

ORDER

RECEIVE

BOOK

RECEIVE

RECEIPT

MAKE

PAYMENT

CONFIRM

ORDER

RECEIVE

PRICE

RECEIVE

ORDERSHIP BOOK

SEND

RECEIPT

RECEIVE

PAYMENT

CALCULATE

PRICE

CONFIRM

INVENTORY


Black-Box System Model (Functional Perspective)

• Addresses external behavior of the system.

• Models the using and controlling of the system.

• Models the interpretation of a requirement.

• The behavior of the system is brought about by

manipulating its inputs.


White-Box System Model (Constructional Perspective)

• Addresses internal behavior of the system.

• Models the construction and operation of the system.

• Models the implementation of a requirement.

• The behavior of a system is brought about, and consequently explained, by its construction and operation.


BASIC SYSTEM DESIGN PROCESS

object system

(OS)

using system

(US)

function of

the OS

New business requirements specify

processes to be implemented in the OS

These requirements create a need in the using system (US)

of an object system (OS) to implement the requirements

determine

requirements

construction

of the USdevise

specifications

construction

of the OS

Portions ©2008 ACM

Used by permission



object system

(OS)

using system

(US)

function of

the OS

determine

requirements

construction

of the US

First, one analyzes the business requirements of the OS

in terms of a white-box model of the of the US

devise

specifications

construction

of the OS

Portions ©2008 ACM

Used by permission



object system

(OS)

using system

(US)

function of

the OS

determine

requirements

construction

of the USdevise

specifications

construction

of the OS

The next basic design step is to devise specifications for the

construction and operation of the OS, in terms of a white-box

model of the OS (construction design).

Portions ©2008 ACM

Used by permission



object system

(OS)

using system

(US)

function of

the OS

determine

requirements

construction

of the USdevise

specifications

construction

of the OS

The US business requirements refer to the function and the behavior

of the OS, and are thus in terms of a black-box model of the OS

Portions ©2008 ACM

Used by permission


BUSINESS REQUIREMENTS ARE

BUSINESS RULES

• Business requirements are either business rules, or they become rules once implemented.

• Business requirements define what shall occur in response to a given business event.


INPUT DATASYSTEM

(BUSINESS PROCESS)

TOP-DOWN SYSTEM VIEWVIEWS A SYSTEM IN TERMS OF BUSINESS EVENTS AND BUSINESS PROCESSES

CHOOSE THE BUSINESS

PROCESSES OF INTEREST

12

DETERMINE WHAT BUSINESS EVENTS TRIGGER

THE BUSINESS PROCESSES OF INTEREST.

DETERMINE HOW THESE EVENTS ARE

REPRESENTED IN THE INPUT DATA.

EXPECTED RESULTS ARE

REPRESENTED IN THE OUTPUT DATA

3

OUTPUT DATA


OUTPUT DATASYSTEM

(BUSINESS PROCESS)

BOTTOM-UP SYSTEM VIEWVIEWS A SYSTEM IN TERMS OF BUSINESS RESPONSES TO BUSINESS PROCESSES

CHOOSE THE BUSINESS

RESPONSES OF INTEREST

1

DETERMINE WHAT BUSINESS

PROCESSES PRODUCE THE

BUSINESS RESPONSES OF INTEREST

2

INPUT DATA

EXPECTED RESULTS ARE

REPRESENTED IN THE INPUT DATA

3


SYSTEM

(BUSINESS PROCESS)INPUT DATA OUTPUT DATAOUTPUT DATA INFORMATION

I

N

T

E

R

P

R

E

T

A

T

I

O

N

OBJECTIVE,

UNAMBIGUOUS

OBJECTIVE,

UNAMBIGUOUSSUBJECTIVE

PRODUCING INFORMATION FROM DATA


SYSTEM

ASYSTEM

BO/P DATA I/P DATA

CROSS-SYSTEM DATA AND INFORMATION


SYSTEM

ASYSTEM

BO/P DATA I/P DATA

I

N

T

E

R

P

R

E

T

A

T

I

O

N

I

N

T

E

R

P

R

E

T

A

T

I

O

N

BUSINESS REQUIREMENTS ADDRESS INFORMATION. DATA MUST BE

INTERPRETED TO PRODUCE THIS INFORMATION.

THE INTERPRETATIONS MUST BE RECONCILED FOR THE REQUIREMENT

TO BE UNDERSTOOD AND IMPLEMENTED CORRECTLY IN BOTH SYSTEMS.

INFORMATION



SYSTEM

ASYSTEM

BO/P DATA I/P DATA

I

N

T

E

R

P

R

E

T

A

T

I

O

N

I

N

T

E

R

P

R

E

T

A

T

I

O

N

IDEALLY, THE TWO INTERPRETATIONS ARE IDENTICAL WITH RESPECT

TO THE INFORMATION FLOWING FROM SYSTEM ‘A’ TO SYSTEM ‘B’.

THIS IS NOT ALWAYS THE CASE, AND IS A SOURCE OF DEFECTS AS

NEW BUSINESS REQUIREMENTS ARE IMPLEMENTED.

INFORMATION



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED

A REQUIREMENT

IS IMPLEMENTED

PERFORMAN IMPLEMENTED

REQUIREMENT IS

PRESENTED FOR

VALIDATION

AN IMPLEMENTED

REQUIREMENT IS

VALIDATED

IMPLEMENT

REQUIREMENT

A VALIDATED

REQUIREMENT IS

DELIVERED TO

THE CUSTOMER

AN IMPLEMENTATION

OF THE REQUIREMENT

IS ACCEPTED BY THE

CUSTOMER

COMPLETE

Business Requirements Workflow Loop


A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED

A REQUIREMENT

IS IMPLEMENTED

PERFORM

IMPLEMENT

REQUIREMENT



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED

A REQUIREMENT

IS IMPLEMENTED


REQUIREMENT IS

PRESENTED FOR

VALIDATION

AN IMPLEMENTED

REQUIREMENT IS

VALIDATED

IMPLEMENT

REQUIREMENT



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED

A REQUIREMENT

IS IMPLEMENTED


REQUIREMENT IS

VALIDATED BY

THE CUSTOMER

IMPLEMENT

REQUIREMENT

AN IMPLEMENTED

REQUIREMENT IS

DELIVERED TO THE

CUSTOMER



A REQUIREMENT

IS STATED BY THE

CUSTOMER

REQUEST

A REQUIREMENT

IS NEGOTIATED

DEFINE

REQUIREMENT

NEGOTIATE

A REQUIREMENT

IS AGREED TO BE

IMPLEMENTED

A REQUIREMENT

IS IMPLEMENTED

PERFORM

IMPLEMENT

REQUIREMENT

AN IMPLEMENTED

REQUIREMENT IS

DELIVERED TO

THE CUSTOMER

AN IMPLEMENTATION

OF THE REQUIREMENT

IS ACCEPTED BY THE

CUSTOMER

COMPLETE



Quality Assurance from a Business

Requirements Perspective

• End-to-End Verification and Validation

– Simulate Business Events to trigger Business Responses.

– Verify expected results against Business Requirements.

• Designed to verify the Business of the Enterprise, that

business events and business responses occur

correctly.

• Focuses exclusively from the end user’s perspective.


Q&A and Comments

Ivars Lenss, PMP, CSM

PMISV Annual Symposium

September 20-21, 2010

[email protected]

mailto:[email protected]

Documents

PMISV Symposium Presentation