thingamy

Fear and uncertainty - sports, parenting and business

We fear uncertainty, and we hate fear.

And honestly, we are bad at calculating risk and handling uncertainty. Fear and a clear head do not mix easily.

When we drive a car or do sports, danger is close and split second reactions is coupled with sometimes a well developed ability to analyse the near future - "small road partly covered by bushes coming up on right side, better slow down and keep an eye peeled on it".

Then there are the not-so-imminent-danger areas where I would suggest parenting and economic security are the never ending suppliers of fear. We often have more fear in these imaginary out-of-our-control situations than when having actual brushes with death while mountain climbing or motorcycling.

And it's in the not-so-imminent-danger areas where we most often fail to make the best decisions - "the city is dangerous, better not let the kids go there, rather have them play at the pool". Anybody ever checked the statistical facts on what's more dangerous? Probably not, stern warnings from other parents last night at some dinner party beats real facts.

Economic security spills over in daily work, and business if we're in charge; and that's when the madness becomes a science. Here it's called planning and budgeting, usually following this recipe:

1. Analyse, predict, budget, plan.

2. Set the structure and execute the plans.

Analyse the market, use focus groups and spend advertising budgets accordingly. Extrapolate growth numbers, mix in macro economic factors, procure, build capacity and set the organisational goals. Classic and boilerplate operational template for most businesses. And by the way, authority gets the last word, at the board meeting or like that lady I sat next to last night at the dinner party. Arguments well delivered are grasped with delight when fear is easy to conjure.

Ah, hang on a sec. There's a third step that I forgot, sorry to mention it but:

3. Uncertainty strikes, the unplanned for, the oil price spike, the new competitor, the collapse of some far away currency. And it happens more often than not.

And with that; #1 and #2 becomes completely moot in one fell swoop.

Worse, 1 and 2 are now cement feet, you risk sinking with a huge capacity or marketing campaign investment around your ankles. Goal cannot be reached, bonuses evaporates and moral is sinking.

Allow me to take a lead from the imminent-danger type of situations, the ones where we "feel" we're in control (but alas, only in part).

