Hypothesis based approach to problem solving (How do wolves eat an elephant?)

How do wolves eat an elephant?

A pack of wolves attack an elephant, they chose their preferred areas to attack on the elephant's body, they then attack and bring it down, they then start eating bite by bite, in a matter of time the elephant is finished, midway through their eating if a flock of birds starts hovering over their heads then they eat the meatiest of the pieces and leave the rest of it.

Lets decompose the above sentence
A pack of wolves attacks an elephant (they have attacked many elephants before and hence they know how to attack elephants, i.e. they know how to solve this problem even before they have met the problem), they chose their preferred areas on the elephant's body to attack (they do a basic planning and positioning before they physically attack, i.e they plan their approach to break down the problem into pieces), they then attack and bring it down (they break down the elephant, if its a stronger elephant then they need to change their attack method, position, numbers; i.e they break down the problem into pieces and if situation demands they adapt their way of breaking down), they then start eating bite by bite (i.e. they solve the problem), in a matter of time the elephant is finished (i.e. they have solved the problem), midway through their eating if a flock of birds starts hovering over their heads then they eat the meatiest of the pieces and leave rest of it. (i.e they solve the biggest problems and quit).

The commentary above, in essence, explains the "Hypothesis based approach to solving problems".

The difference between wolves and consultants is that everyday wolves come across elephants who are all body-types and behavior whereas consultants (or people in general) come across problems which is different every time and this is the reason if you are facing a new type of problem and very keen to learn how to solve it then you should keep reading.

Consultants apply the same logic, as wolves eating an elephant, of breaking a problem down into pieces with the only difference being, consultants keep on trying to cut the problem in different ways till they are able to break it down into chew-able pieces, rest of the work is the same as wolves'.

Hypothesis based business problem solving is a very methodical approach of breaking down a problem into pieces and solving the most important ones.

Once clients gives consultants a big business problem they even starting the engagement think of ways of breaking it down into smaller sub-problems, once on the ground (at the beginning of consulting engagement) they validate if they presumed approach of breaking-the-problem-down was right or not, re-adjusting their problem cutting method continually so the problem cuts nicely and into the smallest possible piece which does not interfere with other problems boundary, then trying to find out solution-options for each of the sub-problems, if time does not permit then they solve the biggest of the problems and ignore the small problems. hence getting the best results with shortest efforts.

Now if its so simple to solve problems then why do we need a full blog on this article. The answer: the challenge with us is that there is a team of consultants working in a complex client environment where there are many unknowns, time is short, expectations high and reputation at risk. This is why the team from  the top to bottom levels needs to work in coordination to solve complex business problems. 

Let us first start by understanding the difference between a problem and its sub-problems

Problem: 
A problem will always a business problem; it has to either generate more money or reduce costs for business.

Sub-Problem:
A big business problem can be broken down into smaller sub-problems which may be of any of these types E.g. customer-interaction issue, supply chain issue, analytics issue, information access issue, issue with any type of business-operations, risk due to an external business environment; issue with marketing, information system related issue, people related issue and the list goes on. To solve a sub-problem you need consultant who have expertise in solving each type of problem.

Hypothesis based Problem solving process can be summarized into following steps:

    1. Define the Exam Question (aka. Problem)

    2. Elaborate the sub-questions (aka. Problem Hypothesis)

    3. Prioritize problem Hypothesis

    4. Define solution-options

    5. In light of the recent findings modify and redo the above steps 2, 3 and 4

    6. Are we hitting the target? If required, adapt our approach

    7. Measure effectiveness of solutions in solving the main Exam Question

In solving complex business problems a team has a hierarchy with different roles and to keep it simple i will suggest only two roles
               Engagement Leads
               Consultants

Let's examine their roles:

Engagement Leads: 
They leads the overall view of the problem and its solutions, typically a Business Architect who knows the business context (the dollar aspect) of solving the problem. We could have named thsi role as Chief-Architect but to keep it simple i have named it as such because most Consulting companies assign Engagement Leads to perform this kind of role. A consulting engagement generally has only one person working in this role. Engagement Directors are people who work on a part-time basis on project and guide the Engagement Leads in complex business problem solving. Engagement Lead manages the progress of overall problem solving process and their inter-dependencies and he is not concerned with nitty gritties of each sub-problems as that is the scope of Consultants. In a RACI matrix the Engagement Leads are Responsible and Accountable for Steps 1, 3, 6 and 7. They are consulted for Steps 2 and 5.

