thingamy

CTO, CIO, CMO, CPO, C3PO?

2013-05-07T11:50:46+02:00

The CIO and CTO titles have been around for a bit…

And I can sympathise with that, after all IT used to be something magical hard-to-grasp stuff for many in the upper echelons of the organisations. And much of that obscure technology was brought in the door and had to be operated by somebody in-house, so better have some focused expert for that.

But does that still apply? IT is fast becoming just a component, a rather boring component, of some service that brings value to the organisation.

Cartoon by Hugh Macleod of Gapingvoid fame

So here's the obvious question:

What about those other technologies that are important to our organisations? Motors? Paper? Electricity?

Do we have CMOs? A Chief Motor Officer who has the final say when anything incorporating a motor is procured or used. Who oversees the Motor Department and spends half his time visiting motor conferences and worrying about what quadrant that new engine for his trucks has been assigned.

Or a CPO, a Chief Paper Officer? The chap who impresses the other managers flaunting terms like paperweight, basis weight, blotting, and bristol and tag. The chap who spends his days on paper strategies for the organisation and who has the final say on what caliper to procure for the copy machines.

Just wondering…

Innovate in four short steps

2013-04-30T17:35:40+02:00

Innovation: "Make changes in something established, esp. by introducing new methods, ideas, products or technology"

Everything we do is based on assumptions, most of which are never questioned. That's how we're stuck with bad ways and mediocre products, and that's an opportunity:

1. Make a list of things we do and take for granted.

Sony once heard: "We listen to music in the living room or in the concert hall, that's the way it is".

And Karl Benz heard: "Transport is by train for long distances and horse for mid distances, that works nicely thank you".

If something is done the same way every day then you can be sure that assumptions are not questioned, that's where you should start.

2. Ask "why is it so?" to challenge the assumptions.

"Because the HiFi is supposed to be in the living room, period."

"Because the horse is the biggest mobile power source known to mankind except for steam engines which are too big for the roads."

3. Find new technology or ways that could negate the reasons.

"We now have chips and miniature motors, so small that you can carry the HiFi and speakers in your pocket."

"I can miniaturise the combustion engine so it fits into a carriage, and it can be stronger than a horse."

4. Choose the situations with the silliest counter argument.

"Why listen to music when on the bus?"

"Why have the freedom to travel 100 km whenever it pleases you?"

Appreciate initial strong resistance and the nay sayers, that's a sure sign that you're on the right track.

Rinse and repeat until you have a nice palette of opportunities.

The information age fallacy

2012-10-30T14:20:39+01:00

Humanity has developed by leap and bounds - when we learned to fish the new ample source of protein increased the human chance of survival and forwarded our development, we became smarter and stronger over time.

With fire we started cooking the food and hence made it easier to digest leaving more energy to be spent on hunting and gathering. Again humanity increased its chances of survival.

Then came the "ages", times when technology and methodology allowed humanity to move forward in great leaps:

The hunter gatherers moved on to the agricultural society and the effect over time was excess food production allowing to feed a few to spend time on thinking and fighting on our behalf - philosophy and wars ensued. As did cities and structured societies.

With industrialisation we had another leap forward, the productivity increase was again dramatic and the whole world gained. Enormous excess wealth was produced, and even more people could spend time on services instead of producing food and goods. More healthcare, more support services, we could even afford to universally support the elderly with pensions.

Now we say we have entered the "information age", and expect similar results. But is it comparable?

The hunter-gatherer on his daily forays might have found that certain trees and bushes yielded more or better fruit and berries, or patches of land that made for better roots and vegetables. At some point he must have tried to keep the tree, bush or patch free from competing plants resulting in an increased yield. And with luck that favourite bush would spread and soon he had a proto-orchard on his hands. In short food gathering efficiency increased - "how" he did things changed, but "what" he did remained basically unchanged.

We can only speculate, but his newfound increase in available food would soon become a given with matching consumption patterns. And still he was chasing pigs and birds in the wild.

With humanity's urge to move forward, maybe triggered by a surprising new growth of berry bushes "behind the outhouse", some ideas to change the overall methodology may have transpired: Instead of distributed food "production" along his old gathering paths a patch of good land was selected and he moved his bushes, trees and veggies there so no more time would be spent on walking, carrying and keeping and eye on a wide area. Some pigs followed to breed inside a fence for a subsequent easier "hunt". In short "what" he did changed and the overall effectiveness increased and we had entered the agricultural society. The "how" we did things just became a daily refinement task, a bit hygienic, a part of the daily chore.

Much later the steam engine was invented. It very quickly and efficiently replaced muscle power in mundane tasks like hauling ore and coal to the surface or running production machinery. A huge bump in efficiency was the result - "how" we did things changed while "what" we did remained the same.

But as always the margin growth flattened out again and consumption caught up with the newfound wealth. Then came Mr Ford who in 1913 went one step further and installed the first real assembly line. Now the task, information and tools were delivered to the worker without any need to go look for, fetch or await orders from the foreman - one could claim that management was automated while the actual value creation work did not change, still using the same parts and tools. Within one year one man could produce 8.7 times more cars per hour thanks to a huge increase in overall effectiveness but very little in efficiency: "What" he did changed; no more looking for stuff, no more meetings, just screw the doors on. The "how" he did things, how the door was attached, did not change at all.

In other words - there are two phases each time we go from one "age" into the next:

The first efficiency phase, the "how" we do things is all about technology: Pruning, clearing, engines, calculating, storing.
The second effectiveness phase, the "what" we do is all about process: Concentrate all in one place, automate the workflows so managing (own or other's) time can be freed towards real value creation work.

And note the important learning that phase 2) did not happen until the marginal gains from 1) begins to flatten out.

Let's use the above core principles to analyse the claimed "information age" that we're supposed to be in:

With the first practical IT technologies some 40 years ago some souls found ways to make how we did things way more efficient. Book keeping, keeping tabs on the inventory, writing letters, and calculating things now took seconds and not days. Communication followed suit. Efficiency gains from "how" we did things differently became obvious and all the world's wealth creation had a multiyear bump so politicians could sleep well assured of no recession looming. Taking a cue from history, at some point in time we should expect the growth curve to flatten while consumption catches up with the gains.

And that ladies and gentlemen, is exactly where we are today.

The emperor's new clothes, illustration by Vilhelm Pedersen

Information technology has mostly produced faster ways to do exactly the same we did two thousand years ago. We write the same way but faster, we calculate the same way but faster, we save the same data but faster, we communicate the same way but wider and faster. Facebook is no different than having all in a big room talking and showing each others pictures.

The "what" we do has not changed much; still we have meetings with action items, still we have to write reports, still we have an accounting department to organise the results, and the good old hierarchy is still there to channel the information- and work-flows.

And the growth curve, the marginal gains, have been exhausted: Not much gain to be had by upgrading your ERP system model 8 to model 9. Not much to be had from installing the latest word processor or email client - except for better ways to handle the ever increasing new problems like spam and communication overload and data bloat. It seems that IT knows it's about to hit a wall and are frantically adding airbags to their products.

We have reached the parallel point to when the first farmers were about to move trees and bushes to their prepared plot, or the point when Mr Ford was about to make a recombination of known technologies to get rid of the milling around, looking for stuff and waiting for foremen to dish out tasks.

But the IT industry has yet to realise that - they're now completely absorbed in squeezing out the last margins, in the last hurrah, by making the old easier to digest - mobile, UX, big data, and cloud are the flavours of the day.

Now is the time for IT to refocus on the effectiveness of the whole value creation chain and "what" we do. Using the history teachings the next step now is to give the work a better framework so we can end those Monday morning meetings, reading and responding to hundreds of cc'd mails every day, the untrustworthy handovers, in general not spend 2/3rd of our time on making the flows move forward, aka managing.

Only then can we say we've entered the "information age".

p.s. The figures are rather simple - knowledge work stands for about 60% of the world's value creation while knowledge workers spend on average about 2/3rd of their time on managing the flows. If we could automate that management and spend that time on value creation instead - i.e. change "what" we do - we would look at approximately 120% GNI growth world wide. Which would be the same as the full world wide GNI growth over the last 30 years. Worth the effort perhaps?

Hand washing, IT and Flow Technology

2012-07-17T15:39:43+02:00

One day in May 1847 at the First Obstetrical Clinic of the Vienna General Hospital Ignaz Semmelweis instituted washing hands between autopsy work and the examination of patients using a chlorinated solution, and almost immediately maternal mortality rate due to puerperal fever was reduced with 90%.

The sad part was that even with proven success it was too early to explain what happened, the germ theory was only to be introduced by Louis Pasteur years after Dr Semmelweiss' death.

As the results were going against the established truths of the day, the medical profession would not accept the findings. "Some doctors, for instance, were offended at the suggestion that they should wash their hands, feeling that their social status as gentlemen was inconsistent with the idea that their hands could be unclean."

Surely such feet dragging cannot happen today?

Earlier this year Kane Gorny, 22, a patient at St George Hospital in South London was so thirsty that he called the police, complaining his request for water was ignored by the hospital staff. One day later he died from dehydration.

This winter a one year old boy was in post operation care at Akershus Universitetsykehus in Norway being fed intravenous. His mother noticed that he was looking more and more dehydrated and contacted the physicians with her concern. The request was ignored and the boy died, from dehydration. The subsequent report blamed “bad practices and lack of time”.

Tomorrow, there will be roughly 1000 preventable healthcare deaths in the US and Europe combined. And it'll happen in modern hospitals staffed by some of the best and equipped with the latest. And unless it's a graphical and strong "human interest" case like the two above, you won't hear about it.

It's not germs this time, the fault seems banal - healthcare has a problem managing the resources, the patient-, information-, and work-flows. The problem lies in less than effective ways of running organisations and their processes. Bluntly speaking, we're talking deadly management methods.

One measure of how safe, secure and effective a work and patient flow is, is how complete the "handovers" are. Unless perfect, something, or somebody will be forgotten, and crucial information will be lost and patients could die.

When asked, 51% of physicians did not trust handovers in the normal hospital workflow environment.

In other, less "life and death" organisations, IT has helped managing workflows, resources and more for decades now, often leading to less errors, more efficient use of resources and sometime happier workers.

In healthcare there is no lack of enterprise systems to handle consumables, beds and more. Or applications to support single tasks like analysing scan images. But strictly speaking, currently there is only one IT product that has direct impact on the clinical work: Electronic Health Records, EHR.

The concept being basically "organise the results to get better activities", which of course is pretty illogical. But nobody says so.

Add that 50 to 80% of all EHR implementations fail. Ask any clinical user and I doubt you will hear much praise. The only praise I've seen lately was for Epic when Kaiser Permante installed their new system for their 14,000 physicians - taking five years and costing 4 bn USD and reduced productivity during the implementation. BTW, Epic's electronic health record is based on a 44-year-old programming language called MUMPS (Massachusetts General Hospital Utility Multi-Programming System). It is essentially a closed platform.

There are today 700 EHR vendors in the US with 1750 certified products which in itself is an indication of rather high margins. Do you think they all talk the same language so that your records can flow freely between your local physician, your hospital or anybody else? Don't ask, you'll be scared.

We have to stop thinking IT as in “information technology”, it's not enough just to handle the information - like the EHR. It’s the combined and seamless flow of patients, information and work that offers the only solution - and for that we need “flow technology”, in short healthcare needs FT. Information is merely a natural ingredient in the flows and not vice versa.

