Download
1 / 27
270 likes | 333 Views
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.
E N D
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 Outputs: To-Be Business Process Models Functional System Actual IT Project
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): • Processes • Inputs and outputs • In scope and Out of scope • “Garbage In, Garbage out” • 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.
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.
