Oracle Technology Strategies - Creating A Business Analytics Roadmap (Practitioner Guides) - 2015

Oracle Practitioner Guide
Creating a BA Roadmap
Release 3.0
E40625-03
July 2013
Creating a BA Roadmap, Release 3.0
E40625-03
Copyright 2013 Oracle and/or its affiliates. All rights reserved.
Primary Author: Dave Chappelle
Contributing Authors: Stephen G. Bennett, Cliff Booth, Bob Hensle, Anbu Krishnaswamy, Mark Wilkins
Warranty Disclaimer
THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS

PROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLE
EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THAT
THE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TO
MAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.
As individual requirements are dependent upon a number of factors and may vary significantly, you should
perform your own tests and evaluations when making technology infrastructure decisions. This document
is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle
Corporation or its affiliates. If you find any errors, please report them to us in writing.
Third Party Content, Products, and Services Disclaimer
This document may provide information on content, products, and services from third parties. Oracle is not
responsible for and expressly disclaim all warranties of any kind with respect to third-party content,
products, and services. Oracle will not be responsible for any loss, costs, or damages incurred due to your
access to or use of third-party content, products, or services.
Limitation of Liability
IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR
CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE,
INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT,
ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
Contents
Send Us Your Comments ........................................................................................................................ ix
Preface ................................................................................................................................................................. xi
Purpose ......................................................................................................................................................... xi
Audience....................................................................................................................................................... xi
How to Use This Document....................................................................................................................... xi
Document Structure .................................................................................................................................... xi
Related Documents .................................................................................................................................... xii
Acknowledgements .................................................................................................................................. xiii
Conventions ............................................................................................................................................... xiii
1 Creating a BA Roadmap
1.1 BA Roadmap Drivers ................................................................................................................. 1-1
1.1.1 Top-Line Drivers.................................................................................................................. 1-1
1.1.2 Bottom-Line Drivers............................................................................................................ 1-2
1.1.3 Agility Drivers...................................................................................................................... 1-2
1.1.4 IT Drivers .............................................................................................................................. 1-2
1.2 BA Roadmap Defined ................................................................................................................ 1-3
1.3 Roadmap Creation Process........................................................................................................ 1-4
1.3.1 Current State Assessment................................................................................................... 1-5
1.3.1.1 Overview ....................................................................................................................... 1-6
1.3.1.2 Details............................................................................................................................. 1-6
1.3.1.3 Output ............................................................................................................................ 1-9
1.3.2 Future Vision Definition ..................................................................................................... 1-9
1.3.2.1 Overview ....................................................................................................................... 1-9
1.3.2.2 Details............................................................................................................................. 1-9
1.3.2.3 Output ......................................................................................................................... 1-12
1.3.3 Gap Analysis ..................................................................................................................... 1-12
1.3.3.1 Overview .................................................................................................................... 1-12
1.3.3.2 Details.......................................................................................................................... 1-13
1.3.3.3 Output ......................................................................................................................... 1-17
1.3.4 Activity Selection and Scheduling ................................................................................. 1-17
1.3.4.1 Overview .................................................................................................................... 1-18
1.3.4.2 Details.......................................................................................................................... 1-18
1.3.4.3 Output ......................................................................................................................... 1-24
iii
1.4 Closing Comments................................................................................................................... 1-24
A BA Maturity Model
A.1 Capabilities ................................................................................................................................. A-1
A.2 Domains ...................................................................................................................................... A-2
A.3 Maturity....................................................................................................................................... A-4
A.4 Adoption ..................................................................................................................................... A-4
iv
v
List of Figures
11 BA Roadmap Program and Project Scope ............................................................................... 1-3
12 Roadmap Creation Process........................................................................................................ 1-5
13 Current State Assessment Process............................................................................................ 1-6
14 Future Vision Definition Process .............................................................................................. 1-9
15 Example BA Vision Summary................................................................................................ 1-12
16 Gap Analysis Process .............................................................................................................. 1-13
17 Vision versus Current Maturity............................................................................................. 1-13
18 Capabilities Scatter Plot .......................................................................................................... 1-15
19 Capabilities Heat Map............................................................................................................. 1-16
110 Activity Scheduling Process ................................................................................................... 1-18
111 Increasing Maturity Over Time ............................................................................................. 1-19
112 Program Activity Overview and RACI Chart ..................................................................... 1-20
113 Project / Activity Dependency Analysis .............................................................................. 1-21
114 Roadmap Phase 1 Schedule.................................................................................................... 1-23
115 BA Roadmap Subsequent Phases .......................................................................................... 1-24
A1 Integrated Analysis Capability ................................................................................................ A-2
A2 BA Capability Domains ............................................................................................................ A-3
vi
List of Tables
11 Typical Interview Participants ................................................................................................. 1-7
12 Typical Relevant Documents ................................................................................................... 1-8
13 BA Goal Statements ................................................................................................................ 1-10
14 BA Initiative Scope.................................................................................................................. 1-10
15 Example BA Benefits .............................................................................................................. 1-11
16 Example BA Guiding Principles ........................................................................................... 1-11
17 Remediation per Domain....................................................................................................... 1-17
vii
viii
Send Us Your Comments
Creating a BA Roadmap, Release 3.0

E40625-03
Oracle welcomes your comments and suggestions on the quality and usefulness of this
publication. Your input is an important part of the information used for revision.
Did you find any errors?
Is the information clearly presented?
Do you need more information? If so, where?
Are the examples correct? Do you need more examples?
What features did you like most about this document?
If you find any errors or have any other suggestions for improvement, please indicate
the title and part number of the documentation and the chapter, section, and page
number. You can send comments to us at its_feedback_ww_grp@oracle.com.
ix
x
Preface
A Business Analytics (BA) Roadmap provides the guidance to advance the maturity of
the BA program and promote greater success with BA-related projects and
technologies. This roadmap creation process examines both the business and technical
aspects of a BA initiative. It addresses many forms of BA, including descriptive,
predictive, prescriptive, and exploratory analytics. It also recognizes the efforts that
pertain to information management in support of BA initiatives.
Building such a roadmap requires a solid understanding of the current situation, a
clear vision of what must be done to be successful, and a structured approach to
defining the iterations that comprise the path to greater success and widespread
adoption.
Purpose
The purpose of this document is to describe a repeatable process for constructing a BA
Roadmap. The process described follows the standard four steps used within the
industry to create roadmaps, i.e. establish the current state, define the future vision,
analyze the gap, and define the phases and schedule of the roadmap. It is the
particulars within each phase of the overall process that provide the uniqueness and
value of the approach described in this document.
Audience
This document is intended for Program Managers and Enterprise Architects that want
to understand how to build a fact-based BA Roadmap. Some level of understanding of
BA is required since this document does not provide any BA background or primer
material.
How to Use This Document

This document is intended to be read from start to finish. However, the first two
sections in Chapter 1 can be read standalone if the goal is only to get a high level
understanding of the roadmap creation process.
Document Structure
This document is organized chronologically. It describes the BA Roadmap building
process from start to finish. Specifically,
Chapter 1 describes the process for creating a BA Roadmap.
xi
Appendix A describes the BA Maturity Model that is used to evaluate the current
state and identify capabilities that are lacking or lagging.
Related Documents
IT Strategies from Oracle (ITSO) is a series of documentation and supporting collateral
designed to enable organizations to develop an architecture-centric approach to
enterprise-class IT initiatives. ITSO presents successful technology strategies and
solution designs by defining universally adopted architecture concepts, principles,
guidelines, standards, and patterns.
ITSO is made up of three primary elements:

Oracle Reference Architecture (ORA) defines a detailed and consistent
architecture for developing and integrating solutions based on Oracle
technologies. The reference architecture offers architecture principles and
guidance based on recommendations from technical experts across Oracle. It
covers a broad spectrum of concerns pertaining to technology architecture,
including middleware, database, hardware, processes, and services.
Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption
of horizontal technologies for the enterprise. They explain how to successfully
execute on a strategy by addressing concerns pertaining to architecture,
technology, engineering, strategy, and governance. An organization can use this
material to measure their maturity, develop their strategy, and achieve greater
levels of adoption and success. In addition, each ETS extends the Oracle Reference
Architecture by adding the unique capabilities and components provided by that
particular technology. It offers a horizontal technology-based perspective of ORA.
Enterprise Solution Designs (ESD) are cross-industry (applicable to many
industries) and industry-specific (focused on a single vertical industry) solution
perspectives based on the Oracle Reference Architecture. They adhere to the ORA
principles and also draw on the best practices and guidelines provided in ETS
collateral. They define the high level business processes, business functions, and
software capabilities that are required to build enterprise-wide industry solutions.
ESDs map the relevant application and technology products against solutions to
illustrate how capabilities in Oracle's complete integrated stack can best meet the
business, technical, and quality-of-service requirements.
This document is one of the series of documents that comprise the Business Analytics
Enterprise Technology Strategy. The BA ETS includes reference architecture
xii
documents (ORA Business Analytics Foundation and ORA Business Analytics
Infrastructure) as well as how to documents such as this guide to creating a BA
Roadmap.
Please consult the ITSO web site for a complete listing of ORA documents as well as
other materials in the ITSO series.
Of particular relevance to this document are the following documents which provide
additional information for the BA Roadmap creation process:
BA Maturity Model Capabilities - This spreadsheet contains the specific
capabilities that are measured as part of the current state analysis. For each
capability a description is provided for each level of maturity and adoption.
BA Maturity Model Analysis - This spreadsheet is used to analyze the scores for
the capabilities on both maturity and adoption. The spreadsheet contains various
graphical depictions of the scores.
Acknowledgements
This document is based on a variety of materials that have been created by many
different individuals and groups. Thanks to all who contributed. The purpose of this
document is to catalogue the materials and describe the process for using the materials
together to create a BA Roadmap.
Conventions
The following typeface conventions are used in this document:
Convention Meaning
boldface text Boldface type in text indicates a term defined in the text, the glossary,
or in both locations.
italic text Italics type in text indicates the name of a document or external
reference.
underline text Underline text indicates a hypertext link.
xiii
xiv
1
1Creating a BA Roadmap
Business analytics (BA), as the name suggests, is very much a business-driven

strategy. The drivers for pursuing BA are predominantly business focused. The user
community is usually business focused, e.g. executives, managers, and financial
planners. Even the most sophisticated "power-users", those that most fully understand
data modeling and technology, use the system in support of business initiatives.
However, the ability to provide the level of intelligence a modern business requires
can involve a great amount of time and effort from IT. For example, a simple business
requirement to track sales of an item can involve hundreds of hours of time from
database administrators, data stewards, developers, and operations personal, in order
to get the right information to the right people in the right way, at the right time. This
makes it vitally important to have a clear and effective line of communication between
the business and IT communities. It also underscores the need for effective planning in
order to ensure that IT is focused on what the business really needs. In addition,
business and IT communities must coordinate well in order to adapt to changing
business requirements and advances in technology.
This chapter describes the process used to create an effective BA Roadmap. It takes
into account several business factors and an evaluation of the current state in order to
prioritize efforts that will best serve both the business and IT communities.
1.1 BA Roadmap Drivers

A number of drivers affect how a BA Roadmap is defined and executed. The ultimate
goal of the roadmap is to provide a strategic path to achieve the goals of the business
and to provide incremental value to gain competitive advantage. BA can positively
affect both the top line and bottom line of the business, and make it more agile and
competitive. The roadmap is greatly influenced by how these benefits can be quickly
realized.
The roadmap is also influenced by the reality of achieving these goals in a manner that
is both practical and sustainable. Given that these issues tend to fall on the shoulders
of IT, they are described below as IT drivers.
1.1.1 Top-Line Drivers

BA strategies are often used to drive top-line growth. This is achieved in many ways,
including:
Improved marketing strategies based on statistical analysis, trend analysis, and
data mining
Improved sales based on analysis of pricing, placement, and cross-sell/up-sell
indicators
Creating a BA Roadmap 1-1

BA Roadmap Drivers
Improved product strategies based on predictive analytics, historical analysis, and

sentiment analysis
The discovery of new product and/or service opportunities based on data mining
and text mining various forms of data
Just-in-time insight and decision making based on real-time event processing,
business activity monitoring, and business rules
Business strategy development and tracking using key performance indicator
(KPI) definition and monitoring
Effective financial planning, customer management, and improved service
1.1.2 Bottom-Line Drivers

BA contributes to improving the bottom line through cost reductions in several ways.
It provides insight into forecasting that can be applied to inventory management,
headcount, and resource optimization. It can be used to improve decision making in
areas that reduce expenses, such as transportation costs, shipping costs, and asset
management. It can also be used to automate decision making, thereby reducing costs
associated with common business processes that would ordinarily require human
intervention. BA has also been used to reduce costs by combating fraud, theft, and
detecting various types of security threats.
1.1.3 Agility Drivers

BA improves business agility by helping businesses respond faster to changes in
market conditions. This requires continuous monitoring of market conditions, sensing
when change occurs, and determining if/when/what actions are required. Business
Activity Monitoring (BAM) and Complex Event Processing (CEP) underpin the
analysis framework necessary to detect and respond to real-time market conditions.
Agility can be gained via automation, as described, and via human decision making as
well. BAM and CEP can feed real-time information to knowledge workers, who in
turn use this information for making more informed decisions. Real-time and
historical information can also be combined in order to recognize abnormal behavior
or new opportunities. Business decisions can change based on current conditions as
opposed to periodic reports or statically defined business rules.
1.1.4 IT Drivers
In order for IT to deliver the benefits of BA, it must ensure that information is
collected, organized, cleansed, and delivered in a manner that produces accurate and
insightful analysis. The capacity for doing so may not already exist within the
organization, therefore, the BA Roadmap may be influenced by a number of IT-related
drivers, such as:
The ability to collect data from operational systems
The ability to semantically organize and cleanse operational data
The ability to manage the volume of data required for historical analysis
The ability to process and deliver analysis queries as quickly as needed
The ability to provide end user capabilities via all necessary delivery channels
The ability to integrate real-time processing with business analytics
1-2 Creating a BA Roadmap

BA Roadmap Defined
IT drivers often require the roadmap to prioritize and coordinate the deployment of
software and infrastructure in order to achieve business goals in a beneficial, practical,
and sustainable manner.
1.2 BA Roadmap Defined

A BA Roadmap provides guidance to the BA initiative, allowing multiple projects to
progress in parallel yet remain coordinated. This ultimately results in a common end
goal that provides value greater than the sum of the individual projects. The BA
Roadmap helps to coordinate two types of activities:
1. Program-level activities that address cross-cutting concerns such as strategy and
planning.
2. Project-level activities that pertain to the delivery of specific infrastructure or
application related assets.
The relationship for these fundamental parts is illustrated in Figure 11.
Figure 11 BA Roadmap Program and Project Scope
In most organizations, BA solutions are created in silos in order to address the needs
of specific departments or users. Little thought is given for how those solutions affect
the rest of the enterprise eco-system or how they might positively or negatively impact
the larger program. This shortsightedness may necessitate follow-on projects to
rationalize data stores, sort out data integration issues, or duplicate design and
development efforts due to lack of communication or coordination between projects.
The BA Roadmap is designed to provide the coordination and communication
necessary to avoid project silos. It does this by defining a common vision for how the
organization should handle all aspects of BA. The processes, projects, and
infrastructure to support BA are organized and managed in order to incrementally
achieve the target vision. The intent is to improve BA maturity over time while
delivering projects that align with the vision and support ongoing business initiatives.