[Disclosure: We're a FT supplier, also for healthcare]

Let the managers go

2012-02-21T12:34:42+01:00

Fire the managers and purge the language of the term "management". Long live leaders and let everybody manage themselves.

Most people manage themselves with great success: they manage to get out of bed in the morning, they manage to get dressed, they manage to get to the office on time.

Then, at the office, they meet the "manager" that will manage them until end of the day. That's at best a paradox, at worst a devastating error.

Highly efficient manager to the left

But is it at all possible to do without managers? Let's check reality:

Take a look at this aptly titled article in Harvard Business Review; "First let's fire all the managers". In that you will find the story of Morning Star, a highly successful tomato processor with 60% of the US market and double digit growth in a one percent growth market. They have 600 full time employees and 2000 seasonal, and not a single manager.

Then read Joel Spolsky's post at AVC and see how he turns it all upside down, making the managers into supporters instead, and, very deftly, suggests that the term "manage" should be replaced with "administrate".

Lastly, if you read some of the Steve Jobs biographies and articles you might notice something peculiar: when Jobs came back in 1997 the managers to employees ratio was about the usual 11%, then Jobs changed the structure until they were down to about 70 VPs, or less than a 1% manager ratio. Personally, as I like Apple, I hope the new leadership will not follow Adam Lashinky's recommendations in his book "Inside Apple" to rebuild a classic management structure again.

Ah, almost forgot Open Source: A pretty impressive product development story, and that without a "manager" in sight.

In sum, it seems that, in some cases at least, that a "lack" of managers is not only possible, but in fact might be a trait of some of the most successful.

Still, the question remains; why would it be worth getting rid of management?

There are three good reasons, three negatives to shed:

The management tax
The killjoy effect
The ineffectiveness

1. As a rule of thumb you need one manager per ten employees, invented 2000 years ago by the Roman army (remember dekurions and centurions?). But with 10 managers you need another manager to manage the managers and so forth. All in all about 11% managers in a "normal" Roman army setup as most corporations have. Assume that the average manager is paid 3 times the average employee and you have 27% of total payroll cost as a "management tax".

But that's only the direct cost, managers require extra administration and support, so much of the administrative services should be added to the "management tax". And then, the indirect cost that we so well know: When you're in a coding run or in the midsts of creating a big presentation and your managers pops by and tells you to "drop this and do that" or simply asks for an update, all solidly counterproductive and an indirect "management tax" as well.

2. We're all driven by certain rewards, and most agree that there are three intrinsic rewards that counts: Autonomy, Purpose and Mastery.

What happens when you're assigned a task, or rather "told" to do a task? First of all autonomy goes down the drain, and mastery certainly gets shot when your flow is rudely interrupted. And unless the task delivery was well supported by context and meaningful purpose beyond the needs of the manager, purpose becomes iffy too.

In short, the dual responsibilities of a "manager"; leadership and managing, are in fact two counter forces that should never be handled by the same person: While leadership is all about nurturing those three intrinsic rewards, any "management act" will ruin that important nurturing.

3. What is management really? What's its purpose? Think: what do a manager do?
He/she distributes tasks, delegates work, makes decisions when no others are willing or when centralised decision making makes sense.

It's all about framing the organisational work; channel the workflow towards stated goals within given constraints like time and resource use.

So here we are, running all our value creation workflows in a highly manual fashion in the same way our forebears did it thousands of years ago, albeit slightly faster thanks to IT that moved report writing from quills and scrolls to keyboard and screens and made boss pestering instant by email and message streams. Same shit, new wrapping.

Outside the corporate world, in places with fewer habits and assumed truths, IT has shown way more promise: we can communicate and collaborate with people all over the world in a gazillion ways, we have the "cloud", we have tablets and smartphones, we have all kinds of technological power. But in the corporate world we still run workflows using doughnuts and stern looks. That's silly. And amazingly ineffective.

What to do?

Be inspired by Rufer, Spolsky and Jobs, but for the alternative framework (Rufer's seems rather cumbersome if you study it) make a request to your enterprise software vendor as follows:

He should change focus from efficiency to effectiveness, from "how we do things" to "what things we do", from "making the old way faster" to "replace the old way".
He should without delay create systems that can framework and run workflows even of the Barely Repeatable kind.
Note that it's about "flows", i.e. processes, so tell them not to come dragging with some process-less collaboration solution or social-whatever that they lifted from the consumer market, that won't wash.

With eventually an alternative workflow framework in place, like a riverbed for water flow, it would be time to burn those "manager" hats and let the ex-managers focus on real value-add and proper leadership.

[Disclosure: The author is in fact engaged in creating such an alternative work framework]

Where's Waldo?

2011-12-07T11:29:02+01:00

Go back to your student days and try to remember your best textbooks...

They always started out with the basics, then went deeper and deeper. Each chapter led you stepwise through a concept, using examples, painting a picture then rounding off with some exercises before moving on to the next chapter.

They were not half bad those books, a well written one could keep us on the edge of the seat, making us wanting answers to the "why?" then triggering the occasional "aha!".

The best ones had a story, even if it was a text book on physics, and we were story dwelling in conflicts where logical solutions slowly emerged. In truth they delivered true process, a series of steps with a goal, and for the best textbooks, in such a way that we got truly involved.

This is how good enterprise software should function, storyline, series of natural steps, process, just like the rest of our lives - but alas the underlying structure seeps through, and that architecture and structure is not process based, it's a dynamic database handling at best. So the well proven and effective process oriented textbook template can not be used.

But luckily, enterprise software architects had Waldo!

No process, no natural building of a story, no alternative paths, all in one interface. Perfect. Now they could focus on the itsy-bitsy details instead; colour schemes, rounded corners and placement of navigation bars. Thank heavens for Waldo.

Here's the template:

All rights: Classic Media Distribution Ltd

And here's one result:

All rights: Guess who...

And with that I rest my UI case for now.

Say goodbye to the organisational hierarchies please

2011-10-25T15:05:41+02:00

It all started by John Tropea's post, then the discussion moved onto Google+.

My first comment was "I'm still puzzled why all still accepts "organisational hierarchies" as a given... after all they're nothing but frameworks for work processes, of the push kind mostly, based on technology like quills, whips and shoe leather."

As always, succinctly described by Hugh at Gapingvoid!

Not having organisational hierarchies is almost unthinkable, so in the comments the premise for the question had to be backed up by a little fictional story:

Say you and five friends start a new company, let's pretend an advertising company. All of you know your stuff, albeit with slightly different focus, interest, abilities and experience. On day one you all sit in one room and the telephone rings, a customer. Luis sitting next to it picks it up and does a damned good job at it, landing your first customer. This was noticed with much satisfaction by all of you so next time it rings all call out "Luis, call for you!" and soon Luis is the designated sales/customer-handing person.

By way of interest Keith starts doodling with some art ideas, while you have some channel ideas spurring you to pick up the phone calling some friends to bounce off your ideas. And so forth. Group dynamics at it's best, and soon your little firm have natural leaders for each type of activity, the next arts chap gets his desk next to Keith. But nobody bothers about titles until you're asked for it by some corporate customer going "ehh, yes, Keith is our arts director" while giving Keith a glance to see if that sound ok :)

The work flow in that example is all manual, but with extremely low overhead thanks to all sitting in the same room, hearing all, seeing all and communicating via looks and head nodding or the occasional group discussion without leaving your desk. Not a report in sight, you all know what's going on after all.

But soon you guys are 120 people and no single room can hold you anymore, offices are rented and walls are cropping up - so now you turn to the classic solution to make the work flows flow - you establish management positions, who will have morning meetings and gather in reports which are distilled into new reports for the management group who spend three hours meetings at regular intervals to inform each other and set new goals. To make all that more efficient you invest in collaboration tools and budget tools and the half-hour slots in google calendar now becomes the guide for your day and scheduling-conflict-time-waster ("sorry, cannot on Tuesday, what about Monday week after?"). And Keith's almost 100% focus on creating great art soon falls to say 40% of the time, rest is spent on "managing" and meetings and reporting. (The 40% BTW is supported by research, we do spend between 55 and 75% of our time on moving the flow forward in similar situations.)

This is when the work to make the work flow becomes costly - Keith is value-creation-wise only 40% of the man he used to be (sorry Keith ;)) Luis having to handle all the interest have a few chaps and chapettes helping him so soon he's also a "40% man" (sorry Luis). And not to talk about the new hires that have to sit in at those meetings and write those reports - so you end up hiring people and paying them 100% for only 40% value-creation time!

If IT architects were abundantly clear that the sole purpose of the organisational hierarchies, the meetings, the calendars, the reports and budgets were nothing but a process framework (make flows flow) - then they would have shifted their focus away from making those manual work flow mechanisms more efficient to focus on actually making the whole more effective by making the flows flow (and flow is process, Barely Repeatable or not, so a process engine must be the core of such solutions). In short, allow the 120 person group in the story to operate as if they were in the same room where no org hierarchy was needed (except to please old school corporate types who need it to navigate) and no reports were required as all could see what was going on in real time.

This focus on efficiency over effectiveness should remind us of what Peter Drucker once said: “There is nothing so useless as doing efficiently that which should not be done at all.” And today, thanks to modern IT we do things very efficiently, especially the 60% that which need not to be done at all.

If all of that 60% non-value-creation could be done away with by a new kind of work flow engine your new advertising company could triple it's output, and not to talk about the pleasure of not having to be pestered by bosses, pester subordinates, sit at long meetings, write reports, or struggle with budgets that we all know is less real than anything coming out of the Walt Disney studios!

As an end note I'll just mention, even if plugging one's own products is frowned upon; this is what we at thingamy actually is doing - automating the flow work.

Gamification, dashboards, search and enterprise failure

2011-09-27T13:43:57+02:00

Ooh, I love a good disagreemnt, and when my friend JP Rangaswami who's views I respect highly, writes a post that I heartily disagrees with I'm tickled pink!

It was his views on Gamification and Dashboards in the enterprise that made me hit the keyboard, because:

I see gamification, dashboards and search as signs of enterprise failure!

There I said it, humbly.

They all signify a lack of process frameworks that can run the processes. And just to clarify, industrial processes are not the only processes, all we do is a process as in "steps of activities with a goal", and that should cover all that we do in organisations, in business, in enterprises. And for a process to happen, for flows to flow, one needs a framework, structured, flexible or manual. Just like water requires a riverbed or a pipeline. But if the framework is manual (bucket passing anyone? Monday morning meetings, budgets and reporting anyone?) then the creative value-creation work will suffer.

[Note: I do absolutely agree with JP that knowledge work and it's BRPs (Barely Repeatable Processes) are way more important than the industrial ERPs (Easily Repeatable processes), twice the importance I'd argue. But still most process software is built for the ERPs and not the BRPs - and that has to change!]

Gamification:

Don't misread me, I'm all for games, it's a core human activity and all positive - but it has two kind of rewards: Extrinsic and intrinsic, and...

Intrinsic works, extrinsic does not work (except for the first instance or two, or for simple menial labour) - and all I read about gamification is about extrinsic rewards, badges and whatnot.

The classic intrinsic rewards are "mastery, purpose and autonomy". Basic, always worked, hugely powerful. But these three intrinsic rewards requires a flow- or process framework that can run the processes in the background, otherwise most of the effort will go into making the flow flow, non-value creation, and that kills all three with a vengeance.

And therein lies the issue, if there is no "automatic" process framework - and there is only manual frameworks for knowledge work today; meetings, hierarchies, budgets, reports - then the intrinsic rewards are hard to attain if at all.

Hence the claim that the need for extrinsic rewards as per most "gamification" efforts being a clear sign of no proper process framework, and hence of enterprise failure.

(Image from Wikipedia)

Dashboard:

If a process is manually framed you will need access to all available activities all the time as the system does not know "where you are" and "what you need" just now. A dashboard is simply the practical solution to this "allness at all times" so you have a spitting chance to find your way. I dare you to count number of clickable links in a typical enterprise system dashboard!

So again, a dashboard only shows that it's all manual and time and effort is wasted on making the flow flow. A proper process based system would have one button for the task at hand, and perhaps a few for reports/views and no need for a sorting desk, aka dashboard. A clear sign of lack of process framework and hence enterprise failure.

Search:

Until 1913 cars were manufactured in workshops and the workers had to go find tools and rummage for parts. Today's office worker does the same, but now it's about searching for documents and information. Task context has to be created manually!

A proper process based system, or process framework would know what your task is and thus know what information to deliver you at the same time so search would be superfluous (not all the time of course, but mostly).

So when I see search then I see a lack of proper process framework again.

Interesting thing that assembly line, within a year value-creation per worker (i.e. putting a car together) increased 7.8 times - and that without automating or changing any of the actual car assembly activities (same parts, same tools, same movements), only by frameworking and automating the work spent on making the flow move forward.

Yes it was a highly linear, utterly predictable process - an Easily Repeatable Process (ERP), and no you cannot use that same process engine for the unpredictable, Barely Repeatable Process (BRP) most of us live in - for that new and different solutions are required.

With that we would see less search, a prepared environment for intrinsic rewards and no dashboards at all.

Evidence vs. belief and enterprise software

2011-09-06T14:50:31+02:00

Just recently "evidence vs belief based management" has been raised again, and that's good, it should be in the forefront at all times if you ask me.

The whole thing seems utterly unbelievable, the indisputable fact [sic] that hugely important decisions, decisions that impacts us all as employees, customers and shareholders are often made based on beliefs and not on facts and evidence. Heck man, believe what you want, but when you run companies leave your beliefs at the door, it's my pension money you're squandering!

New York Times had a great article on evidence based management reminding me yet again of the importance of Jeffrey Pfeffer and Robert Sutton's excellent book “Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management".

Andrew McAfee piped in with a well-written piece here: How "intuition" has moved application from the instant to the slow, how the success of intuition practiced by people with years of hand on experience in situations awash in signals has been promoted to something the half-experts can use in signal-low slow situations. And how wrong that is.

I've seen it all through my business life, and probably been an offender myself.

But now as an "enterprise software vendor" I'm again hitting the same wall. And, from this new angle so to speak, it's plainly annoying.

"Best practices" is one of the building bricks of that wall. Add "proven" and "intuitive" and the wall requires nothing less than a case of dynamite to tear down.

