Problem—The Process of Calculating Costs
We’re on a roll, humming along. Everything is fine because we have all the information we want and need to manage operations and cash. The goal of the company is to make money, and we have an analysis that helps us understand how much we have at any given time, whether we are making money, the extent to which we are, and the levers that allow us to improve how much we can make. We know how much capacity we bought, how we consumed or used it to create the output and how efficiently, effectively, and productively we’ve done so. We also know what we’ve sold and collected. We can calculate practically any key managerial metric, cleanly, from these data. But when someone asks, “What did the output cost?” all hell breaks loose. The question is, “Why does it break loose?”
Before diving in, I’d like to share an idea we can use as context. I have used the terms data and information to represent numbers, measures, and metrics. I once heard an excellent way to distinguish between data and information; data are the raw numbers, and information is the answer to a question. The answer, information, comes from processing the data via an analysis or transformation of some sort. With the OC Domain, we have all the data the company creates available to us. However, when someone asks, “What did it cost?” the answer doesn’t exist as native OC Domain data. Instead, the data involved in answering the question have to be processed, transformed into a different format to create a cost.
Consider the following example. You have a worker whom you pay $240 for eight hours for her time. This is based on a $30 per hour wage rate. She performs a task that takes 1.5 hours. These are all OC Domain data. What did the task cost? One simple way is to take the OC Domain data and suggest that since each hour “costs” $30, 1.5 hours would cost $45. Notice, there is no cash transaction for $45 that leaves the company when she performs the task. The answer is a calculated cost that exists outside the OC Domain.
There is an anatomy to calculating costs (Exhibit 10.1). All business data, whether operational or financial, are created in the OC Domain. To answer the question about the task cost, we take a subset of the data, $30 per hour and the 1.5 hours to complete the task, to create our scope in this case. We then transform this into a cost by multiplying the two. This transformation creates an image or a projection of the OC Domain data, a cost of $45. (Exhibit 10.2). This image is like the circle created by projecting the 3-D ball in 2-D table.
Exhibit 10.1 The anatomy of a cost transformation begins with the OC Domain data. A set of this data is selected as the scope and, through an allocation/assignment schema, transformed into an Accounting Domain cost
Exhibit 10.2 In one case, we can look at the data and transform the data into a $45 cost
What is this image? It’s not money. $45 isn’t spent when she performs the task and $45 isn’t saved if she doesn’t. I would argue it is an opinion of the value placed on the consumption of capacity. The $45 value reflects 1.5 hours at an assumed value of $30 per hour. Recall, there is no math relationship between the capacity you buy and how it is used. To calculate a cost, you need a relationship. When you need a relationship and don’t have one, you make one up. In this case, I assumed every hour was worth $30, so 1.5 of them must be worth $45. It we had paid an outsider $45 for the same output, money would have crossed the CICO Border meaning it would have been a cash cost, costC. However, since no money left the company when the work was performed internally, it is a non-cash cost, or costNC.
When we ask most questions, we often expect a unique answer. For instance, if we ask what time it is, we expect 3:00 PM, not “it’s either 1:45 PM, 3:00 PM, or 4:17 AM.” When we weigh ourselves, we expect 150 lbs., not 110, 150, or 165. We’d prefer to be told the widget costs $1.28 to make, rather than it could cost $1.28, or 99¢ or $2.79. When we ask what something costs, we should expect a unique value; it costs $7.35. With measured values, you can converge on a unique value. However, the calculated cost of a product, service, or activity is costNC, and it is not a unique value because there is no single way to calculate it.
Consider, for instance, a different allocation schema. Say, over the entire shift, she performs the task five times. If the scope is the entire shift, the total amount of money spent is $240. If we divide by five tasks, we end up with a costNC of $48 per task. Now, what if only seven of the eight hours purchased are productive. If we want to focus on productive time, we’re looking at $210 versus $240. If we divide the $210 by five, we now have a cost of $42 per task. Again, no new data are created, as all data were created and available in the OC Domain before the cost calculation. Instead, how we choose, subjectively, to project a past event or set of events, created the answer. We considered a different scope; one shift or a partial shift. We also considered a different allocation or assignment schema—time to create versus number created. Each choice created a new cost. This process is demonstrated in Exhibit 10.3. The cost can also be affected by allocation/assignment schemata.
This resulting image is your calculated cost. It is information derived from OC Domain data and transformed to create accounting information (Exhibit 10.3).
There are a number of inherent problems with this process. First, the numbers are not unique. For every calculated cost you believe to be true, accurate, or precise, someone else with a different scope or allocation schema can create a different value. Neither yours nor the other is right because, recall, the scope is subjective, and the allocation is arbitrary. Hence, regardless of the approach, the number will not be unique or represent cash. Some ask if better allocation schemata model cash more effectively. For instance, is activity-based costing better than lean accounting or standard costing? The answer is, “No.” Costing methodologies can’t partially represent cash just like a woman can’t be partially pregnant. You are either pregnant or you aren’t; you either model cash or you don’t. Costing models do not.
Second, while all of the gyrations are being made to calculate a cost in the Accounting Domain, nothing has changed in the OC Domain. The OC Domain is the source of your unique data, and it is devoid of subjective and arbitrary treatments of data. Thus, it is the OC Domain where operations and cash-based analyses should begin and remain. Only when reporting information is required should the OC Domain data be transferred into Accounting Domain information.
This suggests one final idea. You do not need calculate costs for managerial purposes. The data in the OC Domain are precise and unambiguous. The Accounting Domain information is ambiguous and messy. I describe OC Domain data as tomatoes, garlic, basil, and onions while calculated costs are store-bought spaghetti sauce. It may have some of the important raw ingredients, but it also has a lot of the other additives that we may or may not know or understand, and in the end, they are less healthy for you.
Let’s delve more deeply into the Accounting Domain.
Exhibit 10.3 Different ways of looking at the situation in the OC Domain will lead to unique images or costs