Roadmap Creation Process
Activities included in the program-level scope are intended to advance BA maturity

through proper strategy and planning. They include, (but are not limited to), the
definition of:
A reference architecture that describes the recommended architecture capabilities,
components, principles, technologies, and infrastructure for designing BA
solutions
An engineering method used to guide the development of BA solutions
A governance model that describes how information and solution artifacts will be
properly governed
Guidance on how information and analysis artifacts should be modeled in order to
promote sharing and reuse
Guidance on how KPIs should be described, monitored, and managed
The enterprise may already have some of these assets in various stages of
completeness and relevance. Some may be deemed important and necessary while
others may be less so. The intent of the roadmap process is to determine which
program level activities need to be addressed and in what order.
In addition, the organization will likely have several BA projects that are either ready
to begin or are slated for the near future. The roadmap will endeavor to establish a
logical ordering of activities that benefits both program and project level objectives.
For example, infrastructure to manage BA assets may be deployed in support of
program level objectives. It may be prioritized ahead of certain projects that most need
this capability, or it may be included in a project in order to provide this capability for
future projects. In either case, establishing a roadmap helps to facilitate coordination
and communication between program-level and project-level activities.
Projects in support of BA may be divided into two groups: those that pertain to the
delivery of BA assets, and those that pertain to the delivery of enterprise information
management (EIM) assets. The former group focuses on applications, tools, reports,
dashboards, etc. that enable various forms of analysis. The latter group focuses on the
acquisition, integration, cleansing, management, access, and governance of
information assets.
The two types of projects can be delivered in tandem, in support of a common set of
requirements, or they can be delivered as separate initiatives, prioritized according to
needs. Either way, the organization should strive to get the most value out of these
projects by ensuring that they are aligned with the vision. The BA Roadmap offers a
means to effectively coordinate these different types of projects following
program-level guidance.
Generally, the most effective planning horizon for a BA Roadmap is 2-3 years. This
could be longer or shorter depending on the planning cycles for each organization.
The initial phases (e.g. first six months) of the roadmap will contain much greater
detail than the later phases. This is appropriate and by design. The BA journey is often
a journey of discovery, incremental improvement, and regular course corrections. The
BA Roadmap should be regularly reviewed and updated. The business never stays
static, so do not expect the BA Roadmap to remain static either.
1.3 Roadmap Creation Process

As depicted in Figure 2, there are four main phases in the roadmap creation process:
Current State Assessment, Future Vision Definition, Gap Analysis, and Activity
Selection & Scheduling.

Figure 12 Roadmap Creation Process
The current state is measured based on the Oracle BA Maturity Model. Using this
approach to assess the current state of the BA initiative provides a consistent
measurement scale while keeping the effort focused on capabilities important to BA
success and avoiding the scope creep that frequently undermines current state
evaluation efforts.
The Future Vision Definition phase is used to establish the high-level goal and reason
for the BA program. While a fully fleshed out future vision is needed eventually, the
initial roadmap creation only requires the high-level vision since the development of
the detailed vision can itself be part of the BA Roadmap. Of course, if the current state
of the BA initiative includes a more detailed future vision, that vision can be leveraged
when creating the roadmap.
The Gap Analysis phase evaluates the gap between the current state and the future
vision for each of the capabilities. Generally the capabilities exhibiting the largest gap
are given highest priority during the roadmap creation phase. However, part of the
gap analysis also includes evaluating the relative importance for each of the
capabilities for this particular organization. Size, organizational structure, existing
assets, funding priorities, even politics can significantly impact the relative importance
of capabilities.
The final phase is the Activity Selection & Scheduling phase. This phase uses the
output from the Gap Analysis phase to create a logical ordering of work to be done.
Emphasis is placed on the program-level efforts for the initial phases to establish the
assets and processes used across projects. Projects are evaluated for business benefit,
IT benefit, and risk and are then prioritized based on that evaluation.
The BA Roadmap creation process is itself an iterative process. The first iteration may
have very limited detail on the project portfolios and focus heavily on the program
level efforts. As the roadmap is reviewed and updated, additional details will be
added for the project portfolios. As maturity increases and adoption spreads, it is also
likely that later phases will include additional program-level activities.
1.3.1 Current State Assessment

Attempting to capture a full, detailed description of the current state of an IT
environment of a large company can lead to analysis paralysis. To avoid this problem,
the method described here uses a focused scope and a pragmatic, time-boxed
approach. The underlying goal is not to fully capture an IT environment current state;

rather it is to evaluate the current state relative to the capabilities that are required to
successfully advance BA maturity.
1.3.1.1 Overview
The current state assessment is based on the Oracle BA Maturity Model. (See
Appendix A for a description of the BA Maturity Model.) The BA Maturity Model
includes over eighty capabilities that capture the best practices that Oracle has
collected over many years working with a wide variety of companies. These
capabilities provide the detail necessary to accurately measure and guide the progress
of a BA initiative. Focusing the current state assessment on these specific capabilities
ensures a focused scope for the assessment.
Further, the current state assessment should be tightly time-boxed to ensure timely
completion of this phase. The size and complexity of an organization determines the
actual amount of time that must be allocated to the assessment. Nominally, two weeks
is the amount of time required.
An overview of the current state assessment process is shown below:
Figure 13 Current State Assessment Process
1.3.1.2 Details
This section details the steps defined in the previous section.
1.3.1.2.1 Define Scope

Before beginning the actual assessment, it is vital that the scope of the assessment is
determined and that all involved parties agree to the defined scope. For example, the
scope could be limited to a single division or line-of-business within a larger
enterprise. Or, the scope could be limited to a single geographic location. The scope
defines both the scope of the assessment and, ultimately, the scope of the roadmap.
1.3.1.2.2 Identify Interview Participants

Once the scope has been determined, the participants in the assessment can be
identified. The participants are chosen to ensure that all capabilities within the BA
Maturity Model can be accurately scored. The following table describes the typical
areas of interest and interview participants:

Table 11 Typical Interview Participants

Area of Interest Typical Participant
Business Objectives VP of Business Unit(s)
LOB IT
IT Objectives CIO
VP of Application Development
VP of IT Infrastructure
Enterprise Architecture VP of Enterprise Architecture
Enterprise Architect(s)
Information Architecture VP of Information Architecture
Data Analyst(s)
Data Scientist(s)
Database Architect(s)
Data Steward(s)
Data Integrator(s)
Program Management PMO Manager

Project Manager(s)
Development Process Application Architect(s)
Business Analyst(s)
Development Lead(s)
Methodologist
Build Manager
CM Manger
QA Manager
Operations Director of Operations
Administrator(s)
Security Chief Security Architect
1.3.1.2.3 Determine Interview Schedule

Once the interview participants have been identified, the next step is to create a
schedule for when each participant will be interviewed. The goal is to limit the length
of the assessment phase by creating a compacted schedule. It may be necessary to
delay the start of the assessment to get times on the participants' schedules that fit into
a two week (or so) period. Time before or between interviews can be productive time
spent reviewing documentation (i.e. the next step).
1.3.1.2.4 Gather and Review Relevant Documents

Before beginning the interview process, the assessment team should gather and review
all the existing documents that describe various aspects of the current IT environment
and BA initiative. This allows the assessment team to ask more focused questions in
the interviews and also provides the opportunity to ask questions about the written

material for clarification or to resolve conflicting information. The following table

gives some examples of the types of documents that should be gathered and reviewed:
Table 12 Typical Relevant Documents