Consultants: 
A group of people working under the Engagement Lead trying to solve a sub-problem; their skill-sets differ according to the nature of sub-problems. Their main aim is to solve that sub-problem and control all the risks and issues hindering their problem solving process. They escalate their concerns to the Engagement Lead. In a RACI matrix the Consultants are Responsible and Accountable for Steps 2, 4 and 5. They are consulted for Steps 3 and Informed about step 6.

Detailed Process: 
During the Hypothesis based approach to problem solving at any point of time your team should be able to report on the progress of the Hypothesis validations. And this is why you would need a tool to track the work. I have used MS-Excel to manage this but there is a need for an application to do the hypothesis management.

Depending upon your success or failure rate during the work your team can take a go/no-go decision. 

....Keep watching this page; soon i will be adding more thoughts on this.

Decision Support System (DSS) mind-map

Decision Support System (DSS) mind-map

The following mind-map is something that I had used on a project were we were developing DSS proof of concept for a client for their asset management domain.

All in all i have found this simple approach very handy.
1. Identify the areas of biggest cost savings in asset management and focus your energy in this area.
2. Find out the details of the asset management decisions currently taken
3. Find out what other information and in which form the decision makers want to see
4. Find out a way to extract the data that would create the information needs
5. Present the information in a format which is easy to understand.

For Point numbers. here are the skills your team would require
1. For point-1 above you will need finance skills
2. For point-2 above you will need Business Process Mapping and Business Analysis skills
3. For point-3 above you will need Data Architecture and Analytics skills
4. For point-4 above you will need Data Architecture skills
5. For point-5 above you will need Analytics and Solution and Architecture Skills

Application Rationalisation mind-map

In this short time i am posting just an Application Rationalization mind-map

Target Operating Model (TOM) and Enterprise Architecture (EA) comparison

So what is the difference between a Target Operating Model and Enterprise Architecture?

TOM simply tells Businesses the direction in which it needs to go, based on very high level SWOT Analysis, financial modelling etc. whereas EA provides you the vehicle to go in that direction.

TOM typically, is a term used by management consulting firms; looks at the high level levers of an organisation to show how an Organisation can be improved strategically. At the end of their 1-3 months engagement consulting firms lay down a big picture of the Current Operating Model (COM) a Target Operating Model (TOM) and a business case of how to reach the target state. There is no detail how each project, program suggested as part of the TOM interfaces with each other, no details of how you can measure the outcomes of programs; all in all I have seen TOMs can give you high level direction of where to fix problems, details of how to do it is something that the organisation has to think of. If a company engages the same consultancy to execute the TOM then it’s a different story. Without an Enterprise Architecture in place a TOM can’t deliver much.

Enterprise Architecture is the thing where the rubber hits the road. Once you start to implement the Programs, projects suggested in TOM you need a framework to execute them effectively. Enterprise Architecture provides that framework.

While TOM is transitional, EA stays with the organisation for years together. The Enterprise Architects are full time folks working and staying with your organisation and continuously building and improving your organisations Enterprise Blueprint.

While TOM works at Business strategy Level, EA works at Business Management Level.

TOM is liked by the CFO, EA is liked by CIO.

Till date the most famous Operating model framework I have seen is described in the book "Enterprise Architecture as Strategy: Creating a Foundation for Business Execution" where it describes four TOM models.

1. Low Integration, Low Standardization - the Diversification Operating Model 

2. High Integration, Low Standardization - the Coordination Operating Model 

3. Low Integration, High Standardization - the Replication Operating Model

4. High Integration, High Standardization - the Unification Operating Model 

Not much work has been done in open space about Operating Models. Most of the work on TOM is embedded in Management Consultancies power-point slides and it never comes out in the open.

I have noticed EA communities opening up and speaking about EA in public domain but most Management Consultancies don’t speak about TOM in the open.

But both TOM and EA are there to positively impact businesses so there is an urgent need for Businesses to ask Mgmt. Consultancies to develop their TOMs based on an enterprise’s EA.

In fact it’s only in organisations where Enterprise Architecture (EA) does not exist that TOM survives. If a business has decent EA practice then there may not be a need for TOM as the Business Architecture (BA) part of EA covers what TOM can do.

Most Enterprise Architects I have seen come from IT background (including myself) and hence they focus on the Application, Data, Technology part of the Enterprise Architecture, they mostly forget about the Business, Organisational-Unit, Finance architectures and that is why all non-IT communities being completely unaware of Enterprise Architecture support the TOM concept.

