evolution of sap implementation environments white paper

8/12/2019 Evolution of SAP Implementation Environments White Paper

http://slidepdf.com/reader/full/evolution-of-sap-implementation-environments-white-paper 1/21

ENTERPRISE NTEGRATION, INC. / IDS SCHEERTheEvolution of SAP Implementation Environments: FromValueSAP to Solution Manager

The Evolution of SAP Implementation Environments:

From Value SAP to Solution Manager

WhitePaper



T H E E V O L U T I O N O F S A P I M P L E M E N T A T I O N E N V I R O N M E N T S :

F R O M V A L U E S A P T O S O L U T I O N M A N A G E R

1

T h e E vo l u t i o n o f S A PI m p l e m e n t a t i o n E n v i r o n m e n t s :

F r o m Va l u e S A P t o S o l u t i o n M a n a g e r

© 2004 Enterprise Integration, Inc.5971 Kingstowne Village Parkway • Suite 110

Phone 703.236.0800 • Fax 703.236.0801www.EiiSolutions.net • [email protected]





2





3

Table of Contents

Table of Contents ................................................................................................................................... 3 Abst rac t ......... ........... ........... .......... ........... .......... ........... ........... .......... ........... .......... ............... .......... ....... 4 1.0 Implementation Methodologies ...................................................................................................... 5 2.0 Value SAP ......................................................................................................................................... 5

2.1 Accelerated SAP ........................................................................................................................... 5 2.2 Problems w ith ASAP .................................................................................................................... 7

2.2.1 Discon nect Between the Business Process MasterList (BPML) and the Implement ation Management Guide (IMG)................................................. 7 2.2.2 Downloadable Scr ip ts ............................................................................................................ 8 2.2.3 Confl ic ted Requirements Defini tion ..................................................................................... 8 2.2.4 The Magic Link ....................................................................................................................... 9

3.0 Solut ion Manager ............................................................................................................................. 9 3.1 More Tool than Methodology..................................................................................................... 11 3.2 Tools vs. Meth odology ............................................................................................................... 12 3.3 ARIS for Solut ion Manager ........................................................................................................ 13 3.4 Project Information vs . Enterp ris e Information ....................................................................... 15

4.0 Example: Solut ion Manager Alternatives for the U.S. Arm y ...................................................... 16 4.1 The Single Project Configuration .............................................................................................. 17 4.2 Multiple Project Configuration .................................................................................................. 18

5.0 Conclus ions .................................................................................................................................... 19

6.0 References ...................................................................................................................................... 20





4

Abstracthis paper describes the evolution of SAP implementation methodologies and tools. In particular, it

describes ValueSAP, with a focus on the Accelerated SAP (ASAP) implementation methodology andits evolution into a part of SAP’s new Solution Manager tool. The paper discusses some problemsassociated with the ASAP methodology and also describes how some of these problems are addressed

with Solution Manager. The paper also describes how Solution Manager can be improved by combining itwith the ARIS for MySAP methodology and associated toolset. This enhanced capability is a result of ARISdriving the Solution Manager scope from a business requirements perspective as opposed to an SAP productperspective. Finally, as an example, we show how Solution Manager and ARIS for MySAP should beimplemented in the U.S. Army to manage across three complex SAP projects.





5

1.0 Implementation Methodologies

mplementation methodologies provide detailed instructions, templates, and accelerators to guide thecustomer when implementing standard software solutions. The SAP implementation methodology isthe equivalent to the manufacturer’s instructions that would come with a mechanical or electronicproduct. If the instructions are studied and followed, then one is more like to achieve a successful

implementation than if one does not follow the implementation methodology. In other words, animplementation methodology is neither necessary nor sufficient for project success, but the trade andacademic literature supports the assertion that one is more likely to succeed while following a methodologythan not.

2.0 Value SAP

SAP's overall Lifecycle approach is called Value SAP. Within Value SAP there are three primary phases:• Discovery & Evaluation (Methodology used is Customer Solution Strategy)• Implementation (Methodology used is ASAP or Global ASAP)• Operations & Continuous Improvement (Methodology used is CBI)

