Hai

Business Process Management
Purpose
The purpose of the business process management (BPM) work stream is to build a detailed to-be process and solution design. Business process management includes the following components: Value determination Business process maps Business process and solution design (process level 3- 5) Business process requirements Process models Solution transformation design
Project preparation focuses on the determination of value drivers and the process and solution design on process level (PL) 1-2, which has no corresponding level in SAP Solution Manager. Please note that if scenario-level design was not completed during project preparation or in a prior BPM project, scenarios are defined as part of blueprinting before process level definition. Blueprinting focuses on refining value drivers and associating them to the process hierarchies and the solution design on PL 3-5, corresponding to the process and process-step levels in SAP Solution Manager.
During realization the solution design gets finalized and built. Configuration, SOA/Composition rationales, and technical specifications capture the final design. It is best to start value audits now as well, to monitor whether the project is on track toward realizing the expected benefits.
Inputs
The inputs for business process management are: Project scope (statement of work) Catalog of as-is business process documents, as appropriate Value realization deliverables (such as pain point analysis, value map, and identification of key process changes) Business process maps Business scenario design, as available SAP Solution Manager business process repository, as available Best practices and preconfigured solutions, as available
Deliverables
The major deliverables for business process management are: Value realization deliverables, such as refinement of value maps and the association of KPIs and PPIs on the process level Business object modeling (including organizational structures, master data, and user roles) Detail business process design (PL3-5) Business process map, if not already produced during project preparation Scenario solution design, if not already produced during project preparation Business process and process-step design documents Business process lows (such as value-added chain diagrams, event-driven process chains)
Detail solution design Business process design detail mapped to: 1. Core configuration
2. Core enhancement (functional specifications and reports, interfaces, conversions, enhancements, forms, and workflows per the RICEFW list) 3. SOA/Composition 4. Third-party solutions Detail business process design and solution captured in a blueprinting document managed in SAP Solution Manager
BPM deliverables are best created and stored in SAP Solution Manager. Each deliverable has a separate documentation template type. Deliverable templates originate from the roadmap in the ASAP methodology and are loaded to SAP Solution Manager during project setup. In the absence of SAP Solution Manager, the team can create a single- or multiple-file blueprint.
Integration
The integration points for business process management are: Business process management in project preparation Business process management in the realization phase
Additional Information
For modeling notations on value-added chain diagrams and event-driven process chains, see the BPX community wiki site and the SAP Process Modeling Handbook . Deliverables like value maps and to-be process models can be adapted from any comprehensive BPM or CVR initiative executed prior to blueprinting. BPM leverages the business process repository and SAP Best Practices packages as references for business process design sessions.
Blueprint Approach
Purpose
The purpose of blueprinting is to create a body of work, known as the business blueprint, that Identifies business requirements Illustrates how a company intends to run its business using SAP applications Documents the to-be processes in process models Describes the functional and technical solution design Obtains business sign-off on requirements and solution design Supports value delivery
The blueprint approach is not an implementation deliverable, but instead describes how deliverables get produced during blueprinting, specifying a methodology or path for blueprinting
Blueprinting is based on the assumption that an implementation creates value for the customer. That value must be specified and associated to the scope of the implementation. This association is performed on process levels, and the project team typically produces a value map of KPIs and PPIs to measure the progress of value delivery. Blueprinting is also an iterative approach to solution design organized by processes. The modeling of tobe processes starts at the highest level and moves down the process hierarchy. The SAP process model has five process levels, of which scenarios, processes, process steps or activities are managed in SAP Solution Manager. Typically, the first two levels of process design are delivered as part of business process management during project preparation. To-be process design might be supported by a focused as-is analysis that catalogs processes, applications, and existing data models. As-is documents are intended to serve as a point of reference for the future solution design. The comparison of as-is and to-be processes drives organizational transformation needs. SAP Solution Manager is intended to serve as the central knowledge repository during the full implementation lifecycle. The business process repository serves as the starting point for process models. Solution design deliverables are created and managed in SAP Solution Manager. Blueprinting follows agile principles and leverages best practices, preconfigured content, and techniques such as value prototyping, show-and-tell, conference room pilots, or sprints to illustrate SAP solution functionality and to visualize the solution design. Characteristics of agile techniques are iterations, timeboxed design, and visualization. Blueprint content is developed as the result of a series of workshops chronologically organized in sequence with the process hierarchy. The business blueprint workshop concept provides detailed information on workshops facilitation and documentation generation.
The final outcome of this work stream is a business blueprint, which is typically not a single document but a body of documents that incorporates multiple design elements, such as requirements, models, function solution design, gap analysis, and technical and integration design The recommended approach is to manage and create blueprint documents in SAP Solution Manager. However, depending on the implementation scope and in the absence of SAP Solution Manager, a document-based or minimalistic approach may be chosen, for which templates are available.
All blueprint variants adhere to the content and deliverable specifications for blueprinting work streams. The blueprint approach is determined in agreement with the customer and based on the scope of the implementation. It is typically captured in a project charter. The blueprint approach helps team members: Understand the path to producing blueprint deliverables Leverage the best fit of agile and value determination techniques
Expected Results
The intent of the blueprinting work stream is to deliver various documents as project deliverables. Among these the solution-oriented documentation should be managed in SAP Solution Manager as the primary document repository. Additional documentation, such as project management documents and solution-independent documents are stored in dedicated document management systems outside SAP Solution Manager.
The blueprint approach in SAP project work is based on the following proven methodologies: Value realization, which creates the framework for scope and delivery of expected benefits BPM methodology that provides the framework for process decomposition Agile acceleration techniques that support speed to market and incorporate visualizations, iterative feedback loops, and frequent control points
Solution Manager and Business Process Management