[If you haven't read some of my other posts "best practices" means "copy the others so we can avoid being different and have a strategy" and "intuitive" means "that's how we always did it". Innovation good-bye stuff.]

Young ESW entrepreneur climbing the wall.

Of course Sun Tzu would suggest walk around the wall, but alas the "buyers" are manning the walls and nowhere to be seen at the other side.

No customer facing company today is better than their systems; just think back on your own experience with different banks or telecom suppliers - all have nice friendly people manning the phone banks, but some tend to answer "sorry Sir, but our system does not allow that". I'd suggest that the facts are plentiful.

So the first question is: Are the IT buyers under some rules that obliges them to stick to the known? Of course they are, no leeway whatsoever to take any risk, their performance is measured by the ability to maintain status quo and not on risky innovation. IT departments has taken over from janitor departments; "keep it all clean and unobtrusive".

The second question is: Are those who sets strategy at all aware of the importance of IT? Again the answer is given; not at all. The prevailing belief is that IT is a tool for efficiency gains and the fact that IT is the framework for more effective use of resources and better products and services is not recognised.

So there we are, in dire need of moving IT responsibility back to where strategy is set, way behind the wall. That would leave the walls to crumble and open for some serious business development again.

And I for one would welcome it. And those who does it will win.

Strategic software vs non-strategic software

2011-08-02T15:29:03+02:00

I can just as well be upfront about it and invite ridicule at once: There is no business / enterprise software that is first and foremost built to enable strategies, and thus could be termed "strategic".

Let's look at some characteristics that could help to discern the difference between non-strategic business software and potentially strategic business software:

Non-strategic:

First vendor question: "What is your problem, how can we help you?"

Focus on "how you do things", i.e. on efficiency, bettering the status quo.

Product names almost always includes the term "manage": Control, preside over, govern, rule, command, oversee, administer, organize, conduct, handle. Again no new ways, there is no effectiveness in the term manage, it's all about more control of the "how" we did what we did yesterday, and the day before - tweak the status quo but never challenge it.

A second strain of non-strategic software uses the moniker "productivity". Pure efficiency again, all well and good to do things faster, but there's not a whiff of flexibility in regards of the strategic "what you do".

Strategic:

First vendor question: "What is your strategy?" or "what are you doing and why?" as in “what value are you to deliver, to what customer, and how are you to be different?”.

Focus is on "what you do", i.e. on effectiveness and what can be done differently.

Product names? Hard to say as there are none out there, but I would venture that it would include process, run, operate - and hopefully no "management".

So when was the last time you met with a software vendor or a system integrator where the first question was "what's your strategy?" and not "what's your problem?"?

When was the last time you saw a business/enterprise software product sheet that talked about effectiveness of your whole company, not mentioning efficiency with one word?

I bet you, never.

SMS - Sheep Management System

In other words, all current business/enterprise software is non-strategic in the real sense. And that's nuts, surprising, ultimately destructive, and abundantly obvious - not the Black Swan but a Neon Swan swimming in front of us.

Why is it like this? Here's a possible explanation:

If your employees are disgruntled and demotivated the classic reaction is to add more positives to hopefully outweigh the negatives - more bonus, better food in the cafeteria, more "fun". Few will seek the root cause and remove that, "how" is more important than "what". If your product sales are low, first reaction is to lower the price and throw in a free cap, more positives added. Making a better product, challenging the "what we do" is not as easy as the "how we do things", like being more efficient so we can lower the price.

This has it's natural causes - finding the root cause for dissatisfaction might not be a nice thing to face, or even risk having to face - bad management, no-good strategy, that kind of awkward "truths". Any decision maker would shudder at the thought. So more fun, more food, lower price, bonus, more of anything nice is the way out. And creating a better product or service ain't done overnight, so grab those levers in sight and throw more money at marketing is the easy way out, you're after all the product manager, the manager of the current product.

Business / enterprise software sells to managers, don't ruffle feathers is the obvious choice. So business software is all into the "how", never into the "what". It offers more efficiency but not better products, more control of the status quo, but no new ways to do things.

This is why I think that most if not all current business software fails big time in it's ultimate purpose of making business better. And why a new kind of business software is needed - a strategic kind of software where "what you do" is way more important than "how you do things". Software where each vendor offer should start out by challenging the client's strategies, software where each component is designed for a single purpose; to enable a good strategy.

Stifling growth? Challenge some assumptions!

2011-05-24T15:49:31+02:00

McKinsey Quarterly has an article in their May edition - "Preparing your organization for growth" - that yet again reminds me about the total inability to ask the right question. Or question any assumptions at all.

If you live in a small apartment with one bedroom and your wife becomes pregnant with triplets, what will you do? Will you assume that the apartment is where you will have to live forever and set up a wall in the bedroom to make two bedrooms, or four? Or would you ask yourself "maybe we should look for a bigger apartment?".

If you're in a hurry do you assume that bus is the only means of transportation, jump on it, then proceed to pester the driver to drive faster, or do you take the car?

Management "experts" would partition the bedroom into four and pester the driver.

Their first question should have been: What is the organisational structure for?

It has only one single purpose: Be a framework for workflows. Basically a conduit for information, it be tasks, reports or whatever other information you need to create value in an effective manner.

So why are nobody asking the obvious question? Are there alternatives to the workflow framework? Are there other ways of distributing tasks and information?

I assume it's a bit how we face death; we do not know of any alternative (OK, some religions purport to have a solution long term) so we do not wake up in the morning thinking "ouch, I will die one day, must do something about it".

But the way of running a business is less immutable than a certain death, so why on earth not give it a thought at least? After all, unless somebody challenges the "truth" that organisational structures is the only alternative to make workflows happen effectively, well then, nobody will spend a second on finding an alternative! A self-fulfilling prophecy if there ever was one!

But Hugh knows what might be the problem!

[Disclosure: This is exactly what we at Thingamy are working on, a framework for Barely Repeatable Processes, typical workflows in other words. And yes, strictly speaking, an organisation structure is not needed, the participants can self-organise nicely with the right underlying tool.]

Enterprise software's wrong focus

2011-05-12T15:52:21+02:00

Let me start by refining my earlier "who's you customer" post:

Primary customer/user: This is where your value delivered is appreciated. It's the daily users and the real reason why you have a business at all. But alas, they often do not want to pay, still this is where your focus must be!

Social media: Everybody. Value is simple and easy to understand and consume and the vendors understands this. But the user shows little or no willingness to pay!

Enterprise software: The employees who shall use the software to actually enable them to do their job every day. Even less willingness to pay!

Secondary customer/user: These are interested thanks to the presence and use by the primary group. They are not users in the same sense and their value is mostly totally different. But they are willing to pay as the primary group gets value from the product that trickles directly to this group.

Social media: Advertisers, Games vendors and services like employment agencies and HR departments. Their needs are overview and statistics, delivery and payment mechanisms, and overview and simple connection processes.

Enterprise software: Management with their needs for overview and 'control'.

ESW started out with products only of interest to the secondary customer - ERP, back-office systems, accounting - while the primary group saw no change to his daily work except that numbers entry moved from paper to electronic format. The processes and activities remained the same.

From that ESW vendors built a sales channel, a marketing regime and brand building always geared towards the secondary customer. Which directed the product development as well where every new feature, every new development program had only one focus - to please the secondary customer even more.

User rejected product.

Then something changed: Software became a tool to make cognitive work more efficient and the importance of the primary group increased fast to become more important value-delivery-wise than all that commodity back end stuff nobody but the secondary group sees.

Now, go visit the web sites of large ESW vendors and read with the eyes of a daily user, a mere employee - what do you see? Does the words speak to you? Does "Develop a roadmap to the cloud" or "Best businesses run SAP" or "Oracle is the leader in application servers" speak to you? Does that fire you up giving you a warm and fuzzy feeling that those guys can make your daily life better?

On the other hand a new breed of software vendors emerged; social media and many new and modern vendors understands the issue so they're focused on the primary user, i.e. you. Not much of "Next-generation HR software in the cloud" at Linkedin or "See our roadmap for cloud servers for social interaction" at Facebook.

How successful do you think Google would be if their products first and foremost were built for the advertisers and their needs to punch on users and control the ad stream?

Most of the users of these new products are also employees, so they started to bring some of these new systems and ways to use them to the job. And now the management have been observing this, comparing the willingness to adopt to the reluctance that classic ESW meets, concluding that something must be good about some of that. And a flurry of social media in the business marketplace followed.

In other words, the primary and secondary customer groups at corporations now acts like the same groups in the consumer space.

But that fact has yet to trickle down to the large ESW vendors. Just check out their web sites again if you're not convinced!

There is one sign though that they're not totally blind; lip service ensued with much talk of user-friendly interfaces. But that's spray-painting the old banger at best.

In short, classic software vendors develop software for and speak to the wrong user group.

[EMBARRASSING DISCLOSURE: When writing this I checked out our own site, and lo and behold, had been walking straight into same trap... ehem. Fixed :)]

Software and the Complexity Excuse

2011-04-26T15:39:18+02:00

I am a bit fed up with the (mis)use of the term 'complex' as an excuse for not doing the right thing.

Especially in Enterprise Software: Costs, implementation times and unwillingness to make me something bespoke - "it's because enterprise is so complex".

Bollocks to that I say. Stop saying that, it's not smart.

Nothing is complex, we only think it's complex:

We human beings cannot experience the world directly, we can only grasp it through “abstractions”.

To understand reality, to grasp, we need to have a model in our heads or on our computers.

When we perceive complexity we cannot know if reality is complex, the only thing we know for sure is that the current model of understanding that reality is complex.

Then add the fact, like in science, that every model is wrong, they simply work for now while waiting to be disproven, then replaced by a better one.

The models used to understand and model enterprise have not changed much over thousands of years. If that had a parallel in science, not even Galileo's reality models would have had an impact. Not to talk about Newton's, Einstein's, Bohr's...

And by the way, the most ancient of those, Galileo's reality models, is even younger than double-entry book keeping, the most modern part of the enterprise model!

In science the earth is no more the center of the universe, in enterprise software double-entry book keeping is. Just ask any ERP developer.

Complexity arises when the model does not fit any more. All of the above scientists replaced some former model and hence simplified things.

If only enterprise and software folks could be more like scientists and wake up every morning wondering what new model they could try out instead of giving up even before hitting the coffee by uttering "it's so complex"!

Says Hugh, and he's spot on.

So next time you hear an Enterprise Software vendor say "ah yes, it's so complex" when defending high prices, long implementation times, delays and regrets that nothing can be changed - you shall simply call them on that and state: "Then you're using the wrong model!".

Social Media - Nouns but no Verbs

2011-04-06T15:00:00+02:00

Practical use of Information Technology seems to follow the same maturity trajectory as languages. But being a young phenomena IT still has a way to go: It has the words in place, i.e. the data model is often precise enough, each object has a meaning, but combining the pieces into precise meaning and context where time and activities (verbs) are as important as objects (nouns) is still lacking. The grammar is not there.

Social Media are perfect examples: They're basically dynamic information containers with a wide funnel and some mechanisms to sort, look at the data objects, then redistribute the objects with a smart comment.

But what does information often lead to? What's the most interesting part of information? What is the most valuable aspect?

Action.

When on Facebook, Twitter, Linkedin or in some internal work-limited message stream you stumble over requests, you discover issues or you "get" ideas. Then there's a need to act.

But Social Media is not built for that. They have no actionable mechanism, no verbs to make sense of the nouns, no embedded nor suitable process engine for the unpredictable that can snap up the discovery then run the request/idea/issue objects through a proper sequence of activities towards a solution. You have to take the discovery off-system and into email, word processors, some other manual collaboration tool, or use Social Media as a message pipe. In short Social Media have nouns but no verbs, and hence no grammar. And please do not claim that email or collaboration tools are any better, it's all manual pick up and move around action there too.

The lacking ingredient

Social Media's business focus reflects this; they merely sell the information in the form of advertising, job search, or "addresses" for game vendors. In reality, and despite out-of-this-world valuations, Social Media leave their biggest value delivery unused on the table.

If Social Media had an actionable mechanism, a Barely Repeatable Process engine embedded which could make direct and practical use of the inevitable discoveries we make there, then I'd imagine we'd detect some nervousness in the Enterprise Software world.

Gamification?

2011-03-23T17:16:48+01:00

One recent buzzword that I hear a lot is "gamification". Especially gamification of utterly boring Enterprise Software and consumer experiences in commercial transactions. A heroic attempt to solve one of life's mysteries; why work sometimes drifts towards boring and in particular why ESW tend to be so unimaginative.

On the surface it looks like nothing but a positive thing to do, who can protest the use of words like "game" or "fun"? It might even throw a dyed-in-the-wool sceptic like myself off the scent, a scent of potentially fallacious assumptions. But heretics have warning bells ringing when something sounds that good.

What triggers my scepticism is the "verbification" of the noun indicating that you take something existing, without challenging the assumptions nor changing the underlying, then simply... eh... gamify it. If the underlying part is not good enough, adding, combining or tweaking really seldom works well, history is full of examples from clunky flying cars to walking machines with wheels (Segway anyone?).

I even get this image of the Louis XV court at Versailles - infrequent bathing and worse, all doused by perfume in a feeble effort to cover the lack of some basic concepts. Sorry for that image, could not resist.

The purpose of "Gamification" seems to be to cover up some manual and tedious process in an effort to make it more "fun" (that word makes me double suspicious). I see it being applied as a fix-all in business settings for one single purpose; get the user to use what he's supposed to use without having to flog him. A classic manager and now IT vendor quandary.

