Transcript TwinSPIN Presentation 20120412 v9

Using Business Process
Modeling to improve the
quality of IT projects.
John Columbus, CISA
03/28/2012 version
Biography






Worked in IT since July 1983.
Currently full-time Six Sigma Black Belt for a Fortune 20
company in the IT area.
Graduated from the U of M MSSE program in May of
2010.
Certified Information Systems Auditor (CISA) since 2007.
Published 4 times by ComputerWorld.
The courses I am currently teaching at NHCC are: Web
Development Concepts, Word Basic 2010, Excel
Intermediate 2010 and SQL Introduction.
Agenda







Fundamental Concept
Main Concepts
Business Documentation
Documents created during design phase
UAT (User Acceptance Testing)
Go-Live
Project Example
Fundamental Concept
Business Steering Committee
Inputs: As-Is
Business
Process Models
Business
Requirements
Actual IT Project
Outputs: To-Be
Business
Process Models
Functional
System
Different BA Models



No Business Analyst (BA).
One BA.
Two BA’s.



Business Analyst working just for the Business
Unit
Second BA works for the IT group
In my experience, Either no BA or one BA
is the most common model.
Main Concepts

From the business point of view, they start with
working processes and need to end with working
processes.


IT projects improve processes or add new capability.
The absolute bottom line (no benefit but no loss).



“Do no harm first”
Document in the “Business” language
Must have at least *one* way that works for
each process.
Business Documentation

Before IT work, the Business Units need to document
(“As-Is” process mapping):




“Garbage In, Garbage out”




Processes
Inputs and outputs
In scope and Out of scope
Fix business process first (Six Sigma or Lean)
Quantify what needs to be improved.
Review various ways to improve the situation to balance cost
versus return.
Someone else’s statement: “If you automate a bad
process, you now have a more expensive bad process.”
Business Documentation

Process model benefits



Communicate to IT needed inputs, data modifications
and data outputs.
Standardizes business process before IT changes the
system and the business process.
Documentation is now in the “business” language,
allowing the various non-IT personnel to understand
where we are (“As-Is”) and where we want to go to
(“To-Be”).
Levels of Documentation

Deliverables:







SIPOC (Top level and Strategic level)
Process Maps (Tactical level but may include additional levels)
Requirements Template (to note locations or examples of process
inputs and outputs for reference)
Wish List Template (parking place for ideas of what the Business Unit
would like to explore).
Glossary Document – Describe the terms used in these documents so IT
people can understand what is meant.
Part of initial IT intake process.
IT designers also need the designs and specifications of any current
systems in use that may be interfaced to, updated or shut down.
SIPOC
Supplier
Input
Process
Appliance
Store
Coffee
machine.
Prepare
Coffee
Maker.
Grocery
Store
Coffee
filters
Insert filter.
Grocery
Store
Coffee
Measure
out coffee
Output
Brew coffee Used filter
and coffee
grounds
Department Cup
Store
Customer
Trash
Pour coffee
into clean
cup.
Serve.
One cup of
coffee.
Me.
As-Is Process Model (or map)
<Project Name>
<Project Code>
START
Build As-Is
Process
Maps of
current
Process.
As-Is
Business Process Model
Map: As-Is-1
10/28/2011 version
BPM’s are
not as
detailed as
requirements
.
Determine Validation testing for
maps: Customer Review, Direct
Observation of employees, Use
by employees performing their
jobs, etc.
<Process Name>
1) They don’t have to be
perfect.
2) As the BA learns more,
these must be updated to
reflect the correct As-Is or
To-Be process.
If reviewed with customers,
developers, testers, this can
be a peer review test.
During Validation,
Verify map
structure, syntax,
form.
Use checklists
during testing and
document at least
defect totals.
Still have
Significant
defects?
No
After completion, send out for final review,
change from Draft and change name in
SharePoint. Make sure to monitor
changes on these documents so they are
up to date but also everyone is told of
major changes.
Yes
Build
Business
Requirements
(from BPM &
with
customers)
Determine /
perform Validation
& Verification
techniques with
customer first
Note: All requirements
are “requirements”. All
must meet S.M.A.R.T.
standard and showing
business versus functional
versus technical are not
as important as clearly
showing what the final
project must deliver in a
measureable manner.
Update
documents /
record defect
totals (loop as
needed)
Determine / perform
Validation & Verification
techniques with whole
team that needs to
deliver these.
Repeat process with To-Be
BPM’s and Requirements.
Use them as a base and
then update from there.
Please note that Use Cases can be built rather than formal
requirements *as long as* both deliver S.M.A.R.T.
documents that developers and testers can use. Test
Cases that testers use can be built from requirements or
Use Cases (they’re basically use cases)
End
To-Be Process Model (or map)
<Project Name>
<Project Code>
START
Build As-Is
Process
Maps of
current
Process.
To-Be
Business Process Model
Map: TOBE-1
10/28/2011 version
BPM’s are
not as
detailed as
requirements
.
<Process Name>
1) They don’t have to be
perfect.
2) As the BA learns more,
these must be updated to
reflect the correct As-Is or
To-Be process.
If reviewed with customers,
developers, testers, this can
be a peer review test.
Determine Validation testing for
maps: Customer Review, Direct
Observation of employees, Use
by employees performing their
jobs, etc.
During Validation,
Verify map
structure, syntax,
form.
Use checklists
during testing and
document at least
defect totals.
Still have
Significant
defects?
No
After completion, send out for final review,
change from Draft and change name in
SharePoint. Make sure to monitor
changes on these documents so they are
up to date but also everyone is told of
major changes.
Yes
Example of new
step.
(new)
Build
Business
Requirements
(from BPM &
with
customers)
Determine /
perform Validation
& Verification
techniques with
customer first
Update
documents /
record defect
totals (loop as
needed)
Note: All requirements
are “requirements”. All
must meet S.M.A.R.T.
standard and showing
business versus functional
versus technical are not
as important as clearly
showing what the final
project must deliver in a
measureable manner.
Removed Text.
Added Text.
Determine / perform
Validation & Verification
techniques with whole
team that needs to
deliver these.
Repeat process with To-Be
BPM’s and Requirements.
Use them as a base and
then update from there.
Please note that Use Cases can be built rather than formal
requirements *as long as* both deliver S.M.A.R.T.
documents that developers and testers can use. Test
Cases that testers use can be built from requirements or
Use Cases (they’re basically use cases)
End
Requirements Template
Wish List Template
As-Is process validation.

