thingamy

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.

Enterprise Software's blind spot

2010-02-19T17:31:13+01:00

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

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

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

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

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

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

Spreadsheets. Nothing but spreadsheets.

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

Almost a modern Project Management tool.

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

Work Flows and Wealth Creation

2010-02-02T15:16:56+01:00

Inseparable since the beginning.

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

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

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

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

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

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

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

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

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

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

[Thanks Hugh, perfectly put!]

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

Information, Knowledge, Wisdom, and Innovation

2010-01-19T15:42:02+01:00

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

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

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

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

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

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

Information: object facts

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

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

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

Knowledge: object relations

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

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

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

Wisdom: object relationship patterns

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

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

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

Innovation: object relation rearrangement

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

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

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

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

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

Process Engine + Social Media -> Thingamy and ESME

2010-01-07T11:34:02+01:00

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

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

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

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

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

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

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

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

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

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

Here's a conceptual description:

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

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

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

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

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

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

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

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

How not to do it - 12sprints and Chatter

2009-12-21T12:09:13+01:00

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

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

So what are the vendors doing?

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

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

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

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

But process illusion is not process reality!

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

Nowhere. Or everywhere in different formats.

Illusions works for awhile but will always fail.

It's so strange here...

2009-12-15T15:45:44+01:00

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

[Drawing by Oda Krogh, Wikimedia Commons]

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

I look...

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

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

A raindrop!

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

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

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

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

Now the clouds, blue-grey, thicken.

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

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

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

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

Since that post it has become widely accepted that:

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

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

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

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

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

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

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

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

So what the heck are we waiting for?

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

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

Office work is like shovelling snow

2009-12-09T14:36:11+01:00

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

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

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

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

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

No...

2009-12-04T15:13:03+01:00

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

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

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

Container, content, context - observed in situ

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

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

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

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

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

That's not good enough.

Simple is always better, but harder to sell

2009-12-02T15:04:53+01:00

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

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

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

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

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

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

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

Discovering the universal Business core

2009-12-01T16:42:16+01:00

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

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

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

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

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

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

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

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

8 minutes simple process demo.

Legacy Enterprise Software impedes gravity

2009-11-24T16:43:44+01:00

Movement requires a force.

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

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

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

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

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

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

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

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

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

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

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

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

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

* say, thingamy's Work Processor...

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

Legacy Enterprise Software is not strategic

2009-11-17T14:01:56+01:00

Despite being involved with some radically different Enterprise Software I have been fortunate enough to be frequently invited to study the wares and future plans of many legacy systems vendors.

So again last week, with some of my EI friends, enjoying the latest and shiniest offer from a major SaaS vendor.

And of course I'll be the first to admit that most of the stuff is very good indeed, albeit rather mature and not exactly what Hugh was thinking of when he used the term "being fucking amazing is job one!". Being very good seems to suffice for the best ones.

Core enterprise software usually have hard-to-grasp three letter acronyms - ERP, CRM, HCM, PLM, SCM, SRM. Then you have the non-core but oh so important for Enterprises like Office suites, Project management tools, email and much more.

The vendors claim they deliver a lot of value, and customers pays good money. But let's say I'm a sceptic and would question that:

First I would split your daily work at an office into two parts:

1) Add value: Create an ad, design a new car, deliver advice - the stuff that your customer is willing to pay for.

2) Make the (value adding) process possible: Distribute work, report, update, ask for updates, find stuff, search for information, communicate, go to meetings, budgeting, creating layout for your content, capture transaction details (accounting) - without which all other work would grind to a halt.

So what do the Enterprise Software really do? Some examples:

HCM - Human Capital Management: What we were looking at last week were typical HR management activities - a flurry of the usual HR terms like appraisal, vacations, hours and bonus came to my screen courtesy of WebEx. Not my usual line of activities, but with large organisations comes rather important HR organisations so I accept there's a market and value in helping those activities run smoother and take less time. In this particular demo a new UI was the main theme and how the users felt they now could spend less time doing their job. Always good news that for all involved.

CRM - Customer Relations Management: In essence a tool for the sales people to avoid forgetting to call a customer when they said they should. On the other hand it's supporting the managers so they can have an idea of "what's in the pipeline" when they're pestered by their superiors, that on their side is pestered by the board and Wall Street to tell what the future could look like.

Etc.

Office suites and email: Pretty 'package' my creative input, reports or updates, then distribute same.

Etc. Etc.