But what about checking the original assumptions and see if not the tedious and manual part could be removed instead of being hidden under a new "fun" layer? Try the soap before the perfume so to speak?

The better solution

Games could give an answer, no doubt, but the question is; what to learn from games, what works and what is the core? Then apply the core learning to Enterprise Software instead of adding a flimsy layer on top.

Disregarding puzzle games for a moment; games are often about a narrative, a story, with characters to know and conflicts that shall be solved, and it must allow decisions and meaningful choices, still with uncertain outcomes that spurs reactions and results moving the story forward another notch in unexpected directions. Note the word "direction" there.

In short, story dwelling instead of story telling; play the game, live the life, immerse oneself in a sequence of partly self directed activities with a meaning (aka process, or indeed work).

Sounds like simulation does it not? Sounds like a real work process stripped of the boring stuff does it not? And indeed it is, both.

But simulation of real life processes, which equals an opportunity to run those, requires a "process engine" that can deliver any sequence of activities and punt back the resulting reactive activities. Manual wiki'ish dashboardy, send-mail-from-Word, or browse and select from long to-do lists does not cut it. Look instead to any multiplayer game on the net and that is precisely what you find at the back end; a pure process engine.

That's what most Enterprise Software for Barely Repeatable Processes lacks, they're mostly manual, no underlying process engine, no instantness. Rebuild the BRP ESW on top of a real process engine, take away that tedious, boring and repetitive manual flow-work, automate the flow-work and let the user focus on what's happening, what to do now at this precise moment, manipulate the process in the quest for solved issues and done work, in short focus on the work story.

That would create real world stories, that would be living the life story, that would be the most effective work modus, and that would be the ultimate game.

On Productivity

2011-03-01T14:04:58+01:00

"Productive effort, measured in terms of the rate of output per unit of input"

And I bet you that the next word that is popping up in your head now is efficiency: "Achieving maximum productivity with minimum wasted effort or expense"

All well and good and what managers are focused on every day at the office. And of course what Enterprise Software is all about; faster, better, more.

But hang on a second, so far we have talked about "how we do things", so far not much about "what we do".

Which of course would be highly interesting for the profits and the long term wellbeing of any project or company. In fact, that's the only place where growth comes from. When did you last find any volume growth in efficiency increases?

Eight chaps engaging in effective water transport instead of rowing efficiently in eight different boats.

Where did the pursuit of effectiveness go? Who's focused on "what we do" and the effectiveness of the whole organisation and business endeavour? Of course the founders when they started, that goes without saying, then the board every now and then under the umbrella of "strategy".

But should it not be a daily focus for all I wonder...

After all effectiveness always beats efficiency. Efficiency is all about running faster from A to B, while finding out if going to B is a waste of time and that walking directly to C makes better overall sense is about effectiveness.
In reality efforts to increase effectiveness should precede efforts to increase efficiency every day. That's logical.

The problem is threefold I think:

Efficiency is like the daily shower, results are instantly measurable, the feeling is warm and fuzzy. Hence something that becomes an easy habit, enticing management to choose this above addressing effectiveness issues with way harder to measure results.
Efficiency is on the micro level; anybody can do something with it, while effectiveness involves many.
IT is all focused, and indeed created, to increase efficiency, not at all built for changes to "what we do". On the contrary, effectiveness enhancements often means changes to, or even replacement, of IT systems.

Add that efficiency has a smaller and smaller incremental potential over time, the curve simply flattens out. While effectiveness is a never ending pursuit with definitely no smooth curve, it produces leaps and bounds in profits and overall success.

I think it's time to put the pursuit of efficiency where it belongs, behind the effectiveness pursuit. Both becoming daily pursuits.

Now only to find the IT that suits that approach!