Typical Documents to Review
Balanced Score Card, Strategy Map (or similar business strategy/goals document)
Enterprise Architecture Document(s)
Information Architecture Document(s)
Project Management Handbook(s)
Software Development Process Document(s)
Information Management Proces Document(s)
Operational Process and Procedures Document(s)
Corporate Security Policies
Organizational Structure Document
BA Program Document(s)
Information and BA Governance Document(s)
1.3.1.2.5 Perform Interviews

Before each interview the assessment team should review the BA Maturity Model to
identify capabilities that are particularly relevant for the person being interviewed. It
is NOT recommended that the assessment team simply ask a question for each of the
capabilities. Rather the interview team should ask open ended questions that allow the
interviewee to describe how things are currently done and to identify any problems
that currently exist. Remember, the interviewees are the experts on what goes on
within the organization being evaluated, so encourage them to explain the current
situation.
1.3.1.2.6 Assign Capability Scores

Once the interviews have been completed and the documents have been reviewed,
each of the capabilities in the BA Maturity Matrix should be scored for both maturity
and adoption. These scores provide the raw data that can then be analyzed in the gap
analysis phase of the roadmap creation process.
The BA Maturity Model includes a description for each level of maturity and each
level of adoption for each capability. When scoring a capability, the scores selected
should be the scores where the descriptions of maturity level and adoption level most
accurately match the current situation based on the information collected in interviews
and from the documents reviewed. Although there is always some level of subjectivity
when measuring capability, the goal is to provide an objective measure. This allows
future measurements to be performed by a different assessment team, yet still provide
results that can be used to accurately measure progress.
Frequently when the assessment results are presented there are questions and even
disagreements about the score that was assigned. Therefore, it is also important that in
addition to the score, the assessment team also record the rational for assigning the
maturity and adoption scores. This rational could include quotes from interviews or
specific sections from the documents that were reviewed.

1.3.1.3 Output
The output of the current state assessment is the maturity and adoption score for each
of the capabilities in the BA Maturity Matrix. Additionally, the assessment team will
have an understanding of the current state and should have collected known issues
and problems that were identified and discussed during the interview process.
1.3.2 Future Vision Definition

For the BA Roadmap creation process, the future vision definition phase focuses solely
on the high level goals and principles that will be used to guide the entire BA
initiative. This phase does not attempt to create a detailed future state vision. While a
more detailed future vision is required to achieve successful BA adoption, it is not
something that must be created prior to creating the initial BA Roadmap. The initial
phases of the BA Roadmap may focus on creating the detailed BA future vision. (See
Figure 4)
Figure 14 Future Vision Definition Process
1.3.2.1 Overview
The BA vision definition answers the following questions:
1. What is goal of the BA initiative?
2. What is the organizational scope of the BA initiative?
3. What are the benefits that BA is expected to deliver to the organization?
4. What are the guiding principles for the BA initiative?
These questions must be answered by the executive(s) leading the BA initiative. This is
accomplished in a facilitated workshop. Nominally the workshop should take about
two hours, but may take longer if there is substantial disagreement on either of the
goals, scope, benefits, or principles for BA.
1.3.2.2 Details
This section provides greater detail on how to collect answers to the questions that the
previous section introduced.
1.3.2.2.1 Goal of the BA Initiative The goal being defined is the goal for the BA initiative
by the end of the roadmap. The recommended roadmap planning horizon is 2-3 years;
therefore the goal should be the goal of the BA initiative 2-3 years from now. The
following table provides goal statements from which to choose.

Table 13 BA Goal Statements

Goal Statement Score
Develop experience using BA to provide a foundation for further 1
investments in BA technologies.
Standardize and consolidate technology and methodology for BA 2
according to best practices in order to reduce operational costs
and improve overall efficiency.
Drive widespread sharing and reuse of BA assets by consistently 3
applying architecture, engineering, and governance processes
across the organization.
Improve business/IT alignment and drive business value by 4
measuring and managing to key performance indicators.
Maximize revenue, optimize operations, and create competitive 5
advantage through timely insight and intelligent decision making.
The goal statements in the above table are used to gauge the extent and complexity of
the entire BA initiative and are listed in order of increasing difficulty. It should be
obvious that accomplishing the first goal statement is far less difficult that
accomplishing the fifth goal statement. Greater organizational maturity is required to
achieve the more difficult goals for BA. Of course, the benefits provided by BA are
commensurably greater as well. The 'Score' column in the table is used (and will be
explained) in the gap analysis phase.
1.3.2.2.2 Organizational Scope of the BA Initiative The organizational scope defines which
departments, divisions, lines-of-business, etc. are included in the BA initiative. The
most common scopes are either division or enterprise, but other options are possible
depending on the company's organizational structure. The following table provides
example levels of scope for the BA initiative.
Table 14 BA Initiative Scope

SOA Initiative Scope Score
A small number of projects will be involved in the BA initiative. 1
One or more business units will be included in the BA initiative. 2
The BA initiative will span all business units within a single division. 3
The BA initiative will span multiple divisions within the enterprise. 4
The BA initiative will span the entire enterprise. 5
Defining the scope of the BA initiative is essential to determining a roadmap. With

greater scope, the number of organizational boundaries that must be crossed increases.
This increases the complexity of the effort, and, therefore, requires greater
organizational maturity. The 'Score' column in the table is used (and will be explained)
in the gap analysis phase.
1.3.2.2.3 Expected Benefits of the BA Initiative There are many different benefits that an
organization can realize by successfully adopting BA. However, not all benefits can be
realized in parallel. When creating a BA Roadmap emphasis should be placed on the
benefits that are highest priority and leave the lower priority benefits for later phases.
The table below lists possible benefits from BA adoption:

Table 15 Example BA Benefits

Better visibility into business processes Reduce time to acquire data to make
decisions
Accurate and timely financial reporting Real-time intelligence insight
Predictive analytics Single version of the truth
Improve business simulation & forecasting Visibility into success of current business
strategy
Real-time alerts Optimization of business processes
Analysis of public sentiment regarding Support for analysis using mobile devices
products and services
Achieve cross-department collaboration on More effectively translate business
analysis questions into useable intelligence
Analysis to support business objectives Ability to test business hypotheses
The benefits in the above table can be used as a starting place to identify the benefits
that an organization hopes to achieve via the BA initiative. The above table is only a
start on the possible benefits and is by no means a complete list. Part of the vision
definition is to create a list of possible BA benefits and prioritize the list.
Once a list has been created, the benefits should be prioritized based on the business
and IT objectives of the organization. The easiest way to prioritize the benefits is to
assign a high, medium, or low prioritization to each possible benefit. Roughly one
third of the possible benefits should be in each prioritization i.e. it does no good to list
all the possible benefits as high priority.
1.3.2.2.4 Guiding Principles for the BA Initiative The guiding principles are derived from
the top priority benefits and provide enforceable guidance to the BA initiative. The
following table provides some example guiding principles.
Table 16 Example BA Guiding Principles

The quality of data and accuracy of analysis must be known
Accommodate all forms of data
Provide data abstraction and loose coupling
Unified view of information
Consistent and complete information and analysis
Provide security secure access to information and analysis
Define and share information and analysis constructs and
semantics
Enable insight to action
All changes that affect analysis must be properly governed
Analysis must be available when and where it is needed
Infrastructure resources must be pooled across departments and
business units
The guiding principles should be sufficiently clear and detailed that the principles can
be enforced across the entire scope of the BA initiative and on specific projects that fall
under the purview of the initiative. The principles should also serve as a foundation to
make more specific decisions in the future.

1.3.2.3 Output
The output from the vision definition phase is the overall goal of the initiative, the
scope of the initiative, the expected benefits, and the guiding principles to achieve the
goal and the benefits. This vision for the BA initiative can be captured in a single
summary slide and used to educate and align the organization with the BA initiative.
An example of this summary slide is shown in Figure 5.
Figure 15 Example BA Vision Summary
This clearly shows the goal and scope of the BA initiative. It also shows that the BA
principles will be enforced across the entire BA initiative and that the BA initiative is
expected to deliver the prioritized benefits.
1.3.3 Gap Analysis

