thingamy

Blind growth and social networking technology

Hat tip to Doc and his post where he comments and links to this, this and this - all suggesting that a network, or group, at some point of growth diminishes in value for each new participant. Appropriately termed as Metcalfe's plateau.

Spam always follows size of the network, and we know that groups at some point (quickly) becomes too large for real conversations so that would not be a huge surprise.

Organisations realised this a long time ago. The Roman army had ten subordinates per commander all the way to the top, and modern organisation growth eventually leads to departments, divisions or even separate companies.

Human bandwidth has it's limits.

So where does networking technology focus today? Bandwidth. Massive pipes to deliver volume (checked your Facebook notifications today?). And splitting up into smaller groups becomes an urge.

There's something about this splitting, it be amongst friends or in a corporate setting. They're often close to random or at best (or worse?) follows some guidelines of education or expertise. Or plain good behaviour bringing your friends into the next group.

And then you're stuck. The post-split is rigid, it's set and seldom change according to the need of the moment. Never true to the purpose of the task at hand, like when you're in a department and want to work with somebody in another office. That's when you have to prepare for some serious paperwork.

Instead of focussing on becoming a volume pipeline, this is where technology should focus: Deliver a purpose friendly framework allowing for instant changes to paths and nodes like a fast evolving brain. A framework that allows efficient patching to the right nodes for the purpose-driven conversation or collaboration you need to have, then instantly change again as the purpose changes.

Purpose, framework, paths, nodes, conversations - we're talking process here. Flexible process framework instead of massive volume delivery pipes.

Perhaps that's why I am sceptical to Facebook et al in the purpose centred enterprise setting?

Anyway, for alternatives, Doc's working on the VRM Project while I'm trying to do my best as well.

Creativology??

I see a lot on my Sunday bike rides, lush vegetation, grand vistas, charming villages and beautiful cities like Cannes.

Yesterday morning pedalling along the Croisette I lifted my gaze and was hit by this, almost fell off my bike:

Is this Microsoft's answer to the failed Yahoo deal? Is this the answer to Hugh's call for "change the world or go home"?

If so, time to go home. Creativology???

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.

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!

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

dismantling enterprises - why Big Enterprise Software thrive

"The customer can have any colour he wants, as long as it's black" - true or not, that statement captures what most industrial entities have been up to for a long time:

Focus on the linear Easily Repeatable Processes. Simplify them further for efficiency.

As the name implies these are the easy ones to map, model and structure. Perfect for the Big Enterprise Software vendors who have become unbeatable in delivering systems that precisely and dependably can crank out two million chocolate bars per hour or have plastic dolls delivered for Xmas at the right aisle in some midwestern Walmart without a glitch.

Easily Repeatable Processes, the real translation for ERP?

Then there are the the Barely Repeatable Processes, the BRPs.

The orphans of the big ones, the "ouch, something unplanned happened", the creative and innovative ongoing everywhere in an organisation and not to forget the processes involving the most Barely Repeatable Process generator of them all; human beings.

Some organisations does almost nothing but service these uncontrollable entities: Consulting, government, health and education - and there the resource oriented and Easily Repeatable Process systems are limited to handle HR, inventories of pills, lecture halls and time.

When enterprises are focused on the ERPs the Big Enterprise Software vendors have no reason to spend much on the BRP, after all they are "market driven" and follows the needs as they see them. Don't blame them for that.

But, the cat's out of the bag, there is an increasing call for supporting the BRPs in a most efficient way. After all the BRPs of creativity and innovation is core and government, education and health are rather important services - why should they not become as effective as producers of cars and plastic dolls?

Add that the Easily Repeatable Process IT systems is a mature business technology-wise thus the productivity growth gains little from an upgrade from a version 3.0 to 3.1. All the while the BRPs have been barely touched leaving a huge productivity potential ripe for plucking.

Something is afoot, and I see two directions emerging:

1. Collaboration as a work-around

The current popular method is mostly some version of web 2.0 and SOA mashups where social networks and collaboration are the catchwords. Niftily renamed enterprise 2.0.

The thing is that it does not entirely do away with the paper-based rules and policies that frameworks BRP today. Lacking true process structure they do not deliver much learning nor knowledge assimilation. Ditto for the ever present cracks, the "oops, forgot to..."s.

A "process" is simply anything that happens in a sequence. Everything is a "process", even collaboration. Why not accept that and act accordingly?

2. Run-time flexible processes

Accept reality and let processes remain processes, but this time focus on creating a structured framework that captures the reality and leaves no cracks while allowing the inherent need for flexibility that BRPs require.

For that you need an easy way to model and tweak and change the hard to grasp and often complex processes. At the same time leaving maximum run-time flexibility to allow for creative use of the resources.

That way you can unstick that sheet of Business Rules from your wall and recycle it to save some trees.

Not to mention getting accountability, and with capture of data; a learning process and knowledge. Pretty important stuff that.

Of course the last is an unashamed plug for thingamy... the only system where you can model and run a football game ;)

categorising or relationships

Thanks to Johnnie Moore and his links to Stuart Henshall referring to a keynote by Dave Snowdon I was yet again reminded about the importance of ditching the tags.

Yep, the tags, a popular categorising tool still spreading, as an alternative to the age old taxonomy tree structures which I find no better. (But as I supported until doubt set in!)

My favourite take away was Dave's request to the audience:

"What's the odd one out from chicken, cow and grass?"

What's your answer? Pretty standard IQ test stuff such...

"Here in the West most of us would say grass but in much of the world they'd say chicken. That's because we're trained to filter by categories; elsewhere they filter for relationships."

says Dave, and I admit to the same fault. So much for western dominated IQ tests... heh.

Thing about categorising is that it creates relationships between objects in a indirect way, and thus leaves precision out.

Chicken and Cow are not directly related other than both being members of same groups: "Domesticated animals" or both "farm dwellers" or both being "staple food in many countries", when dead and parted of course.

Hardly precise those relationships, and thus not very valuable as knowledge enhancers.

Adding knowledge to the objects is what it's all about.

If precise and fulfilling you and a system can find the right object at the right time - enhancing productivity, learning, speed, precision and minimising errors and waste of time.

Whatever we're doing to software systems or ways of running anything - using the best possible knowledge enhancers is of utmost importance. Without the best the rest is kind of moot.

Back to the cow.

Cows eats grass. That's useful and pretty simple or what?

Cows lives on farms.

Chicken lives on farms.

All relationships. Semantic N-triples - readable by you and me, and a proper system as well.

Allowing queries like "what eats grass?", "what animals lives in same locations as cows?" or even "what is the most popular car brand among owners of locations with grass eating animals and egg laying animals?".

Nifty eh? And not easy to do with categorising...

Storytelling and running enterprises

I like storytelling, I like Spielberg and JK Rowling. The conflicts, the suspense, the events and transactions enhanced with what people think and feel. All tweaked and bent so the story flows better.

Just like accounting - summarised reports of events and transactions, all tweaked so the intended story is easier to follow.

That's the beauty of using events to paint a picture, lots of freedom but alas little reality.

If you're working in an enterprise, when you order a widget you describe the first event with an "order sheet", then the shipping event with "shipping papers" and so forth. To understand the widget, or understand Harry Potter, you have to study the events and put them all together, a whole stack of reports and sheets in the enterprise world, or a book in Rowling's world. But just as for Harry Potter one event might throw you off and conflict ensues. In accounting that's called reconciliation.
And of course, add SOX and other regulation rules to keep a lid on things.

This is how enterprise software is designed, event documentation, or as some would call it, storytelling. Even the enterprise tools like word-processors and spreadsheets are support tools for the storytelling, and worse, made for story manipulation.

This because event documentation, or story telling, was the only way to capture the essence of the enterprise when we only had pen and papers. Event-driven and event-documentation. Or transaction-driven - same concept but for stuff with value.

But there is another way. It's called object-driven and object-representation.

If I'm at a football game my eyes follows the ball and registers it's every move, the spin, the direction, the goals. The game is object-driven. If the ball looses speed and stops up I can deduce nobody has kicked it, the object represents what happens. Obviously I'll also keep an eye on the other "objects"; the ball-kicking-assignees - the players.

The plants in my garden "tells" me if they get too little water or sun by signs of dry leaves. The plant-object captures all that happens to it and I can deduce what happened. I'm using "rules" and "mapping templates" in my studies of the object - dry leaves, short of water - then I'll increase watering by changing the "aperture" property of the "sprinkler" object.

When I'm driving, my eyes are peeled on other objects; cars, people and cyclist - objects with telling signs of what's going to happen is "told" by the objects themselves. No doubt also a object-driven environment.

The assembly line used to be like that, the car arrived without doors - I have doors at the ready and tools to fasten them. No need for a "work order" I can deduce from the objects themselves what my task is, and when. After that the object itself have captured what has happened to it, no need for an event report as the doors are visibly in place. If they were not the object itself would have "told" that I fell short of my task.

This is possible to attain using IT: Let any real-world object be represented by one data-object, punt those data-objects letting the real objects follow along the sequence of work that shall happen in lieu of work-orders. Then let the data-objects capture what happens and use templates with rules to produce any report with immediate effect.

What about virtual objects? No problem, replace the "car" object with a data object representing say an "issue" or a "medical condition" and add details as properties of such data-objects and punt it to an expert or the doctor who then decides where to punt it onwards. X-ray perhaps? Another expert? The work-order or appointment comes as a fully displayed data-object just like the car on the assembly line, no doubt what to do, no need to tell "please fix this patient" and data capture happens through the object properties being filled out or changed as well through capture of who and when did it all.

That way an object-driven model of the enterprise will open for far easier modelling of barely repeatable processes as well as the classic linear ones, have much built in run-flexibility and deliver reports real-time in any format with no need to worry about reconciliation. SOX and other rules all covered by design too.

Boring perhaps, storytelling being so much fun - but your shareholders will thank you and the CPA will have less to do.

process flow simplicity (even more on documents, forms and accounts)

Business is all about flows, and flows are all about data.

An IT supported flow has to work with data objects, and how these are designed will determine the complexity and scalability of the flow model:

Since old we've used comprehensive chunks of data for presentation which has led us to keep dissimilar rigid buckets for capture, storage and flow - documents, forms and accounts.

Thingamy sticks to finite data-objects for capture, storage and flow, then rearranges finite data into chunks for presentation later.

A bucket-passing line grows complex and error-prone fast.

A river of the smallest finite objects, like molecules of water, is not complex, only capacious.

Keep empty buckets of different size next to the river and fill when need be.