SAP Terminology

A few terms to help the uninitiated:-

• SAP – World class, highly integrated business system processes and software used by many of the world’s largest and medium sized businesses.
• APO – ‘Advanced Planner and Optimizer’, SAP’s primary module aimed at supply chain planning, now changed its name/morphed into SCM ‘Supply Chain Management’.
• PP & PP-PI – SAP’s modules that deal with the business processes around manufacturing and supply operations. PP is essentially a production job model responding to customer orders, whereas PP-PI is aimed at continuous production models – most factory scenarios.

My Background

Since 2003, I have spent most of my time understanding and implementing SAP APO supply chain planning systems in many business scenarios within the FMCG market. For the 7 years prior to that, I implemented SAP for manufacturing operations, so I’ve gained a good background of SAP generally and APO specifically.

What is SAP APO or SCM

SAP in a system sense, appears to be a highly integrated set of modules. Mostly these modules sit within what is called R/3 or ECC…the core part of SAP. Core SAP holds the reins on integrated data throughout the SAP world so data about a plan to make something is all within core SAP and is linked in to master data defining materials and resources.

The SAP functionality to build supply chain plans is also within core SAP but in reality for most purposes it is near unusable in any practical sense. The practical side of automated planning requires a great deal of computing power and, for that reason, APO was conceived.

APO or SCM as it is now called, is in three parts:-

• DP – Demand Planning (forecasting) – can be linked to Customer Relationship Management to pull data about campaigns etc from there
• SNP – Supply Network Planning – it views the organization as a network of locations (factories and distribution centres primarily) which all have individual stock projections and stock keeping criteria. Calculations in SNP drive dependent requirements down to supplying locations (production and receiving stores)
• PPDS – Production Planning and Detailed Scheduling – the production plans are calculated here to meet the dependent requirements from locations within the supply network, passed down from SNP. PPDS is linked in with Material Requirement Planning, which is part of core SAP, to schedule inbound material components required by the production plan.

Master Data and Integration between Core SAP and APO / SCM

Despite APO or SCM now being on its sixth sojourn, it is still a long lost cousin in SAP integration terms. APO has many master data tables that mirror core SAP but generally with different names and with more attributes that are specific to planning. APO also has various planning versions which support what-if planning, each planning version can have its own version of master data.

The overall picture is one of a lot of master data complexity to support the functionality. However the complexity is really needed to support these calculations when you understand that SAP is highly configurable and has to deal with many different scenarios. Of course your company might be only interested in 20% of this opportunity and the other 80% is essentially noise! This isn’t a APO fact, this is a SAP one and to be fair one that is general for all configurable enterprise systems and not just SAP.

Where APO and data does become complicated in a peculiarly SAP way is that it has something called the Core-Interface that passes master data and transactional data between core SAP and APO. As transactions and master data changes pass through this interface, trying to keep the two systems in synchronization, they can frequently get stuck when activities happen out of sequence! This places heavy demands on the users (of various departments) to do their activities following a script with a specific sequence.

When activities happen out of sequence, transactions for the material or product in question get held in a queue needing manual intervention. Someone will then have to diagnose the problem and unpick it! Working with APO requires specific technical support in this area. For a large company this role will be a full time job and for an international company, there could be a team of people doing this!

Production Plan Calculations

Production planning uses a number of graphical interfaces, the two main ones being:-

• Production Planning Table – spreadsheet type interface with plan quantities in cells which represent a bucket of time (month, day, shift, etc)
• Detailed Schedulers Planning Board – Gantt type planning board with time as an axis and orders appearing as slugs in time.

Planning and scheduling calculations can be done manually by typing numbers into cells or dragging and dropping orders into new positions. It can also be done by background calculations. There are two broad approaches – Heuristics or the Optimizer.

Heuristics

I remember as an under graduate being told heuristic methods were those arrived at through experience…”suck it and see” approaches. SAP uses the term to mean customizable calculations based on an underlying algorithm to do a specific job eg. create new planned orders. Customizing in this context would be getting the algorithm to create orders based on specific parameters. In simple planning terms, heuristics are a bit like MRP calculations.

Optimizer

There are lots of ways to “skin a cat” as the story goes and similarly there are usually many different ways of creating a production plan, all of which may well be valid! The chosen plan will be chosen because it priorities one aspect above others or maybe there is a hierarchy of important aspects to achieve in the plan, eg. just in time, maintain shelf-life, etc. The Optimizer needs to know the relative costs of aspects so that it can rank their importance. You then set the Optimizer off and give it a period of time to do calculations. It will calculate the plan many times over and when the clock stops, it checks to see which of its plans was achieved at lowest cost (ie. highest achievement of rankings).

What’s it like using APO?

Unless you have very flexible and short supply routes, the Optimizer is very difficult to use because every time you run it it will come up with a different answer. Most continuous process businesses can’t cope with changing their inbound supply plans to this degree and so the Optimizer if used at all, might have to be restricted to those materials that have components that can be sourced very quickly.

The heuristics provide a means of working with APO that most scenarios can cope with. Some levels of planning become an automatic reaction to plans in other areas and so these can be set to automatically plan each time something changes that relates to them.

From a planners perspective, APO is a heavy tool to crack a nut but they are likely to be relating a lot to spreadsheets and failing to see the positive side of APO in being integrated with their other business systems. You raise an order in APO and it gets worked on in core SAP, APO being updated in real time with what’s going on for stocks etc.

I recall visiting a planner three years after I’d implemented APO. Lets call him Jim, as that was his name! Prior to SAP, he had a very flexible graphical planning board and all their questions were based around how can SAP be made to be like the tool they had. They had no integration between that tool however and their MRP and stock control systems and that could often cause them stock-out surprises! So it would be fair to say that Jim wasn’t overly keen on moving to SAP and APO. Three years on, he was managing considerably more production capacity and singing APO’s praises. He was well aware of its problems, including the poor integration between APO and R/3 but it was bringing him more benefits than he had previously and as a factory they had learned how to manage their processes more effectively, which in turn brought fewer integration problems.

Resourcing to support APO

I had the privilege of working with APO’s founder PP-DS developer, Guy Lauwers, on a prototype project between Nestle SA and SAP SA in 1999-2000. APO PP-DS has changed little in concept since its days known as PFS. Since then, with over ten years of APO, SAP have studiously avoided tackling its integration issues. It is a great shame as it is the single biggest drain on resources to support APO and continues to undermine its credibility.

I hope my description of SAP APO and what it entails has opened your eyes rather than put you off. If you’re using SAP as an enterprise-wide system, SAP APO is very usable. It takes quite a long time for planner to pick up because there are a lot of buttons and widgets that create noise for learning and half of their understanding is in how their process now interconnects in real-time with other processes within the organization.

So expect to have to spend time and money on supporting APO and when constructing project plans remember that APO can only plan when all the APO master has been built on top of the underlying core SAP master data. Don’t expect rabbits out of planners hats if you haven’t allocated sufficient project time for this activity!

The following is part two in BayForce’s series on Solution Manager and details specific issues and key steps to consider when implementing ChaRM.

Click here to view the first part of this series “Solution Manager: What Is It & What Can It Do For Your Business”.

Solution Manager Part II: ChaRM Revealed

Right-click to download white paper.

SAP has been encouraging customers to use Solution Manager for quite a while now; somewhat subtly in the beginning by making this the only channel to acquire installation keys.  Customers with impending installations or upgrades reluctantly raced to stand up minimal instances of Solution Manager for the sole purpose of obtaining these keys while the remaining customers ignored it.  Initially Solution Manager was widely viewed as a nuisance, one more instance of SAP that needed to be supported.