Recognise something? See a common denominator?

Of course, all falls squarely into part 2) above, the non-value add. Only supporting the work that allows real value-add work to be done.

As 'Strategy' is about 'what value are we to deliver to what customer and how are we going to be different' one can conclude that (almost) all Legacy Enterprise Software is non-strategic.

It merely supports the old structures and ways that executes strategies and business models today, in exactly the same way using the very same methods we've done for thousands of years.

IT is powerful per se, and I'm sure the moment the minds of business can free themselves from old habits and start challenging unconscious assumptions we shall have IT that can execute the strategies and business models and make the work that supports the real work a thing of the past.

That's when legacy Enterprise Software will be deprived of it's purpose, not merely become old fashioned or mature, but irrelevant, of no use, history, gone, bye-bye.

P.s. Special message to CIOs: Wouldn't it be nice to be responsible for the execution of the firm's strategy and business model instead of merely supporting the work supporting the work? Make the 'Chief' part of your title meaningful again?

E 2.0 - not joining the debate, but...

2009-11-06T19:21:38+01:00

Being 'diplomatic' I'm not going to step into the debate featuring Dennis, Susan, Nenshad and others... but I've been waiting and waiting for one benefit to be touted, an important but unplanned benefit (the only one?) I've seen in practice myself:

Years ago I was chairman-and-investor-in-residence at a electronic games company. Starting in 1995 it gained about 50 new employees every year, doing games on Nintendo and Sega platforms, later Sony and online - all developed by a great gang of mostly boys with an average age of 20. No kidding, our first Xmas party started with a 'parents day'.

As the industry expanded and the kids became slightly older and experienced we had the usual groups gelling in some corner tinkering with business plans behind our backs, then jumping ship and starting a competitor.

Not what the 'leadership' wanted of course, but pretty inevitable. The kids soon learned to encrypt the business plans as well, so the fun of reading plans and mails left behind on hard drives was withdrawn. Annoying.

Suddenly something happened, we did not know what, but whatever it was it stopped the wave of desertions.

Could it be the new menu in the cafeteria? Could it be that we suddenly became better at communicating? No theory clicked and management (me included) remained as clueless as we should be.

Until one day.

This being the quintessential geek work place, reeking of popcorn and with employees sleeping on the floor after a good night of downloading stuff, they had just made good use of the servers and network and created a flurry of internal 'newsgroups', the predecessor of todays forums. Of course the management was the last to find out, but we did not care.

Suddenly the group dynamics changed. When networking was solely physical classic group dynamics ruled, groups formed in a corner of the corridor, and face to face disagreements had to be handled and a common purpose quickly built. Usually along the lines of 'management sucks, we're smarter' and 'lets split and do it on our own'. And surely enough every desertion group came from the same physical location of the office.

With the company-wide network something else happened, visiting the office next door was replaced with online socialising. And while Peter found Andy in full agreement with his views one day it did not take long before they found disagreement helped by full transparency and input from 100 opinionated co-workers. The full throttle dynamics killed the slower dynamics of yesteryear and any tendency to group forming was followed by instant and efficient group splintering.

It was the exact same effect the E 2.0 advocates predict will flatten the hierarchy that splintered the employee group building. 'Split and control' is an old adage, and here they had organised it themselves. Excellent we said.

And the management lived happily ever after. ;)

A case for rethinking the data model - reporting from SAP TechEd

2009-11-03T15:09:10+01:00

Yet another TechEd is over, again definitely worth the time and effort.

Mike and Stacey did amazing work yet again, my good blogger and SAP Mentor friends were a treat as always, and the management of SAP displays an amazing openness towards us unruly bloggers. Sometimes I even suspect they're having a good time despite the barrage of ad-hoc and prying questions! Are we such a nice bunch? But of course... ;)

New this year was an "NDA" note in regards some of the themes, and not being a trained journalist I had to watch my mouth and think hard in follow up discussions. Too bad, understandable of course, but it probably allowed us to dig deeper and get a better understanding, even if some of the facts had to be kept in-memory only.

Fellow traveller Dennis Howlett did an excellent report from our meeting with Marge Breya, EVP & GM Intelligence Platform and NetWeaver, aptly titled "Is BI ready to meet the real world?". That meeting I found very interesting as a distinct data-oriented culture had descended onto SAP. Like inviting an army of sleuths to roam around your business trying to make sense of all your data, beyond what your normal reports could show.

My answer to Dennis' question would be a resounding "well...". For reasons that could be summed up as "BI is trying to band-aid an imperfect Enterprise Software reality, BI does not fix any root causes for the imperfectness" making it useful, but it's still a stopgap.

Marge started with an example: Diving into their own last results she found a positive abnormality in a certain product group/area, and with a childlike "wow, how did they do that?" and "let's find out so we can replicate!" she sent off mails to the producers of the sales-spike to get better explanations.

Obviously trying to find out who did what and how; what was said and offered by whom, what sequence did things happen - all the ach so important data that they call "unstructured". In reality she was trying to reconstruct the process that delivered the good results but could not find real "process-data" only "process-results-data". The solution was email and ask for process-data, if still present in their personal in-memory DB.

Unfortunately most see the "process-results-data" as process-data, but it's clearly not so. "Sales" says nothing about the sequence of activities, instructions given, changes to process path or anything else but the results.

Whatever BI does, no amount of analysis and time consuming queries person to person, nor any type of query algorithms will ever give the exact historical picture as most of the pertinent and most important process-data resides in-human-memory. Who called first, what was said, how was that handled and by who, what then and so forth.

Hence any bettering of the process and replicating successful process will be hard, or rather impossible.

(I probably do not have to remind anybody that it's in bettering the processes where the big gains and values lies.)

A bit later we again had the pleasure of meeting with Pascal Brosset, Chief Strategy Officer, who with his daft educational talent managed to explain what the new direction they're taking with in-memory database - the man would have been a huge success as a teacher - and the bloggers gave him a good round of applause (a first according to Mike).

According to Pascal, in essence, this will allow SAP to keep the raw data before they're manipulated and stored, giving the Business Objects data-sleuths something much more valuable to work with. As such I cannot but welcome them to the club as this is one of the core concepts of Thingamy; raw data rules, manipulated date is... well... manipulated!

As a part of that a new product is underway, Constellation, that hopefully will be able to extract "process-data" (actually rather in this case "pseudo-process-data") from the mess of unstructured "process-results-data".

Using the same argument as above I sincerely doubt the practical results of that, another at-best-approximation for reality as the real process-data (not the results of a process) are simply not present.

My understanding is that such extracted pseudo-process-data could then be converted to BPM processes, in itself not a bad idea but for the fact that BPM do not do real Barely Repeatable Process (BRP) which of course are the major part of what a business engages in.

But a data model does not stand alone, it's an intrinsic part of the Enterprise system.

There is only one logical next step, turn the situation upside down and start with the process. Include the BRPs in a real system that delivers workorders and runs the processes (like Thingamy of course). There is no other way to capture real, relevant and correct process data.

The processes are where the effectiveness of the business lies, merely capturing the results and not the process itself makes little sense. In addition running the processes would eliminate the data (and the work!) created by the unstructuredness of the process itself (reports, updates, mails, search, meetings, budgets, deadlines etc).

Talking about "next step", when meeting with Jim Hagemann Snabe, Executive Board member, I asked if they have a dedicated R&D group with the single task of "making SAP's products irrelevant"? History and nature tells us that it will happen, always, thus better to do it yourself. He agreed with the premises of the question but could not reveal the existence of any such single-minded little department. :)

[Disclaimer: SAP paid for my trip and hotel which was much appreciated of course.]

Work processor

2009-11-01T10:12:17+01:00

On Friday I was asked to give a presentation of Thingamy to an audience of non-techies.

My preparation and energy was a tad hampered by a bad cold and three days of non-stop meetings at SAP TechEd.

The presentation format was seven minutes which accentuated the issue of getting over a simple message of what Thingamy really is. No time for a half hour demo, no time to take the horse buggy and whip makers out on a ride in the Daimler automobile prototype in 1886.

But looking into baffled faces certainly kicks you into thinking mode. Lot's of ideas and paper use ensued.

Until this morning when my wife said the word, this is what Thingamy is:

Work processor.

Precisely, just like Word processors frameworks the smallish process of creating a letter or a report, Thingamy frameworks the somewhat longer processes of delivering a service or a product.

What do you think? Does it resonate?

Do something instead of doing things to get something done

2009-10-20T14:43:50+02:00

What if we could shift the whole world to renewable energy sources, feed and educate all children at no extra cost nor resource use?

What if you could double your bottom line without cutting costs?

All possible. Now.

Of all things, the solution lies within a segment for Enterprise Software not yet tackled, namely unstructured, ad-hoc, untamed, manual or barely Repeatable Processes (BRP).

BRP is a massive pit of wasted resources and lost effectiveness. And you're reminded of it every day as you spend all that time on "doing things to get something done" - planning, meeting, budgeting, reporting, updating, searching, accounting, pestering and being pestered. 20% of your time? 30%? 40%?

Efficient "work" flow situation free of meetings and budget reporting.

Eliminate those "doing things to get something done" and free resources that can be better spent (and on a micro level increase your profits as well).

And that's where Enterprise Software enters as it should be tasked to deliver a framework for the work flow, automate the flow if you'd like. Although in a way that allows the full human potential, not as rigid as Ford's assembly line or most three letter Enterprise Software apps.

To wit, let's look at last week's interesting conclusions about unstructured / Barely Repeatable Processes in the world of Enterprise Software:

It's huge, immensely important and forgotten. Gartner says such stands for 60% of all work while Oracle suggested 20% of world GDP happens in projects (typical BRP).
There is no current IT solution. Gartner, despite being an IT analyst suggested throwing more management on it as BPM (only IT solution with a glimmer of hope) is much too focused on, and built for, structured processes.

That fits my world view nicely having suggested that BRP stands for 64% of the world's GDP and that old models and transactions based Enterprise Software architecture will never ever be able to model the BRPs.

As you would know already, the stuff we're tinkering with is a complete break from old Enterprise Software architecture and thrives with BRP. In fact it's made for it, framing work so it can flow by itself in a transparent (reported) way.

But a natural "flow" is alien to the office worker of today, which might explain the unwillingness of Enterprise Software vendors to break with the past:

He has to start doing things the natural way; follow the flow and unlearn the silo'ed workshop ways of current IT. It's like re-learning to run barefoot, it requires an effort. And that in an IT reality imbued with words like "easy consumption" and "intuitive" (see "that's how I always did it") making the term "effort" dubious at best.

It's time to face reality and to translate it into tangible figures, weighing that up against the laziness and unwillingness to unlearn. Allow me a hint:

Say that your business/department is (as Gartner says is typical) 60% BRP, and assume 30% (much too low I think) is spent on doing things to get something done and your EBIT margin is 20%. Getting rid of that wasted time (assuming the newly freed capacity actually has customers) would increase your profit with 110%.

Now let's add up all those "profit increases" and look at the accrued effect: Use same 30% wasted time to all BRP at 64% of world's GDP and what do we get?

A little bump in our common and total annual products/services delivery (world GDP) of 19%. That would be an extra 11.7 trillion USD per year that we could spend on important stuff without using any extra resources.

Say feed and educate every child on earth, shift the entire world to renewable energies and pay off the financial crisis and it's bailouts (that would be a one year thing) - still you'd be wondering what to do with the 7 trillion left after the first year and the 11 surplus the next. Perhaps start working on bettering the circumstances for the poorest of this world? Wiping out Africa's debt would be a mere drop of 0.2 trillion.

And by the way, if my figures are way off it would not matter, enough to go on to cover it all anyway.

The facts are telling, the potential results compelling, but the familiar "but this is how we've always done it!" and "where are the familiar interfaces?" is the defence against change. Laziness and oblivion rules.

Yes, one has to make an effort, and yes, stop focusing on "intuitive", "easy to use", Anything 2.0, Cloud, SaaS and any other buzzwords that makes life easy and your inside go fuzzy and warm. It's business, life's tough so get over it and focus on the results.

Is Gartner "getting it"?

2009-10-06T17:49:16+02:00

(At least they've found a huge issue, but not so much a solution.)

Always a pleasure to read a blog post with "revelations" like this:

"...the hidden costs of unstructured processes: although a lot of focus of BPM efforts (time and money) is on structured processes, as much as 60% of an organization’s processes are unstructured – and probably also unmonitored, unmanaged, unknown and unruly."

Fellow Enterprise Irregular Sandy Kemsley wrote this yesterday following a presentation at Gartner BPM Summit by Elise Olding and Carol Rozwell.

The reason I'm quite pleased is of course that this is about what I've been chirping about for last few years, namely the volume of and complete lack of an IT framework for Barely Repeatable Processes.

The difference though is that Gartner, after seeing the issue, struggles with the solution. Despite their IT credentials they fall back to suggesting more of the existing (and thousands of year old) framework; more management. I, obviously for those who knows from where I come from, humbly suggests there is an IT solution. And it's not BPM.

"...a lot of focus of BPM efforts is on structured processes" is something I would dare to expand with "as BPM cannot do unstructured processes (BRPs)".

Pools and swimlanes and a nice palette of icons do not help much when the structure itself is too structured, limited to two dimensions and allows leftover structural beams like organisational hierarchies and business rules to add even more rigidity.

Hailing from colder climes I cannot but use a wintery metaphor - BPM is like cross-contry skiing; rather two-dimensional, sticking to clean tracks and clear intersections with limited choices.

BPM moment

BRP is snowboarding. You're on top of the hill and down there you've got the bottom of the lift. In between you have a piece of a mountain and on your feet you've got the tool ready to go. Exactly what happens between here and there is completely up to the participant. But if the environment is well laid out, the tools any good and the snowboarder worth his salt he'll get down in a fashion and in a time that cannot be bettered by any maps, plans, budgets or pestering by any "coach" on the sideline.

BRP'ish non-BPM situation

Impossible to model you say? Ah, well, that would be depending on the level of detail (read control) and if your mind is still in "automation" mode or not.

Actually, even Barely Repeatable Processes are repeatable big picture wise. Believe me, I've been to the mountains...

Building by taking apart

2009-09-22T15:08:47+02:00

Apologies for spotty posting activity, much too busy busy with stuff that is shaping up in unexpected ways.

Ever had that feeling you're close to some solution even if you're not even looking for one? A vague pattern slowly appearing somewhere in the back of your head?

That's where I've been a long time now since starting to model real world businesses in Thingamy. The solution-not-looked after rising from the increasing revelation that "heck, these seems to be very similar" when one day building for a support department handling IT installs and the next a marketing department tinkering with requests and ideas.

Not to mention building an A to Z model for a law firm and the next the same for an advertising agency, same "ah, they're the same, different wrapping only, different weight on different part, different terms but all together same shit".

The very few business process modelling and running tools out there, basically BPM and Thingamy, are empty and requires theoretical modelling after much analysis etc. Then build from bottom up and implement. Then tweak. Much work, although I'm extremely pleased with Thingamy as I can do things in hours instead of days and weeks.

But would it not be nice to have the exact opposite situation? Take bits and pieces away and keep what you want? Like this block of Carrara marble but with less sweat :)

Start with something that covers all you do and more, then hide what you don't need for now allowing you to bring that back at any time. Spend a few minutes then implement while having two sips from the tea cup. All done before the client could finish the sentence "how long would this take?".

Done, the first of two generic models / templates is ready and about to be used: The "BRP One" that covers (almost?) any Barely Repeatable Process.

In progress, the second model / template: "Services One" that should cover most typical services firms from customer calling to delivery - law firms, advertising agencies and consultants of all stripes. Out-of-the-box cover of all they do, just tweak the terms and hide what you do not need just now.

That's where my head is these days, too much fun, too much single-mindedness going on to potter off and discuss minor issues like world economy and such. Sorry, but will re-surface and do some more double-entry book keeping attacks soon :)

Think I nailed it

2009-09-08T10:08:27+02:00

One single model for all Barely Repeatable Processes: IMCI, OODA and uttering of eureka!

Most of this summer I've been busy building real world pilots, process model templates for Thingamy that is.

When implemented and tested (such radical stuff) always inspires "straight and honest" reactions from uninitiated users - reactions that frequently had me slapping my forehead, utter a "duh!" and execute a quick dive into the code. An inspiring and quite practical process indeed.

A summer of Aha!s and Real Leaps Forward.

All the builds were for classic examples of BRPs (Barely Repeatable Processes), albeit bits, pieces and chunks of such.

Yearning for some holistic solution coupled with a hunch that we were getting closer I made many attempts on merging different builds and many, many rebuilds from scratch. Not always a success, but somewhat fulfilling as it seemed I was getting closer for each step.

Until the other day. Nailed it. I think...

Suddenly all the mess sorted itself out and in my mind I could see clearly how all Barely Repeatable Process were following the same four phases. With different time and resource use on each of course, but still the same four phases. Then I implemented those in one single working model. Enter, turn the key and drive off...

For lack of better words I termed the phases Initiate, Mature, Convert and Implement - IMCI.

Then my good friend Adrian went "hey, that reminds me of the OODA loop!". But of course, double duh: OODA - Observe, Orient, Decide and Act, a decision model/method devised by the US Air Force ages ago, also widely known in business.

