My First Digest

Enterprise Apps User Interface - the wrong discussion

Wed, 10 Mar 2010 08:38 GMT

Imagine an Enterprise App with UI design lifted from World of Warcraft? A tad gothic?

But games work, kids dive into them in droves and never seem to scratch their heads. Electronic games now being a bigger industry than the film industry must mean that their user interfaces work as well.

So it would be safe to assume that the UI issue is not about what it looks like.

It's about what happens in the interface.

Dynamic works, static does not:

A game is always a process, it delivers next task without delay, and more, it's a process where the participant chooses what next - i.e. the perfect BRP (Barely Repeatable Process) and quite like reality. Ah, yes, forgot, games are indeed (fictional) reality models are they not?

When in a game, or in reality, what matters is that you are given complete and relevant information for that particular task so you can make up your mind and proceed to action. Monster to the right, monster on the left. Then, at the same time, one single tool or click to get the task done, now. Shoot the monster on the left. One activity at a time. Few and logical choices, just do it and get on with life (eh, game) now delivered by the process engine in the form of yet another gruesome monster walking into sight.

And this is the process that happens in WoW and at your office every day, every hour, very BRP:

A temporary activity or sequence of activities initiated by an issue, an idea or a request, with multiple participants where the sequence of activities are directed by human knowledge to act according to the current situation and related circumstances.

Now the typical Enterprise Software: Basically it's not a process engine that simulates, or models, reality. It's mostly an organising tool, delivering all options at once, no simple yes/no decision based on relevant information restricted to task at hand.

Last time I counted buttons and choices in a simple CRM UI I found 150 links or buttons to click. And under many there were countless more options.

Process? There is no process delivery/automation in most software systems for use in Enterprise BRP. Any process is strict DIY. You create your own process, so claiming that the system "have process" would be a gross overstatement.

Proper automation and delivery of process is what matters. No layout, colours, rounded boxes can rectify the lack of such.

Hence, a discussion about what Enterprise Software should look like and how to present functions, would be a waste of time. The well-meant design efforts as well. Waste of time, save it for later. There is only one way to attack the issue - fix the source and build everything on top of a process engine.

[Thanks to @vendorprisey, @dhinchcliffe and @bitterer that suggested Enterprise Apps UIs should learn from Games. Then @yojibe and @mrinal who piped in with a good discussion.]

Elegant Organisations? Daily Simplicity? Fugetaboutit!

Tue, 02 Mar 2010 09:13 GMT

"Entia non sunt multiplicanda praeter necessitatem"

Occam's razor keeps it simple - "entities must not be multiplied beyond necessity". Or in short form; simple is better.

A basic philosophy of science - simple is better. Einstein could be a signatory to that principle.

And for us little people we drift towards simplicity. Yes we want features, but by all means give me one button to control it all. Jonathan Ive of Apple is revered as the current master of simplicity, and we love what he does. Braun had the same success when they had a strong designer running the show. And today, consumer car reviews usually ends up with detailed criticism of the navigation interface instead of chassis refinement. Simple we want, simple is elegant, simple makes our lives simpler.

Dieter Rams simplicity. Source www.wallpaper.com

All good and well until you leave home and enter the workplace. Meet the organisation, another form of entity:

Picking up a random business card from my coat pocket I can read "Tech Solution Manager Part of The Intelligence Platform and Market Insight and Enablement Team". Wonder what the strategy of same firm reads like...

Ah, their strategy... something simple my windy-titled acquaintance could relate to. I looked, I poked, I searched, but alas, could not find it. Some vision snippets here, some there, some clear, some worthy of the (now defunct) Dilbert's vision generator. But no one-button interface to how he should deliver value.

Or, here's how another friend described his own (different) organisation: "Global matrix organisation relying on the brownian motion of clever individuals to create the illusion of progress". Can you hear the frustration between the lines? Can you see how value-creation evaporates?

No wonder both corporations are struggling.

Now, guess how above corporations are addressing these hard times: Reorganising. New titles, people reshuffled, people removed, new reporting lines, injection of fear, frustration, adrenalin and for some, hope.

Seeking simplicity is nowhere in sight. Where are the "work design" Occams or Ives when we need them?

I once did an MBA, cannot remember a class called "Work Design", nor much talk about simplicity principles, only a lot of the term "complex" as if the whole concept of the education was to enhance and cultivate the complexity. Long titles, impossible to understand gobbledygook and power delivered by opaqueness ensured well paid jobs for the freshly minted MBAs.

Something is wrong.

There's a huge glaring hole in the title jungle - "Work Designer". And hopefully the first one's will do to organisations what Raymond Loewy, Bauhaus, Dieter Rams, and Jonathan Ive did to the tangible stuff.

This is what a "Work Designer" could help those two corporate examples above to: A simple strategy, a simple way to deliver the value, a one-button way for all to interact to save time and energy and increase profits.

Forget everything else for now. Time to simplify the stupid complexity. Time for "Good Business Design".

From wishy washy mission statements to singularly clear strategies, from cumbersome and resource depleting manual flow handling to automated flows. Simplicity and focus, one-button interfaces to value-creation, that'll be the future.

And that's where a new kind of Enterprise Software comes in, automate the flow, convert a singular strategy to efficient value creation, that's the only thing that matters.

I'm sure both my friends above will embrace the coming as there's one thing that beats visual simplicity, and that's practical simplicity, aka efficiency.

Enterprise Software's blind spot

Fri, 19 Feb 2010 10:31 GMT

A Project is a temporary activity or sequence of activities with a specific goal initiated by an issue, an idea or a request, often with multiple participants. It is usually unstructured, at least somewhat unpredictable and hence Barely Repeatable.

There are engineering projects, research projects, travel to Mars projects, garden projects and clean-out-the-garage projects.

A Project often begins with some research, a discussion and a decision before a dash of planning and moving into the activity phase where a possible solution is tested, built or implemented. Quite following the form of an OODA loop.

What part of that longish process you would term a Project is up to you, no rules there. But why not call of it a Project? The whole process is after all temporary with a specific goal.

With this somewhat expanded view of what a Project is, it can be argued that a Project is another term for the generic Barely Repeatable Process (BRP). And I have argued before that BRPs are responsible for 60% or more of the world's value creation.

So one would assume that Projects, this type of process, is well covered by Enterprise Software. But alas, what ubiquitous Enterprise Software manages all this value creation?

Spreadsheets. Nothing but spreadsheets.

Who said the Enterprise Software market is mature? Heck, it's not even potty trained yet.

Almost a modern Project Management tool.

And here, a tad more modern-than-pushing-spreadsheets approach.

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 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. [The work part of the workflow]

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 flow part of the workflow]

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, the work has changed.

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.