These initial instances of Solution Manager were very basic installations that a competent Basis resource could install and configure within a few hours. They required little attention or interaction unless new installation or upgrade keys were needed. Solution Manger has evolved into a comprehensive set of tools that provide system performance monitoring, problem tracking, root cause analysis and change and transport management. This new functionality requires extensive configuration and can touch every instance within an enterprise.

If you’ve attended Sapphire or SAP TechEd in the last few years you’ve no doubt seen a presentation on Solution Manager.  SAP advertises Solution Manger as an included component, sometimes leading customers to believe that to activate its vast functionality requires only basic configuration.  This combined with the historic belief that Solution Manger is a simple system, requiring little effort to install, has misled many an executive or manager. This is compounded by Basis/Technical resources believing that having mastered the support of SAP prepares them for the new requirements of Solution Manager. While the basic installation of Solution Manger remains a relatively simple task for a technical resource, gone are the days of a 1 day installation and configuration of Solution Manager.

To appreciate this complexity it’s valuable to break down the components of Solution Manager and identify some of the common pitfalls and challenges many customers face.  The first and largest challenge is the decision process.  Questions such as what components will be activated, what problems will be reported, who will be notified, where will the server reside, will it be a discreet instance and will it function as a central or distributed manager of change and problem tracking.  These decisions rest with the project management and/or executive sponsors of the project.  The challenge is people don’t know what they don’t know.  Until the functionality of Solution Manager is peeled back layer by layer, management not only doesn’t know the answers, they don’t even know there was a question to be answered.  Progress is hindered until these questions can be answered.

I know how glamorous the SAP product presentations appear.  Customers are almost convinced that 90% of the advertised functionality comes with the installation itself.  This is not true at all.  Each installation of SAP Solution Manager is a unique configuration based on specific customer needs.  It’s not unlike configuring any other component of SAP.  For proper project planning it could be compared to configuring FI, a fundamental component of SAP. Experienced project teams staffed with power users and supplemented by consulting partners spend months developing business process blue prints and migration plans.  Careful consideration is made to plan cutover during a weekend.  Integration and performance testing scenarios are planned and executed.  Support for critical projects such as this must start from the top.  Can you see how the perspective that Solution Manager is essentially a Basis component merely needing activation is harmful to proper budget and project planning?

SAP has provided a comprehensive, useful toolset that can function beautifully as the central system management console when properly implemented.  However, Solution Manager provides functionality for several business functions, each with specific, unique challenges that must be considered.  I’ve found that most clients are focusing on ChaRM as the primary component to implement, so the following provides some specific information and issues relating to this component.

ChaRM Misunderstandings & Technical Challenges Explained

A common misunderstanding is the belief that implementing ChaRM will provide a pre-defined workflow and change management process.  It’s true that ChaRM will force customers to adhere to a plan and inherently provide consistency but that is accomplished by the customer providing the plan.  If your transport management process is a mess today, it will be hard to adapt to ChaRM without first adopting a consistent plan.  The first critical step will be to identify users who will create transports, manage transports, test transports and approve transports.  These users can either be manually assigned at the creation of a transport, or based on pre-defined criteria, they can be automatically assigned.  They must exist and be identified or ChaRM cannot function.

One of the benefits of ChaRM is that it will provide much more formidable structure to organize transports automatically using multiple factors that previously were performed manually or thru substantial custom development.  To realize this robust functionality, however, customers must learn how to create and manage Solution Manager Projects thru maintenance cycles.  Decisions will need to be made as to which transports move into what environments based on the project(s) they are assigned to.  A well defined set of criteria must be in place to sort transports into categories of routine, emergency or standard maintenance and different processes must be established for each of these along with potentially different transport routes.

Once Solution Manager is properly understood and appropriately planned, then you finally begin experiencing, and can address the technical challenges.  Following are several of the key steps and issues you should be aware of when implementing ChaRM.

There are many configuration steps to complete the activation of ChaRM.  These start with 2 critical activities that are actually not part of SolMan and are common problems.  First, the SAP SLD (System Landscape Directory) must be setup.  This is the foundation that provides the entire system mapping to Solution Manager and ChaRM.  Another critical SAP specific task is to establish the Transport Routes and consolidated Transport Routes for the environment.

Transport routes must be defined in STMS in order for Solution Manager / ChaRM to function.  Many initial problems are related to the SAP configuration being incomplete or non-compliant with ChaRM.

Following SLD and transport route related issues as the most common trouble areas, problems caused by a flawed basic configuration of ChaRM run a close second.  It’s important to verify that the configuration of ChaRM was completed correctly.  This verification can be accomplished like other SAP components via the IMG using transaction SPRO.

Another significant step often overlooked is the creation of an RFC connection between the ChaRM client and client 000 in the Solution Manager instance.  This can be accomplished with transaction SMSY.  Because clients often move their transport domain controller from development to production once they’ve gone live, it is necessary to recreate the RFC connection to the new instance if this occurs.

Additionally, it is important to verify that ChaRM has been activated by confirming that the table BCOS_CUST contains the following entries.

|
This will confirm that ChaRM has been activated for specific clients.

The activation of the BC Set for ChaRM SOLMAN40_CHARM_BASICFUNC_001 must be completed and Extended Transport Control must be activated.

Verify that the domain controller has been properly created within transaction STMS.

To request a link between two transport domains, proceed as follows:

1. Log on to one of the two domain controller systems, in SolMan system, for example:
2. Call transaction STMS (always being in client 000)
3. Choose Overview > Systems

The system overview appears.

Choose SAP System > Create > Domain link

The dialog box Request for Linking 2 Domains appears.

Enter system name, DEV for example, hostname where is installed the system and system number, all this information is in SM51 of the DEV system, if DEV system is the domain controller of your real landscape.

Your SAP System performs the following actions automatically:

• Generates the required RFC destinations
• Sends the address data of the controller to the controller in the other domain

Afterwards, you need to logon in the domain controller, client 000, of your real landscape and confirm the link between these two domains as follows:

• Log on to the domain controller in the other domain
• Call Transaction STMS in client 000
• Choose Overview >Systems. The system overview appears
• Position the cursor on the domain controller where you requested the domain link, DOMAIN_SMM in our example, and choose SAP System Approve
• Confirm the prompt and distribute the configuration

The two domain controllers now exchange all necessary information about the systems in their domains. This information is distributed to all systems in the domain whose controller you are currently logged on to. A transport profile is generated, which contains all systems in both domains.

You have to see something like this in your SolMan system (called SSM in this real example):

And this in the DEV system (called ED4 in this real example):

To check that the domain link is good, go into the SolMan system and in the development system to STMS->transport routes, in the top of the screen you will see that in the SolMan system, the systems belonging to the other transport domain appear like boxes and are the same if you go to STMS in the DEV system, the box of the SolMan system can be seen.

Another area where a lack of experience can lead to a number of frustrating problems and wasted time through trial and error is the creation of a “Project”.  Projects are the fundamental mechanism for managing change in ChaRM.  There are 2 types of projects– implementation and maintenance.

For reference to creating projects please click here.

1. 1. Select SAP Solution Manager 7.0
2. 2. Select Learning Map for Supp Organizations/Serv providers
3. 3. Open Change Request Management section and see the iTutor called “Create a Project”

The following screen shots will walk through the process of creating and activating a ChaRM maintenance project.

Under the System Landscape Tab:

Systems: the Logical component is entered

Take into account that all systems that belongs to the TMS landscape must be assigned to the same logical component because all systems must have the same product version except when upgrading.

This means that in the same logical component each system must be assigned a role; you can have a minimum of two systems for a ChaRM scenario but you can have, for example, 5 systems with different roles in your real landscape.

The following screen shot represents this example:

A problem that many customers struggle with when trying to create a project is the inability to activate ChaRM. This will happen when the landscape that is defined in Solution Manager doesn’t exactly match the landscape in STMS.  Until these landscapes are consistent, ChaRM can not be activated.

Under the IMG project tab: define the project

ALWAYS define projects in the development system ONLY!  The project must be defined in the development system so that it can be assigned to all transport orders that are created with a Change request in the SolMan system.  This is an absolute requirement when using ChaRM.

See the above iTutor to see how to define this IMG project.

Don’t define IMG projects in other roles, systems, different from development.

Under the Change Request tab: Select “Activate Change Request Management”

Select Create Task List

Select the name of your Maintenance Cycle also called Project Cycle.

Note: Choose Lock/Unlock Group/Subsequent Groups to unlock the tasks in the task list.

If all is working correctly a Task List and a Maintenance transaction type SDMN (called Service Desk Transaction in the screenshot) is being created.

Service Desk Transaction Tab: shows the SDMN document for this project cycle.

The task list is one representative of the cycle and represents the system landscape tracks with tasks to be used by an IT operator for managing project related IT activities, especially imports.

The SDMN transaction represents the service request for managing the phase changes.

It is recommended that you activate and change the phase by executing transaction CRM_DNO_MONITOR using transaction type SDMN.

So, phase shifts should be done from within the cycle transaction SDMN but not from within the tasklist.

In the case of the Task list not being created, please run the Check (transaction /n/tmwflow/charmchk) or go to the Application Log via the button or calling SLG1 directly.

In both places you will get information as to why the Task List and the Maintenance Cycle is not being created.

These steps will help verify that SAP and Solution Manger / ChaRM have been correctly configured to support the features of ChaRM.

I hope you find this document helpful in understanding and implementing ChaRM.  These are just some examples of common problems that are experienced by customers implementing ChaRM and not a comprehensive list.  This document is also not a replacement for proper consulting help.  It’s imperative to have not only an experienced technical resource, but one who’s specifically experienced with Solution Manger implementation and configuration.  There is a reason that SAP has a specific certification program for Solution Manager.

If you would like assistance evaluating, implementing, or trouble-shooting your Solution Manager system, please contact us and we will be happy to set up a preliminary call to discuss.

About the Author

Ken Asher holds a Masters degree in Engineering, Mathematics, and Computer Science. He has over 17 years of SAP experience and has worked as an SAP America liaison to various clients to resolve critical architecture and solution issues throughout his career including during his time with Andersen Consulting/Accenture.  Ken was also a member of SAP’s ATAC team for advanced technical application consulting.  He has a deep understanding of SAP architecture and has worked with all of the latest SAP technologies.  In many of his previous projects he has been responsible for reviewing and recommending strategy as well as project planning for SAP clients including GMAC, Raytheon, and MIT.  Ken is currently deployed by BayForce to assist Amtrak with multiple ongoing projects including one of their largest initiatives for Strategic Asset Management.

To contact Mr. Asher or discuss how we can assist you with your upcoming projects, please call Kim Snow, Vice President of Delivery at BayForce, at 813-908-8593 or send an email to ksnow@bayforce.com.

The Proof of Concept Upgrade – A Small Investment Today, for Significant Savings Tomorrow

One piece of advice I offer to customers as discussions of an upgrade start taking place is, before you even start writing your upgrade project plans, strongly consider executing a Proof of Concept Upgrade project. This is a low cost and extremely effective means to properly plan for and execute an SAP upgrade. In the numerous upgrades I’ve been involved in managing, the projects that start off with a Proof of Concept upgrade having already taken place are almost without exception the smoothest and most predictable.

Right-Click the PDF icon and select to download this Proof of Concept Upgrade article.

A proof of concept upgrade project consists of copying your productive environment to a new system(s), performing the technical upgrade on that system, and initial functional testing taking place. Use of software testing tools can be used in conjunction with this effort as well.

No two SAP systems are “the same”. Your SAP system is comprised of your servers, software, configuration, data, and connecting systems. Your SAP system will always be unique to your environment. Due to this, no two SAP upgrades are the same, and the key here is that you’re gleaning as much information as possible about the total effort involved in your upgrade, before committing to a timeline, methodology, or budget.

I normally recommend a Proof of Concept upgrade take place 6 months prior to the planned start of an upgrade project. This accomplishes several things.

1. It identifies any technical dependencies that your Basis group will need to be prepared for during or before the upgrade cycle. Often times, dependencies on software versions, pre-existing issues with your SAP system (which may have been lingering unseen since your last support pack project, upgrade, or possibly, your initial installation), or possible compatibility issues with connecting systems get overlooked until you’ve reached the upgrade timeline. Any one of these issues could quickly turn into a timeline consuming, costly, and game changing project issue if they’re not discovered before you’re on a critical timeline.
2. Better prepares your functional, security, and ABAP teams for necessary changes by giving them additional insight into the changes that will be necessary during the upgrade. Once again, this information is critical for properly planning the actual upgrade timeline.
3. Identifies and familiarizes your team with new features of the software that may be of interest for implementing.

The Proof of Concept upgrade should ideally consist of a copy of your productive landscape. While many companies may find it too costly to exactly reproduce all systems involved, the closer this can be done will greatly help identify compatibility issues. Whatever the case may be, this landscape should be isolated from your actual productive landscape, and ideally, your actual upgrade timeline.

Plan on using a full database copy of your production data for the system. This will better ensure that data-related issues during the actual upgrade process are replicated during the sandbox phase, as opposed to during the critical path of your actual upgrade project timeline.

All in all, keep in mind that there is a tremendous amount of change during any SAP upgrade process and the changes involved will impact all areas of your SAP team. The more you can know early on, before going into the project, will only help you keep your project on-time, on-budget, and successful.

For more information about BayForce SAP Technical Services click here.

About the Author

Adam Marcus has over 12 years of SAP experience and has directed teams of 20+ consultants delivering services to as many as 50 clients at any one time. Adam has served as a Director and Practice Manager in the SAP Managed Services industry for 7 years.

To contact Mr. Marcus or discuss how we can assist you with your upcoming projects please call Adam at 262-643-4817 or email amarcus@bayforce.com.

Right-click to download white paper.

Are you considering implementing additional functionality within Solution Manager?  Do you want to understand how different features within SolMan can benefit your business?   Or do you already understand the features but want to ensure you are prepared for their implementation?

The following Solution Overview is designed to provide SAP customers with an understanding of what SolMan is, what it can do for your business, steps you must take to prepare for implementation, and third party tools integration.

Subsequent issues of our BayForce newsletter will include a detailed look at ChaRM and CCMS.

1. SOLMAN Background

The SAP Solution Manager or SOLMAN is a type of application which:

• •  Takes a consistent business-process and phase-oriented approach
• •  Provides End-to-end functionality for application management and continuous improvement
• •  Provides full life-cycle support and collaboration with SAP
• •  Contains best practices for implementation, operation and optimization of SAP solutions
• •  Is delivered as part of the annual maintenance fee

SOLMAN Provides the necessary tools around the Implementation, Operational and Optimization aspects of your SAP Application life cycle.

