thingamy

SAP Sapphire - Berlin

Yet again my friends at SAP have graciously invited me to one of their huge get-together - aptly named Sapphire. So Sunday I'm off for a few days with notebook in hand.

I'm seriously obliged to our most efficient hosts, Mike and Stacey, as it gives me a huge opportunity to get under the hood of the industry and in particular of course, the leading player in the Enterprise Software field. And it's always a pleasure I might add. A real pleasure.

When arriving Mike and Stacey will have it all organised for us bloggers, of which many are fellow Enterprise Irregulars - the high point being when top management graciously joins us in "fire side chats" for free discourse. Not to forget roaming the halls and mingling with the all-knowing SDN and BPX folks! So Craig and Marilyn, watch out ;)

For me - such openness is a clear sign of a corporate self confidence not often seen!

As always I'll be having a few questions brewing, mostly big picture stuff as my fellow Enterprise Irregulars are amazingly good at unearthing the important tech and marketing questions du jour, so I'll leave that to their able minds. Just take a look at what Dennis, Brian, Charlie, Larry, Sandy, Vinnie, Dan, Susan, Maggie, Jevon, Mark, Josh, Jason C and Jason B wrote already about SAP following the Sapphire in Orlando.

Without saying too much I suspect I'll be poking around for the some answers to what I raised here. And some more.

