Business Process Definitions
At the same time Portfolio Management activities are in progress, work to define any Business Process(es) a Solution may support can begin. Afterwards, outputs from both efforts provide many of the inputs Solution Strategy & Architecture requires to finish Solution Definition.
Product Solutions and many Service Solutions exist to support specific Business Operations. Of course, those operations rely upon Business Processes. Defining each relevant process is a smart investment, saving time and money in the long run. Definitions help ensure selection of an appropriate application or technology. Moreover, they are a pre-requisite to both complete Solution Definition activities and begin Solution Delivery activities.
There are many ways to describe processes and their context. For example, many organizations use the Process Classification Framework (PCF) championed by the American Productivity & Quality Center (APQC). In short, the PCF provides a taxonomy of business processes that allows organizations to objectively track and compare their performance internally and externally with organizations from any industry. Certainly, the ITM can work with PCF materials. Although, to effectively support application implementation most process descriptions require additional, specific information.
Accordingly, this section describes the how and why of Business Process Definition. To be sure, completing these Definitions provides most of the content required for Solution Definition. Moreover, they also provide content required before iterative Planning and Implementation activities can begin.
Section Overview
The Best Investment for Transformative Change
The results of future-state Process Definition provide the framework, and guidance, anyone needs to plan and execute a large-scale transformation or implementation. Indeed, Process Definition should precede the implementation of any business system.
In general, business systems include Commercial Off-The-Shelf (COTS) (i.e., packaged) applications, Solution as a Service (SaaS) Products, and may even include custom software. For example, Salesforce, SAP, Oracle EBS, Teamcenter, Dynamics 365, Workday etc., are all examples of business applications.
In fact, it is best to complete some Process Definition work even before considering the supporting technology. Initial levels of each Definition provide inputs to help identify, evaluate, and select, from available Solution alternatives. After software selection, complete the remaining portions of each Definition.
In almost every case, the time and effort put into Process Definition repay themselves many times over during the course of an implementation. Indeed, there is little chance of success without them. Accordingly, it is best to create these up front, when their content can then guide work and answer questions that are sure to arise.
After the Overview below, explore the following in more detail:
Introduction
A Business Process Definition (BPD) is a set of artifacts which describe a given business process, such as Payables or Payroll.  During creation, Process Owners and SMEs will make decisions related to action sequencing, roles and responsibilities, terminology, and options available. BPD artifacts capture these decisions and, thus, define the business process.
A BPD is a prerequisite for delivery of any supporting software Product (whether COTS, SaaS or something else). After all, it describes, in relative detail, a target future-state which the Product is to support. In addition, the prescribed process mapping based approach will build common understanding, and drive better managed expectations.
Not an "Agile" Effort
The definition of a business process cannot, and should not, be done in an "Agile" manner. That's not to say that a process cannot be defined over some number of iterations. Rather, it means complete the definition of any in-scope process(es) prior to beginning cycles related to subsequent iterative planning, analysis & design, or implementation.
To put it differently, a BPD is an ITM activity which does not lend itself to incremental development. To clarify, do not use Sprints to define processes. It is neither efficient, nor effective, to attempt defining a bit of a process, then a bit of a system, then a bit more of a process, and so on. For this reason, complete the definition of any process(es) that will be in-scope for a pending Solution Phase. Defer definition of any future Phase process(es) until just prior to Phase Inception.
The only thing worse than trying to define a process via Sprints, is to not bother defining any part of the process at all. Each definition provides information required to define the Solution that will support it. This is the most effective, and efficient, means to capture information required to successfully implement any business Solution.
Objective
A BPD is not about process improvement or process re-engineering. Those are admirable, and often beneficial, objectives in themselves. If including process improvement, or re-engineering, as part of the overall effort, complete those efforts first, prior to creating BPDs or beginning any incremental Solution Delivery activities.
However, whether using a Six Sigma, Kaizen, SIPOC, Value Stream Mapping or other tools and methods, their results are not as well suited as BPDs for system implementation. Fortunately, results from any of these tools can be quickly, and easily, translated into BPD form. The BPD form and approach prescribed by the ITM is specifically designed to support subsequent implementation activities.
Conversely, perhaps no one is seeking a specific improvement, or re-engineering effort. In this case, just follow the steps to define each process, and to create the corresponding BPD artifacts. Doing so will still force debate, and decisions, that will improve outcomes.
The objectives of the BPD are to capture and convey information relevant to both Business and IT for the subsequent implementation and operation of a given solution. BPD artifacts become touchstones against which to evaluate subsequent requirements, designs, tests, policies and procedures.
As depicted in the upper-left of the figure below, producing BPDs is the first, key activity in delivering any business system.
Key Point:
Of all the mistakes which lead to poor incremental delivery, the lack of an agreed upon, target future-state process(es) is perhaps the largest contributing factor. The information generated by this effort - action sequences, roles & responsibilities, business rules & software configurations, requirements, etc., - are all vital pieces of information which enable both Solution Definition, as well as Solution Delivery. Skip this work at your own peril. Â
What is a Business Process?
Where to draw the boundaries around what is, or is not, a "business process" is a topic open for debate (i.e., different sources will have differing definitions). The same applies to process names: Payables; Accounts Payable; Process Payables; Process Accounts Payable; and Expense Reimbursements; - all refer to the same conceptual scope.
Objective Criteria
As used here, and as recommended for use in ITM Solution Delivery, a Business Process meets some objective criteria.
- First, "Business" is not in contrast to IT. It refers to any value provided by any entity within the enterprise. To illustrate, IT processes of Application Delivery, Project & Program Management, or Service Desk Support, are all "business processes".
- Second, a "process" is a series of work-related actions, typically undertaken by multiple individuals within one part of an organization. At some level within the enterprise, boundaries will exist between organizations, such as between Finance and HR, or between Sales and Customer Service. At whichever level organizational boundaries are set, they should reflect process boundaries. That is, if more than one organization owns the operational actions, it is probable the definition involves multiple processes. Start with one per organization, and then breakdown as needed.
- A "process" should not be too broadly, nor too narrowly, defined. Processes typically roll up, into larger Process Groups, Categories, Value Streams, Departments, or Divisions. Conversely, processes also split out into smaller Activities and Tasks. Thus a "process" is a mid-level object. If using APQC's cross-industry Process Classification Framework (PCF), their Level 3 - Process provide a good general context.
Sequence of ITM Solution Delivery Events
The diagram depics where a BPD (i.e., Process Definition) fits into the broader ITM Solution Delivery model.
What's Next?
For additional info, see Guidelines for Defining a Business Process.
After reviewing the parts within this section shown towards the top of the page:
- If reviewing this section prior to strategy and architecture, then the next section to review is Solution Strategy & Architecture.
- If a review of strategy and architecture is complete, then proceed on to the Iterative Solution Planning section.