DISQUS

Duncan Drennan · 2 years ago

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?

sig · 2 years ago

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 · 2 years ago

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.

sig · 2 years ago

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 · 2 years ago

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

rafenta · 2 years ago

rafenta · 2 years ago