Friday, April 10, 2020

Business Process Modelling - Five Phases

What is the "Definition of Done" for a Business Process Model?

Process Model Value Stream: Five Phases

This tutorial defines Five Phases that each has its own set of objectives and criteria for determining the Definition of Done for the Process Model:

  1. Reference Pattern
  2. Straw Model
  3. Analysis Model
  4. Specification Model
  5. MVP and Delivery Model
The most common Reference Pattern is for Case Management.  Once the specialist is aware of the Pattern, the major themes are readily understood and it is possible to structure the approach to defining functions and lower level models.  This will reduce the mystery on understanding where you are and reduce the amount of refactoring needed over time.

The Straw Model's purpose is to aid the specialist in working with the Subject Matter Experts to elicit needs and verify understanding.  The Project Charter provides business-specific context (both detail and scope) for the generic themes provided by the Reference Pattern.  

The Analysis Model is the result of working with the SMEs to elicit more detail, vet what will streamline the process, and address the opportunities to apply best practices and familiarity with enabling technologies.

The Specification Model pivots toward grouping what has been learned into functional components, the volumetrics, and a better understanding of the data in use, in transit, and exchanges with business partners.  Use Cases are identified to guide preparation of user stories, Decisions are well defined to guide business rule specification.  The architects use the Specification Model to make decisions on platforms, choice of development tools such as COTS, low-code, custom code, available re-usable components, and open source capabilities.  

The Product Owner decisions from assessment of the options in the Specification Model are shown in the MVP Model.  The MVP guides Sprint Planning for capabilities ranging from Infrastructure to Architecture, data readiness to Application functionality.  The MVP model informs all change control decisions as well as the completion of user stories including  business rules by sprint teams.


Friday, July 3, 2009

Discovery, Analysis, Specification, Architecture, and Design

What level of analysis belongs in the Project Charter, the requirements specification, the end of what the Unified Method calls Initiation and then Specification? How do we reconcile the need for incremental and iterative refinement of work products with contracts that pay for deliverables, not some esoteric definition of earned value analysis.
Let's start by distinguishing between business analysis and functional specification.
Business analysis encompasses business process analysis (as-is and to-be), functional requirements and non-functional requirements, the conceptual data model, harvesting business rules, identification of business use cases based on examination of the process models, and identification of internal and external interfaces. The conceptual data model can include the glossary of business terms.
Functional Specification includes the entity-relationship diagram, the data elements dictionary, the web page hierarchy diagram, the storyboard (wireframes and user narrative), re-factored business rules, and the use cases.
Skilled business analysts with experience working throughout the system development life cycle can do all the work in conjunction with customer subject matter experts for both the analysis and the specification.
Architectural work occurs on two levels: end-to-end and application-specific.
End-to-End architecture addresses existing enterprise capabilities and standards such as those for databases, programming languages, internal and external portals, industry standards for data exchange, existing applications that may be re-used as a web service, investments needed for the project that can contribute to future projects throughout the enterprise, interoperability across platforms such as content management, imaging, business intelligence, and the number and type of environments needed for development, testing, acceptance and staging, and production.
Application architecture addresses more than just the presentation, business, and data access layers. Within the business layer, application architecture addresses the buy versus build approach to managing and executing business rules, orchestration and workflow, and the determination of components within the application. Component boundaries need to recognize future re-use opportunities throughout the enterprise as well as what makes immediate sense for the current application.
Only once the project begins work on the detailed design's work products do the software design specialists need get involved. Designers will work with architects on the scope of components described above to meet application as well as future enterprise opportunities. Designers will address buy versus build for handling workflow, orchestration, and business rules. Customer and project architects and designers will establish how to implement the integration tier that supports interfaces to external systems as well as interoperability with legacy systems within the enterprise. Increasingly, projects will implement an enterprise service bus (ESB) product to manage the integration tier without the fanfare of declaring victory for service oriented architecture. The ESB selection for the integration tier can result from something as simple as a buy versus build analysis on how to manage data transformations, orchestration, logging, guaranteed delivery, and other responsibilities when moving data from one system to another.

Saturday, September 15, 2007

Business Interaction Model