Purpose
The purpose of solution manager and business process management is to transfer designed business processes into SAP Solution Manager. The approach is determined by whether or not a modeling tool was used during earlier phases to set up a business process structure. With a Modeling Tool In this case a process structure has been created in the ARIS software from IDS Scheer or a similar modeling tool during opportunity management, project preparation, or parts of blueprinting to design the processes from a business perspective. After the structure is in place, the business process models are transferred to SAP Solution Manager to develop the solution. This ensures that the external tool and SAP Solution Manager are synchronized during further process modeling. Without a Modeling Tool
No modeling tool has been used during project preparation, and no business process modeling environment exists. In this case SAP Solution Manager is leveraged to define the business process levels (business scenario, business process, business process step). For the creation of the business process structure, the business process repository can be used as a baseline reference model for process design and prototyping, or the process structure can be defined based on the existing business process list. In any case, all blueprinting documents such as business process lists, process flow charts, and functional requirements specifications are associated with the business process hierarchy and managed within the SAP Solution Manager knowledge repository. The documents remain in that repository can be displayed from the external tool by means of cross-referencing.
Inputs
The inputs for solution manager and business process management are: Business process repository (SAP Solution Manager) Business process list Requirements descriptions Process flow SAP Solution manager operational guideline SAP Process modeling handbook BPX community wiki site System landscape with logical components (project preparation phase)
Subdeliverables
The subdeliverables for solution manager and business process management are: Project scope process structure with all blueprinting documentation in SAP Solution Manager Assignment of logical components (solutions) and transactions (if available) at the process-step level
Expected Results
Once the solution manager and business process management deliverables are complete, the project has one central repository for all solution-related documentation. The process structure with assigned logical components in SAP Solution Manager drives the build phase, along with testing and incident management. With this body of knowledge in place, the transition into operational production after go-live is easier.
For additional information on existing SAP process management, see the SAP business process repository at https://implementationcontent.sap.com/bpr For details on process modeling, see the SAP Process Modeling Handbook, BPX community wiki site, section 2 at http://wiki.sdn.sap.com/wiki/display/ModHandbook/SAP+Modeling+Handbook+Management+Summary For details on ARIS and SAP Solution Manager Integration, see the SAP Field Services Modeling Handbook, section 5.
Value Realization
Purpose
The purpose of a value-based solution design is to align the value drivers and key process changes with the business blueprinting process. The following figure shows value deliverables (in orange and process management and technical solution design deliverables in blue. Value determination should be completed by the project preparation phase, or at the latest at the beginning of blueprinting. A business case is the starting point for value determination. Based on the input of process owners and business stakeholders, a pain point analysis is undertaken and key process changes are determined. The value map links pain points, key process changes, and performance indicators and is thus the central deliverable for value determination. The results from value determination are mapped to the process and solution design. A link is maintained through value maps, key performance indicators (KPIs), and process performance indicators (PPIs). At the scenario level, financial KPIs come into play, and at the process level PPIs are the link to the value drivers. A value realization roadmap or landscape can also be created to illustrate how the overall solution is sequenced in implementation cycles in order to optimize the time to value. The landscape illustrates the overall integration of the SAP solution into the legacy environment.
The purpose of value realization is to: Refine value drivers, identified in project preparation, and associate them with blueprint deliverables Determine the impact and use value maps within the blueprinting approach Associate value drivers with the process hierarchy in SAP solution manager Define the Value Dashboard to track and manage the value during the whole project lifecycle, including post implementation Use the business value as a key decision element for scope changes Update the business case with the new information to set the right level of expectations with business executives
Inputs
The inputs for value realization are based on outputs from value determination/value map during project preparation and include: Statement of work scope determination Business case Initiative roadmap, as applicable To-be solution design (PL1-2), as applicable As-is analysis, as applicable Pain point analysis, as applicable Process weaknesses (in process flow, organizational structure, system support, and data structure) Value maps (financial and operational KPIs
Deliverables
The deliverables for value realization are Refined value maps Association of a value map breakdown to process decomposition Association of financial and operational KPIs on a scenario level Value Dashboard with operational KPIs and PPIs on a process level Updated Business Case Value Based scope change management
Expected Results
Value realization enhances the ability of the project team to: Determine priorities for the solution design and to manage scope Determine development needs to ensure that every solution enhancement maps to a value driver Drive key decisions for the solution design Track progress of key process changes
Define the tracking tool to ensure value attainment post go live
Value realization is a key step that is assed during the implementation in the value assessment.
Business Objects Modeling

Purpose
The purpose of business objects modeling (cross-process view) is to identify business objects that are relevant for the scope of the implementation, such as organizational structures or customer or material masters, and to design a solution for these business objects within the SAP solution. Business objects are associated to processes and reflected in applications. Understanding these relationships is essential for overall integration and cross-process integrity. Business object modeling may also build the foundation for service modeling, if the project is implementing a service-oriented architecture (SOA).
Inputs
The inputs for business objects modeling are: Project scope as recorded in the statement of work (SOW) Business process map Business process and cross-functional requirements
Deliverables
The deliverables for business objects modeling are: Business organizational structures within the SAP solution Understanding of general settings Identification and solution design for master data elements User role concepts Logical data models, as applicable
Expected Results
When business objects modeling is completed correctly, the project is able to avoid misunderstandings driven by ambiguous business object definitions. It is essential, for example, that customer orders and vendor orders be clearly differentiated, since order by itself is ambiguous.
Business object and service modeling rules are described under Static Modeling Standards and Service Modeling in the SAP Process Modeling Handbook on the BPX community wiki site.
Business Organizational Structure

Purpose
The purpose of a business organizational structure is to model the to-be organizational structure design that reflects business requirements and provides a translation into the design framework for the SAP solution. The design is based on the current business organizational models, which are analyzed and brought into the context of to-be processes and functionality. The design of business organizational structures not only drives system behavior, but is also relevant for reporting purposes.
Inputs
The inputs for the business organizational structure include: Scope as defined in the statement of work As-is organizational structure and design documentation Business process map Key decision documentation Global design principles Authorization and security requirements
Subdeliverables
The standard organizational structure design framework governs modeling of organizational structures, master data, and business processes. The design of the organizational structure is based on an understanding of this framework and the functional requirements for application behavior. The design and requirements of the organizational structure reflect multiple views of a company: Legal Fiscal Functional Product-oriented Regional and geographical -
Customer-group Distribution-channel Purchasing-channel
It is best to store all organizational structure deliverables in the process hierarchy in SAP Solution Manager.
Expected Results
The expected result is the design of an organizational structure that supports business processes and reporting within the standard design framework. The design takes into account current and to-be processes and includes: Identification and definition of organizational entities and their interrelationships Organizational design that allows for future company changes Detailed documentation of the customer organization, including all legal entities. Identification and consideration of geographic and hierarchical structures A baseline model for process analysis or at least an understanding of the relationships among processes) A first, high-level definition of the required reporting levels
For more details on modeling notation, see Modeling of Organizational Structures in the SAP Process Modeling Handbook on the BPX community wiki site. See also the business process repository.
General Settings and Master Data

Purpose
The purpose of General Settings and Master Data is a detailed description of design and maintenance processes for general settings and master data. These processes must be correlated with standard master data models and general settings in the Implementation Management Guide (IMG).
Inputs
The inputs for general settings and master data include: Implementations scope as recorded in the statement of work Process maps Business scenario descriptions, as applicable Global design principles Key decision documentation Business organizational structures and models
Subdeliverables
The team should produce one deliverable or document per master-data or general-setting object. The documentation should include: General Settings and Master Data Design, addressing cross-application general settings for countries, languages, currencies, organizational units, units of measure, number ranges, product hierarchies, material types, shipment rules, and so on Definition of business rules, including ownership Master Data Requirements and Design Document, addressing such general master data elements as materials, products, customers, vendors, and business partners
Expected Results
The result is a harmonized solution design for general settings and master data elements at the configuration and key-field level.
For details on modeling business objects, see Modeling of Software Independent Business Objects (ERM) in the SAP Process Modeling Handbook on the BPX community wiki site. See also the business process repository at https://implementationcontent.sap.com/bpr
User Role Concept

Purpose
The purpose of the user role concept is to describe all relevant end-user roles and corresponding responsibilities from a business point of view. The foundation is the approved business organizational model, used as the basis for a harmonized and consistent end-user role concept that supports the operation of the designed business processes. All identified user roles must be aligned with the organizational change management transition plan. User roles should be derived from the process models and business process design documents.
Inputs
The inputs for user role descriptions include:
Scope as defined in the statement of work Process maps Business scenario requirements Global design principles Business organizational model To-be business process design, as available Organizational change management alignment plan, as applicable
Subdeliverables
User role concept overview User role documents, one per role Consistent user role name and assignment to defined business organization model Type and frequency of user role application access Expected application skills Corresponding SAP default roles Mapping rules for composite roles
Expected Results
Completing the user role concept correctly yields a consistent and standardized view of user roles at the corporate level. The design will be further refined during the realization phase, when a detailed authorization concept is developed.
Logical Data Modeling

Purpose
The purpose of logical data modeling is to create guidelines for modeling and to help the team understand when additional data models need to be created.
Inputs
The inputs for logical data modeling are Project scope statements As-is logical data models Standard data and reference models
Subdeliverables
The deliverable for logical data modeling is a logical data model for master or transactional data relevant to the implementation scope across the application landscape, including both legacy and SAP components.
If It Is Not Done
If logical data modeling is not completed properly, the project may misjudge the impact of the implementation on the existing application landscape, and the implementation may miss major scope items and data relationships or misalign interfaces.
Expected Results
Logical data modeling gives the project an instrument to: Verify implementation scope Implement holistically
Additional modeling information is available within the WBS node Blueprint Approach > Accelerator SAP Process Modeling Handbook, BPX community wiki site, Modeling of Software Independent Business Objects (ERM) and 3.3.2 Orchestrating Software-Independent Process Component Modeling.
See also the business process repository at https://implementationcontent.sap.com/bpr.
Business Solution Design

Purpose
The purpose of business solution design is to provide a process-based solution design that includes business requirements, process descriptions, and a functional and technical solution design. The approach is iterative and driven by the process-hierarchy structure, referencing SAP standards and leveraging agile techniques to create transparency. The design process starts by referencing the defined scope and value drivers. As applicable, the current pain points and key process changes are reviewed and the proposed SAP solution introduced. In order to visualize the proposed solution, it is best to leverage existing SAP environments or applications, such as sandbox environments, IDES systems, preconfigured solutions using best practices, or mock-ups. This technique is called show-and-tell and promotes a mutual understanding of SAP functionality. After the proposed solution has been introduced, the project team starts refining business requirements and maps them to application functionality. Business requirements build the foundation for gap analysis, solution design, and testing. Therefore, requirements need to be unique, traceable, testable, and unambiguous. Process models are derived from the business process repository in SAP Solution Manager (as applicable) and complemented with model-rich information. Process flows not only illustrate a process in a meaningful way but also help associate process parameters such as KPIs, control points, roles, and responsibilities, which are solution design elements. Once the design has been documented, it is verified by the business owners, leveraging mock-ups or sandbox configurations of key design elements.
Inputs
The inputs for solution design are: Solution scope as defined in statement of work Value maps Business process map Scenario requirements documents Business process repository in SAP Solution Manager, as applicable Preconfigured solutions or sandbox environment and mock ups for show-and-tell, as applicable Prioritized and clustered list of as-is weaknesses regarding processes and organizational or IT technical aspects
Deliverables
The deliverables for solution design are: Detailed to-be business process design eliminating weaknesses outlined in as-is process assessment Detail process mapping to. core configuration, core enhancement, SOA/ composition, and thirdparty solution Business process requirements documents Cross-functional requirements SOA requirements Refined business process map Business scenario design Business process design Business process step design Gap analysis and solution enhancement
Expected Results
After completing the business solution design, the project team is able to describe the SAP solution based on business process decomposition. SAP Solution Manager is intended to be the central repository for solution-related documentation.
For details on business process modelin g, see Business Process Modeling (Blueprint Approach) in the SAP Process Modeling Handbook on the BPX community wiki site. See also the business process repository.
Business Process Requirements
Purpose
The purpose of business process requirements is to capture a requirements list, which is a structured way to provide uniqueness and traceability. It enables consolidation, status tracking, and the option of exchanging requirements within the enabling tool landscape. Requirements include: Functions that a process must have Functions that the application must perform Properties that the solution must have Constraints on applications or processes
Requirements should have the following attributes: Uniqueness Traceability Completeness Unambiguousness Conciseness and consistency Correctness Usability, feasibility, and verifiability
Requirement management follows this lifecycle: Requirements elicitation Requirements analysis Requirements representation Requirements change management
Inputs
Gathering requirements is an iterative process, and team members should start by visualizing the potential future solution, following the show-and-tell approach. Based on this understanding, they identify application behavior that is necessary to fulfill the business needs. These requirements can be met through core configuration, SOA/composition, core enhancement, or third-party solutions. The inputs for the business process requirements documents include: Implementation scope as defined in the statement of work Functional and architectural design principles
System visualizations such as show-and-tell and mock-ups Value Pain points Key decision documents Business process maps Business scenario requirements descriptions Business process models
maps
Subdeliverables
The subdeliverable for business process requirements is the business process requirements document. It is best to store all requirements documentation in an implementation project at the process level in SAP Solution Manager. Each process has a list of requirements, and SAP Solution Manager provides the functionality to generate a blueprint based on process structure that contains specified documentation types. A consolidated requirements document can be generated from the blueprint.
Expected Results
Business process requirements documents deliver the foundation for the process and solution design and define criteria for testing.
Additional References
For more on requirements engineering, see requirements section in Ramp Up Training For guidance on using SAP Solution Manager, see the Solution Manager Business Blueprint Operational Guid
Business Process Requirements - Cross Functional

Purpose
Cross-functional requirements describe functionality that is not limited to a single process or functional area. Cross-functional requirements need to be brought to the attention of the entire project team. Integration meetings are mandatory to ensure that requirements across processes are properly recorded and followed up on.
Requirements are:
Functions that a process must have Functions that an application must perform Properties that the application must have Constraint on the solution or a process
Requirements should have the following attributes: Uniqueness Traceability Completeness Unambiguousness Conciseness and consistency Correctness Usability, feasibility, and verifiability
Requirements management follows this lifecycle: Requirements elicitation Requirements analysis Requirements representation Requirements change management
Inputs
The inputs for cross-functional requirements are: Implementation scope as defined in the statement of work Functional and architectural design principles System visualizations such as show-and-tell and mock-ups Value maps Pain points Key decision documents
Business process maps Business scenario requirements descriptions Business process models
Subdeliverables
The deliverables for cross-functional requirements are: Business requirements cross-functional Cross functional integration meetings
It is best to store all requirements documentation in an implementation project at the scenario or process level in SAP Solution Manager. . A consolidated requirements list can be generated through SAP Solution Manager.
If It Is Not Done
If cross-functional requirements are not properly captured, the project may miss integration points and deliverables.
Expected Results
After completing the cross-functional requirements, the project team can create an integrated design that links organizations, processes, and functional teams.
For details on requirements engineering, see the requirements section of Ramp Up Training For additional information on using SAP Solution Manager, see the Solution Manager Business Blueprint Operational Guide
Business Process Map

Purpose
The purpose of the business process map is to derive an agreed-on scope for the start of business blueprinting. The business process map is a deliverable of the project preparation phase. During blueprinting the process map is refined and becomes the foundation for the process hierarchy, a decomposition of the process design reflected in scenarios, processes, and process steps in SAP Solution Manager. The process landscape should be based on the reference process model content, so that the team does not have to develop models from scratch.
Inputs
The inputs for a business process map are: Process scope, as defined in the statement of work The Solution composer tool in SAP Solution Manager, SAP Best Practices packages Customer reference content Interviews with owners of business responsibilities
Subdeliverables
The deliverables for the business process map are: A process map based on the defined high-level process scope High-level process landscape (PL 1- 2)
Expected Results
The process map serves as a framework for process modeling and helps manage process scope. It also serves as an important point of reference for further process modeling and deep-dive sessions.
For details on business process modeling, see the SAP Process Modeling Handbook on the BPX community wiki site. See also the business process repository in SAP Solution Manager.
Business Scenario Desig

Purpose
The purpose of business scenario design is to provide an understanding of the essential processes at the scenario level (PL1-2). It also builds the foundation for the business blueprint phase where process levels 35 are defined. Business scenario design is typically begun during project preparation and must be completed early in blueprinting before process-level design sessions begin.
Inputs
The inputs for business scenario design include: Project scope from the statement of work (SOW) Catalog of as-is business process documents, as appropriate Value realization deliverables for example pain point analysis, value map, identification of key process changes Solution map from SAP Solution Manager, as available Business process repository in SAP Solution Manager Ready-to-run end-to-end process content
Subdeliverables
The subdeliverables for business scenario design are: Business scenario design document, which includes o Business requirements o Level 2 process design (value-added chain diagrams) o Level 2 solution gap analysis o Level 2 functional solution design o Value drivers and financial KPIs o Level 2 organizational impact analysis Revised project scope
Expected Results
Business scenario design should produce a framework for process decomposition during blueprinting and for creation of the process hierarchy in SAP Solution Manager
For details on business process modeling, see the SAP Process Modeling Handbook on the BPX community wiki site.. See also the business process repository.
Business Process Design

Purpose
The purpose of business process design is to detail the to-be business process descriptions on an activity level (PL 3-5) and to describe gaps where the standard solution does not cover all required functionalities. This level of granularity is relevant for: Description of solution gaps (potential RICEFW objects) Description of processes and process steps that affect the user interface Description of processes and process steps potentially relevant to SOA composition, in order to provide information for identifying and specifying services in the solution transformation deliverable
Business process design includes design elements such as organizational changes, IT infrastructure and application landscape, master data management design, and a gaps analysis. From the point of view of value delivery, key value areas of a value map or business case (the so-called benefit objectives) and key process changes should be reflected in business process models:
A benefit objective indicates what has to be accomplished. A benefit objective may be supported by one or more key process changes. The benefit objective is part of the benefit area identified in the business case. A set of proposed process changes called key process changes or value drivers is also included. The key process change represents how to achieve the goal defined by a benefit objective.
Key performance indicators (KPIs) must also be defined to measure and manage process change and value. One or more KPIs or process performance indicators (PPIs) should be identified for each key process change.
Inputs
The inputs for business process design are: Scope as defined in the statement of work Value maps and value drivers Key decision documents Business process maps Business scenario requirements descriptions Organizational structure and design documentation Business process requirements Business process repository in SAP Solution Manager Ready-to-run end-to-end process content Pre-configured solutions for show-and-tell sessions, as applicable
Subdeliverables
The subdeliverable for business process design is the business process and solutions design document (BPD), which contains the following information: Business process overview Business process model Business process steps Key policies, Sarbanes-Oxley- and controls-related information Operational KPIs and PPIs Integration points Functional design considerations
GAP analysis and identification of reports, interfaces, conversions, enhancements, forms, and workflows (the RICEFW elements) Organizational change impact analysis Key decision document, capturing issues resolved during blueprinting User profiles, including roles and requirements (for example relevant to clients and channels) Low-fidelity user interface design and screen flow Activity and entity relationship models Input and output parameters, required business objects, services, and additional information carriers per activity Preconfigurations and mock-ups to support show-and-tell, as scoped
It is best to store business process design documentation in SAP Solution Manager. After the design has been completed, the solution transformation deliverable in the business blueprint can be generated. SAP Solution Manager provides functionality to generate a single blueprint or a consolidation of specific blueprint deliverables.
Expected Results
Business process design delivers the to-be business processes.
For additional information on existing processes, see the business process repository. For more on business process modeling, see the SAP Process Modeling Handbook on the BPX community wiki site.
Solution Transformation and Design

Purpose
The purpose of solution transformation and design is to provide a detailed solution mapping to defined to-be business processes. Each of the four bullet points listed below represents a solution track. For example, core implementation refers to the configuration settings required for the implementation of a major SAP solution like the SAP ERP application, the SAP Customer Relationship Management application (SAP CRM), or the SAP Supply Chain Management application (SAP SCM): Core implementation: describe detailed configuration settings Solution gaps and core enhancements: describe detailed enhancement requirements SOA/Composition: describe detailed service-oriented architecture and composition requirements Third-party solutions: describe available third-party solutions and detailed requirements for them
Inputs
The inputs for solution transformation are: Draft of to-be business process design
SAP standard contents and reference content, for example from the Solution Composer tool or business process requirements documentation Business process list with marked gaps and solution approach Enterprise services bundles and standard enterprise services The SAP EcoHub site
Deliverables
Solution transformation and design produces: Definition and detailed documentation of important customizations to the standard implementation List with detailed descriptions of core enhancements, for example reports, interfaces, conversions, enhancements, forms, and workflows (RICEFW) List with detailed descriptions of enterprise service and composition requirements List of required third-party systems
Expected Results
Completing solution transformation and design gives the project team a detailed description of the solution.
Core Configuration
Purpose
The purpose of core configuration is to list the important configuration objects and settings that were derived during the to-be process definition. The list should include only high-level configuration elements that have a significant influence on the process flow (for example the definition of various document or order types).
Inputs
The inputs for core configuration are: To-be business process description SAP reference content
Subdeliverables
The subdeliverable for core configuration is the definition and documentation of important customizations for standard implementations within the business process design document in the section called Functional Solution and Core Configuration.
Depending on the level of detail in the to-be process definition, configuration elements may be discussed during to-be process definition and mapping to existing SAP solutions or process components. The goal of the discussions is to define and document these important configuration elements for SAP standard implementations and to transfer as much information as possible from the business blueprint phase to the realization phase. Core configuration is relevant only for configuration elements that have a significant influence on the process flow or are necessary to differentiate similar processes (for example, the definition of various document types or order types). The following list of important configuration activities is not intended to replace the configuration specification during the implementation phase: Derive important configuration elements during to-be process definition and SAP solution mapping Use SAP reference content to determine relevant configuration elements within industry best practices and implementation guides in SAP Solution Manager List defined configuration objects and briefly describe each
SOA and Composition

Purpose
The purpose of SOA and composition is to generate all models and specifications required to start the actual development process for the composite application. This involves translating the business requirements into models that can be implemented. The business blueprint phase starts by classifying business processes as use cases or technical processes. A high-level screen-flow model and a user interface mock-up are created for every use case. These models allow for aligning business and IT concerns. The corresponding departments can see how the composite works even before any code is implemented. As soon as these models are accepted by stakeholders, they can be used as a basis for devising more technical models. A technical screen-flow model shows how various screens work together and what kind of service requirements must be met. In addition, a mock-up template describes every user interface element in detail, which enables a steady flow of work during the implementation phase.SOA and composition also consolidates and documents the detailed service requirements, as well as those from composite application design and development. These service requirements must be compared with SAP standard enterprise services to identify gaps and fits, which means differentiating among services that can be reused, services that have to be newly implemented, and services that need to be enhanced
Inputs
See the first chart below for a summary of inputs and deliverables for composite applications and the second chart below for a summary of inputs and deliverables for modeling and design of new services.
Deliverables
Inputs, deliverables, techniques, accelerators, and outputs are defined as follows for composite applications:
Deliverable
Converted process model
Input
Business process model from blueprint (Plan phase)
Techniques and Accelerators

Sample technical process model
Output
Technical pr (BPMN)
Use cases Business requirements from blueprint (Plan phase) Service interfaces Authorization matrix Use case descriptions Portal architecture Requirements specification
Use case de
Domain mod
Consumer model
Technical process model (BPMN)
Screen-flow model template mock-up template
Lifecycle mo Consumer m
UI mock-ups Screen flow
Local provide
Service adaptation and communication
Composition layer architecture Consumer model
Sample of solution communication diagram
Service cand Local provide
Portal integration concept
Solution com diagram
Portal Integr
Internationalization concept
International
Inputs, deliverables, techniques, accelerators, and outputs are defined as follows for modeling and design of new services:
Deliverable
Enterprise service requirements (consolidated)
Input
Business blueprint (service candidates) Service requirements from composite application design and
Techniques and Accelerators

Template for documenting enterprise services requirements
Output
Enterprise services requirements (consolidated)
Identified SAP enterprise services
development Enterprise service requirements (consolidated)
Matching detailed service requirements and standard services (Enterprise service wiki and enterprise service workplace) Template for documenting fits and gaps
Enterprise service - models and design
Enterprise services requirements (consolidated) Classification of services: Fits 100% standard Enterprise services enhancement possible Custom or partner enterprise services needed
Enterprise service design governance Harmonized enterprise service model Component models in ESR Message derivation from BO model
Classification of services: Fits 100% standard Enterprise services enhancement possible Custom or partner enterprise services needed Component models in ESR (according to enterprise service design governance) Service and message structure definition (xls) Service interfaces, operations and messages modeled in ESR
Enhanced enterprise services
Enterprise services requirements (consolidated) Classification of services: Fits 100% standard Enterprise services enhancement possible Custom or partner enterprise services needed
Interface and message definition in ESR Enterprise service enhancement guide
Enhanced enterprise services
Solution Gaps and Core Enhancements
Purpose
The purpose of solution gaps and core enhancements is to identify objects needed to complement standard functionality in order to fulfill business requirements. These objects can be classified as: Reports that have to be designed or adjusted Interfaces that need to be developed Conversions (mostly related to master data) Enhancements that need to be performed Forms for print-out or other purposes Workflows that need to be implemented or designed
RICEFW objects are based on process requirements, and they are specified in business process and solution design documents (BPD). All RICEFW objects are consolidated in the RICEFW list, which serves as a tracker and a tool for rationalization and estimating.
Inputs
The inputs for solution gaps and core enhancements are: Scope documents, such as sstatement of work Key decision documents Business process requirements documents Business process and solution design document
Subdeliverables
The deliverables for solution gaps and core enhancements are: RICEFW list Functional specifications for each RICEFW object
Templates for functional specification may vary depending on the engaged development parties. It is best to associate functional specifications in SAP Solution Manager at the process level or process-step level, as appropriate. Functional specification can be consolidated under a dedicated node in the process hierarchy in SAP Solution Manager.
Expected Results
By completing solution gaps and core enhancements, the projectteam gains a detailed description of gap requirements and necessary enhancements.
For larger development projects, and especially for development of new applications that go beyond the scope of typical RICEFW work, initiating a custom development project (CDP) with involvement of the SAP Custom Development organization should be considered. The Global Delivery group can also be engaged for solution development.
Third-Party Solution
Purpose
The purpose of this work with third-party solutions is to obtain an overview of the technical integration aspects for all necessary third-party systems. System integration may be necessary for existing thirdparty solutions and also for new third-party applications required to cover solution gaps. Based on the solution approach, the to-be architecture is drafted and a list of all relevant third-party systems and corresponding interfaces created. This effort also involves briefly describing all development related to third-party solutions, for example the reports, interfaces, conversions, enhancements, forms, and workflows in the RICEFW list. This development is needed to support the to-be business processes and to cover existing gaps detected during gap identification. The description of necessary enhancements should be kept high-level, it is not meant to replace the technical specification of enhancements.
Inputs
The inputs for third-party solutions are: Solution mapping at business-process and process-step level Gaps identification Overview of solution approach for each business process First draft of architecture overview for the solution SAP reference content (for example, solution maps/Solution Composer)
Subdeliverables:
The subdeliverables are:
List of all relevant third-party systems List of all required interfaces with third-party solutions List and brief description of all required development related to third-party solutions (interfaces, business objects)
If process definition has uncovered a major white spot, like lack of coverage in the SAP applications for some or all of a set of process requirements, integration of a third-party solution may be appropriate. The following questions can help the team reach a decision in this regard: Does the third-party solution cover required functionality? How can the third-party solution be integrated into the to-be IT architecture (in terms of data, logic, user interface, APIs, and so on)? What are the initial and operational costs and estimated effort?
The integration aspects need to be documented, for example with the following kinds of information: Which parts of a process are covered by the third-party application? Which integration interfaces with other systems are necessary and which data has to be transferred? What are the implications for the data model (for example, a change of business object responsibility or extensions of business objects)?
Technical Solution Management

Purpose
The purpose of the Technical Solution Management work stream is to outline essential technical and infrastructure deliverables that are appropriate to an SAP implementation project. In the context of the Business Blueprint phase of the ASAP Implementation Roadmap, the overall objective of Technical Solution Management is to prepare for the Realization phase by completing key technical deliverables that are necessary to meet the needs of other work streams of the project.
Inputs
The inputs required for Technical Solution Management are the deliverables from the Project Preparation phase: Preliminary inventory of external systems that may be required to interface with the SAP solution. Preliminary definition of the target solution landscape and the overall system landscape strategy for supporting the implementation. Preliminary hardware sizing model for the production environment. Definition of tools and standards for providing technical support to the project itself.
The following documents generated from other work streams during Business Blueprint are also useful inputs to this phase: Business process landscape Business process requirements cross functional Solution gap and enhancements identified interfaces SOA and composite application development requirements
Deliverables
The major deliverables of Technical Solution Management in the Business Blueprint phase are: A technical requirements and design specification, mapping business processes in the solution to SAP applications and system instances. Installation and provision of the development environment to the project team. Definition of system administration procedures and processes for ensuring the operation and availability of the development environment to the project team. Definition and documentation of technical support procedures, guidelines, and standards for incident reporting and resolution in the context of the project. Setup of the project Implementation Guide (IMG) in the SAP Solution Manager. Definition of security and user authentication requirements for the target solution.
Integration
Technical Solution Management requires tight integration into other activities and other work streams in blueprinting. The integration with Business Process Management is most crucial for the success of the project. The relationship of these two work streams is bidirectional, because each work stream supports decisions that need to be reflected in the deliverables of the other. For example, business process requirements should be defined against specific assumptions of the software component versions that will be present in the technical landscape, including assumptions about Enhancement Packages, Industry Solutions, or Add-On solutions that will be used, as planning is required to technically install these in a landscape. There is also integration of Technical Solution Management into the Data Management work stream in blueprinting, especially regarding legacy data migration and data archiving. The requirements from data management may include unique hardware and software components, and need to be reflected in the design and setup of the technical system landscape. The proceedings of all work streams therefore need to be planned in parallel, and frequent joint progress reports are highly recommended.
Technical and Integration Design

Purpose
The purpose of technical and integration design phase is to provide a detailed technical and integration design of the solution to be implemented, accounting for all decisions made during the Business Blueprint phase including business process definitions, integration with external systems, and physical server deployment. The technical infrastructure specification deliverable should be created during this phase, and provides a technical description of the entire technology landscape from a physical standpoint, showing where each of the SAP and non-SAP systems are installed, and the physical or virtual servers assigned to each system along with their specifications (CPUs, physical memory, OS version). The transport & change management procedures deliverable should also be created during this phase. This document specifies the procedures and guidelines around all configuration and development activities to be performed throughout the project, the Quality Assurance guidelines for such changes, and policies for moving changes between systems and clients in the landscape.
Several deliverables previously created are updated with current information as part of this deliverable: The technical requirements specification should be updated based on current assumptions about software components required for inclusion in the target solution, including external systems that are being deployed as part of the project. The technical infrastructure capacity plan should be updated based on more accurate sizing models of the production workloadideally, using a transaction-based sizing.
Inputs
The inputs for the technical and integration design are: The definition of the business process model and the solution mapped from it, which is created during business process requirement analysis. SAP Scenario & Process Component List (SCL). The SCL is an online tool in the SAP Service Marketplace that maps business scenarios (sets of related business processes) to the specific SAP software components that are required to realize them. SAP Master Guides. Master Guides are planning documents that provide a comprehensive view of the business scenarios of a specific SAP solution & version, and the realization alternatives for each. Master Guides are available for download in the Installation and Upgrade Documentation repository in the SAP Service Marketplace. The SAP Product Availability Matrix, which shows the supported versions of the SAP kernel, operating system, and database management system for each version of SAP software.
Deliverable
The technical infrastructure specification deliverable should be created during this phase, and provides a technical description of the entire technology landscape from a physical standpoint, showing where each of the SAP and non-SAP systems are installed, and the physical or virtual servers assigned to each system along with their specifications (CPUs, physical memory, OS version).
Several deliverables previously created should be updated with current information as part of this phase: The technical requirements specification should be updated based on current assumptions about software components required for inclusion in the target solution, including external systems that are being deployed as part of the project. The technical infrastructure capacity plan should be updated based on more accurate sizing models of the production workloadideally, using a transaction-based sizing.
Expected results
By completing this deliverable correctly, all members of the project will gain visibility into the detailed technical design of the solution landscape
Development Environment
Purpose
The purpose of the development environment deliverable is to install a viable, correctly configured technical development environment that is available for use by the project team to begin the realization phase. This development environment includes not only the installed development systems, but also the initial technical configuration, such as project team user IDs, installed front ends for the project team, and configured change and transport settings. Note that the ASAP Implementation Roadmap does not yet include a sandbox environment deliverable in the standard roadmap structure. If your project utilizes a sandbox environment, this environment should be included as a separate deliverable, typically provided in advance of the development environment.
Inputs
The inputs for development environment are: Technical requirements specification Technical infrastructure specification SAP Installation Guides Project standards and procedures, including team authorization standards
Deliverable
The deliverables for a viable, properly configured development environment are: Installation of hardware required for the systems in this environment. Installation of SAP software specified for use in this environment, according to the procedures specified in the SAP Installation Guides for the applicable solutions. Installation and activation of optional SAP software components that are required to support the project, such as Extensions, Add-Ons, and components of Enhancement Package. Installation of non-SAP software solutions that are included in the scope of the project. Configuration and testing of the required CTS/CTS+ environment within the development environment, including setup of Change Request Management in Solution Manager if it is to be used. Creation of all user IDs, roles, authorizations, and role assignments necessary to accommodate full functional access to the development system by all members of the project team Setup of the SAP GUI front ends for the project team, locally or on terminal servers. Definition and configuration of output devices for the SAP development environment.
A development environment specification should be created and completed throughout the course of the installation process. The purpose of this document is to capture the specific configuration of this environment, including software components installed and activated, documentation of the clients created in each system and the purpose of each, and any other details that are unique to this environment; a similar specification is to be created for each environment as it is installed and the handoff to the project team is completed.
A separate technical installation procedures document should be created to note additional manual steps during the installation process. This document is not intended to replicate the content of the SAP Installation Guide for the installed solutions; rather, it is a project-specific addendum to those documents to serve as a reference for the technical team. There are many individual steps in the installation process, and properly documenting special steps and noting errors encountered and other hints will ensure that all systems in the landscape are installed in a consistent and repeatable manner, regardless of turnover or changes in responsibility of technical team resources.
Expected results
By completing the deliverable development environment correctly the project will gain a working and functional environment to support Realization activities that has been installed according to previouslyagreed upon specifications
System Administration Procedures
Purpose
The purpose of the system administration procedures deliverable is to begin to detail procedures for periodic system administration and maintenance. These procedures should encompass daily, weekly, monthly, and annual tasks. In addition, the procedures should specify roles and responsibilities for each task. The Business Blueprint phase of a project is generally too early to write the complete technical handbook for administration of the production environment. Instead, in this phase the goal should be to begin defining administrative tasks for supporting the project landscape, and then add to it over time as more experience is gained in the administration of the solution. Eventually, this document will serve as a foundation for defining the production system administration procedures and for the eventual handoff of this role to the IT organization for post-production support.
Inputs
The inputs for the system administration procedures deliverable are: Technical requirements specification Technical infrastructure specification
Transport & change management procedures
In addition, stakeholders and experts within the companys IT organization who focus on infrastructure and administration should be identified and asked for input during the collection of requirements. SAP also provides a series of whitepapers describing recommended best practices in end-to-end solutions operations. The library of these documents, called SAP Standards for Solution Operations, can be found on the SAP Support Portal at the link provided in the accelerators.
Deliverable
The system administration procedures deliverable should address technical team standards in the following topics: Software maintenance procedures, including responsibilities for application of support package stacks, individual support packages, and the specification of regular downtimes for maintenance. System security procedures, including standards for maintaining OS-level passwords and usage of firewalls or other host intrusion prevention systems. Performance optimization procedures, including the setup of regular system monitoring activities and periodic reports of the systems performance against existing service -level agreements. Periodic system maintenance activities, detailing recurring tasks to be performed on daily, weekly, monthly, and annual timetables. Database administration procedures for all databases in the solution landscape. Output device administration, including definition and troubleshooting of spool, fax, and email devices, as well as tool selection and general guidelines for output to print servers or local printers. Batch process management, including tool selection and specification of authorized batch users, servers, and naming conventions.
Expected results
By completing the system administration procedures deliverable, the technical team will begin to understand the required technical skills and internal procedures for ensuring the system landscape is maintained properly and highly performing. Having these procedures fully documented will ensure that administration procedures can remain consistent despite staff turnover or reassignment. In turn, this will minimize the chance that technical issues become an obstacle to overall project timelines and objectives.
Support Strategy and Procedures

Purpose
The purpose of the support strategy and procedures deliverable is to define the overall objectives and requirements for system operations and support. The deliverable defines the future concept for support strategy, which integrates the support of the new solution into the existing support processes and procedures. It is expected that these support standards may not be fully defined at this phase of the project, but will be revised over the course of the project to be completed in time for eventual handoff to the post-production support organization. This deliverable differs from the system administration procedures deliverable in that it is intended to document the overall support strategy, of which technical operations are only one component.
Inputs
The inputs for the support strategy and procedures deliverable are: Technical requirements specification Transport & change management procedures Existing support standards in the customers IT organization
In addition, stakeholders and experts within the companys IT organization who focus on s olution support should be identified and asked for input during the collection of requirements. From business process requirements in blueprinting, the following documents are needed: Solution scope document Business process design Cross-functionality process requirements Gap requirements and resolution concept
SAP provides a separate roadmap for implementing end-to-end solution operations procedures, called Run SAP. This methodology is part of SAP Application Lifecycle Management (ALM), and is available through the same channels as other ASAP methodologies. SAP also provides a series of whitepapers describing best practices in SAP support. The library of these documents, called SAP Standards for Solution Operations, can be found on the SAP Support Portal at the link provided in the accelerators.
Deliverable
The support strategy and procedures deliverable should address project standards in the following topics Incident management and exception handling, describing the process for reporting, investigating, and resolving exceptions and error situations. Change request management, including initiation, approval, and execution, and quality control of technical and functional changes to business processes. Software maintenance standards, including procedures for request and approval of release upgrades, support packages, or other recurring maintenance activities. End user security standards, including password support and procedures for requesting new/changed authorizations in the SAP system.
Expected results
By completing the support strategy and procedures deliverable, the project can ensure full operation and availability of the solution after go-live.
Project Implementation Guide

Purpose
The purpose of this deliverable is to have a project implementation management guide (IMG) generated either manually or automatically through SAP Solution Manager. The IMG is the location in the SAP application landscape where the business process team members and consultants perform actual customizing activities. The project IMG enables you to plan and organize the necessary customizing activities within your SAP software implementation project. There are two ways to create a project IMG: Manually Using SAP Solution Manage
Manual Creation A short meeting should be held with experienced consultants and customer IT representatives to define the following: Customizing scope Level of usage of the planning tools Level of usage of status reporting Level of usage of resource assignment functionality Level of usage of notes (global or local)
For manual creation, the more-common method, the person responsible (usually the project manager) manually identifies the components of the IMG that must be configured according to the project scope and clicks on the generate button.
Automatic Creation Using SAP Solution Manager SAP Solution Manager lets you automatically set up project IMGs for all applications in an implementation of SAP Business Suite software. Verify after generation that all the necessary components were selected.
Inputs
The inputs for the project IMG are: Technical and integration design document System administration procedures Development environment Business blueprint
Deliverables
The deliverables are: Project IMG naming conventions and standards Generated project IMG
If It Is Not Done
Without a project IMG, documentation of the customizing activities in the system is not possible. Clear documentation of changes to customizing activities is not possible either, which can cause legal issues in some countries. The configuration of the SAP solution cannot commence without a project IMG.
Project size and the extent of the customers current project planning and control framework may affect requirements for the project IMG. It is also important to consider which objects (such as documentation) are to be transported with customizing settings. There may be requirements for additional project IMGs during the lifetime of the project. For synchronized transportation and protection of customizing content among development, QA, and production systems or between template and rollout landscapes, consider using business configuration (BC) sets.. BC sets are like snapshots of customizing settings, capturing copies of the settings with no reference to original customizing content. Both client-dependent and clientindependent customizing can be captured in BC sets. There are four ways to create a BC set: Through the IMG hierarchy By combining existing BC sets into so-called hierarchical BC sets Automatically during customizing Through a transport request
Authorization Requirements and Design

Purpose
The purpose of authorization requirements and design deliverable is to: Describe the authorization requirements at the level of business scenario and process Evaluate the authorization and security concept against SAP standards Identify additional security measures that need to be implemented Choose a security method or a combination of several methods appropriate for the implementation
Inputs
The inputs for authorization requirements and design are: Business process map (preparation phase) Scenario design documentation Business process documentation (blueprint phase) User role concept (business view) User role Document (Blueprint phase)
Deliverables
The major output of authorization requirements and design is a detailed plan for the setup of previously identified and selected security measures. This plan contains a description of concrete methods, products, services, or solutions needed to successfully support the security standard. This serves as the foundation for setting up the implementation methodology.
If It Is Not Done
If authorization requirements and design is not completed correctly, the project may not properly manage future access to production scenarios and processes based on corporate security standards.
Expected Results
By completing authorization requirements and design correctly, the project gains an instrument to list security design elements and relate them to authorization requirements and fixed security methods. Then team members can build implementation solutions with a solid grounding in corporate security standards.
Please see also the security section in the SAP Technical Operatio
SOA/Composition Development Environment

Purpose
The purpose of this work on the SOA/composition development environment is to specify tools to meet the requirements from solution transformation and design. Team members evaluate various serviceoriented architecture (SOA) tools and finalize the specific tools and technologies to be implemented for the solution. This is especially important when there are multiple tool choices for a specific technology, and when it is not immediately clear which tool is best suited to the solution.
Inputs
The input for tool selection is the architecture of the SOA/composition solution described in the business blueprint/.
Deliverables
The deliverable is a description of the SOA technology platform, indicating the choice of tools and technologies selected. The description should also specify the reasoning behind the selection of the tools for the various layers. The various tools required to successfully realize an SOA solution can be grouped into layers as shown in the diagram below:
At the very top is the process layer, where the reusable services and user interface are orchestrated into executable processes. Workflow engines based on business process modeling and notation (BPMN) are typically used to model these processes. The next two layers below the process layer, the views layer and the services layer, are the layers in which reusable user interfaces and services are developed for consumption by the processes in the process layer. Various user-interface modeling and service implementation options are available to implement these reusable artifacts. The service bus integrates components that are not service-enabled with the service-enabled components. It also provides mediation, routing, and monitoring for services. The service modeling tool (represented in the diagram by the enterprise services repository <ESR>) is an infrastructure tool typically used to model and store all service definitions and realize a centralized SOA governance model Other infrastructure tools that play a role in the SOA-based solution but are not depicted in the diagram include: A portal to host the composite applications A development Infrastructure for services and composite applications A centralized directory for solution landscapes, systems, and software components.
More details about the technology components offered by SAP are provided in the Landscape Development and Operations section of this roadmap. In general, the choice of a specific technology component depends on the following criteria:
The feature requirements of the composite application as detailed in the BPM blueprint The skill sets of the developers involved in the solution implementation The tools already in place in the landscape
The choice of tools at the process, views, and services levels may change with each SOA project, since it is heavily dependent on the solution architecture, whereas the decision on infrastructure tools may be made once at the enterprise level for all SOA projects. The accelerators described below help the team evaluate technology components for the SOA solution:
Accelerator
Service implementation options
Description
Services are modeled in a language-independent way using the ESR. Global data type delivered by SAP can be reused when the services are modeled in ESR, thereby enab of the service definitions. The modeled services can be implemented in any service imp platform and in any implementation language.
The attached document explores a number of ways to implement enterprise services a situations in which a particular implementation option makes sense. The options can al many ways. For example, certain key services may be implemented in ABAP in the ba system and auxiliary services in Java.
During the project setup phase, these implementation options need to be discussed an as to which services are to be implemented using which service implementation techno Composite application development tools
SAP offers multiple technologies like the Web Dynpro development environment and th Visual Composer tool for creating user interfaces for composite applications. For mode one may use either guided procedures or the SAP NetWeaver Business Process Mana component (SAP BPM). In addition there are non-SAP tools like Microsoft.NET that ca composite applications that consume the enterprise services.
The attached Microsoft Excel spreadsheet helps evaluate some of the composite appli development tools mentioned above. The sheet may be customized once to include or relevant for the customer. During the setup of the SOA project, the spreadsheet can be tools.. Choosing between Visual Composer and Web Dynpro
The attached document provides guidance as to when and how to use SAP NetWeave and Web Dynpro Java. It shows the relationship between the two UI modeling tools tha with the SAP NetWeaver Composition Environment (SAP NetWeaver CE) offering in th medium term. Beyond choosing Web Dynpro as the UI modeling technology, to the team also needs Web Dynpro ABAP (WDA) or Web Dynpro (WDJ) is best suited to the SOA solution.
Choosing between Web Dynpro ABAP or Web Dynpro Java
The attached document explores the similarities and differences between Web Dynpro Dynpro for the ABAP programming languages, as well as providing guidance to help yo tool.
Development Landscape Concept

Purpose
The purpose of the development landscape concept is to explain how an SOA-based solution introduces new infrastructure tools like an enterprise services repository (ESR), a service registry, a process integration service bus, a composition environment, and so on, to a development landscape that may already contain other development infrastructure tools like SAP Solution Manager or the system landscape directory and development infrastructure in the SAP NetWeaver technology platform. The appropriate landscapes for these new tools need to be planned well in advance of solution implementation, because procurement, installation, and configuration of these systems may significantly affect the overall timeline for the project.
Inputs
The following chart summarizes inputs to the development landscape concept:
Source of Input
Plan phase Architecture from the project setup phase System design and operations in project setup Development team information
Input
Conceptual solution architecture in the business blueprint Technology platform Assessment of the current development landscape Development team member skills and preferences
Subdeliverables
The development landscape concept identifies the software tools and systems needed for the development of the solution. Further, it specifies the roles of developers in terms of the tools and systems to be accessed. It serves as an input to the planning of the physical development landscape that is eventually carried out by the system development team. A development landscape comprises the systems and tools the development team needs and is influenced by a variety of factors, including the following:
Technology choice Sharing of the existing systems with other project teams Development mode (remote or on site)
A development landscape can be described using a unified modeling language (UML) deployment diagram, including the following elements: Systems, with their types (WebAS for the ABAP programming language, WebAS Java, and so on) Products deployed on the systems (the SAP NetWeaver Process Integration (SAP NetWeaver PI) technology, the SAP NetWeaver Composition Environment (SAP NetWeaver CE) offering, the SAP NetWeaver Portal component, and so on) Developer groups as stakeholders on various levels and workstation types with the corresponding client tools Identity management tools Testing tools
The creation of this diagram is usually a joint effort of the architect and the development lead. . A sample development environment in the form of a UML diagram is shown below, indicating the set of application servers and other components needed in a sample SOA development landscape:
A Microsoft Visio version of the above diagram is also attached as an accelerator for this deliverable. In addition to this type of deployment diagram, a typical development landscape concept should address the following topics: Appropriate landscape options for the various tools, including service registries (SRs) and enterprise services repositories (ESRs) Transport mechanisms and the corresponding routes for transporting SOA artifacts in a multisystem landscape Trade-offs between a central WebAS server for testing and debugging and a local WebAS installation on the developer's desktop Access privileges and restrictions needed in the various systems for the development team
An example of a system landscape diagram is provided below, indicating how the various servers are organized in a typical three-system landscape:
Multiple diagrams can be used to cover these topics in the development landscape. The information can be combined in a single diagram if the landscape is sufficiently simple.
The accelerators described below and provided with this deliverable are intended to help the team design a suitable development landscape concept for the SOA solution.
Accelerator
ESR and service registry landscapes
Description
The ESR and the service registry are key components in developing an SOA-based solution. ESR is available in both SAP NetWeaver CE and SAP NetWeaver PI. It is important to decide early on, during the project setup phase, which of those two the development group is to use. In addition, it is also important to decide whether a threesystem landscape (separate development, quality assurance, and production systems) necessary for these components.
The attached presentation describes the various options, including SAP recommendati for ESR and service registry landscapes. SLD planning guide
The system landscape directory (SLD) plays a crucial role during both design and runti Many development systems, including SAP NetWeaver PI and the SAP NetWeaver Developer Studio (NWDS) tool, connect to the SLD during design time to access the lis software components (SCs) and to register the names of development components (D software packages, and database tables The attached SLD planning guide covers the various options and recommended best practices for planning the SLD development landscape.
Unified transports through CTS+
In an SOA development landscape, it is important to ensure combined and consistent transports of heterogeneous entities across the entire landscape.
For example, if a composite application was developed in the development system and consumes a service that has been newly implemented in the back-end ERP developm system, both the composite and the service implementation are to be transported into t quality assurance (QA) system. If the composite application alone is transported, it will be possible to test the application against the QA back-end system, since that system missing the new service end-points..
Here, the new change and transport system (CTS+) plays a crucial role in combining b ABAP and non-ABAP transports throughout the landscape.
The attached how-to guide provides valuable guidelines on how to configure the transp routes in a heterogeneous development landscape.
Solution Deployment Concept
Purpose
Once a composite application is developed, it must be deployed in the production landscape. Employees within the enterprise intranet and partners and customers outside the firewall may all need to access the application. The application may consume Web services developed in-house and located within the intranet, as well as services provided by a third party located outside the intranet. The application must therefore be deployed in an appropriate security zone to that enables the necessary access and simultaneously secures enterprise service-oriented architecture (SOA) and non-SOA assets. It is best to create a deployment concept for the SOA solution at an early stage in project setup, so that relevant physical system design and implementation, for example the setting up of firewalls and opening of ports, can be carried out in the solution design and implementation phases.
Inputs
The inputs for the solution deployment concept include: Solution architecture from the business blueprint Technology platform Development landscape concept
Subdeliverables
The subdeliverable is a logical solution deployment diagram, indicating the security zones where the composite applications created as part of the SOA solution need to be deployed, the communication paths among the composite applications, and the various back-end applications and middleware components that are also part of the SOA solution. The business process management blueprint provides details on the various internal and external roles that are granted access to the composite application. Based on those needs, the team identifies the appropriate security zone in which the composite application can be deployed. If the development infrastructure in the SAP NetWeaver technology platform is used as the infrastructure for composite application development, the application developers need access to it during development. However, the development infrastructure may need access to the server on which the composite application runs, so that it can automatically deploy the composite applications. If the composite
application server and the development infrastructure are on different SSNs, appropriate ports must be opened for the automatic deployments to work. Based on the above requirements and the information on security zones, proxy servers, and identity management tools in the network landscape, a solution deployment diagram can be created indicating the distribution of components among systems and of systems among security zones.
Integrated Solution Management
The purpose of the integrated solution management work stream is to outline essential solution testing deliverables, processes, and procedures appropriate to the implementation project. This work stream organizes testing of individual processes, process steps, and scenarios and helps prepare for the move to a productive SAP solution.
Inputs
The inputs required for integrated solution management are: Project scope Project schedule Business requirements Functional requirements Test assessment and related materials completed in the project preparation phase
Deliverables
The major deliverables of integrated solution management are: Functional test plan Performance pest plan Test strategy and approach
Testing Strategy and Approach

Purpose
The purpose of this deliverable is to outline key elements of the testing methodology that the project will use as guiding principles going forward. This is a point-in-time view of testing and will not be updated over time.
Inputs
The inputs for the test strategy and approach document are: Test assessment completed in the project reparation phase Existing functionality for the following: Types of testing (unit test, assembly test, integration test, regression test, security test, and performance test) Methods of testing - manual and automated Testing toolset
Requirements traceability Test case development Test data Test execution Test resources Defect management Test coordination Test reporting and analysis Test metrics Change control process
Deliverables
The deliverable for testing strategy and approach includes: Project testing objectives and requirements Assumptions Test scope Types of testing Test phases (e.g. development test to end-to-end integration test) Test approach Test planning and management Test case creation and selection Risk analysis
Test deliverables Test tools Test automation Defect management Integration with change control Roles and responsibilities
Expected Results
Completion of the test strategy and approach deliverable provides a detailed strategy guide which will drive completion of a comprehensive test plan for the project. The test plan is a crucial artifact that provides a detailed guide for testing the entire SAP solution in order to meet the test objectives.
Test Planning
Purpose
The test plan is a central document detailing all aspects of testing for a particular project.
Inputs
The inputs for the test plan document are: Test assessment completed in the project preparation phase Test strategy and approach document from earlier in the blueprint phase Existing functionality for the following: Types of testing (unit test, assembly test, integration test, regression test, security test, and performance test) Methods of testing - manual and automated
Testing toolset Requirements traceability Test case development Test data Test execution Test resources Defect management Test coordination Test reporting and analysis Test metrics Change control process
Deliverables
The test plan deliverable includes: Project testing Objectives and requirements Assumptions Test scope Types of testing (performance, technical, functional, and so on) Test approach Resource schedule Test tools Defect management Roles and responsibilities
Expected Results
Completion of the Test Plan deliverable provides a detailed guide for testing the entire SAP solution in order to meet the test objectives.

Hai

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Hai

Caricato da

Copyright:

Formati disponibili

Business Process Management

Solution Manager and Business Process Management

Define the tracking tool to ensure value attainment post go live

Business Objects Modeling

Business Organizational Structure

Customer-group Distribution-channel Purchasing-channel

General Settings and Master Data

User Role Concept

Logical Data Modeling

See also the business process repository at https://implementationcontent.sap.com/bpr.

Business Solution Design

Business Process Requirements

Business Process Requirements - Cross Functional

Business Process Map

Business Scenario Desig

Business Process Design

Solution Transformation and Design

SOA and Composition

Techniques and Accelerators

Technical process model (BPMN)

Screen-flow model template mock-up template

UI mock-ups Screen flow

Service adaptation and communication

Composition layer architecture Consumer model

Sample of solution communication diagram

Service cand Local provide

Portal integration concept

Solution com diagram

Techniques and Accelerators

Identified SAP enterprise services

development Enterprise service requirements (consolidated)

Enterprise service - models and design

Enhanced enterprise services

Interface and message definition in ESR Enterprise service enhancement guide

Enhanced enterprise services

Solution Gaps and Core Enhancements

Technical Solution Management

Technical and Integration Design

System Administration Procedures

Transport & change management procedures

Support Strategy and Procedures

Project Implementation Guide

Authorization Requirements and Design

SOA/Composition Development Environment

Choosing between Web Dynpro ABAP or Web Dynpro Java

Development Landscape Concept

Unified transports through CTS+

Solution Deployment Concept

Integrated Solution Management

Testing Strategy and Approach

Potrebbero piacerti anche