[Guess you know me so you don't need much of a hint...]

Social Business and the Command & Control Excuse

2011-02-08T10:27:33+01:00

A few days ago I had the usual pleasure of reading one of Euan's posts, where there was one paragraph that triggered something in my mind:

"On the same day I get an email from a senior official in a government job saying "I'm beginning to think that the inherently democratic nature of social media tools is the very reason why they are being restricted or marginalised in some organisations. After all, the traditional notion of command and control is still very much alive in the dark heart of many business places - symptomatic of a deeply entrenched need for power....?"

When Social Business meets feet-dragging old school hierarchical organisations it's quite natural to raise the obvious "but Social Business does make sense, so why not embrace it?". And what is a more natural explanation than "it's the hang to command & control".

On first glance I do "buy the argument" but then...

...I think it's something entirely different.

Think "accountability". Say you've been given a task, accepted it, and now you will have to answer to somebody or somebodies, or even the whole firm. But then you need help, from your peers or your subordinates:

Now you're facing the obvious need to transfer accountability for that specific task to an assignee, otherwise you'd be out on a limb. Sure, if you're in a good old hierarchy and have subordinates that's doable by decree and the "enforcement" is easy come next bonus meet.

But if you need help from peers, or even a superior, maybe even from some other department, how easy is it then to nail accountability on that assignee? How would the organisation enforce that?

It cannot. That would be against the hierarchy's very design so you're basically stuck with subordinates for help, or do it all yourself.

Transfer of accountability must be visible and recordable, but that's not enough, an orderly transfer of all what the assignee needs to do the job properly (anything else is unfair and ineffective) is crucial. You cannot just say "do this" then leave, you need to transfer all pertinent information, the full context, before even an acceptance can be had.

Proper handover!

In other words, transfer of accountability, handing over the key for all to see as well as all information, is a sequence of activities in itself, it's proper process. And that process must be embedded in the framework to ensure proper recording and the full transfer of accountability.

And here comes the Social Business "situation" in: As there is no clear distribution, no process engine nor framework to handle such, including the transfer of all pertinent information and context, the situation becomes all too similar to nailing your boss's boss to be accountable for a task you have tried to give him when passing him in the hallway. If it works, you're in luck, but hardly a mechanism to build effective businesses on.

Social Business would indeed be able to open up the hierarchy so "resources" can be more effectively used disregarding organisational silos and walls. But it does not address the accountability transfer issue, instead it lazily blames the lack of enthusiasm on some notion of "need for command & control".

I think the reluctance to adopt is healthy, nobody wants to be accountable while soliciting help does not allow proper transfer of accountability. That's like being responsible for what some strangers are doing on the street outside your house. Do not expect that to happen.

Work is Communication

2011-01-27T13:48:43+01:00

Work relies on, no, consists of two things:

brains and hands
communication

Brains and hands: The appropriate and best-possible ability must be available, that's a good start.

But what can brains and hands do unless they know what to do? Unless they have the full context, the full overview so they're at least given a spitting chance to use their groomed brains? That is what communication is all about.

Communication is about finding the right brain and hands for the task at hand, then disseminate the information accordingly: Precise tasks, all pertinent information, not less and not more, and full context so we understand the whys as well as the whats. Then what is undertaken, context, must be captured in full so there is no doubt as to who did what and what the work was based on, what the results were, and above all that accountability was assigned and accepted - reverse information dissemination. Without all of that the brains and hands are useless.

Yes the two are interdependent, but arguably the latter, communication, would have an even bigger impact on the effectiveness of the organisation than refining the brains and hands another notch.

That's the reality.

What does the map look like?

All focus is on brains and hands - large HR departments, extensive vetting processes, constant evaluation, mentoring, training, coaching, all important of course.

But where's the Communication Department? IT help desk supporting setting up Outlook? Often that's it.

We talk about HR strategy, we have HR Directors sitting on boards - all fine and good, but where is the Communication strategy? Ah, yes, then we immediately think "marketing", how we "communicate" our product "story" to the customer but never how we enable the stakeholders to effectively do their thing in best possible ways.

In fact, if it weren't for "organisational culture", aka "this is how we usually do things" communication would not work at all in most organisations. As communication architecture that's about as solid as two empty cans with a string between them.

Yes there is something brewing; "social platforms/tools" are trying to address this glaring omission.

But "social platforms/tools" as widely understood will not be enough: They have no process base so they cannot disseminate information correctly, it will be all or nothing, they are not able to automatically capture context and new information hence not able to produce reports on the fly. Their data architecture is built on old technologies like pen and paper, but worst of all, lacking a process base the crucial element of accountability will not be present: Who was given (or took) what task at what time, and what did he/she know at the time, and how did he/she proceed to what conclusion at what time? And who's doing what now, and who's not doing the what they were supposed to do at this very moment?

By the way, in extremis, search can be seen as a sign of communication failure: If there was process in place the process would know exactly what you need, then deliver it with the task.

The "social platforms/tools" efforts are commendable, and the issue addressed is the right one, but the deluge of free information will never do what focused "process" can do for work.

If you're thirsty you put your glass under the faucet, you would not stand under the shower glass in hand.

Get rid of the Calendar, and the Watch too

2011-01-04T16:20:45+01:00

Those are leftovers from the industrial age and the biggest impediment to an effective society.

Before I hear the protest I can just as well agree that sometimes it's needed; like when I'm to meet somebody for a spot of lunch, or when an airplane or train operating company wants to ferry me and 120 other people at the same time, in the same contraption from A to B. Then exact time, and location, is useful.

But for me to work, for me to do my best? Mondays better than Sundays? Why on earth that? What if it rains on a Sunday so I cannot cycle while Monday is sunny and balm? Why not leave that to me?
What about that utterly stupid notion of a "deadline"? What happens when you give somebody two weeks to deliver? What would you do? First week you'd go "I've got plenty of time", second week, "better get started" until you go "shoot, have to do that job". Ever seen a task being delivered in one day instead of the two weeks you gave the assignee? No, that would have been an insult to your ability to estimate the time that a task would take!

And come to think of it, your focus will always be your, eh, focus. Would it not be more sensible to focus on the undone task at hand instead of the future (hopefully) done task? When I participate in a race I go when they shout "go", never linger even if I think I have all the time in the world. When cycling fast downhill the practical truth is that "you go where you look".

You can even translate the "scheduling monster" into company losses; I think you'll recognise what Jeffrey Phillips describes:

"Another tyranny of the calendar is simply attempting to schedule meetings and events with an innovation team. Most innovation teams include many people who have “day jobs” and the attempts to schedule time to discuss trends, or generate ideas, or interact with customer panels is almost impossible. Everyone in business today is overscheduled, and every item on the calendar seems of dire importance. I had a client recently tell us that the innovation project we were working on was of the utmost importance, yet we couldn’t schedule a meeting of the innovation team for almost six weeks due to scheduling conflicts. What’s more important, innovation or the calendar?"

I've noticed that the bigger the corporation is, or the more a manager tries to "look busy", the harder it is to set a meeting. Invites goes out, scheduling conflicts punted back and forth and at last a WebEx invite appears in my Google calendar. And that for an online meet! Heck, I'm next to my computer all the time, why don't you ping me and see if I have a half hour? I almost always have, and if not I simply go "sorry busy on another call, I'll ping to see if you're in when I'm off the call".

Classic industrial age profit killer.

I once built a working workflow for a advertising agency, starting off with the current processes from customer request to start of an advertising campaign: As they were it all pivoted around four "big meetings" where one of the "owners" had to be present, effectively throttling all activity to a grinding halt before it fanned out again to the "creatives".

Now my workflow, using a work processor delivering tasks and information and capturing all ongoing, made everything visible so there would not be any need for such meetings. Everybody would be able to see what was going on, and even jump in, in real time. No need to get together to "see" the progress and assign new tasks ("action items" anyone?) as that particular work processor did that nicely indeed, entirely without communal doughnut consumption.

With an average seven weeks from start to end for their projects, where I assumed half a week average delay from instant for each meeting due to "sorry, I'm busy on Thursday"s (that I would argue was very optimistic), we could cut the time from seven to five weeks per project, on average, without losing anything but thumb twiddling. With a 20% profit margin today it would translate to a tripling of their profits.

Did they go for this no-brainer? Nope, the two owners would not hear of it, their controlling habits and methods where not to be touched, and bah humbug to tripling of profits. Ah well, their prerogative, they did not have outside investors. Maybe I should have had a chat with their spouses over lunch at Harrods?

Status quo is always "warm and fuzzy", but the race might very well be on, and they might find that not coming first out of the gate actually will have practical ramifications.

This, by the way, is what "Business modelling" is all about; "how to use resources to deliver the value and keep as much of that value as possible" - and for most, the most important resource by far is time! Start the pivot by rethinking the calendar and the Watch, old industrial age things they are.

[UPDATE: A month after this post I sold my watch (the only one I had, and yes, same as pictured above). Good thing that I'm early getting rid of the watch, I got way more for it than what I paid for it!]

Strategy, Business Model, and Who's Your Customer

2010-12-14T18:44:02+01:00

As a vendor or SI you can approach the delivery of enterprise software in two ways:

The good old and safe way; accept the premises, scope their processes and ways, then deliver something that makes the existing more efficient.
Do not accept the premises, revisit their strategy and (re)model their business, then supply Software as a Business Model (SaaBM of course) that can deliver on that strategy in an effective way.

I choose the latter. Hence my interest in Strategy and Business Models:

Any business (or even activity) requires clarification of three issues, in this sequence, everything else follows:

Strategy
Business Model
Business Plan

Strategy (based on Michael Porter’s work) is the answer to the following three questions:

What value are you to deliver,
to what customer, and
how are you going to be different?

Who has a need?
What is the need?
Does she see the need?
How can you visualise the need by offering a solution?

A homogenous group with a common interest.

Sounds simple? But alas, it's not:

The “who” and the “need” are closely knit, and in most cases quite confusing as your "customer" is not singular, almost never: You have users that you'll need but that do not want to pay, users that want to pay but that will not even use your product, users that want to pay and are heavy users of your product, users that all need and that might even be willing to pay, or users that nobody wants but who want to pay. As I said, highly confusing.

Having tinkered with this a lot, I've found that the "customer" most often can be split into three tiers or groups:

Primary customer/user: The ones that finds a real and tangible value in your product and who are willing to pay for that. In some cases they will be actual users of the product/service, but sometimes they will not even use the system or be very light users, an indirect value delivery situation. These are the users that you will have to "sell" to, but not necessarily those you will create the system or service features and solutions for.

Social platforms: The power users, the ones that can translate the available volume and network to tangible value that is worth paying for, often a minority. Or corporations that wants a branded presence or access to the network.

In-cloud apps, enterprise systems: Company management, and sometimes power users. These might be actual users or not at all, but they have a need to ensure company wide data consistency or use, or they have a need for more features or something bespoke.

Secondary customer/user: The ones that the primary user is dependent on and who have the underlying needs that is fulfilled by your product, courtesy of the primary customer. Typically they take the offer for granted; free use of some cloudy service or given systems that allows them to do their job, so no interest in paying. These are the customer you design your product or service for, these are the ones that must find it easy, useful and a pleasure to use. They are the drivers of growth pushing the value up for the primary (and tertiary) user, but they are not the direct source of income.

Social platforms: You and me and my uncle finding it easy to connect and that it enhances our every day life. The more we are the merrier the value is for ourselves and for the other "customer" groups.

In-cloud apps, enterprise software: The bulk of the users. Takes the offer for granted but are still the harshest critics and callers for features, ease of use and all that which makes your product or service. This is the customer group that will eat your cash while not wanting to pay, but still you have to love them. Make them dependent on your product and attracting the paying customer groups will be a walk in the park.

Tertiary customer/user: The third layer of users that can enhance the overall value for both above groups, and that often finds enough value in the product or service to be willing to pay as well.

Social platforms: Advertisers, service and product suppliers. Willing to pay for the use of a virtual "distribution channel", and useful for the two other customer groups. Some times these can be just annoying (see advertising) which of course might indicate that the choice of tertiary customer is wrong.

In-cloud apps, enterprise software: Service and product vendors as well as most other ecosphere members and partners. Sometimes these are a core and crucial part of the product or service value, but if the strategy is any good their use-interests would be high enough to make them paying customers - frequently in the form of using the product or service as an effective distribution channel.

So, who are your primary, secondary and tertiary customers?

Why, what value do they need, and what would they be willing to pay?

And what do they add to the overall value of your product or service?

Then find how you can be different from your competition and you have a strategy. With that you're ready to start thinking about how to use your resources to deliver on that strategy in such a way that you can keep a lot of the value yourself. That would be your Business Model and you're ready to plan and execute.

[Update May 2011: Refined the model a wee bit and used it as basis to discuss the approach of Enterprise Software vendors in the blog post "Enterprise software's wrong focus"]

"Business" is nothing but "Social Networks"

2010-11-24T16:13:35+01:00

We have a plethora of hugely successful cloud based social networks, but why only fulfil banal social needs? Those way up in the Maslow pyramid kind of needs. Why stop there?

[This was inspired By @dahowlett's post the other day so a thankful nod his way!]

Let's step back:

What happens when people mingle, in Starbucks, on a plane, in a queue? We look around, see if we see something "interesting" which often is a clue to that person sitting next to you has some common interest. A book that leads to "hey, heard about that book, is it any good?", a shiny new bike that you've been lusting for "veeeery nice, you happy with it?".

That's the mechanism of socialising with strangers, using what Hugh Mcleod and Jyri Engeström calls "Social Objects", to initiate the process. And we've been at it for a long time, man dropping his well marked Porsche keys on the bar hoping to solicit some peer strokes.

My own "social objects" always starting conversations...

The second part of the equation is the interaction part, the easier the more fluent the socialising happens. Obviously very easy if you sit next to somebody.

Social networks, the kind we now know so well, in the cloud networks, works the same way. Facebook started out having universities as the "Social Object", now extended to all kind of groups, fan-of or I-like affiliations with very easy to use interfaces all making it happen. Linkedin has business connections as the "Social Object", or purpose if you want. I would not go to Linkedin to find a cyclist keen to join a Sunday ride, for that I have other social forums.

Hence the equation, the core measure of how strong and effective a social networking offer can be:

Social network strength/growth = ("Social Object" importance) * (ease of interaction)

Starting with the importance, or strength of the "Social Object": I would venture that "doing business", "trade", "investigate and act on an opportunity", "earn money", is extremely strong, maybe the top one, after all that is a core activity driver that made humankind survive. Have to be fulfilled before any of those needs driving us to spend time on Facebook and Twitter. Basic.

Now to the "interaction" parameter. Doing business as a general activity is context dependent, who, what, where, when, and hence not predictable. The best solution is face to face, as it happens in organisations and in meetings, but that is not very effective for the society as a whole, we're after all distributed and the hiring and firing mechanisms of organisations is far from instant. But adding networking technology so far has only yielded non-process solutions, like simple auctions and wiki-like collaboration tools.

Adding "social" as a layer onto a rigid structure created pre-IT will never do it. E 2.0 or it's new name, "social business", is commendable but a blind alley, you have to focus on bettering the core mechanism instead. The core mechanism that allows and executes "a series of actions or steps taken in order to achieve a particular end by working with someone to produce or create something". (That was the definition of Process and Collaboration baked into one sentence.)

What's needed is a proper process framework where a trade, a business opportunity can be handled in a proper sequential way as it should, involving the people that can add value in a dynamic and effective manner. A core interaction engine.

But "business" is inherently unpredictable, Barely Repeatable at it's core. So no linear process tool can model it, only parts of it, and that long after the business has been established.

So yet again we see the Barely Repeatable Process (BRP), and that's what's needed for the "business" as a whole.

And it's social, people are involved. Place it in the cloud, unhampered by old school business entities and structures - just like Facebook or Twitter - a virtual "business world", an ad-hoc office, an engine of value creation. That core engine could become the most interesting kind of "social network" ever. Ah, yes, and a very effective "Business" driver as well.

A true "social network" catering for human needs far stronger than those further up the Maslow pyramid currently so well catered for.

It'll come.

Don't touch the core

2010-10-19T14:25:11+02:00

Or how SAP chooses stability over change.

Sounds smart on the surface until you start to think: Change is the only possible path to survival, stability can only be temporary, that's a law of nature.

Now back from yet another SAP Teched, again well organised and highly interesting. And I must admit, Berlin is one of my favourite cities so all's good when one is invited and costs are covered.

That was my disclosure if you find me too gushing about SAP, and my second disclosure is that I'm drifting towards becoming a head on competitor, which might be blamed if you'll find me all too negative.

So what's my wrap? I won't go into all, I'd rather stick with one single issue. An issue which is long term more important than all other combined...

As always these shindigs starts out with the keynote(s) setting the big goals and general framework for their efforts and plans. As always, and obviously, innovation is a key theme. This time summed up by three focus areas - on demand, in memory (DB), and mobility.

But that's just window dressing, behind there's a big lurking policeman; an overall guiding principle for their innovation, and his name is: "Don't touch the core, innovate on the fringes".

Touching the core...

Colour me a sceptic, but when I hear that message I immediately "read" two things:

It being stated explicitly makes me suspect that this is exactly what they think they should do; challenge the core. But that is scary, so no, don't.
That the focus is on the now, the existing, the customers want no change - all sounds sensible.

But that sense reflects only the surface. Behind lurks reality; all businesses must move forward, new business models (as in the whole business) attacks the old business models every day, and with that effectiveness of the business as a whole makes the efficiency of business operations irrelevant. And the current core is stuck in one way to do business, it has no leeway for testing out other ways, its focus is on operational efficiency.

I agree that the core should not be messed with, huge numbers of users are dependent on it, and for SAP it's a core cash flow source as well.

But it does not preclude that they should challenge it!

In fact, if they really mean not to "touch the core" it implicitly means that that they think the present core (architecture) will last forever. And that is simply illogical and cannot be.

Let some group, entity, skunkwork, be free to challenge the old core and experiment with new and very different cores and architectures. They should revisit the business situation at their customers, then proceed backwards not taking anything for given or set in stone.

It could be seen as a simple insurance premium payment. If the skunkworkers come back and say "the core will last forever", well that's good, like my house not burning down despite me having an insurance. Or it could lead to "oy, here's an alternative, lets invest in exploring that further".

Not doing this is illogical, and very dangerous in my view. Good for me as a long term competitor though as I do think their core is in for some nasty surprises.

Romans, Barbarians, and Innovation.

2010-10-06T11:57:53+02:00

Yesterday, Thomas Friedman of NYT quoted from the historian Lewis Mumford’s book, “The Condition of Man,” about the development of civilisation. Mumford was describing Rome’s decline:

“Everyone aimed at security: no one accepted responsibility. What was plainly lacking, long before the barbarian invasions had done their work, long before economic dislocations became serious, was an inner go. Rome’s life was now an imitation of life: a mere holding on. Security was the watchword — as if life knew any other stability than through constant change, or any form of security except through a constant willingness to take risks.”

It made chills going down Mr Friedman's spine, for me it was another deja vu:

Being a large corporation watcher I have no problems in finding parallels to societies as a whole, except the corporation is clearly a more structured entity which makes it into a faster moving petri dish of what can happen in the society as a whole. And vice versa.

Former glorious institution.

Change requires bravery, taking risks, every day, that is the law of nature, that is a basic human responsibility. Those who handle risks as a second nature are the one's that moves us forward. Those who avoid risk at all costs are the one's holding us back increasing the overall risk of actual demise.

Look at any large corporation and you'll find nothing but mechanisms fostering "security" and "no-change": Bonus structures based on existing products (product manager positions), quarterly results reporting and renumeration (see stock options), position focus (read career) and many more. And yes, they talk loudly about being innovative, but mostly we know what that means; "spray painting" and "fast food'ing" all low risk "innovation".

"Don't rock the boat!", "if it works, don't fix it!" - our language is full of it, sayings that supports the daily no-change choices.

Every now and then you'll find a leader who "has it" and takes the risk to achieve real change. In corporations that usually means challenging their current products and services to see if they can be reinvented or if something different should be offered. Apple comes to mind, Sony many years ago, Intel also long times ago and IBM a couple of times in their history.

But the rest, and I do meet with some of them occasionally, have lost it. So unless the inevitable barbarians at the gate are of the friendly sort, their fate might be a parallel to the Roman Empire. Actually, those "Barbarians" are mostly not barbarians at all, just from some sister city to Rome that happens to have more money so they're (read management positions) fine most of the time.

Luckily true Barbarians exists; those that do not know rules, that have no boat yet to rock, that have nothing that works that does not need fixing, that have no reward systems for no-change in place, that still see their business model as something dynamic - and they're called startups.

Creating a new business: The old way or the smart way

2010-09-21T10:34:24+02:00

@jobsworth tweeted the other day "Whenever I hear talk about business models, I am reminded of Peter Drucker's wonderful cautionary words: People make shoes, not money"

I would venture that it's because the term "Business Model" today is mostly understood as "how to get paid".

I tweeted back ""Business Model" is mostly misused, re-read it as "Model of the Business" (as in value creation activities) and voila, useful."

So from now on, please understand "Business Model" as "Model of the Business". All of the business, all of the value creation and what supports that. The whole shebang.

An excellent example on how widely understood terms hampers our thinking.

But terms are not alone in hampering, important concepts, practices and tools that we use - like double-entry book keeping and ubiquitous Enterprise Software - are even worse.

When I was a kid I had a model train set, the "Märklin" HO gauge, all nicely mounted on a huge chipboard. Of course it had houses too, all in the Alpine style befitting the painted paper maché mountains that I had built.

"Faller" was the brand that delivered the houses in HO scale. They came in little cardboard boxes and had to be assembled with glue and all.

The result was spectacular, a vista where one easily could imagine oneself a part of.

But once built not much one could do but chug along while drawing the curtains and lightening the street lights for imaginary changes from day to night.

Enjoyable as it was, innovation was not invited, unless I was willing to rip up tracks, rewire streets and shelve some houses while building some new.

Now imagine "Lego", no doubt somewhat less perfect to look at with it's inevitable angled features. But what innovation possibilities there were!

Even simple bricks can make a nice whole...
(Image thanks to Sarahindenmark and TravelPod.)

A block was a block, but it could be combined with other blocks in ways only limited by my fantasy.

Now transpose that thought onto your company, and a day of strategy talks:

The bits and pieces you have are seldom atomised, you're in the Airline business or in the Hospital business. Then you have the "best practices" ERP, SCM, HCM and whatnot systems already installed.

Differentiating yourself from your competitors, given the infrastructure and the business definition, is very limited. Branding as in colour schemes, logos and handouts seems to be an often chosen path of action. You're in a "Faller" situation.

Now think "Lego", starting with an atomised view of reality (in fact the data model of the reality that your business is in):

First look for the Core Value Delivery as objects that needs manipulation (tangible or intangible does not matter):

Long distance, fast, transport.
Cure Medical Conditions.

That would lead to other objects that you need:

Airplane, Customers, Fuel, Baggage handlers, etc.
MDs, Nurses, X-ray, Medication, Surgery, a Patient, etc.

Then you can go about combining these objects of reality representation, tangible or not does not matter.

First thing that will happen is that you'll find some assumptions already baked into some of the objects, now rip those apart for the fun of it:

Transport - who says it must be fast and long distance, same customers have other transport needs as well don't they?
Medical Conditions - why only cure if it could be prevented?

Then why "planes"? Is that the only way to transport?

And voila, a few more "Lego" blocks can be added for the strategy discussion - cars, bikes, sports, food, education, no limits really, discard later.

And now the "strategy builders" will have a field day, build and test (first totally theoretical using your calculator to look for pieces of the value creation that one could keep, aka profit).

If some of the "Lego" houses looks promising, then time to make a real life stab at it.

Now the big problem will hit you, your nice and shiny "Best Practices" Enterprise Software is not built for such frivolities, "Best Practices" means that, what has been done before and that works as such.

To quote Larry Ellison from Oracle Open World the other day talking about their new Fusion application suite: "There are some 10,000 unique business processes in the suite, and 100 different products will be available simultaneously at the general release."

That's a lot of prebuilt "Faller" houses, surely enough to enable somewhat different businesses for different users, but still you're stuck with Mr Ellison's view of the world. The existing world of business processes that is.

[WARNING: Words alluding to our own technology might ensue. So if you'll have none of that, stop reading now and please accept my apologies for leading you this far :)]

But were you to strike out on your own, differentiating yourself and even innovate in business models; what you're in need of now is a piece of Enterprise Software that models reality like you did in above Strategy session. Like "Lego".

And do you really have a choice? Can you really compete without being different? Yes you can follow best practices and use Mr Ellison's world view, but then you have to get up earlier in the morning, your time being your only competitive parameter after you left the creative part to Oracle or it's many brethren.

Nope, the "Lego" model is better I would argue.

That is exactly what we set out to with Thingamy, and what it now does, it is the "Lego" set for business strategies and subsequent implementation. No wonder that we see increasing interest from startups, both virgin firms and new "projects" within established firms.

Instead of focus on individual efficiency (or general efficiency as per "best practices") we focus on organisational effectiveness and strategic freedom.

Leaning on Mr Ellison's and his brethren's world view and vast experience in the existing feels safe, but be aware that the safeness of the crowd also means risk of being trampled. Good for the established mastodons, bad for the new and smaller.

Who killed big corp innovation?

2010-09-07T14:53:05+02:00

The Product Manager.

Look no further, that's the one, the main Big Corp innovation killer.

OK, do take that with a pinch of salt. It's not personal either, if you're a PM, it's not your fault. But please read on, there might be a grain of truth in the silly claim after all:

You don't even have to have that title, any "VP of something" often have responsibility for a specific product/product-line/technology. Same thing, different wrapping. That's how big organisations are built, around a core of guardians of existing products/technologies, perpetuating the status quo as it is.

Responsible for a product or product line? That's the whole shebang; full lifecycle, it's growth, it's profitability, it's wellbeing, it's existence.

A great idea if the word was static. Excellent idea. But alas...

Would a Product Manager for riding crops have welcomed Gottfried Daimler to his office?

The Guardian Of Existing Stuff, aka Product Manager

But it's not his or her fault:

The product/product-line/technology "owner" is measured by, and his/her bonus and future is dependent on how good they are at milking and keeping alive "what we've got".

There never were any bonuses for killing off the horse buggy business to build a complete new car business, or dismantling the train tracks then start flying.

But even without bonuses it happens all the time, but mostly too late for the poor Product Manager. He only gets the blame while his successor makes the much needed kill before moving into the future as the new hero.

Nope, the responsibility lies with the strategists and top leadership.

Refocus from corporate viewpoint to customer viewpoint, from "our needs" to "customer needs", from "our product" to "customer's product". Then the "Product Managers" could become "Customer Value Managers", responsible for a set of customers and how to help them best, bugger the product really, that follows.

Enterprise Software Innovation - mostly Spray Paint and Fast Food

2010-08-24T15:30:40+02:00

As Vinnie puts it, "Big Tech is Broken - badly".

And broken needs fixing, but is the patient ready for that? I wonder if the issue is a semantic issue; how the fix, the innovation, is understood. If you don't get that right, well then, you're off on the wrong foot. Or rather, you might be band-aiding a broken leg.

Lets have a closer look at the term "innovation":

"Make changes in something established, esp. by introducing new methods, ideas, or products"

Chew on that for a second. Think Enterprise Software innovation and notice how easy it is to interpret it differently depending on where you hail from?

For the new chap on the block "something established" should mean the established ways of their potential customers. I.e. an opportunity to innovate on how the end user delivers value using IT.

The established folks (or the new with an "established" mindset) could easily think that "something established" means "established technology and products". I.e. a need to enhance existing products without bothering the end user.

Both interpretations can arguably be useful for the end user. But only until a certain point, the latter, refining and making it easier to consume old technology, will have a rapidly diminishing value gain, in the end have no gain at all. What is the gain of upgrading from ERP x.1 to ERP x.2 these days? What about the amounts spent on UI experts and labs, does it feel like well spent (my) money?

The propensity to focus on bettering established products instead of challenging how things are done at the end user and do something innovative about that, is also influenced by a closeness to the market: End users are not often willing to change their ways until they have to, so when asked by the marketing people of the established vendors they tend to define their needs based on existing ways and products.

[See "The innovator's dilemma" by Clayton M. Christensen for more on that.]

Hence the two general innovation strategies of the Enterprise Software industry:

1. Spray paint.

Upgrade old stuff, tweaking of anything in existence, tinkering with new features, UI work to make it look better, add more reports (say BI) - spray painting for short.

[Thanks again to Vinnie who coined the phrase "'Spray Painters' of the New Renaissance" on page 12 in his new (and great!) book "The New Polymath" (more about that in a later post).]

Spray painting has long been the daily "innovation" path for the established, but lately a new "innovation" option has emerged, both for the establishes and for many new vendors:

2. Fast food.

Take a cue from the restaurant business, make the product(s) easier to consume: On demand, in the cloud, cheaper, faster, simpler, SaaS - the fast food strategy.

SaaS with relish.

Sadly enough, easy scaling and the lure of easier consumption entices many a new entrant to act as if they were established, often with initial good results. But soon the fast food chains will be established and the consumers will wake up to their real need; deliver better value, not only engage in gluttonous, cheap and easy consumption of the old ancillary tools.

The dilemma for the new is often that their backers (see VCs) have a well established "truth" of "never try to change user behaviour". A rather sensible attitude per se, but a disaster for real innovation if one wants something truly new and disruptive for the long run.

The dilemma for the established is the inevitable cannibalisation; if they were to innovate on the ways their customers delivers (IT supported) value it would question their existing products and threaten the cash flow.

Spray painting and fast food strategies makes much sense short term, but history has shown us time over and again that some will break the short term mould and one day make the others irrelevant. To get there one has to be truly brave and go beyond the obvious and visible. But alas, brave is not typical enterprisey :)

Business Software is in need of some leaps and bounds!

2010-08-11T13:49:47+02:00

Most business software is created to help you do what you do today, in the same manner, but hopefully better, faster, and with less effort. Efficiency is the siren call.

But alas, the usefulness and ROI of upgrading have a diminishing rate of return. After x versions of word processors, after y versions of browsers, big company ERP systems now in version z, can you imagine any gain at all by upgrading?

Of course the vendors are aware of this, shifting their R&D spend towards delivery methods and technical tweaks to deliver speed and simpler consumption: The Fast Food Strategy for Enterprise Software.

But there is another kind of curve, the results of doing things differently; when we moved form horse to car, from hunting to agriculture, when the assembly lines were introduced, when electricity became widely distributed and people changed their ways and let machines do much of the manual labour. And indeed, when the first word processor was introduced. That curve is not a simple curve, it's more like a collection of leaps and bounds interspersed (and paused) by the usual diminishing gain curves.

To have one of these, one has to allow for changes in what one does, to focus on effectiveness of the whole instead of efficiency of the parts. But alas, software marketers and designers are not of the brave persuasion, they would never dream of trying to change the way people go about their business. The age old "truth" of "find a need and fulfil that need" is followed without a question. Follow the customer's lead, never risk leading, never make the move from efficiency to effectiveness.

Look closer and you'll find that a Diminishing Return Curve is identical to a Maturity Curve, so no wonder why most agree that Business/Enterprise Software is mature. In truth it's not, it's just waiting for the next bound. If somebody dares.

Unlearn or Challenge?

2010-07-30T18:57:00+02:00

What's the diff?

David Heinemeir Hansson of 37signals and Ruby on Rails fame spoke at Stanford the other day - Unlearn your MBA!

Good concept of course, provocative title for a talk for business students, and old stuff is old and new stuff is new so hard to build new using old, catchy.

Albeit, a small logical flaw there - the old is there, new is only new in relation to the existing. Better is only better compared to something worse.

Hence, you need to know the old, you need to know it damned well in fact - without that you cannot position your new product or business model. You need to know all about building houses before you can create a better one.

And worse, without knowing the existing you cannot create. Creating is another form of reusing, or rather reusing in another form!

The crux lies in "challenging", learning and then challenge what you learned. Question everything, do not take anything for true or granted. That will create new things and ways.

In other words, not "learn then unlearn" but "learn then challenge".

But alas, I heavily suspect that is a personality trait not easily "learned". You know the types, always sceptical, heretics even. I like heretics, they create the new - and I bet you that they know the existing extremely well!

If you're not into questioning all and everything, perhaps the simple solution is to unlearn, but then you might end up with the shack above.

Summer and all that

2010-07-29T17:36:23+02:00

Been quiet for awhile now, and not because I've had a spot of vacation, quite the opposite.

Delivery-time now, meaning programming, helping to build a new business model (and delivery using Thingamy of course) for a very interesting and ambitious startup. Now stuff's ready as POC.

New RESTful API, new front end engine in Rails (no less) and lo and behold, good fun all of it. Allowing me to hash around with the interfaces like I've never been able to before. PUI, Process User Interface, on-device. Actually started with the iPad/iPhone and cloned to normal browser.

In addition, found that all the tinkering with "Projects" and "Cases" and whatnot led me one day to say "bugger all those terms" it's all "work" and the people doing it are "workers" and most "work" is collaborative and Barely Repeatable. Full stop. One system to do all work, simple ain't it?

So here's such a thing:

Soon back with normal posting, have a few brewing already, just need a couple of dips in the pool and some cycling in the back country in between so I won't miss vacations too much :)

Simple errors and big consequences, same procedure as always.

2010-06-30T14:36:43+02:00

Hat tip to Eapen Thomas who pointed me to this year's commencement speech at Stanford’s School of Medicine given by Atul Gawande. Here is an excerpt of what he told the graduating class:

We’ve been obsessed in medicine with having the best drugs, the best devices, the best specialists—but we’ve paid little attention to how to make them fit together well. Don Berwick, of the Institute for Healthcare Improvement, has noted how wrongheaded this is. “Anyone who understands systems will know immediately that optimizing parts is not a good route to system excellence,” he says. He gives the example of a famous thought experiment in which an attempt is made to build the world’s greatest car by assembling the world’s greatest car parts. We connect the engine of a Ferrari, the brakes of a Porsche, the suspension of a BMW, the body of a Volvo: “What we get, of course, is nothing close to a great car; we get a pile of very expensive junk.” Nonetheless, in medicine, that’s exactly what we have done.

Earlier this year, I received a letter from a patient named Duane Smith. He was a thirty-four-year-old assistant grocery-store manager when he had a terrible head-on car collision that left him with a broken leg, a broken pelvis, and a broken arm, two collapsed lungs, and uncontrolled internal bleeding. The members of his hospital’s trauma team went swiftly into action. They stabilized his fractured leg and pelvis. They put tubes in both sides of his chest to reëxpand his lungs. They gave him blood and got him to an operating room fast enough to remove the ruptured spleen that was the source of his bleeding. He required intensive care and three weeks of hospital recovery to get through all this. The clinicians did almost every single thing right.

But they missed one small step. They forgot to give him the vaccines that every patient who has his spleen removed requires, vaccines against three bacteria that the spleen usually fights off. Maybe the surgeons thought the critical-care doctors were going to give the vaccines, and maybe the critical-care doctors thought the primary-care physician was going to give them, and maybe the primary-care physician thought the surgeons already had. Or maybe they all forgot. Whatever the case, two years later, Duane Smith was on a beach vacation when he picked up an ordinary strep infection. Because he hadn’t had those vaccines, the infection spread rapidly throughout his body. He survived—but it cost him all his fingers and all his toes.

How can anybody really believe that all processes, or workflows, will always happen as planned when they're manual and dependent on people? What geniuses take that for granted?

Risk is a result of two components - probability and consequence - and the probability to forget to "pick up milk" is equal to forgetting to "check the damned oil blow-out preventer". No amount of to-do lists will change that; forgetting to add a to-do is as easy as not reading it. Not to speak about the usual accountability and hand-off issues: "I thought my wife would pick up the milk".

The practice and theory of making organisations tick and make processes happen is called "management". And we've been refining organisational practices and management theories since long before the Roman army, including hundred years of Business Schools, armies of Management Consultants and about 40,000 management books in print at any time. With two results; 1. nothing much has happened, and, 2. we are still accepting manual DIY process.

There is only one way out of that mess, and that is to automate the sequences, that B follows A all by itself. In other words a proper process based system is required.

Process is the core, and without a proper framework that ensures hand-over in an iron-clad way, and that guarantees complete accountability, the risk won't change. No amount of money forked over to McKinsey (slow behaviour changes) or dog shock collars (improve behaviour fast) would alter that reality.

Three types of GUIs - past, present and the future

2010-06-08T15:42:10+02:00

There are three types of Graphical User Interfaces: First we had to interact with our early IT tools, as on our Apple IIs with Visicalc, then we had to face an ever increasing number of apps that made our screen into a messy desktop, and lately, the front end of process snippets on new and often smaller screens.

I'll call them TUIs, DUIs and PUIs.

TUI, the "Tool User Interface" is the mature one. We're now used to what we were served at first, as can be seen from the cries of protest when Microsoft moves an edit button from one place to another. Usability inevitably being measured by how easy it is to navigate by an old MS Word scribe.

In essence the TUIs' purpose is similar to a well sorted toolbox when you go about repairing your car, or when taking apart your laptop to replace the hard drive. Sorted, "logical", find stuff in the usual place with minimum effort and disruption to the task at hand.

It's the UI of word processors, presentation kits, image manipulation tools, blogging interfaces and every other single task tool.

A TUI as we know it.

DUI, the "Desktop User Interface" is still not quite mature, hence the theme of a million blog posts, thousands of UI web sites, "expert consultants" and even conferences. Now it's about making the tool cabinet full of toolboxes easy to navigate.

In essence its purpose is to take a cluttered desktop with all kinds of tools, papers and sorting boxes and making them virtual onto a single screen so you can find the right toolbox, the right files and get going with whatever task you choose with minimum effort and no confusion.

It's the UI of multi task "systems" like CRM, HCM, ERP, personal organisers etc., and not to forget operating systems.

Now, all business is about process and multiple tasks, hence the importance of DUIs. Problem with the current crop of multi task systems is that they have little or no process built in, it's usually a matter of do-it-yourself - hence the need for all possible and impossible options being present at all times.

A DUI with about 150 clickable "buttons".

PUI, the "Process User Interface" - so far the area of simple OS processes like "Install new printer"; pure step by step process, but as of lately, quickly spreading in the form of iPhone (and other mobile devices) apps.

Now it becomes interesting as a process can be delivered in a different format; one step at a time, no need for all options at all times and the interfaces can be two buttons, three choices or some fields to fill in - all with a "Next" or "Submit" button on the bottom leading straight to the next interface - yours or somebody else.

Some PUIs

It changes the whole understanding of what a UI is even if some have touched upon it: Google; one logo and a simple search field in the middle of a white screen. Twitter began with a list of messages, a reply button, a message field, send. Wait for somebody else to reply. OK, not much process there, but two or three steps is still a process.

Now imagine business or enterprise apps that are process based, not single task items knit together by DIY process: An app that can pick up an idea, issue or request and run it through an unpredictable process that might look like a ball of yarn all the way to an implemented idea, a solved issue or a happy customer.

For these, forget DUIs and TUIs, think PUIs. Imagine wizardly step by step, think two choices and a submit button, think that you will get exactly the information and the choices to make, or fields to fill in at the right time, then add what the iPhone and now the iPad has done to interface thinking.

That is the future of business and enterprise apps and UIs. Bye bye to a million blog posts using the term "intuitive", hello "just do it".

Thingamy is a business/enterprise app like that, so that's exactly what we're tinkering with now - dumping all notions of DUIs, going pure PUI. In a month or so I might give you a glimpse of what the future of business/enterprise UIs might look like. No confusion, just-in-time and just-what-you-need information and functionality. Ugly or not, pleasing colours or not, rounded corners or not - different issues altogether, all secondary at best.

SAPPHIRE Now - huge surprise, good stuff and a couple of important issues

2010-05-21T16:52:39+02:00

I have to admit I went to Orlando and this year's SAPPHIRE Now with lower than normal expectations.

Boy was I surprised, and in a good way.

Overall I found a turbocharged and far, far nimbler SAP. To the extent agile that our freshly printed meeting agendas sometimes had the executive descriptions wrong. New units, new responsibilities, new groups emerging on the fly - like the day before. I promptly gave up understanding the intricacies of their hierarchies and went with the flow and what people actually were up to.

It even seemed to me that the people had the same attitude, the "heck let's do this and bugger the old structure" confidence. And for sure, Vishal Sikka, Jim Hagemann Snabe and Bill McDermott all displayed an assured poise I haven't seen before among SAP top executives. All well supported by a fun loving, iPad toting Professor Plattner roaming the halls.

[Cartoon by the ever great Hugh "Gapingvoid" MacLeod of course]

I am the archetypical sceptic, but on the grand scale my hope for SAP long term got a huge boost. And I still like them a lot.

Now to the first disclaimer; SAP graciously paid for my trip and lodging and the ever efficient Mike Prosceno and Stacey Fish had it all in their able hands making our stay a great pleasure. Not to forget the ever helpful and good friends at SAP like Marilyn Pratt, Ann Rosenberg and many, many more.

My second disclaimer is that I'm creating software that I once declared was "not meant to compete with SAP, rather to make SAP irrelevant" - which now has grown to become a "development and run time platform" to allow the likes of SAP to make their old technology and concepts irrelevant instead. This obviously adds quite a bit of tint to the glasses I'm wearing, so read accordingly. But notably; our interests are aligned overall.

From that point of view, certain news made me happy, even if the results are not yet in:

Jim Hagemann Snabe clearly stated that their "old stack" would be challenged and that they will work with partners to create a future stack. This is a very radical shift, only six months ago any new idea or concept was seen through the filter of "how can this be added to our existing stack?".

That "on demand" is a clear and important part of the overall strategy is another issue that pleases me. And it's more important to SAP I think than merely new deployment mechanisms, it will touch the whole organisation and speed up the shift towards new stacks as well. Now we're talking about products beyond the suite; Business by Design, definitely an extremely promising product but still born by the old beast. The will to see "on demand" as something more than extensions and add-ons could be gleaned from new (and generous?) funding made available as well as separate organisational groups, all good in my view.

With "on demand", even for stodgy Enterprises, things change by force of nature: Transparency and speed are the new factors - long term, waterfall and cards-close-to-chest is dead, costly products devised by committees is a non-starter. SAP is now entering, for a part of their portfolio, the world of Google and others where new products are picked up, thrown at the wall - if it sticks fine, if not, redo and rethink or try another. Of course with more solidness than what Google and others might get away with, SAP still has a brand and mission critical type of use to look after.

An interesting aspect of that is that the notion of "success" changes as well: If a four-years-in-the-making product from SAP of yore fell flat on the face it would be an unmitigated disaster and taint the brand, hence cards-close-to-chest. In the world of try early, fail fast nobody bothers and it's seen as brawny - and innovative in fact. So SAP, please stop defending new products in that area, listen, retry and go about life with your head held high. (Could point to a certain recent product that is well executed, nice looking but has many puzzled as to what it is - name withheld but for those in know; it had three names so far..;)

Now they will need more than a new attitude and agile organisations, they will certainly need new and different technologies if they are to "throw a bi-weekly product or two" onto the market to see if they stick. (Here my own interest comes into play, our platform is built for that of course. If they say they are "Real" real time I will say we are "Agile" agile).

Despite all the new and great I found there are still a couple of issues I would raise again, now with a much higher hope they will actually do something about these (both definitely seen through my tinted glasses):

1. Still no reaction to a huge potential market and opportunity they're missing out on.

Two and a half years ago I wrote a post after attending their "Influencer's Summit" in Boston: "SAP missing the biggest opportunity ever". As most of my readers know it's about the ERP vs BRP market.

Now, 30 months later the BRP (Barely Repeatable Process) market is as big (twice that of ERP (Easily Repeatable Process)) and still utterly virgin as to lack of process based IT support while having a huge upside value-wise for the customer (2/3rd of resources spent in BRP is on manually driving the process and not on value creation). And of course the ERP market is as well covered, very competitive, utterly mature and even more incremental value-wise for the customer.

SAP has killed the old sacred cow of all-growth-from-incremental-add-ons, and they want to double their (stated goal) addressable market: Hence they will need to find a new and virgin market involving existing customers and know-how - and here it is, named BRP.

The first signs that SAP is slowly eying the BRP market can be seen in the launch of products like Streamwork. Too bad though that their first stab do not have process as the core (still only DIY manual process) - dear SAP, please make note of the P in BRP!

If they took BRP seriously, with a P; not only would they have their doubling (actually they could triple it) of the addressable market, they would also be the dominating first mover. But of course it requires some challenging of old assumptions and a dab of new technologies, but they know where to find me (sorry, see my second disclaimer above), BRP is our forte.

So I'm going to repeat it: Do it, and do it now.

2. A missing ingredient in their grand (and otherwise good) In Memory DBMS strategy.

First out I must say there is nothing to dislike about in-memory and columnar DBMS, I liked that since Shai Agassi's days and the term "accelerator", partly coloured by the fact that our DB always was in-memory.

My issue is that their focus is merely on the BMS part of the DBMS; the way they handle the data. They forgot something: The first letter, I always like to start with the first part, the underlying part as that often leads to better solutions - the D in this case.

Nobody challenged the D, or rather "what is the data, why is it in the form it is?". Which inevitably would lead to the architecture of the main applications where such is set and the data is created.

If they had asked me I would have said the following: The format of data today is a model by itself based on old technologies and is not a direct model of reality, specifically, I have these two issues to raise:

a) No split of representation and presentation is bad:

This made sense when you had a correspondent at the battle of Bulge that used pen and paper to represent the ongoing in the same format that it was going to be used for presentation later.
That is the principle of forms and documents and most of the business objects in ABAP: Each data object often representing many real world objects in one go; a letter representing you, your house, the bank, it's office building, the account and so forth. And you know what the complexity brings: Last time you moved, how many letters did you have to send to update you address change? One single object representing your house, then related to you as another singular object, you then related to the bank account and so forth. Change the relationship between you and your old house to the new house once and all is fine.
Split representation and presentation and the data volume falls dramatically, combine the singular objects at will when you need presentation and not only do you get a huge boost to reporting depth and ease but the overall complexity shrinks dramatically.

b) Multiple indirect representations - should be direct representation:

A result of double entry book keeping, a never challenged 515 year old paper based technology.

A widget in today's system is indirectly represented by a multitude of invoices, shipping papers, reports etc. A singular direct representation of objects that is timestamped using relations can deliver the accounting reports with far higher reporting depth, far less objects and no reconciliation issues.
A system holding 200 objects each indirectly represented by 20 objects would be 40,000 times more complex than a system as described above (our stuff is like that).
Then a speed increase of 10,000 as claimed by the in-memory becomes small potatoes.
I am not saying this is attainable overnight, quite the opposite, it would need a long term transformation of the underlying models before it spills over into the DBMS. The In Memory DBMS path is good, but I'm saying that it could have been so much better if SAP had spent (or will start spending) time to challenge the D part of the DBMS.

All in all a most enjoyable SAPPHIRE Now, with much to applaud and lots of reasons why my last few quibbles will soon be addressed I'm sure. Thanks again to SAP for putting up with me!

Bonus point: If anybody was sceptical about iPad being a potential enterprise tool; a day or two at SAPPHIRE would have killed that scepticism. Professor Plattner used it in the keynote demo, enterprise suits of all ages could be seen toting only iPads instead of laptops (perhaps first chance to get away from Dells/HPs with Windows on?) and all trade booths raffled out iPads to anybody showing any interest in their wares. Except Microsoft of course, who raffled out a Zune... and the only guy who signed up for that won it I think... :)