The gap analysis phase compares the current state of the BA initiative (as measured in
the assessment phase) with the goal for the initiative (defined in the vision phase). The
gap between these two is then analyzed to determine the causes and remediation
approaches are identified.
1.3.3.1 Overview
The maturity and adoption scores from the current state assessment phase measure
the progress of a BA initiative and, more importantly, identify specific capabilities that
are lacking or lagging and are therefore inhibiting the BA initiative. The gap between
where the organization is currently and where they need to be to achieve their goal is
broken down by capability domain (from the BA Maturity Model) to identify lagging
domains. It is further broken down by individual capability to identify specific
capabilities that are lacking or lagging. The following diagram illustrates the process:

Figure 16 Gap Analysis Process
Once the lagging capabilities have been identified, a remediation approach for each of
the identified inhibitors is determined from industry best practices and prior Oracle
experience.
1.3.3.2 Details
1.3.3.2.1 Identify Problem Domains

The first step in the gap analysis phase is to identify the domains that exhibit the
largest gap between current maturity and the maturity needed to achieve the BA goal.
The gap for the domains can be visually represented by a spider (aka radar) graph as
shown Figure 17.
Figure 17 Vision versus Current Maturity
The 'Vision' level is determined by the following formula:

Where GS is the score from the goal statement (see Table 13) and SS is the score from
the scope of the BA initiative (see Table 14). This formula maps the goal statement to
a level of maturity necessary to reach that goal. The scope of the initiative is used as a
modifier if the scope score is greater than the goal score i.e. it takes greater maturity to
achieve success on a broader scope. The vision score (VS) is then mapped to the
maturity levels in the BA Maturity Model by applying the simple formula: 1=Ad Hoc,
2=Opportunistic, , 5=Optimized.
For the example spider graph shown in Figure 17, the 'Vision' level was derived
using this formula as follows:
Goal Statement: Maximize revenue, optimize operations, and create competitive
advantage through timely insight and intelligent decision making.
Scope Statement: The BA initiative will span multiple divisions within the enterprise.
So GS = 5 and SS = 4. Therefore, since GS is greater than SS, VS = GS. The GS score of 5
mapped to the maturity levels yields a vision maturity of Optimized. This 'Vision'
level of maturity is what is plotted across all domains in Figure 17.
The 'Current Maturity' level for each domain is calculated by simply averaging the
maturity score for each capability within the domain. This provides an average
maturity for each of the eight domains which is then plotted in the spider graph.
Plotting the Current Maturity relative to the Vision (as shown in Figure 17) provides
a visual representation of the gap between where the organization is with respect to
BA and where it needs to be to meet the goal of the BA initiative. In this example, the
graph clearly shows that the Business & Strategy, Information, and Governance
domains require the most attention.
This analysis is fed into the roadmap creation phase. In this example, initial activities
in the roadmap should center on addressing the lagging capabilities in the Business &
Strategy, Information, and Governance domains.
1.3.3.2.2 Outlier Capabilities

Outlier capabilities are capabilities where the maturity and the adoption are
significantly out of sync. This usually indicates a capability that should receive
attention early in the roadmap. The outlier capabilities can be easily detected by
plotting the maturity and adoption score for each capability in a scatter plot as shown
in Figure 18.

Figure 18 Capabilities Scatter Plot
As shown in the above graph, the maturity and adoption scores for capabilities usually
fall along the diagonal when plotted against each other. In the above example, there
are two scores that are significantly off the diagonal, one well above the diagonal and
one well below the diagonal. The capability well above the diagonal is a capability
from the Architecture domain. The capability well below the diagonal is a capability
from the Organization domain. The analyst will need to review the actual capability
scores to identify exactly which capabilities yielded the outlier points on the graph.
A capability that falls well above the diagonal indicates a capability that is done very
well within a relatively small area of the organization. In this example, there is a
capability at a 'Managed' level of maturity done within a single project. Fostering
greater adoption of this capability provides an easy win for the BA initiative i.e. there
is no need to develop greater competency for this capability within the organization
since it already exists within the organization. Some training or mentoring can spread
the ability more broadly within the organization.
A capability well below the diagonal indicates a capability that is done poorly (or in a
non-compliant fashion) very broadly. In this example, there is a capability being done
at an 'Ad Hoc' level of maturity across the entire enterprise. Corrective action needs to
be taken for this capability since if left uncorrected, it will inhibit (and probably
already has inhibited) the BA initiative.
Capabilities that plot nearer the lower left corner are capabilities that are either
non-existent or are lagging behind the other capabilities. These capabilities will be
addressed in the next step of the gap analysis process.
The capabilities that plot toward the upper right corner are capabilities that are
currently being done well. No remediation is required and the organization should
continue business as usual for those capabilities.
1.3.3.2.3 Low Maturity Capabilities

The capabilities that plot nearer the lower left corner in the scatter plot are capabilities
that require attention in early phases of the roadmap. Capability heat maps can be
used to visually identify these low maturity capabilities as shown in Figure 19.

Figure 19 Capabilities Heat Map
The capabilities heat map colors each of the capabilities based on the maturity score
recorded for that capability. The above diagram shows the color coding legend as well
as each capability with color coding applied. The capabilities are organized by the
domains used in the BA Maturity Model.
The heat maps draw immediate attention to the capabilities that require attention. In
the above example, there is one capability in the Governance domain (Governance
Principles) that scored at the 'No BA' level of maturity. These capabilities should be
addressed in early phases of the BA Roadmap. Likewise, there are several capabilities
in other domains that scored at the 'Ad Hoc' level of maturity. These capabilities
should also be addressed in early phases of the BA Roadmap. It should come as no
surprise that the Business & Strategy, Information, and Governance domains were also
identified in Figure 17 as lagging domains.
It is important to point out that not all capabilities are of equal importance for a
particular organization. In fact, there may be capabilities that are deemed unimportant
or even not applicable for a particular organization. Thus, it is necessary to review
each capability with a low score and determine whether it is a top priority, a low
priority, or unimportant from a roadmap creation perspective.
If a capability is deemed unimportant for a particular organization, it should be
removed from the maturity model and the graphics should be regenerated. This
should be done with caution. A capability should only be removed if it is clearly not
appropriate for the BA initiative at this organization.
1.3.3.2.4 Determine Remediation Activities

At this point in the gap analysis process, the problem domains have been identified
and the problem capabilities within each domain have also been identified. The next
step is to identify remedies for each problem domain and capability. The remedies,
obviously, depend on the problem being addressed and also frequently have some
aspect that is organization specific. Thus, unfortunately, it is not possible to provide a
prescriptive approach to determining remediation activities for all 80+ capabilities.
However, there are some general guidelines based on the domains that can usually be
applied to creating remediation activities.

Table 17 Remediation per Domain