Say cycling in these days of daily doses of Tour de France images: Look at those guys going down the hills at breakneck speed on 18 mm narrow tires. Planning and budgeting would not do much for these guys, except lots of bike handling experience and choice of good tires (too bad they're all the same though).
Neither would any prediction that states "there is a 88% chance of a right-hander after the left-hander" be of much help. Riders with closed eyes relying on such predictions would make for scary and entertaining TV though.

Nah, it's all about having hands on the handle, eyes wide open and the brain sucking up all input all the time allowing the rider in control to handle the unsuspected.

That's precisely how a business should be run. Full stop.

Real time feedback on internal and external ongoing (eyes), real time benchmarking of competition (understand the other riders) and seamless execution of decisions (handlebar, brakes and derailleurs).

And please, please stay away from the budgets and predictions, a sure-fire way to distract and send you over the rails!

For the processes and their support systems focus on (real!) realtime feedback and (instant!) seamless execution, that'll keep the road rash off your bum.

Trundling down hallways to meetings, flipping through CC'd e-mails, contemplating a conversion of a customer to "prospective" status in CRMs or sucking out data from rigid ERP systems for some spread-sheeting is not for business navigating high speed hairpins. A definite recipe for wipe-out if any of your competitors gets it, and one will one day.

[Bonus thanks to @johndodds: "What, me not worry?". Reminded me that worrying is healthy, fear is bad. Think the cyclist worry a bit, but fear would wipe him out. Suspect that managers often switch from worry to fear though as the link to their economic well being comes into play...]

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.

freedom and structure

Playing games - that's when we experience real freedom.

We've known that since we were kids creating games in the backyard. And, it came naturally, had to invent some rules as well. We "knew" that the experience of perfect freedom required some framework; rules, some equipment, a playing field. All good.

Structure enough to let you focus on the game, structure to help the game while not enough to limit your game.

Translating that play mode into business life would be nice, experience real freedom where we spend so much of our life.

Well, perhaps not impossible if one rethinks a few things:

A few weeks ago I was getting my head around a user case (building a pilot) for a project driven service firm, OK, project driven is rather what all service business is about - from health to legal, but back to the situation:

They had project structure, nicely described in a workflow diagram: It all starts off with a meeting between the client and some folks from the firm's side. Then back in the office another meeting where plans and action items are set and distributed and a date for next meeting is set.
Two weeks later another meeting - the people involved presents their work and again they discuss and settle on new action items that are brotherly divided among the participants. Another week, another three weeks, meeting to meeting to allow for the tasks to merge back into the flow.

In other words, meetings are the bookends in the work distribution framework. Anchoring the flows instead of driving the flows.

Would make for a rather boring game of football (soccer) that. Pre-set meeting points to discuss last few moments of dribbling, I would imagine the game could last long into the night while quickly loosing spectators.

So why not do as the footballers do?

I get the ball and that's when I spring in action and do what I'm best at (whatever that is) as fast as I can (however fast or slow that is). The ball is forwarded to another player who then does his bit, back and forth until an opening, fast through and into the net (hopefully) while everybody see everything that happens. If I'm slow my team mates might cheer me on, reach out to help or give me a hard time for not doing my best.

Team members with project.

In other words, let the project (ball) drive the workflow, allow changes to the project path as deemed useful during the flow - the meetings now being moot as they're no more needed, actually they would hamper the game.

(Note: Meetings as in meetings of minds to discuss an issue is different, that would be more akin to a quick discussion on the field as what next move would be good.)

So that's what I'm piloting - the tools, rules and field to play the game - the project being the ball. Sequential, visible and flexible but still with the much needed structure. And by the way using the football metaphor, have the game video taped so no reports have to be written, the ball itself capturing all that happens to it.

More fun. Less time spent. Freedom to do your best.

management... duh!

Business process management, document management, customer relationship management, supply chain management, management, management, management...

Managing is what you do to horses. Wielding a whip in the middle of the manège putting the horse through it's paces.


Management at work, western style.

Yep, that's what enterprise software is still about; corralling chaotic processes.

But you cannot flog a dead horse so modern management consists of two parts:

1. Get the horses going, wake them up, aka "inspire the troops".
2. Get the whip out and manage whatever chaos you started.

Anybody heard of a car? Modern thing, a post horse contraption which you enter and drive. No need to wake it up, no need for a whip, no management involved.

Why on earth is enterprise software still in the horse and buggy mode?

Why manage customers when they can be included? Why manage suppliers and channels when they can be a part of the process? Why manage processes when they can be driven by the participants?

Set up the roads, prepare the vehicles - that's what enterprise software should offer.

Drive the business. Managing is for circus directors. Or cowboys.

my life as a bug tester

For every new line of code, for each new feature added or cleaned up I'm on the front line. Firing it up, poking around and stumbling over bugs, then carefully trying to recreate.

After creating functionality, ease of use is the focus. And bugger me that's the real hard part! What is ease of use?

First step is easy (duh), minimise number of clicks, right balance of number of features, speedy reaction and no scrolling please.

Second step being the elusive "intuitive" - and that I'm always giving up on. Ask a chap who's used to Windows and get one answer, then ask somebody running Gnome and you get another.
So I'm trying my best to not-think-computer-interfaces and reach for the moon; the other stuff we do on a daily basis. Wish me luck and ask me in fifteen years how it went!

And don't get me started on "pretty"! Anyway we outsmarted that one - all css files are open, please feel free to change!

The first part is going well, and for the second area I'm in luck as most terms in my system are user-defined so I'll let each user decide, with a little help of course. Not only terms, but process flows as well. Despite many existing standards, reality is different; each organisation has it's own ways and good is that. And believe me, reality in most organisations is usually quite different from the internal and neat flowcharts once created.

But I've found one quite unexpected effect when the system gets easier to use:

I get sloppy!

I'm invited to become sloppy and god knows I grab that invitation with both hands. The easier and faster I can build the sloppier I get, most unfortunate.

My system requires good and solid logic; it's after all a Business Model I start out to build, processes and report templates - the engine, chassis and control of a car business. Omit a small but important step, do the wrong sequence and lo and behold - it does not work very well.

If you'd been around me you would hear the occasional muttering of "bugger, bugger, another bug" - then followed by a slap on the forehead and a relieved "ouch, how stupid am I??". Yep, I am relieved when I find out it's me and not the system that is stupid.

So how can I fix me? Not that easy if you ask my family. I can try to hold my hand of course but then I end up in "intuitive" land again, a lose-lose situation that.

Thing is that when I buy a car I find it easy to use, but the good folks that designed it and built it were fastidious, precise, organised and thorough. Sloppiness not accepted. I the driver is allowed much more leeway.

Thingamy as a system for an end-user is like the car, but building the Business Model therein requires more of the attitude displayed by the engineers of an F1 team than the local drivers of battered Renaults.

Business builder view of what he can build.

End user view of the system.

I'll do my best to supply the very best tools for the Business Model building engineers, but I have to insist on fastidiousness, precision and focus. Sorry, life requires it sometimes.

Cannot really see how I can avoid that. But I can promise a huge surge of pride with a job well done with end-users going about their daily work in a uncomplicated fashion, just like me in my modern car.

Meetings - a silent sigh

Meeting of minds are core to our existence, and almost always a pleasure (except for that chance brush with a surly parking meter overlord of course).

But there is another kind of meeting, mostly an intracompany phenomena: The project workflow node par excellence, the book-ends of any process snippet in our daily Barely Repeatable work day.

Check out the way your own office is organising a project, do a workflow diagram including milestones on a piece of paper. What are the milestones called? I bet you that they're meetings, or sign-offs. The very framework used to organise any BRP flow are centred around meetings - gather all hands on deck, discuss results so far, distribute tasks and set next node, eh, meeting. Rinse and repeat. Check, control and allocate.

If my cycling club were to organise the Sunday group rides accordingly we would regroup every four kilometres, wait until all are assembled, give individual progress report, dole out the route for the next four kilometres and mount our bikes again.
Luckily it's not like that; we all know where to go, having no problems in finding our most efficient pace for the long slog, constantly cheered forward by our cycling buddies interspersed by the occasional bout of friendly competitiveness when approaching a crest in the road. A damned more efficient and a whole lot more enjoyable process I would add.

So why don't business do the same? Old habits and no other useful work flow framework I'm afraid. (But of course there is, you just have not implemented it yet ;)

Typical project meeting.

(I challenge you to source a suitable "meeting" image from your favourite stock photo supplier - a few absent looking faces, somebody nodding off or hiding an urge to yawn. Yeah, as if, nothing but smiling faces and handshaking by fresh looking well dressed models. Somebody is trying to gloss over reality, fishy, very fishy.)

Quo vadis SAP? - Sapphire 2008 # 2

My favourite takeaway from Berlin is in regard of their Business Process Platform. The basis for most SAP products.

A whiff of disagreement discerned, snippets of enthusiastic arguments heard - engaged voices for opposite views on this obvious core importance for SAP. I say bravo! Creative discords and passionate discussions is what pushed the world forwards:

One camp was adamant that the platform is mature and as such poised to become a platform for all things enterprise software - a black-box-back-end that no firm nor enterprise software vendor could do without. SAP still delivering front ends while inviting others to add their (vertical or not) apps on the top as well - true platform thinking with community included.

Another camp was convinced that the Process Platform is far from mature and should have much growth potential.

I like what I hear - and I agree heartily with both camps!

Based on today's architecture - transaction based - the BPP is mature. As I have many times suggested, transaction based architecture has met it's nemesis, complexity, and will not be able to grow past the types of processes - the easily repeatable process - that the platform handles with great aplomb today.

A perfect black box for all things easily repeatable which I could easily imagine as a "must" underneath all other enterprise software, following the path of databases - you do not see them but you certainly need them.

On the other hand if you look at it from the "run a business" value and do not bother about the technology, well, then I think the life of BPP (in whatever form it can become, not what it is) has only started.

Most work as measured in man-hours is collaborative, sometimes ad-hoc, sometimes quite structured - but as it's about creative work and involves people it's usually barely repeatable. The kind of business processes that consumes acres of time and people resources, being the core business process of health, government, consulting and many other businesses. Thus most probably a much larger market for enterprise software than the existing one (I would argue) while currently barely covered by the enterprise software vendors.

How SAP will solve the conundrum I do not know - but from the outside it seems slightly obvious that the existing BPP black box could be a wonderful "cash cow" and lock-up-the-market tool. The established platform for all to be on. Doable and making sense.

At the same time a new tack has to be undertaken given the large untapped market, but as could be expected from somebody (me that would be) who's been pestering his readers with claims that "transaction based" systems are doomed - I think they have to start over to create a new platform for value adding to the BRP area, a new and potential huge growth area.

The SI shift - Sapphire 2008 # 1

I'm so pleased to find that SAP at times agree wholeheartedly with me, OK, OK, granted that it's rather the other way around ;)

