thingamy

Legacy Enterprise Software impedes gravity

Movement requires a force.

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

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

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

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

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

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

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

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

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

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

 

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

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

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

* say, thingamy's Work Processor...

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

Legacy Enterprise Software is not strategic

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

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

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

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

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

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

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

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

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

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

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

Etc.

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

Etc. Etc.

Recognise something? See a common denominator?

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

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

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

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

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

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

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

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

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

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

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

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

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

Until one day.

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

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

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

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

And the management lived happily ever after. ;)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Work processor

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

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

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

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

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

Work processor.

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

What do you think? Does it resonate?