Domain Remediation Comments
Business & Remediation for this domain and the capabilities within this domain
Strategy usually requires executive management decisions and directives. A
common remediation activity is a facilitated workshop with
appropriate executives to define the necessary strategies, make
decisions, and formulate directives.
Architecture Low scores in this domain usually indicate the lack of a reference
architecture for the BA initiative, or if the reference architecture exists,
it lacks completeness and details. Remediation usually entails
workshops with Enterprise Architects to specify a complete, detailed
reference architecture.
Infrastructure Low scores in this domain usually indicate that the BA infrastructure
is lacking significant elements. Infrastructure installation and
configuration type projects are common remediation activities.
Information Low scores in this domain usually indicate issues with the
information architecture, data quality approach, and/or information
stewardship. Common remediation activities are workshops to
address the causes for the low scores and/or EIM projects to improve
architecture capabilities.
Operations, Remediation activities for low scores in this domain usually entail
Administration & definition, documentation, and enforcement of BA compatible OA&M
Management procedures. Low scores could be due to lacking BA knowledge/skills
or could be due to a low maturity of OA&M in general.
Projects, Portfolios & Low scores in this domain usually indicate a lack of BA compatible
Services management and delivery processes. Common remediation activities
entail workshops to modify existing management and delivery
processes to inject BA best practices.
Organization Low scores in this domain usually indicate that roles and
responsibilities appropriate for BA have not been instituted within
the organization. There may also be a lack of BA knowledge/skills.
Common remediation activities include developing training plans
and workshops to define the necessary roles and responsibilities.
Remediation may also require organization restructuring.
Governance Most organizations have existing IT governance in place, so low
scores in this domain usually indicate that governance has not been
extended to cover BA. Remediation usually requires a workshop to
define and institute the governance extensions required for BA.
1.3.3.3 Output
The output from the gap analysis phase is an understanding of which domains and
which individual capabilities are inhibiting the successful achievement of the goal of
the BA initiative. Additionally, remediation activities have been identified to address
the lagging domains and capabilities. These remediation activities provide the primary
input into the roadmap creation process.
1.3.4 Activity Selection and Scheduling

The remedies identified in the gap analysis phase are prioritized and used to create a
plan, called the BA Roadmap. Projects are then evaluated to determine which
remedies are immediately pertinent and beneficial to the projects. BA Roadmap
scheduling and prioritization are derived from the combination of remedies and
projects.

1.3.4.1 Overview
There are five steps in this final phase of the process to create a BA Roadmap. These
five steps are illustrated in Figure 110.
Figure 110 Activity Scheduling Process
As shown in the diagram, the main inputs to this phase are the remediation activities
identified in the gap analysis phase and the portfolio of BA projects that have already
been identified. The final step is to determine timelines and dependencies and
organize all the activities into a schedule.
1.3.4.2 Details
1.3.4.2.1 Determine Program-Level Activities

The program-level activities are determined by prioritizing the remediation activities
identified in the gap analysis phase. Top priority is usually given to remediation
activities that focus on the domain with lowest current maturity score. Top priority
remediation activities are usually the first activities in the roadmap since the results
from these activities are leveraged across the project delivery efforts.
Program-level activities frequently entail changes with wide ranging impacts. For
example, changing the software development process (to inject newly defined best
practices) impacts all development teams within the scope of the BA initiative.
Organizational changes can be even more taxing. Therefore, it is usually necessary to
undertake these changes in a series of iterations. These iterations become the phases of
the overall BA Roadmap. At a high level, this can be shown graphically as illustrated
by Figure 111.

Figure 111 Increasing Maturity Over Time
The graph illustrates three iterations each increasing maturity of one or more domains
until the desired 'vision' level of maturity is achieved. Notice that the first phase
focuses on bringing all domains up to the 'Systematic' level of maturity. This means
that the first phase will primarily include remedy activities for the Business &
Strategy, Information, and Governance domains. Once near parity is achieved across
domains, follow-on phases address the eight domains more uniformly to keep the BA
initiative progressing smoothly.
The amount of change introduced by an iteration must not exceed the organization's
ability to absorb that change; therefore the scope of each iteration must be carefully
planned. Likewise, the duration of each iteration must be long enough to accomplish
some meaningful progress, yet remain short enough to minimize risk and maintain a
continuous pace of incremental progress.
1.3.4.2.2 Create Program Activity Overview

Once a set of program-level activities for this iteration has been determined, further
information will need to be captured for each activity in order to create a roadmap.
This information includes the earliest likely start date, the expected time until
completion, the list of deliverables, and any dependencies that the activity has on
other activities.
Some of this information, particularly the begin and end dates, may depend on who,
or which group, is doing the work. Therefore, it is beneficial to determine who the
responsible parties are for each activity. A RACI chart can be used for this purpose.
This form of chart captures who is responsible, accountable, consulted, and informed
for each activity. Figure 112 illustrates a sample RACI chart that captures the
information described in this section.

Figure 112 Program Activity Overview and RACI Chart
The chart includes six remediation activities that have been selected for this iteration
of the roadmap. Each activity has been assigned one person that is accountable for
ensuring that the activity is completed properly. This person may or may not be
responsible for actually completing the activity. The person who is accountable may
delegate responsibility for completing the activity to one or more other persons.
In addition to the accountable and responsible parties, the chart recognizes that some
people may need to be consulted prior to the completion of the activity. The
'consulted' parties are recognized for their potential interest, input, and guidance on
how the activity is performed. Others may need to be informed when the activity has
been completed. The 'informed' parties are noted as having an interest in the
completed work as they may be directly affected by the outcome.
1.3.4.2.3 Identify Remediation Projects

There are several different types of remediation activities that can be performed. Some
may be performed through workshops, meetings, and strategy sessions. Others may
require the definition and delivery of a project.
Remediation activities for Infrastructure and Information domains are the most likely
to result in project delivery. They identify many capabilities of BA that are more
directly supported by various types of infrastructure. Other domains may also identify
capabilities that are indirectly supported or enhanced using infrastructure, therefore
they may also contribute to remediation project requirements.
Remediation projects can be classified as either program-level or project-level
activities. If the project delivers a solution that is primarily intended to benefit the BA
program and other projects, then it should be classified as a program-level activity.
However, if the project delivers a solution that primarily addresses specific business
needs, then it should be classified as a project-level activity. Funding may also factor
into the classification if program and project funding are provided by different
sources.
1.3.4.2.4 Identify Project and Activity Dependencies

The purpose of this step is to determine if there are any relationships or dependencies
between the remediation activities that have been defined and the BA projects that are
currently scheduled to begin or are already in flight. This enables the gains in maturity
that are obtained via remediation activities to be recognized by the projects, as
applicable. It also helps to avoid any rework or duplication of effort that may occur if
work that is being performed as part of a project happens to be included in, or affected
by, a remediation activity.

When considering the effect a remediation activity has on a particular project, a

number of factors may be considered:
Will the activity make the project easier to complete? For instance, will it help
reduce complexity or provide features or functionality that the project would
otherwise need to develop?
Will it help reduce (or increase) project cost or delivery time?
Will it improve the project results? For example, will it make analysis more
consistent or accurate? Will it make analysis more agile or interactive? Will it
produce a higher quality deliverable?
Will it increase the likelihood that the project will be viewed as a success?
Will it improve any of the non-functional project qualities such as reliability,
availability, scalability, performance, and security?
The remediation activity, applied to a particular project, may also have great benefits
or consequences to the larger BA program. For instance, if a project requires the
deployment of new infrastructure, and a remediation activity is defined to evaluate
infrastructure vendors and recommend a technology standard, then it would be very
beneficial to the program to ensure that the project uses the technology standard that
is evaluated and selected for the program. Otherwise, the project may deploy a
technology that is soon afterward rejected as a standard. In addition to the cost and
effort of potential rework, the program will be set back in its effort to raise its level of
maturity. The project may also inadvertently undermine the goals and principles that
the program has just defined.
To aid in dependency analysis, the overview chart from the previous step has been
modified to identify project relationships in place of RACI assignments, as shown in
Figure 113.
Figure 113 Project / Activity Dependency Analysis
The chart includes five projects that happen to be defined in the BA Project Portfolio.
They are projects that are either scheduled to begin during this iteration of the
roadmap or have recently begun. Each remediation activity is assessed for each
project. The objective is to determine how important it is to the program and the
project for the remediation activity to be completed and applied to the project.
A determination is made given the time constraints each project has, and the
applicability and value of each remediation activity. The determination may follow a
simple 4-option choice:
Must. The project must leverage the outcome of the remediation activity.
Scheduling issues must be resolved in order to make this happen.