SOLMAN provides insights into all of the following shown in the picture below:

1.1 Application Lifecycle Management

SAP SOLMAN provides support for all phases of the Application Lifecycle Management. The following diagram is provided by SAP to show the support of the tool in all phases of the Application Lifecycle.

1.2 Functionality Overview

SAP SOLMAN Offers a broad range of functionality for Project Implementation and Operations as shown below:

1.3 SOLMAN in the lifecycle of an Implementation Project

During the lifecycle of an Implementation project, Solution Manager supports all project phases.

1.3.1 Design Phase

• •  Define methodology (select and design roadmap)
• •  Define and setup system landscape
• •  Define documentation strategy and deliverables management
• •  Create business process model and designs

1.3.2 Build Phase

• •  Perform and document backend system configuration
• •  Develop custom RICEFW objects
• •  Plan test approach and manage testing
• •  Track development, configuration and test progress

1.3.3 Test and Deploy

• •  Plan and manage training approach
• •  Create training materials
• •  Define roll-out strategy
• •  Manage local/global business process approach

1.3.4 Manage Project

• •  Compare and harmonize configuration settings across system landscape
• •  Throughout the project: track deliverables, configuration, development, testing and training progress

2. Prerequisites

2.1 System Landscape

The System Landscape (transaction SMSY) is the central point in Solution Manager to configure the landscape (both SAP and non-SAP components) including detailed technical information about the components and the connections between them.

Features:

• •  Central configuration of satellite systems
• •  Automatic collection of system information
• •  Creation of (Trusted) RFC Connections and RFC Users
• •  Creation of logical components
• •  Logical components group all systems of a transport track. They can include virtual systems, that work as placeholders for future systems that are not yet available, but transports can already be sent there (transport buffer file exists).
• •  The system information is used for system monitoring, ChaRM and to receive tailored updates from SAP Support.
• •  The correct setup of the system landscape is a prerequisite to nearly all other functionality of Solution Manager.

2.2 Document Management

SAP Solution Manager contains a complete Document Management System that supports the documentation of the SAP solution at any level and across all functionalities in order to support the project, the global roll-out and later on the solution support.

Functionality:

• •  SAP Solution Manager offers a wide range of document management functions (status schemes, versioning, history, detailed authorizations, custom attributes etc.)
• •  Complete MS Office Integration (but also other files)
• •  Digital signature for document sign-off
• •  Documents are available in Projects, as well as in Roadmaps, Test and Service Tickets
• •  SAP business process repository (BPR) allows you to add generic SAP business and setup documentation for the blueprint structure and the configuration.
• •  In the context of global roll-out, all documents of a project can be easily compared with a reference template.

Prerequisites:

• •  Creation of a project
• •  Set up of the business blueprint

Benefits and Value:

• •  Integrates the documentation and solution set up along business processes
• •  Allows you to run a central project documentation point
• •  Within a global roll-out the document can be delivered, managed and updated per roll-out
• •  All documents related to a change request can be identified
• •  Easy status tracking of documentation, test and training

2.2.1 Document Management Screens in SOLMAN

2.2.2 SOLMAN Document Management – Functional Teams

The Functional teams can leverage the Document Management functionality offered by SOLMAN and centralize all process and project related documentation.

The Functional team is encouraged to go through the wealth of SAP library web resources on the following topics:

• •  Document Repository
• •  Edit Documents
• •  Solution Manager and SAP KW Documents
• •  Assign Authorizations for Documents
• •  Status, Keywords and Documentation Types
• •  General Documentation
• •  Create Business Blueprint Document
• •  Create Configuration Guide

http://help.sap.com/saphelp_smehp1/helpdata/en/b3/64c33af662c514e10000000a114084/frameset.htm

Navigate to: SAP Solution Manager > Implementing and Upgrading SAP Solutions > Projects > Document  Management

2.3 Project Administration

All implementation functions within Solution Manager are based on the project. The project administration is the single point for all central project administration tasks which need to be performed.

There are several “Project Administration” functions available:

• •  Setup the Project with general data
• •  Creation of project templates
• •  Defining project standards (status values, documentation types, keywords)
• •  Definition of the project landscape
• •  Creation of IMG projects
• •  Definition of transport details
• •  The Project Administration is the prerequisite for all other Solution Manager functions that’s why at least one project with a specific type needs to be created

2.3.1 Project Administration Screens in SOLMAN

3. Implementation

3.1 Road Maps

Along with the business process and system documentation, SAP offers the Roadmap functionality to track the progress of the project work. SAP delivers their best practise methods (ASAP) for a variety of products with the Solution Manager. Roadmaps contain the following information (RMMAIN):

• •  Phases of the project, e.g. Project Preparation, Business Blueprint, Realization, GoLive.
• •  Work packages within the project phases (eg. Initial Project Planning, Project Procedures).
• •  Document Templates (“Accelerators”) and description of activities to be carried out within the work packages.
• •  Milestones, which can be used for Quality Management processes (e.g. Quality Gates, QPI).

For each project a roadmap can be selected from a list of predefined SAP roadmaps (e.g. ASAP Implementation, ASAP Global Template Rollout, etc). Changes to the central Roadmap are immediately visible in all projects that use this Roadmap.

3.2 Business Blueprint

The Business Blueprint (transaction SOLAR01) is used to structure, analyze and document all to-be business processes within a hierarchical 3-level structure

Functionality:

• •  The business process hierarchy is set up in
  • Business Scenarios (Level 1)
  • Business Processes (Level 2)
  • Business Process Steps (Level 3)

• •  Pre-delivered SAP business content (documentation, transactions, configuration) are shipped with Solution Manager or can be downloaded from SAP Service Market Place
  • Administrative information (responsible, status, keywords, plan/actual dates) available on all levels
  • Use of document management at any level
  • Add/execute relevant transactions at structure level
  • Analysis across all structure levels regarding status, contents, documents

3.3 Configuration

The Functional teams can leverage the Configuration functionality offered by SOLMAN and centralize all process changes and associated documentation via SAP SOLMAN.

The configuration functionality (transaction SOLAR02) offers the possibility to centralize process-orientated system configuration and custom development to a single point of entry.

Functionality:

• •  Centralized configuration of defined logical components
• •  Use of pre-delivered SAP business content (documentation, transactions, configuration, BC-sets)
• •  Administration of any structure level (responsible, state, plan/actual efforts)
• •  Use of document management at any level
• •  Add/execute relevant configuration, custom development, BC-Sets to individual structure level
• •  Analyzing of all structure level regarding status and plan/actual effort
• •  Platform and system starting point for test and training management

Prerequisites:

• •  Creation of a Project
• •  Setup of Business Blueprint structure
• •  Setup of System Landscape and Logical Components
• •  Creation of an IMG Project

Benefits and Value for Teams:

• •  Document and link customizing and custom development for all satellite systems via SolMan
• •  Automated checks avoid typos or inconsistencies
• •  Lock of transaction SPRO in satellite systems ensures that no undocumented customizing can be performed
• •  Assignment of IMG nodes, developments, RICEFW and Configuration Documentation to processes or activities
• •  Support of global roll-out with configuration templates
• •  Easy implementation of pre-delivered configuration content

3.3.1 Configuration Screens in SOLMAN

3.3.2 Configuration – Functional Teams

This part of the project configures the process requirements specified in the Business Blueprint phase, in the system.

If you use objects from the Business Process Repository in your own structures, some of them are already assigned to transactions and BC Sets. If you create structures independently, i.e. without objects from the Business Process Repository, you can assign transactions in the transaction Business Blueprint.

