thingamy

Work Flows and Wealth Creation

Inseparable since the beginning.

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

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

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

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

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

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

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

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

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

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

[Thanks Hugh, perfectly put!]

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

Information, Knowledge, Wisdom, and Innovation

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

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

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

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

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

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

Information: object facts

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

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

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

Knowledge: object relations

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

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

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

Wisdom: object relationship patterns

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

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

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

Innovation: object relation rearrangement

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

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

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

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

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

How not to do it - 12sprints and Chatter

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

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

So what are the vendors doing?

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

 

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

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

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

But process illusion is not process reality!

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

Nowhere. Or everywhere in different formats. 

Illusions works for awhile but will always fail.

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

Go to market by Extreme Business Planning

Don't know if this is an effort to make own behaviour plausible, but so what...

When entering a market the GAMP (Generally Accepted Marketing Practices) has to be right, as in getting certain stuff right:

• Target market
• Price
• Packaging
• Channel
• Story
• And the rest of it

But one forgets, there are two ways to enter a market:

A. By GAMP

1. Spend days and weeks in the boardroom trying to outguess your potential customers as to who, how, what and when they will use your product.
2. Set the choices in stone, get the channel onboard, set the message and story, price it and colour your product.
3. Go.

Result? Binary. Uncontrolled and rigid outcome. But fast. Success or crash and burn in the fast lane.

B. By EBP (Extreme Business Planning)

1. Keep everything open with two exceptions; build your product so it can be changed and tweaked easily, ditto for your organisation and cash burn.
2. Go.
3. Let the potential customers decide who, how, what and when. Adjust accordingly.

Result? Analogue. Controlled and continuous movement. But slower. Slow and deliberate right hand lane driving.

Think I like B. better. Doable? But of course as long as you question the assumptions you do not know you're making.

Bonus question: Which method would the time-constrained VC board members push for?

Context over Dogma

Context: "The circumstances that form the setting for any event, statement or idea, and in terms of which it can be fully understood and assessed."

Dogma: "An authoritative principle, belief or statement of opinion, especially one considered to be absolutely true regardless of evidence, or without evidence to support it."

In other words "fully understand why something happens versus an unchallenged belief in what causes an event", two counterpoints in how we handle reality. One or the other is behind every method and principle that runs our daily life.

There are four issues regarding context versus dogma that should interest us:

1. Organisational events are difficult to understand and model, thus business and government operations (management) got fraught with dogma. 
2. Dogmas are the simplest and most obvious barriers to further development and when accepted will continue to limit wealth creation in business, governments and society as a whole.
3. Replacing dogmas with context is potentially the most powerful and efficient form of innovation - large and instant gains from very little resource and time spend.
4. An important aspect of a dogma is it's inherent absolutism, infallibility, irrefutability, unquestioned acceptance (among adherents) and anti-scepticism. In other words it has self-defence built in.

Interestingly enough, the latter phenomena yields the best indication that an idea or principle in fact is a dogma: Challenge the current ways, and the more vicious the defence is, the higher the probability that you are facing a dogma. On the surface some of the defence might sound plausible, but often the defence is in the form of "that's how we always did it", "it works as it is" and "don't rock the boat".   

Hence the most efficient path towards enhanced wealth creation for business and government is to find and challenge the dogmas and create alternative operational ways based on context. Let context win over dogma.

On the surface it does not look easy - first to find real dogmas, then to device a context so you can introduce alternative ways.

But nothing is easy if you do not recognise the barriers (dogmas). Passing a wall is not possible unless you recognise it as a wall. But when you recognise it, it may not be that difficult after all. The scaling or circumventing process would certainly be more enjoyable in daylight than repeatedly bumping into it in the dark!

Here's my usual list of organisational dogmas, or rather the practical implementation of such. Enough to keep anybody busy for awhile and certainly enough to create a huge leap in wealth creation if replaced with context based methods:

1. The Organisational Hierarchy. It's old, it's been developed during times of no technology to speak of. It's clearly fraught with problems and it is always strongly defended.
2. Organising by tree-structures. Sadly, but expected, Carl von Linnae did beat Comte de Buffon as the two-dimensional organising methods beat out the three-dimensional and relations based method. But that was about 300 years ago when handling three dimensions using paper was a bit too much to ask.
3. That managing is a requirement. Managing as in controlling and as a theory of organisational functions, the practical and theoretical umbrella for most of the dogmas on this list.
4. That double-entry book keeping is the only way to gather economic information. With only paper-based ledgers it was certainly a stroke of genius 515 years ago. But we do have developed technology-wise since the bound wad of paper.
5. That budgets are a must. At least a dogma under siege; many large multinationals have abandoned this already and are doing better for it.
6. That meetings are unavoidable. Meetings as in exchange of ideas still make a lot of sense, but as a forum for dissection and dissemination of tasks I would question it as there are other widely used and efficient communication methods available.
7. That documents and forms are the best information format. Simple, easy to understand, easy to handle - but they are also a source of data complexity, reconciliation issues and errors. There should be no need today to keep all of layout, object data, transactions and time context in one and same format. Yet another methodology sourced from the paper-only days.

If you disagree and believe the above list is the best methods life can offer organisations, please give this (my usual) argument a chance: The Roman army and their finely tuned organisational hierarchy found that ten subordinates per supervisor was perfect. Thus their system of decurions and centurions. Now, two thousand years later, hundred years of Harvard Business School, 40,000 management books in print at any given time, we have found that the number most probably should be eight. With that kind of development progress using that kind of resources and time, there surely must be something wrong with the base (organisational hierarchy and management theory) or what? 

By the way, as a last parting thought: The vigourous defence against changes that is to be expected, and indeed is an intrinsic part of dogmas, will keep most from doing anything. Hence the first movers will be doubly rewarded with competitiveness and profits.

Go challenge dogmas and create wealth now.

P.S. Thingamy can directly and immediately replace dogma based methods with context based methods in 1, 2, 4, 6 and 7.

What they miss out on in Davos

Good thing about working from home is that I can watch webstreams from conferences - these days it's the fun they're having up in Davos.

Obviously much is about the crisis, what happened, how to fix it and how the heck did it happen. More and better regulation being one of the main themes of course, following the human inclination to grab more control when things goes... ehh.... out of control!

But one thing is missing from the discussion - finding the root cause for it all. Is there a single thing that lies behind it all? If found all would be much easier, at least the issue of how to avoid such calamities again.

Is there a root cause? And if so, why is it not discussed?

So why is it not discussed? Because sometimes we take some things for granted, we cannot imagine the world without that something, we in fact forget or even cannot answer this simple question:

What assumptions are we making that we do not know we're making?

And the root cause could be what? Allow me to posit that it is:

Double Entry Book Keeping.

Not the accounting reports as such, I'm fine with those, it's the method of capture and representation of facts that I see as the culprit.

That's a method that we take for granted, that is never questioned, that we assume we need, an assumption we do not know we make every day.

Let me ask: Do you really think that a method created 515 years ago in Venice, based on a technology called "bound paper" as in ledgers, will stand a chance on Wall Street using fibre optics to disseminate information to all corners of the world?

I think a snowball in hell has a better chance to be of use.

At least question it. Challenge the unknown assumption.

Double Entry Book Keeping uses transaction representation to capture and store "what happened", the ubiquitous invoices, bank statements and many more types of paper based or electronic documents. When captured the representation is assigned as per accounting principles and rules to a single "account", or slot if you will. Those principles and rules are differing from place to place of course making it all so much easier (insert hollow laughter).

This how far that technology has come in 515 years.

With that in hand reports can be produced - cash flows, P&Ls, balance sheets and more. 

But...

• That is how the gentlemen at Parmalat could use Tipp-Ex on a piece of paper and suddenly show that they had in excess of € 4 Billion on some Cayman bank account. Except a few extra naughts on one piece of paper does not make much sense the day you need the cash.
• That is how a few well placed misplacements or closed eyes at Satyam could make them pretend to be much richer than they were.
• That is how reports has errors, always, and is delayed, always, making the whole thing a charade similar to driving a car by a dirty and cracked rear view mirror.
• That is how layers of rubber stamping or at best, wild guessing using statistics, by rating agencies is needed to give a whiff of reality for the nifty Wall Street repackaged packages - the quality of which we now know too well.
• That is why changes to a house owner's economic status never have a chance to trickle through the layers of CDOs and whatnots all the way to the holder of the debt in some far away municipality on the other side of the world.
• When you keep the same information in different places, in different formats, you will, and be in no doubt - you will have errors and doubt. To fight that queasiness we have the usual band aid mechanism named CPAs, reconciliation and regulation.