These phases repeat in a continuous circular fashion as the implementing organization proceeds with itsinstallation of SAP. This paper focuses mainly on the implementation phase

2.1 Accelerated SAPSince 1997, SAP’s recommended implementation methodology for a single well defined enterprise has beenAccelerated SAP (ASAP). The methodology was designed to address issues of excessive implementation cycletimes and cost overruns, primarily in the U.S. market. In general, ASAP is one of a class of implementationmethodologies called Rapid Implementation Methodologies , and their overall success is still disputed [see, forexample, Ferguson and McCright (2001)]. ASAP is a phased methodology that has similarities to thesoftware development lifecycle model that software engineers typically follow.

ASAP consists of:

• The Roadmap is a project plan with detailed descriptions about what, why, and how certainactivities are performed. It describes all activities in an implementation, making sure that

nothing is omitted. This allows managers to plan for implementation, using the experience ofmany completed R/ 3 implementations. The Roadmap addresses things like interfaces, dataconversions, authorizations, etc. It even includes very detailed items, like printer setup, etc.Whenever possible, ASAP provides examples, checklists, or templates as starting points forimplementation; i.e., Accelerators.

• Tools are a part of the package, including ASAP-specific tools to support project management,questionnaires for the business process consultants, and numerous technical guidebooks and

I





6

checklists. The core of ASAP is the R/3 Business Engineer, with its suite of softwareconfiguration tools.

• SAP Services and Training are also a component of ASAP, including all consulting, educationand support services, such as the hotline, remote upgraded, archiving, etc.

Accelerated SAP is divided into the phases that are indicated in Figure 1 and described below.

Figure 1: The Phases of the Accelerated SAP Implementation Methodology

Project Preparation: The Project Preparation phase is focused on organizing the project. This includes theexecutive kickoff meeting and making all of the organizational arrangements for the project team. Once theteam has been selected, they are trained in the ASAP methodology, a rough project plan is drafted, and thehardware order is processed.

Business Blueprint: The objective of the Business Blueprint phase is to document the business requirementsfor the implementation. Interviews and business process workshops, supported by questionnaires andgraphical business process chains from the R/3 Business Engineer, help the business teams decide which R/ 3business processes will be implemented. In some sense, Business Blueprinting is a scoping exercise, but that isnot the primary intent. The Blueprint actually “maps” the transactions that will be executed by R/3; hencealigning the software (at a high level) with internal business processes. The output of the Blueprintingprocess is a detailed document, called a transactional scope document, or just a scope document for short.

Blueprinting is a critical step in the implementation process. Decisions are made that bound theimplementation, and they MUST be correct. If not, the cost of changing later in the project can besignificant. Once the scope document is “frozen,” the project is defined, and further changes in scopemust adhere to a rigorous change control process.





7

Realization: Based on the business processes identified in the Business Blueprint, a baseline system isconfigured to match the “company structure” 100%, and to cover 80% of the business processes. The systemis documented and configured, using the R/3 Business Engineer tools. The technical team sets up the systemadministration and plans the interfaces and data conversion. The output of this phase is a configuredsystem, known as the “baseline system .”

Final Preparation: The Final Preparation phase consolidates all of the activities of the previous phases,readying the R/3 system and the implementing organization for production startup. This phase covers thefinal system tests, end user training, and migration of data to the new system. The conversion and interfaceprograms are all checked, volume and stress tests are run, and user-acceptance tests are carried out. End usertraining is initiated and a production start-up strategy is developed. The final step is to sign off the system,go live, and switch on.

Go Live and Support Continuous Change: Immediately after going live, the system is reviewed to ensurethat the business environment is fully supported. This means validating the business processes and technical

parameters, and interviewing end-users. The business benefits of the system are measured with the goal ofestimating ROI.

