Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

How ‘As-Is’ BAs Deliver ‘Has-Been’ Enterprises

Spread across the world, there is an army of BAs that are daily sending enterprises backwards in time and building ever higher walls between them and the future.  Are these BAs dedicated industrial saboteurs? Far from it! Most are actually conscientious, hard working and well meaning.

So, how can they be doing so much damage? Because they have never learnt, or choose to ignore, some fundamental and critical business modelling rules. Consequently, they daily carry out a modelling practice which, in its cumulative global affect, probably does more damage than any team of dedicated industrial saboteurs could do.

And what is this hugely damaging practice? Modelling ‘As-Is’ Business Processes!

Learn From the Past

In the early days of computing, programmers were so determined to bring benefits to all parts of an enterprise that they tried to computerise everything in sight – and as quickly as possible.  Rather than achieve the anticipated benefits, this created a huge mess and very nearly crippled many enterprises.Fundamental Programming Rule 1

The more enlightened programmers stood back and asked themselves what they were doing wrong. They discovered that their most critical error was that they were computerising how things were currently done in the enterprise. This was, and still is, the biggest mistake that any programmer can make, as it always results in overcomplicated coding and nightmarish data structures. The net result of implementing programs built like this is to drive accelerated chaos and, quite often, bring about enterprise meltdown.

Good computer programmers quickly learnt that they should never computerise the As-Is business processes.  They learnt that before they computerised any part of an enterprise that they must first determine what it is that OUGHT to be happening there. Once they knew this, they could then build an algorithm for this, code the algorithm and deliver programs that took the enterprise to where it needed to be.

Fundamental Programming Rule 1

You cannot build an effective computer program without first building a specification of WHAT it OUGHT to be doing.

Another phenomenon of these early days of computing was the existence of teams (some would say armies) of programmers who would spend all of their time working on one piece of code trying to make it run ever faster and become ‘more efficient’.Fundamental Programming Rule 2

At first glance, this seemed to be an eminently sensible thing to do, until it was discovered that much of the code they were working on was hardly ever, sometimes never, used by the master programs and, worse still, for many modules of code, there was no clear specification of what that piece of code OUGHT to be doing.

So, in effect, they were getting the code to more quickly produce either an undefined or an erroneous outcome.

Fundamental Programming Rule 2

Before you make sure that the code is right make sure that it is the right code.

This is a very well known programming axiom. Again, what it means is that you cannot create or tune a piece of computer code without first knowing what it is meant to be doing.

What’s That Got to Do with BAs?

This may all be a very interesting, but what has it got to do with Process Modelling and BAs? The fact is that Business Processes are nothing more than high level computer programs and, as such, must conform to all of the fundamental logic rules of programming, if they are to bring benefit to an enterprise, rather than plunge it into chaos.

Sadly, most BAs around the globe have never been trained as computer programmers and, consequently, have never learnt these fundamental rules.

This lack of programming training would have been of no consequence if the training they received as BAs included these programming rules. Sadly, most training for BAs (for those few that ever undergo any) does not include any of these critical rules and is, as a result, fundamentally flawed.

If you don’t believe me, have a look at any training program for BAs out there and you will see at a glance if it is flawed or not. How can you tell this? Simply ask the question, “Does it include modelling the ‘As-Is’ processes?” If the answer is ‘Yes’, then this training is fundamentally flawed. It’s as simple as that.

What’s the Solution?

All BAs must be aware of, and daily practice, the fundamental rules of programming that were described above. This means that before they can model or tune any Business Process, they must first be in possession of a specification that unambiguously defines WHAT it is that the enterprise OUGHT to be doing.

There is only one such unambiguous specification and that is the Business Function Model for the enterprise. Without this model, no enterprise can effectively model its Business Processes, Procedures, not even its Data Structures.

Arrogance the Ultimate Saboteur!!!

In the opening paragraph of this post I said that As-Is BAs, in spite of the damage they cause, are not evil saboteurs. On the contrary, they are generally dedicated and well meaning, if ill informed, untrained and misguided.

There is a second group of BAs, whose members are also ill informed, untrained and misguided.  However, the members of this group could definitely not be termed dedicated or well meaning.

What makes the members of this second group so dangerous is that they suffer from the most debilitating character defect that can afflict any BA namely, arrogance!  This defect totally clouds their judgement and blinds them to the fact that they are completely wrong in their approach to Process Modelling and that all of their actions actually damage, rather than benefit, the enterprises in which they work.