You can assign BC Sets, IMG objects and test cases/business test requirements, in the transaction Configuration.

Prerequisites:

You have selected scenarios and processes or created your own processes using the Business Process Repository, in the Business Blueprint phase.

You are in the Realization phase and have called the Configuration transaction.

Features:

In this project task, we can:

• • Edit transaction/program assignments
• • You can run the transactions which are already assigned in the Transactions tab, add new transactions, or remove not-needed transactions from the project scope.
• • Assign/edit BC Sets
• • You can assign BC Sets to project steps, in the Configuration tab, view the contents of the assigned BC Sets, and remove not-needed BC Sets from the project scope.
• • You can activate one BC Set or all BC Sets assigned to a process.
• • You can create new BC Sets in application systems, and assign them in the Solution Manager, for project or company-specific settings which you want to use (e.g. in a global rollout or to create your own solution).
• • Make/edit IMG assignment
• • You can assign IMG objects to the project steps. You can see and edit these settings, and the settings made by BC Sets, in the component system IMG.
• • Edit test cases
• • You can perform first function tests directly after the configuration. You can also run CATTs to familiarize yourself with how a transaction works. You can also create test cases.
• • You document the settings which are relevant to the configuration, along the project structure, in the Project Documentation tab. For more information, see Processing Documents.
• • Create/change issues and problem messages in the Issues/Messages tab.

Help and Reference for Configuration – Functional Teams

The functional teams can leverage the wealth of information on various Configuration options in SOLMAN by referring to this SAP library web resource:

http://help.sap.com/saphelp_smehp1/helpdata/en/b3/64c33af662c514e10000000a114084/frameset.htm

Navigate to: SAP Solution Manager > Implementing and Upgrading SAP Solutions > Projects > Document  Management

3.4 Test Management

SAP recommends two options for testing SAP solutions:

• •  Use of Solution Manager combined with 3^rd Party tools (esp. HP Quality Center for SAP)

• •  Use of Solution Manager Test Workbench only. The Test Workbench provides a comprehensive toolset supporting functional testing (manual as well as basic automated testing).

Some customers leverage HP Quality Center which can be integrated into SAP Solution Manager. It has a broad range of features beyond what is offered by the SOLMAN Test Workbench. However for quick testing, the SOLMAN Test Workbench can still be leveraged.

Some of the features of the SOLMAN Test WorkBench for Basic Testing:

• •  Easily use test cases and recorded eCATT test scripts stored in the business process structure
• •  Create test plans as a logical structure for test phases
• •  Divide test plans into test packages which are assigned to one or more testers
• •  Directly jump into test system and respective transaction
• •  Document test results within the Solution Manager
• •  Analyze all test results and test status within the Solution Manager
• •  Integrate the Test Workbench with the Service Desk using tickets to raise and manage bugs discovered

3.4.1 SOLMAN Screens for Test Management via Test WorkBench

4. Operation

The Solution Manager delivers integrated solutions and tools to efficiently monitor and operate your SAP Landscape.

After the SAP Solution has been established, SOLUTION MANAGER supports the operations team with the following functionality:

4.1 Operation – Prerequisite – Solution Landscape

The Solution Landscape makes it possible to manage and to monitor systems and business processes in operational processing.

A solution contains systems, which you assign according to certain criteria, for example:

• •  It contains all systems used in the production processing in your system landscape (i.e. on which one or more of your most important business processes run). You can proactively monitor the business processes, business process steps, and interfaces of these systems (e.g. all production systems).
• •  It has a restricted view of the systems in your system landscape (e.g. for a business area).
• •  The solution scope and settings can be specified in the Solution Directory.

Prerequisites:

• •  Physical and technical connection to satellite systems
• •  Assigned the Solution Monitoring role to the users
• •  Defined systems and logical components in the System landscape maintenance (transaction SMSY)
• •  The correct setup of the solution landscape is prerequisite to almost all Solution Manager operation functionality like Monitoring, Service Desk, Change Request Management etc.

4.2 Solution Manager Diagnostics

The current version of Solution Manager Diagnostics focuses on root cause analysis for SAP Web Application Server JAVA Stack and SAP Enterprise Portal with the following key features:

• • Central Configuration Display
• • Central Log File Viewer
• • Software Change Tracking
• • Portal Monitoring and Single Activity Trace
• • HTTP Analysis
• • JAVA Thread Dump Analysis
• • JAVA Performance Analysis with WilyTech Introscope
• • Load tests with Mercury Loadrunner

Prerequisites:

• • The Solution Manager Diagnostics is based on SAP Web AS 6.40.
• • SMD is required if you run at least one SAP Web Application Server JAVA Stack in your SAP Solution
• • SAP PI (dual stack) and EP will sit on SAP Web Application Server JAVA Stack.

Benefits and Value:

• • Solution Manager Diagnostics provides efficient and safe root cause analysis for SAP NetWeaver.
• • The SMD is a pure analysis tool, it has read access only. SAP wants to avoid being accused of damaging the Java system. For Java, without SMD, you need to connect to the file system of the server in order to be able to read all the system logs.
• • One central web-enable console
• • Integrates in Service Desk scenario
• • Ensures standardized operations and effective optimization

4.2.1 SOLMAN Screens for Solution Manager Diagnostics

4.3 Service Desk

The Solution Manager offers all functionality to set up a Service Desk scenario for the customers system landscape.

• • One-click support message creation from satellite systems and automatic Data Collection (e.g. Time, System, Client, User, Transaction) from sending system
• • Various possibilities to customize the scenario (e.g. Support Desk Org., Status scheme, Parties involved)
• • Basic Ticket Reporting (no built-in SLA-time reporting!)
• • Solution Database functionality to store problems, root-causes and re-usable solutions
• • In case of an existing Support Organization connection of 3rd Party Ticketing Tool possible (WebService)
• • Service Desk is based on a reduced SAP CRM system already integrated in SAP Solution Manager
• • Extension “Service Desk XT” (extra license costs!) enhances the Service Desk to support non-SAP components

Prerequisites:

• • Setup of system landscape and logical components
• • Configure RFC to Solution Manager in all satellite systems
• • SAP PI (dual stack) and EP will sit on SAP Web Application Server JAVA Stack

Benefits and Value for SAM:

• • Very comfortable ticket creation for SAP end/key users
• • Service Desk as SPOC of Support Services for all connected SAP (and optional: non-SAP) Systems
• • Automatic support team assignment for SAP components
• • Seamless ticket escalation to SAP Global Support
• • Compliant to ITIL Service Support process model
• • Incident tickets highly integrated with other SolMan functionalities, e.g. creation from / assign. to Roadmap, Blueprint, Configuration, Monitoring, Test, ChaRM

4.3.1 Service Desk

• • Create a Support Message

• • Creation of support message directly in the satellite system à Automatic transfer of necessary data to Solution Manager (e.g. system, client, user, module, transaction).
• • Documents like e.g. screenshots of the error message can be attached to the support message
• • Process Message

• • Service Desk in SAPGUI or via WebFrontend
• • Transaction CRM_DNO_MONITOR
• • Analyze the Error Message
• • Assign Responsibilities
• • Search for and apply OSS Notes
• • Forward Messages to SAP Active Global Support
• • Send out emails to Requester based on status

4.4 Change Request Management

The SolMan Change Request Management (ChaRM) provides all functionality to govern and operate a system change scenario from the raise of a request for change (RfC) over the approval process to the implementation, test and transport management.