2.2 Problems with ASAPASAP has been used to guide many successful implementations. It provides an integrated SAP solution usingreusable business processes that have been refined over many implementations. Every major SAPimplementation consulting company has a repository of previously configured business process scripts,which can accelerate implementation within and across modules. This approach works reasonably well aslong as the implementing enterprise is bounded and well defined (i.e., there are no unique or unusualbusiness processes, and the project scope aligns with the boundaries of the SAP solution).

However, if there are unique and unusual requirements, and if there are many unnatural breaks in thesoftware, the ASAP methodology can lead to suboptimal business process configurations. If theimplementation consultants are configuring a mundane business process that they have configured manytimes in the past, they are familiar with the particular business process procedure, and it is likely that there isa pre-configured business process that can be used from a previous implementation. However, if the businessprocess is unique (e.g., DoD Funds Management or Moving Average Cost (MAC) calculations), then morecare must be taken. The implementing organization has the responsibility to understand the business processrequirements and must compare these requirements to the business processes that are supported by the SAPsoftware. There is mounting evidence that failure to pay attention to these additional details can lead todisappointing results 1.

2.2.1 Disconnect Between the Business Process Master List (BPML) and the ImplementationManagement Guide (IMG)

With ASAP, project scope information is stored in a stand-alone database that is called the Question &Answer Database (Q&Adb). SAP’s original intent was to scope the business processes using a survey

1 See the Boston Consulting Group Survey (2000) and the description of that survey by Booker (2000).





8

instrument. The results of the survey (i.e., the Questions & Answers) would be stored in a database (i.e., theQ&Adb) along with other business process documentation. The “answers” would be processed by an expertsystem, generating a business process scope for the project. This business process scope was presented in theform of a Business Process Master List (BPML).

To make a long story short, this approach never worked properly, causing many implementation consultingcompanies to bypass the surveys. The BPML was often populated in an ad-hoc fashion based on consultantexperience, resulting in what is popularly known as the “Empty Q&Adb.” On many projects, scope wasdetermined by interviewing alone, with no documenting or understanding of the organization’s businessprocesses. As noted by Booker (2000) and the BCG (2000), this lack of up-front study and analysis oftenleads to dissatisfaction with the results of the implementation.

2.2.2 Downloadable Scripts

SAP Business Process Procedures (BPPs) verbally describe how a business process should be configured. TheBPPs are usually generated though a modified rapid prototyping procedure where the business teammembers and the implementation consultants agree on the verbal description of how the business processshould be executed. In the USA, the BPPs are call “business scripts,” and they can be quite detailed,containing business process drawings and actual screen shots from the SAP software. The implementationconsultant uses the “business scripts” that have been approved by the customer as a guide for configuringthe SAP software. This provides “protection” for the consultant, in the form of customer approval. Theactual configuration takes place in an area of the SAP software that is called the ImplementationManagement Guide (IMG). There is no direct link between the BPML, the BPPs, and the IMG. Theconsultant interprets the linkage from experience and manually configures the software.

There are several shortcomings of this approach. The SAP software has considerable flexibility inconfiguration. The modified rapid prototyping approach can result in the consultant only displaying a

subset of the configurable options that are supported by the software. It is only natural that the consultantwill try to shorten the implementation cycle by reusing “business scripts” from previous engagements, or bydownloading previously defined scripts from the corporate repository. This can shorten implementationcycle times, and it does lead to an integrated solution. However, the solution was developed for someoneelse’s business.

2.2.3 Conflicted Requirements Definition

The Accelerated SAP approach requires that the business team members from the implementingorganization work side-by-side with the implementation consultants while they are executing the modifiedrapid prototyping procedure. The risk in this approach is that the consultant is helping to define businessprocess requirements based on what is most convenient to configure as opposed to what is best for theimplementing organization. This is a type of conflict of interest, which is akin to writing the RFP and thenwriting a proposal against the RFP. A better scenario has the implementing organization responsible fordefining and documenting the requirements and then passing those requirements to the consultant forconfiguration. While this modified process could be supported by ASAP, our experience is that thisseparation seldom occurs. This problem is getting more attention as many organizations try to regaincontrol of their implementation projects [see, for example, Koch (2002)].





9

2.2.4 The Magic Link

