Building Blocks of Business Architecture for Partners #2
The goal of this blog series is to provide a comprehensive outline of the disciplines required for successful enterprise architecture. As a systems implementation consultant, I frequently encounter the need to rewire systems to enable new capabilities or adopt a new technical stack. In this series, I will guide you through the process.
As a board member of the Kansas City IIBA chapter, it is my aim to preserve this valuable knowledge for our members and other professionals in enterprise architecture and business analyst (BA) roles within our network, as well as the Partnering Professionals that use our team for guidance. This series will outline the essential steps for implementing new capabilities or incorporating new technical stack components. Change always happens in an enterprise, and having a well-defined game plan can make all the difference between success and failure. I highly encourage your feedback throughout this journey.
===================================
Article #2 Process Decomposition Fundamentals?
OK, so what is process decomposition, and why is it important?
Process decomposition involves defining a process at a suitable level of detail. When you have process items with varying levels of granularity, such as a high-level item like "Billing" and a detailed item like "Calculate County Sales Tax," it's important not to include them in the same diagram because they are not at the same level of detail.
So, how do you ensure that things are at the same level, and what does it mean to be at "Level 3," which is most valuable for enterprise architecture discussions? I utilize a process model framework called IDEF, originally created by the USAF, which provides a basis for defining process levels.
Level 1: This is usually equivalent to a business function found on an organizational chart (e.g., Accounting, Customer Service, Sales, Marketing).
领英推荐
Level 2: This level typically represents a key process or subject within the business function (e.g., Accounts Payable within Accounting). Level 2 processes often serve as the definition of a value stream point for enterprise architecture discussions.
Level 3: This level represents a unit of work within the value stream (e.g., "Receive Invoice" within Accounts Payable). In my methodology, I refer to Level 3 processes as "Capabilities," which we will explore in detail in another blog post.
Level 4: This level corresponds to individual steps within a process (e.g., "Record Invoice Number" as Step 1 of "Receive Invoice").
For enterprise architecture purposes, working with Level 3 processes proves most beneficial. To achieve a version of business flow at this level of process decomposition, I employ the "elevator ride" paradigm. By asking stakeholders to describe the Level 2 process of "Accounts Payable" within a three-minute elevator ride, we can elicit a quick and unfiltered list of sequential functions. Each statement becomes a candidate for a Capability (which we'll define further later). Our hypothetical example may yield a series of statements like this:
These steps form a Level 3 process flow that describes the Level 2 process (value stream) of "Accounts Payable." This exercise should be concise yet informative for defining the function. With this information, you should be able to construct a solid process flow. Note that I have highlighted key words in these steps using capital letters, which can be used to create proper Capability names.
Level 4 would involve detailing each step associated with each Level 3 item.
In summary, understanding process decomposition and being able to define business processes using this structure are key tools for enterprise architects. Level 3 provides the appropriate level of detail for process descriptions and planning purposes.