Plans, Budgets, Deadlines, not what you think

2010-05-11T15:24:50+02:00

You know the stuff that makes the corporation hum and spin it's wheels, the workflow mechanism, the process framework activities and not the value creation work per se: Plans, Budgets, Deadlines, Rules, Meetings, Reports... Are they as efficient as they claim to be?

[Emperor's new clothes - Illustration by Vilhelm Pedersen]

Plans

Plans are the railway tracks of work, keeps it all in place and makes the train go faster. Close your eyes and fire up the engine. No direction changes please. Nor much creative input underway, just shuffle the coal and shut up. Good for building the bridge, not when you're trying to solve a traffic problem, so the bridge is what you get.

Plans limit.

Budgets

The boss wants high income, low costs, the subordinate wants high costs and low income. They agree on some middle way and the subordinate follows the budget and use it all to ensure next year's budget while the boss is happy. Budgets adds a floor just under the ceiling, budgets keeps the costs up. And in the meantime the world trundles on with shifts to oil prices, exchange rates and market conditions, blissfully unaware of any budgets.

Budgets increase costs.

Deadlines

When I was out cycling with my oldest for the first time we passed a brook. Son, of course, shifted his focus toward the running water, and guess where he ended.

Give a man two weeks to finish up and that's what he'll focus on. Delivering in half the time would be offensive to the boss who set the deadline, hence all is delivered on time, never before, rather a tad late.

Deadlines make things take longer.

Business rules

Ever been on the phone with some support department and heard "sorry Sir, but our rules does not allow me to..."? Or been to a government office and had "nope, you're not in the system..." thrown at you? Well, trust me, it happens. Sometime, with luck much of the time, dumb rules work. But at best they merely extrapolate history, and history is the past and things change. Only one way to term such:

Rules are stupid.

Enough, don't get me started on meetings, reports, double entry book keeping, organisational hierarchies and the rest that makes up the old work process framework.

Time for an alternative work framework. No more rigidity, move business back to "now" again.

How business hoodwinks itself

2010-04-20T17:12:10+02:00

When you create a new company you have an idea, some sketches, then you develop a product or a service while trying to understand your potential customers by listening and testing. Then the production/service org gets cranking, channels established and sales ensues. All fine and dandy.

But imperceptibly...

Your focus slowly shifts from idea, customer understanding, and free-thinking development to efficient production/service delivery, better channel deals, development restricted to "what you know" (i.e. what your production/service can handle) and your customer relationship shifts from "curious partnership" to "pushy marketing" (adding "social" to the CRM does not count).

That's when you start the slide. OK, many years of success might ensue as you grow, but the customers and the markets are fickle, technological changes will happen, the market might get saturated - and if your focus has shifted from "ideas" to "production" you will eventually be outdated, lose out, and the days of blooming flowers will be replaced by wilting stalks. That's the nature of things.

Why this shift of focus?

Humans (even managers) crave the predictable and will chose it over the unpredictable any day. Easily understandable patterns, especially process patterns, are much preferred to life's randomness. Stable and known processes makes life easy and an urge to shift focus onto the Repeatable and predictable is the result.

[Yep, used it before, now to illustrate doing BRP stuff the ERP way.]

Production, service delivery machinations, human capital management, and supply chain management are examples of Repeatable and predictable processes well served by ERP, SCM, HCM and other such nice TLAs.

This is yet another example of the ERP versus BRP issue. Those functions that are of the BRP type, once the "core", now becomes "support functions" while ERPs becomes the new "core". We like ERP so we try to streamline BRP using rules or rigid processes, but otherwise we minimise them. Over time the pure "BRP mode" startup becomes a rigid "ERP" machine.

Logically speaking; ERP is a subset of BRP. BRP in essence is a set of smaller ERP snippets with participant-chosen paths in between. An MD meets the patient, in itself rather ERP as it requires standard questions and predictable sequences of analysis. When finished, and only then, can the MD decide to send the patient to X-ray (another predictable and Easily Repeatable sequence of activities), to blood tests (another ERP), to another expert, or straight to surgery.

If the BRPs were well supported, even run as processes in some "Repeatable" fashion, then patterns becomes visible and some sort of predictability ensues. That might allow businesses to keep their focus on idea generation, partnering with customers, free-form development - in other words keep their focus on the true core, enhancing the "value we are to deliver".

Or put another way, BRPs are immensely important, the foundation of all business. Resource-wise, that's also where the majority of world wide value creation happens, so it's a win-win. So let's help the BRPs now.

Make it easy to conduct business properly again.

Fixing Greece

2010-04-16T14:15:36+02:00

I've been chirping about how automating the flow part of workflows, by adding a proper IT based process framework to BRPs, would suggest a possible 67% increase in World Wide GDP.

But I completely forgot an important issue; Corruption and Cronyism!

Here's yesterday's WSJ - "Tragic Flaw: Graft Feeds Greek Crisis":

[Greek construction drama, photo from Travelphoto.net]

"A study to be published in coming weeks by the Washington-based Brookings Institution finds that bribery, patronage and other public corruption are major contributors to the country's ballooning debt, depriving the Greek state each year of the equivalent of at least 8% of its gross domestic product, or more than €20 billion (about $27 billion)."

and that

"Greece's budget deficit averaged around 6.5% of GDP over the past five years, including a 13% shortfall last year. If Greece's public sector were as clean and transparent as Sweden's or the Netherlands', the country might have posted budget surpluses over the past decade, the study implies."

Obviously, government and health is (almost) all BRP. Put all of that into a proper process based IT system and total accountability and transparency follows. And that, as we know, kills graft, corruption and cronyism swiftly and painlessly.

As for Greece, that would solve their problem. I rest my case as I change our tag line to "Here's 30 Megs. Now go run Greece".

[Hat tip to my friend Pete for the nudge and WSJ link]

Disregarding BRP is like being long on subprime CDOs

2010-04-13T16:56:57+02:00

Now and then.

If you, as a developer and vendor of products, create a new product that has the promise of value for your customer you're onto something.

Say going back a few years starting up Facebook or creating the iPod you would end up with a wildly successful product, tons of happy customers and fat bank accounts.

But if those never happened the world would probably be just the same.

For the supplier of tools and solutions to enterprises, things are a bit different.

If nobody had "invented" the Subprime CDOs (Collateralized Debt Obligation) and all it's synthetic cousins the world would have been simpler. If Ford did not implement his assembly line (and nobody else for that matter) we might not be as mobile as we are today.

The purveyors of Enterprise systems and tools have a direct effect on everybody's life, wealth and resource use, and the results are sometimes dramatic.

Michael Lewis' last book "The big short: Inside the Doomsday Machine" arrived from Amazon the other day, and being a big fan of Lewis, a former investment banker and a stubborn sceptic I enjoyed reading more about the subprime crisis.

[Reuters]

But as I'm fully engaged in areas of enterprise software where I found, and try to address, rather obvious holes in the fabric, it also gave me some serious flashes of deja vu:

Barely Repeatable Processes (BRPs) is where at least 60% of the world's value creation takes place, and in those processes about 65% of the time and resources are spent on manually running the processes and not on value creation.

This means that we, World Wide, spend 40% of all resources and time on things that are basically a waste and that could be automated. Or to put it in other words, by automating the BRP flows we could increase World Wide GDP by 67%. Value damned well needed as it could mean much suffering wiped out and much less limited resource use, but now wasted due to old habits and unwillingness to face reality. Just like in 2007.

Those are the facts, that is the disregarded reality.

If you are an Enterprise Software vendor and are not facing this, please do yourself a favour and read about Bear Sterns and Lehman Brothers.

Then read about the head-shaking sceptics of 2007 that were pinching their arms (not always able to believe what the saw) while shorting the subprime market with both hands. Know then that I so sympathise with those brave souls while I'm trying to nudge organisations towards the inevitable in today's world.

OK, the Enterprise Software market has started talking about the issue, so far adding "Dynamic", "Social", "Adaptive" and similar prefixes to existing products. For me another deja vu from 2007 when Wall Street added names like "High-Grade Structured Credit Strategies Enhanced Leverage Master Fund" to their existing products. "High", "Structured" are good words, gives hope, just like "Dynamic" and "Adaptive".

Others of course are saying their "new" stuff "have process", but on closer look it's all DIY process easily reminding me of Moody graciously dishing out triple As.

Organisational Effectiveness vs. Personal Efficiency

2010-03-19T17:37:10+01:00

Wherever you turn you'll find that Enterprise Software is on a never ending quest to increase your personal efficiency.

It says so on the vendor's site, it seeps through in discussion about User Interfaces, one is constantly reminded how good that is for your company.

Sure, except...

Ask those who have had the fortune of becoming more efficient. Ask those who have all their tools in an easy-to-navigate interface. Ask those who have learned to read and skim reports faster. Are they under less stress now? Did that help to increase the company profit?

Not much of that is what I hear from within large organisations.

You do your job faster, then sit and wait for something else or get to dig into the slushpile.

Your rowing stroke gets stronger and faster, but so what unless the whole crew falls into same pace?

Here's the thing:

It's all about organisational effectiveness. How fast, efficient and correct all information is disseminated, how effective hand-overs in the workflow happens, how visible and easy to understand the process is, how effective the capture and subsequent dissemination of knowledge is and how little time you spend on making the flow happen.

That counts. That means better profits. That means more time for the kids and less stress.

And where is Enterprise Software in this? Where are the process engines and effective frameworks that can make the organisation more effective? Huh?

[Said same thing last summer, but as I meet this issue more and more often I felt it was upon time to rehash it a bit. Too important to be forgotten.]

Happiness and a better Enterprise Software Data Model

2010-03-16T17:20:14+01:00

Funny thing, seems the human brain uses same tricks as Enterprise Software to save disk space :)