• • Covers all types of application changes:
• • Urgent live system corrections
• • Periodic SAP system maintenance
• • New software release implementation
• • Roll-out based system adaptations
• • Supports workflow based role scenario with different roles: Requester, Change Manager, Developer, Tester)
• • Integrates seamlessly with the Service Desk (B03)
• • ChaRM is SAP’s answer to the ITIL Service Support Change Mgmt. scenario: ChaRM is ITIL compliant
• • ChaRM provides an overview over all RfCs and change implementations within the entire system landscape

Prerequisites:

• • Solution Manager Project set up (Template, Implementation or Maintenance)
• • Configured System Landscape (X01)
• • Configured Transport Routes in all satellite systems

Benefits and Value:

• • Complete integration with Service Desk to enable efficient and effective production support
• • No system changes can be transported to productive systems without appropriate approval (recommended setup)
• • Complete history log available for all system adoptions
• • Import of changes via maintenance and project cycles
• • Controlled system change implementation, testing and transportation procedure supported by an end-to-end change management workflow

4.4.1 SOLMAN Screens for ChaRM

5. SOLMAN Integration with 3rd Party Tools

The following diagram shows the possible SOLMAN Integration with 3^rd party tools.

6. SOLMAN Summary – What functionality and which phase?

The following diagram shows which aspects of implementation and operation functionality can be leveraged in which phase of the project as a summarized view.

About the Author

Ken Asher holds a Masters degree in Engineering, Mathematics, and Computer Science. He has over 17 years of SAP experience and has worked as an SAP America liaison to various clients to resolve critical architecture and solution issues throughout his career including during his time with Andersen Consulting/Accenture.  Ken was also a member of SAP’s ATAC team for advanced technical application consulting.  He has a deep understanding of SAP architecture and has worked with all of the latest SAP technologies.  In many of his previous projects he has been responsible for reviewing and recommending strategy as well as project planning for SAP clients including GMAC, Raytheon, and MIT.  Ken is currently deployed by BayForce to assist Amtrak with multiple ongoing projects including one of their largest initiatives for Strategic Asset Management.

To contact Mr. Asher or discuss how we can assist you with your upcoming projects, please call Kim Snow, Vice President of Delivery at BayForce, at 813-908-8593 or send an email to ksnow@bayforce.com.

Client

Click on the icon above to download this article as a PDF.

Jason Finishing Group is a global brush manufacturer with production facilities in 12 countries and customers in over 100. Their brushes are used for hundreds of applications in the manufacturing finishing process to improve repeatability and cycle times. In 2009 Jason Finishing Group implemented SAP with the assistance of a Big 4 integrator. The same integrator provided post go-live support utilizing an off-shore support model in addition to Jason Finishing Group’s own internal support team consisting exclusively of Super Users.

Challenge

Jason Finishing Group faced a number of challenges associated with their SAP support model. Internal bandwidth was extremely limited due to the small number of internal Super Users. The internal team also lacked the practical SAP knowledge and experience required to support such a complex SAP implementation without risking day-to-day business operations.

Jason Finishing Group also faced increasing issues with their SAP Support Provider’s off-shore model. SAP support was adversely affected as issues with time zones, communication barriers and business process knowledge for this mid-sized manufacturer became increasingly frustrating and time consuming.

Additionally, Jason Finishing Group identified gaps in their SAP system (specifically in their financial reporting capabilities in COPA and BI) that needed to be addressed quickly.

Solution

BayForce was initially selected to fill the gaps identified in Jason Finishing Group’s SAP system due to the fact that our Platinum-level Consultants are experienced with multiple years of practical SAP knowledge, possess exceptional communication skills (both written and verbal), possess business process knowledge and were able to understand Jason Finishing Group’s unique needs.

BayForce was able to provide Jason Finishing Group with Platinum-level remote support at a significant cost savings that was flexible and based on their teams availability as to not disturb their normal working process. In phase 1 of this project, BayForce was able to deliver this functionality before their fiscal year end and prepare the road map for their global reporting template.

Jason Finishing Group’s Executive Team was so pleased with BayForce’s ability to complete this project on-time and on-budget with minimal disturbance to day-to-day business operations that we were asked to become Jason Finishing Group’s exclusive SAP service provider.

BayForce has gone on to provide Jason Finishing Group with our SAP Managed Services Solution (BayForce Remote 360) which encompasses a complete family of support solutions that are completely customized to their unique environment offering Jason Finishing Group true three hundred and sixty degree support, covering their Basis/Netweaver, Functional, and ABAP support needs.  Jason Finishing Group is now able to leverage BayForce’s “Always On” Emergency Production Support, Dedicated Remote Support Teams, and our U.S.-based Platinum-Level Consultants.

BayForce immediately set up an SAP Early Watch Session and provided Jason Finishing Group with an executive summary of recommendations detailing improvements that could be made to greatly improve the efficiency of their ECC and BI environments.

BayForce has gone on to make a number of significant, proactive, changes and upgrades to Jason Finishing Group’s SAP environment such as a reimplementation and upgrade of Solution Manager, Support Pack implementations, and a QA environment refresh.

Why BayForce?

BayForce, a Certified SAP Services Partner, has focused exclusively on providing SAP services since 1996. Our service offerings encompass the entire SAP suite and include (but are not limited to) full lifecycle SAP Project Services, SAP Managed Support Services, and Staff Augmentation.

BayForce was not selected based solely on our ability to deliver Platinum-level consultants that deliver consistent results, posses years of practical experience, and possess exceptional communication skills.  We were also selected because we take a holistic approach to meeting our clients’ unique business requirements, including developing alternatives to business issues not identified during the initial selection process. BayForce’s ability to provide a combination of remote and onsite support, and our commitment to ensuring that internal teams are acclimated with changes to the technical environment through knowledge transfer, also weighed heavily in the decision to select us as an SAP service provider.

Another determining factor in BayForce’s selection by Jason Finishing Group was our flexible SAP Managed Services Solution (also known as BayForce Remote 360).

BayForce’s SAP Managed Services offer a robust portfolio of completely customizable services that cover all of our client’s Technical and Functional support needs. Clients are able to take advantage of our U.S.-based, Platinum-level resources while ensuring their SAP environment is monitored and maintained 24/7. BayForce’s Managed Services are available at varying levels of commitment and can be customized to fit any budget without sacrificing service integrity.

Our Managed Services ensure “Steady State Operations” by offering a wide range of services such as 24/7 emergency support, system monitoring, proactive troubleshooting and error resolution, transport management, performance tuning, support stack applications, and landscape refreshes among others.

BayForce’s dedicated remote support team model provides a depth and breadth of experience and knowledge unattainable with individual consulting models, while providing our clients the continuity of resources to ensure your support is being provided by resources intimately familiar with our client’s individual SAP environments, policies, procedures, and internal support teams.

Benefit

BayForce’s approach to meeting the business needs of Jason Finishing Group quickly established BayForce as a partner upon whom Jason Finishing Group can depend. The routine process improvement efforts allow Jason Finishing Group to recognize continued operational excellence not just internally, but throughout the entire SAP landscape.

Contact Us

If you are interested in learning more about our SAP Managed Services or another of our other SAP Services (such as Staff Augmentation) please contact us using the information below:

Contact: Kim Snow, Vice President

Email: ksnow@bayforce.com

Phone: 813-908-8593

