Upload
vuongtu
View
220
Download
1
Embed Size (px)
Citation preview
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 1
Business Analysis and Business
Process Analysis have been
developing as separate
professions for the past couple
of decades and have had
professional bodies established
to look after the professional
development of practitioners.
In many instances however,
they are treated as one and the
same by employers and
recruiters alike, with Business
Analysis being used as an
umbrella term to cover both
professional specializations.
Business Process Analysis versus Business Analysis:
Why most organizations confuse them?*
By Ali Darwish, PhD
Business Process Management Consultant
August, 2015
usiness Analysis and Business Process Analysis have been developing as separate
professions for the past couple of decades and have had professional bodies established to look after the professional development of practitioners. In many
instances however, they are treated as one and the
same by employers and recruiters alike, with
Business Analysis being used as an umbrella term to cover both professional specializations. It is not
unusual to hear senior management talking about
their need for “a generalist Business Analyst who
can do process mapping”, only to discover to their dismay – perhaps too late - that such a person is
unable to meet the business process analysis
requirements. Agencies and consultancies are not
any better when it comes to recruiting business process analysts.
Whether instructed by their clients or following
their own definitions of business process analyst, a reductionist, checklist mentality pervades their
thinking and selection and vetting processes, with
very little understanding of the differences between
business analysis and business process analysis — in many situations, process analysis is subsumed
under business analysis. It seems just the sheer
presence of the term “analyst” signals to them that
they are on the right track to selecting “a generalist Business Analyst who can do process mapping”. A more informed recruiter would ask
about BABOK, for example, (but not BPM CBOK) and other forms of certifications, as
another meaningless safety net — a “guide” that has become the be-all and end-all evidence
of business analysis competence and aptitude. But that is the subject of another article.
A quick survey of the roles posted by recruitment agencies over a period of six months
instantaneously reveals this trend of confusion and overlap. The distinction invariably
depends on the maturity of the organization and whether it already has a process
* A chapter in Management Styles of the Mediocre World, Darwish, Ali (forthcoming).
B
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 2
capability center and process methodologies and frameworks that support the transition
towards a process-centric organization. It is a fact of corporate life that most organizations
have not reached an enabling level of maturity to draw the distinction between the two
specializations.
Their processes vary in maturity and efficiency from one functional unit to the next,
depending on the importance and power such functional units wield and the influence
they exert in the organization—and senior management fool themselves into thinking
their processes are not broken, while middle and first management seek “quick wins” to look good on reporting dashboards, often aimed at reducing their workforce as an easy
target under the pretext of business improvement and transformation.
Many process improvement and organizational transformation initiatives start with a
target number of employees earmarked for retrenchment, resulting in insignificant improvements to their existing processes. This is one of ten textbook errors in process
improvement. Yet any informed opposition to this
preemptive approach ends up being dubbed
philosophical and the argument that improving the processes first may not necessarily result in
reducing the workforce as a natural outcome of
process improvement is readily dismissed as theoretical. Curiously, many organizations seem to
have gone in a reverse cycle of maturity in the first
decade of the twenty-first century—a rollback
process of de-maturation and deskilling. Driven by economic pressures and their desire to rapidly
respond and “adapt to market and environmental
changes in productive and cost-effective ways”1,
many organizations have opted to cut corners and abandon their sound practices in favour of good-enough and fit-for-purpose approaches
and template-based work and a generalist, all-round workforce. Organizations also do not
seem to be interested in or serious about full-scale business transformation, despite
promoting such to their workforce, and opt for partial transformation focused on IT solutions to improve their “customer experience”. And if they ever embrace new
approaches to help them improve their business, such as Agile, Lean, Six Sigma, and so on,
they are partially adopted and poorly executed, with different departments, functions, and
projects within the same organization using different methodologies and frameworks. For these disciplines and approaches to work and yield good results, they must be embraced
and applied by the entire organization to drive efficiency into their development methods.
A case in point is Root Cause Analysis (RCA), which is used in Business Analysis and Business Process Analysis as a narrow, localized technique, is in fact an enterprise-wide
framework with methodologies and processes. As a tool used in business analysis, RCA is
invariably confined to what Latino, et al (2011) call “shallow cause analysis”.
Many initiatives start and stop and start again over a period of time, and run in cycles, as if the objective is to get everyone’s hopes up or cause the workforce so much grief and pain
that comes with uncertainty such false starts create. This also demonstrates poor strategic
planning and poor implementation, and lack of stamina to stay the course. When change
“The first rule of any
technology used in a business
is that automation applied to
an efficient operation will
magnify the efficiency. The
second is that automation
applied to an inefficient
operation will magnify the
inefficiency.” (Bill Gates)
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 3
is in response to trends and fads and not to real business needs, it is bound to be short-
lived. An organization’s ability to achieve its strategic goals through transformation begins
with defining these strategic goals and building the mechanisms to achieve them, including
a business process model. How these goals are achieved will critically depend on the type of professionals an organization chooses to hire at the right levels for the specific activities
that ensure the business understands where it is and where it wants to be. It also depends
on the role of both business analyst and business process analyst in the strategic planning
of the organization.
In the absence of adequate understanding of business process analysis and the value it
brings to business improvement, many organizations hire business analysts, whose focus is
mostly on business requirements and invariably on technology solutions that bear little
relevance to process improvement. Consequently, many process improvement initiatives start with IT and
end up failing with IT. Automation seems to be the
magic code word for process improvement. With poor
understanding of the various aspects of process change, automation rarely produces the desired outcomes. As
Bill Gates once said, "the first rule of any technology
used in a business is that automation applied to an efficient operation will magnify the efficiency. The
second is that automation applied to an inefficient
operation will magnify the inefficiency.” Many
organizations that follow the latest trends and fads fail to see this problem and end up commissioning
consultancies that milk them dry. Such consultancies hire green-horned, recent graduates
who are given a template to populate. Often, off-the-shelf prepopulated templates are
rebranded and sold to the clients as though the process maps were an illustration of their processes under the pretense of best practice. With a narrow focus on IT solutions, the
process improvement initiative time and again fails to produce the desired outcomes. Back
to the drawing board and more money to spend on faulty methodologies and unsound
practices and the confusion between business analysis and business process analysis continues.
Requirements: the source of all evil
In the absence of business analysis that is grounded in sound methodologies and processes,
one of the most problematic areas that haunts the profession and clients is the business
requirements process and failure on the part of project managers to manage the
stakeholders’ expectations of the business requirements documents — a process that applies to both business analysis and business process analysis, yet with different objectives
and intents. Getting the requirements rights in both areas of specializations requires
adequate understanding of the different objectives of requirement gathering and the
different techniques employed.
With the younger generation entering the workforce and assuming managerial and senior
roles, with little exposure to the full range of methods and techniques and with superegos
taking control of their approaches to work and problem solving, and with the widening
gap between the older generation and this group of “professionals”, more chaos, confusion
“The real art of
requirements is discovering
the real problem. Once you
do that, you have the basis
for identifying and choosing
between alternative
solutions. (Robertson &
Robertson)
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 4
Many organizations seeking to
improve their processes lose
sight of the fact that for their
business processes to be fixed,
they need to have the right
process improvement
methodologies, standards, and
frameworks in place.
and ambiguity is thrown into the fray. What the teacher did not show them in class when
they were studying is readily and arrogantly dismissed. Ignorance combined with
arrogance is a detrimental combination. And this is part of the indoctrination and
induction process these newcomers undergo. As Robertson and Robertson (2013) confirm, the requirements activity is not principally about writing a requirements document, but
understanding a business problem. “The real art of requirements is discovering the real
problem. Once you do that, you have the basis for identifying and choosing between
alternative solutions. In essence then, requirements are not about the written requirements as such, but rather an uncovering of the problem to be solved.” (Robertson and Robertson
2013, 1). Writing requirements is preceded by requirements capture and analysis, which is
the process of deriving requirements through observation of existing systems, discussion
with business stakeholders, subject-matter experts, task analysis, and process mapping. Often these are applied differently in business analysis and business process analysis and
are time and again confused.
Common ground but separate spaces
While Business Analysis and Business Process Analysis may share overlapping techniques
and methods at some point in the lifecycle, they are definitely two distinct areas of
specialization and should be treated as such for three reasons: (1) hiring the right professionals for the right tasks, and (2) defining the professional boundaries of both
knowledge domains, and (3) using the right
methodologies and approaches to achieve the right
outcomes. Moreover, while Business Process Analysis may use techniques that are common to
both, or have similar names to refer to certain
techniques, such as gap analysis, it goes beyond
mere gathering, communication, validation and analysis of business, functional and non-functional
requirements and development of use cases, and
perhaps as projects may allow, technical
specifications and solution requirements. Business Process Analysis is in fact one key component of
the business process management, which
encompasses process modelling, process analysis, process design, process performance management, process analytics and diagnostics, and process transformation. Each of these
components has a set of activities, methods, techniques and standards that are unique to
business process management and are not necessarily commonly understood or practiced
by all business analysts. Using one lifecycle to manage the projects of another is like using a chainsaw to trim flowers. Many organizations seeking to improve their processes lose
sight of the fact that for their business processes to be fixed, they need to have the right
process improvement methodologies, standards, and frameworks in place.
The art of wasting energy (muda no waza)
One of the seven areas of waste, muda (無駄), identified by the Lean method is time. A
great amount of time (waiting) is wasted in trying to fix faulty process management tools and methods after the horse has bolted, so to speak. One of the main causes of this
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 5
problem is using business analysis methods instead of business process analysis methods. It
is like using a flathead screwdriver to screw in a Philip screw. You may eventually drive
the screw in, but at a cost.
Figure 1: The Seven areas of waste (muda)
So why is there so much confusion?
One of the reasons is that business process analysis is relatively a more recent phenomenon. Organizations have had business analysts (under a variety of different titles)
for quite a long time, and while there is still a great deal of confusion about what business
analysis is and is not and the different classifications of business analyst, it is only since the
early 1990s that business process management and business process analysis have taken a separate,
distinct pathway towards an independent
professional specialization. The term Business
Process Management was introduced in 1967 by S. Williams, but it did not become popular and the
term “process” did not become a new productivity
paradigm until the 1990s. Many business analysts have since then made the transition to business
process analysts, giving them more professional
scope and latitude and another means of securing
income in an ever unstable and uncertain job marketplace. But there is ample evidence to suggest that not many business analysts have
good understanding of the methodologies and techniques that are required or used in
Business Process Analysis and Business Process Management, or the process classification
frameworks and process decomposition in an organization. Business analysts may refer to process levels, but these are often flawed and confused. One critical difference that seems
to consume so much energy in organizations embarking on process mapping and
modelling is failure to distinguish between three types of taxonomies: (1) the taxonomical
hierarchy of process decomposition, (2) the typological hierarchy of document
“Having a process map of the
future without understanding
the present is like having a
map without knowing where
you are and without knowing
where you are how do you
know where you want to
go?”
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 6
management, and (3) organizational structures. Frequently, process activities are confused
with organizational hierarchical functions, and gateways with decision points.
Handsome is as handsome does
As I have previously observed, “Business Process Management (BPM) has been gaining
prominence in business and management circles for almost twenty years. Organizations
and businesses wishing to improve their performance have turned to BPM for quick fixes
or long-term transformation solutions in response to an ever-changing and volatile market and have invested in process improvement initiatives. […] “the drive for business process
improvement has seen thousands of business process management experts appearing
overnight, reminiscent of the Y2K “gold rush”, offering their services to ill-prepared and
ill-advised organizations, and organizations launching business process improvement initiatives without adequate understanding of the requirements and complexities of
business process change management and the resources, frameworks and process skills
required for such undertakings” (Darwish 2011, 30). Yet there is little understanding of this relatively new discipline.
“In this new gold rush, many business process analysts, as they are known today, have
come to BPM from adjacent areas such as technical writing, business analysis, system
architecture, and information technology. In the absence of clear methodologies and standards, these new specialists have supplemented their work by adopting practices from
their previous professions or from other areas of knowledge, with results that are
demonstrative of poor understanding and indicative of lack of sound approaches to
business process mapping and modelling. There is now an entire generation of BPM consultants who have learned to talk the talk and walk the walk, using the jargon of the
day, and produce very little positive results” (Darwish 2011, 30).
It is not unusual for this breed of business process analysts to be ignorant of BPM
methodologies, standards, frameworks and techniques — not to mention the shoddy standards of mapping, whether they use UML to build their use cases, BPMN or the
standard process mapping notation. In some situations, their lack of exposure to the
various types of diagrams and maps drives them to condemn what they have not
encountered in their studies or what their teachers did not teach them, as alluded to earlier. Today, one is bound to find process maps that lack external uniformity and
internal consistency causing ambiguity of map reading and process interpretation.
What is business analysis?
Despite the recent efforts by professional development associations, such as the
International Institute of Business Analysis (IIBA), there is still no standard definition of
business analysis in organizations. As Hass (2008) confirms, “some organizations restrict business analysis to the process of requirements elicitation, analysis, and change
management.[…] Other organizations broaden the definition to include financial analysis,
quality assurance, organizational development, testing and training, and documentation of
business policies and procedures” (Hass 2008).2
IIBA defines business analysis as "the set of tasks and techniques used to work as a liaison
among stakeholders in order to understand the structure, policies, and operations of an
organization, and recommend solutions that enable the organization to achieve its goals"
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 7
Business process analysis
utilizes a range of frameworks
and methodologies to achieve
these activities, including the
business process management
lifecycle illustrated in the
following diagram.
(International Institute of Business Analysis 2009, 3). This is definitely a disappointing
broad, high-level definition that lumps everything into one basket without being specific.
According to Blais (2012), the business analyst is a new position in the corporate
hierarchy. It is therefore not surprising that the professional boundaries are often blurred and encroached upon. As the IIBA’s definition suggests, business analysis is used as a hold-
all basket of anything and everything that relates to business and IT. As Carkenord (2009)
confirms, most of the projects in which business analysts are involved include a software
or IT solution. It is no wonder then that most business analysts who dabble in business process analysis have the proclivity to treat process analysis as an IT-driven business
analysis exercise.
According to Paul (2014), business analysis is a discipline that has evolved over the last
two decades that seeks to ensure there is alignment between business needs and business change solutions. She confirms that in the absence of a standard definition of business
analysis and a standard set of business analysis activities, problems have arisen that can be
summarized into four key problems: (1) many
business analysts focus on documenting requirements without a clear understanding of the
desired business outcomes; (2) some business
analysts are previously experienced IT system analysts and are not quite at ease with business
requirements and the range of potential solutions
that would meet the requirements; (3) many
business analysts have a business background and limited understanding of IT; and (4) a lack of
understanding of the role of business analysts in
the organization (Paul, Cadle and Yeates 2014).
These problems have contributed to the confusion that now exists between business analysis and business process analysis.
What is business process analysis?
According to the BPM CBOK, "the analysis of business processes incorporates several methodologies with the goal of understanding the current organizational processes in the
context of the desired goals and objectives. Analysis assimilates information from strategic
plans, process models, performance measurements, change in the environment, and other factors in order to understand fully the business processes in the context of the overall
organization" (ABPMP 2009). However, process analysis is only one dimension of
Business Process Management (BPM), which is the systematic and structured process-
driven life-cycled approach of identification, understanding, and management of business processes that enable people to perform outcome-driven activities using enabling systems
in the organization. Business process analysis utilizes a range of frameworks and
methodologies to achieve these activities, including the business process management
lifecycle illustrated in the following diagram.
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 8
Figure 2: The Business Process Management Lifecycle
In this business process management lifecycle, mapping the current process is informed by
the strategic plans and business process framework an organization may have in place. It is
also informed by business process requirements that are captured as part of the analysis
work preceding the mapping of the current state. Evaluating the current processes involves analysis of the process in terms of its maturity level, efficiency and effectiveness.
In this regard, process maps work as an analysis tool to determine the level of detail,
sequence of steps, handoffs and bottlenecks, primary and secondary paths, and other
attributes. CEDAR-PIM5™ is a process improvement methodology that I developed a few years ago that can be used to evaluate the process map and suggest improvements.
Modelling the future state is informed by the analysis done in the evaluation phase, based
on the business process requirements and strategic goals. Performing gap analysis includes a comparison between the current state and future state vis-à-vis the business process
requirements and strategic plans. Impact analysis is a corollary activity of the gap analysis
and should inform the change management and implementation strategies and plans.
However, most business transformation initiatives fail in the implementation phase because:
• Not enough strategic planning in the early phases of development and design is
undertaken
• Not enough understanding of the impact of change and how the future state will look like
• Not enough preparation in the implementation phase for the changes that are
necessary to transition the enterprise into the future state
• No business transformation framework and methodology are adopted in the initial stages of the initiative
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 9
The underlying principle of
information design is the
organic relationship between
content and structure.
• Not enough understanding of the different stages of the implementation phase
• Embarking on business transformation with a staff reduction target in mind
To remedy this, the implementation strategy should focus on:
• Business readiness analysis and planning
• Transition management
• Handover
• Benefits ownership and realization
• Building the capability
Figure 3: The Implementation Framework (Darwish, 2014)
Embedding the new processes in the BAU is part of the process of transitioning the
processes to Business As Usual, starting with the least disruptive processes to ensure
business continuity. Embedding consists of phasing in each process, mapping it, documenting it and testing it. It also includes defining each process area and process
owner, and allocating roles and responsibilities
(RACI). Operationalizing the processes happens
after the processes have been embedded in the BAU. It consists of using and monitoring the
newly embedded processes in confined business
areas first and then organization-wide,
operationalizing procedures, including support of training curriculum development, process education, and supporting key performance
measure development. Socializing the process consists of disseminating, publishing and
broadcasting the new processes, ensuring the acceptability of the process to the process
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 10
implementers. A process cannot work as intended if the people who are supposed to
execute it do not believe it is the appropriate process for their ways of working, if it is
seen to be to be too rigid and unrealistic in terms of time, outcomes and productivity, or if
it is regarded as posing risk to their jobs. The extent to which a new process is accepted by its users is measured by their readiness to embrace and implement it or their resistance to
it. Thus, creating process-thinking capabilities within the organization enables the
organization to manage the resistance to change by contextualizing, visualizing and
socializing the new processes to show how they work through the organization and how the various business units and functions contribute to these processes to fulfil the business
goals (Darwish, 2011).
You are as good as your template
The role of templates in both specializations cannot be underestimated for two reasons: (1)
it is important to have a well-designed template that enables the business analyst and
business process analyst to present the information captured during the interviews with the stakeholders and subject matter experts. An easily accessible, effectively structured
document is an effective tool of communication. A faulty template that has a weak frame
of reference is bound to cause so much confusion and consternation with the stakeholders
who cannot sign off on something that makes little sense to them; (2) adhering to a faulty template in terms of structure, information organization, frame of reference and
information content is a dangerous way of approaching information presentation and
communication. The underlying principle of information design is the organic
relationship between content and structure. If the structure is weak, it weakens the content, no matter how good the content is. If the content is weak, a weak structure will
make things worse, and if the structure is strong and clear, it will expose weaknesses in the
content, giving the business analyst the opportunity to remedy the problem. Often, this
organic relationship is not understood; and the focus on either the content or the structure undermines the business analyst’s ability to provide a qualitatively effective document.
While verbal and written communication is a critical skill that is expected of business
analysts, not everyone is a writer and not everyone is aware of the basic principle of
technical writing and information and document design. Whether in the private or public sector, the quality of documentation design in Australia has deteriorated markedly since
the Y2K non-event. Prior to that, there had been a genuine drive to produce documents
that conformed to development and design standards, informed by a body of scientific research, generated mainly in the United States and United Kingdom. Human factors and
ergonomics had played a critical role in the design of technical and end user
documentation ─ readability, legibility and ease of access, are three key factors that have
been thrown out with the bath water, so to speak, now that ISO certification is not as essential as it had been in the two decades leading to the Y2K.
Today, with very few shining examples, the majority of documents produced in the
corporate domain are substandard, and there is a general relaxed attitude and apathy
towards best practices in documentation design, and more so a degree of ignorance of the basic principles of design. All the more for the need to have at least templates that are
designed to present the analysts’ findings in the most effective way —after all, in the
absence of technical writing skills, we are as good as our templates.
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 11
The end-to-end is not the end – it is a means to an end
Everyone seems to be talking about the end-to-end process. In low maturity organizations, instead of setting the strategic direction of the process improvement initiative,
management often dictates a certain business process analysis approach to produce the
outcomes they have in mind irrespective of what the modelling exercise may unearth.
Often, they force the modelling of the future state down to a serious level of granularity without mapping the current state. As Watts S. Humphrey once put it, “if you don’t
know where you are, a map won't help.” So having a process map of the future without
understanding the present is like having a map without knowing where you are, and without knowing where you are how do you know where you want to go? Most
organizations follow the trend and suffer from “I’ll have what she is having”3 syndrome,
without quite understanding the problems they are trying to solve.
But such intervention also stems from the widespread confusion about business analysis and business process analysis. Unable to detach themselves from their technical past,
managers will always seek to dabble in the technical aspects of the process improvement
effort. As I previously argued4, most managers rise from the ranks and are unable to
separate their managerial responsibilities from the technical knowledge for which their staff are hired. This is an observed problem not only with first-line managers who rise
from the ranks of technical staff and who have no experience, training or aptitude as
managers, but also increasingly with senior management as the management landscape
changes.
Concluding remarks
It is critical for organizations wishing to transform their business and improve their processes to reduce cost and increase productivity to hire the right people for the right
tasks. Hiring business analysts to do the work of business process analysts is one sure way
to undermine the effort to achieve these strategic goals. It is important to make a clear
distinction between these two professions, in light of the discussion in the preceding paragraphs. Different professions use different methods and techniques and have different
frameworks and standards, and ensuring connectivity, progression, and transition of
business process mapping and modelling work within a structured framework that utilizes
these methods and techniques can only be achieved if there is awareness and understanding of business process management, not only as a way to manage existing
processes as seems to be the misconception, but more so to manage the mapping,
modelling, analysis and improvement of processes in organizations. Creating synergy
across these professions, while understanding the differences and the need to maintain the professional boundaries between business analysis and business process analysis, is one
critical success factor for organizations wishing to improve their performance. �
© 2015 Ali Darwish. All rights reserved.
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 12
About the Author
Ali Darwish, PhD, MIS, MBII, MA is an award-winning expert communication and business
improvement consultant, for over 30 years, delivering best-in-class solutions. He is also an
active scholar, researcher and published author of international renown, specializing in
cross-cultural social semiotics and communication. He has published more than 25 books on
business process management, enabling methodologies, translation, communication, and
knowledge management.
August, 2015
Works Cited ABPMP. Guide to the Business Process Management Common Body of Knowledge (BPM CBOK). USA:
ABPMP, 2009.
Blias, Steven P. Business Analysis: Best Practices for Success. Hobboken, New Jersey: John Wiley &
Sons, 2012.
Carkenord, Barbara A. Seven Steps to Mastring Business Analysis. USA: J. Ross Publishing, 2009.
Darnton, Geoffrey. Business Process Analysis: Including Architecture, Engineering, Management, and
Maturity. 2nd. Bournmouth, UK: Requirements Analytics, 2012.
Darwish, Ali. Business Process Mapping: A Guide to Best Practice. Melbourne: Writescope Publishers,
2011.
—. CEDAR-PIM5: Process Improvement Method. Melbourne: Writescope Publishers, 2014.
Debevoise, Tom. Business Process Management, with a Business Rules Approach: Implementing the
Services Oriented Architecture. Roanoke, Virginia: Tipping Point Solutions, 2005, 2007.
Debevoise, Tom, and Rick Geneva. The Microguide to Process Modeling with BPMN 2.0: How to build
process, rule, and event models. Lexington, Virginia: Advanced Component Research,
Incorporated, 2011.
Hass, Kathleen B. Professionalizing Business Analysts: Breaking the Cycle of Challenged Projects.
Vienna, VA: Management Concepts, Inc., 2008.
International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge
(BABOK Guide). 2nd Edition. Toronto: International Institute of Business Analysis, 2009.
Latino, Robert J, Kenneth C Latino, and . Mark A Latino. Root Cause Analysis: Improving Performance
for Bottom-Line Results. Boca Raton: CRS Press - Taylor & Francis Group, 2011.
Paul, Debra, James Cadle, and Donald (editors) Yeates. Business Analysis. Oxford: BCS, 2014.
Robertson, Suzanne, and James Robertson. Mastering the Requirements Process: getting
requirements right. 3rd. New York: Addison-Wesley, 2013.
Business Process Analysis versus Business Analysis: Why most organizations confuse them?
Page | 13
Notes
1 https://en.wikipedia.org/wiki/Business_agility
2 Hass 2008, 10-11.
3 A Kellogg’s TV commercial. https://www.youtube.com/watch?v=8r2-xCxFpa4
4 See Darwish (2015). The Lee Moment: Decisiveness in Leadership and Management.