The Business Interaction Model defines six interactions between the customer and the "System". (The System can be broadly defined as including not just automated systems, but also human interactions, and interactions with entities outside the enterprise that trigger the customer to then address the system.) The Model is a graphical depiction of the interactions of the Customer with the System, the applications within the System, and the System's interactions with external Suppliers. External suppliers can include other divisions of the enterprise as well as trading partners that provide the materiel for the enterprise or to whom the enterprise outsources activities. The key contribution of the BIM is the "Customer Interaction Stack". There are six phases to the customer's interactions with the enterprise. The six phases described below center upon the Customer's key interactions:
Recognize the Need/Want
Research Options
Inquiry: Establish Contact, understand offerings, prepare offer
Contractual Phase
Delivery/Fulfillment
Completion: Audit, appeal, satisfaction assessment.

The point is these six interactions occur whether they are formally recognized by the enterprise or not. The lack of recognition and measurement for each interaction suggests a deficiency in the enterprise's service delivery capability and accomplishment.

The Business Interaction Model is a way to discover functions, events, and roles that need to be part of the business process analysis/models, business rules, use cases, and the business architecture.

The Business Interaction Model preparation can begin immediately after preparation of the Context Model (that identifies the system's stakeholders.) The BIM does not include all stakeholders. The main roles included in the BIM are the Customer, the Suppliers (external business partners and other divisions within the enterprise.) The BIM can also include automated systems.

BIMs may be prepared for the "AS IS" and the "TO BE". Each of the interactions may represent an Activity shown in the subsequent Process Modeling effort. The BIM is a good guide for preparing the Process Model. The BIM may infer the order of major activities but the order is not explicit.

The first BIM phase is the customer's recognition of a need. In the health appointment example, the first phase is the customer's recognition of a need to address a cold.

The second BIM phase is research or exploration of how to deal with the cold. The customer may know to search the internet for a site such as WebMD to explore how to identify symptoms (to verify or make the diagnosis) and then to find out ways of dealing with the cold. A well-informed customer may go to the doctor or health carrier's web site to look for information on what to do. The insurance site may explain the coverage for doctor's visits and the higher charges for an emergency room visit. This information alone may be sufficient to make the customer wait for business hours instead of a late night emergency room visit.

The doctor's site may explain business hours, protocols to follow for after hour medical attention, the phone number for the advice nurse (which may be a subscription service offered by the employer or insurance company or offered by the medical group), or protocols to follow for common illnesses such as a cold. These explanations may help the customer find a solution that does not require a visit to the doctor's office--saving money for the customer and the doctor and possibly speeding the solution.

Where the enterprise is actually seeking to create demand, the online site may provide the needed marketing information to motivate the customer to buy the product online, view brochures on line, or seek a retailer located nearby to speed the purchasing decision.

The BIM's third phase is to establish contact. Web sites that capture information about the customer may accomplish this phase at the same time as the customer is in phase two doing research on options. More typical is to get the customer to fill out an online form requesting specialized information, submitting an application, or calling a contact center.

The BIM's fourth phase is to establish a contract. In the health example, the customer makes an appointment to visit the doctor's office.

The BIM's fifth phase is the delivery of the service or fulfillment of the order to provide a product. This is the doctor and lab performing their services (in the health example this would include completing charting the results), collecting the co-pay and billing the insurance company.

Quite frankly, there is a good argument to create a new phase to address billing and payment.

For an employee filing for retirement, the application is a phase three inquiry including the calculations done to present retirement options. The applicants signed selection of the retirement option and entry of this information in the benefit system are part of the contractual phase.

For the benefit application example, establishing the monthly roster and delivering the benefit warrant represent the fulfillment phase. Fulfillment may include a first check as an estimate and a later adjustment check.

The BIM's sixth phase of Completion addresses the audit, appeal and/or customer satisfaction survey. Too often, the assessment phase is not defined within the business process. Omission of this phase is a defect in the business process. The AS IS may not include the assessment but the BIM provides the impetus to ensure the TO BE does include audits and assessments.

The Level One Process Model may only include one or at most two activities for each phase of the BIM. There may be a separate Level Two Process Model for each BIM phase. Some BIM phases such as the Contract and Fulfillment may require multiple level Three process models. Given the brevity of the activities, you may combine the first and second BIM phases (recognition and research) into a single process model. Invariably, exploration of the customer's research phase will reveal many thought provoking ideas on worthwhile activities to include in the TO BE solution to address the customer's research effort.

Business Process Analysis contribution to the Requirements Definition Document

Business Process Analysis (BPA) guides the organization and stimulates the content of the functional requirements portion of the Requirements Definition Document (RDD). A separate post will describe how the "to be" process model serves as the shared reference throughout the project life cycle for business, technical, and management participants to address status, issues, and the impact of proposed changes -- and to actually understand what the proposed system is doing and how it impacts the enterprise, business partners, organizational units, and staff.

The RDD should have six major artifacts:
AS IS Business Process Model
TO BE BPA (at least an early version of it that will be revised following the technical architecture decisions that may impact the process)
Functional Requirements
Technical Requirements
Business Interactioon Model
Business Use Cases
Subject Data Model
Policies
Alignment of the Project proposal to the Enterprise Business/Operational Architecture and Enterprise Technical Architecture.

The Business Process Model triangulates with the Functional Requirements and Business Use Cases.

Triangulation means that each artifact is interdependent with at least two other artifacts. Therefore all three artifacts must be compared against one another to ensure consistency. This assessment will invariably identify gaps and inconsistencies to resolve. This triangulation will ensure that each artifact has greater value in future phases.

the purpose of any artifact is at least two fold:
Verify a shared understanding of the work that has been done to date;
provide the guidance for the work that lies ahead.

All artifacts are work products. An artifact may be a deliverable but that is not essential. Deliverables have a more formal review process and may be associated with "go-no go" decisions. too often, too much formality goes in to the presentation and precision of deliverables.

Deliverables should be measured by do they provide sufficient affirmation of understanding and sufficient guidance. Subsequent phases will identify issues and information that can enhance a previously approved deliverable.

Most work products (and deliverables) have sufficient substance and guidance when sixty percent complete to enable the next phase to begin. work on the next phase enables identification of issues and information to include in the work in progress work products. Approval may occur when the next phase is already 30-50 percent completed.

This overlap enables the next phase to serve as a "scouting party" to ensure the work products provide the needed guidance, to avoid putting too much into a work product when the extra resources can contribute to the next steps. Formal approvals have greater certainty when already "field tested" by the guidance the work product has given the next phases scouting party.

Summary:
The Requirements Definition Document has multiple artifacts, not just a list of functional and technical requirements. The Atlantic Systems Group got RDDs pointed in the right direciton but did not take requirements far enough.

Each artifact is compared against at least two other artifacts in a process called triangulation.

The purpose of artifacts is to verify a shared understanding on the project and to provide guidance for the next phase.

Artifacts are work products and may be deliverables. Even deliverables need not be more than sixty percent complete b efore providinng sufficient understanding and guidance for the next phase to begin. The next phase may be up to fifty percent complete before the prior phase's formal deliverables are approved.

All work products (including deliverables) will need modification based on findings and issues revealed in subsequent phases.

Thursday, May 17, 2007

Business Process Management Systems

Helpful overview to BPMS 2.0 found at
http://itredux.com/blog/bpm-20/

There may be a bit of a vendor bias overall in the itredux.com blog but the value of the information and analytical approach gives the reader enough insight to make one's way just fine.

Sunday, May 13, 2007

References for Business Process Analysis

Just to get started:

Alec Sharp and Patrick McDermott's, Workflow Modeling: Tools for Porcess Improvement and Application Development, Artech House, 2001
Among many innovations, proposes six dimensions (called enablers) to the process analysis:
  1. Process workflow design (actors, steps, flow);
  2. Information technology (applications, databases, etc)
  3. Motivation and measurement (reward and punishment schemes)
  4. Human Resources (skills, training, job definitions, organizational structure)
  5. Policies and rules
  6. Facilities design
Best source I've ever found to explain practical approaches for the novice as well as the expert for "as is" and "to be" process modeling.

Once Alec's permission is gained, will add more of their insights.


"Learn business process modeling basics for the analyst" by IBM's Ken Beck, Joshy Joseph, and German Goldszmidt. See: http://www-128.ibm.com/developerworks/webservices/library/ws-bpm4analyst/
Offers more than a sales pitch for a product but is necessarily brief.

Barbara von Halle published a series of articles about 15 years ago that remain a seminal work; will track down to see if available on-0nline.

Michael Havey, Essential Business Process Modeling, O'Reilly press, 2005
Does less to explain how to do modeling than to show notations and standards. Helps to explain the differences among standards from Workflow Management Coalition, Business Process Management Institute, and others. Helps understand the role of BPEL in process modeling.

Will add other references over time. Please suggest your own.