Unpacking Value Stream Stages and Adding Capabilities

In the previous post, we saw how outcomes can be used to link together the stages of a value stream and describe the dynamic behavior of the value stream. This description supports analysis of the possible paths through the stages of a value stream, together with determining which paths are important to the business. For example, the transition to the “travel abandoned” outcome ends the behavior of the value stream without value for either the traveler or the transportation company.

Unpacking the trip inquiry

In this post, we are going to unpack what happens in the “Plan a Trip” value stream stage. This will show how to model the case that the traveler decides to stop searching for a trip. It will also allow the architect to establish capabilities that are the primary support for the stage. We start at the following diagram, which has only the entry and exit criteria for the “Plan a Trip” stage. “Plan a Trip” has two exit criteria: “travel planned” is an outcome representing the state in which the traveler has selected a trip offering; “travel abandoned” represents the state in which the traveler has disengaged without selecting a travel offering. When a value stream stage has two or more exit criteria, they should be alternatives – one or the other is the case, but not both.

The “travel need” outcome represents the state of mind of the traveler. This state of mind provokes the traveler to take the action of making an inquiry to the travel company. The inquiry action happens at a “touchpoint”, a BACM 1.2 concept representing an interaction between a customer and a business. The transportation company’s “inquiry establishment” capability receives the inquiry and records it along with an identification of the traveler making the inquiry. The model for this is shown below.

Touchpoints and capabilities represent actions that make changes in the state of the business and its interactions with customers and other stakeholders. These changes are modeled as a pair of outcomes, one that describes the state prior to the action and the other that describes the state after the action. “travel need” is an outcome that describes the state prior to the “traveler inquires” touchpoint; the traveler can be assumed to have a need to travel, otherwise there would be little reason to interact at the touchpoint. The prior state for a touchpoint is identified by an inbound arrow labelled “experiences”. Because touchpoints typically are interactions with persons or organizations, a prior outcome will reflect the state of mind of the person that motivates them to act at the touchpoint.

The state after the touchpoint, “traveler inquired”, describes the state of the transportation company recognizing that an inquiry has been received. This state is identified by an outbound arrow labelled “trigger2” as it typically triggers a capability to take some action in response. In this example, the “inquiry establishment” capability records the inquiry as described by the outcome “trip inquired”. The “inquiry establishment” capability prior state is identified by an inbound arrow labelled “needs0” and the after state is identified by an outbound arrow labelled “produces0”. These labels serve to indicate the parts of the BACM metamodel template used to create the arrows.

Outcomes, such as “trip inquired” are assertions about the state of business objects. The business object for “trip inquired” will be a “trip inquiry” record that is established by the business to accumulate information about the trip being planned. We can add this business object as an information item to the preceding diagram. The relationship between an outcome and a business object is indicated by a blue line labelled “state of”. However, “trip inquired” also asserts the relationship between the Traveler and the trip inqurty record to associated the Traveler with the inquiry, demonstrating that outcomes may describe the state of multiple business objects and of relationships between them.

State Conflicts

The “travel abandoned” outcome also describes a state of the “trip inquiry” information item, e.g. that the inquiry has been abandoned. Does the “travel abandoned” state contradict the “trip inquired” state? The BACM metamodel does not answer this question, so the business architect must determine whether these two states conflict, i.e. they cannot both be valid at the same time. Making such decisions is an important part of the business architect’s job as it will influence both process design and data design during the implementation design phase of a project. There will be more to say about state conflict in subsequent posts.

Unpacking the Touchpoints and Capabilities

The Traveler interacts with the transportation company at a touchpoint “traveler inquires”. The transportation company responds to the inquiry by performing a capability “inquiry establishment” to record the inquiry and then performing the “trip/route matching” capability to construct a collection of travel offerings that it believes could satisfy the traveler’s need as expressed by the trip inquiry. The BACM metamodel provides templates for touchpoints (representing the interaction between the business and its stakeholders) and capabilities. These concepts represent actions that are enabled by states (like the entry criteria of value stream stages) and produce states (like the exit criteria). The BACM models the relations between touchpoints and outcomes with the “experiences” and “trigger2” relationships. The relations between capability and outcome are labelled “needs” and “produces”. The capability that produces the “travel offered” outcome is “trip/route matching”. The preceding diagram is extended as shown below:

When we add back the “state of” relationship between the outcomes and the information items, we get an abstract operating model design as shown in the following diagram. This model shows the capabilities and touchpoints needed to support the value stream stage. The outcomes define the possible sequences of behavior of the touchpoints and capabilities. The outcomes also define the potential states of the information items. The business architect and the process designer can sit down together and discuss alternative abstract operating models and potential process designs for an implementation.

The new information items created by the “trip/route matching” capability are:

• “trip route” – a record containing a sequence of point to point trip segments with times and locations;
• “trip offers” – an aggregation of “trip routes”; and the
• “responds” relation that links trip offers to trip inquiry.

The creation of these information items is asserted by the “travel offered” outcome, produced by the “trip/route matching” capability.

Unpacking the Traveler’s Choice

