What the Heck Is Enterprise Analysis Part 2

In Part 1 of this article, IIBA subject expert Robin Goldsmith described and critiqued the inappropriateness of what the IIBA Business Analysis Body of Knowledge Version 2 (BABOK® v2) calls “Enterprise Analysis” (EA).   In this Part 2, he addresses some additional ideas about and suggests some alternatives and resolutions of What the Heck Enterprise Analysis Is.

Problem Pyramid™

Figure 3 is the powerful Problem Pyramid™ described in my book and several articles.  I believe the Problem Pyramid™ provides the appropriate structure for guiding effective business analysis, both for initiating and carrying out projects, whether for what BABOK® v2 calls projects or for topics that truly fit within Enterprise Analysis.

The Problem Pyramid™ clearly distinguishes the Business Need Problem, Opportunity, or Challenge (Box 1) from the REAL business requirements (Box 5) deliverable whats that solve the Problem when accomplished. 

The Problem Pyramid™ discipline also defines Current-Now (Box 2) and Goal (Box 3) Measures of the Problem that determine quantifiable Value; and the Problem Pyramid™ process applies systematic evaluation guidelines to help assure the Problem, its related Measures, and the other Boxes are right.

By explicitly identifying and systematically evaluating accuracy of the Causes (Box 4) of the Problem producing the (Box 2) Current Measures, the Problem Pyramid™ assures the (Box 5) REAL business requirements indeed do provide the Value by reducing or eliminating the key (Box 4) Causes and thereby achieving the (Box 3) Goal Measures.  The high-level (Box 5) REAL business requirements in the Problem Pyramid™ that will be the subject of implementation projects need to be driven down to detail.

BABOK® v2 Solution (Box 6) hows are clearly responses to (Box 5) REAL business requirements whats, not merely a decomposition of them into greater detail.

So What the Heck Is Enterprise Analysis?

At the very least, it should be incontrovertibly evident that BABOK® v2 EA is not Enterprise Analysis.  What BABOK® v2 calls EA assumes enterprise-criteria-based senior executive involvement and includes defining Business Needs and Goals, defining Solution Requirements, Business Cases, and Project Initiation.

One cannot assume any of these supposed EA activities actually involves enterprise-level analysis or senior executives.  All can pertain to situations which don’t reach enterprise levels.  Even if executives are making decisions doesn’t mean they are doing so wisely, with suitable information, or from an enterprise view.  Moreover, all projects need what BABOK® v2 calls EA, but typically only the larger ones are likely to get EA as BABOK® v2 describes it.

Defining Business Needs and Goals is essential for all projects and is most effective at the project’s start; but it doesn’t require a separate EA and for most projects doesn’t need an enterprise or even executive perspective—although to be fair, both perspectives are needed more often than they probably are obtained.  Just because a Business Need is corporate or otherwise involves multiple business units within the enterprise doesn’t mean defining it constitutes Enterprise Analysis.  For example, the enterprise’s General Ledger involves plain Business Analysis and doesn’t extend to Enterprise Analysis.

Defining what BABOK® v2 calls Solution Requirements also doesn’t necessarily need either executive or enterprise views.  In fact, in most instances senior executives are the least qualified to identify suitable Solutions.  Moreover, BABOK® v2 fails to recognize the need to discover high-level and detailed REAL business requirements whats before it’s worthwhile to design Solution Requirements hows to satisfy the whats. 

REAL business requirements can and should be used by executives and for Enterprise Analysis; but all projects need to discover their REAL business requirements, not just ones involving executives or the enterprise.

Financial feasibility analysis Business Cases are valuable for assisting decisions about the advisability of choosing one proposed Solution over another.  Business Cases often are used by executives and frequently are required for large initiatives, which in fact may be enterprise in nature.  However, just because Business Cases may not usually be prepared for non-enterprise projects or for decision makers below the executive level, doesn’t mean a Business Case couldn’t or shouldn’t be prepared.  Developing a Business Case does not necessarily mean it involves the enterprise or executives.

Many if not most projects don’t deal with enterprise issues and generally are initiated without necessarily considering them in an enterprise context, often by non-executives.  On the other hand, most Enterprise Analysis is likely to be conducted within the context of a project to implement or achieve the results of the analysis.  Thus, the presence of a project is not what makes something Business Analysis rather than Enterprise Analysis.

So, Really, What the Heck Is Enterprise Analysis?

It’s possible Enterprise Analysis doesn’t really exist.  After all, I think people would consider Business Analysis of accounts payable, Business Analysis of accounts receivable, Business Analysis of general ledger, Business Analysis of capital budgeting, Business Analysis of manufacturing, and Business Analysis of marketing all to be instances of the same thing--Business Analysis.  The fact that some of them may need to be integrated and coordinated doesn’t by itself turn their Business Analysis into Enterprise Analysis. 

