Life Cycle Management
What it is,
Who can do it,
Where it can be done,
and, When?
What is Life Cycle Management?
Life Cycle Management is the process of managing the BPC environment to evolve with the business needs for consolidations and planning. Over time, changes will be required to allow BPC to continue to meet the needs of the business. However, there are rules to be followed regarding who can make changes, what types of changes they can make, and how they go about making the changes.
This document should help the business developers to understand clearly what changes they can make directly in Production versus what needs to start in the Development instance and be promoted through to Production.
Who can do what, and where?
SAP BPC is meant to be a business-driven solution to enable agility in the planning and financial close processes. Consequently, the life cycle management is intended to follow a methodology that supports this.
The tables below define whether actions can be performed in Production by the Business or by IT. In short, if the change requires a change to the structure of a model or underlying tables in BW, then these will be transported from DEV to PROD following the transport landscape defined by IT. If the changes are purely changes to data (master data or transaction data), then these can be executed in Production directly, by the appropriate business users.
Changes to be Made Directly in PROD (after DEV) (Performed by the Business Developers, according to Security Profiles) |
Environment Objects
Model Objects
|
NOTE: Individual user security changes can be made by a combination of the SAP Security team and the SAP BPC Admin team, at any time, directly in Production.
Changes to be Transported from DEV to PROD (Performed by the SAP BPC Admin Team and the Basis Team) |
Environment Objects
Model Objects
BW, Basis, and Other Considerations
Items for Deletion (rarely ever used or necessary)
|
Changes to be transported from Development to Production can be developed and/or tested by either business resources or IT resources. It is important to note, however, that these changes must be made in Development (and currently tested in Development, in lieu of a QA / Test instance) prior to being transported to Production.
NOTE: ABAP changes would be managed as they traditionally are in BW, including version comparisons between DEV and PROD
Timing of Changes
BW-Layer Transports
Transports that do not impact the business user community can be executed at any point in time, as the Basis team deems appropriate. Currently, this takes place on Thursday afternoons, after approval in the Change CAB.
BPC-Layer Transports
Transports that modify BPC content will require that the target environment (formerly referred to as Appset, prior to SAP BPC 10.0) be taken offline, prior to the deployment of the transport. Once the transport has been moved successfully, the target environment needs to be put back online.
Because of this impact to the business user community, these types of transports are currently deployed, starting at 3a Central, by our offshore Basis resources, typically on Friday, after approval in Thursday’s Change CAB.
Other Factors to Consider
Currently, the only other jobs scheduled in the SAP BPC solution that impact the ability to move transports are the Light Optimization routines that run each day, starting at 1a Central. They generally conclude by 3a Central.
Also, other maintenance activities, such as the archival of audit data or routine scheduled backups of the Production instance (via the UJBR transaction code in BW, specifically to backup or restore BPC content) may alter the window of availability.
Any specific instructions required to move a transport to Production will be explicitly documented in the JSOX document required by Change Management.
Emergency changes will be executed as needed, according to the nature of the emergency.