The purpose of the previous blogs was to give a high-level understanding of the “SAP Data and Analytics Advisory Methodology”:
With this blog we will start to provide more details on the phases and steps to develop a target solution architecture for data-driven business outcomes and use cases.
Phase I is designed to prepare the subsequent architecture development work. It clarifies why a need for action exists. It includes scope definition and planning of the architecture investigation and reviewing all relevant artefacts. A more foundational analysis to identify issues or opportunities in the area of data management and analytics can be conducted, if required. This might be useful if data-driven business outcomes are not clear or need to be prioritized.
Why is this phase important? Because the methodology assumes that the execution of the architecture development work should be treated as project and managed according to defined project management standards. And a proper planning is the foundation for a successful project execution.
Without understanding the goals and related functional / technical scope, resources, stakeholders, timeline and other restricting factors it is hard to monitor progress and success against a defined outcome or result. The project context, a good understanding of the current business and IT environment and the identification of current issues or opportunities is the foundation to organize the subsequent architecture development process managed in phases II and III.
In good project management practice every project starts with a definition of its unique purpose and goals.
Usually this is described in a project charter, a short document that explains the project in clear, concise wording for high-level management. A similar approach is used in architecture development methods. TOGAF for example introduced an “Statement of Architecture Work”. The idea is the same: outline the entirety of the project to help teams quickly understand the goals, tasks, timelines, and stakeholders.
The statement of work should include the following aspects:
There might be additional dimensions that can be documented accordingly.
Any additional information that supports the project definition can be added as required. But keep in mind that the statement of work should give a quick overview of the project and therefore only the key aspects should be documented.
In case of a more comprehensive investigation a detailed project plan is advisable to plan and track progress.
To complete this step, a kick-off meeting is advisable to get all participants and stakeholders aligned. This will ensure that everyone is getting a common understanding of what needs to be delivered and why.
This step is required to provide all artefacts that help to understand the current customer situation in context of the previously defined scope. This can be architecture representations, data models, process descriptions, responsibility matrix, organizational charts or capability maps.
These artefacts need to be provided in a central repository that is accessible to all involved parties and allows for collaboration. They should be provided in advance of the workshop to allow participants to preview the content and prepare questions.
A capability assessment can be conducted at this stage to understand current data and analytics expertise. You can use the data & analytics capability model provided by the methodology or any other comparable model available as a reference for analysis. Nevertheless, this can also be done in phase III where to-be capabilities are identified based on use case analysis results. If mapped against as-is capabilities the gaps should emerge and considered in the further process.
The same applies for data governance aspects that can already be discussed in this phase. Related issues will be considered again in phase IV of the methodology where data governance and organizational impacts are analyzed.
The first workshop should be used by the project team to analyze the as-is situation and investigate questions like the following:
The goal is to get everyone on the same level of understanding to investigate the improvement potential and opportunities.
The final step provides tools and methods to analyses current issues or pain points in the data management and analytics space. Or it can be used to identify potential improvements or even new data-driven business opportunities.
Usually, such analysis is conducted before the architecture definition phases, e.g., as part of a more strategic data & analytics investigation. Depending on the scope this could be a project on its own. Just consider that such analysis would cover several Lines of Business (LoBs), business units or countries such investigation might get quite extensive.
Thus, the tools and methods referenced in the methodology represent only some examples:
The first two focus more on strategic excellence, i.e., introducing new processes, products, business capabilities or business models. The latter two can be used when the focus is more on operational excellence (pain point & improvement analysis).
Whatever approach you chose the result should be a list of issues that need to be prioritized to focus on the most beneficial ones first. A Business Priority Matrix is a good instrument to support this process.
The Business Priority Matrix has two dimensions:
Each issue is positioned in the matrix which helps to prioritize the issues. This can be done by functional area together with respective business representatives. If several LoBs are analyzed the top 2-3 issues by LoB can be consolidated in one matrix to discuss the overall sequence to resolve those issues.
Here is a customer example from LoB Supply Chain:
Finally, the issues or opportunities that should be investigated in the following target architecture development phases need to be translated into business outcomes. This is the first step of phase II of the SAP Data & Analytics Advisory Methodology. We will describe the details in the next blog.
Please reach out to sap-data-analytics-methodology@sap.com to get invited to our SAP Build Work Zone workspace to get access to the presentation and further assets like templates.
- Release of SAP Data and Analytics Advisory Methodology
- Motivation and Key Artefacts of SAP Data and Analytics Advisory Methodology
- General approach of SAP Data and Analytics Advisory Methodology
With this blog we will start to provide more details on the phases and steps to develop a target solution architecture for data-driven business outcomes and use cases.
Overview of phase I
Phase I is designed to prepare the subsequent architecture development work. It clarifies why a need for action exists. It includes scope definition and planning of the architecture investigation and reviewing all relevant artefacts. A more foundational analysis to identify issues or opportunities in the area of data management and analytics can be conducted, if required. This might be useful if data-driven business outcomes are not clear or need to be prioritized.
Why is this phase important? Because the methodology assumes that the execution of the architecture development work should be treated as project and managed according to defined project management standards. And a proper planning is the foundation for a successful project execution.
Without understanding the goals and related functional / technical scope, resources, stakeholders, timeline and other restricting factors it is hard to monitor progress and success against a defined outcome or result. The project context, a good understanding of the current business and IT environment and the identification of current issues or opportunities is the foundation to organize the subsequent architecture development process managed in phases II and III.
Step I.1: Define scope of investigation
In good project management practice every project starts with a definition of its unique purpose and goals.
Usually this is described in a project charter, a short document that explains the project in clear, concise wording for high-level management. A similar approach is used in architecture development methods. TOGAF for example introduced an “Statement of Architecture Work”. The idea is the same: outline the entirety of the project to help teams quickly understand the goals, tasks, timelines, and stakeholders.
The statement of work should include the following aspects:
- First, a description of the mission or purpose and main drivers is provided.
- Next up is the scope of the investigation that spans several scope dimensions:
- Organizational Scope: Global focus with enterprise-wide investigation or regional / local focus, i.e., only selected business units, sites or countries
- Business Process Scope: Selected E2E processes or functional process areas
- Functional / Data Domain Scope: Selected Line of business and related Data Domains (if already existing)
- Data Architecture Scope: Business applications, data & analytics solutions and related technology components
- Data scope: List of key data entities if already known.
There might be additional dimensions that can be documented accordingly.
- Then the main deliverables of the investigation are listed. They define what result artefacts need to be delivered. Examples in context of data and analytics could be a report, an architecture model, a capability heat map, or even a prototype.
- The deliverables need to be scheduled and put into a plan that outlines the key milestones and due dates.
- Finally, it is advisable to list the key roles and resources of the investigation. This starts with the sponsor, followed by the project lead and finally key roles from business and IT contributing to the project.
Any additional information that supports the project definition can be added as required. But keep in mind that the statement of work should give a quick overview of the project and therefore only the key aspects should be documented.
In case of a more comprehensive investigation a detailed project plan is advisable to plan and track progress.
To complete this step, a kick-off meeting is advisable to get all participants and stakeholders aligned. This will ensure that everyone is getting a common understanding of what needs to be delivered and why.
Step I.2: Overview of current data architecture & capabilities
This step is required to provide all artefacts that help to understand the current customer situation in context of the previously defined scope. This can be architecture representations, data models, process descriptions, responsibility matrix, organizational charts or capability maps.
These artefacts need to be provided in a central repository that is accessible to all involved parties and allows for collaboration. They should be provided in advance of the workshop to allow participants to preview the content and prepare questions.
A capability assessment can be conducted at this stage to understand current data and analytics expertise. You can use the data & analytics capability model provided by the methodology or any other comparable model available as a reference for analysis. Nevertheless, this can also be done in phase III where to-be capabilities are identified based on use case analysis results. If mapped against as-is capabilities the gaps should emerge and considered in the further process.
The same applies for data governance aspects that can already be discussed in this phase. Related issues will be considered again in phase IV of the methodology where data governance and organizational impacts are analyzed.
The first workshop should be used by the project team to analyze the as-is situation and investigate questions like the following:
- how the current data & analytics landscape looks like,
- where data in scope of the investigation is residing,
- how data is created in transaction systems, integrated and managed in data stores for analytics purposes and
- which analytics tools are used for which analytics purpose.
The goal is to get everyone on the same level of understanding to investigate the improvement potential and opportunities.
Step I.3: Opportunities & improvement potential
The final step provides tools and methods to analyses current issues or pain points in the data management and analytics space. Or it can be used to identify potential improvements or even new data-driven business opportunities.
Usually, such analysis is conducted before the architecture definition phases, e.g., as part of a more strategic data & analytics investigation. Depending on the scope this could be a project on its own. Just consider that such analysis would cover several Lines of Business (LoBs), business units or countries such investigation might get quite extensive.
Thus, the tools and methods referenced in the methodology represent only some examples:
- SWOT Analysis
- Design Thinking
- Fishbone diagram
- SAP Data & Analytics Strategy Assessment (SAP Service)
The first two focus more on strategic excellence, i.e., introducing new processes, products, business capabilities or business models. The latter two can be used when the focus is more on operational excellence (pain point & improvement analysis).
Whatever approach you chose the result should be a list of issues that need to be prioritized to focus on the most beneficial ones first. A Business Priority Matrix is a good instrument to support this process.
The Business Priority Matrix has two dimensions:
- “Business Pain”: how big is the issue and
- “Business Impact”: if resolved.
Each issue is positioned in the matrix which helps to prioritize the issues. This can be done by functional area together with respective business representatives. If several LoBs are analyzed the top 2-3 issues by LoB can be consolidated in one matrix to discuss the overall sequence to resolve those issues.
Here is a customer example from LoB Supply Chain:
Finally, the issues or opportunities that should be investigated in the following target architecture development phases need to be translated into business outcomes. This is the first step of phase II of the SAP Data & Analytics Advisory Methodology. We will describe the details in the next blog.
Please reach out to sap-data-analytics-methodology@sap.com to get invited to our SAP Build Work Zone workspace to get access to the presentation and further assets like templates.
- SAP Managed Tags:
1 Comment