Undoubtedly, some things that people want to call Enterprise Analysis, perhaps to elevate their importance, in fact are just Business Analysis.  It could seem as though it ought to be Enterprise Analysis because it affects multiple or special parts of the enterprise, or even goes outside the enterprise.  For example, some may say that Business Analysis of something pertaining only to executives would turn it into Enterprise Analysis.  Does Business Analysis of issues regarding keys to the Executive Washroom or Executive Parking Spaces qualify for being called Enterprise Analysis?

It’s also possible Enterprise Analysis does exist but is sort of like obscenity in that I can’t define it but I know it when I see it.  This probably occurs a lot but isn’t very helpful.  Let’s see whether instead we can find some elements that more reliably indicate Enterprise Analysis.

Strategy and Enterprise Analysis

Strategy is the one topic that seems most amenable to agreement as pertaining to the enterprise and therefore I suppose to Enterprise Analysis.  Of course, it invites the question:  What the heck is strategy? 

To me, strategy represents the thought process rationale guiding the way the organization goes about achieving its Vision and Mission in accordance with its Values.  That is, strategy is not Vision, Mission, or Values although Strategic Planning generally starts with identifying the enterprise’s Vision, Mission, and Values. 

Nonetheless, I don’t think Enterprise Analysis is actually the way an enterprise defines its Vision, Mission, and Values.  Rather, they are formulated by true leaders (as opposed to those in leadership positions); and it’s questionable how much actual analysis goes into their creation.  However, because Vision, Mission, and Values often have not been articulated, a form of analysis may be needed to identify them and make them explicit. 

It seems to me that strategies can and often are formulated without necessarily engaging in Enterprise Analysis or even conscious Strategic Planning.  In my experience, many organizations’ strategies are at best implicit and frequently are not known well enough to carries out strategy’s primary purpose of guiding actions.

That’s especially true of start ups.  Certainly very few enterprises start by consciously planning their strategy.  Instead, Strategic Planning almost always seems to occur in established organizations, usually to figure out what their current strategy is, why it’s not working as well as they want for them, and what it should be to achieve better results.  Also, Business Analysis often should include understanding what the strategy is.

Furthermore, Strategic Planning seems to be a role unto itself performed by Strategic Planning specialists.  Ironically, organizations that have Strategic Planning Departments often can end up creating Strategic Plans extraneous to the true leaders’ thinking.   When the leaders are not truly invested in the strategy, it seldom succeeds in guiding activities throughout the organization that achieve desired successful results. 

I can’t recall anyone considering Strategic Planning to be something performed by an Enterprise Analyst or as part of Enterprise Analysis. By the way, developing a Marketing Plan similarly is an enterprise-oriented activity that is performed by Marketing people, not by Enterprise Analysts.   

On the other hand, I’d certainly acknowledge that Enterprise Analysis would be helpful input to leaders formulating strategy.  Moreover, Enterprise Analysis seems essential to determining how to implement a strategy and evaluate the strategy’s effectiveness.

Enterprise/Business Architecture/Modeling and Enterprise Analysis

Business Models, Enterprise Architecture, and Business Architecture are additional terms that generally would be considered related to Enterprise Analysis.  The way BABOK® v2 defines these terms may not be optimal but seems close enough for this discussion:

• Business Models [are] how the organization generates profits or otherwise accomplishes its goals.  (Section 8.3.3.2)

• Enterprise Architecture: Describes the organizational units that exist, their interac­tions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationships within each organizational unit. (Section 2.2.3)

• Business Architecture A subset of the enterprise architecture that defines an organization’s current and future state, includ­ing its strategy, its goals and objectives, the inter­nal environment through a process or functional view, the external environment in which the business operates, and the stakeholders affected by the organization’s activities. (Glossary)

Some people treat these two types of Architectures synonymously; and some also consider them the same or tightly coupled with Business Models.  Many people assume they refer to the Zachman Framework, which is by far the best known of several Enterprise Architecture models.  I prefer to think of these terms generically.    

It seems to me that academicians often approach these Architectures as somewhat of an end in themselves to be designed in the abstract by specialists and then imposed upon an organization.  I think it’s far more fruitful to treat Business Modeling, including Enterprise and Business Architectures, first as informative ways to analyze an enterprise in order to better understand how it does things and why it’s getting the results it gets.  

In fact, I’d go so far as to suggest as a reasonable starting point that:

Author:  Robin F. Goldsmith, JD is President of Needham, MA consultancy Go Pro Management, Inc.  He works directly with and trains business and systems professionals in requirements, quality and testing, metrics, ROI, and project and process management.  IIBA BABOK® subject expert and reviewer, participant in developing the IIBA Handbook of Enterprise Business Analysis, and TechTarget SearchSoftwareQuality.com testing and requirements subject expert, he is the author of the Proactive Testing™ and REAL RIO™ methodologies and the Artech House book, Discovering REAL Business Requirements for Software Project Success. [email protected]   www.gopromanagement.com    www.ProveIT.net