Since there is not a direct link between the project scope and the IMG, the implementing organization hasto rely on the interpretation of the consultant. This is not necessarily bad, but there is a major disconnect in

the ASAP methodology that is well known by consultants, but is typically unknown to the customer. Theproject scope has a business process orientation; i.e., it is summarized in the Business Process Master List.The IMG, on the other hand, is SAP module-oriented, and the transition between the two is sometimesunclear. The disconnect between business process scope and the IMG must be closed; hence, the consultantcloses it as best he can. Consulting experience is a key factor in enabling the transition from the BPML tothe IMG; therefore, implementations that try to control costs by hiring less experienced consultants, typicallypay a much larger cost. That is, the configuration does not align with the scope. The bottom line is that themodular orientation of the IMG is incompatible with cross-module business processes.

SAP has been aware of these problems for some time. To address these problems (and others) SAP hasdeveloped a product that is known as Solution Manager. However, as will be seen in the following sections,Solution Manager is just the first step in addressing the implementation problems. ARIS for my SAPenhances Solution Manager by focusing the SAP implementation on business process requirements, asopposed to MySAP components.

3.0 Solution ManagerAP Solution Manager is a platform that provides tools, integrated content, and the procedures neededto implement, support, and operate the MySAP solution. Solution Manager is NOT a new version ofASAP. It is a new tool and approach for managing SAP implementations, and it extends previousimplementation concepts. Solution Manager is designed to manage all SAP products, not just SAP

R/3. Hence, Solution Manager is more than an implementation methodology. It is a tool that is embeddedin the mySAP software, and the tool contains an implementation methodology

Solution Manager retains some aspects of the ASAP methodology and the supporting tools, but SolutionManager assumes the role as the onsite platform to support key implementation activities. In fact, it is theSAP implementation portal.

Solution Manager helps to:

• Ensure that the Business Blueprint will be configured, tested and monitored,• Understand events that occurred during the implementation project,• Ensure that the right deliverables are built at the right time during the project,• Monitor implementation progress,• Organize configuration and testing across a complex system landscape, and• Manage and compare configurations across systems.

Figure 2 presents the phases in which Solution Manager is used during the SAP implementation life-cycle.

S





10

SAP Solution Manager in Implementation

Configuration

Projectdefinition

Defin e BusinessBlueprint

ProjectPreparation

BusinessBlueprint Realization Go Live &

SupportFinal

preparation

Customizingsynchronization

Set upof DEV

landscape

Aut hor izati on

Datatransfer

End userTraining and

documentation

Testing

Projectphase

Roadmaps

Project AdministrationCrossfunctions

roe

a

vte

Issue Tracking Monitoring Reporting

DevelopmentsDefinesystem

landscape

Tool support available

Tool support outside ofSAP Solution Manager

SAP Solution Manager in Implementation

Configuration

Projectdefinition

Defin e BusinessBlueprint

ProjectPreparation

BusinessBlueprint Realization Go Live &

SupportFinal

preparation

Customizingsynchronization

Set upof DEV

landscape

Aut hor izati on

Datatransfer

End userTraining and

documentation

Testing

Projectphase

Roadmaps

Project AdministrationCrossfunctions

roe

a

vte

Issue Tracking Monitoring Reporting

DevelopmentsDefinesystem

landscape

Tool support available

Tool support outside ofSAP Solution Manager

Figure 2: SAP Solution Manager in Implementation

As previously mentioned, Solution Manager is an implementation portal, providing all necessaryimplementation tools. It also integrates the project deliverables to improve implementation results, whileallowing the team to reuse outputs from earlier phases as input for following phases; e.g., the blueprint is

integrated into the configuration process (i.e., SAP Customization) as well as into the testing. The portal hasthe appearance of an implementation roadmap, which makes it easier to use the implementationmethodology that is embedded inside Solution Manager. The Solution Manager implementation portal ispresented in Figure 3.





11

Figure 3: Solution Manager Implementation Portal.