If we ever think we should be able to address the crisis and make this world a better place we have to throw that thinking and those methods out the window, and that asap.

Instead we need a direct and dynamic representation of the "transactions", something that is real time and where changes anywhere in the chain are precisely and immediately reflected everywhere independent on principles and rules.

Believe me, it's doable now. It's even simple.

Beyond the crisis - the importance of wealth creation and enterprise software

2009 looks bleak, people are nervous, businesses have found the handbrake and sounds of changing gears without using the clutch can be heard.

But a crisis has a side effect; it spurs changes and new ideas that moves society forward. Even stronger, it cries out for changes and new ideas, just cost-cutting your way forward does not cut it.

As I said to my EI friend Dennis the other day - you have two choices:

1. Try to understand what's happening and get a grip on the future so you can prepare a defence (futile on all counts I would say), or 
2. put on your best running shoes, a headlamp and a big smile as you venture out into the dark in search for opportunities.

I'm more inclined to the latter approach.

So let's put on the headlamp and do some nocturnal orienteering:

The credit crunch is scary, the loss of share and house values is devastating for pension plans and of course the loss of jobs is heart wrenching. But they're all inevitable results of the mechanism in how society works; either by the downs in the natural up-and-down imbalanced nature of things, or by the bigger shifts in "ways".

Imbalances and natural ups-and-downs are only surface effects, the core issue is how fast and efficient "real" wealth is created in the society as a whole. An increase in "real" wealth creation will affect us long term and should balance imbalances in short term, so that's where we should focus.

We've done the big leaps from hunter-gatherer to agriculture, and agriculture to industry moves - so not much to find there, and ICT has done it's job over the last 30 years in organisations/enterprises (the hubs of wealth creation), or so it "seems".

I use the term "seems" as I'm not so sure it's potential has been exhausted.

Academic studies are a bit vague as to specific figures, but while digging around I found at least irrevocable signs that IT in the industrial enterprise did have a serious impact on wealth creation, and maybe more interesting, it was an accelerator for the impact of other capital investments and labour. This should not come as a surprise as we have seen the IT enhanced efficiency of industrial production, logistics and other near-linear processes.

A surprise was the indication that IT did not have a similar impact on the services sector, there's even talk about an initial negative impact moving towards a neutral impact over time.  

Why this? IT applied to linear and physical processes is what has been deployed, it's the kind of software that can run most of the industrial core and thus their main value creation processes. It's the software that some vendors have grown big by, SAP and Oracle being two good examples. In broad terms this enterprise software market is about 228 Bn $ per year.

On the other hand the services sector (and in parts of the industry sector), where the processes are much less linear, where people are involved, processes changes paths all the time. Such processes are called practices, exceptions, ad-hoc, knowledge worker or manual processes - and the software delivered is almost without exception non-process based. These are mostly ad-hoc application (linked or not) to aid ad-hoc writing, analysis, communication, keeping and sorting knowledge and recording of the ongoing. 

More or less the only process based software that is trying to add some structure here would be BPM systems, still a fledgling and small market at 1.5 Bn $ per year. Beyond that, the processes are mostly run by "technologies" like organisational hierarchies, budgets, deadlines, email and meetings (methods that are accepted as a "given" and subsequently modelled by BPM, thus effectively limiting that IT solution long term in my view).

These types of processes are what I call, as you would expect if you've been here before, ERP (Easily Repeatable Process) and BRP (Barely Repeatable Process).

Now to something interesting: If you take world wide GDP (for the lack of better) as a reasonable measure of wealth creation for different sectors, then adjust it with some rough estimates as to where ERP and BRP type of activities happen you could deduce that ERPs stands for about 32% of world's wealth creation while BRPs stand for roughly 64%. [Note below] 

So now we have this situation while we enter 2009 looking for the "yet to be used" wealth creation acceleration methods:

ERP, IT and wealth creation:

- 32% of world wide wealth creation.

- 228 Bn $ of software delivered per year.

