CHAPTER 4

Introduction to Business Domain Management

In the last chapter, I focused on two things. First, to understand cash, what affects cash, and to understand improvements to cash, we have to model cash. Unfortunately, most companies do not. They rely on accounting information instead. Second, accounting does a poor job modeling cash and providing the context we need to improve cash, so we should not use it as a tool for managing project costs and benefits.

To address these and other factors I propose the use of Business Domain Management, or BDM. BDM can be used to model an organization, its performance, and to provide insight into how we affect and manage operations and cash performance through improvement projects and other managerial activities. BDM is a business framework that was designed to create a direct relationship between operations, cash, and accounting, and show the direct impact, or lack thereof, of improvement projects and management action on both cash and accounting values.¹ It focuses on cash and the factors that affect cash, while demonstrating why saving on accounting costs often have no, and sometimes even negative effects on cash.

BDM starts by breaking organizations down into two business domains, the Operations and Cash, or OC Domain, and the Accounting Domain (Figure 4.1). This will allow us to model and understand what happens, why, and where in an organization with the proper context. Some of the information will be straightforward, such as understanding where business transactions occur. However, some of it isn’t, such as where cash data comes from and where we should model it. Each domain will be discussed in turn.

Figure 4.1 Businesses can be broken down into two domains, the Operations and Cash Domain and the Accounting Domain. They are separate and distinct, and it’s important to understand what activities, data, and information reside in both

The OC Domain

The OC Domain reflects where business activities and cash transactions occur. It begins with the cash model from Figure 3.2, which is repeated here as Figure 4.2. Consider cash_IN and cash_OUT. Cash_IN represents cash received. For the most part, cash is received because something was sold, and cash was received for the sale. However, that’s not the only way. The infusion of cash from lending sources, royalties, and licensing fees received are examples of other sources of cash_IN.

Regarding cash_OUT, cash leaves the company generally because we are paying for something we bought. Most of what we buy is capacity, what we buy in anticipation of use.² For instance, you have workers, and you pay them expecting you will use them to do work. You lease space expecting you will need it for work or to store things. You buy materials expecting you will use them for work or to convert into salable items. However, it’s not always things we buy because payments such as taxes, royalties owed, dividends, and fines are not necessarily tied to things we bought.

Figure 4.2 Only activities and activities in the OC Domain affect cash entering, and living the company

There are five primary capacity types: space, labor, equipment, materials, and information technology.³ They all have the same basic characteristics. You buy a certain amount, you pay for what you buy, you consume what you bought, and you create output of all sorts (Figure 4.3). For instance, we buy time, space, equipment, and materials to make widgets that we sell in the market. In some cases, what you create, you can sell, but not all. For instance, we buy the labor that comprises our HR department. One source of their output is hired employees, but we don’t sell hired employees. Or we buy a day of someone’s time, we buy access to the space they’ll work in, and the computers they will use, we consume each, and we create data analytics reports.

Figure 4.3 These are the primary business activities that occur in the OC Domain

Notionally, all business operations can be modeled by looking at how much capacity there is, how it is consumed, and what it creates. Most of what we will use to understand the impact of improvement projects throughout the rest of the book is based on this model.

As mentioned previously, the capacity you buy and pay for affects cash_OUT and what you sell and receive payment for affects cash_IN. From this interaction, you can create a comprehensive model of operations and the resulting cash transactions. This is the OC Domain’s Business Activity Framework.⁴ It models all business operations activities and cash transactions (Figure 4.4).

Figure 4.4 The Business Activity Framework models business activities and cash transactions and shows the relationship between business activities and how they affect cash transactions

For instance, let’s say you have a person who makes $25 per hour. For a shift, they will be paid $200. Let’s assume seven hours were consumed on productive activities, and from this, 56 units of output were created and 48 were sold at a price of $8 each.

This scenario is modeled in Figure 4.5. The diagram is called a capacity map, and we use capacity maps to represent Buy-Consume-Create, or BCC activities discussed previously.

Figure 4.5 This is a typical capacity map, which represents capacity purchased, consumed, and used to create output – Buy-Consume-Create. None of this information is contained in the Accounting Domain. Another key factor is demand. Demand is not found in the Accounting Domain. We only see the influence of demand met