3.1 More Tool than MethodologyValue SAP (i.e., ASAP and its supporting tools) was a stand-alone software product; i.e., Value SAP resided onone computer while the R/3 software was being installed on another. There was nothing wrong with thisapproach but, because they were separate systems, it was impossible to have close integration between thetwo. The ASAP methodology and tools captured all aspects of the implementation process, but still requiredsignificant external management during the implementation process. At the end of the implementation, youwere never sure that the design was realized, much less the tested business process agreed with the productionbusiness processes. This was a direct result of the configuration consultant interpretation problem that wasdiscussed in the previous section.

Solution Manager represents SAP’s attempt to close the gap between planned implementation and realizedimplementation by integrating the deliverables across ASAP phases. The gap closure is aided by the fact thatSolution Manager is built into the SAP software solution.

Furthermore, Solution Manager utilizes and fully integrates other SAP components, such as

• Knowledge Warehouse (Document Management),• eCATT (Automated Test Tool),





12

• Configuration Management and Transportation 2, and• System Monitoring.

Also, Business Blueprinting is managed and documented from inside Solution Manager. The Blueprinting

screen is reproduced in Figure 4.

Figure 4: Blueprinting Screen form Solution Manager

Within Solution Manager, SAP has made an important change from ASAP as it was implemented in ValueSAP. In Solution Manager, the Business Processes, Organizational Units and Master Data are fully integratedwithin one scenario, which makes the transition between the blueprinting and realization phases muchsmoother.

3.2 Tools vs. MethodologyAn ERP implementation is a broader effort than the configuration of the selected ERP software. Changemanagement, business process improvement, training, and other important components are a part of asuccessful implementation.

A methodology provides guidance on “how to get there,” while implementation tools support “what isdelivered.” The challenge is to bring the two concepts together effectively. Solution Manager is a tool; it isnot a methodology for a SAP implementation. Solution Manager supports the technical aspects of theimplementation and aligns the technical aspects within a roadmap that is displayed through a portal.

2 This linkage is still weak in Solution Manager. The next generation of SAP implementation products, the Change Management Server, isbeing designed to control this linkage. At that time (i.e., post 2005), the technology landscape will be closely linked with the businessprocess scope.





13

Hence, Solution Manager

• Is the new standard SAP implementation product,• Is the manufacture’s tool to “install” the software,• Produces standardized project deliverables, and• Allows standardization, visibility and management across SAP projects.

Solution Manager allows the customer to receive and own the deliverables and to enable the reuse of theimplementation results for the future. This is a major shift in project control, decreasing the flexibility of theimplementation consultants, and transferring control to the customer. Still, Solution Manager is notcomplete. It can be greatly improved by leveraging its capabilities with the ARIS for MySAP suite of tools.

3.3 ARIS for Solution ManagerARIS for Solution Manager is a version of the ARIS Toolset. Based on the conceptual changes in this SAPimplementation tool that were discussed in the previous section, the integration approach used by ARIS forSolution Manager is different from the approach used with ARIS and the Value SAP methodology.

The major change is a reorientation of the reference model approach. With the Q&Adb there was onereference model that contained the business processes from SAP R/3 only . Solution Manager includes allSAP products and this makes it impossible to have ONE reference model for all possible combinations ofmultiple SAP products and releases. Figure 5 shows the steps within the Solution Manager software for thegeneration of the reference process component.

ProductsProducts

ScenariosScenarios

ProcessesProcesses

1

2

3

Product Selection: As a first step, thecustomer selects the products andcomponents, as well as the releases neededfrom SAP to support the business scope.

Scenario Selection: As a result of theselected products, a list of available businessscenarios will be provided in Solution Manager.The customer must select the best-fit businessscenarios to be realized in the planned SAPimplementation

Process Generation: Solution Manager thengenerates all possible business processcomponents for the specified SAP solutions asan aid in the implementation.

Figure 5: Solution Manager Approach to Reference Process Generation





14

ARIS for Solution Manager enables an improved approach. With ARIS for Solution Manager, the order ofbox 1 and box 2 are reversed in Figure 5. This revised approach better satisfies the customer’s needs, since thesoftware should be purchased according to business needs, rather than selecting from a catalog of available