Sadly, these analysts are beyond redemption unless, by some profound change in their personalities, they can become humble.

Humble Beginnings – Magnificent Ends

Humility does not mean grovelling or kowtowing to others. It means to become ‘teachable’, the most empowering state for any BA, indeed for any human being.

To anyone wanting to become the best BA they can be I would say, “Become teachable, learn the golden fundamentals and build good foundations”. Through these you will take the quality of your work and the processes in your enterprise to whole new heights.

Spread The Love

If you enjoyed reading this post then please share it with a colleague or friend who might also enjoy it.

Tags:

12 Responses to “How ‘As-Is’ BAs Deliver ‘Has-Been’ Enterprises”

  1. Lew May 11, 2013 3:17 pm #

    Hi John,

    Good information. Do your ought to be models essentially derive from the strategy, goals and tactics that an organization’s senior leadership has defined?

    Lew

    • John Owens May 22, 2013 12:16 am #

      Hi Lew

      The answer is a very definite ‘Yes’. The ‘Ought to Be’ models define all of the key activities (Business Functions) that are required in order to implement the strategy and goals of the organization’s senior leadership.

      They will also include all the necessary Business Functions that are required to measure Key Performance Indicators (KPIs), etc. in order to ensure that the day-to-day business activities fully aligns with this executive view.

      The ‘Ought to Be’ models for data, which are derived from exactly the same source as the Business Functions, ensure that all of the data structures (Product, Party, etc.) of the enterprise are also exactly what are required to support the executive’s strategy and goals.

      Rgards
      John

  2. Garry March 4, 2013 1:34 pm #

    Hi John,
    I am not a BA as such but do know our business and that its processes need to be re-defined. You advice in not doing that in terms of “as is” makes refreshing sense to me. Even the best and most clearly “as is” processes are to set in their ways. As are the best BPM methodolgies which will struggle to make sense from such rigidity and too late a start point.
    As I understand it, “Ought to be” thinking seems to be the “intelligent” part (and/or start) to how a so called Business Intelligence solution could more successfully “optimise” business process management. Have I got the right grasp on this?
    Garry C.

    • John Owens March 4, 2013 10:31 pm #

      Hi Garry

      The starting point for any effective Business Improvement Project are the following two steps:

      1. Get the senior executives(through recorded structured interviews)to define WHAT the enterprise OUGHT to be doing.
      2. From this structured output, build a Business Function Model.

      Having built the Business Function Model, you can then build all relevant Business Processes and, over and above that, you will be able to build a complete Data Model for the enterprise, as all data comes from the Business Functions.

      I hope that this helps.

      Regards
      John

  3. Colin Gibson February 25, 2013 7:08 am #

    Great post John. Poor quality Business Analysis costs a lot of organisations a lot of money.

    I would be interested in whether you would extend the “don’t start with As Is” argument to data. For data modelling, I believe there IS value in understanding the current state. It tends to provide a very big clue to the data that is important to an organisation, and can also provide some insight (that possibly needs to be tempered) to the real world “objects” that need to be captured / represented in data.

    • John Owens February 26, 2013 1:56 am #

      Hi Colin

      Thank you for your kind comments.

      Sadly, all ‘As-Is’ data models are completely fraught with danger. Just as with ‘As-Is’ Processes, you cannot look at an existing data model and infer from it what it OUGHT to be.

      Because so many data models in the past were plucked from ‘thin air’, without any reference to the Business Functions they were meant to be supporting, it would be very unsafe to use them going forward. They will have a whole range of errors that include, but are not limited to, missing attributes, unused attributes, missing relationships, incorrect relationships, duplicate relationships, incorrect UIDs, codes for UIDs, etc.

      The only safe starting point is to model the Business Functions for the business area in question. Once you know the business functions, you can then determine what all of the entities are and the relationships between these entities. Looking at the Elementary Business Functions will give you all of the attributes that are required.

      Once you have built this new data model, you can then cross check it with the existing data model for this business area to make sure that you have missed nothing obvious. However, just because something exists in the old data model that is not in your new one, does not mean that it should be included in the new one. It is simply a means to check that you have not inadvertently missed something vital.

      I hope that this helps.

      Kind regards
      John

  4. Jack February 25, 2013 2:32 am #

    John – great article. Challenged me. What advise would you have for me as a self taught BA who uses ‘As-Is’ modeling for no other reason than because it seemed like the most logical approach? Do you recommend any formal training? Looking forward to employing business process modeling on what the process ought to be on my next project.

    Thanks!
    Jack

    • John Owens February 25, 2013 3:05 am #

      Hi Jack

      Thanks for your kind feedback and for having the courage to admit that the article challenged you.

      The best advice I can give you is to purchase, read and work through my e-book  IMM Business Function Modelling available from the IMM Online Store.

      This really is a ‘Course in a Book’ as it not only describes in detail the methods and the reasoning behind Function Modelling, it also has exercises that will take you through the whole thinking process of performing effective Function Modelling. Better still, it has detailed worked solutions for each exercise that will explain exactly what thinking processes you need to apply in order to arrive at a quality solution first time, every time.

      You will be taking absolutely no risk, as the book comes with a full 30 day money back guarantee. The good news is, both for you and for me, is that in 12 years no Business Analyst as asked for the money back.

      If you need any further information, please do not hesitate contact me.

      Kind regards
      John

  5. Dee February 14, 2013 8:17 pm #

    Great read & point of view.
    There is another view here on the As-is process.
    http://fluxicon.com/blog/2011/01/dont-skip-as-is/

    • John Owens February 15, 2013 4:36 am #

      Thank you for your feedback and for the link to the alternative point of view on modelling the ‘As-Is’ Business Processes.

      I have read the article with interest. I was honestly hoping that somebody would come up with a really good argument in favour of the ‘As-Is’. Sadly, I was disappointed. All the arguments put forward are false arguments trying to support a flawed approach to business modelling.

      Even the very famous, ‘If you don’t know where you are, how do you know how to get to where you want to be?’ is totally flawed, as getting from where you are to getting to where you want to be is called a Project Plan.

      The fact remains that looking at your current business processes will give you no clue to what they ought to be. The only way to know what your business processes ought to be is by defining what they ought to be!!! There is simply no way around this.

      Many of these bad practices have come about as a result of untrained analysts who have absolutely no idea how to find out from the enterprise WHAT it is that it OUGHT to be doing. They also have no idea how to model this and simply model the the only thing they’re capable of modelling (although it is of absolutely no value to the enterprise), the current business processes. They then lie to the business by telling them that this is the only possible starting point. It is for them, as bad analysts. However for the business, it is the worst possible starting point.

      Now, it is very important to know that when I talk about ‘As-Is’ that I am talking about ‘As-Is’ Business Processes. I am not saying that analysts should not document existing technology, existing priorities, etc. On the contrary, all of these will need to be known when going forward as it is vital to ensure that these will support what the enterprise ought to be doing.

      What I am very definitely saying is that modelling ‘As-Is’ business processes is a complete and utter waste of time!!!

      Again, thanks to your input.

      Regards
      John

  6. Richard Ordowich February 13, 2013 10:17 am #

    The capability that most BA’s and for that matter programmers lack is the ability to think systemically and socio-technically. What industry doesn’t need are more myopic programmers for whom every problem is a programming problem.

    Technology is a tool and selecting the proper tool requires understanding the system and the human behaviors. Programmers are reductionists, trying to “engineer” a business process into a series of discrete, repeatable non-humanistic tasks; Taylorism for today’s world.

    BA’s and programmers need training in sociotechnical systems theory to help them design new solutions that are a balance between technology and humans. Not all problems can or need to be solved with technology.

    • John Owens February 13, 2013 11:29 pm #

      Hi Richard

      Thanks for your input.

      I totally agree that all problems do not need to be solved using technology. This post is not about technology. It is about ensuring that BAs have the skills to model Business Processes in a way that will result in them doing what they OUGHT to be doing, as opposed to simply modelling how things are currently done.

      The main problem that enterprises are experiencing globally is not that of myopic programmers but of blinkered (some would say, blind) and untrained Business Analysts.

      Good programmers and good BAs are worth their weight in gold. When you’ve worked in enterprises where these people are working you will be amazed and inspired at what they achieve. Sadly, far too few programmers (and far fewer BAs) now have the necessary skills and ways of thinking that are required to bring real benefits to any enterprise. The standards in business modelling and programming are now lower than they where 25 years ago.

      I find this totally unacceptable. BAs are playing a wider and wider role in enterprises which, instead of spreading high quality processes, is spreading a totally flawed approach to process modelling. This has got to stop.

      Regards
      John

Leave a Reply