[Addendum: Vinnie raised a pertinent question here, and Frank has a very good follow-up here. As always I have my own skewed interpretation of the situation (see my comment at Frank's post) that I will pursue in Berlin methinks.]

Will let you know if I make any sense of what I find, or rather the inverse, if my questions makes any sense!

Hitting the wall - the destiny of enterprise software.

A wall named complexity. Overly complex and utterly self-inflicted.

The problem is banal but hard to overcome; it's the wrong choice of modelling method.

That method, thanks to the gentlemen in Venice 514 years ago and ne'er questioned, makes the complexity 100 times, nay, 400 times more complex than reality pure.

In reality a widget is a widget. One object.

Add "distance management" of the widget in a widget producing or consuming organisation and the double-entry bookkeeping monster roars, requiring precise representation of each and every transaction.

Every order, every task, every move, every change of colour or bent ear - all must be properly documented, then entered into the books or system.

In that model each widget is represented by invoices, purchase orders, sales orders, work orders, bills of lading, journals and reports. The widget itself does not "exist". A paper based model that never knew of modern IT.

But it does not have to be like this, we have IT now. Let a singular data-object represent a singular real-object, then capture the what, who and when onto itself. Not "what" as defined by some GAAP, but rather the "what" as in reality - now moved to warehouse B, now painted blue.
Transactions and events can thus be gleaned from changes to relations and properties: A change of the relation "is owned by" is often what legally constitutes a sale or purchase, thus useful for a (P&L say) report. A change to the relation "is located in" is useful to produce inventory reports at any time and so forth without limits. (This is what thingamy does of course, straight reality modelling albeit slightly enhanced.)
Most important result - one data-object only per real-object, simple as in reality. A reality-model.

So, let's do a simple calculation: Say you have 20 objects to handle, 20 real world things and for simplicity, each goes through ten transactions or events. Then relate them all, objects and transactions/events criss-crossing the organisational fabric.

Thus the maximum number of relations* for the two modelling methods pans out to be:

Reality model: 380 relations.
Transaction / event based model: 39'800 relations.

An increase in complexity over real-world complexity of 10'374%. Or about 105 times more complex.

Now do 100 objects each represented by 20 documented transactions and you'll have 403 times the complexity, an increase of 40'203%. That's how to complicate things in an efficient manner!

Of course systems creating such complexity are big and... eh... complex. They have to handle the self-inflicted transaction and event-based complexity. Selber schuld, kein mitleid as the Germans would say.

Use the reality model and you'll have a system that could be 105 times... eh... 403 times... eh... "better"? It might even avoid the wall.

Or...

Reconcile 39'800 relations instead of 380, query ten times more objects.
Handle fully formatted objects instead of raw data and buy more CPU power.
Save thousands times more manipulated data and bloat your DB size and query times freely.
Create processes for modern world corporations following constraints designed in Venice 514 years ago. Duh.

What can I say?

I can say one thing; forget about tweaking the current systems, you'll have to start over again. A car does not become an aeroplane by adding decals on the doors (SaaS anyone?).

* [n!/k!(n-k)!] where k=2 and relations are not symmetrical thus total is twice the number.

No ownership, no accountability - wikis, collaboration software, social media, Enterprise 2.0 and how not to get things done.

The buzz around Enterprise 2.0 / Office 2.0 is palpable, one conference after the other with $ 50 k stands offering yet-another-wiki-version trying to snag the enterprise CTO/CIO.

No wonder that start-up spends the 50k: Web 2.0 and social media relies on advertising for income, something that sounds enticing enough. But world-wide internet advertising (beside Google's 70%) is a mere 6-9 Bn $ annual market while the enterprise IT market is many, many times bigger. Banks alone will spend 390 Bn $ on IT this year. Temptation to redefine your target market is high and re-branding with a few added features ensues.

But the enterprise buyer is sceptical. And calls for "culture changes", or the more pragmatic "change management" does not make pigs fly.

Me? I side with the enterprise buyer, collaboration and social software as such is a good thing, for single task sandbox use. But an overall solution to the unstructured Barely Repeatable Processes in organisations they're not.

It's rather simple:

1. Business is a value chain, a social value chain with a clear purpose.
2. I am a part of a value chain and will have to do my part. For that I need ownership to what I'm supposed to do. Either I do it or somebody else does it.
3. We all need accountability, if somebody else is dependent on what I'm supposed to do I better get down to it. And vice versa.

In social continuous processes, aka the value chains, ownership has to be clear and accountability towards the owner and all that is dependent on my work is a must. That's the reality meeting Web 2.0 when it redefines itself to Enterprise 2.0.

I'm a keen user of "discussion groups", and I do know my wikis. Occasionally a great idea or interesting theme grabs me and I join with enthusiasm hoping we can move it forward. Two days of constant refreshing of my browser most often leave me disappointed, perhaps one or two joins in and fizzling out is the end game. Nobody takes ownership, the idea resides and dies as a communal idea.

Collaboration software is slightly better, create a "ticket" or "task" and assign it - but anybody who has some experience knows that such tend to slip away to the bottom of the list (all soon classified as "critical").
Again the phenomena of not being crucial in an accountable flow, but rather a "pick it up from the sandbox when it suits me" abets the human tendency to postpone and shift focus to something more interesting.

The oldest of all these solutions, the email, is more of the same. And we know it, why else use the cc field as much as we do? An attempt to involve more people than the recipient, make him/her accountable to more people than myself. Problem is that when cc'd, my position in the flow is not a given, I go "ah, now it's in good hands" and promptly forget about it. After all, I'm not the owner of the issue and the value chain is hard to discern.

An open sandbox does not deliver clear ownership nor real accountability - the two value chain requirements. In fact, there's not a whiff of "chain" therein.

Batch processing in a sandbox is useful for single tasks, but when used they must be part of the value chain, the whole workflow.

The only social value chain framework existing today; the organisational hierarchy, is in all senses counter to the philosophy of the open sandbox thus the current clash between old and new. Given that a new value chain framework is not delivered by the Enterprise 2.0 stuff, the enterprisey buyers will remain sceptical. And rightly so in my humble view.

But do not give up on the single task sandboxes, they're basically excellent. Focus instead on the search for a new value chain framework that befits them instead of trying to merge two mutually exclusive philosophies and incompatible methods.

ideas, problems, broken arms - social objects

Thanks goes to Tony C for the inspiration:

Business and organisations are social groups with a value creation purpose.

The value creation happens to tangible or virtual objects, from widgets and bikes to concepts and broken arms.

Sometimes it happens in very linear processes like when a car is built. The classic ERP value chain.

Sometimes it happens in more haphazard manners like when an idea metamorphoses into a film or a medical condition becomes cured. The typical BRP value chain.

Now, the last kind, the BRP value chain: It always involves people, in organisations or network of business, suppliers and advisors and the value chain is a collaboration, a social process. And most often it involves virtual objects like ideas, problems or medical conditions.

Solving a problem is often an effort to create a collective mental model and take it from there. The problem is socialised.

Thus the idea, a problem or a broken arm becomes a Social Object.

And problem solving, idea generation or curing sickness becomes a social value chain.

But the social object requires a conduit so it can move efficiently around, and the value chain requires a framework for it to efficiently fulfil it's purpose. That of course is where thingamy excels [blatantly tooting our own horn, but so what :)].

transactions, accounting, bah humbug

In these tax return days, please raise your hands all who love accounting. Anybody?

Accounting - double-entry bookkeeping - transactions. Basically unchanged since 1494.

Did they have computers in 1494?

So why do we keep doing it the same way the Venetians did it?

The double-entry bookkeeping has one requirement: Register transactions.

When your product changes owner it's deemed to be a transaction. No, hang on, not always, you have differing rules there, from country to country, from year to year. So what you register as a transaction one year may not be a transaction the next. A moving target indeed.

In practice we try our best to reflect the transaction by a an invoice, a contract, a bill of transport or a receipt of delivery. Then that travels to the accounting department who's main purpose is to make educated guesses as to what bill, receipt or invoice best reflects what the tax authorities rules as that particular transaction in section 93, part 3, clause 34.

Next year clause 34 is amended and comparing last year's results with this year is like comparing apples and bananas.

In reality most of "how we do things" in business is a direct result of the 514 year old accounting method. It created the invoice, the bill-of-whatever, the report - no other need for such massive resource wasting documents and reporting requirements.

Then you have Enterprise Software, the stuff that has made the world's best and brightest production and retail companies amazingly efficient. Guess what principles these are built on. Yep, transactions. 514 year old methods nicely translated into efficient code. Not to mention the invoices, bills-ofs, documents and forms, yech.

Is that fair to the code? Is that really smart at all?

The thing is - I do not disagree with the concept, I merely disagree with how it's done, i.e. accounting as in methodology:

Today: You make up your mind as to what report or activity that best matches the current and local rules, then register that as a "transaction". Then you make best use of that piece of manipulated data, raw data with somebody's logic stuck to it. Any changes at a later date requires unsticking the transaction, reapply a different logic (rule) and stick it back into the system.

As a result you end up comparing apples with bananas, reconciliation bloating your OH and days, weeks or even months gaps between reality and reporting of that reality. (Nice way to architect a management control system eh? Drive a car by proxy.)

Tomorrow: Register what really happens when it happens, not the transaction but what really, really happens: Widget is created, widget is painted red, widget changes owner, widget leaves our warehouse. These activities are direct results of tasks, again results of work orders and all such can be captured. If your Enterprise Software is meant for that first and foremost (and not to exist in order to register transactions), well then you have the raw data onto which you can apply some logic in the form of templates at the back end: One for UK GAAP, one for German GAAP, one for last year's rules, one for this year's rules.

As a result you have only apples or only bananas, no reconciliation and real reports in real time. Drive with direct steering.

First step to better business, better use or resources, a greener world, better profits and more time for the family is - well, rather simple: Disentangle us from the 514 year old methods!

Good riddance to accounting as we know it. It will happen.

problem solving app in 17 minutes

When the phone rings, when an e-mail arrives - how often is it an issue that needs solving?

Can you count how many times that happens in a week?

Any idea how often you forget to follow up?

And can you tell me, honest now, you remember ten months later how you solved that particular problem?

Or, do you have an inkling how your co-workers solved a similar problem last week?

For some industries all of the above is their core value adding process - consulting, health - for the rest it's a daily nuisance.

The classic and omnipresent Barely Repeatable Process that can be given a proper framework to ensure accountability (nobody can blame bouncing e-mails) and knowledge increase from every step done (capture the data by the task itself).

Built a simple and generic one in thingamy captured on video here. Took me 17 minutes to build. Including testing.

Nothing fancy of course, and tweaking it to something useful for a specific organisation would take a few minutes more...

SAP's R&D - asking the right questions

Dennis posted some thoughts on SAP's new co-CEO and their R&D plans.

"Apotheker also confirmed that 2008 is the peak year for SAP R&D investments and that over the coming years, SAP will scale back its investments by around one percent per annum."

then Dennis adds to the equation:

"I’ve said before but it is worth repeating: profit levels for SAP, Microsoft and Oracle are at extraordinarily high levels, reflecting a maturing industry."

Now this is interesting, and I do agree with Dennis' take, but it's the "maturing industry" part I react to:

For the logic to hold it's obvious the "industry" have to be defined as the current "technology". Going from X.1 to version X.2 does not much to your bottom line I would imagine. Tweaking the already well-working HCM or CRM system ditto.

But the market has been barely touched if you think "run your business" overall. We still use email, have meetings, have paper based business rules - and without doubt waste a lot of resources and time thanks to a long accepted "control & steering mechanism" named double-entry accounting. A mechanism that not only is 514 years old and barely untouched, but as anybody knows, is very far from perfection as an "instrument panel" for the organisation.

So why scale back R&D?

My guess is that the issue lies in the high-level questions of "what's our business".

If it's "ERP", well then, time to milk the cow.

If it's "run-your-business" they have barely started.

So, good folks in Walldorf, what's the answer? Are you in the windmill or power generation business?

Thingamy fun...

Days away from a pre-beta (or whatever one might call such) that is much changed - bye to tags, hello to relationships, point-of-time and time-period for numerical reports, refurbished Ajax and much, much more.

Under the skin we have quite a few features lurking and more can be added in a day or so - but we'll wait with that until we're really sure we'll need whatever. Better to keep it simple.

With a quiet weekend on my hand I just had to redo the demo video in the new version and a couple of new yada yada videos on events versus objects and new accounting as well as adding new screenshots. All over at thingamy.com.

Just have to...

...more or less sums up my goals.

I'm so in agreement with Robert Scoble when he takes issue with Mike Arrington's goal: To beat CNET.

"Beating" someone never really worked as a strategy, it's merely a tactic in the heat of a battle.

As a student I read Erich Fromm's "To have or to be?", and it's still amongst my favourites. In essence: "Be" in the process when walking up the mountain, enjoy every step, focus on making every step a pleasure and as efficient as possible. If standing on the peak (to have) is your only source of pleasure, well, not much energy goes into the process and the pleasure will be short-lived.

That's why getting a new car is a pleasure for a day. That's why golfers spend hours and hours hacking away even after they reached 15, 10 or 2 in handicap. That's why I focus on and enjoy every turn on the pedal, and any cyclist will back me when I say the moment you start looking at the Kms left in a race you loose:

When asked why I do thingamy I cannot but say: Just because I can. Because it's important. Because it's difficult. And it gets me out of bed every morning with a smile on my face. Best is that I see no peak; not when finished, not with next version, not when many uses it, not when everybody uses it, there will always be lot of room to make it, the use and the life for the user better every day. Discovery to be found around every bend. Goodness.

at last

Seems it has dawned upon the VCs that yet another social network might not be the thing.

And when two "Facebook widget applications" (heh, a category by itself) startups are valued at substantially more than Bear Stearns, well, how can you avoid being hit by a blinding flash of the obvious: Something is not quite right.

Still, the reason for the VCs getting cold feet seems to me to be for the wrong reasons. Mind you a good reason but not what I would see as the major reason.

The argument is that there is a consumer fatigue out there, how many times are we to recreate our social networks for another new and shiny place? How many places are we to go, how many apps and browser windows do we have to refresh to hear the same messages from the same friends? I'm a victim of the fatigue for sure.

But what about the good old "how to earn money" - slow, fast or no growth in users - in my view kind of the most important aspect.

And they're all based on advertising, albeit with creative tweaks to exactly how, all touted as completely new and promising. Still the same source, internet advertising.

There are a few numbers around for the grand total spend on internet advertising world wide - I've seen 20 Bn $ up to 37 Bn. But whichever way you see it, it's a sum where you simply can deduct 70%, as that's what Google takes. Rest to be shared among all the Facebooks, Myspaces, Twitters, and... and 300 Mill $ valued Facebook apps.

Come on dear VCs, what about a bit of simple arithmetics? This simply does not add up.

creativity, competition and strategy

Good quotes often come from unexpected sources. Yesterday one of my sons came home with a sheet setting out the teaching philosophy of his drum instructor, in which I found the following gem about the importance of passion:

"And with passion comes creativity. When we create, we have no competition. We need not worry about someone being better than us, only different."

From percussion to business; allow me to add how Michael Porter conveys a definition of strategy:

"What value are you to deliver to what customers and how are you going to be different."

For those concerned about this 'forget about competing' attitude allow me to suggest that:

"The best way to beat your competition is to make them irrelevant."

There is no way around 'being different' - the core of creativity, an unavoidable part of business strategy and the source of success in a competitive market.

Creativity has to start at the top, and not so much by focus on the usual 'how to create a creative organisation'. The leaders must be extremely creative themselves and dare to be different.

Go and be different.

thanks!

Must say I am pleased when I hear the terms BRP (Barely Repeatable Processes) and Easily Repeatable Processes (ERP) being used by people I never met.

In December I wrote a post defining the terms and it did hit a soft spot it seems.

Now I hear almost every week about some speaker at a conference or big company leader using the term - that pleases me no end. So here's a thank to you all!

There is no doubt that the issue is felt out there, after all we do spend much (most?) of our time handling exceptions, ad-hoc stuff, starting with a call or email and handled by meetings and a lot of back and forth in rather unorganised manners.

And yes, social software, collaboration software is a way to go - also seen as the focus among large business software vendors trying to address the pains felt by the "knowledge worker" - but:

Everything is a process. Everything happens in sequence. When you and I discuss we listen then counter, then listens, then...

Process is important - without understanding the process no progress can be made. If you do not know the path you cannot run faster next time. A ski instructor will not give you advice when in the bar he will need to see you on the slope before he can help you becoming better.

One argument I hear is that knowledge work, creative work, would be hampered by structure - thus finding social software and collaboration solutions like wikis the perfect way to go. Every step should be open for unlimited new path choices.

To that I do agree, to a certain extent: We're talking about getting-something-done not entertainment which means there is a purpose. That is the actual reason for organising into groups, clubs, governments and business. A business or hospital or educational institution have a purpose, and that limits the choices. A purpose is a framework.

A physician would not send you trekking in the Andes as result of studying an x-ray of your broken arm. A board member would not blurt out "lets stage a musical!". And you would not choose a forum for vintage race cars when having an issue with your Vista driver for your Epson printer.

I see all too much jumping. "Jumping to conclusions" that is when the word "process" is used - most visualise something linear and rigid, a pipeline with no leeway. But at it's core, process is not at all that, it's purpose and path:

When it's raining in the mountains the water finds the way to the ocean one way or the other, hard to predict and even harder to follow, but one day it'll find it's salty brethren driven by a strong and simple purpose - go with the flow, let gravitation be the driving force. And the water does that, a single drop teams up with another, then another, soon being big enough to become a trickle down the mountain surface meeting other trickles merging into a small brook, then finding other brooks to become a river that has the power to move obstacles making for an even more efficient flow towards the ocean.

That's what it's all about - a clear purpose and a riverbed framework. Rainwater or business, raindrops or people, same situation, same solution.

A riverbed framework; and BRP will become a force and cease to be an issue.

stop organising, please

Organising, or rather the reason for organising - finding stuff - is the focus and raison d'être for much software development: From search - finding stuff in huge heaps of more stuff, accounting - organise by event, to collaboration software - keep stuff somewhere where all will find it and can work on it.

So give this a thought: It's barking up the wrong tree(structure), it's counterproductive.

Well almost.

Look around you where you are just now. I have my desk in a corner of our living room where there are two sofas, opposite each other, two very comfy chairs, paintings on the walls, books in bookshelves and a plethora of little things residing on countertops, tables and on the footstool.

Nothing is organised in rows or columns, nothing is labelled nor tagged - still it all makes perfect sense and I'm never in doubt where to find what I need when I need it.

The location of all the little and slightly bigger things have a meaning - they're where they are for a reason, not to follow a strict system, plainly how the things are used; where it's good to sit to watch the television, where one might find a quiet spot out of traffic with good light for a quiet moment of reading. Everything relates to something else because each thing is unique and have a purpose. Things have a meaning.

Now do a mind experiment. Say you brought in your three shoe boxes of pictures that never found their way into an album. Now empty the boxes onto the floor and see if you can find the picture of your son and yourself from summer 2003 when he was horse riding for the first time.
Not easy. Not a fluid search about to happen while you shuffle through the heap, turning over those which came face down in the kerfuffle.

What's the difference?

1. The physical things around you are singular, unique and have a purpose as in relationship with some other physical thing or activity.
2. Your pictures or documents are not singular, they each represent many objects, activities and situations. They're narrative in form and as such will have a whole range of meanings and relationships. And with that no natural place nor connection. They need organising. We think.

Every day we read about new ways, better ways sometimes, to organise such narrative objects - new and interesting search algorithms, newfangled taxonomies, semantic webs, artificial intelligence or efficient hierarchies. Not to forget tagging and other ways to add labels or meaning - all dependent on the system constructor's logic as well as the understanding of the user, in other words a clearly set system followed by well-trained users.

All well meant and seemingly important so we can make better use of knowledge amassed by others - a never ending quest for humanity.

But why this narrow focus on only one of the parameters of the equation?

Information Usefulness = ƒ(Information Format, Distribution)
and Distribution = ƒ(Capture, Availability, Assimilation)

And as we know - all focus is on "Availability" as in how to organise and find. If not organised search is the last resort. Add tags, categories and labels and some organising helps the last resort search. Add hierarchies and we reach the tipping point where training and understanding of the rules are required.

I do not really understand why this focus and complete blindness for the three other parameters. But of course, we've learned that "organising is the right and good way to manage life and it's components". A culture thing I suppose.

Forget that, unlearn that, think living room instead of shoe boxes full of pictures, think in "what" form we capture and keep information and how it can help the issues of Availability and Assimilation of knowledge.

Step 1: Instead of mashed up information bearers, cut them into singular representations all linked with meaningful relationships. Just like my sofa.

But hang on a sec, what about the "well almost" in the start you might ask.

Stories - on paper bound by cardboard, on newsprint or in electronic form, on canvas or sculpted from marble or etched into celluloid - those are not made for "cutting up into unique pieces bound by relationships". Or are they?

Are art galleries organised? Last time at the Guggenheim, were the paintings organised by size? By year painted? Not always so. Are the theatres grouped by what kind of plays they do? 

In other words - information comes in two forms - narrative or direct representation; content of a good book or some data representing a widget in the warehouse.

What happens is that we're interested in the timeline as well as the actual facts, what happened to that widget. And when. The solution when we only had paper was "write a story" as the narrative delivers the timeline.

And there we are, factual data represented in narratives, the ubiquitous documents.

Step 2: Enable the information bearers, the unique representation of reality to capture and hold the timeline, the process, as well.

Then we're in control of the other parameters of the equation - a must if we want to create more value using less resources and in general better our life.

And we have to start with the first parameter: Format, then proceed with the second: Capture - then Availability and Assimilation will follow.

We just might have to learn that what we learned can be unlearned for even better results.

[Wee bonus: Charlotte did some organising, Thomas was bemused - excellent!]

Hugh's hat

Just had to - fresh from Skype chat:

DID or PID

Business is social - gather a group of good people for a purpose. Let information flow uninterrupted amongst the participants wherever and whoever they are, that is the requirement for the most efficient creation and delivery of value.

Enter Social Software - perfectly aligned for that quest, efficient distribution of information in the format we currently keep it:

Narrative and post-event format (aka forms and documents), manipulated facts still posing as "information" for good or bad. Manipulated facts, dubious information.

In other words:

Social Media is Dubious Information Distribution - DID

We need Precise Information Distribution - PID

Distribute the facts separate from the logic, then slap logic to the facts - your own or that of others if found viable.

Note that "Distribution" is the same, that is not the crux, it's the information format. Facts and logic are two separate parts - keep them that way. Then manipulate when needed.

Clarification: Do not think the very structured and "precise" methods and systems are any better at it - accounting is DID as well. Somebody applied personal logic when deciding what account an item was assigned to.

[Nod goes to JP, Balaji and Alan for inspiration :)]

Social Software - a twitter moment

on a sunny Thursday.

James Governor spurred a 140 char restricted discussion by mentioning some (preposterous?) claims by JBoss about their future marketshare for Enterprise Middleware. Ric picked up the ball and I piped in.

aqualung: @monkchips in 2015 there will be a crapload of middleware workload ... 50% could be a staggering number - beyond JBoss scale?

sig @aqualung Or there will be little middleware... that depends on keeping or not the "workshoppish" nature of the app based architecture..

aqualung @sig I lean the other way - I think it will ALL be "middleware" ... but connecting people rather than apps

sig @aqualung think we say the same - but that would be a new definition for "middle", like that

sig @aqualung If you saw my last post, I'm into "social software" - connecting people, organising the connections... same as you say I suspect

sig @aqualung Thus the middleware of the future will be entirely something different and today's players not the future ones, or what?

aqualung @sig Yes - I see "middleware" as what carries the connections and enables the relationships (WWW as the ultimate "middleware"?)

aqualung @sig and I think the future middleware, although different, will be recognisable; but the players? Open season has begun!

sig @aqualung Add the purpose of the organisation (social) you need to add "workflow" to the "relationships" and you have "enterprise"

sig @aqualung The definition of "social software" is wide enough, the current understanding of what it can be is too narrow though

aqualung @sig it could be argued that our current understanding of anything will be proved too narrow ;-0

I think we're onto something there - social software is what it's all about - in particular in the BRP space where knowledge workers are all dependent on fast and efficient connections with their fellow knowledge workers, obviously in such a way that the ongoing is captured for future use.

Now when I bring up the need for a framework for such creative work I get frowns - we've found after all that letting the brain loose is conductive for creative work. While restrictions are counterproductive in a wholesale fashion.

Yes and no I say. The moment the social group has a purpose (like delivering a service or a product or a value), limits and flows have been introduced. And with the slightest set of limits or need for flows a framework is required. Then from the purpose comes a strategy, from the strategy comes goals - each steps that could make good use of a process framework without messing with the creative freedom.

That day social software will be truly enterprisey and the non-social apps oriented enterprise software a thing of the past.

thingamy is social software, duh

When using the term "enterprise software" about thingamy I am met with much blank stares and urges to change theme - enterprise is boring...

As said earlier - "boring is good" as it attract much less fluff as in money-willing-to-be-lost and fifteen competitors a week after you've launched a new service.

Looking at VC portfolios I cannot but shake my head - "how on earth do they think me-too products can yield the highest reward-to-risk ratio?". A mystery no less. Or a different economics professor than the ones I've listened to.

Add the size of the market being bigger by a double digit factor - and enterprise software seems to be a good place to be even when it never gets any "oohs or ahhs".

Quite a few started-in-consumer software firms have found out and are hard at making an effort to enter the enterprise market, typically among the "social software" crowd. And who can blame them? Not much willingness to pay for services coupled with a online advertising market about 1/20th of what banks alone will spend on IT this year, and where Google have like 77% of the market - that is tough. While at the same time, enterprise is social per definition.

Social software is thus interesting, so allow me throw out a few traits often used to define it:

• Allow users to interact and share data with other users.
• Social technologies or Conversational technologies used in organisations.
• Web-based.
• Knowledge creation and storage that is carried out through collaborative writing.
• Conversational technologies seen as tools to support work units and the individual knowledge worker.
• They create actual communities.

One particular paragraph that interests me in the Wikipedia entry is:

"Communities formed by "bottom-up" processes are often contrasted to the less vibrant collectivities formed by "top-down" software, in which users' roles are determined by an external authority and circumscribed by rigidly conceived software mechanisms (such as access rights). Given small differences in policies, very similar software can produce radically different social outcomes."

Precisely!

That's almost like defining the difference between ERP and BRP - where the last actually requires less rigid policies, the typical situation for the knowledge worker. Every step in a Barely Repeatable process has to be "free" in the sense of having a waste number of choices leaving the operator freedom to judge earlier results and choose next step from there. Passing the bucket kind of process; "Hmm, no sign of fracture in this Xray, time for a blood test." - but within limits of course, the MD would not suggest "...time to change mufflers". As enterprises have a purpose they will have some underlying structure, obviously.

This is precisely what the thingamy is good at, all of the above, including adding a snippet of structure - as little or as much as you want - tweak those policies to have radically better results.

Hmm, thingamy is in fact "Social software"... and solidly so.

• It needs no hierarchy nor any rules or policies (but you can have them if you must).
• It connects people when things needs to be done.
• It goes beyond sharing of data, it moves the data you want to have moved to the people you want at the time you want.
• It allows any kind of transparency.
• It captures all that happens and increases knowledge by every thing done. Nothing is lost.
• It automates the boring stuff like reports - that can be generated automagically from real activities.
• Web-based, check. Tweakable and changeable at any time, check. Social, yah.

Wonder if my focus is too narrow on the enterprise space, perhaps there is a consumer play hidden therein as well? Could it even enhance my social interactions with non-enterprisey folks? Time for some reverse idea-engineering for the fun of it? (Don't think there's any money in it though - but could be fun, good for learning, straddle the divide, sneak in backdoors, etc.)

But on the other hand, conceptually, better to be the enterprise Social software with the by far deepest well of features than being the simple (on the surface) Enterprise software that still have not produced a chocolate bar ever, not to talk about a million per hour that some of my bigger competitors can brag about.

Food for thought on a Tuesday morning... ah well, back to reality and testing semantic process engines and other radical goodies!

sea, sailing and selling

22 years ago I met Lars for the first time. He's big, solid and Swedish - and if you've ever read Pippi Longstocking he would definitely remind you of (a young version of) Pippi's father, the seafarer and cannibal king. Although I don't think neither Ephraim nor Lars were into cannibalism.

Pippi's father, eh, Lars, left, owner hanging from boom like a monkey on the right, assorted deckhands in the middle

Lars and his at that time girlfriend, Robbie, were hired as crew on my boat, a Swan 59, build number 8 (current Thingamy build is 2.2.12 I think...) a white beauty named "Sassy" built up north in Finland (my third Swan no less).

For three years Lars ran the boat with deft professionalism and Robbie ruled the galley while Lars' nephew Lennart inhabited the forepeak and oiled winches when he was not making the best piña colada ever (a dash of bananas I think it was).

Antigua race week, 21 cases of Heineken consumed on first race day, owner sitting in shade

We even had our "own" chauffeur in English Harbour in Antigua, Jim, who normally ran one of the taxis. His son was a member of the local soccer team where Lars and Lennart joined in during the winter charter season. Myself I was limited to sponsoring the team uniform, numbered garments that were collected after each game to avoid too much wear and tear during the rest of the week.

Our team in baby blue sponsored team suits

Good times indeed. But every phase in life has an end so in 1988 I sold the yacht and Lars and I opened a yacht brokerage in Antibes, the yacht centre in Europe, and the world for that matter.

BCR Yachts

Since then Lars has run and built that business with the same diligence and professionalism as he ran the boat - I was merely the passenger and intermittent supporter as before. [The Fenderkicker blog is here by the way.]

One year ago time was ripe for yet another change as Lars moved on to New Zealand (his wife is Kiwi) but still keeping a keen eye on the operations up here.

And with that we felt an increased interest in our business among potential acquirers. Not only has the business been profitable for almost twenty years, it has a very good reputation and extremely capable people while being one of the few, if not the only mid sized yacht broker in this area not yet gobbled up by the big operators. In other word a perfect target.

The combination of having an interesting asset on our hands, a decision to move on and a need to shore up my wine budget (already under undue pressure from thingamy development) simply made us open the doors.

So now we're in multiple discussions, and if none of the current crop pans out we'll allow others to enter the fringe - we're sellers now. Just mail me if you want to enter the yacht business... ;)

A very good time it has been, but life goes on, and our co-workers deserve owners/partners with a more forward-looking yacht focus as I have shifted my focus ever so slightly to less salty business areas.

Bars and Business - social objects and business objects

Hugh's post on social objects the other day resonated with many, and I still remember Jyri bouncing a beach ball around at Reboot a couple of years ago.

Allow me to quote Hugh reporting from a social setting:

"Increasingly I've been using a term, "Social Marker" to describe a certain type of Social Object. I've found it especially useful for explaining certain ideas to marketing folk.

When two people meet, the first thing they try to do is place each other in context. A social context. So they insert some hints into the conversation:

"I used to know your Uncle Bob."
"I work at Saatchi & Saatchi's.
"I've been reading Malcolm Gladwell for years."
"I'm a member of Soho House."
"I was reading Doc Searls' blog the other day."
"I was college roommates with your ex-girlfriend."
"You're a Red Sox fan too?""

Social objects - the stuff that connects us, objects that spurs a common interest, the nodes in the social fabric. Not to forget basic knowledge about each other as expressed by relationships to known objects.

With some common nodes connected the social flow can start - discussions, much nodding and trust between the bar patrons is established with the knowledge yielding a feel-good sense of connection while downing another beer.

Allow me to quote myself from a less frivolous setting:

"When a patient arrives at the hospital, the first thing the physician tries to do is to unearth the main "business object", the medical condition. So he inserts some questions in the conversation, exploring (in this context) "business markers":

"Where does it hurt?"
"When did it happen?"
"What did you do when it happened?"
"Have this happened before?"
"Who's your physician?""

Soon he will be on track to establish what the issue is, or issues are; the main "business object(s)" in their "business" relationship, the thing that he as an expert might add value to by curing it.

When the first connecting nodes are found the value creation flow starts - medication, X-rays, tests - leading to the establishment of a core "business object", the medical condition. With that the physician can go about and create value by manipulating that object, curing it through surgery, plastering and medication.

Now, let's expand that to a more "commercial" business proposition - a sales situation. Let's follow two kind of sales people on a sales call for, say, enterprise software:

Sales person 1: Straight into presentation of product, pushing brochures over the table while pouring out a well-learned sales pitch.

Sales person 2: Asks questions - "could you please describe your business?", "any areas that does not work perfectly?", "any daily issues that annoy you?", "could you tell me a user story?" - quite the physician looking for that particular node where he and his expertise connects with the customer.

Would Hugh's bar patron go off on a rant about his excellent career or name drop or brag about his cars and boats and houses? Yep, some would - the social version of sales person type 1. The bar bores. "Sorry, have an appointment in five...".

The one - it be bar patron or sales person, social setting or business setting - that seeks out the markers to find the core connecting nodes will win. Every time. Same thing for business and social life - explore the social or business objects and find the node(s) that connect!

It's what Seth Godin always says about sales - you have to establish a relationship first! Quite, but not quite:

The relationship have to connect through the relevant business object(s) - a patient and physician connecting by a common support for Arsenal would not mend a broken arm.

business and a boring brain-dump

Been quiet for awhile, but busy!

A bit of this and a bit of that - some business stuff (buyers prowling around one of my investments) and some tech stuff - thingamy being a part of the tech stuff obviously. Quite into the practical side of all the theorising now - but that's pretty much darned fun I must say!

A few months ago I had a sudden blinding flash of the obvious where we dump categorising altogether, replacing it with nothing but relationships between our dear singular objects.

So if you're an enterprise systems geek or plain how-to-get-daily-work-done in a proper fashion inclined here's a small brain-dump. Perhaps a bit boring, but as mentioned, just bridging here :)

When I started to see the new thingamy fork taking shape, user stories gathered over the last year suddenly come back to me as I start building models to reflect reality.

Today I'm thinking of a certain IT department that had a hard time keeping tabs on servers when stuff was replaced. The physical entities and the server function/position were not separate in their current system so they knew "where" but not always "what" historically. In addition it was sometimes hard to spot how a change somewhere (changing a router say) could affect a service - would it constrict the traffic? Not to talk about a sudden problem and the obvious question - "anything happened lately that could have an impact on the system?".
Remember the shutdown at LAX last summer? Well here's this morning's stab to solve such.

In our new and shiny version I would go about it this way (roughly of course):

1. Create the things (classes) I handle and from which we create specific instances (objects). And I would not limit it to physical objects like servers, network cards, printers, routers, people and such, I would also include stuff like software instances (each software install would be a unique instance or object of the class "software") and places (where the server or the router actually resides) and so forth without limits. Perhaps even "issues" and "purpose" objects if I find such useful. No rules here, just do it and clean up later.

2. Then create the basis for relationships between all the objects; in our case that requires only the predicators (verb phrases) and their inverse values - subjects and objects are already in the system. Like "server-object, runs, software-instance" with inverse predicator "runs on" and "software-instance, requires, software-instance" and the inverse "is required by" and so forth.
Moving a box somewhere would not change the properties of that data-object (as it would not for the real-world-object either), you merely altered the relationships to place, software instances, sysadmin and so forth.

3. Add the natural flows which involves said systems and hardware - procurement would be one, installing and upgrading software another, maintenance a third. Then give those workflows a rethink and sew them together using questions like - what is the optimal maintenance program? What triggers a purchase?

4. Create the report templates - or rather pre-set queries like "list all routers that delivers traffic to servers that has an instance of software Y running" and such.

That way all bits and pieces, software instances, electric hubs, sysadms and suppliers can be related to each other in any relevant way opening up for dependencies to be clearly seen at all times. Just think of a problem with the performance of a server based system - "please list all hardware related to this system in xxx ways either directly or indirectly and narrow down to yyy issues - and list the last change to any of these as well as all details on maintenance and who did that".

And that was only this morning, expecting more ideas to be built shortly. This is fun indeed!

P.s. Did I mention that it could deliver all kinds of numerical reports as well - from power requirements to costs - up front or as in accounting?

P.p.s. Can add that the interfaces are undergoing some radical rebuilding as well. Simple-as-can-be on top, seriously deep underneath. Then we'll simplify again. Rinse and repeat.

Tagged, argh...

Been keeping head down and hoping to avoid being tagged, but Jeff has a keen eye for cowardly dodgers so here I go.

But hey, if every tagged person takes at most half a day to write and tag on - and Jeff was the first one (and he's not) we'd have 134 million tag-posts by Wednesday next week. So somebody must be cheating, and I'll do my best so as not to swamp the sphere - herewith officially not tagging any! ;)

OK, here goes:

1. Only profession I always regret not having tried - ballet dancer. (But don't tell anybody, could be misunderstood, but really, I love ballet.)

2. Done the Lauberhorn strecke in a downhill race (not World Cup though). Came 10th I think, but I do remember that the red skis where only a vague blur underneath. Scary but fun.

3. Tried to do a LBO of the family firm (I was third generation) when I was 29 without telling my father who was the CEO. When over the shock he accepted the offer with a grunt, turned in the door, and left for a long vacation. But aunts, cousins and uncles did not want to sell to "their sister-in-law's son" despite me having breakfast, lunch and dinners with them all for two weeks, and giving a better offer than the competition that they drummed up. A straw man would have been the thing.

4. When 17 and working as a "engine boy" on a freighter I went inside the oil sump of a ships engine knee-and-arm-deep in the gooey stuff hanging by one arm around the crankshaft rummaging around for lost tools. I was given a half day off for that. And yes, I found enough tools to fill a toolbox down there.

5. Every time I get reasonably good at a sport I pick up another - love the learning curve. But the attic is rather full of stuff, anybody in the market for nine Hardy fly fishing rods or a row of golfbags? Current activities are alpine touring (ski), cycling and orienteering (last two competing). Ask me next year for an update of what's new.

6. Studied in Zurich due to the fact that I took a right instead of left on the motorway between Bern and Basel on a Friday and ended up with some friends partying all weekend. Stayed for six years. My mother waited for me on the ferry landing in Oslo every morning for a week until she heard from some mother of a friend that I stayed behind in Zurich. (Hope my sons will treat me better though!)

7. Tried once to buy up some snuff manufacturers in northern England, almost became a member of the UK Snuff Manufacturers Association. But alas, the owner's sole interests were walking the moors and playing bridge so they could not see any use of ready cash. Rubber wellies are still cheap.

8. Was thrown out of high school for being overly lazy and generally useless. Did my exams with good results on time anyway thanks to self study and renewed interest in studying. Smart chaps those teachers that threw me out, that was what the doctor ordered.

Bonus 9. Have a huge weakness; bags, suitcases, whatever travel goods, cannot buy enough of that. Obviously tried to do a LBO on a good old British bag manufacturer once too.

sexy or boring - investing in the software industry

If you're an investor, there are two basic industry traits that you should look for:

1. Big market
2. Boring

Boring?

I've been an investor in many business, of which some have been of the oh-so-cool kind: Yachting, sports equipment, fashion, electronic games...

And then I've been involved in the bugger-how-boring kind: Pulp and paper, cans (yep, the fish and paint containers)...

From my many years in business I learned one thing about this dichotomy:

Cool and sexy industries attracts a steady flow of new entries, players and investors. A kind of margin influx of money that is willing to be lost and people that are in it for the wrong reason. That makes it extremely hard to earn money, if anything at all.

Boring industries are the completely opposite, the people involved stays and know what they do, the influx of new entries and money is at most a trickle. Margins are stable.

So if you want to earn money, find a boring industry!

And now I'm in software. There you have two kinds:

Consumer software: The cool and sexy stuff, especially anything web based and 2.0'ish.

Enterprise software: The boring stuff nobody sees nor gets you anywhere when striking up a conversation at a cocktail party.

Consumer software is big, but not that big. Online advertising, the income that has to be shared among the most sexy ones like Google, new media and Web 2.0 kind of stuff is approximately 20 Bn $ per year. For an indication about the rest of the consumer software market ask yourself, how much did you spend last five years on non-professional, pure consumer software (not games mind you!)?

Banks will spend about 390 Bn $ on IT next year. Banks only. Enterprisey that.
[Thanks to Dennis for the figures]

In sum:

Consumer software
Is a smallish market, has a steady influx of new entries and willing money to ensure ruined margins (work a VC packed drinks party and you'll get the drift). But that cute long legged lady at the last cocktail party was really impressed.

Enterprise software
Huge compared to consumer market, has a very restricted flow of new entries to rock the boat nor the margins much. But you need a make pretend answer to "what are you doing" when partying.

Would suggest "ski bum" to impress socially and enterprise software to impress financially. With one exception; if you're to see a VC next week, refocus your enterprise stuff to the consumer section and do not forget the colour scheme and Ajax while you're at it!

One would think that investing in enterprise software is a no-brainer, but not so, seems one actually needs brains to make no-brainer decisions. Lets hope it stays that way. Stop the calls for making enterprise software sexy, leave us alone, and bugger my lack-of-investor-interest motivated string budget.

Blink, rapid cognition, Categories and Relationships

Being out of fresh reading material over the holidays I picked up some previous read books from the bookshelves - one of which was "Blink" by Malcolm Gladwell.

Must say second-time-over-reading has it's positives - you know when you're in a boring or not so interesting part so you can happily fast-forward.

Following my recent post on Categories vs. Relationships I guess my mind was skewed when I hit a good story on some strawberry jam testing experiments:

In short, from the book - a group of food experts ranked 44 types using their usual arsenal of specific measurements like texture and taste. Taste of course split into many subcategories. Texture could be "adhesive to lips, firmness, denseness, slipperiness" and so forth. Each of those again getting a number from 1 to 15. Pretty complex, but we're talking about people with long experience and a second nature of how slippery a jam is.

Then they simplified and took the first-, eleventh-, twenty-fourth-, thirty-second-, and forty-forth-ranking jams and gave them to a group of college students. And lo and behold, their relative ranking was pretty close to the experts.

Then they repeated the same with a different group of students, but this time they gave the students a questionnaire and asked them to enumerate the reasons for the ranking. Now the results were dramatically different from the two earlier ones.

This Mr. Gladwell argues is another proof that rapid cognition or "blink" thinking is pretty good, and will be immediately ruined by too much thinking unless you're a highly trained expert.

Sounds plausible indeed, and he has lots of other examples supporting the theory. I agree, but I was lacking a good explanation as to why we're so good at rapid cognition and bad at the "long thinking".

Thus, allow me to try to add something to his theory: The third experiment was for me a classic example of using a complex system of categories or taxonomy by the untrained, a given that it does not work. Categories requires education and training. Slipperiness of jams as felt in the mouth surely more than other taxonomies - as can be witnessed by the training period for food taste experts and perfume designers, not much of four week training courses there, more like twenty years internships and much sniffing and spitting. No training and chaos ensues. As always.

But what about the second one? Or rather what's connecting the first and the second so the results becomes similar?

Taste and smell, both having very strong emotional memory (ever get flashes of memories when you pass some flowers or blossoming tree?), would give immediate relationships - "that reminds me of my grandmother's jam and sunny days during summer vacation", a sure measurement of "good taste" I would suspect.

Or the "yech, that's like the cheap stuff I have to buy on a student budget" - probably not getting high marks in the taste department.

And obviously, the whole idea about the "taste-taxonomy" would be to recognise what triggers the "good" relationships, those that triggers the good memories and the natural linking to strawberries in a field on a sunny day. Relationships thus being the common base for one and two.

If you have the book, check the other experiments and examples of rapid cognition or blink moments and you might suspect the same as me - if conscious or unconscious relationships exists in our experience we'll have a quick and easy path to decisions. Try to explain the decisions by using categories (as we're usually meant to if "thinking") and you'll find that nobody but the experts will have a chance. Obviously.

After all, relationships - between, and the actions involving, objects - is the basis for all our learning until we're put in school - and a damned good method it is. And here's good indication that categorising is fools way if you're not specifically trained so why not leave categories methods alone, accept the relationships method as better and develop it further for education and for practical daily use?

As said earlier - awast ye scurvy categories!

Knowledge handling - the neglected opportunity

I believe we are making a huge and unconscious mistake in how we handle knowledge; how we capture, organise and distribute facts and information for assimilation. It might have a wide-ranging negative impact on all what we do, and I think we should do something about it.

Knowledge is the source of our wealth, well-being, and hope for the future.

Knowledge is facts, information and skills acquired by experience or education.

Thus the most important aspect of knowledge is how and in what form it is captured and distributed for the most efficient assimilation.

As we cannot have all knowledge in our personal RAM at all times we need systems and ways to have the right information and facts delivered at the right time, and in a form that we immediately understand - preferably without any previous and specific training.

That is what makes organisations work better, that increases global wealth and well-being, in short, that yields more efficient resource use.

And in practice it's about the single most important aspect for education, knowledge management, politics, global warming, enterprise software and almost anything else. Do not underestimate the importance of how knowledge is handled.

Let me keep it simple and divide the handling methods into two distinct ways:

1. Categories

When asked "what word is the odd one out among these three - cow, chicken, grass" and your answer is "grass" - then you lean towards organising life by Categories.

Also known as taxonomies, hierarchies, tags, classes, branches and similar.

That's when you want to acquire some knowledge about the honey bee and find that it has a latin name - Apis mellifera - mellifera for "honey" of the family "apis" for bee, with no less than 10 more super-categories and you really need to be a highly trained zoologist to assimilate the official knowledge.

Tag this post with "education", and someone looking for tuition fees might read it, not precisely what you meant.

Categories are nouns, they are boxed, limited and requires training and acceptance and belief that the definitions are "right".

Categories are dogmatic as in "accept it" and quite theoretical as in taxonomies based on the male reproductive organs.

Categories requires distribution of common rules and understanding of what each category entails, without that knowledge categories are rendered useless. Or worse, it becomes a source of discord and destruction. This requirement was perhaps always one of the driving forces for the educational system, second only after the historic need for dogmatic religious training.

2. Relationships

When asked "what word is the odd one out among these three - cow, chicken, grass" and your answer is "chicken" - then you lean towards organising life by Relationships.

When we observe that "honey bees" fly, "honey bees" gather nectar, flowers produce nectar, nectar attracts bees, bees get covered by pollen, pollen is brought to other flowers by bees, nectar is converted to honey by the bee... we establish Relationships.

Relationships are endless collections, a web where relationships can easily be followed without training nor much education, and that still could diffuse more precise knowledge about the bee and all that it touches directly or indirectly than any strictly logical taxonomy could do.

That's when you may do a (IT based of course) multilevel query of the full population of all IBM'ers (if you work there) for: "Everyone that know C++, speak Italian, have friends that live in Rome and where those friends ride bikes and have a bike my size to lend out".

Relationships describe how a cup needs liquids and a mouth, thus makes it a cup.

That's how children learn, they observe and "get" the relationship between the objects in their vicinity. That's how our mind works, empirical, learn from observation.

Relationships are verb phrases, based on real activities. It's pragmatic and not theoretical and have no boundaries as the relationships links everything in one way or the other.

Relationships are human in form while still useful for all other things, after all, all relates to the observer, the human being.

In your daily life you would say "Chanterelles are yellow, look like beakers and are really good when sautéed" instead of "Cantharellus cibarius of cantharellaceae family of the Basidiomycetes class". Relationships instead of Categories is what comes natural, and the listener does not have to be a highly trained mycologist.

Not so at work with it's category-based forms and questionnaires and hierarchical positions. Heck, even archiving, the high priesthood of categorising is a proper profession!

So why do we still bother with the Category method if the Relationship method is better in all aspects?

Because of technological limits. Organised life required organised facts and information, and for that technology had to be employed.

Categories worked well in the two-dimensional reality of pen and paper where the multidimensional Relationships could not easily be represented. So frameworks suitable for paper were devised - taxonomy, organisational hierarchies, narrative reporting, accounting and even the last kid to the block, tagging.

But now, yep, Relationships are "made for" modern information technology with its ability to represent multiple dimensions and query links for any number of steps with great speed.

Time to refocus on the single most important issue in all what we do: How we capture, distribute and assimilate facts and information - in short how we handle knowledge.

Make that better, then the rest follows - economic efficiency, better resource use and simplified and better educational methods.

Relationships, not Categories, will save the planet.

BRP - what is it really?

BRP is about walking the woods finding the right trees for logging, ERP is the river where you leave the log, then let the river do it's job while waiting at the paper mill at the mouth of the river.

BRP is about making sensible use of the Barely Repeatable - a true BRP system covers the woods with freshly fallen snow leaving tracks when you're out there, so when you've found a nice route you may retread it later and even show it to others so they can enjoy the good path.

In business lingo that translates to accountability, knowledge enhancement and process bettering.

Use a snowplough and you'll have a motorway, the ERP version of BRP. Apply ERP to BRP and you'll end up razing the whole forest - a popular method some while ago until somebody found it to be rather counterproductive as no natural new growth happened. The forest version of continuos innovation and creativity had been lost.

BRP today lives in a snow-free world, it's more like orienteering where you have posts hidden in the woods and you're given a map and compass.

In business the posts are the applications where you do your tasks, the compass is the vision and strategy on those corporate posters and the map comes in the form of Monday morning meetings.
In all fairness, some applications leave a sprinkle of snow close to the posts though.

The accountability is limited, the race organisers have to rely on you stamping your sheet in the right sequence. The learning is limited to you sitting down after the race pondering why you spent so long time finding post #3. But alas, my experience is that it takes many repeats of the same error before I get it.
And if you're any good, you can smile at your competitors as they have no way of learning from your amazing ability to weave through the woods in no time.

Add a layer of fresh snow to the ground and all would be different.

In technical terms BRP vs. ERP solutions could be described as:

• ERP is resource-centric, tangible objects (parts, products, logs), transactional (add parts, build product, float the logs) and have linear processes (parts does not object, same product every time, always same flow down to the paper mill).
• BRP is human centric, includes virtual objects (problems, medical conditions, unknown places in the woods), transformational (cure that disease, shorten that run) and have conditional processes (ah, the x-ray results, think we'll do a blood test now - now I'm here, follow that road to the next post would save time I think).
• ERP is a proper subset of BRP so BRP can do ERP, ERP cannot do BRP - that's the logic of proper supersets and subsets.

So the time is ripe to go human centric while offering a layer of fresh snow on the ground.

Big Company Innovation

I believe that Business Innovation is all about innovating processes.

Obviously product innovation is a given, but think of a product as in two parts - physical incarnation and process delivery - and there I think the process component is more important: The processes that the product generates internally and what processes it takes the customer through.

If this holds true, then all innovation has to be process focused. Processes must be allowed to be changed, not an easy task if organisational hierarchies and transactional enterprise systems cements it all. With a culture of rigidity all around how can one expect to think freely when it comes to innovate processes for the customer? Process innovation starts at home.

In any case: How much is product innovation, how much is process innovation? How much of a product is process?

Quite.

Let's pick some of the most valuable companies in the world and see if the success is about physical product or process innovation...

Of the top ten you have six financial institutions and three oil companies - all delivering physical products that have not seen much innovation, perhaps not since the creditcard was invented. All their products and innovation is about process - distribution and services.

Add some of the ones that have arrived lately among the highly valued corporations, i.e. those who must have innovated a lot - Walmart, eBay, Google, Amazon, Dell...

Any doubt there? Distribution process efficiency, new distribution channels, logistics, user driven sales, lots of direct user process baked in. The physical products, not much different from before. Then the expected question; with the success, do they still innovate processes or have they glued them to the floor? I'm afraid that they might have applied some glue.

Let's look at another which on first sight seems to be all about physical product, Apple, who makes one great physical product after another, no doubt.

They have chosen to deliver both hardware and software unclogging the support channel - just imagine how much support at MS is about disparate hardware drivers! - and unclogging the user experience. For me a holistic process focus - their process on how and what to deliver, but perhaps even more, the process that their customers experience.

Plugging in my iPhone the first time into my MacBook Pro is uncanny, zip zap click click and I'm registered and all mail settings, all bookmarks have been cloned. A process I could only love, and for Apple, a process-as-a-product that eliminates much of the usual support and delivery process needs.

When I'm in London with the kids the Apple store on Regent street is always the first "sight" we do. Again, a holistic view on the whole distribution process - gives me a "whole" experience and makes their distribution process rather efficient.

In other words, I would suggest that process is where the focus should be and that:

Process Innovation requires flexibility so you can experiment. You need to be able to prototype any idea.

Process Innovation means that you have to know your customer's processes intimately. Same applies to your own processes, all of them. Both requires a culture where processes are not a given but something dynamic.

Process Innovation requires that you can build processes from strategic ideas and not only from tactical needs.

Process Innovation requires provocation to start rethinking of any or all processes.

To aid and abet such innovation you need a flexible system to run your processes.
But you would be much better off with a process oriented "tool" beyond the mere operational; a process modeller for real life use that provokes process thinking, that is flexible enough to accommodate tests and trials and that is sturdy enough to put new processes into life.

Funny enough, same requirements as for a system that runs BRPs...

SAP Influencer Summit #3 - SAP missing the biggest opportunity ever?

I believe that SAP is missing an opportunity to more than double their market, in the same space with the same customers, still for business processes, in a new market segment that is amazingly virgin with virtually no competition, and where the customers are only waiting for the first products.

Why do I believe that? Well, allow me:

A Business Process is any process, sequential work or activity, that happens in an organisation. Some are repeatable and linear, others happens in unstructured ways and are hard to model.

Let me keep it simple and divide process types into two groups:

1. The Easily Repeatable Process (ERP for me)

Processes that handles resources, from human (hiring, firing, payroll and more) to parts and products through supply chains, distribution and production. The IT systems go under catchy names like ERP, SCM, PLM, SRM, CRM and the biggest players are as we know SAP and Oracle plus a long roster of smaller firms.

Known to be rigid, but handles events and transactions with precision and in volume. Systems delivers value through extensive reports and full control over resources.

Resource oriented, transactional, event driven systems. Delivered by system vendors with roots in accounting using up to 25 year old technological solutions.

A mature market segment where an upgrade from version 7.0 to 7.1 would not deliver much in productivity growth for the customer so much of the vendor growth stems from finding new customers for the same solutions.

2. The Barely Repeatable Process (BRP)

Typically exceptions to the ERPs, anything that involves people in non-rigid flows through education, health, support, government, consulting or the daily unplanned issues that happens in every organisation. The activities that employees spend most of their time on every day. Processes that often starts with an e-mail or a call. A process volume, measured by time and resource spent at organisations, probably larger than for the Easily Repeatable Processes. 

These are mostly handled and organised - frameworked - by systems like paper based rules and policies, e-mail, meetings, calls and now in more modern organisations by wikis and other collaboration systems and methods.

Known by extensive loss of information (e-mails residing on HDDs), little knowledge acquired and reused (typical research says 70% of problems solved before without being known) and most of all, untrustworthy processes (oops, forgot to send that mail). In other words not an iota (well almost) of business process thinking or methodology applied to this huge untapped area of business processes.

Requires a different conceptual representation of the processes and data than the transactional linear processes so this would require a technological shift from the current.

A truly virgin market segment where even installing a humble wiki would increase productivity measurably. And most important, a market where the customers are yearning for solutions.

The big question: Why does not SAP spend almost all of it's R&D funding in the BRP space? It would make utterly, completely, undisputed sense.

Now folks, this situation puzzles me so much that I need some help; is there a glitch in my logic? Good folks at SAP, prove me wrong or right!

[Sidenote: Obviously BRPs is what thingamy can handle nicely, but I'm not afraid of some competition at all so come on ye big enterprise software vendors, I'm waiting! ;)]

[Update: Should have been a question mark in the title really, as afterthought, added that]

SAP Influencer Summit #2 - the message

Have you ever been to a car show? If not, imagine for a moment a wife and husband spending a Sunday browsing the current crop of gleaming machines.

Bill the husband sees a slick black wonder, muscular curves and wide tires and drags his wife over. The well dressed representative greets them, seeing Bill's obvious interest in the magnesium rims, the air intakes, and coaches him over to the bonnet that slid