My First Digest

Work Flows and Wealth Creation

Tue, 02 Feb 2010 08:16 GMT

Inseparable since the beginning.

Following the last post about Information, Knowledge, Wisdom and Innovation let's add one particularly interesting and dynamic object organiser, an object by itself: The Workflow. The representation of a particular sequence where value is created and wealth built.

Work flows, mostly in groups, sometimes on your own, but always as a sequence of activities is where all value is created. If the value creation efficiency increases, then wealth is created.

For each historical and economical "age" the efficiency of value creation, and hence wealth creation, took two major leaps in two distinct steps; the first addressing the work, the second step mostly much later, when the work flow was addressed.

First we changed the "What" we do: From gathering in the wild to planting seeds to be harvested. From using muscles to letting an engine do the hard work so we could create and refine for more value.

Then we changed the "How" we do things: Irrigate instead of waiting for the rain, plough dung and more back into the earth so the plants were well fed. Put cars together on a assembly line so time is spent on value creating work not on organising work.

The new "What"s and "How"s gave an enormous boost to the overall wealth and living conditions, but the changed "How" probably delivered a bigger boost than the first change of "What":

In the agricultural age it was irrigation, fertilisers and knowledge of what crops where and when that made things really take off.

In the industrial age Mr Ford gave us the proof when he automated and supported the flow without making any changes to the value-creation-work as such - going from 728 man-minutes per car to 93 man-minutes per car in one year. It was not even expected, but Henry was probably mildly amused by the results while it filled his coffers faster than anything seen before.

So now we're supposed to be in the "information age". And yes, step one has been done, "What" we do have changed and we do not spend time in typing pools any more.

But we still have not done anything about step two. The work flow is the same, the age old methods still rule and takes up about 65% of people process time. Organisational hierarchies, organising, budgets and meetings still hold the actual value creation activities together, methods more or less unchanged since Julius Caesar was at it.

[Thanks Hugh, perfectly put!]

When we get to step two we shall be able to declare that the "information age" has really been accomplished, but not quite yet. And I would suspect that the first one doing it will reap results not seen since Ford back in 1914.

Information, Knowledge, Wisdom, and Innovation

Tue, 19 Jan 2010 08:42 GMT

These four concepts makes humanity move forward. They're basic requirements for every day work as well as for Big Important Decisions, hence nothing to take lightly. Indeed, if possible to grasp, sort, handle, and model efficiently we would all be better off. So lets have a closer look.

Where is the wisdom? Lost in the knowledge. Where is the knowledge? Lost in the information. — T. S. Elliot

Well put, but it also has the kernel of something more, so let me rephrase that by turning the dependencies upside down (keep in mind that "objects" can be tangible or intangible):

Information = object facts
Knowledge = object relationships
Wisdom = object relationship patterns
Innovation = rearranging object relations

But do not for a moment be fooled by the philosophical whimsy, this touches, no, it is the very essence of any software system or management practice that purports to support the future of organisations.

Do it right and the results will be important, keep on doing it wrong and one shall become the 'lanterne rouge'.

Information: object facts

The car is blue, she's 167 cm tall. Object properties. Information.

Where we go wrong: Thanks to habits developed under old technologies we mix Presentation and Representation, mash logic and information, for the same object. Mostly into documents, forms and accounts, but also into the business objects of large Enterprise Systems.

How to better: Information should be Representation only. Take the information and add logic for Presentation separately when needed. Kill the notion of documents, forms and accounts. We are not limited to scrolls, quills and ledgers any more.

Knowledge: object relations

This we call a "coffee mug" and you have never seen such a thing: The "teacher" fills it with coffee (or tea or water), holds it by the handle in her hand and moves the rim to her mouth while tipping it. Voila you can now use the "coffee mug" with confidence to sip or drink the liquid of choice, you have the knowledge.
This is how children learn, this is how Plato defined knowledge.

Where we go wrong: The problem starts with the information as the "holders" of information keeps more than one object. A letter from the bank holds information about you, your house, the bank, the banks offices, your account and more.
Precisely relating a suitcase of different objects to another bag of other objects is not possible. Hence the knowledge is lost in the (bad format of) information.

How to better: One-to-one only. Single model objects representing single unique real world (tangible or intangible) objects only. Then relate these precisely in the model as they are in reality. That would lower model and system complexity tremendously as well. Reality has the lowest possible complexity. We create unnecessary complexity by using bad models.

Wisdom: object relationship patterns

Over time we (might) become wise for one simple reason: We accumulate knowledge and as humans we're inherently good at recognising patterns. First it takes the form of intuition or gut feeling (male term for intuition), then with luck, one is able to understand and approach the feeling with structured thoughts putting words to the reaction, understanding it, and wisdom emerges.

Where we go wrong: Recognising patterns require a clear view, and lowest possible complexity. But as we can see, most efforts to structure information and add knowledge has failed and thus messed up the path to wisdom. So we most often end up being wise in areas of less commercial importance and thus less structured. Typically life issues are were wisdom emerges, for sure important, but for the overall benefit of mankind it would have been nice if wisdom could be a part of our value-creation life too.

How to better: Fix the two first issues and the rest follows.

Innovation: object relation rearrangement

Why would we only listen to music in the living room or concert hall? Walkman ensued.

Where we go wrong: Yet again, mashed up objects equals irrelevant and rather useless relations leading to a less than clear material to work with and innovation suffers.

How to Better: Simple, as above; fix the two first issues and the rest follows.

Represent real world objects by unique and single objects, then relate these precisely, just like in reality.

Those changes alone will automagically rectify the issues and better models will ensue. And with truer and more direct models of reality we'll all be much better off on all levels - wisdom and innovation included.

Process Engine + Social Media -> Thingamy and ESME

Thu, 07 Jan 2010 04:34 GMT

For a long while I've been keeping an eye on the E 2.0, collaboration and social media efforts meant for enterprise use. I have to admit to being a sceptic, still viewing such as mainly single-task tools with little or no process and mostly lacking any way to add accountability and task ownership.

When discussing this with the large Enterprise Software vendors this has not been countered, quite the opposite, and promises of adding some 'process' to their E 2.0 / socmed efforts has been uttered.

In regards SAP's latest E 2.0 effort my fellow EI'er Dennis Moore suggests:

"SAP can distinguish 12Sprints.com by integrating it with business processes and enterprise data, including the Business Suite and Business Objects. This is an area few other collaboration tool providers are venturing into, and one where SAP has a natural advantage. If SAP does take this path, it is likely that 12Sprints.com can deliver real value to enterprises. This likely would result in new customers for SAP, new users within SAP's installed base, and greater customer satisfaction for SAP's existing customers."

To which I humbly disagree: SAP do not have any process engines (nor do any of the other big ones) for Barely Repeatable Processes, and this tool (12sprints) is for people centred processes that by definition are BRP. Hence SAP has no suitable process engine to integrate with.

But I do not think slapping some "process'ish stuff" on top of E 2.0 / socmed / collaboration tools would not cut it, that would be like putting the cart in front of the horse. Or at best elevating E 2.0 to Middleware 2.0.

Better, and I think the only way to go, is to have a core process engine and data architecture onto which the ad-hoc and mostly single task social media and collaboration tools could be added.

To put my money where my mouth is, we integrated some social media into our own BRP process framework in between the holiday parties and food frenzies.

ESME, aka Enterprise Social Messaging Experiment is now a part of the Apache Incubator program, developed and supported by a group springing out of the SAP mentor program.

Yes it's quite similar to Twitter, but it has features and abilities minted for the enterprise user - hence a perfect starting point for Thingamy.

Here's a conceptual description:

Thingamy's Work Processor runs the workflow without a glitch with path choices at most corners - punting a little "train" of relevant and inter-related objects (Workflow/issue/request/idea object - the main one + Assignment objects) through a workflow. The Assignment objects holds the task instructions and captures what's done in the assignment while the Workflow objects holds the details about the issue/idea/request.

That way an Assignee is presented with relevant objects, all the pertinent information required for a specific task + the Assignment object to fill in with result and files.

When having been assigned a task, or when trying to get one's head around the progress of a workflow there is always a need for ad-hoc communication with co-workers and/or other participants; "anybody know...?", "Could somebody help with...?" etc. Normally that would happen by email, phone or walking around - all of which limits the discovery of the unknown, like a co-worker having unknown but useful knowledge or ideas. And it would not add the very useful effect of "peer review" either.

ESME adds that crucial part of "Discovery & Discussion" that inevitably is needed during any process; in a task or when studying the progress. In addition it should become the natural in-system conduit for communication as well as the social pivot point, the water cooler, for the group/department/firm.

The crux being that the data in the two parts must be related - and that is implemented here; any ESME message can be related to any Thingamy object adding context to both sides - in the midst of a task, when studying the automatically generated reports or when scratching your head wondering "what's this discussion about?".

I don't know what next step, as in features, will be - our philosophy is to keep it as simple as possible in the beginning and only add if it makes huge sense and works in practice. So we'll see, the good thing is that both ESME and Thingamy are extremely nimble and doing crazy stunts underway shall be easy.

And here's a quick and dirty effort to demo the result within seven minutes :)

[Update - more discussions out there: Dennis at Zdnet, and David at Biztwozero.]

How not to do it - 12sprints and Chatter

Mon, 21 Dec 2009 05:09 GMT

More and more Enterprise Software vendors (and users) have their "aha!" moments, getting the reality that "unstructured", Barely Repeatable Processes are immensely important.

Not only happens about 60% of all work in such processes, but no proper process based IT exists, leading to about 65% of all time spent at such work being spent on running the processes and not on value creation.

So what are the vendors doing?

Grasping at the term "collaboration", then stitching collaboration tools together hoping for some process structure to ensue. Some early examples, before the serious stitching and slapping-on has commenced, are Salesforce and their Chatter, SAP with 12sprints and misc. creative plug-in uses involving Google Wave.

The process result is equal to sending mail from Word. And back again.

Instead of approaching the issue from the bottom up, creating one core that orchestrates all tasks and activities with a single data model for everything that happens, they slap something on the top like bandaid applied to broken legs.

Sucking data from one application, via APIs, applying local logic, then sending off to the next application with another data model and logic looks fine on the surface - some illusion of process ensues.

But process illusion is not process reality!

Where's the full real time overview? Where's the historical data? Where are the easy changes to process? And, most importantly, where is the process-data (not the process-result-data)?

Nowhere. Or everywhere in different formats.

Illusions works for awhile but will always fail.

It's so strange here...

Tue, 15 Dec 2009 08:45 GMT

As a kid I was a huge fan of a Norwegian poet named Sigbjørn Obstfelder, a contemporary and friend of Edvard Munch (I'm a big fan of him as well).

[Drawing by Oda Krogh, Wikimedia Commons]

Now, many years later, when watching and participating in the Enterprise Software discussions I am reminded all the time about this one - "Jeg ser":

I look...

I look at the whitish sky,
I look at the clouds, blue-grey,
I look at the bloodshot sun.

So this is the world.
So this is the planets' home.

A raindrop!

I look at the lofty houses,
I look at a thousand windows,
I look at the far away spires.

So this is Earth.
So this is the home of mankind.

The clouds, blue-grey, are gathering;
the sun's gone away.

I look at the well-dressed gents,
I look at the smiling ladies,
I look at the tired horses.

Now the clouds, blue-grey, thicken.

I look and I look...
I must have come to the wrong planet.
It's so strange here.

[Thanks to Åsa who printed an English translation by Caru. Original here.]

Two years ago I wrote a post about SAP and a big opportunity they're missing; how Barely Repeatable Processes are a much larger part of the enterprise world than Easily Repeatable Processes and how completely under-supported by Enterprise Software they are.

That was not only meant for SAP of course, it applies to everybody else in the Enterprise Software space as well.

Since that post it has become widely accepted that:

1) Barely Repeatable Processes (BRPs) stands for 60% of all work, or even WW value creation, while the Easily Repeatable Processes (ERPs) stands for only half of that.

2) For the value creation that happens in BRPs only about 35% is real value creation, rest of the resource and time use is to support the work flow as such.

3) ERPs are fully supported by all kind of process based Enterprise Software from the three letter ERP types to BPM.

4) That BRPs have no process based Enterprise Software to support it.

Should not be very hard to draw some conclusions from that:

A) BRP is a much larger market than the existing and mature (ERP) Enterprise Software market. (Two times)

B) BRPs are utterly under-supported process wise. (No support in fact, a virgin market)

C) That any good process based system to support BRPs would deliver huge customer value instantly. (Convert up to 65% of all resource use to value creation is no trifle.)

So what the heck are we waiting for?

I look and I look...
I must have come to the wrong planet.
It's so strange here.

Or to put it differently in these end-of-year days and times of predictions: Once the reality described above eventually becomes acknowledged it will be within the BRP space that Enterprise Software will grow, big time. That'll be where things will happen.

Office work is like shovelling snow

Wed, 09 Dec 2009 07:36 GMT

When I entered the work force I lived in a log cabin in the woods, only connected by a footpath to the road, very romantic, but with a few "hardships" thrown in.

When winter hit, nightly snowfalls had me out in the morning in gaiter protected suit, shovel in hand working my way meticulously towards the main road. A brisk half hour of very fresh air to allow me go about what I was supposed to do; work.

Once at the office, precisely the same thing repeated itself, even in summer: For every request, idea or issue some sort of a process started and I had to get started. As always it was an unsupported, unknown, and unstructured process so I had to 'make the path' myself. Much organising, todo listing, letter writing (in those days), phone calls, meetings and planning to do - the office worker's equivalents of shovelling and stomping snow to create a negotiable path before any value creation could happen. About 65% of one's time as it is, according to studies.

Handling the snow: If I'd bothered I could have had somebody to clear my path of snow and spend less time and effort just to get anywhere. Simple solution, only a matter of cost.

Handling work: If the year was 1959, like on Mad Men, I'd have an efficient secretary that would keep all work flowing so I could stick to value creation only. But alas, the fifties are over. The only hope is for some process based IT system that can deliver my work path so I can create value all the time and not spend it on organising myself and others.

No...

Fri, 04 Dec 2009 08:13 GMT

No container, then no content.
No data context, then no meaning.
No process, then no business.
No presence, then no record.

Words makes no sense unless they're arranged sequentially on paper or in a text or html file, i.e. held by a container.

My address has no meaning unless somebody tells you that the "7" is the house number. Your name has little meaning unless somebody denotes your first name as "First name".

Container, content, context - observed in situ

People work together in sequential activities; the making of a business or an organisation. A note has little meaning unless you know from whom in relation to what, when, what did he know, what happened before, in short what was the process.

Why then is all Legacy Enterprise Software focused on capturing the sale, the transaction, the finished report, in short only the process results?

Because you have to "be there" to see and capture the ongoing.

Legacy Enterprise Software do not deliver the process for the main part of what most do every day - the unstructured, the untamed, the Barely Repeatable Processes - hence "it's not there" and cannot record what happened.

Today there's a frenetic, although commendable, drive to support Barely Repeatable Processes using collaboration tools from E 2.0 to Salesforce's Chatter and SAP's 12sprints. They deliver on the two first points, but skip the two last points leaving the process to other means and cannot therefore capture the most meaningful of important contexts.

That's not good enough.

Simple is always better, but harder to sell

Wed, 02 Dec 2009 08:04 GMT

The classic "Apologies for the long letter, I did not have time to write a short one" surely applies to development of Enterprise Software.

So I've spent my time with Thingamy, too much some would say, exactly enough I say. And it's become simple, to use, to install, still looking like it'll deliver on promise. In fact it's exactly simple enough, complexity happens when it happens and not before.

It's like a walk in the park, very simple, but map out the path, step by step, and it becomes complex. But who cares at that point?

The problem arises when people are used to see and analyse the steps, every one, then suddenly selling the simple concept of a walk in the park is no more a... walk in the park.

That's my experience. Before one sees Thingamy in action it's "advanced", when seen it's "wow, it's simple". But still, some leap of faith is required and I strongly suspect my story has become all too conceptual.

So my fault entirely. But heck, it's hard to explain a simple thing if it breaks with habitual complexity. Or is it really something about "complex" being reassuring after all? A preference to believe arising from not understanding over facing reality? Or is it only me who has not freed myself from earlier conceptual deep diving?

I'll hone my abilities to tell the story, if it pops up here, please give it a quick look see and give me a hard time :)

Discovering the universal Business core

Tue, 01 Dec 2009 09:42 GMT

What should Enterprise Software do if it stopped wasting everybody's time supporting the work to allow real work instead of supporting real value creating work?

Obviously, it should directly support the work that actually creates value. If it did that, much of the work to allow work would become irrelevant and much resources could be freed.

Over the last few years I've been busy analysing all kind of businesses, and in many cases built models thereof on our Enterprise Software platform.

Slowly but surely, like peeling an onion, it seems that I've found the core. A core that could model any business.

And that's pretty important, with a generic business model the step to a code based model is short. That could lead to a process based IT system that could run any businesses. Or government, health or education organisation.

This model can make the ubiquitous Barely Repeatable Processes repeatable, structure the unstructured processes, tame the untamed processes:

Everything starts with one of three instigators: An issue, an idea or a request. A customer calling, an idea that hits you in the shower, a patient with a broken leg, perhaps some observations in the field, sudden drop in sales figures or a new survey landing on your desk. Register that and you have the start of a value creating workflow.
That will lead to a first level of assignments, to yourself or others, that might be termed "research" or starting with "please find out...".
With results in from that first level of activities you can now discuss it, even ask pointed question to specific people you might think have valuable input. An asynchronous version of a meeting - "Peter, what do you think about...". Or even have an old fashioned meeting with donuts as a single task assigned to whoever you'd like as meeting organiser.
As the issue, request or idea starts accumulating good and bad solutions, you'll get closer to the point where you and perhaps some others will make a decision: This is the best solution, lets implement.
With that, another multilayer set of assignments will happen. As assigned tasks are ticked off, new levels of sub and sub-sub tasks are assigned then finished off, something that looks and behaves like a 'project' unfolds. Until all done, solution implemented, leg plastered or a new product designed and set in production.

Converted to code, it would function like this Work Processor, no rules, no limits:

8 minutes simple process demo.

Legacy Enterprise Software impedes gravity

Tue, 24 Nov 2009 09:43 GMT

Movement requires a force.

Gravity or electromagnetic force is not enough, a clear unobstructed path is required as well.

The nature of the force is important; gravity is free and universally present while electromagnetic force has to be applied locally, repeatedly, and consumes power itself.

Gravity is nature's version of the organisational vision, purpose, and personal recognition. Management is more like electromagnetism - requires precise and repeated application consuming massive amounts of energy and resources.

If an organisation has a clear value proposition, a purpose, it will have gravity, moving everything forward as it should and there would be no need for counter gravity forces. In nature on the other hand, we would occasionally have to push a ball uphill, or stop it from rolling down the hill.

Let a steel ball roll down a hill, trust gravity, and leave it alone to build speed as it bounces around. Of course you could put it into a pipe and apply short boosts of magnetic force - doable with precise equipment but instantly counter productive if milliseconds out of sync.

A human being is not a steel ball so the management version of magnetic pulses is often counter productive for the imprecise human path. At the same time humans are self propelled entities that can amplify even the slightest whiff of personal gravity. Well aligned purpose, clear visions and above all, and unhampered path to the destination will always increase the speed and quality of the actions.

But alas... back to my snowy (sorry, was born in a snowdrift) metaphors again:

Give a good snowboarder a great snowboard and a pair of well polished goggles and tell him to get down to the bottom as fast as possible. Gravity is on his side and he knows how to use it.

Would stopping every 200 meters to yell back at you how far he came, meet with the other snowboarders every 500 meters to discuss progress and plan next 500 meters or even having a coach following him and requesting him to stop to discuss technique get him down faster?

Don't think so. Still it's the latter model that is dominant in business.

Office worker stopping mid-work waiting for meeting to start.

And what support is always included in Enterprise Software? Management, control, budgets, reports - it's made for the current ways: Instead of keeping the snowboarder's goggles clean it increases the coach's vision and voice volume so he can interfere faster and more often. It does not trust gravity, it works against it.

Time for enterprise software that trusts gravity, it is.*

* say, thingamy's Work Processor...

[Tongue-in-cheek sports analogies bonus: Snowboarding is a geek sport, a programmer understands the natural flow of his coding. Golf is more of a manager type of sport - stop and go, meetings, right elbow adjustment, remember to bend right knee, left wrist two inches the other way, now hit the ball, then walk proudly/annoyed (delete one) over to ball and wait.]