Analyzing End-to-End Processes

To help give context to a VPEC-T analysis of business activities, Business Analysts and IS Architects might find it is useful to imagine
for a moment that the familiar models to describe a business didn’t exist. Imagine a business without an Organization Chart, a set of
Process Diagrams, or Financial Models. How might we think about describing the business in a way that represents its highly inter-connected,unstructured, and structured operations?

Think of “processes,” not in a static and mechanical sense, but as a series of more abstract themes (or threads) of interaction that
run in all directions across the enterprise. On each thread, imagine a series of beads. These beads represent a business capability or service, (a contracted capability) either of which is triggered by real-world events. Each bead undertakes specific tasks and creates interim or final outcomes. 

Using this concept helps focus on specific strands of behavior and provides context to a discussion about the VPEC-T dimensions,
without becoming constrained by more rigorous process-based methods. This is a neutral and flexible way of describing business

Figure 4-2: An Example of a Threads and Beads

processes or value chains, with the primary purpose of discussing the VPEC-T dimensions rather than, for example, the engineering
of formal process steps. However, it’s possible to use almost any technique that helps provide the context for the overall interaction between tasks, activities, competencies, components, and services.

For example, VPEC-T dimensions might be added to formal process analysis techniques, such as Value Chain Analysis, Swim-Lane Modeling, or Interaction Design. What’s important is to make sure that the VPEC-T dimensions are discussed and any insights recorded.

The graphical representation of threads and beads is similar to other process, workflow, or value-chain analysis diagrams; however, the deemphasis on the expression of formal process, and emphasis on the core VPEC-T dimensions are critical differences. To put it another way, it’s the discussion behind the diagram that is important. The purpose of the threads and beads diagram is nothing more than to provide context for the VPEC-T discussion.

Getting back to the threads and beads approach, threads can be used to represent a business theme or an end-to-end process. To
help with the distinction between process and theme, it’s useful to think of the process as being owned by someone, whereas a theme
isn’t. However, both processes and themes are focused on delivering one or more business outcomes. For example, within the context of a government’s drive to improve its Criminal Justice services to a citizen, a thread might be the theme of “Victim and Witness Support” and the outcomes might be “Improved Witness Protection” and “Post-Trial Victim Follow-up.” The thread might describe an existing or future process, or combination of processes, and themes.

So, in summary, threads and beads describe how a business outcome will be achieved. They provide a simple way to capture current
interactions and a structure for brainstorming future ways of working. In either case, they maintain a focus on the desired business outcomes. The business outcomes provide the basis of the VPEC-T discussion along each thread and at each bead within it. Often, the most illuminating insights will be gained by examining multiple threads of interaction and comparing the VPEC-T dimensions of one thread to another across different business objectives (desired outcomes).

Shared Service Discovery
Many businesses focus on removing duplication and improving agility, which is leading them to initiate efforts to discover candidates
for shared services (both human-based and/or technology-based). Understanding the nature of the cross-overs and joins between threads of interaction is at the heart of the discovery and implementation of shared services.The Systems-thinking basis of VPEC-T Analysis lends itself to Service Orientation and component engineering. However, it is designed to communicate to the broadest possible audience across both the business and IT worlds. It structures discussion in such a way that specifications of services and the associate triggering events, contracts (or Policies), information exchanges (Events and Content), and Trust rating are made explicit.

Figure 4-3 here

Taking the Lid Off the ”Magic Happens Here Box”

Perhaps one of the most compelling illustrations of the difference between the VPEC-T approach and traditional process analysis represented in a process-flow diagram is the “Magic Happens Here Box.” The “flat” nature of a process model can create the illusion that “All Boxes are Equal.” A box that describes a highly automated and industrialized activity might sit alongside a much less-defined process step—one that is essentially a collection of loosely defined behaviors that might be supported by the extensive use of user-selected IT (see later section on Shadow IT).

The “language” of the process model lacks the richness to describe such behavior in a way that is consistent with the automated steps,and as a result, is often poorly described—“Magic Happens Here.” In contrast, because the VPEC-T approach places emphasis on the dimensions of Value, Policies, Events, Content, and Trust, it is possible to consistently describe both industrialized activities and the more people-oriented behaviors.

Figure 4-4 here

The requirements for both transaction and interaction-type behaviors can be articulated under the same VPEC-T headings.
However, regardless of the particular business need or the number of threads involved, the challenge is in recognizing and then meeting
the needs of each stakeholder group, and creating a unified system of values (Value System). This may require several discussions and workshops to reach agreement. Finally, the simplified nature of the threads and beads approach provides a common mechanism for describing the interactions without being hampered by a focus on:

• the existence or absence of a recognized process,
• the degree to which the behavior is automated or otherwise“industrialized,”
• organizational domains and geographical boundaries,
• the perceived achievability of a desired outcome based on a narrow view of current practice.

Figure 4-5 here

Where’s The Beef?
Given that VPEC-T is a way of thinking rather than a methodology, we won’t attempt to define exactly what a VPEC-T-influenced deliverable would look like. The results of the VPEC-T analysis will become embedded in deliverables your project will produce. The findings of the analysis might be included in, for example, a business or IT strategy report, they might be documented as a set of principles for an Enterprise Architecture, or they might be documented as input to a business transformation program design.

VPEC-T dimensions might also, for example, be captured in ServiceSpecifications in a situation where a formal definition of Services is
needed. Examples include: defining a Service-Oriented Architecture (SOA), understanding the services from a Software as a Service (SaaS) delivered by an enterprise business software provider, or when documenting the third-party business services within a Supply Chain. However, the most important outcome is the common understanding between the business stakeholders, the business operators, and the IT providers. A common understanding that is expressed in the simple, real-world-aligned language of Values, Policies, Events, Content and Trust, and is focused on delivering better IT!