Guest post: Sig Rinde – Abolish Accounting

by admin on March 26, 2007

Sig Rinde is one of the smartest, charming people I know. He’s developing Thingamy a business modeling toolkit. Long term readers may remember the 34-Minute Time and Expense application. It was the third most popular read during 2006 and despite being a year plus old, still gets a fair sprinkling of hits. Thingamy is a great start if you’re thinking about remodeling your business. Sig graciously agreed to crank out a piece for this site and he came up with Abolish Accounting. What a great tagline!

“Accounting is supposed to be the “glass cockpit” of business.

Oops, nope, it tries but is not. It should be, but it cannot.

The throttle and pedals and flaps and engines and gauges in the plane are all aspects of the same issue so they work seamlessly together. Without instant engine response and gauge feedback when throttling I

would stall and crash.

In business those are separate – throttle (orders), engine (work) and gauge (accounting) – comes in different packages. We’re saved from crashing by inertia, but we’re not saved from inefficiency.

In the aircraft a gauge is linked to one engine, no doubt, no reconciliation. In business you have masses of reports and documents that represents one single object – order sheet, invoice, shipping papers, production reports, sales reports, support reports – no end to error sources and checks, balances and reconciliation are required.

In the aircraft you’re allowed to add any kind of sensor to any part to give you any type of measure. In business the sensors are pre-set and regulated, they’re called accounts. That freezes any development of the measurement methods. Actually it froze it ages ago.

Two steps backward please, rethink and start over again:

  • Order, action and feedback must be one. One single system,
  • The real world object is the thing of interest, represent that with one single data-object that captures all that happens to it.
  • Keep all data in raw form and add logic when needed.
  • No more pre-set accounts, abolish accounting (required GAAP reports can be produced out of sight deep down in the basement for the government accounting trolls) and develop Your Own Measurement Methods.

Here’s a suggestion:

Imagine that a widget procured by your firm is represented by a widget-data-object and that the widget-data-object is punted from a procurer to supplier to the shipper to the chap on the dock. The widget-data-object presenting work orders and input fields in each step – “Hi, I’m your blue widget with serial number 2346 just arrived from supplier X, please move me to the warehouse. When you’re done with it please note here where you put me and hit “completed”.” The widget-data-object not only supplies the work order and information needed, but also captures what happens to the real widget in real time.

The system would know at all times where the widget is, who owns it at any time, it’s value, colour and serial number. Slap on a “report template” that sucks out the data and applies some rules to them and

you have the gauges in the plane cockpit. No more reporting errors, no more reconciliation, any kind of report you can imagine today or tomorrow. Real time flying with your own dynamic “business glasscockpit”.

Then perhaps accounting could evolve from it’s ledger past and start to represent reality as it is, or how you see it. At least the “department of input & reconciliation” would be redundant.”

Technorati Tags:

  • http://blog.engineersimplicity.com Duncan Drennan

    I've been reading Sig's blog for a short while now, and really buy into his concepts. As I read this though, there is one thing which stuck me, which is common to ALL business systems and processes, and niggles away at me the whole time.

    Everything runs on people.

    Every time the blue widget moves from warehouse to warehouse that information has to be captured somehow. What if the underlying process – the person – fails to capture the info? It is common to all processes. How can data capture become a natural process?

  • http://thingamy.typepad.com/ sig

    Duncan,

    "Every time the blue widget moves from warehouse to warehouse…" – but it does not so by itself, it does so because some orders it to be done.

    Again the problem is that order and documentation of the result are separate. That's how it's always been and still is as most "orders" is delivered by the classic process infrastructure, the organisational hierarchy. Then slapping reporting systems (See accounting :) ) onto the organisational hierarchy, which of course requires separate and human input. And there you are absolutely right, human structure to IT structure will always be messy and error prone.

    Think different – let "a system" deliver the orders as a todo or a task, have a system that focus on the process and in fact would be an alternative process structure. (Reporting is just a natural extension in that case).
    The operator hooks off the todo as completed (and perhaps adds some information as one tend to do with todos), and that should be enough. Now the system knows what happened to the widget, and thus have the data for whatever report you want. Even something GAAP'ish.

  • alastair

    If I am getting this right then you kind of have a widget journey, and the widget encapsulates within itself where it is on that journey? So if you want to know then you ask it? Sounds a little like the way that some of the more advanced manufacturing businesses document their products – the ones that have quality processes in place to track their products over their lifecycles. Although how they use technology to do it may not match where you are coming from.

    Of course accounting is never any more than reporting, although there are many different sorts, and I think I understand where you are coming from with the “department of input & reconciliation” thing. But I like my debits and credits and don't see why would I want to throw them away? Providing I don't duplicate then surely my ledgers have an important role to play? OK they are time bound and steeped in tradition… but nothing wrong with that!!!

    Actually I don't think we are disagreeing. But to make sense of your widget data I am going to have to understand how to read it – sounds like an open standard of some sort is required? I don't think this does away with people, apart from those redundant chappies that used to key and check data.

  • http://thingamy.typepad.com/ sig

    Alistair,

    as such there is nothing wrong with any GAAP and I do like my Debits & Credits (actually I like my ST Receivables best!) as I know how the stuff works, I'm used to it and I can make sense of it… until a certain point. Then I whip out my HP 12C and try to glean some "raw" data from the manipulated figures in the Annual Reports so I can apply some of my own logic to it.

    In other words it's the "stickiness" of the current rules that I have an issue with first, then that the data is kept in manipulated form so when I or other "middleware" is finished with it the crispness of the data have decreased, and last but not least the fact that you end up with multiple documents pretending to represent the real-world object. That will always give errors.
    And to rid the data of these traits the up-front "accounts" (where you choose account when entering data) would have to go. In other words, do not apply logic up front and cement the data forever, apply logic at the back end when needed, with no limits to the logic so it can better suit your specific needs.

    OK, to the widget example: It is a bit more radical than meets the eye, it breaks with the current ways where we document the event or transaction – which leads to a multitude of "data-objects" per "real-world object". That is how all legacy systems are designed, modeling how it was done in the paper and pen days.

    Instead I would suggest an "object-driven" model: The real widget is represented in the "system" by one single data widget that (thanks to the good old IT) can in fact capture all that happens to it, even keep historical records, no limits to that.

    Then use that data-widget as bearer of data and collector of data for the different events/tasks/todos. Most important though is that the workflow/process is the core of the system, that's the only way to make it work. And with the raw data there are no limits to what reports you can deliver – and it would be real time and no reconciliation needed as there would be only a single data-object per real-object.

    Standards… hmmm.. do not think so, it's about basic design. Hard to get a car and a horse to work seamlessly together, they're two different concepts of transport and no standard horse-car interface would work well (ok, bad analogy ;) )

  • morganusvitus

    The site looks great ! Thanks for all your help ( past, present and future !)

  • http://discount-viagra-35727f7.drozdyonok.org rafenta

  • http://discount-viagra-35727f7.drozdyonok.org rafenta

    <a>

Previous post:

Next post: