thingamy

How not to do it - 12sprints and Chatter

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...

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

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...

• 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

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

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:

1. 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.
2. That will lead to a first level of assignments, to yourself or others, that might be termed "research" or starting with "please find out...".
3. 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.
4. 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.
5. 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.