Should. The project should leverage the outcome of the remediation activity. A
variance may be requested and obtained if circumstances make it infeasible.
Could. The project could leverage the outcome, if it is conveniently available.
Won't. The project will not be affected by the remediation activity, or a variance to
avoid being affected has been obtained.
As indicated in Figure 113, there are four instances where a remediation activity has a
'must' relationship with a project. Furthermore, a special relationship exists between
Project 3 and RA 3. RA 3 is actually a remediation project that is designed to deliver a
shared data warehouse for unstructured data. Project 3 happens to require such a data
warehouse. Therefore, RA 3 will base its initial set of requirements on the needs of
Project 3, and it will deliver the data warehouse in time for Project 3 integration
testing.
Since, in this example, projects are funded by the line of business, RA 3 is tracked as a
remediation activity rather than a project. The BA program will be able to accomplish
one of its objectives using an existing, funded project.
1.3.4.2.5 Create the Combined Schedule

The combined schedule illustrates the orchestration of program-level activities and
projects over time to achieve the greatest overall benefit. The schedule is based on
information assembled in Figure 113 and refined in order to account for
program-level deliverables that are desired by projects but may not be available until
after the project is underway.
The first step is to create a timeline, beginning with the current time, and spanning the
first iteration of the roadmap. Weekly time intervals are generally convenient to work
with. Next, overlay the program-level activities and projects according to their start
times and durations. Begin with only the activities that are not dependent on other
activities. Add in the dependent activities afterward so that they do not begin until the
deliverables they are dependent upon are scheduled to be completed.
Once this is finished, the dependencies between program-level activities and projects
can be addressed. Start with dependencies that are rated a 'must' as shown in
Figure 113. Ensure that the deliverable from the program-level activity will be
available at the time the project needs it. Deliverables will not always be needed at the
start of the project, particularly if they address issues in later stages of the project, such
as testing, deployment, and maintenance.
Adjustments may need to be made to the schedule, or to the scope of the deliverable,
in order to have it completed by the project's 'need by' date. Negotiate the necessary
changes and adjust the schedule and activity overview accordingly. Complete all of
the 'must' relationships before moving on to the 'should' relationships.
Repeat the same procedure for instances where a project 'should' leverage the output
of a program-level activity. Make adjustments to the schedule as needed in order to
accommodate as many cases as possible. For those cases where scheduling does not
permit the inclusion of program-level deliverables into the project, determine a best
effort alternative and grant a variance.
Lastly, identify the areas where projects can use program-level activity deliverables as
indicated by a 'could' relationship. Since these instances are by definition 'best effort', it
isn't necessary to go to great lengths to accommodate these requests.

Figure 114 Roadmap Phase 1 Schedule
Figure 114 serves as a basic example of how the roadmap may be organized. It is
divided into two sections: the top section contains program-level activities, and the
bottom section contains projects. The program-level activities are identified using
remediation activity (RA) numbers for sake of simplicity. RA-3, in this example, is also
identified as an infrastructure project.
Hard dependencies, e.g. 'must' relationships, between activities and projects are
denoted with solid lines. The lines originate from the point in time where the
deliverable is completed to the point in time where it is needed. In some cases the
'needed by' date is the beginning of an activity or project, while in others cases it is
some point in time during the life cycle of the project. In contrast, dashed lines are
used to indicate a 'should' relationship.
Three additional activities have been added to the diagram: "BA Leadership", "Align
Program Accomplishments and Deliverables with Projects", and "Phase 2 Planning".
The first two identify ongoing activities that are required in order to continually
advance the program. Additional such activities may be added to represent the work
of a 'Center of Excellence' or similar group that is chartered with mentoring and
establishing best practices. Phase 2 Planning represents a reassessment of BA Maturity
as a result of the first phase of remediation. The deliverable from this activity is the
detailed roadmap for the second phase.
In Figure 114 the link between program-level deliverables and projects is mediated
by the alignment activity. The intent is to actively facilitate the use of these
deliverables in order to advance the program. The diagram includes vertical arrows to
represent the acceptance of program-level deliverables. It uses the same arrows to
indicate where deliverables are used by projects, representing the 'could' relationship
from the previous section.
As mentioned earlier, the detail in the initial phase of the BA Roadmap will be much
greater than the detail provided for the later phases. The later phases likely include
additional program-level activities and more projects, but will contain less detail since
precise dates are more difficult to predict. An example of such a schedule is shown in
Figure 115.

Closing Comments
Figure 115 BA Roadmap Subsequent Phases
The first phase schedule was broken down into weeks but only covered two quarters.
This schedule covers the entire planning horizon (three years) but with significantly
less detail.
The program-level activities chosen for the first phase were meant to address the most
pressing needs and deficiencies. The activities undertaken in subsequent phases may
be selected based on knowledge of specific projects and business initiatives that are
being planned. This foresight can be used to make the dependency analysis and
scheduling process more beneficial and advantageous.
1.3.4.3 Output
The output from the roadmap creation phase is the BA Roadmap that includes a
detailed initial phase and less detailed subsequent phases. The BA Roadmap provides
guidance for achieving the goal of the BA initiative via a series of much smaller
transitions. Ideally, each of the smaller transitions has its own individual business
benefit, but it is frequently necessary to invest a little up front to reap larger benefits
down the line.
1.4 Closing Comments

It is important to keep the end goal in mind when applying this roadmap creation
process. The end goal is achieving the goal of the BA initiative. It is NOT to attain a
particular score on the BA Maturity Model. The success of the BA initiative is
measured by the realization of the prioritized BA benefits identified in the Future
Vision Definition phase. The BA Maturity Model and the various frameworks are
merely tools to help build a plan to achieve the goal.
Finally, and perhaps most importantly, this is an incremental approach. The process
described in this document to create a BA Roadmap should be regularly re-applied
and the roadmap should be updated to reflect the changing reality. This allows each
iteration of the process to focus on the most pressing needs. Areas not of immediate
concern can be relegated to future iterations, thereby reducing the size and complexity
of the current iteration.

A
ABA Maturity Model
The Oracle BA Maturity Model defines the following key concepts: capabilities,
domains, maturity, and adoption.
A.1 Capabilities
The BA Maturity Model includes over eighty capabilities that capture the best
practices that Oracle has collected over many years working with a wide variety of
companies. There is still considerable debate on what constitutes BA best practices and
standards, and products change fairly regularly, therefore the BA Maturity Model
remains technology, standards, and product agnostic while still capturing the major
tenants of a complete BA strategy.
Additional capabilities are added as the field of BA evolves. Thus, the details of the BA
Maturity Model will continue to evolve as new technologies and capabilities emerge.
This allows the specifics to morph and improve as industry and Oracle knowledge of
BA advance. One of the capabilities from the maturity model is shown in Figure A1.
BA Maturity Model A-1

Domains
Figure A1 Integrated Analysis Capability
As shown in the above figure, for each capability included in the model, a description
for each level of maturity and each level of adoption is provided. (The maturity and
adoption levels are defined below.) Although there is always some level of subjectivity
when measuring a capability, these descriptions minimize the subjectivity injected,
and thereby provide, as best as possible, an objective measure of both maturity and
adoption.
A.2 Domains
The BA Maturity Model uses the concept of domains to classify and organize the
related capabilities. As depicted in Figure 17, there are eight domains in the maturity
model:
A-2 Creating a BA Roadmap

