A Process Definition's Purpose & Use
The first of four (1 of 4) parts in Business Process Definitions (BPD) describes their purpose and use. In general, this part introduces the ITM's process model, a key component to guide and frame any Iterative Transformation or Enterprise Implementation.
The information which this process model derives is specifically designed to support both Solution Definition and Solution Delivery. Accordingly, they are some of the first materials to produce. Moreover, they are also some of the most valuable.
After reviewing the content below, refer to the following pages for more detail on each subject.
BPD Purpose & Use
For anyone unfamiliar with the benefits of defining business processes before trying to automate them, this part explains several of the many reasons to do so.
A Means to an End, Not the End Itself
To be clear, the importance for undertaking a BPD is not to create a set of diagrams. Nevertheless, the diagrams themselves will be very handy, and widely used. Rather, justification lies in through which their creation occurs. In short, proper completion of a BPD requires each of the following:
- Identification of relevant participants.
- Discussions and alignment amongst participants.
- Negotiations where multiple objectives do not align; and
- Decisions where multiple options exist.
Indeed, it is these aspects which establish the solid foundation for subsequent transformation and implementation. For instance, each aspect contributes to related Portfolio Management, Solution Strategy & Architecture and Solution Delivery activities.
Horse before Cart
In truth, the time and effort required to complete each BPD is relatively small. At least, as compared to delivery of the related system - or worse, as compared to implementation failure.
In fact, it takes far less time and effort to simply produce a BPD than an initiative wastes by not producing them. To explain, work based on assumptions, or (re)explaining and justifying the ill-defined, slows progress and creates confusion. Moreover, the lack of an agreed upon future-state contributes to frequent rework, mistakes and oversights.
As a result, lack of Process Definitions almost always winds up consuming more resources than folks imagine they save by skipping BPDs. To emphasize, BPDs are an excellent example of an ounce of prevention being worth a pound (or more) of cure.
A Solid Foundation
The diagrams, or flows, which comprise a BPD provide everyone involved with a common frame of reference. In effect, they capture, align, and consolidate tribal and personal knowledge. Furthermore, they present accumulated knowledge in a format which is both understandable, and referenceable, over the long-term.
As such, BPD diagrams become a reference point for many related activities and artifacts. Two initial examples include Process Requirements Matrices and Process Detailing Matrices. Without a doubt, this process model drives better requirements gathering than other, less thorough, approaches. As a result, they directly provide subsequent content to many delivery activities. Among those are:
- Business Case and SOW development.
- Scope management.
- Feature & Story identification and definition.
- Planning.
- Implementation and Testing.
- Training, and Change Management design.
Regardless of the planned implementation approach - Agile, Waterfall, or Hybrid - the foundation and baseline which Business Process Definitions provide ensures faster, and higher quality, results.
BPD Development
A Business Process Definition cannot exist on a single page. No matter how large the sheet, or how small the text and icons, a one-page diagram is never the answer. Here’s why a single diagram is not enough:
'Picture' vs. 'Definition'
Anyone with the perspective that it's about a picture misses what's really important about a definition's details.
Insufficient Detail
Not enough detail is sought – Of course, the objective is to achieve an agreed upon, future-state, definition. That agreement must involve many stakeholders. Hence, it must consider many perspectives and levels of detail. If discussions only scratch the surface, or only delve into a few areas, then initiatives are likely to overlook requirements, scope, and dependencies. Undeniably, these types of misses always come back to haunt future efforts. Too often, they delay value delivery and increase costs. A healthy level of detail, as provided by this process model, makes an initiative easier. It also improves an initiative's probability of success.
Wrong Participants
The right folks are not involved – When discussions remain at too high a level, they often fail to include groups or individuals who possess key information. Alternatively, it may be that others attempt to speak on behalf of those who truly know. In either case, this leads to gaps, misinformation, and misunderstanding. Experience shows these are far easier to identify and resolve up front. To clarify, it is far easier to make changes when working on paper, rather than after developing and/or deploying technology. In other words, it is much better to adjust the Process Definition than to make changes within the system.
Missing Pieces
The right conversations and requirements are overlooked – Finally, this is analogous to not getting the right people involved. Without input from those who truly know the details, critical information often remains unknown. Conversely, by the time proper Process Definition is complete, there is little chance of any major misses.
Not an "Agile" Effort
An organization cannot define any business process piece meal. That is, definition should not occur in an “Agile” manner. Why?
Complexity
Firstly, the complexity, broad impacts and interdependence of a Business Process. Each definition requires input from various stakeholders. Undoubtedly, it also requires negotiations and clarifications amongst participants. In general, any aspect of a process is flexible. Until, that is, key stakeholders finalize and agree to all aspects. Only after defining a future-state can an incremental approach to enable it begin.
Interdependence
Secondly, incremental definition can occur in the sense that there is no need to define all potential Business Processes up front. Begin with one (or more) and tackle others as needed. However, never move on to subsequent implementation tasks until relevant definitions are complete. Solution Definition and Solution Delivery each have multiple actions that require well defined inputs. This is particularly important when a series of processes involve interdependencies. For instance, handoffs from Quote, to Order, to Manufacture, to Service. Tackling each independently, without consideration of related Processes, will cause major problems. Conversely, an understanding of the "bigger picture" will ease many complexities. Moreover, it will also speed up subsequent tasks. Thus, ensure definition of any in-scope Process(es) concludes prior to, or during, Phase Inception. In other words, ensure everyone understands the end-to-end sequence, within current scope, before delivery activities begin.
Definition vs Delivery
Finally, you cannot be Agile by attempting to define processes on a Feature-by-Feature basis. Or worse, on a Story-by-Story basis. This is analogous to taking a single window, or door. Then, for that specific item, attempting to design a house (or portion of it) into which said item will fit. Again, understanding the big picture must come first. Features & Stories will later describe how to achieve the big picture in small, manageable, increments.
BPD Perspectives
The most important aspect of BPDs is the way they are created. It is through these process model methods that Business, IT, Vendor(s), and all stakeholders come to a shared understanding of objectives. As described herein, the model addresses objectives across dimensions of:
- People – affected organizations, roles, and responsibilities.
- Process – scope, dependencies, decisions, business rules.
- Technology – applications, functions, access, security, volumes; and
- Information – data flows, data definitions, reports, integrations.
Portfolio Management & Solution Delivery Support
A BPD sets the baseline upon which several Portfolio Management tasks, and all other Solution Delivery tasks, depend. For instance, they identify content available for use by Process Scenarios. Similarly, they derive information appropriate for gathering high-level business requirements. Moreover, this process model also identifies system functionality that will support end users. Above all, BPDs provide the requisite framework to set and manage scope for many other activities. For example, such information contributes to Business Case development, and the selection of COTS/SaaS Package software.
In later Elaborate tasks in Portfolio Management, as well as Analysis & Design tasks in Iterative Implementation, BPDs also provide the basis for many delivery activities and artifacts. Some of which include:
- Identification of Epics & Features.
- Identification of Interfaces / Integrations, Data Migrations, and Reports.
- Initial Feature & Story definitions and estimates.
- Prioritization of efforts, as per the Solution Roadmap.
- Testing and Training design and development.
Undertaking many Portfolio Management and Solution Delivery tasks without foundational BPDs will lead to missed objectives. Further, expect lower quality results, and too many mismatched, or unmet, expectations.
After reviewing the related child pages which appear above, the next section to review described the Creation & Evolution of a BPD.