SAP products. The first step should be the determination of business needs based on existing and desiredbusiness scenarios, not SAP products that are available in the MySAP business suite. Figure 6 shows themodified approach using ARIS for Solution Manager.

ScenariosScenarios

ProductsProducts

ProcessesProcesses

1

2

3

Scenario Selection : Before making a decisionregarding which SAP products to purchase, thecustomer can evaluate, select and potentiallymap the existing and desired businessscenarios beforehand

Product Selection: Based on the selectedscenarios, ARIS reveals which SAP productsare needed to realize the scenarios, as well aswhich scenarios SAP products can not satisfy.

Process Generation: Solution Manager willthen generate all possible process componentsfor the SAP solutions to aid in theimplementation.

Figure 6: ARIS for Solution Manager Approach to Reference Process Generation

These generated business process components are structured along the selected scenarios, but do not expresshow the customer’s business is aligned with the technical SAP capabilities.

At this point, ARIS integration provides the biggest benefit during an SAP implementation project, sinceARIS builds a bridge between the business structure and MySAP products. After the 3 rd step (ProcessGeneration), the generated SAP business process components are also be available in ARIS to be linked tothe customer’s specific business process architecture. Figure 7 describes this relationship. ARIS updates andsynchronizes the selected business process components from ARIS to Solution Manager and vice versa.





15

EnterpirseProcess

SAP ProcessComponents

SAP BusinesProcess

+ =

EnterpirseProcess

SAP ProcessComponents

SAP BusinesProcess

+ =

Figure 7: Mapping the Enterprise Architecture to SAP Components

This tight integration allows the reuse of existing Enterprise Architectures or business blueprints. However, amapping process is required, and the possibility that this can be done automatically or at least semi-automatically is currently under evaluation but not resolved.

3.4 Project Information vs. Enterprise Information

The information stored inside Solution Manager is only project related and was never intended to representthe entire Enterprise Architecture. The implementation-oriented SAP reference structure is not sufficientlyrobust to represent all the needs of an integrated enterprise-wide architecture for an organization. The SAPblueprint is too detailed, and it does not document the overall solution; i.e. there are many businessprocesses that typically fall outside of SAP. ARIS for Solution Manager allows the use and reuse of project-specific information for a project-wide focus, as well as a starting point for building a complete EnterpriseArchitecture.

Furthermore, the approach using ARIS has major advantages over paper-based documentation from drawingtools, such as Visio. Since ARIS synchronizes directly to the Q&Adb and Solution Manager, alldocumentation is precisely linked to the SAP software. That is, since the business functional scripts are

mapped at the transaction level, the resulting solution maps and business process models are directly relatedto each other, as well as to the SAP software. This provides an accurate view of business process scope relativeto what has actually been configured by the project teams. Since all documentation is stored in a repository,changes are immediately reflected across all business processes and other views.

For example, if an object is contained in ten business processes across multiple organizational views, a singlechange to the object is immediately reflected in all views where that object occurs. This is in direct





16

opposition to drawing tools (like Visio) or file based tools (like Popkin), where each drawing that containsthe object must be manually updated. In an environment where multiple ERP projects use the samemethodology and all are mapped to the SAP reference model, unambiguous comparisons across the projectsare directly possible.

In summary, there is no “silver bullet” for resolving business process requirements against configurationdocumentation for complex enterprise initiatives. In the end, the senior executives must understand thecritical issues, including the implications of resolving one way versus another. Someone has to make thedifficult decisions that define business process scope that bounds the configuration. The EnterpriseArchitecture provides the documentation to support the decision process, and this documentation ismaintained using Solution Manager and ARIS for Solution Manager.

4.0 Example: Solution Manager Alternatives for the U.S.ArmySolution Manager is an attractive tool for the Army because of the complex system landscape. That is, theArmy has three projects (LMP, GCSS-A, and PLM+), which must be managed as one. This section providesone concept for how Solution Manager and ARIS may be used together to manage/monitor across theArmy’s complex solution landscape.

