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.
Saturday, September 15, 2007
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.
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.
Subscribe to:
Comments (Atom)
