2022_0829 Getting Started with BPM in Requirements Specification_V11

Getting Started with BPM in Requirements Specification

Introduction

Intro paragraph around BPM,

what it is, and why there is a document series…  Use this paragraph to call out the intended audience

What is a “Getting Started” Guide?

Who should read this? 

Requirement specifications are critical in the development of responsive and effective software solutions. The BPM requirements specification process is designed to help you and your organization become more effective in designing and developing solutions that will meet the needs of your end users.  Leadership needs to understand the how and why of this requirement process, but they are not the ‘doers’. Engagement of the people in your organization who own the processes and the people responsible for the products and services that use these processes is essential to success. These people are found in multiple roles, including business analysts, functional subject experts, business line owner, project/product team technical leadership and business architects. Not all of these roles may exist within your organization—but, if they do, they should be reading this how to guide!

How will this help you?

Many organizations recognize that successfully realizing process improvement and fostering effective HIT solutions is predicated on their ability to adequately express their needs and requirements, but lack the clarity how to improve.  This “Getting Started” guide is targeted to specifically address those needs. 

The “traditional” approach of documenting requirements in text (e.g., natural language) has inherent limitations.  Text often can be interpreted multiple different ways, is subject to inherent ambiguity, and lacks the rigor to sufficiently and unambiguously detail the needs of the clinical community or the business.  Moreover, any such narrative requirements cannot be consumed directly – they must be “parsed” and turned into technical requirements – a step that frequently introduces new errors or omissions.

So what?  What’s the end state?

Drawing on best-practices from across multiple vertical market sectors, from Finance to Manufacturing to Aerospace and others, the use of formal models (e.g., diagrams with precise symbology and meanings) flattens this curve, reduces ambiguity, and allows the models to be directly consumed by software.  This approach limits interpretive steps, avoids introducing error, and fosters are more consistent use of the requirements products.  Further, as these techniques help your business stakeholders in thinking through their needs and being more precise about documenting them, the resultant downstream implementations better meet business goals and better suit your stakeholders.  Requirements documented via formal models are more accurate representations of need, are easier to consume, are verifiable, and ultimately foster more rapid and accurate implementation.  

Before you start

Setting expectations:  Developing standard requirements is a process that takes time; requirements will not be perfect right from the start.  Start the process slowly.  Be patient. Identify a specific problem that may be very small or seem to be of little significant.

Setting the scope: Scoping the project is a critical step in the process. Before gathering requirements, the team must clearly identify the problem to be solved, understand  what is included and what is not included. Define the deliverables and success criteria at the start to ensure that the team stays focused.

Remember to stay with your narrow scope.  Don’t creep into other problems.  Manage from the beginning with goal in mind.

Iterate, learn, improve:  Document throughout,  identify your successes and lessons, Reuse these as you go along. Demonstrate the value within the organization through this process. Success will be of great value and an important milestone for the organization.      

Change management:  The process itself is a  starting point for organizational change.  Once requirements/standards are developed others within the organization need to consume and use the standards and e models which have been developed. The entire organization works together to make this successful.  

What skills/resource needs are there?

People: Have committed resources assigned to designated roles. Successful BPM+ requirements capture depends on the following roles:

• The subject matter experts provide insights into the process. Subject matter experts may have different types of expertise, for example clinical, regulatory, financial, functional, etc.
• The facilitator drives the conversation to reach consensus and ensure that the who, what, when, where, and how of the process is clearly described.
• The documenter succinctly captures the information provided by the SMEs and creates a record of working sessions that can serve as a reference to the modeler.
• The modeler represents the information knowledge elicited from the SMEs in a standard BPM+ format and validates the model(s) with the SMEs.

Your team members will need a working knowledge of BPM+, the standards are reasonably intuitive and there are a variety of training opportunities available to can quickly acquire the skills necessary to use BPM+ to define system requirements.

Process:

Requirements definition is generally a part of a larger project. establish a team and leadership buy-in and frame the expectations for the project make  sure to have the buy-in of leadership, project manager, the subject matter experts, and the consumers of the requirements. Take the time to orient the team to what BPM+ is and the anticipated benefits of using it.  The Field Guide can serve as a resource for this orientation.

BPM+ adds value for the requirements definition..  Define the current process and tasks at a high level, including the what, who, when, where, and especially the why of each task. Examine theprocess for opportunities to standardize, streamline and optimize, then . document the ideal process.

Drill down or slice the process into needed to make the requirement ready for development.

Ensure that there is a shared understanding of the ideal and that it is correctly reflected in the BPM+ model through verification and validation process.

Advantage of the BPM+ approach: People can better understand and express requirements, and is usable as a software asset

Technology:

You need an editing tool to create BPM+ models. There are open source and free tools available. the free versions should be sufficient to get you started. A basic editing tool can create  the models.

Next, ensure that you have an easy way for team members and SMEs to view and understand the models. Many tools include workflow engines to automate the review and publication process, but synchronous model review using generic screen-sharing tools will meet your needs and provide an opportunity for group discussion and learning; you will need tools that allow for model validation and model simulation for SME verification of the models. Note that general drawing tools can be used to illustrate processes, but those tools lack the rich semantics that would allow for future process automation

A mechanism for the management (e.g metadata, versioning, relationships) and dissemination (e.g. search, browse, export, API) of the models helps ensure that knowledge assets are recorded. This ensures that your project has a common “source of truth” throughout its life cycle.

Finally, since this is a new approach for your organization, identify up front the tools that will be used for training, including technology to support teaching and knowledge transfer, as well as an environment with sample models, use cases, etc.

Conclusion

There are tremendous opportunities to augment existing approaches to requirements gathering take advantage of the benefits of process models with minimal experience and investment.   augmenting narrative requirements with easy-to-understand visuals (diagrams) helps ensure that the original clinical intent is better preserved;  subsequent reuse of the model ensures fewer interpretive errors and implementation inconsistencies.

Start small and learn.  A pilot program helps determine what works within your organization, and allows for whatever adaptation is needed to meet local needs. Remember, keep the scope small and ‘relatable’ to the end users. 

Plan and grow.   Be deliberate around the selection of your topic, the initial community of participants, the approach to the problem, and the complexity of the project.  Starting with amodestactivity results in early success and business value. Early returned value paves the foundation for ongoing work and subsequent investments.  The goal is to change the way problems are approached and solved, not toolings, however, a new way to think and use tooling helps ensure improved outcomes for the user and the organization. The business case is developed and the foundation is lain for investment in the tools to work effectively. 

Engage.   The BPM+ Health Community is an open community-of-practice comprised of organizations like yours working to improve their delivery, consistency, quality, and efficiencies.  By engaging within the community, you are among a cohort of others solving similar problems, and sharing experiences.  We welcome you!

 

Appendix or Complementary Artifact

Visual Example

•  Telemarketing sales scripts as an example;
• Market wouldn’t exist without process automation
• Is there a good healthcare example:  [a specific healthcare process flow for example – appointment checkin;  
  • Success Factors:
    • Familiarity
    • Approachability
    • [data collection, identity proofing, etc.]
• Consider mixed-media or on-demand video presentation – applying the document to a real example
• Cover problem/policy/process/measure?