As part of this initiative, BayForce was tasked with creating Profit and Loss statements via New General Ledger, Profit Center Accounting and Profitability Analysis. The deliverables covered a 12 week timeline to install PCA within a New GL implementation, as well as align CO-PA characteristics and value fields to provided Business Intelligence and OutlookSoft information structures. Document Splitting and Profit Center Accounting integration played a central role in the project that also included multiple Make-to-Order, Make-to-Stock and Assemble-to-Order business scenarios were revisited and some were redesigned to apply a SAP Best Practices approach and to ensure an efficient business process.

The existing pre-configured system install leveraged the quick setup approach. This approach successfully provided access to SAP business processes, but lacked the report design needed to manage the details on the Profit & Loss. Changes in the control measures were necessary to allow an ease of use which presented a challenge in report structures and necessitated a change to a more controlled environments. Several major business practices were adapted to ensure compliance with the corporate directed reporting logic.

The result is that JFG now has a system which provides a consistent Profit & Loss from the Financial Statement Version, through a PCA Profit & Loss by Profit Center and an organized CO-PA set of value fields. This alignment will allow the population of the OutlookSoft consolidation system.

Due to the previous lack of documentation, heavy emphasis was placed on documenting each phase of this initiative. During user and customer acceptance testing, a step by step testing model was developed for each effected business process which has allowed the users access to a training model for future employee re-training and new hire education.

The successful delivery of this project has led to an additional phase in which JFG will integrate the SAP Planning modules. This phase of the project is currently underway.

Regardless of an up or down economy everyone wants to get the most value for their dollar; particularly in the IT space where costs continue to rise. There are always more projects to be done than a company can reasonably afford. The more mature your SAP environments become, the more changes, upgrades, and enhancements, your company needs to make. SAP is always rolling out additional modules, support packs and new versions.

Every business sponsor would like to believe that their SAP environment has been built in the same manner and approach as a master carpenter who builds their own home – using the best materials and paying attention to every painstaking detail until the home is finished. Then for the next 20 years the builder provides enhancements to the structure, sparing no expense on maintenance, upgrading rooms, and keeping up with the latest trends in home improvement.

The reality is, however, that many SAP projects are underfunded and planning isn’t always perfect. Many details of the implementation are left until the proverbial “Phase Two”. This cleanup phase often never comes for a variety of reasons. Sometimes attention and money is turned to new technologies or pressing projects. Often there is turnover in expert staff without proper knowledge transfer. As of late, changing market conditions have caused a shift in priorities away from IT projects. Instead, there has been a greater emphasis on making what is already in place last a little longer and work a little better. Paying for SAP does not stop after the initial implementation. Making changes to an existing landscape, upgrading, and adding modules or instances comprises a bigger part of the IT budget at most companies. For the most part everyone understands the need to control “changes” and ensure that these changes are compliant. SAP like many other ERP systems is an integrated solution. It is not enough to manage changes by making sure they fall within compliance guidelines.

One of the outcomes of the introduction of the Sarbanes-Oxley Act of 2002 focused organizations toward compliance and controlling changes in their IT environment. This adherence to compliance helped to stabilize environments to some extent. During the early 2000’s companies spent a lot of money and energy into becoming compliant and putting controls into place. Every change introduced to the system has the ability to “break” the system. The amount of changes and the speed at which change is introduced is directly proportional to disruptions in service and downtime. Because SAP is so integrated one can follow all of the compliance requirements and pass single objects (change requests) through all testing and pass, yet still have problems once they reach production. Hence, the need to package sets of changes, the need for Release Management.

What is Release Management?

iRelease Management is used by the software migration team for platform-independent and automated distribution of software and hardware, including license controls across the entire IT infrastructure. Proper software and hardware control ensures the availability of licensed, tested, and version-certified software and hardware, which functions as intended when introduced into existing infrastructure. Quality control during the development and implementation of new hardware and software is also the responsibility of Release Management. This guarantees that all software meets the demands of the business processes.

The goals of release management include:

• • Planning the rollout of software
• • Designing and implementing procedures for the distribution and installation of changes to IT systems
• • Effectively communicating and managing expectations of the customer during the planning and rollout of new releases
• • Controlling the distribution and installation of changes to IT systems

Release management focuses on the protection of the live environment and its services through the use of formal procedures and checks. A Release consists of the new or changed software and/or hardware required to implement approved changes.

In common terms Release Management is simply this:

Organizing a set of desired changes into one concise cohesive work package whose components can be developed together, moved to the quality test environment together, tested together, and then moved to production as one change (release).

The Manufacturing Analogy – W.I.P.
Whenever I talk about Release Management I relate to it in terms of a simple manufacturing process. Orders or changes come in as separate pieces like materials coming into the front end of the process (such as a funnel). The changes (materials) are sorted out in some priority fashion and sent through the landscape from development to test and into production much like “Work In Process” phases of the manufacturing process. If one were to develop parts of a machine using metric measurements and another set of parts using American Standard measurements, the two sub-assemblies obviously would not come together in final assembly. It works the same way in integrated ERP systems like SAP. You can manage individual changes, individual modules, individual projects, but sooner or later they get integrated and rolled into your total solution. Unless they are developed and tested as subassemblies you can have a problem when they become part of the complete solution. See the diagram below:

The Problem with Managing individual Changes

There are three key problems when managing individual changes in a complex ERP integrated environment: “code collisions”, incorrect prioritization, and improper utilization of resources.

For example, let’s say I am managing independent changes and I introduce a change to the test environment on a Tuesday and test it and the change works. I then introduce a change to the test environment on Thursday and this change also works. However, the change I made on Thursday caused some failure to the change made on Tuesday. I would not realize this failure until it showed up in the production environment (i.e. a “Code Collision”). A Code Collision is an error which could cause system downtime or causes problems for the customer including potentially costing the customer money to untangle (locked tables causing automated jobs to stop in their tracks etc.). If I had, instead, held the first change and then moved the two changes into test together, I would have found the “code collision” and been able to correct it in the test environment.

The second issue caused by managing individual changes is improper prioritization. As changes come into the funnel they are prioritized. When individual changes are requested there is a tendency to work on what is perceived as most important rather than what may benefit the organization as a whole. To coin a few terms “the squeaky wheel gets the grease” and ”whoever has the most money gets the service” (The Golden Rule). My personal favorite – “your lack of planning does not necessitate an emergency on my part”. I am sure we have all worked in environments where this is the perception of how work gets prioritized and resources assigned.

The third issue with managing individual changes is an improper allocation of resources. Many times a report request will come in from one division and a developer will be assigned to complete the coding. Another developer in another work area may be doing a very similar report with the same data. It is possible the two reports could have been assigned as one using different variants. Unless the developers are talking independently with each other this waste of resources often goes undiscovered. Perhaps there is a better way to gain some synergies.

Managing Changes as a group – Release Management

When you begin to look across all of the changes that are coming into the IT organization you can begin to see logical groups of changes (i.e. this set of changes are all reports that may contain some of the same data, perhaps they can be developed together realizing some synergies). The next set of changes are all for one division so we can tap the business resources for one period of time rather than constantly going to them for testing and SME time. Another set of changes will require a hardware upgrade, so the hardware upgrade will need to be expedited to align with all changes that are better served to be done after the upgrade is complete, etc. You can begin to create sets of changes that will reap the benefits of synergies – consistent development without overlap, better scrutiny in regard to correct prioritization and enhanced testing to prevent code collisions in production. See diagram below:

You might think that this discipline is intuitive and it would be natural to assume that your IT organization is automatically working in this way. However, more often than not, IT shops manage changes on an individual basis and only to the level that is required to be compliant.

