Hello friends if you are looking for SAP Business Blueprint Note | SAP Business Blueprint for Beginner | SAP Business Blueprint Step by step process for beginner | SAP Business Blueprint system organization structure | SAP Business Blueprint Organizational Unit | SAP Business Blueprint Master Data related Content then you will get related details here.
The SAP Business Blueprint is a crucial phase in the implementation of SAP software within an organization. It’s essentially a detailed documentation of the business processes and requirements gathered during the project’s initiation and planning stages.
What is an SAP Business Blueprint?
The SAP Business Blueprint phase includes a number of activities, events, milestones and deliverables as described in ASAP (Accelerated SAP) Roadmaps and generally classified as having overall project management significance. The Business Blueprint is the output (or product) of the project design tasks as they are managed in the appropriate tools – the SAP Solution Manager and the ARIS Business Architect for SAP NetWeaver – and the subsequent enterprise design processes. The tools support an architecture driven implementation through a tight integration of the solution (SAP) and the enterprise solution architecture (ARIS).
An SAP Business Blueprint is derived through an iterative process of defining the business process
and technical requirements for a specified project using the SAP Solution Manager and ARIS Business Architect for SAP NetWeaver. The Business Blueprint also refers to the contents on the solution and business process architecture repository. The phase begins after Project Preparation on the SAP implementation lifecycle and ends prior to the Realization (configuration) phase. So, it is important to note that nothing is built during the Business Blueprint phase. The plan (i.e., the completed Business Blueprint) describes a completely configured SAP solution, including all interface and security requirements. During the Realization phase, the customer and the implementation consultants, working together, “realize” the plan that is defined by the completed Business Blueprint.
The SAP Solution Manager is critical for creating a Business Blueprint. Three key elements are
required in order to create a project on the Solution Manager. Those are an Organization Unit, Master Data, and Business Scenarios. These three elements defined during the blueprinting phase set the foundation for accurately aligning the SAP ERP to enterprise business processes.
A high-level SAP Business Blueprint development process includes:
- Creating a project in the SAP Solution Manager;
- Selecting cross-functional business processes from predefined business scenarios in the Solution Manager;
- Synchronizing the SAP Solution Manager project content to the solution architecture as described in the ARIS Business Architect for SAP NetWeaver;
- Further developing the business processes using the ARIS Business Architect for SAP NetWeaver; and Synchronizing solution architecture content in the ARIS business process repository to the SAP Solution Manager content.
The Solution Manager manages both the SAP part of the solution as well as those business processes that are not enabled by the SAP software. This step is less critical if the organization enables all of its business processes in the SAP product suite, but that is seldom (if ever) the case.
An SAP Business Blueprint process can be applied based on the guidelines provided by SAP;
however, this paper discusses the development of business blueprint from a practical SAP
implementation project perspective. In reality, there are a number of activities that have to be
accomplished to ensure that the business blueprint on the solution side and the architecture side are in compliant with applicable rules and regulations. This is because most organizations must be compliant with some larger regulatory environment, whether it be Sarbanes-Oxley or one of the many public sector compliance requirements. Thus, the somewhat simplified SAP guidelines fall short of addressing the compliance requirements in detail.
For example, SAP recommends picking suitable business scenarios using the SAP Solution Composer and using that as a starting point to pick from a list of predefined scenarios from the Business Process Repository (BPR) inside the SAP Solution Manager. The predefined business processes from BPR ST- ICO1501 serves as the “to-be” business processes to be realized in the SAP solution. Thus existing processes are forced to fit (align) to the predefined business processes. This approach is known to work in some organizations, but in large and complex organization (e.g., the U.S. Department of Defense), these “to-be” processes are problematic. There must be a better assurance that these “to-be” processes can “fit” within the “as-is” scenarios (in customer terms) that are bound by those systems that are not replaced by the SAP solution. This alignment requires considerable additional modeling and analysis outside of the Solution Manager. Further alignment of the end-to-end business processes to the SAP solution’s predefined business processes is required to develop a new “to-be” as well as a
“transition” architecture that “fits” organizational requirements.
In some organizations, architecture development starts at an early stage without tight integration
with a live-solution. A particular solution architecture may contain proprietary concepts, standards, structures, and semantics that can be described using any acceptable architecture
framework. Thus the “as-is,” which may also serve as the compliance architecture, matures faster. Then as the SAP implementation begins, a new “as-is” (a redocumentation) is captured during the SAP Level 1 and 2 blueprinting workshops. This makes it even more cumbersome to maintain a repository that captures a matured “as-is” architecture in addition to the new workshop “as-is” models, the predefined solution architecture, and the “to-be” architectures.
The drawback of being compliant is “time.” Concurrent development of the “to-be” architecture from a combination of the “as-is” and the solution architecture could be time consuming, because such a multi-purpose architecture may also incorporate the different “flavors” of the business processes in a single architecture repository as well. However, this process must be completed, because the SAP solution must be completely aligned with the non- SAP business processes in a complex organization with many systems enabling the landscape. We reiterate because this point is critical. If the SAP software enables only a portion of an organization, the Business Blueprint must define how the “to-be” SAP processes in the Solution Manager align with the “as-is” business processes that fall outside of the SAP solution. Otherwise, the organization cannot
efficiently execute the cross-functional business processes that flow across SAP and non-SAP solution components.
Going back to the content of an SAP blueprint, the details of an SAP Business Blueprint are discussed in the subsequent sections including the delineation of the system organization structure (i.e., the system organization model), the definition of organization units, the determination of master data, and the selection of business scenarios.
System Organization Component of The Business Blueprint
Organization in SAP implies to two distinct sets of expressions one referring to a system configuration structure while the other refers to organizational units. In SAP, a system configuration structure is the way of defining the financial and logistics operational structures while configuring the solution. It is defined in terms of company code for financials, plant for logistics and sales area for sales and distributions. System configuration structures are derived from the reporting hierarchy and roles of a unit in terms of production, procurement, maintenance and material planning, selling and purchasing power. Selecting a suitable SAP organization structure is an intricate analysis process.
On the other hand, an organizational unit in SAP implies to the organizational roles of units in terms of responsibilities for the associated costs. A traditional organization unit structure usually reflects a hierarchy and authority rather than financial obligations. Hence, org unit in SAP is derived from the perspective of creating a cost controlling area. Both system organization structure and organization unit will be elaborated in the next section.
System Organization Structure
An organizational model defines an enterprise. The structure defines, at a minimum, information flows and financial roll-ups for reporting and control. In order to “set-up” the SAP software the organization must ensure that its organizational structure aligns with the structure that is enabled by the SAP software solution. The system organization model reflects the degree of centralization across an enterprise. For instance, an enterprise with one company code, controlling area and funds management area demonstrates a highly centralized enterprise. Decentralization for such enterprise begins at the profit, cost, and business center levels. The system organization structure in SAP is instructive of SAP’s enterprise focus.
If the SAP solution is fragmented, it may be impossible to truly align the software with enterprise
information flows and reporting structure, forcing an artificial Business-to-Business (B2B) e-Commerce solution inside of the enterprise. To complete the logic, an enterprise with multiple
company codes mimics a highly decentralized enterprise even though each entity may have to a
certain degree identical controlling and funds management area.
Similarly, for logistics, organizational structure configuration is accomplished through the purchasing power of plants. The purchasing organization unit divides an enterprise according to the requirements of purchasing. Unlike the financial system organizational structure, the logistics system organizational structure determines the degree of cross-organizational business process harmonization for activities such as inter-plant planning and transfers. As an example, a purchasing organization may have one or more plants that are further sub- organized to multiple storage locations containing warehouses. Such structure simplifies business processes to a greater extent among the plants. Conversely, multiple purchasing orgs having individual plants increase the complexity of business process procedures among the plants.
Sales area ties both the products/services offered within an enterprise with the corresponding financial transactions. Sales area consists of a sales org, distribution channel and division. A sales org is assigned to one company code as well as one plant when defining an enterprise on SAP. However, multiple sales orgs may be assigned to a plant. Distribution channel(s) (product/service outlet vehicle) and division(s) (product/service sellers) are designated to one or more sales orgs. The assignment of a sales org to a plant provides visibility to the activities within a plant including warehouse inventories and services. One organizational entity that is not tied to any of the org structures discussed above but has important relationship with sales and distribution is a shipping point. Shipping points simply stated schedule and process shipments. As discussed previously, defining a system organization structure has a greater operational implication on an enterprise unless outlined diligently. This is because once configured it’s hard to go back and undo the company structure unless the system is re-installed.
Organizational Unit
An organizational unit in SAP takes a slightly different approach than the traditional functional job
classification used by most organizations. An organization unit could be a plant, cost center,
distribution channel, project team, group, etc. with a responsibility over cost. SAP maintains each
organization unit’s information such as account assignment, cost distribution, address, work schedule, and quota planning based on functional requirement, allocation criteria, physical location, and responsibility for cost. Examples of organizational unit are sales area, receiving point, shipping point, storage bin and loading point.
How is the organization structure on the HR side linked to organization units defined per cost centers? SAP’s Enterprise Organization supports such relationship by providing a means of assigning cost and profit centers to traditional organization structures. Thus, it provides a comprehensive view of the enterprise by roles and responsibilities, costs and revenues. The key here again is the word “enterprise.” The SAP software is designed to enable an enterprise, and highly fragmented solutions can make organizational model alignment problematic.
Ultimately, each user is then given a role and assigned to an organizational unit, and this must be
defined and documented in the Business Blueprint. SAP’s scheme for assigning roles and
authorizations applies a three-tiered approach for granting access to transactions and task delegation. The ASAP Implementation guide strongly recommends that the three-tier approach be followed and if possible, only Tier 3 authorization be given to users. This reduces the complexity of assigning user roles and authorization. Still, the assignment of roles and authorization is a complex process, and SAP does not provide adequate tools to enable this process. We use the ARIS Process Platform to manage the roles and authorizations, since it provides a methodology for maintaining tight configuration management control over those assignments.
MASTER DATA COMPONENT OF THE BUSINESS BLUEPRINT
Master data are key variables that are relatively constant; e.g., customers, vendors, materials,
equipment, etc. These data may change, but they change infrequently. The SAP solution requires high quality master data, and since the solution is enabled by a consolidated production database, there is a low tolerance for data gaps. Therefore, significant pre-analysis required for any SAP project is a master data readiness study. Master data could be business partner record, product condition, master record, material information, material classification, chart of account, cost center, fund center, customer material information, etc. Master data could also be defined at a project and/or under a business process scenario level depending on the requirement.
For a given business process scope, specific master data are required. These data are identified,
inventoried, and targeted for data conversion on the Business Blueprint.
Data conversion requires that all required master data be migrated from legacy sources and loaded into the SAP production database. This can be efficiently accomplished using Extract, Transform, and Load methods and tools, but this approach cannot alleviate problems of improperly identified (i.e., sourced) or missing data on the system side. A properly sourced and identified data should be linked directly to the enterprise architecture as the data is the information that fuels the enterprise.
WHAT IS THE CONTENT OF AN SAP BUSINESS BLUEPRINT ON THE ARCHITECTURE AND SOLUTION SIDE?
The content of an SAP Business Blueprint on the solution side is thus the details of an organization design including the details of the business scenarios, organization units, and master data with the supporting documentations. On the architecture side, resides the detail of the business scenarios including business process, process steps, and transactions.
Upon launching of the SAP solution users are able to execute a transaction from the architecture side on ARIS to SAP. Such tight integration of the architecture and the solution facilitates transition to the new “to-be” business processes as well as user training and acceptance.
For documentation purposes, critical Business Blueprint information can be store in the Solution
Manager and graphically displayed in the enterprise architecture repository as well. The business
process information can be displayed using the Extended Event-Driven Process Chain (eEPC) model type in ARIS. The process (represented via SAP function object) on an eEPC may be assigned directly to a process step using the Function Allocation Diagram (FAD) model type. This model also portrays the details of organizational units, master data entities, and transactions. The architecture view of the SAP Business Blueprint is depicted in Figure 3. Note that in Figure 3 that other relevant objects could be displayed using the FAD, including interfaces, Key Performance Indicators (KPIs), or any additional information that are relevant for planning purposes. The ARIS business blueprint products can then be used to further analyze and optimize the enterprise business processes, support enterprise- wide governance, manage process performance and develop service-oriented architectures.