(I have read somewhere that most decision makers agree that they don’t have the relevant data at hand to make decisions but they have to make decisions every-time; which leads to another lengthy discussion on the ad-hoc way in which Information is managed as an Asset today and this can be the topic of separate blog later on)

Limitations of TOM
TOM Design comes from Finance, HR world and is mostly targeted to deliver something on a quarterly basis, mostly taken up in an organisation on a Business Case Level. It can at best provide incremental improvements where-as it’s looked upon by Businesses as something that can provide strategic improvements. No way in 2-3 months time you can assess the situation of an enterprise and recommend improvements. Consultants doing a 2-3 months analysis of an enterprises’ Current Operating Model and recommending a Target Operating Model is very much like a doctor checking a patient’s temperature with a thermometer (Pareto, SWOT, PEST, Excel) and recommending (on a PowerPoint) him a heart-transplant.

While Business-Clients might rightly agree the need for their enterprise getting a heart-transplant because the temperature is showing up as so high (the as-is analysis shows so) they may be wrongly doing a heart-transplant where a brain-transplant is required.

But till the time the enterprise recovers from the major operation neither the Consultant nor their clients can prove or dis-prove if it solved the problem; and by then another new quarter comes up and the time to do another TOM re-design.

Limitations of Enterprise Architecture
Enterprise architecture today is in a state where the Systems Integrators or IT consulting companies come to the Business-Clients and provide them with point-solutions very much akin to a doctor knowing the patient for many years and based on their knowledge of patient suggesting him to take a paracetamol to get over a fever.

The real limitation of Enterprise-Architecture as a science is that it’s thought of as IT folk’s gadgetry. In actuality, it should be exercised as a tool that reflects an Enterprises’ situation from a Systems (or holistic) Perspective. Without Finance, HR, Organisation-Units etc. included in an Enterprise Architecture it will always be in-complete and will never get a buy-in from the CFOs and CEOs.

Enterprise Architecture is the, lesser known, body-part of an Enterprise into which a consultant should actually probe-in his diagnostic tools to assess the Enterprise Current Operating Model. Until Businesses develop Enterprise Architecture they have to rely on Management consultants’ major-transplants or System Integrators quack-treatments to get the illusion of getting rid of their ails.

Whether it’s the limitation of the Enterprise-Architecture approach or that of the Operating Models approach, Businesses are going to keep on suffering the till a combined approach on EA and TOM is adopted.

Conclusion
If due diligence is done to Finance, Organisational-Unit, Supply-Chain, Regulatory Architecture as part of company wide EA adoption then it will become very easy to develop real TOMs.

Most EA product vendors can then support TOM dashboards which can provide businesses right-info (based on real hard facts and not based on the board room discussions) at right-time to take decisions to go into the right-direction from an ailing enterprise towards a healthy prospering profitable business.

Need for an Enterprise Blueprint

Need for an Enterprise Blueprint

Enterprises today are managed in a tribal fashion. In a big company we have different tribes very protective about their assets, not open, not adaptable, un-welcoming outsiders. There is a big reason why people behave like this and it’s that telling outsiders about their system may lead to some kinds of changes happening in the ecosystem and as a result then may need to incur extra cost, risk and time keep their show on.  

We all know that in today’s business, change is the only thing that is constant. The sheer complexity of enterprises today baffles people; it makes them understand enterprises in exactly the same was as ancient man understood the universe and solar system; fearing the sheer size and complexity of an enterprise as if it has some demonic powers. Rather than use an enterprise to their competitive advantage people are worried most of the times about barely surviving in it.

Enterprise efficiency is not the term people talk about mostly because efficiency leads to mostly reduction in headcounts; and then there is another issue; there is so much mess to clean-up in an organisation that people don’t know where to start.

Many frameworks have been proposed to improve enterprise efficiency

1.    Six Sigma

2.    Total Quality Management

3.    Enterprise Architecture

4.    Technology Solutions like SOA, Cloud, Big-Data etc.

But the problem is they are way too complex for a humble employee to understand.

Xamtrex Consulting’s Enterprise Modelling System (EMS) product is one such product that provides you a way to organise your enterprise’s people, processes, applications, data, technology, business-rules (aka Enterprise-Entities) in a way where you can see the relationships between them.

EMS lets you understand your Enterprise using EMS’s unique ability to show you the single truth about your company’s Enterprise-Entities.

This assists people in creating a single blueprint of the enterprise and thus being able to manage it easily. To learn more about how Xamtrex can help you use EMS please visit our website http://www.xamtrex.com