@remembermytweet and @tetradian explore the Types of Cost (Jan 2013).
Alex identifies a number of different types of cost, which as Tom points out are largely monetary costs. But what is a cost anyway?
An enterprise incurs a great deal of cost. and these can be broken down and classified in various ways. Accountants like to express all costs in monetary terms - so for example, human effort is translated into labour cost.
But that only works if the enterprise is directly paying for the labour, in the form of wages or contractor bills. Wasting the customers' time doesn't count as a direct cost to the enterprise, although it may well have an indirect cost in terms of customer complaints and lost revenue.
We might also think of anxiety as a cost. As Seth Godin comments in relation to the airline industry, "By assuming that their customer base prefers to save money, not anxiety, they create an anxiety-filled system." Eleven things organizations can learn from airports (Jan 2013). See also my post on Anxiety as a Cost (Jan 2013).
Even for direct labour, the human cost may not be fully reflected by the wages and monetary overheads associated with employment. Many employees do unpaid overtime and incur other personal costs, and this is only visible to the enterprise accountants when it results in high levels of sickness and staff turnover.
So we need to remember the difference between a real cost and its monetary measure.
Showing posts with label accounting. Show all posts
Showing posts with label accounting. Show all posts
Saturday, January 26, 2013
Wednesday, November 07, 2012
On Business Architecture and Management Accounting
Someone asked on Linked-In Should EA be knowledgeable about accounting and its pitfalls? Here is a rewritten version of my reply.
Management accounting provides a view of the distribution of costs, benefits and risks. Costs include labour costs, materials and other purchases, and so-called overheads. So if we want to know the total production cost of a particular product, or the total cost of a particular activity, we need to work out what share of the total expenditure should be allocated to this product or this activity. These calculations are important for many reasons, including deciding whether to invest in improved systems and technology, deciding whether to keep some capability inhouse or outsource, determining how profitable a given product or service is at a given price and volume.
In One Strategy One PL (January 2013), John R Moran argues that a company can only have a unified strategy if it has a single unified accounting view, and suggests that "the entire logic of profit centers rests on the assumption that maximizing the pieces will maximize the whole". Clearly the relationship between the performance of the pieces and the performance of the whole is an important topic for architects.
Accountants use various simple methods for cost allocation, including so-called Activity-Based Costing. These methods all make some structural assumptions about the dependencies between activities, capabilities, resources and other things. They also involve rules about handling expenditure spanning more than one accounting period. These assumptions also affect project evaluation (e.g. return on investment).
If these structural assumptions are simplistic or incorrect, the management accounting view may lead management to make poor decisions - for example, about investment or cost-cutting or outsourcing. (See my post on Architecture as Jenga.) So business architects need to appreciate what structural assumptions are implicit in the management accounts, and be prepared to challenge these assumptions when necessary.
This is not just because business architects should understand the structure of the business, but also because architecturally-led initiatives may depend on producing a business case that relies on a correct allocation of costs and benefits. For example, architects often wish to advocate long-term investment in shared services and platforms, but such investment may sometimes appear unattractive or unfundable when viewed from a conventional accounting viewpoint, and may be hard to get through the conventional budgeting process. If architects don't understand the potential distortion of the conventional accounting viewpoint, and allow management to take the accounting viewpoint at face value, then they are effectively ceding control of the business structure to the accountants.
Business architects need to pay attention to the structure of cost. Accountants allocate costs according to implicit (and often simplistic) architectural assumptions. For example, accountants use activity-based costing, based on a very simple activity architecture. If left unchallenged, these cost allocation rules can create difficulties for architects in establlshing the business case for shared services and shared infrastructure platforms, and other architecturally-led initiatives. This is one reason why architects need to take on the accountants rather than accept the accountancy view at face value.
See also my post on the Calculus of Cost. This is one of a series of posts on The Purpose of Business Architecture.
See also Tom Graves, Financial-architecture and enterprise-architecture (30 September 2013)
Updated 2 September 2013
Management accounting provides a view of the distribution of costs, benefits and risks. Costs include labour costs, materials and other purchases, and so-called overheads. So if we want to know the total production cost of a particular product, or the total cost of a particular activity, we need to work out what share of the total expenditure should be allocated to this product or this activity. These calculations are important for many reasons, including deciding whether to invest in improved systems and technology, deciding whether to keep some capability inhouse or outsource, determining how profitable a given product or service is at a given price and volume.
In One Strategy One PL (January 2013), John R Moran argues that a company can only have a unified strategy if it has a single unified accounting view, and suggests that "the entire logic of profit centers rests on the assumption that maximizing the pieces will maximize the whole". Clearly the relationship between the performance of the pieces and the performance of the whole is an important topic for architects.
Accountants use various simple methods for cost allocation, including so-called Activity-Based Costing. These methods all make some structural assumptions about the dependencies between activities, capabilities, resources and other things. They also involve rules about handling expenditure spanning more than one accounting period. These assumptions also affect project evaluation (e.g. return on investment).
If these structural assumptions are simplistic or incorrect, the management accounting view may lead management to make poor decisions - for example, about investment or cost-cutting or outsourcing. (See my post on Architecture as Jenga.) So business architects need to appreciate what structural assumptions are implicit in the management accounts, and be prepared to challenge these assumptions when necessary.
This is not just because business architects should understand the structure of the business, but also because architecturally-led initiatives may depend on producing a business case that relies on a correct allocation of costs and benefits. For example, architects often wish to advocate long-term investment in shared services and platforms, but such investment may sometimes appear unattractive or unfundable when viewed from a conventional accounting viewpoint, and may be hard to get through the conventional budgeting process. If architects don't understand the potential distortion of the conventional accounting viewpoint, and allow management to take the accounting viewpoint at face value, then they are effectively ceding control of the business structure to the accountants.
Business architects need to pay attention to the structure of cost. Accountants allocate costs according to implicit (and often simplistic) architectural assumptions. For example, accountants use activity-based costing, based on a very simple activity architecture. If left unchallenged, these cost allocation rules can create difficulties for architects in establlshing the business case for shared services and shared infrastructure platforms, and other architecturally-led initiatives. This is one reason why architects need to take on the accountants rather than accept the accountancy view at face value.
See also my post on the Calculus of Cost. This is one of a series of posts on The Purpose of Business Architecture.
See also Tom Graves, Financial-architecture and enterprise-architecture (30 September 2013)
Updated 2 September 2013
Friday, September 07, 2012
Architecture as Jenga
#entarch In my post Where were the architects at RBS? (June 2012), I quoted a banking sofware expert comparing banking systems to the game of Jenga. I now want to expand upon the Jenga analogy.
Casual observers looking at a large and complex human activity system can easily convince themselves that there is a lot of inefficiency and waste. So it looks as if we can save huge amounts of money simply by taking out all the unnecessary pieces. But this is a bit like a game of Jenga. If you try to remove pieces without understanding the overall structure, you are likely to cause the whole thing to collapse in a heap. This seems like a pretty good reason for doing some kind of business or systems architecture.
However, complex human activity systems generally don’t just stop working. The people in the systems usually find a way to keep things running, although with a lot of hidden costs, including personal stress.
This has a lot of bad implications. Firstly, it is bad for the people and the working environment; among other things, excessive stress is damaging for people and their working relationships. It is bad for the architecture, because it results in a lot of additional structure (props and supports and workarounds) to keep the systems up and running. These props and supports and workarounds often end up costing far more than the original system, so it can be pretty counter-productive in terms of the cost-saving objectives. And finally, it is bad for the decision-makers, because the full consequences of their decisions are often unclear, and they may go on to repeat the same pattern.
I’m not saying that we shouldn’t eliminate inefficiency and waste – but in order to do it properly and safely, it helps if we have a proper understanding of the overall structure and behaviour of the system – in other words, an architectural view.
Casual observers looking at a large and complex human activity system can easily convince themselves that there is a lot of inefficiency and waste. So it looks as if we can save huge amounts of money simply by taking out all the unnecessary pieces. But this is a bit like a game of Jenga. If you try to remove pieces without understanding the overall structure, you are likely to cause the whole thing to collapse in a heap. This seems like a pretty good reason for doing some kind of business or systems architecture.
However, complex human activity systems generally don’t just stop working. The people in the systems usually find a way to keep things running, although with a lot of hidden costs, including personal stress.
This has a lot of bad implications. Firstly, it is bad for the people and the working environment; among other things, excessive stress is damaging for people and their working relationships. It is bad for the architecture, because it results in a lot of additional structure (props and supports and workarounds) to keep the systems up and running. These props and supports and workarounds often end up costing far more than the original system, so it can be pretty counter-productive in terms of the cost-saving objectives. And finally, it is bad for the decision-makers, because the full consequences of their decisions are often unclear, and they may go on to repeat the same pattern.
I’m not saying that we shouldn’t eliminate inefficiency and waste – but in order to do it properly and safely, it helps if we have a proper understanding of the overall structure and behaviour of the system – in other words, an architectural view.
Subscribe to:
Posts (Atom)