Domains
Figure A2 BA Capability Domains
Business & Strategy - Contains capabilities that provide the high-level constructs
that allow the BA initiative to proceed. This includes such things as business
motivation, expected benefits, guiding principles, expected costs, funding model,
etc.
Architecture - Contains capabilities concerning the definitions of the overall
architecture and guidelines for various practitioners to ensure adherence to the
architecture.
Infrastructure - Contains capabilities concerning the infrastructure and tools that
provide the technical foundation for the BA initiative.
Information - Contains capabilities concerning the information aspects of BA, e.g.,
providing information acquisition, management, virtualization, and access
capabilities.
Projects, Portfolios & Services - Contains capabilities concerning the planning,
building, and delivery of BA projects and services.
Operations, Administration & Management - Contains capabilities concerning
the post deployment aspects of BA solutions i.e. the Operations, Administration,
and Management aspects of BA.
Organization - Contains capabilities concerning the development of corporate
competency around BA including the organizational structure and skills
development.
Governance - Contains capabilities concerning the governance structures and
processes that support and guide the BA efforts. Maturity and adoption of an
adequate amount of governance is a leading indicator of the overall BA success.
These eight domains, although interrelated, are sufficiently distinct. To succeed at BA
adoption, an organization must make adequate progress in all of these domains.
Inevitably an organization will be more advanced in some domains (and further in
some of the capabilities within a domain) than others. Therefore, it is important to be
able to measure the relative maturity within each domain (and capabilities therein)

Maturity
and across domains to identify areas that are lagging. Once the lagging areas have
been identified it is possible to formulate remedies and thereby improve the success of
the overall BA program.
A.3 Maturity
Within the software industry, maturity is frequently related to the Capability Maturity
Model (CMM) and the CMM successor, the Capability Maturity Model Integration
(CMMI). The BA Maturity Model parallels this understanding and measures BA
capability against defined maturity levels. The levels of maturity used in the BA
Maturity Model (from highest to lowest) are:
Optimized - Metrics are being consistently gathered and are being used to
incrementally improve the capability. Assets are proactively maintained to ensure
relevancy and correctness.
Managed - The capability is being measured and quantitatively managed via
some type of governance structure. Appropriate metrics are being gathered and
reported.
Systematic - The approach has been reviewed and accepted by affected parties.
There has been buy-in to the documented approach and the approach is always
(or nearly always) followed.
Opportunistic - An approach has been decided upon and is being
opportunistically applied. The approach has not been widely accepted nor
adopted. It may be incomplete, informally defined, or if documented, may exist
primarily as "shelf ware".
Ad Hoc - Decisions are based on individual perceptions and practices. There is no
common BA strategy, data definitions, or formal measures defined.
No BA - There is no BA approach being taken. Decisions and forecasts are based
on intuition and/or routine.
The maturity levels progress from 'No BA' up to 'Optimized.' These levels define the
path an organization usually takes moving toward BA maturity. BA by its very nature
requires coordination, cooperation, and a common vision to be successful; therefore, it
is necessary to define the strategy before it is possible to be truly successful at
repeating it and then ultimately optimizing it.
A.4 Adoption
Adoption measures how widely BA best practices are being defined, accepted,
embraced, and applied within the enterprise. For smaller organizations within a single
line-of-business, maturity and adoption are usually tightly related since there is a
single approach to BA being followed by the entire organization.
However, within large companies with multiple divisions or lines-of-business this is
not usually the case. It is common to have one or more divisions that are relatively
mature in BA while other divisions are less so. The BA Maturity Model handles these
situations by providing a separate measure for adoption level. This allows a single
division to be effectively evaluated for BA maturity while still capturing the lack of
widespread adoption as a separate measure.
The levels of adoption used in the BA Maturity Model are:
Enterprise Level - The capability is implemented consistently across the enterprise
i.e. all divisions or business units are applying the same approach.

Adoption
Cross Division - The capability is implemented by multiple divisions using a

common approach i.e. the approach is being shared or is spreading to multiple
divisions.
Division Wide - The capability is implemented consistently across a division or
business unit. A division or business unit is led by an executive at the VP level or
higher.
Department Level - A directive for adoption exists at a lesser scope than the
division. The scope may be a department or program within a division with
leadership at the manager or director level.
Individual Level - No formal directive for adoption exists or is being followed.
Uniformity is a function of the sharing and voluntary adoption of best practices
amongst individuals or projects / solutions within an organization.
No Implementation - There is no current implementation anywhere in the
organization of the capability being measured.
For small organizations, it may be desirable to ignore the adoption dimension
altogether and simply measure maturity. Conversely, for very large organizations
with a goal of achieving enterprise-wide BA adoption, it may be desirable to measure
the maturity for each division or line-of-business separately and then provide a single
measure of adoption across the enterprise. It should be noted, however, that for the
realization of many of the key BA benefits, a level of adoption across the organization
is critical. For example, it is possible to have two divisions with mature but
incompatible capabilities in which case the adoption is lower (division-wide) and that
will inhibit an enterprise-wide BA initiative.
Thus, to properly measure the overall progress of BA initiative in a large organization,
the maturity of the individual capabilities and the degree of adoption of such
capabilities across the organization is vital.

Adoption

Oracle Technology Strategies - Creating A Business Analytics Roadmap (Practitioner Guides) - 2015

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Oracle Technology Strategies - Creating A Business Analytics Roadmap (Practitioner Guides) - 2015

Загружено:

Авторское право:

Доступные форматы

Oracle Practitioner Guide

Copyright 2013 Oracle and/or its affiliates. All rights reserved.

Primary Author: Dave Chappelle

THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS

Third Party Content, Products, and Services Disclaimer

Send Us Your Comments ........................................................................................................................ ix

Creating a BA Roadmap, Release 3.0

How to Use This Document

ITSO is made up of three primary elements:

Business analytics (BA), as the name suggests, is very much a business-driven

1.1 BA Roadmap Drivers

1.1.1 Top-Line Drivers

Creating a BA Roadmap 1-1

Improved product strategies based on predictive analytics, historical analysis, and

1.1.2 Bottom-Line Drivers

1.1.3 Agility Drivers

1-2 Creating a BA Roadmap

1.2 BA Roadmap Defined

Figure 11 BA Roadmap Program and Project Scope

Creating a BA Roadmap 1-3

Activities included in the program-level scope are intended to advance BA maturity

1.3 Roadmap Creation Process

1-4 Creating a BA Roadmap

Figure 12 Roadmap Creation Process

1.3.1 Current State Assessment

Creating a BA Roadmap 1-5

Figure 13 Current State Assessment Process

1.3.1.2.1 Define Scope

1.3.1.2.2 Identify Interview Participants

1-6 Creating a BA Roadmap

Table 11 Typical Interview Participants

Program Management PMO Manager

1.3.1.2.3 Determine Interview Schedule

1.3.1.2.4 Gather and Review Relevant Documents

Creating a BA Roadmap 1-7

material for clarification or to resolve conflicting information. The following table

Table 12 Typical Relevant Documents

1.3.1.2.5 Perform Interviews

1.3.1.2.6 Assign Capability Scores

1-8 Creating a BA Roadmap

1.3.2 Future Vision Definition

Figure 14 Future Vision Definition Process

Creating a BA Roadmap 1-9

Table 13 BA Goal Statements

Table 14 BA Initiative Scope

Defining the scope of the BA initiative is essential to determining a roadmap. With

1-10 Creating a BA Roadmap

Table 15 Example BA Benefits

Table 16 Example BA Guiding Principles

Creating a BA Roadmap 1-11

Figure 15 Example BA Vision Summary

1.3.3 Gap Analysis

1-12 Creating a BA Roadmap

Figure 16 Gap Analysis Process

1.3.3.2.1 Identify Problem Domains

Figure 17 Vision versus Current Maturity

The 'Vision' level is determined by the following formula:

Creating a BA Roadmap 1-13

1.3.3.2.2 Outlier Capabilities

1-14 Creating a BA Roadmap

Figure 18 Capabilities Scatter Plot

1.3.3.2.3 Low Maturity Capabilities

Creating a BA Roadmap 1-15