Accounting reports are management tools. A way to see what's happening, the basis for well-made decisions.
Like bettering profitability (very popular task).
The way those reports are built, strengthened by legal requirements often expressed by GAAPs, is another leftover from the good old industrial days.
A fact that has a huge influence in daily business decisions, and eventually has an impact on your life.
Allow me a rethink with some slightly (!) simplified examples:
Classic P&L structure for a typical producer of consumer goods:
Sales 100
Materials 25
Prod. wages 50
Cost of goods sold 75
Gross profit I 25
Marketing 4
Admin and OH 11
Finance 5
Earnings before tax 5
Imagine being the boss looking at this, you would go "Hmm, where can I start?"
And sure, cut materials cost with 10% and you get a 50% increase in EBT! Even better, what about slashing production wages with 10% and you get a doubling in profit! Welcome year-end bonus, welcome hero status. Hello outsourcing.
Now to something completely different, accounting-thinking-wise:
1) Start with what the consumer is willing to pay.
2) Forget about your classic thinking that the business ends with its employees, the legal entity, the organisational chart. Include everything all the way to the end-user.
3) Look for anything that smacks of 'information', anything that (feel free to stretch your imagination) could be replaced by information technologies:
- Sales (check),
- distribution and inventories (sure, they're there to put let the consumer touch and feel, mostly),
- marketing (oh, absolutely),
- administration (there is a bit of awkward communication and information exchange happening there too). But for simplicity lets split the admin & OH into 'strategy' and 'admin', first one not information-type.
The thingamy GAAP P&L for the same company:
Sales (to end user) 200
Materials 25
Salaries 50
Cost of goods sold 75
Gross profit I 125
Strategy etc. 6
Fixed assets part of finance 4
Gross profit II 115
Distribution & retail 100
Marketing 4
Working cap cost 1
Admin 5
Information costs 110
Earnings before tax 5
Now this makes it more interesting, what catches your eye? Where would you focus to attain your Porsche at end-of-year?
Information costs of course!
Squeeze 10% out of that and you'll get more than a tripling of earnings! That counts.
Now the important part: Business have been staring at their standard GAAP P&L's for so long and done their daily, weekly, annual squeeze of that. The toothpaste tube is pretty flat, creative re-rolling of tube yields tiny nuggets of paste.
Try the other tube, the information-cost tube. Untouched, full, and a little squeeze yields amazing globs of paste.
But remember to start with what's effective, the decision-analysis-tool, the accounting! That's the map that the decision-makers use.
Direct them to the other tube.
Hello,
Sure, as you said in your post about thinkgamy manifesto, accounting science came from 1494 (http://en.wikipedia.org/wiki/Luca_Pacioli) when technology was pencil and paper, a now so-called "two dimensions technology".
Double entry accounting doesn't capture what happens to things, it just capture what things happens according to predefined views.
In current computer age, we now can capture the reality, what happens to things in a multidimensional way. More often, accounting is a separate IT silo in IT architecture, with specific datamodel as all applications in the information system.
25 years ago, william mc Carthy proposed a new model for accounting which capture reality as it happend from a global business view. This model is called REA, ressource-event-agent. see McCarthy webpage : http://www.msu.edu/user/mccarth4/
This model has been refined with time, and it manage more and more business cases. One of the last release of REA ontology seems to be the model of Pavel Hruby : http://reatechnology.com/
I think that the main issue in information system is to try to integrate model that were built to a specific task (or domain). If a firm was able to build (and maintain) a global ontology of its business, we will have no more integration issue, but instead a kind of global business application like monolithic ERP but more flexible because build by the firm for the firm and not taken from outside by outside so-called "business analysts".
I think that the root cause of the disintegrated business ontology is in the IT organization. Business Objects and Business Processes are not managed as first-class concepts of the business, instead IT organization manage applications, which embodies narrow-ontology business sub-objects and sub-processes.
I try to explain my view on my blog (http://udsi.wordpress.com/), please take interest about its subjects (it's in french, tough, but it seems that you live in France, so maybe, you can read french).
Bye,
And thanks for sharing your insightfull indeas,
Vincent.
Posted by: vincent poncet | January 09, 2007 at 15:08
I just remember a very interesting article about accounting ontology written by a very interesting ontologist Chris Partridge , "A new foundation for accounting:
Steps towards the development of a reference ontology for accounting" : http://www.boroprogram.org/bp_pipex/ladsebreports/ladseb_t_r_23-02.pdf
Posted by: vincent poncet | January 09, 2007 at 15:12
Vincent, very interesting indeed!
After just a quick glance on the REA (will study more) - it seems we're on the same page.
Although for us the "accounting" becomes just another report based on the data produced and captured in/by the flows of the Business Model.
Like they say "all accounting artifacts are always consistent, because they are derived from the same data; for example, the data describing the sale event is used in the warehouse management, payroll, distribution, finance and other application areas, without transformations or adjustments."
That is what we do, albeit perhaps solved differently: We use report-templates that maps from the report to the data, raw of course. For us you can define a Sale in any way you want, like when an object (Bike say) changes owner from "Company" to whatever, or if the GAAP wants it differently, when the linked invoice-object is paid off, or whatever.
That way you can run as many GAAPs in parallel as you want.
Mapping from an account (as defined by the CPAs GAAP Account Plan) uses object type, tags, place, link and owner in any combination and/or and adds or subtracts the cost or any other numerical value for the given period.
Of course this gives an interesting side effect - our balance, normally a static snapshot - is generated dynamically. Inventory today would take all objects according to the rules and add all values minus all that has changed it status (sold off or otherwise) for the same period.
Thus we can produce a balance for any moment in time, down to the minute, and even use the same balance report to give you balance changes over any period!
Thanks, great pointer! (Yep, I live in France, close to Cannes - but have to admit less than perfect language skills :) )
Posted by: sig | January 09, 2007 at 15:41
For a current view on REA, I recommend to read latest REA 2006 conferences papers.
http://itu.dk/people/hessellund/REA2006/
Specially, McCathy presentation in which he describes REA as a new ISO standard
http://itu.dk/people/hessellund/REA2006/papers/McCarthy.pdf
http://itu.dk/people/hessellund/REA2006/presentations/McCarthy.pdf
Posted by: vincent poncet | January 10, 2007 at 01:05
Vincent, interesting reading - and I'm getting my head slowly around the differences from what we're doing (first stab this!):
1) Their basis is "not to rock the boat", i.e. take common denominators from legacy enterprise software and standardise and simplify to create a base for a new software interacting with that legacy stuff. Basically not change the architecture.
We on the other hand say that you have to change that architecture, sooner or later, as it is based on another model (the way we do things today) that is in reality outdated. So that's what we've done.
2) They're still "event-driven" while we are purely "object-driven". They still talk about sales-order to represent the sale, an event.
We don't bother with any sales order, the object itself can capture that by a property, say an "owner property" which then can be mapped by the account template for "sale" - add up the objects that changed "owner" from "us". And so forth.
We see that this gives a huge leap in process flexibility and model simplicity, and more important, only one data-object to represent the real-world-object. (Not a stack of documents)
But I'll study on, definitely some good stuff therein!
Posted by: sig | January 10, 2007 at 11:08
I'm perfectly on the same line as you.
We need to trash our current architecture, build a new one upon BO&BP, and organize IT division around these concepts.
That's my point on my blog ;-)
But we also need to manage the transition, which will take a long time.
Posted by: vincent poncet | January 10, 2007 at 14:53