Test the documents: “Conference Room Piloting” (source unknown)







Use completed documents to “run through” documentation.
Make sure documents cover 100% of process map paths.
Include worse case or all known unique situations.
May also use random sample.
Testing done in conference room with process maps and business
documentation. Each person has their part of the map they normally
due day-to-day.
Physically write on the process maps showing the start through to the
end (input to output).
Run through each scenario and see if the maps truly show how that
situation would work:




Do I have the right information to start with?
Does the process allow me to do all the changes I need to?
Does the process generate the right output for the next steps?
Input documents for IT Design can have the highest cost to fix if
found in System Testing. Test the documentation first.
Process Change Freeze





Stop process changes when possible during IT
project.
If changes must be made, update As-Is
documentation and check on IT impact.
In case of major process changes during Design,
re-do the Conference Room Pilots.
Targets do move in an IT project. We must
adjust our aim to compensate.
Communication with the Business is critical. You
can’t design for process changes you don’t know
about.
Documents created during design phase

“To-Be” documentation. How work is done after
Go-Live:





The As-Is documentation is copied and now called the
To-Be documentation.
Normally the Top Level and Strategic SIPOCs do not
change in an IT project.
The process maps must show how the process will
change.
To-Be Requirements are normal IT requirements but
start from the As-Is Requirements. Everything from
the As-Is documentation must have a home or
explanation on the To-Be documents.
IT may also add in requirements from current IT
systems that the new system will now provide.
Design Validation




Once the design is completed and verified, it’s
time to bring the new To-Be process models
back to the Business for validation testing.
Use a “Conference Room Pilot” and same test
cases from As-Is testing plus random samples.
Check out test cases and other parts of the
testing plan during conference room testing.
The Business stakeholders must understand that
this is their final check before the major costs of
coding and testing starts. Process defects or
requirement defects after this point start getting
very expensive.
Final approvals for the To-Be documents

There must be some point where changes are
locked down so the project can actually end.



With the To-Be process maps and requirements, we
have management sign-off that this is what they want
and agree to. If there are any changes after
agreement, the responsible Steering Committee will
need to approve the change.
With agreed-to process maps and requirements,
Development and Testing can begin their work in
earnest.
Once all of the work is nearly completion, then we
start the final phase which is User Acceptance Testing
(UAT).
User Acceptance Testing

At this point, this is where we must demonstrate that
every input, process map and output is able to be
delivered by the new system:





Tests must prove one good way to perform all business functions.
Great time to show the comparison of old screens and old reports to
their new replacements.
Excellent time to check all training materials.
From a Human-Computer Interface stance, have system users outside
of the development team take the training materials and see if they can
figure out how to do the new process.
This is the last point the Business Units have to determine if the new
processes will work and/or complete for all processes.
Go-Live process and beyond





Rename To-Be documentation as As-Is.
Make sure process is in place to maintain process documentation.
Review process documents quarterly for changes (both business and
software).
Update all process maps before changes are made to any system.
To maintain maps and UAT tests



Have business teams use these documents as their SOP.
Best way to keep documentation current and useful.
Greatly reduced time & cost to fix systems.
Recent project

In this recent project I’ll call “Project X”,
here is key factors:




Purchased system from vendor that is customizable.
Involved multiple departments.
Included several regulated activities with stakeholders
both inside and outside of the corporation.
Drivers were high quality and cost containment.
Current systems were in place to allow time to
complete the project.
Project X

As-Is side of Project X:







As-Is process took around 10 calendar weeks.
127 existing processes were reviewed.
39 processes were marked out of scope.
87 current process maps were reviewed with
needed improvements listed.
4 Top Level SIPOCs were created and 23
Strategic SIPOCs.
55 new process maps were created or
updated from existing maps.
52 requirement documents and 8 wish lists
were also created.
Project X

Key factors in this project:




This process was new to the team and was documented just
before using.
All the business users who created or updated the
documentation were not trained Business Analysts. They were
all trained in what was needed to be done, how to do it and how
to review it.
One BB / process mentor (me) was available to the project for
roughly 10 hours per week.
There was one Business Analyst on the project working roughly
20-40 hours to assist the teams on creating / updating their
documentation.
Project X

Key results:





Business teams had documentation to refer back to as needed
during process.
Vendor had process maps to use to help design process flows
within their system.
Team could map various vendor configuration documents to
process documents to keep everything updated.
System go-live was “successful with minimal issues”.
However, now we are doing a project to develop common
“terms” and a common “process”.
Project Y comparison






Request was made for financial control reports to help
current manual process.
Requirements were vague and process maps were not
completely business or technical.
Took 9 months to create reports, cost $500,000 and
reports were not usable.
Then created requirements in business language and
then created translation columns for IT.
Created report example business could understand and
added IT needed terms.
Reports should be re-done after an additional 6 months
and $300,000. If reports had been done on time and
correctly, could have found defects in code releases that
ended up costing several thousands of hours to manually
fix.
Questions?