Identifying Business Processes

This step identifies the organization’s core processes and the support processes that enable or guide core processes. During this step, a process map is built, and the associated attributes of the cross-functional processes are documented. The step should provide a common understanding and set of semantics for discussing the business of the “Organization-in-Focus.” Refer to Figure 11.2 for an example of a Process Architecture diagram.

Techniques

The techniques of identifying business processes include

• Architecture mapping by categorization of process types: core, guiding, and enabling

• Event/outcome analysis

• Interviews

• Workshops

Lessons Learned

Unlike with other forms of analysis, you might find defining the organization’s processes very difficult to do, primarily because processes are subjective in nature and can be arbitrarily combined or disaggregated. Managers might do this according to their political whims, particularly if they see specific processes within the boundaries of their own responsibilities. Avoid such problems by keeping process analysis cross-functional and focused on customer value creation.

Always start process analysis with the customer segments and work through the lifecycle of the customer relationship, even to the time before they became customers. Keep in mind all the possible things that could happen in the relationship, whether or not they are desirable or undesirable activities—for example, include making potential customers aware of the company’s services and losing customers.

By conducting interviews and information-gathering workshops for each significant customer type, you can determine the major types of events that trigger action and the possible outcomes important to the triggering stakeholder that complete the cross-functional process. Analyze these event/outcome pairings and consolidate them into a set of 4 to 10 core processes and 8 to 14 support (enabling and guiding) processes. Some high level processes will require their own architecture to be developed later (for example, the process of providing staff.)

To gather input from managers, conduct interviews and then run workshops to validate common concerns. Interviewing first helps spot sensitive issues in private and allows for more effective workshops, leading to more sensitive facilitation and consensus.

Involve the customer or a knowledgeable proxy to define what the customer values are and what performance indicators are important. Don’t rely solely on insiders for knowledge and insight.

Make sure that outcome analysis examines real and final outcomes, not just intermediate results. Outcomes must be directly tied to the values of importance to customers, owners, and other outside stakeholders.

Not all process attributes can be defined at this point. These can be updated later as more knowledge is gained. Have a clear place to store the knowledge gained so that it can be accessed and updated easily.

Make sure that the architecture has a steward or custodian, whose job it is to keep the architecture maps current and help others use it effectively.