Thanks to Zia I found Daniel Kahneman at Ted's site (go see):

Kahneman's premise being "confusion between experience and memory: basically it’s between being happy in your life and being happy about your life or happy with your life”.

Expanding on that he uses an example "about a person who listens to 20 minutes of glorious symphony music yet at the very end there is a dreadful screeching sound. In reporting this incident the listener said that the screeching sound had 'ruined the whole experience'. Still he had had the experience of 20 minutes of glorious music. But now that counted for nothing because he was left with a memory of the end; the memory was ruined, and the memory was all that he was left with."

That reminded me about data models for Enterprise Software: Save the "sales figures for March", forget, or even better, don't even bother capture the total of raw data that could have been captured in the sales process.

It's, like in Kahneman's issue, an issue about direct or indirect representation of reality. The indirect in his meaning I would presume "memory", while the direct being the "experience". Or slightly different; (indirect, manipulated) "presentation" being "memory", (direct) "representation" being "experience".

[Objects, now use your own imagination and create the story...]

Thanks to our paper based past we're still sticking to "presentation" being used to "represent": Documents being the perfect example, any write-up represents multiple real world objects, and often with events all mashed together with a dollop of the writer's own logic thrown in. In the days of handwritten scrolls it made sense to capture reality onto a form that could be used unaltered as a presentation. Ditto with double entry book keeping, decide at the point of capture what "it is", let a receipt "be" the "sale". Keeping the memory of the transaction and not the actual events with all it's little details that comprises what one calls a "sale". Did the customer smile? No data about that in the receipt I'm afraid.

