Transcript business rules (ground level)

Defining Business Requirements Through Business Process Mapping
Kathy O’Brien, Senior Business Analyst at Merck
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.
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
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
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.
Demo in Blueprint
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
Synopsis – In Blueprint
Synopsis – In Word Template
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
SIPOC – In Blueprint
SIPOC – In PowerPoint
Workflow
• Created a workflow to show the process
overview (5,000 foot level)
• Used the Sub-Process features to dive into subprocesses (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
Workflow Overview – In Blueprint
Workflow Sub-Process – In Blueprint
Workflow – In Word Template
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
Business Rules – In Blueprint
Business Rules – In Word Template
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.
Questions?