The assumption is that LMP, GCSS-A, and PLM+ will be managed as a single implementation program,with all projects sharing a common Business Blueprint that is stored in the SAP Solution Manager tool. Thebasic assumption is extended to include the version of Solution Manager; i.e., all projects will use SolutionManager 3.1. This blueprint will be periodically synchronized with the Enterprise Architecture 3 using the bi-directional interface with the ARIS for MySAP Suite. The Strategies, Architectures, and Standards Group(SASG) will consult with the project teams to address inconsistencies in the implementation program relativeto the plan. In this context, the plan is the SALE architecture.

A subset of the information stored in Solution Manager is relevant to the SASG. Our preliminary analysisindicates that the SASG has sufficient information to complete its tasking using the FunctionalImplementation component and the Global Strategy Management component inside of Solution Manager.However, the implementation project teams should use all components of Solution Manager. This allows theArmy to standardize its implementation methodology, tools, and documentation across the logisticsenterprise.

This section will first show how the monitoring environment will work for a single implementation project.Once the basic concepts are introduced with a single project, then we will show how the concept scales to

cover the three projects: LMP, PLM+, and GCSS-Army.

3 The Enterprise Architecture for Army Logistics is called the Single Army Logistics Enterprise (SALE) architecture. The word “single” isincluded to specifically note that the three projects are being as managed as one.





17

4.1 The Single Project ConfigurationAs previously mentioned, we will begin by describing a single project solution. This approach is only forsimplicity and the more general case will follow. The single project configuration is presented in Figure 8.

Architectu reRepository

(SASG)

ProjectManager

ProcessOwner

FI

ApplicationConfigurator (s)

(Full Time)

ProcessOwner

MM


(Full Time)

ProcessOwner

PP


