Defining Business Requirements T hrough Business Process Mapping

1. Defining Business Requirements Through Business Process Mapping Kathy O’Brien, Senior Business Analyst at Merck

2. My Background • I have over 15 years of experience in information technology, with over 10 years of concentration in business analysis in industries such as defense, financial, power, and pharmaceutical. • I am a currently a Lead Analyst at Merck & Co., Inc in West Point, PA. Merck is a global pharmaceutical • Our Vision - We make a difference in the lives of people globally through our innovative medicines, vaccines, and consumer health and animal products. We aspire to be the best healthcare company in the world and are dedicated to providing leading innovations and solutions for tomorrow. • Our Mission - To provide innovative, distinctive products and services that save and improve lives and satisfy customer needs, to be recognized as a great place to work, and to provide investors with a superior rate of return. • I lead requirements development efforts for various key initiatives in the Global Human Health IT organization, which supports sales and marketing functions at Merck. • I am an earnest contributor to HH IT BA Center of Excellence and an active member of the Greater Philadelphia Chapter of the IIBA.

3. Blueprint Experience • “Discovered” Blueprint at the Philly BA World in early 2008 • Conducted demos in 2008 of Blueprint to the COE • The COE overwhelmingly voted to pursue the use of the Tool • Started piloting in late 2008 with one project • Now using Blueprint on multiple project across 3 divisions • Run our own User Group with about 80 members • Have seen a number of major and minor releases to the tool • Presented process improvements realized from using Blueprint at both IIBA GPC and BA World

4. Our Project • Our project is create the next generation of existing application that supports a key business area at Merck: • Upgrade to new technology • Implement minor enhancements • Redesign key functions • Based on the attributes of the project and our stakeholders, we developed a business process oriented requirements approach • Our approach is based on Martin Schedlbauer’s PROMAP process modeling methodology that is outlined in his book “The Art of Business Process Modeling: The Business Analyst's Guide to Process Modeling with UML & BPMN” • Once we defined this approach, Blueprint became the obvious enabler

5. Our Process Approach • Martin Schedlbauer’s PROMAP process modeling methodology emphasized that process modeling is more than a simple flowchart. • AHA MOMENT! • Problem: Business process modeling is perceived as separate from requirements. • Realization: Business process modeling is not a distinct activity from business requirements. In fact, the business process artifacts ARE the business requirements and the BA does not need to restate the process in statement form. • We review the process model components put forth in the PROMAP methodology and based on the project and stakeholders selected: • Process Synopsis/SIPOC • Workflow • Business Rules • These artifacts are diverse (i.e. not all textual) which has benefits: • “Peel the onion”. Start high level and drill into details. • Enhance comprehension by making the requirements both textual and visual. This appeals to multiple learning styles.

6. Demo in Blueprint

7. Synopsis • Used Blueprint Custom Properties to create a process synopsis to gain agreement on the process essence (i.e. 10,000 foot level): • Name • Description • Participants • Inputs • Outputs • Result • Created a custom word template to export

8. Synopsis – In Blueprint

9. Synopsis – In Word Template

10. SIPOC • Reinforced the synopsis by flipping it on its side and making it visual using a Sigma Tool – SIPOC • Created in PowerPoint, loaded to Blueprint and linked to the process via the hyperlink capability

11. SIPOC – In Blueprint

12. SIPOC – In PowerPoint

13. Workflow • Created a workflow to show the process overview(5,000 foot level) • Used the Sub-Process features to dive into sub-processes (1,000 foot level) • Added high level data to the sub-processes to add a different dimension and aid in ensuring we have it right • Created in Blueprint’s Business Process module • Reviewed with the stakeholders via Blueprint to get a visual, interactive experience

14. Workflow Overview – In Blueprint

15. Workflow Sub-Process – In Blueprint

16. Workflow – In Word Template

17. Business Rules • Created textual requirements to capture the business rules (ground level) that constrain or influence the process • Traced back to Business Process • Created a custom property to flag the new requirements so they could be loaded to our product backlog • Created a custom word template to export

18. Business Rules – In Blueprint

19. Business Rules – In Word Template

20. End Result • Able to start at the highest level and iterate into details - “Peel the onion”. • Gain agreement at each level of detail. Less painful! • Solidify terminology early before used in many places. • Mixed visual and textual artifacts to support multiple learning styles and promote comprehension. • Fluid requirements that can be exported at any time in whatever form best meet the artifact being reviewed. • Business Requirements are captured in a way that reinforces the system is in place to support a set of business processes. Not IT system driven! • UAT can be driven from the business process.

21. Questions?