I like to narrow down the “complexity” of a process to “what can happen after an event/task”. Tasks/events are by themselves simple, but the moment you cannot predict “what next” you’re buggered when using normal tools

BRP is precisely that, every step is “free” within the limits of “purpose” for the organisation or flow and/or business practices. To have a system for that the flow have to allow change of path at every corner without braking the capture nor the flow, and that’s possible the moment your think “object driven” (as in beachball being thrown into a crowd…) instead of “transaction/event driven” where the transaction or event is the focus (that’s how we capture data, by creating after the fact narratives in documents and forms). Let the objects themselves (like the beachball) capture what happens to it. And voila, complexity is lowered down to life level from the model complexity level.

Extending that thinking into accounting, which is the issue you mention: In classic double-entry accounting (since 1494) one records the transaction, slots it into a drawer, using GAAP rules and SIC codes and whatnot. A never ending source of income for accountants, reconciliation and errors. And zero possibility to flip from one GAAP to another or run more than one in parallel.

So the question is: What is a transaction, like a sale?
Transaction oriented: That’s when you slot a representative for the sale (say in invoice) into account #10023 (or whatever).
Object oriented: That’s when all objects of type Widgets change owner (that’s a relationship and can be expressed with an N-triple) from us to whoever else, and if the GAAP so requires, and has left our premises. If the objects “knows’ that (from the flows) one could slap a template using queries on the back end and sum up value of say all Widgets not owned by us (and not residing at our premises) at year end minus all Widgets not owned by us (and…) at beginning of year, which in essence would give you sales according to those GAAP rules. Add another query with slightly different semantics matching another GAAP and presto two GAAP accounts in parallel without any effort.
That way you’ll evade the issue about classification and such, simply use the actual reality facts as captured by the objects themselves.

Sitting here building (a hospital system, shows both BRP and accounting so that’s my favourite) with new and shiny version now, kind-of-beta version (2.2. build 575) and ironing out quirks and bugs as we speak, so soon’ish…

Re “brewing a cup of tea”. The point of the exercise for the students is that even the most simple processes can be hard to express unambiguously. On the (admittedly rare) occasions that I make a cup of tea for my colleagues I get the different versions that they want correct whether it involves peppermint or yorkshire tea bags, milk etc. Which is why I would think this needs to be considered an easily repeatable process rather than a barely repeatable one.

Re “a cup of tea vs a procurement process”. I recall many Ariba eProcurement implemtnations that had enormous difficulties working out what the approval rules should be. And then realising that they needed to be changed once the system had gone live. So it doesn’t fit well in my head to say that a procurement process is really that straightforward. (and this is without even taking into account the possible exceptions: what happens if the item is not in the catalogue etc).

Perhaps a point is that at one level of abstraction, all processes are fairly straightforward. But then once you get into the details they can all get pretty complex? Just thinking out loud on this.

On the subject of tagging. I like the way you take issue with storing information in boxes. Life is far more complex than that. This is something I wrestle with at work on quite a regular basis. The challenge is how to categorise different spend categories. Do you do it based on SIC code hierarchies? On UN/SPSC hierarchies? On ProClass hierarchies? etc. The more I use different category hierarchies the more it seems to me that they break down as often as they work well. So I love the idea of verbs with the tags. I can’t wait to see how you’ve implemented this in Thingamy.

I certainly agree with your two criticisms – but there is still a reason behind why I’m pushing forward on these:

1. Widening the gap between “ideas” and “reality” – agree completely that my take often cannot use current software or other technologies. That’s why I’m at it with the thingamy software,a direct result of telling myself many years ago “shut up and do something about it!’. Still doing something about it so I cheekily allow myself to keep on talking. New version for limited testing coming next week so we’re not that far from real life use.
OK, not going to be quite perfect and all-encompassing in first iteration, but still a quantum leap methinks.

2. Tags. I still think that tags are very useful – for the way/format we “keep” information today. But I’d rather have something that delivers more precise relationships – thus add the verbs to the sentence. Sig tagged with France can tell many stories, but add the predicator “lives in” and sense arrives.
The problem with that is the way we keep information – in documents and forms (leftovers from the pen and paper only days) which in themselves are like “buckets of objects” and a precise relationship between a bucket-of-objects and a suitcase-of-objects makes no sense. Thus the tags being useful today.
Better though if we could do something about the “information format” and then add more precise relationships (which equals knowledge). This we do in thingamy as well, information-holders first, then knowledge-enhancers..

There is one exception to my accord with Sig’s thoughts. It has to do with tagging http://thingamy.typepad.com/sigs_blog/2007/11/categorising-or.html . I still see tagging, specifically in relation to describing items or attribution as a key element in better managing information. Sig sees major shortcomings in the use of tags http://thingamy.typepad.com/sigs_blog/2007/11/categorising-or.html My thoughts are so ill formed that I have not been able to respond to the posting. I think that tags might help describe relationships as well. Maybe they are part of developing BPM that can account for BRPs and ERPs. I don’t know. David Weinberger has me convinced that everything is miscellaneous http://www.everythingismiscellaneous.com/ and that tagging brings order to disorder.

as you note the difference between BRP and ERP is not always clear – but what I find to be the core difference is the “conditionality” of each task:

An ERP, say a procurement process, might have simple conditions attached to single tasks like “if order is more than 10 k then send to supervisor for review first”. Pure production even less options.
While BRP would have almost unlimited conditions for each task, meaning almost unlimited paths the flow would take after each task: A physician studying an X-ray would have many choices. And the tea brewing is similar – due to the unknown environment, is the sugar in place, what do I fancy today and so forth.

If you want unlimited choices at each step you might as well use social software or make a meeting – or use the e-mail and work the phones as today. The trade-off is obvious as data capture relies on after-fact reports (and we all hate to write those) and little chance of learning and bettering as the process is unknown.

Good thing though that in practical life there is no such thing as unlimited (which could allow real process structure/framework) – any business or organisation has a purpose and thus a framework that limits to a certain degree the number of choices. The physician finding you have a broken arm would not send you off playing golf in Ireland…