From this simple example, a significant amount of both operational and financial information can be captured as seen in Table 4.1. I often hear from executives and consultants alike that they need the accounting information for managerial decisions and cannot shift to another set of data and information. The question is, “Why?” This information, created in the OC Domain, is the source of what is created in the Accounting Domain. The Accounting Domain, as we will see later, does not add anything, it just processes and creates one of what is practically an infinite number of descriptions of what has already happened in the OC Domain.

In this case, we know revenue generated, cash spent, and we have a significant number of metrics that help us understand where we have too much capacity, and what is necessary to achieve various types of improvements. We can see very clearly what the cash implications would be, given certain changes in operations and capacity levels. But then someone comes along and asks what the output, 56 units costs, and what the subsequent profit is.

This simple question, “What does it cost?” opens up Pandora’s box. Why? The question is mathematically impossible to answer from a cash perspective and needs another solution. Let’s consider why and discuss the relevance to projects.

Table 4.1 I often hear people tell me they cannot shift away from Accounting Domain information. Why can’t they? First, all the information you need to manage is created in the OC Domain. Nothing new is created in the Accounting Domain. Second, where do they think the data they use come from?

First, let’s consider a simple example we’re all familiar with to drive this notion home. Let’s say you buy phone service where you pay $25 for unlimited local calls. Long-distance calls are 10¢ per minute. A 10-minute long distance call would cost $1. How much would a 10-minute local cost? No clear answer, right? Here’s why. When you made the long-distance call, you were buying time; a minute for 10¢. The cash cost curve looks like the one found in Figure 4.6A. With the local calls, you are buying access. This cost is the same whether you make 0, 10, 50, or an infinite number of calls. That cost curve looks like the one in Figure 4.6B. Recall, this is the same curve we created with our IT employee in Figure 3.4. These costs change with how much we buy and what we pay for them. This suggests that there is no relationship between what you bought, access for $25, and how you use it making calls. However, to calculate a cost, you need a relationship. If you need one and you don’t have one, you make it up. Enter accounting and the Accounting Domain.

Figures 4.6A and 4.6B Cash costs change with what we buy. Noncash costs change with what we do. Mathematically, there is no relationship between what we buy, access for a period, and how we use it, making calls. This is the mathematical dilemma accounting tries, and fails, to address

The Accounting Domain

The Accounting Domain exists primarily for financial reporting purposes. It also exists to address accounting-related questions related to costs, profit, taxes, and other financial matters. These are values that cannot be calculated in the OC Domain because to calculate them requires a transformation of the OC Domain data. The OC Domain provides raw unambiguous data about the operations and cash transactions of a company, and that’s it. To create accounting information, we take data from the OC Domain and use a transformation algorithm to turn into accounting information such as cost and profit (Figure 4.7).

Figure 4.7 Accounting information comes from transforming business and cash activity data from the OC Domain

Calculating a cost in this example will require identifying the appropriate OC Domain data (what we paid and length of call) and transforming it into a cost (cost per 10 minute call). In other words, you need to somehow transform what you pay for a month of phone access $25 to the length of the call, 10 minutes. But how? It turns out, the same way we handled labor earlier on project costs and savings; we make it up. One way is to calculate a per minute rate, but how? What do you use? Do you use the total number of minutes in a month? If so, are you willing to accept February is the most expensive month to make phone calls solely because it has fewer minutes? Or that months with 30 days have more expensive calls than those with 31? Should we consider a 24-hour day or the time we’d likely be making calls, say, 16 hours per day … or is it 17, 15, 20, or 8? That is the subjectivity of calculating costs. In the end, whatever model you use is arbitrary because you are still creating a relationship between mathematically independent values.

As a result, the cost of the local call can be whatever you want it to be, really, within certain parameters. For instance, the cost of a call can’t exceed $25. If you have a cost per minute of $2, someone calls you and hangs up, say, in 0.05 seconds, the cost of that call could be calculated to be $40 even though you spent $25 for access. That makes no sense. Other than that, it’s pretty much all fair game. Here’s what’s going on.

Business activity and cash transactions occur in OC Domain. Calculated costs and accounting information exist in the Accounting Domain. The Accounting Domain is the result of a transformation of OC Domain data into accounting information (Figure 4.8). The transformation is necessary because there is no relationship between what you bought, capacity, and how you use it, but to calculate a cost, a relationship must be created. Hence, we take data from the OC Domain and transform it into information that can answer accounting questions.

Figure 4.8 The Business Domain Management framework includes both the OC Domain and the Accounting Domain

The transformation process involves defining a data scope in the OC Domain and using a transformation algorithm to create an Accounting Domain image of what happened in the OC Domain. For example, take the person who makes $25 per hour. We know what we bought (eight hours for $200), we know what was consumed (seven hours), and what was created in that time (56 units). One way to calculate a cost per unit is to take the total time and cost ($200) and divide it by output to calculate an image or cost of $3.57. However, a different scope and set of assumptions will create a different image or cost (Figure 4.9). For instance, if we choose to use the seven productive hours instead of the eight total hours with the same output, the cost is $3.13.

Notice two things here. First, we have two costs in the Accounting Domain with only one set of OC Domain data. In other words, nothing changed in the OC Domain, yet by changing the assumptions and, hence, the transformation algorithm, we came up with a cost that is arguably significantly different. Second, these are just two of a practically infinite number of possible costs. We could change the scope to consider how long each unit takes to make, how we classify production time, and many other factors. We can also change the transformation technique. We used average costing, but that could as easily have been a different costing approach such as standard, activity based, lean, or something else. Each will create its own unique cost (Figure 4.10).

Figure 4.9 There is only one instance of operations and cash data. However, there are practically an infinite number of ways to transform it into accounting image. The lack of convergence to a single image is one of several reasons why business value should not be placed in accounting information

Figure 4.10 We see that, although nothing changes in the OC Domain, how you choose to calculate costs affects what the cost becomes. Note, Cost_NCX refers to noncash costs that are calculated from each transformation

Why is this significant? If we look at the transformation process, OC Domain data are concrete, real data. However, Accounting Domain information is an abstraction of the real data that exists in the OC Domain. In fact, it’s not just one abstraction. There are an infinite number of them. Hence, while you may have one you are working with and using for managerial decisions, it would be easy for someone to come along and create a completely different, equally valid (or not) abstraction with a different cost and profit from the exact same OC Domain data. If that’s the case, how do you know if your information is any better?

Project financial analyses and CBAs are often captured or modeled in the Accounting Domain. Think about the cost reduction we discussed earlier when we reduced processing time for the employee from one hour to 20 minutes, and the different ways we could calculate the savings. When we considered the cost of internal resources, that is Accounting Domain information. Likewise, financial benefit calculations that result from improvements in efficiency, for instance, are also in the Accounting Domain. Because of the ambiguity of the information in the Accounting Domain and the fact that it is transformed or processed OC data, the proposal here is that if you want concrete, accurate, precise, data and information, you should model projects using OC Domain data rather than Accounting Domain information.

We can always project OC Domain data into the Accounting Domain to see what the impact will be on Accounting Domain information and metrics. However, this is much harder, if not practically impossible to project Accounting Domain data into the OC Domain and create managerially useful information.⁵ For example, consider a product or service your company provides. Now say something happened that reduced that cost by 10¢. With this information, can you describe what happened in the OC Domain? No. Was there a change to how much capacity you bought or the price of the capacity? Was it based on capacity consumption rates? Improvement in terms of output that can be created in the same time? The answer is, from this information alone, we do not know. By focusing on the OC Domain, we are dealing with clean operations and cash data. If we make a change to the BCC Model, we can project the impact in the Accounting Domain. In other words, we can see where the 10¢ improvement came from. We will see later, why focusing on the OC Domain versus the Accounting Domain is so much more effective when modeling projects.

Next, we will focus on the importance of defining and prioritizing projects to ensure that they are able to generate cash returns for the firm as defined in the OC Domain, and that they’re aligned with both the strategy of the firm and the needs of your customers.

Key Takeaways

¹ Ibid.

² R.T. Yu-Lee. 2002. “Essentials of Capacity Management.” John Wiley & Sons. Note, in the book, there were five entities. However, with the advent of online models where companies subscribe to IT, IT hardware can be considered equipment.

³ Ibid.

⁴ Lee 2018.

⁵ Ibid.