My First Digest

Where's Waldo?

Wed, 07 Dec 2011 04:29 GMT

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

Tue, 25 Oct 2011 07:05 GMT

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

Tue, 27 Sep 2011 05:43 GMT

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:

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

Tue, 06 Sep 2011 06:50 GMT

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

Tue, 02 Aug 2011 07:29 GMT

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!

Tue, 24 May 2011 07:49 GMT

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

Thu, 12 May 2011 07:52 GMT

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

Tue, 26 Apr 2011 07:39 GMT

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

Wed, 06 Apr 2011 07:00 GMT

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?

Wed, 23 Mar 2011 10:16 GMT

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.