I am working as Executive Management Advisor for many years and many clients and assisted them to restructure their organisations and to develop or restructure Business Process Models (BPM). There are many typically used methods which a Business Analyst may use when facilitating business transformations and they have all got fancy, if not scary names:
. CATWOE: Customers, Actors, Transformation Process, World View, Owner, Environmental (and Regulatory) Constraints;
. Five Why's;
. HEPTALYSIS: Market Opportunity, Product/Solution, Execution Plan, Financial Engine, Human Capital, Potential Return, Margin of Safety;
. MOST: Mission, Objectives, Strategies, Tactics;
. MoSCoW: Must have, Should have, Could have, Would like to have in the future;
. PESTLE: Political, Economic, Sociological, Technological, Legal, Environmental;
. The famous SWOT: Strength, Weaknesses, Opportunities, Threats;
. Six Thinking Hats;
. Six Sigma;
. VPEC-T: Values, Policies, Events, Content.
All these impressive acronyms help to describe an individual approach; the aim, however remains the same: business process engineering, which is regarded to be the backbone and most important foundation for every well managed organisation - regardless of size by the way. The optimization process requires human intervention and skilled, insightful, ideally experienced professionals.
Interestingly enough though: according to my experience the perfect analyst should not be a specialist in the actual technical or scientific process. I was once asked what I did know about food technology and I replied "basics only", but that I hoped my counterpart who was a Professor with a PHD, would be the expert in our team, as I knew nobody could beat his expertise. I am convinced that a consultant claiming to be an expert on the subject matter not only limits, it actually disturbs the project. A successful business analyst needs be able to understand each organisation, seeing the whole process flow with a neutral bird's eye view.
It is helpful to comprehend a business process as an on-going living cycle which pictures how work gets done. By identifying the particular sequence of work events across time and place, with a beginning, an end and with clearly defined inputs and outputs the analyst identifies shortcomings and saving potentials. Critically reflecting how a business works typically goes hand-in-hand with a re-organisation and can - in my experience - achieve conservatively between 10 % and 20 % savings - without hurting anybody too much.
So this is the ideal set-up: a willing, supportive client, a (group of) skilled business process analyst(s) together with internal process experts forming the project team.
But despite perfect arrangements why do Business Process Management (BPM) projects ever so often fail or at least do not achieve the expected end result? We analyse problems, suggest solutions, accompany the transformation, manage the change and when it fails we feel pointing the finger at the client: "internal politics, nepotism, ignorance, the good people left, incompetence of implementing team, resistance to change."
I won't play the whistle blower. Of course I had similar projects. I had clients who only implemented the processes they dared to change and left out the rest - no wonder the project failed. I was asked to leave prematurely and then the client made all sorts of peculiar alterations. I learned my lesson: if my name is at stake, it is of utmost importance to see the implementation phase through.
My 25-odd years' experience illustrates a more reasonable explanation for failing like this: once we leave, we barely get the chance to see our recommendations life over a period of time. Hardly ever we are hired to act as a permanent advisor; we are kept uncertain about the short, much less the long term success. Pretty much like the tax payers association; they write fancy reports where the tax payers' money is wasted and by next year nothing's really changed. The same with us: we actually do not leave an ultimate and tangible legacy behind.
What is needed? Currently I am evaluating a solution which might fix the problem, which I will share publicly, once done: a simple, reasonably inexpensive but workable solution which ensures that the processes are implemented as defined or if altered remain functioning.