- Mature technologies, widespread use.

BRP, IT and wealth creation.

- 64% of world wide wealth creation.

- 1.5 Bn $ of software delivered per year.

- Early or inexistent technologies, very early adoption.

If IT could do wonders for past world wide wealth creation by handling ERP better, why should it not have at least the same impact on future wealth creation if it could handle BRP better? In fact why should it not have twice the impact? Of course it could, it just have to be done and should thus be a worthwhile activity to focus on in 2009 and beyond.

As you would/might know, supplying an overall BRP solution is my particular area of interest and activity so I am definitely biased, but quite happy to do my bit to prove if I'm right or wrong.

[Note: GDP per sector: Agriculture: 4%, Industry: 32 %, Services: 64 %.

Estimated percentage of a sector's people processes being BRP: Using GM in 2007 as a measuring stick with 7.5% in Admin costs -> let's assume that 2/3rd of that is non-linear or BRP -> 5% BRP and 2.5% ERP on top of 92.5% core ERP or BRP.

Thus W-W ERP GDP share would be: 32% x 0.95 + 64% x 0.025 ≈ 32 %

And W-W BRP GDP could be: 32% x 0.05 + 64% x 0.975 ≈ 64 %]

Bad times? No, fantastic times for the entrepreneur!

Suddenly things changed, buyers are holding back, budgets are frozen, projects are moved into "next year" - and to add insult to injury this happens when most start their budget cycle. Not the expansive mood to create a supplier-friendly next year's budget I would say.

Bad? Sure, but hang on:

That buyers says "stop" does not mean that they have no needs anymore, it simply means that overnight their needs have changed.

That you suddenly ditched the idea of a new car, that the expensive family summer cruise is now on hold does not mean that you do not need transport or a family vacation anymore. Sitting down you now think taking the train instead of driving would be good, that a camping trip would do the family even more good than stuffing your face on a floating restaurant.

And that's where the "great" part for the entrepreneur lies - the needs did not disappear overnight, they simply shifted while your competition is geared towards the products in vogue two weeks ago. Suddenly they are bewildered and succumb to the tendency to say "the market will return when all this is over", cutting costs, holding their breath and in general thread water.

Two realities:

1. There is suddenly a shift to needs that few, probably unprepared, caters for.
2. That things might not turn back to "normal", shifted needs means new solutions that may end up as the new "normal".

You could end up doing camping trips for many years when you found how much you all loved it. The cruise folks will sit there while the camping outfitters will thrive.

This is what you must do now:

1. Find out, as fast as you can, to what have your customer's needs shifted to, and if there are other potential customers looking for what you can deliver.
2. Change your own offerings to that and deliver now.

It's in "bad" times that the basis for big fortunes are laid. Good luck!

Business Changes and Organisations

In business "change" is a part of life, as in life itself. It's prompted by new ideas, a changing environment, new competition and sometimes the healthy and simple need to move on.

So, what happens the day when the issue is raised?

One word - "organisational change".

Analysis of organisational structure ensues, roles, positions and hierarchies are scrutinised, boxes and interconnecting lines on a white-board are erased and drawn and erased and drawn.

Once a consensus is reached plans are set in motion and hapless employees are sent offsite to dangle from ropes and devise clever ways to cross rivers with a nail and a tooth. Seventy blue baseball caps have been ordered and a big kick-off party tries hard to drum up some enthusiasm.

Here's an even worse situation: Try to merge two different organisations that in principle are doing the same thing.

Reshuffle the org charts, streamline the lines of responsibility on the white-board, implement. What happens? The well made plan hits reality, i.e. when the top-to-bottom theory is merged into the bottom-to-top reality: Grinding of gears, and even longer "team-building" outings in the damp woods for the reluctant troops.

An extremely expensive, time consuming and amazingly inefficient way to change what is basically "how we do things".

So why is "business process change" equal to "organisational change" in most people's minds?

Because the organisational hierarchy is still seen, and used, as the framework for business processes - the mechanism that distributes, controls and measures work in most organisations but pure assembly lines.

But, times have changed: It is not the only available framework anymore. It is only the old framework. And it is the most inefficient framework. Full stop.

Do I need to mention the Thingamy work framework as an alternative? Nah, done that before.