» 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.
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 220.127.116.11)
Enterprise Architecture: Describes the organizational units that exist, their interactions 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, including its strategy, its goals and objectives, the internal 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:
Enterprise Analysis is a form of Business Analysis for which it’s relevant and perhaps necessary to understand the enterprise’s strategy, Business Model, and Enterprise/Business Architecture in order to understand an enterprise Business Need Problem, including its Current and Goal Measures, Causes of the Problem, and REAL business requirements that reasonably would solve the problem. REAL business requirements for solving enterprise Problems could be likely to include changes to the current Business Model and/or Enterprise/Business Architecture.
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@example.com www.gopromanagement.com www.ProveIT.net
I just finished reading part two of what the heck is EA. I’m left with the impression that the existence of EA and perhaps strategy is a definite maybe. However, I do agree with your basic problem pyramid concept.
With reference to the problem pyramid; let us consider what is known as the three part lag. First, the organization must discover the problem, second, the organization has to define and implement as solution to the problem, third, and the organization has to determine if the solution worked. These three time periods can be days, weeks, months or of sufficient duration such that the corporation is no longer a going concern. In cases like this time is the enemy.
Moreover, with respect to problem solving and decision making; I would assert that the ability to solve a problem is a function of the analysts’ skill and the analytical tools available to the analyst. I also suggest that uncertainties in the form of human, organizational and knowledge uncertainties play a part in the scheme of things.
Write more articles.
I fully agree with your concept of the need to identify the real business requirements.
But, I seem to have a different interpretation of the BABOK than you.
First, I do not understand how you can state that the BABOK assumes senior executive involvement in its definition of EA. I just re-read the EA chapter of the BABOK again and, while it does state that every effort should align with corporate strategy, presumably set at the executive level, I see nowhere else where it even remotely implies that executive involvement is needed.
Secondly, what the BABOK calls solution requirements can also be referred to as functional requirements. They define the what. As a result, your statement that the BABOK " ... 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" is not valid based on my understanding.
Lastly, while Enterprise Analysis may not be the proper term, I feel that it does exist as defined in the BABOK. It aligns to the "Investigate" phase of the standard PLC and should always include at least a summary analysis of the enterprise to determine the priority of the problem or idea (Should we invest in this or something else?). It is the input to portfolio management / governance.
I fully agree with your premise that most executives should not be involved in the granular operational decisions. It’s not their place to do so.
Rather the role of the CEO and the Executive Team is to lead the enterprise, set their Strategy, set the enterprise’s Objective, defining the Business Models, and aligning the various divisional and operational units towards a common shared vision.
Since most enterprises over the last ten years have been flattened and have reduced the complexity of the reporting structures to three or four management levels it follows that Enterprise Analysis begins at the top and cascades down to the individual employee. I would add that enterprise analysis should be seen as an analysis that touches all parts of the enterprise, assuming a holistic view and that originates at the top but that takes and seeks the consideration and participation of all.
Concerning Strategy again I fully agree with your definition. Strategy is the process by which an enterprise defines itself within its unique environment. The Enterprise set its objective and unites its people towards a common goal through its mission, vision and value statements.
The Enterprise can be seemed as articulating (to its employees) who they are, what they stand for, and where they should see themselves in the future. All this is done with the specific goal to increase its alignment and reinforcing its differentiation. It is trying to provide a unique value proposition to its customers that no one else can.
Again I agree with your statement that strategies are often formulated without any analysis or any kind of consultation neither with their clients or employees. It is not surprised then that some many Strategies fail and so many Strategies sound totally artificial, they are.
Thank you for your incisive observations.
You wrote; it follows that Enterprise Analysis begins at the top and cascades down to the individual employee. I would add that enterprise analysis should be seen as an analysis that touches all parts of the enterprise, assuming a holistic view and that originates at the top but that takes and seeks the consideration and participation of all.
Zarfman writes; perhaps, however, the enterprises that I’ve worked in ranged from thousands of employees to those with one hundred or more were all afflicted with what I call enterprise disorder. By enterprise disorder I mean turf wars, politics, individuals trying to climb the corporate ladder for their own gain, wildly varying skill levels, infighting, backbiting just to name a few. I’m not sure that EA can adequately address these vary real problems. In fact absent the foregoing problems I’m not sure EA in its current form (what ever that is) can effectively analyze dynamic enterprise systems.
Zarfman writes; strategy is one of those easy to talk about tasks, unfortunately vary hard to accomplish with a high degree of accuracy. I consider an enterprise to be a dynamic system, that is to say a system that varies with time. Moreover, the environment that an enterprise exists in is also dynamic.
You have to see the role of the Enterprise Business Analyst (EBA) as a
consulting role, working with the executive team; and as such acting in an advisory position. Management remains responsible to make the decisions and take the required actions as in the case of internal politics or managerial problems.
I too have worked in companies ranging from start ups of several individuals to thousands of employees; but you have to see EBA role more as a senior role and as such most probably would be in major corporations brining their Business Analysis expertise to the executive board room.
As you pointed out certain companies are riddled with managerial problems
and do not have the structures, culture or desire to think in terms of a strategy or a
holistic approach to company initiatives, they simply lack the business maturing and expertise to do enterprise analysis.
As you mentioned formulating, implementing and evaluation a business strategy isn't easy, it requires a highly competent and highly trained management teams with the expertise. How many companies don't even have a mission or vision statements, let
alone a strategy? How many just go by their gut feelings and past performance and total disregard any analysis and strategic thinking or planning? Lots!
Enterprise Business Analysis and Strategy is not for the faint of heart; they are not easy to build, they take time, planning and talent individuals who have the experience. You are right, lots of companies talk about it and write cool looking Strategy Statements but have no idea what they are doing or how to implement them.
Many more companies do not empower their employees, do not
consult then and do not ask for their participation in creating a strategy. It not surprising then that their strategies are simply limited to the board room, are meaningless and fail to create any differentiation.
As you and I know there are a lot of companies out there that are far from cutting edge and survive on a daily basis blown about by competitors, economic down turns and changing customer needs.
What I am trying to say like Robin is that there is a better way; and that enterprise business analysis and strategic planning have a role in insuring a company's survival. It's not just a theory, it’s a fact that top notch companies analyze, plan and act.
But I again have to agree with you; building a Strategy is difficult it is dynamic and as such has to be constantly evaluate and changed because companies change and their environments change.
The strategic process necessitates reviews, evaluations and adjustments.
Thank you for your thoughts.
I agree BABOK v2 does not specifically refer to senior executive management. However, what BABOK v2 describes as “Enterprise Analysis” (EA) very clearly positions it within project initiation, which is a management function, and assumes that decisions about whether or not to initiate the project are based upon enterprise considerations, which typically are the province of senior or executive management.
Some, but by no means all, projects in fact are initiated in the manner BABOK v2 EA suggests applies to all projects. Enterprise considerations often are not and do not need to be part of project initiations. BABOK v2’s description of identifying the business need is only partially accurate and by no means is limited to (especially explicit, separate) project initiation as BABOK v2 indicates. In short, what BABOK v2 calls EA seems not to be what EA really is; and all the things BABOK v2 includes within EA, plus more, do need to be addressed with a meaningful body of knowledge, just not as EA.
I have not said that executives should not be involved in the granular operational decisions. In fact, they often are. Effective EA takes dynamics, politics, and the like into account for all affect what and how an organization does and can function. Yes, effective organizations align and drive enterprise considerations into decision making throughout the organization; but relatively few actually do this effectively. That doesn’t mean that those below senior executive levels have reason or suitable knowledge/ability to engage in EA. Conversely, many decisions don’t involve enterprise considerations, even those made by senior executives. The fact is that many senior executives don’t have the knowledge/ability to do effective EA either, which is why guidance for them an their Enterprise Business Analyst advisors/assistants is so important.
Many requirements authors/authorities, including those who wrote BABOK v2, and others have difficulty understanding the differences between what I call REAL business requirements and product, system, software, solution, functional requirements/specifications that they and BABOK v2 refer to as _the_ requirements.
Ironically, requirements authorities (who are perhaps more invested in their current views) often have more difficulty understanding the differences than do practicing business analysts, who when they attend my courses and talks on the topic generally readily understand the differences and indicate appreciation for finally realizing why following the product-requirements-focused conventional wisdom model had consistently led them to repeating the same old creep frustrations.
The fact that even knowledgeable people have difficulty perceiving the differences doesn’t mean there are not very real differences or that they’re not important differences. It means I’ve not been as effective as I need to be in explaining the differences. Let’s try again.
A product, system, or software is not one’s requirements. The product etc. provides value if and only if it satisfies one’s REAL, business requirements—business deliverable _whats_ that provide value when delivered, satisfied, or met. That is, the product is a human-defined high-level design of a presumed way _how_ to satisfy the REAL business requirements, which exist within the business environment and must be discovered. Creep generally occurs when the REAL business requirements also are presumed, which frequently results in the product being built as intended but failing to provide needed value.
Specification is a synonym for design. A design does not have to be technical or in engineering terms. The product’s requirements indeed are _whats_ OF THE PRODUCT, which is a presumed _how_ to satisfy the REAL business requirements.
For example, someone might describe their requirements as a four-door mid-sized sedan automobile. Four doors, mid-size, and sedan style are _whats_ of the car. They provide value only if they satisfy the REAL business requirements, such as: safely and comfortably transporting 12-20 passengers at a time and their three pieces of luggage each distances of 1000 miles in less than three hours. A sedan is not a suitable way _how_ to satisfy such a REAL business requirement.
The ability to solve a problem indeed is a function of the analyst’s skill and the analytical tools available to the analyst. Unfortunately, too few problem solvers have relevant skills or tools, or the skills to use the tools effectively. Many problems don’t get solved because the problem itself is not defined correctly, often because the problem solver lacks suitable models, approaches, tools, and skills.
The Problem Pyramid™ is a powerful tool for getting the problem right, followed by its causes, followed by the business deliverable _whats_ REAL business requirements that when satisfied will provide value by solving the problem, followed by _how_ it could be done. The Problem Pyramid™ is difficult to use because solving problems is difficult and involves often unfamiliar disciplined ways of thinking that take considerable practice and guidance to become proficient.
So what the heck is enterprise analysis? Philosophically, I would define it as a decision problem, for which it is possible/impossible to construct an analytical technique/algorithm that always leads to a correct yes-or-no answer or true value.
However, I suggest that for other than trivial business problems, enterprise analysis and business analysis in general are plagued by the following;
Relativity: says that there is no privileged, "objective" viewpoint for certain observations.
Uncertainty: The lack of certainty, A state of having limited knowledge where it is impossible to exactly describe existing state or future outcome, more than one possible outcome. There are usually no guarantees of absolute correctness.
Incompleteness: Does the analyst have all the necessary and sufficient data? This kind of involves the question why… When one asks someone the question why, it is required that both parties have a similar frame of reference and that they both agree that certain things are true. If not, things go astray.
Un-decidability: Un-decidability of a statement in a particular deductive system does not, in and of itself, address the question of whether the truth value of the statement is well-defined, or whether it can be determined by other means. Un-decidability only implies that the particular deductive system being considered does not prove the truth or falsity of the statement. Whether there exist so-called absolutely un-decidable statements, whose truth value can never be known or is ill-specified, is a controversial point. However, mathematicians have proven absolutely un-decidable cases do exist.
Relativity, Uncertainty, Incompleteness and Un-decidability are reasons the REAL business requirements may never be ascertained. The tincture of time may help or not.
I would also suggest that analysis of dynamic businesses operating in a dynamic business environment will remain in its infancy until some advanced form of mathematical analysis is available to analysts. By that I mean such things as decision analysis, graph theory, game theory etc.
Enterprise analysis (or enterprise business analysis—EBA—as the IIBA Handbook of Enterprise Business Analysis working group has termed it) is a form of business analysis (BA). All analysis is in the service of decision making, improving degree of confidence but not providing mathematical certainty. The questions are whether EBA and BA actually differ, and if so, how. In either case, IIBA’s interest is in making the applicable concepts and methods more explicit so that they can be used more reliably to advantage guiding decision making. I believe it is very evident that the BA/EBA concepts and methods distinctions made in BABOK v2 are incorrect and hopefully will be improved to become more useful by the upcoming Handbook and BABOK v3, which I believe will have to reflect that accurate discovery and use of REAL business requirements are key to both BA and EBA effectiveness.
You wrote: All analysis is in the service of decision making, improving degree of confidence but not providing mathematical certainty.
Zarfman writes: I agree with your comment that, analysis is in the service of decision making.
You also wrote: improving degree of confidence but not providing mathematical certainty.
Zarfman writes: With regard to EA and BA, what is the definition of confidence? In order determine if analysis to improved one must measure it. How is confidence measured? If we can’t arrive at some quantitative solution we are then thrown into the qualitative realm. Where, distinctions based on some subjective quality or characteristic rather than on some quantity or measured value.
For many years sub specialties of mathematics spend a great deal of time dealing with uncertainty. We can have mathematical certainty as long as we agree on certain rules. For example, most of us are familiar with the number 13 in the base 10. However, if we use the base 5 13 become 23.
You also wrote: IIBA’s interest is in making the applicable concepts and methods more explicit so that they can be used more reliably to advantage guiding decision making.
Zarfman writes: Let us hope that IIBA can make the concepts and methods very explicit. This may result in some long time practitioners becoming obsolete if that happens.
As far as I can tell our discourse is similar to the centuries old faith vs. reason debate. Only in our case it appears to be quantitative vs. qualitative. I’ve enjoyed our discussion, I wish you well in your attempt to improve BABOK.
Only registered users may post comments.