And it seeps through in all our ways and keeps those not present from seeing the reality as it was, re-experience it to allow for new views. The "data" we're stuck with in Enterprise Software are "stories", already manipulated and far from reality, a "memory".

So this is what we must do, and Enterprise Software vendors, take note: Keep experience and memory apart as much as presentation and representation should be separates. See it for what it is, not what it presents. Add the colour and interpretation yourself, but for that you need the direct, "experiencing" data free of any previous manipulation. In practice one must capture all data, important or not is for somebody else to decide, by running all activities in process based systems, keep the raw data and apply logic only when in need of "presentation" (reports).

Yet again, the basis for all Enterprise Software must be process engines, unless "you're there" you cannot "experience". But alas, most Enterprise Software are capture-tools and process free, or at best, DIY process.

If your argument is that such models would create too much data I would say: Raw data takes minimum space, manipulated and formatted data takes much more space. Add that my brain is limited to hat size 61 but there are no hat size issues in the cloud.

And the last nail; Kahnemann suggests "that we think about future not as anticipated experiences but anticipated memories." And that is how planning is in the Enterprise, based on extrapolation of manipulated data with little context visible. Enterprise Planning is based on the logic of whoever wrote the reports or chose what account to add an item. Not smart.

Enterprise Apps User Interface - the wrong discussion

2010-03-10T15:38:49+01:00

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

[Update March 10: And Marc Benioff of Salesforce (the 150 buttons organising dashboard thing with DIY process mentioned above) is at it again: Facebook is the thing, linger away and create your own process as we've done for the last few thousand years. A quote that tells all - "time to transform the business conversation". What about process structure, why not automate the flow/process? Ford did it 100 years ago for Easily Repeatable Processes (ERP) and increase the organisational effectiveness 8.5 times, now time to do the same for Barely Repeatable Processes (BRP)! More of the wrong discussion again.]

Elegant Organisations? Daily Simplicity? Fugetaboutit!

2010-03-02T16:13:03+01:00

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