My feeling of being so amazingly original was replaced with a warm and fuzzy feeling that I must be on the right path given the "prior art".

One thing is different though - I could build a working framework (in Thingamy) for that method / process model that could cover almost every iteration of it's practical use. In other words a generic BRP running engine that could cover most of what humans do in non-automated processes. Operate in one single and efficient framework where a mashup of collaboration software, knowledge and document handling systems, office apps, meetings and email does it's best today.

I promptly named the build BRP One. And it works. Suddenly bumping Thingamy from a platform onto which you had to build your own model to a out-of-the-box product.

Here are the four phases:

Initiate (Observe in OODA):

The trigger, the source of activities, the initiator of what we do.

Observation of changes, new activities by the competition, a request (for a service, consulting, legal help, etc), an idea of any kind, a problem/issue is raised, anything.

Activity triggers in places where you work; consulting firms, in support departments, in R&D, in business strategy departments ("will the merger between Sun and Oracle affect us and what can we do?"), in marketing departments ("our Fiesta model is losing market share") - any and everywhere.

Observe and gather information from the source.
Mature (Orient in OODA):

Sleep on it, discuss it, punt it back and forth - let it mature.

Put the "topics" (idea, issue, request..) in an easily accessible "pool" to allow free discussion and adding of notes, files and suggested "solutions". Allow participants to pick up a "topic" or a suggested "solution", then add comments or requests to it and punt it to some other participant for further and accountable action - "Please do some research on this.." or "Could you check that...?"

Currently the land of "Collaboration Software", email and hour long meetings.

Maturity is reached when possible future paths of action start to gel.
Convert (Decide in OODA):

When a "solution" emerges as the way to go for one or more "topic(s)"; time is ripe to act and implement said "solution".

That's when a "team leader" (Project owner) makes the decision and "converts" a "solution" to a "project" (implementation, research, whatever).
Implement (Act in OODA):

Any single purpose action is a "project"; involving one person or 10,000, a single task or a myriad of tasks and sub-tasks in all kind of sequences. Anything from "buy milk" to "build the largest bridge".

Let the "project owners" (project managers) conduct it all with ease and in full view. Include ad-hoc adding of sub-tasks to own tasks (or any for Owners), add more tasks to Project for Owners, add notes and files to any task or project, change path and rhythm at any time and let it all be transparent and have no glitches.

Now that I have a working framework that covers it all - time to dive back into some more real world work. Interesting times etc.

[P.s. for testers; latest version including the "BRP One" now up in the usual place...]