The traveler is going to look at these offerings and respond in one of three ways: (1) accept a a trip route contained in the offerings; (2) make some changes to the inquiry and expect new travel offerings as a response; (3) abandon the search for a trip. We model this as a touchpoint “traveler chooses” with three triggers as follows:

If the traveler chooses to modify the inquiry, the triggered outcome is “traveler inquired”, the outcome needed to establish a trip inquiry record. It would not make sense if the inquiry was unchanged from the Traveler’s initial inquiry; why would the traveler repeat the inquiry but hope for different results? The preceding model diagram does not answer this question; it only shows that an inquiry was received and that a “trip inquiry” record will be produced¹. It does not show what specific destinations and dates that inquiry contained or what specific travel offers were produced in response. The presumption will be that the traveler did not like any of the trip offers and made changes to the inquiry, expecting a different group of trip offers. There are other ways to model this looping behavior and we will discuss them in subsequent posts.

If the traveler chooses to abandon the inquiry, the “travel abandoned” outcome is triggered, ending the stage and the value stream. The ending of the stage is shown by having the “travel abandoned” outcome be both the exit criteria of the “Plan a Trip” value stream stage and the outcome triggered from the “traveler chooses” touchpoint. When an outcome produced in an unpacking of a value stream stage is also an exit criterion of the stage, it ends the stage. If the outcome is the exit criteria for a stage and does not enable any stage, the value stream is ended.

If the traveler chooses to accept one of the offered trip routes, this is modeled as the triggered “travel chosen” outcome. This outcome is not an exit criteria for the “Plan a Trip” stage, but it could be. We are modeling a scenario in which the transportation company wants to use the traveler’s need for travel as an opportunity to sell travel related products, such as membership in a frequent traveler program or travel insurance. The model says that the exit criteria, “travel planned” includes “travel chosen” but may require other things as well, such as acceptance or rejection of a frequent traveler membership. In this example, we do not model any other outcomes required to complete “travel planned”, so once the “travel chosen” outcome is produced, the “travel planned” exit criteria is also realized.

Outcome Composition

You might be wondering why “travel chosen” in not the exit criterion for “Plan a Trip” and what the meaning of the “adds” relation is. Once an itinerary is chosen, the transportation company will often offer the Traveler a chance to reserve additional amenities, such as a window seat or a special meal. In other words, “travel chosen” is not the end of the “Plan a Trip” stage. We are not going to model that part of the behavior, but if we were, we would need to model “trip planned” as a combination of “travel chosen” and “amenities chosen”.

The “adds” relation asserts that both “travel planned” and “travel chosen” must be valid simultaneously. Had we added “amenities chosen” to “travel planned”, all three outcomes would have to be simultaneously valid. There is a “denies” outcome relation meaning that the target outcome must not be valid and the source outcome must be valid. These relations allow the re-use of outcomes that would otherwise need to be duplicated in many places in the model. In addition, all of the cases where an outcome is re-used, negatively or positively, can be found by traversing the “adds” and “denies” relations from that outcome. You will see more examples of outcome composition in the future posts.

Completing the Information Model

Below is the preceding diagram with the additional information items created as described by the “travel chosen” outcome:

The new information items are a “trip record” – recording the fact that the traveler chose a “trip route” that is “assigned” to the trip record.

This diagram should have included another capability, “TripEstablishment” that actually produces the “trip record” and “assign” to the chosen trip route, but the diagram is already pretty complicated and extending it is straightforward.

Summary

In this post, we see how to unpack some details of a value stream stage. These details include additional outcomes that are consistent with the “Plan a Trip” value stream stage and extend the idea that there is a composite state (“Plan a Trip”) with discrete substates (e.g. “trip inquired”, “travel chosen”). The idea of composite states of a business helps us model business behavior at multiple levels of detain as needed for analysis without being forced to model everything about the business at that level of detail.

We also see how capabilities can “support” value stream stages. In this example, we justified the “inquiry establishment”, “trip/route matching” and “trip establishment” capabilities as supporting the value stream stage by virtue of the fact that they are all involved in producing the composite outcomes of the stage. Other capabilities that “support” this stage can be found by additional unpacking and decomposition of the stage and its primary support capabilities.

We see how information concepts can be added to an unpacked value stream stage. These information concepts provide additional meaning to the outcomes that define the composite stages and establish a basic set of business requirements for conceptual data models that can be defined later in the architecture process.

We further see that outcomes can be re-used in two distinct ways: (1) to create composite states of a value stream stage, (2) to re-use specific outcomes in other outcomes in a manner that allows traceability and the identification and resolution of state conflicts. There are issues here that we have barely scratched the surface of, so look for more posts on this topic.

Next Steps

Thematix offers training and consulting on advanced topics in business architecture modeling and applications to strategy management. To schedule an initial web meeting to see if our offerings will benefit your business, please use this link: https://calendly.com/jrhyne-thematix/30min

If you have questions about the content in these posts or want to discuss the BACM specification, please connect with me on LinkedIn https://www.linkedin.com/in/jrhyne/

1. BACM models types not individuals. Outcomes are rules that can be satisfied or not when applied to an individual or a group of individuals. Information items are specifications of information that a corresponding data record must contain. Capabilities define what types of business objects they need and produce and what the states of those business objects should be on entry and on exit. ↩︎