For a variety of reasons IT organizations tend to be reactionary. Advances in technology are happening more quickly. Mergers and acquisitions are more frequent and system changes to accommodate those transitions come with little or no advance warning. SAP is shifting from a module based focus (MM, SD, PP, FI) to a more process-oriented view (Order to Cash, Procure to Pay) etc. However, skill sets and development teams are largely still aligned in the more silo construct organized by module area. Managers tend to still react, staff, and organize work in that silo, module, and non-matrix fashion.

Moving to Release Management requires a paradigm shift throughout the organization. The Organizational Change Management accompanied with this shift should not be underestimated. Even though it requires a great deal of shepherding, it is worth the effort.

What are the Benefits of Release Management?

Release Management done properly can create some obvious benefits and some that are more subtle. The obvious advantage of working in a release management strategy is moving changes together through the landscape. One can define specific work tasks and define a timeline that can be managed, thus reducing the cost of “wasted” time in organization and planning (i.e. developers randomly hopping from one fix to the next trying to accommodate shifting priorities). Once a release is set everyone knows the priorities. Only true emergencies can be moved into the release so there will be careful scrutiny. The second most obvious benefit is that objects will be tested together in your quality environment. This testing reduces the risk of failures in production as described in my earlier example. Another benefit is the reduced cost from less errors occurring in production. There will be less backing out code and correcting bad data, reprocessing orders and related work that I call “do-overs”.

Some benefits that are not so obvious can be the synergies obtained from the entire team viewing the system as a whole. Once you move to the release concept you will notice more dialogue around correctly prioritizing changes; performing additional testing; checking to see that infrastructure needs, storage space, and security questions are answered ahead of time instead of at the 11th hour. All of this dialogue leads to better performance from your delivery teams.

Some benefits that are not so obvious can be the synergies obtained from the entire team viewing the system as a whole. Once you move to the release concept you will notice more dialogue around correctly prioritizing changes; performing additional testing; checking to see that infrastructure needs, storage space, and security questions are answered ahead of time instead of at the 11th hour. All of this dialogue leads to better performance from your delivery teams.

Are they in the pipeline? Are they poised to move to production? Once you establish a release calendar everyone knows when the next move to production will take place.

How Do I start Release Management?

I approach moving from a change/control management discipline to a Release Management discipline in three steps. I will go back to the manufacturing analogy for a moment.

1. Step 1) Secure the pipeline.
2. Step 2) Rearrange and manage the funnel.
3. Step 3) Enhance both the pipeline and the funnel (process and architecture).

These three steps are counterintuitive and here’s why. It would seem to make more sense to start at the top by organizing changes as they come into the funnel, building relationships across the business areas and building bridges into the IT organization then building out your landscape and infrastructure to match how you plan on developing releases, and finally, ending with actually moving releases through this well-defined structure and process as a release. From a process standpoint that makes sense. But the reality is that you are processing changes every day. More changes are coming in all the time, and as stated earlier, you cannot underestimate the organizational change management needed to shift the paradigm and recover from perhaps some already poor relationships between business and IT.

In addition, many company’s first reaction is to go out and find a tool that can perform release management. Some comprehensive tools can be brought up with minor configuration in order to manage changes, build releases, and do it automatically. I highly advise against considering tools until much later in the game. You cannot hope that a tool will take the place of a sound process or that it will fix bad will.

In addition, many company’s first reaction is to go out and find a tool that can perform release management. Some comprehensive tools can be brought up with minor configuration in order to manage changes, build releases, and do it automatically. I highly advise against considering tools until much later in the game. You cannot hope that a tool will take the place of a sound process or that it will fix bad will.

Now that you are forming an organized queue that will allow you to present future target dates to the business, you can establish a calendar based on how fast requests come in and the type of resources you have at your disposal. Also take into consideration what the business will tolerate. You may prefer to move to quarterly releases but that may be too big of a paradigm shift and you will have to settle for monthly releases. After a few on-time moves to production you will have restored some confidence between business and IT. You have now “Secured the Pipeline”.

Step 2: With confidence levels rising you can now begin to work on the funnel. Organize requests that have already been submitted to your organization. Reconnect with the business and begin to build bridges talking about effective prioritization. Organize IT managers so they are looking across all of the changes coming into the IT organization rather then looking at just what is in their individual queue. Once you have re-arranged the funnel and how managers view the work, you can now manage the flow of information coming into the funnel.

At this point you can begin to look at what types of releases you may wish to produce. Do you organize releases by process area, by division, by project types? Do you treat projects as separate releases independent of operational-type changes? How you organize releases depends largely on how you work the relationship between business and IT. Once your changes are coming into the funnel and being assigned into specific releases you have completed step 2.

Step 3: Enhance the pipeline and Funnel (Process and Architecture). Finally, you can consider how to enhance the manual process you have built. Enhance aspects of both the funnel and the pipeline. Maybe now you can consider creating some N+1 landscape architecture or perhaps an alternate production path for low impact changes vs. long term projects. Maybe you increase the type of testing or enhance testing with automated tools. You can investigate how to streamline the process in which changes are brought into the IT area (a single path for entering changes). Now is also the time to look at tools that can automate some of the workload in regard to change management. SAP Solution Manager CharM? There is no point in doing this, however, until you have a manual process that works. Automating a mess creates an automatic mess.

So in summary the three steps in effectively beginning release management are:

• • Secure the Pipeline (manage what is in the process)
• • Re-arrange and Manage the Funnel (control the front end)
• • Enhance the Process and Architecture

What Are the Pitfalls of Release Management?

Moving to a Release Management discipline has some drawbacks at first. It is a paradigm shift that requires organizational change management. Once you overcome the initial resistance you will raise confidence by producing fewer errors in production. The business units will be happier with the IT organization, developers will find the repeatable process easy to work within, and testing will become more comprehensive.

The hazards are that there will be an initial resistance from the business when you tell them you need to slow moves to production. The knee-jerk reaction can be “you mean to tell me I have to wait weeks just to put in a two line code change?” You may also get a backlash from developers who contend it is easier to deal with changes as they arise rather than treating changes as a group. You may also expect dissension between development teams. The thinking initially may be, “we are already organized better and work faster than so-and-so group – we can’t wait for them! “Our” process is too different”.

As is always the case there will be requests that come in late from the business that must be done. Priorities will shift based on the market, the season, or economic climate. Mergers and acquisitions will happen. People will move in and out of roles. Larger projects will threaten your ability to control the release timeline. There are answers for these objections and other objections you may think of that will probably be raised; ones that I haven’t mentioned in this paper.

Summary

1. SAP is too complex and integrated to continue moving changes individually.
2. Release management requires effort in Organizational Change Management.
3. There is a three step process to effectively starting Release Management.

• • Secure the pipeline
• • Rearrange the funnel
• • Enhance the process and architecture

4. The benefits of Release Management include

• • Lower costs per change
• • Fewer production errors
• • More comprehensive testing
• • Better prioritization of work

i The description of Release Management is taken from the following: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

About The Author

Jim Gerber is a PMP certified project Manager with 15 years IT experience. He holds a Bachelor in Business Administration from Carthage College, Kenosha Wisconsin. He has played a variety of roles in SAP from Developer to Project Manager. Jim is currently the SAP Release Manager at a Global Pharmaceutical Company.

To contact Jim Gerber or discuss how we can assist you with implementing a Release Management strategy, please call Kim Snow, Vice President of Delivery at BayForce, 813-908-8593 or send an email to ksnow@bayforce.com.