The business of System Integration is in for a dramatic and imminent change.

In fact I heard one SI top executive express with conviction (one-on-one, so certainly with more drama than otherwise allowed) that the current form would more or less cease to exist. The SAP'ies themselves were a bit more diplomatic, but still directly urging their SI partners to focus on a shift "up the value chain".

Just before going to Berlin and Sapphire 2008 I was building a draft run-your-business system for a potential customer, reading the requirements in my usual sceptical mode - then immediately shifting to a mode of business consulting using IT as a mere tool to model, real world test and implement.

And Thingamy is not alone in this - the current crop of systems from SAP increasingly boasts business oriented interfaces leaving the mundane IT stuff hidden. Selling, installing, implementing and even support is thus moving away from being IT centric to be a pure business issue. Already reports of sales to department heads and not CIOs could be heard and the expectation is clear: This trend will only become stronger.

This means that there will be a need for a different kind of partner, or a changed partner expertise makeup required for the new products beginning with BBD - business being the core. "Having 15 years of ERP experience will not be be the thing to have anymore" was mentioned.

What impresses me is that SAP have very clear ideas of the general trend while openly accepting that they're in a learning phase creating the path as they proceed - and involving their SI partners as well as they can. An "extreme business planning" approach after my heart.

But what about the Management Consultants? Any management consultants out there seeing the huge opportunity? If so, mail me as I've got some tools for you as well ;)

P.s. Again my thanks goes out to the kind people of SAP - Stacey Fish for once again looking after us in the best of ways and to Léo Apotheker, Pascal Brosset, Peter Zencke, Doug Merritt and many more for their openness and for not getting flustered by the impertinent questions from our little band of bloggers. We certainly enjoyed it a lot, and how could we not, those guys are definitely on the top of things!

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.