[UPDATE: BRP One now has it's own little product site.]

Rules

2009-08-26T09:58:52+02:00

A flow requires a framework.

Electricity flows through lines directed by switches. No framework, then no boiled egg for breakfast.

Work in large organisations flows through the organisational structure directed by rules. "If this then do that" is the switch.

If too many fires up their coffee machines at the same time in an unplanned fashion we get outages. If you forget "to complain within 48 hours" about your broken guitar you will not get any compensation. Such worketh the dumb frameworks.

Electrons do not think, so they need a rigid framework. But people think.

People and business deserves better frameworks than those based on rules, budgets, deadlines, meetings and organisational structures.

But that's never mentioned in management training handbooks because "management" is the "science" of work frameworks. Or to put it bluntly; the "science" of rules, budgets, deadlines, meetings and organisational structures.

Make better use of people, make better profits and have a nice day? Start by doubting the concept of "management" and try some other and less ancient framework for people work flows.

[Disclosure: We do make that kind of framework, a modern replacement for rules-, meetings-, budgets-, deadlines type of thing. Add that we think "management is a waste of time" because people are smarter than that, but that's another story.]

Habits inhibits

2009-08-19T10:42:18+02:00

I'm sometimes hitting a small snag when building pilots in Thingamy; actual workflow running engines where work flows seamlessly from person to person while all information and "tools" are delivered with the task:

"This is not how we're used to work! I'm not a farmer or fisherman that follows the weather or other outside instigators of activities! I am in control and like to fire up my apps and seek for information whenever I want - thank you very much. I grudgingly have to accept the "manager" but that's where I set the limit!"

What's referred to is how we've handled "knowledge work" since whenever:

With a new client onboard, a new idea on the table, project or problem to fix we created a folder. Literally, we took a fresh new cardboard folder and using a pen added the name of the client or idea or project to the back of it. The very organised even added colourful cardboard sheets with tabs to it and, using same pen, added names to the tabs.

Then we went about getting things done, choosing a dedicated project manager or client responsible who was the holder of the folder and who called for meetings where things were discussed and work was distributed.

Impertinent side-question: How many "Project Managers" do you think exists? And what actual work beyond doing sheepdog stuff do they do?

Add new technology (IT) and you can speed up everything (but no method change as such) - like the distribution of files (email), keep them all on one virtual table even if you're not in the same place (collaboration software) and avoid dusting blackboard erasers as the planning is now on your screen (project management/planning systems).

A typical individual "intuitive knowledge work process" would look more or less like this:

Sit down at desk, read emails and get a new task or check rss feeder to see if "my files" have been worked on since last.
Fire up some app; Word, Excel or some web based interface to collaboration - open file.
Do your stuff, probably intercepted by a round of search and some coffee.
Wrap it up, save and close "file".
Fire up some other app and summarise, graphicalise and generally prettify what you've done lately into a "report", go to meeting and deliver.
Rinse and repeat until "Project manager" says "huzzah" and offers drinks all around.

Habits feels safe but kills innovation.

In short, habits furthers nothing.

The fallacy of IT productivity tools

2009-07-31T10:41:08+02:00

Good thing we humans are flexible, able as we are to handle all kinds of tasks with sometimes far too little training.

I can often get a lamp to work again, I can paint a door or even grease the hinges without any training. In my early days of summer jobs I worked in a brewery (no training beyond drinking a few), I took apart diesel engines on a ship mid ocean (heavily supervised) and did stints as a substitute teacher (fresh out of pupil training).

I was useful at best, but at least I filled some vacant positions making some manager look good on paper.

This ability to adjust allows organisations to function even if the natural dynamics have long been killed off by artificial hierarchies, when skilled experts have been promoted beyond their ability into management positions or when a proper framework for work flows in reality does not exist.

If organisations had parts like engines and you promoted the exhaust manifold to be a gearbox the result would not be very successful. Luckily the human flywheel can do stints as spark-plug without huge repercussions, but overall effectiveness would be far from excellent.

It allows another disastrous practice to go on without question, a practice that involves IT most of the time:

Focus on individual efficiency instead of organisational effectiveness.

Word processors, spreadsheets, email clients, personal productivity tools of all stripes, all talk about "make better use of data", "simpler search", "better UIs", "faster query times" and rigid rules and automation so one might even skip training altogether. Even the so called "collaboration" stuff is fully focused in the same direction; to allow you to do your job better and handle information better - not much of a proper process framework to be found there either.

Mostly "support" tools are for the individuals, and they do not run anything. MS Project, spreadsheets and whatnot - like toy cars. Nice to look at, good for dreaming and planning but gets you nowhere.

(Hat tip to Adrian for the toy car analogy)

(Spreadsheet functionality)

And don't get me started on "Dashboards", "Data mining", "Business intelligence" and such - all about after-the-fact efforts to get some control over something that's gone awry already - no bearing on real interaction and real-time correct use of parts and resources. Nothing to do with frameworks that, more like sheep dogs running around barking at sheep astray.

(IT Dashboard screen shot, manager at left)

Sure the individual must be efficient, nothing wrong with that. But unless the whole, how the parts work together, what parts are where, direct and dynamic connection between the world and the whole engine and all that which makes the whole a lot more than the sum of the parts - then the individual efficiency has very little impact.

If the interoperability of the parts in the whole is less than good it will kill off the individual efficiency fast and certainly make some parts counter each other out and leave the whole far from what it could have been. If it's good, now then we're talking, then no competitor can beat you.

That leaves the question why do IT vendors focus on individual efficiency while leaving organisational effectiveness untouched. Old habits I suspect.

[UPDATE: The never-in-loss-of-words Seth Godin has a term for this focus on fixing the symptoms instead of fixing the root cause - "Bear shaving"... :-) ]

Increase profits by working less

2009-07-02T12:25:28+02:00

What's taking up most of your working day?

Add up the time spent on the following:

Receiving tasks from superiors
Distributing tasks to subordinates
Discussing these tasks to get more knowledge and clarify
Emailing
Phone and Skype calls
Searching for information
Shuffling paper or looking for paper, documents and forms
Meetings (non-single task meetings)
Budgeting
Fretting over deadlines
Planning work
Updating plans
Reporting
Keeping to-do lists up to date

How many percent of your daily time would that be? 30%? 40%? 50%? 60%?

All of the above have no other purpose than "frameworking" you own (and sometimes other's) work flow. And that's a must, no flow of any kind can exist without a framework even if the framework is as iffy as a to-do list or yourself reminding you to answer some email. Like a river needs a riverbed you and your co-workers need some framework.

What if you had an alternative framework, like Thingamy (that's the essence of what it is, a framework for work flows and any other process), so all of the above Dilbertesque moments disappeared?

Less annoying and more meaningful work might ensue, but if you're a shareholder in a typical services firm (advertising, law, consulting, health) this will happen:

Assuming plentiful work and 20% profit margin your profit would increase as follows when work shifted to value creating work from different levels of time spent on "frameworking":

Time spent on frameworking	Increase in net profits
10%	29.6 %
20%	55.2 %
30%	77.4 %
40%	97.0 %
50%	114.3 %

And that's the annual gain even before you find out that you can change and better your business model!

What's your alternative ROIs by the way?

[Bonus: This would not be the first time, in 1913 Mr. Ford did the same "frameworking" thing for a set of typically Easily Repeatable Processes for the typical ad hoc workshop work by adding a physical framework; the assembly line. In six months they went from 70 man hours per car to 7!]

[30megs.com]

Solutions creates problems

2009-06-25T13:48:55+02:00

Thingamy's first business task is to create problems.

Worse, Thingamy's business is to create problems for the daily work of most people!

Sounds like a rather bad business purpose or what?

Not so, it's more to it:

Solving problems is the foremost driver of new products, services and economic growth. That we're taught.

What nobody teaches you is that you need a solution before a state becomes a problem.

Do you wake up every day thinking "ouch, ouch, I'm going to die one day, must fix that problem!"?

You don't. That you eventually will die from old age has no solution hence is not a problem, just the inevitable fate of being human so enjoy it while it lasts.

Now, straight from the spiritual to the mundane - daily work:

Meetings, phone calls, budget processes, paper shuffling, firing up multiple applications, enter figures, travel - in short all that will bog down you and Dilbert every day. Is this a problem? Not really, just the inevitable nuisance of working in an organisation knowing that the only alternative is to go Bedouin and leave the cubicle farm.

Now add politics to meetings, wrong people at the wrong time on the line, lost papers, bugs to applications and cancelled flights - now we see problems! And of course such problems have solutions; focus on agenda, install CRM, KMS, support desks and conduct online meetings fixes problems.

But the meetings, phone calls etc. are still there taking up most of our days minimising our creative and work output while leaving a somewhat bitter aftertaste of much time lost. But that's as inevitable as death at a ripe old age leaving us to went the frustrations on Twitter and at the water cooler instead.

Enter Thingamy, it offers a real alternative by making much of those time-wasting issues moot.

There's the dilemma - this hugely counterproductive state is not seen as a problem so we have a solution to fate and not a problem!

Luckily there's a way out: Show the solution and the state of things becomes a highly visible problem!

So there we go building business flows disregarding how things are done today, show how it works as a natural flow without much use of meetings, phone calls, lost documents and other issues. Suddenly the inevitable becomes a visible problem that can be solved, not quite on par with an offer of eternal life but still extremely helpful to all.

Hence our initial business is to create problems.

http://30megs.com/

Stop managing

2009-06-16T14:30:07+02:00

If you like the occasional blinding flash of the obvious there's a book out - Management rewired: Why feedback doesn't work and other surprising lessons from the latest brain science by Charles S. Jacobs. Basically takeaway is that the annual performance review is for the birds, and boss pressure is of dubious value. When I was involved in running companies I always found employees telling about their latest work successes and solutions like new algorithms or graphical UIs at lunch. Not bragging to a boss but discussing and getting much ahhs and ooohs from their peers. Peer strokes and peer pressure is good. Simple as that, it's pretty obvious and we know it. But alas most management experts don't for whatever reasons. Another issue is motivation. How come the military see their crew risk life and work long and hard hours? How come small startups have employees working nights and days without complaining? They have simple and clear goals, goals that are easy to understand and for some to get aligned with - purpose and belonging that at the end will entice us to give our utmost. What would be a common denominator for these obvious facts? Transparency. Let your peers see what you do and allow you to see what and why all is happening. Simple, obvious and presumably easy to implement even in a cubicle farm. Except of course, that current enterprise systems and even E 2.0 stuff are designed as tools for specific organisational and process silos. And as we all know, sitting inside a silo hampers transparency big time. So, silos away and let the sun shine on the workers again.