(Full Time

Infrastructure Support

TechSupport

SuperUsers

DevProgrammers

RptProgrammers

TrainingDoc

ClericalSupport

MiscSupport

ProcessOwner

Etc.


(Full Time

BTL BTL BTL BTL

Seat Seat Seat Seat

Bi-Directional

SAP SolutionManager

SAP SolutionManager

SAP Solution Manager SAP Solution Manager

SAP SolutionManager

SAP SolutionManager

SAP SolutionManager

SAP SolutionManager

SAP SolutionManager

SAP SolutionManager

Single ProjectView of ARISand Solution

Manager

Figure 8: Single Project Configuration for ARIS and Solution Manager

Figure 8 indicates a standard SAP project organization, with Process Owners, Business Team Leads, andApplication Configurators. At the project level, there is a single Solution Manager Implementation and asingle ARIS for MySAP implementation. Each business team has access to both, so they can manage theirappropriate project information. The Single Army Logistics Enterprise architecture is managed as a separateARIS for MySAP solution. This separate solution is under the configuration control of the SASG.

As noted, the project teams feed scope and configuration information into Solution Manager, with supportfrom the ARIS for MySAP Suite. The information is maintained at the project level. Periodically, the SASGaccesses the project-level Solution Manager tool and synchronizes the architecture against the businessprocess structure that is stored in the tool. Since the reference structure in SAP is identical to the referencestructure in ARIS, such a synchronization is possible.

Hence, the roles in Figure 8 must be clearly defined. The Project Team is focused on implementation, andthe SASG is focused on monitoring the implementation relative to the architecture. Gaps in the contentprovided by SAP are developed in ARIS and stored in the SALE Architecture and in Solution Manager. Thisextends the SAP business process scope to include an Enterprise view, as indicated in the previous section.

The integration between ARIS and Solution Manager positions the Army to manage by business process.ARIS for MySAP and SAP Solution Manager allow one to monitor the implementation, but it also creates





18

an architecture for business process management. If managed to completion, the ARIS Process Platformallows the Army to manage by business process on the post-go-live SAP system.

BusinessLogic

TechnicalRealization

Business ProcessBusiness ProcessManagementManagement

Process Cost AnalyzingProcess Cost Analyzing

BSCBSC

SimulationSimulationWebWeb --publishingpublishing

……

ARIS ARISProcessProcessPlatformPlatform

TransactionsTransactions

BC SetsBC Sets

CustomizingCustomizing

Customizing distributionCustomizing distribution

MonitoringMonitoringOperationOperation

……

SAPSAPSOLMANSOLMAN

Integration

ProcessProcess --Oriented ImplementationOriented Implementation

ProcessProcess --Oriented User TrainingsOriented User Trainings

Individual Help SystemIndividual Help System

Interface DescriptionInterface Description

ProcessProcess --Oriented TestingOriented Testing

Creating User ProfilesCreating User Profiles

Reusing SAP HR DataReusing SAP HR Data

Role MappingRole Mapping

……

ARIS fo r mySAP ARIS fo r mySAP

Business Processes Aligned with SAP Technolo gy!

Figure 9: Relationship between ARIS and Solution Manager

We also note that the integration between ARIS for MySAP and Solution Manager is complementary. ARISis focused on the management level, and Solution Manager is focused on the technical level. The tightintegration between the two products “pulls” the levels together.

4.2 Multiple Project ConfigurationThis section extends the single project configuration to a multiple configuration scenario. For purposes ofthe example, we use the project names that are relevant to Army logistics; i.e., LMP, GCSS-Army, and PLM+.Figure 10 presents a multiple project configuration.





19

ArchitectureRepository

(SASG)

Bi-Directional

SAP Solution Manager SAP Solution Manager

LMP PLM+ GCSS-ASingle Instance of Solution Manager for All Projects!

Figure 10: Multiple Product Configuration for ARIS and Solution ManagerAs Figure 10 indicates, the multiple project scenario is an extension of the single project scenario. Thelandscape in Figure 10 is more complex, but the complexity is more related to project and contractmanagement than to the monitoring environment. In the multiple product scenario, there is still a singleSolution Manager and a single ARIS for MySAP installation. The synchronization with the SALEArchitecture is the same as in the single project scenario.

As seen in Figure 10, the three projects feed the single Solution Manager implementation. The individualproject business teams have Solution Manager seats as well as ARIS seats. As before, MySAP content gaps arefilled as organization-specific reference models using ARIS for MySAP. Also, as before, the roles of theProject Teams and SASG are clearly defined. The details are managed at the project level, and the SASGmonitors the implementation progress relative to the architecture.

5.0 Conclusionshis paper discusses the evolution of SAP’s implementation and tools. The focus is on comparingValue SAP with Solution Manager. The objective is to understand why Solution Manager is preferredover Value SAP, and also to understand how Solution Manager can enhance implementation successin large and complex implementations. To meet these objectives, the paper describes how

implementation methodologies relate to implementation tools, and also how the Solution Manager tool maybe used to monitor complex SAP system landscapes.





20

We also show how the ARIS for MySAP methodology and toolset can be used to enhance the capabilities ofSolution Manager. This enhanced capability is a result of ARIS driving the Solution Manager scope from abusiness requirements perspective as opposed to and SAP product perspective.

Finally, as an example, we show how Solution Manager and ARIS can be used together to help the U.S.Army manage three complex SAP implementations as one. This is accomplished by presenting a proposedimplementation environment that is based on project monitoring and control from an EnterpriseArchitecture.

6.0 ReferencesBooker, Ellis, Enterprise Projects Rarely Satisfy, InternetWeek , March 28, 2000,http://www.internetwk.com/story/INW20000328S0004

Boston Consulting Group, GettingValuefromEnterpriseInitiatives: A Survey of Executives . Boston: The Boston Consulting Group, March, 2000.

Ferguson, Renee Boucher and John S. McCright, ERP Vendors Rev Fast-Rollout Efforts, eWEEK

, August 24, 2001,http://www.zdnet.com/eweek/stories/general/0,11011,2807751,00.html

Koch, Christopher, Its Time to Take Control, CIO Magazine, July 15, 2002.

evolution of sap implementation environments white paper

Documents