The allover Requirement-to-Deploy process in Solution Manager 7.1 and 7.2 spans from project preparation through a discovery process in business, ending up in creating business requirements prior to handing the project over to the IT department. I describe the end-to-end Requirement-to-Deploy process as delivered as of the Focused Build for Solution Manager solution within Solution Manager 7.1 and 7.2. The Focused Build solution provides a requirement process that is deeply integrated into a newly delivered release management process. The integration into IT Portfolio and Project Management (ITPPM) projects is the basis of dashboard-driven progress analysis, such as milestones, waves, sprints, and requirement progress.

Different than Change Request Management (ChaRM), the application comes with many functional enhancements, dashboards, and SAPUI5 components. After a process description, the main customization is shown enabling ChaRM users to adjust the Focused Build solution to their company’s needs. The table at the end of the article shows the main functional differences between ChaRM and the Focused Build solution.

I cover functionality available in the Solution Manager 7.1 Focused Solution Support Package 14, and also provide details about the Solution Manager 7.2 Focused Solution Support Package 3, which is to be delivered as of November 2016. Since Solution Manager 7.1 runs out of maintenance at the end of 2017, the screenprints in this article are exclusively based on 7.2.

Requirement-to-Deploy Process Flow Overview

Figure 1 shows the Requirement-to-Deploy end-to-end process flow as it is set up out of the box if the ST-OST Focused Build solution is implemented. (The technical name of the Focused Build solution Add-On is ST-OST.) Discovery teams create the ongoing requirements in business units. If they are signed off from a business perspective, the requirements go to the IT department. The project management organization plans IT projects, related budgets, schedules, and resources. Projects are then structured into waves, and within each wave there are sprints, if a lean-development approach is embraced. The project goes to build teams that convert the project into work packages. The work packages are assigned to an existing project and then to a wave within a project. The work packages are further divided into work items, which are assigned to sprints. The build team in development executes on work items by creating code and configurations during a sprint time frame. By assigning work packages to project waves and by assigning work items to wave sprints, test signoffs can be managed for sprint-related unit testing as well as for wave-related functional testing. The test management organization manages tests after each wave, providing finalized work item implementations as well as when a release is planned to be built and prepared for production. During testing phases, test defects and defect corrections are managed by the test-and-build team until a final signoff is given by the project team, test team, and release management team. The release management team finally bundles ready-to-be deployed work item content and deploys it to production. A hypercare phase extends beyond the go-live date until a deployed solution meets defined stability measures and the release is finally operational and ready to be managed by the IT Service Management (ITSM) operations team. Figure 2 shows how an ITSM-based request for change (RfC) is integrated into ITPPM for ensuring compatibility with ITPPM resource planning. The Requirement-to-Deploy process integrates innovation projects and ITSM operational support by introducing business requirements, work packages, and RfCs. Whereas work packages are linked to project waves manually, the ITPPM project integration of the RfC is executed in the background and is not visible for a change manager. It keeps ITPPM projects in sync in regards to resource demands and consumption. Both work package-driven work item execution and RfC-driven change execution are linked to the release management application. Process modeling and solution documentation are integrated into business requirement management, work packages, work items, RfCs, and change or defect corrections.

Solution Readiness Dashboard for the Program Office

Project management members can monitor and evaluate the progress of the Requirement-to-Deploy process via a Solution Readiness Dashboard. All aspects of project execution from waves, sprints, tests, milestones/Quality-Gates (Q-Gates), work packages, work item statuses, and risk and issue statuses are provided. Figure 3 shows the tiles of the Solution Readiness Dashboard. The Solution Readiness Dashboard is based on a data model generated by the execution of program /SALM/DATA_EXTRACTION_PPMITSM. The Solution Readiness Dashboard is an SAPUI5-based application. Figure 3 shows the Scheduled Progress view. Next to an overall rating of a ITPPM project, it gives the next Q-gates and a details view on all subprojects and their statuses. All transactional progress related to the ITPPM project is displayed, such as Work Packages, Work Items, Functional Gaps, Risks, Issues, and Scope Change. The Requirements Backlog tile interprets work packages as being open or in work. The Schedule and Current Wave Progress tiles relate to the project structure elements, such as waves, sprints, cross testing, and work packages, being executed. Functional Specification, Technical Design, Development, and Unit Test evaluate on milestones reached, statuses being set, and documents with document statuses being provided in work packages and work items. Figure 4 shows the scheduled progress of work packages related to an ITPPM project wave. Figure 5 shows the number of work packages and their relationship to waves and process areas to which they are assigned. Figure 6 shows the number of work items and their relationship to Workflows, Reports, Interfaces, Conversions, Enhancements, Forms, and Authorizations (WRICEFs), and process areas to which they are assigned.

Release Dashboard for Release Management Operations

The Release Dashboard is based on the same data set as the Solution Readiness Dashboard. Different from the Solution Readiness Dashboard, the Release Dashboard allows an overview of release-related work packages, work items, defect corrections, and transports in systems from a release management point of view. The header tile detail views allow an overview of releases, development teams, systems and related work packages, work items, defect corrections, transports, and systems. Projects are not taken into account. Figure 7 shows the tiles of the Release Dashboard. The top areas give an overview of the number of releases of one release class in Solution Manager 7.1 (release component in Solution Manager 7.2) development teams, and the systems of the release landscape. The lower part provides insights into work packages/work items, defect corrections, and transport requests statuses in related systems. Figure 8 shows the Release detail view. Figure 9 shows the Work Packages detail view with the overall rating and all related attributes. Navigation into the transaction is available. Figure 10 shows all transports and their statuses in systems-clients including their relationship to work items and work packages.

End-to-End Process Description

During the business-discovery process, process modeling is used to create requirements. In Solution Manager 7.1, requirements are created in a third-party Signavio process modeling cloud solution, as shown in Figure 11. Whereas Signavio is a third-party tool, Solution Manager 7.2 provides the process modeling capability as part of standard Solution Manager, as shown in Figure 12. The business-discovery phase ends up with the sign-off of business requirements that then will be transferred into work packages. Whereas in Solution Manager 7.1 business requirements are mapped to a separate repository, Solution Manager 7.2 represents requirements as a separate Customer Relationship Management (CRM) transaction type being created out of process modeling. Any signed-off business requirement is finally mapped to one or multiple work packages with an N:M cardinality. To do so, the solution architect gets a grid application that allows a mass transition of business requirements to work packages. With N:M cardinality, each requirement can be mapped to M work packages, but also each work package can assign N requirements. Figure 13 shows the grid application that allows you to execute a business requirement to a work package transfer. Whereas in Solution Manager 7.1 an SAP List Viewer grid is used, in Solution Manager 7.2 a Fiori app is provided for the transition process as well as for all mass activities, such as work packages, work items, or defect-correction mass maintenance. Next to the grid shown in Figure 12, there are also grids allowing mass maintenance for work packages and work items, such as switching the status or assigning business partners. A mass-maintenance grid is provided for the purpose of maintaining the status, setting priorities, reassigning waves, or assigning responsible people to work packages (Figure 14).     A mass-maintenance grid (Figure 15) is provided for the purpose of maintaining the status, setting priorities and finish dates, reassigning sprints, or assigning responsible people to work items.     Business requirements are finally replicated to Solution Manager 7.1 as soon as the status is set to design completed. Within Solution Manager 7.2, a new process-modeling tool allows process modeling as well as creation of business requirements within Solution Manager. Business requirements are created as CRM transactions from within process modeling that will be transferred to work packages as soon as the design completed status is reached. Requirements that reach a defined status, such as design completed, follow up with work packages. Work packages are generated in a mass-grid application in an N:M cardinality, as is shown in Figure 13. If a 1:1 cardinality between a requirement and a work package is configured in Solution Manager 7.2, the generation of work packages takes place automatically in the background.

Work Package and Work Item

Within the design process, solution architects are supposed to translate the user stories of the business requirements into functional specification documents and hand them over to developers within work items. Within each work package, the assignment of WRICEF qualifications, time-planning data, and the distribution of functional scopes to work items is met. The release is automatically inherited from the PPM project header or from the ITPPM wave (if one ITPPM project serves multiple releases). As a final activity executed by the solution architect, sprint, process structures, specification documents, WRICEF attributes, and development teams are related to each work item prior to work items being generated. As mentioned before, all user interfaces (UIs) for work packages and work items are based on SAPUI5 without disabling the WebUI capabilities. Thus you have a choice about which UI to take. For work packages there are two transaction types available. One is scope change and the other is work package. The scope change transaction is used for all business requirements being introduced after the discovery phase of a project is finalized. It allows you to measure the amount of effort arising from an extended functional scope after the first demand sign-off. All functional capabilities of the work package transaction apply to the scope-change transaction. Figure 16 shows the header of the work package in SAPUI5. The SAPUI5 application for managing work packages and work items represents all assignment blocks that are configured in WebUI configuration in the SAPUI5 tile. Figure 17 shows the assignment of processes and documents from solution documentation to a work item. Figure 18 shows the assignment of documents, processes, and business partners to work items, with the work package scope assignment where work items are to be created. As part of the work package and work item in SAPUI5, the DropDoc is incorporated, allowing a simple look-and-feel access to the solution documentation. The DropDoc is also available as a stand-alone transaction for managing solution documentation. The DropDoc is an SAPUI5 application that allows easy-to-manage solution documentation for developers.

Work Package and Work Item – Project Waves and Project Sprints

With ITPPM projects now an inherent part of the Requirement-to-Deploy application, project managers can view and maintain the distribution of work packages and work items to waves and sprints within their projects. As soon as a wave and a sprint are released, the development process can start, meaning that the status of work items can be switched to in-development status. Now transports can be created the same way as in standard ChaRM, and the development process can be executed up to a test-confirmed status (unit test confirmed). Figure 19 shows an ITPPM project with a phases build and a breakdown structure showing the wave, and below that the scope and sprint. On the right side, work packages are assigned to either Wave 1:Scope or Wave 2:Scope. Work package attributes, such as those shown on the right side of the view, can be maintained centrally by the project manager. Whereas the UI component of a work package is highly enhanced compared to a standard RfC, the UI component of a work item is closer to the standard change of ChaRM, excluding the fact that SAPUI5 UI is provided as an alternative to the standard WebUI. Different from standard ChaRM, work items have a status of handover to release. In addition, the new status can only be set if the related work package is already in test-confirmed status. A work package can only be set to test-confirmed status if all related work items have passed the unit test. Thus, for innovation projects, work packages can only be released to production when all related work items have passed the unit test, and the single functional test of the work package has passed. Figure 20 shows the work-item status dependency on work-package status. As soon as a solution architect assigns a project and wave to a work package, and sprints for each work item, the work packages and work items are visible within the project. The project manager can maintain attributes such as sprint assignment, priority, dates, and completion rate. A work package creates all its related work items at the status to be developed, as shown in Figure 21. The first work item set to in-development status sets the related work package status to in development. As soon as all work items are in the status successfully tested, the related work package status is set to successfully tested. The handover-to-release status of work items can only be set when the work package status is set to handover to release. This is only authorized by the project manager, team lead, or solution architect. The handover-to-release status of a work item is automatically set when the work package sets the status to handover to release. As mentioned in the introduction, work packages and work items are enhancements of the RfC and change of ST standard UI components as of Solution Manager 7.1. ST is the standard ChaRM component that is being enhanced. The enhancement framework is used to build work packages and work items in ST-OST. Figure 22 shows the work package UI component AIC_CMCR_H with the implemented enhancement /SALM/CRM_UI_ENH. As of Solution Manager 7.2, the UI components of a work package are implemented as a Focused Build solution with its own UI components that are inherited from the UI components of the RfC and the change of standard ST component. Figure 23 shows the work package UI component in Solution Manager 7.2 without the enhancement framework being used. You reach it via transaction BSP_WD_CMPWB. Figure 24 shows the work package UI component for the work package implementation of Solution Manager 7.2.

Test Management Dashboard

After project sprints are fully executed, work items are fulfilled up to the status of Test Confirmed, and work packages of a project wave have passed a single functional test, a save sign-off finally allows the project manager to hand over work packages. The work packages include all related work items to cross-wave and release testing (functional integration test, system integration test, and regression test). Figure 25 shows the test-management dashboard that allows you to assign and manage test plans in relationship to project phases. The mapping of a test plan to an ITPPM project task is done by a test request CRM transaction, as is visible in the last two columns of the grid. The new test-management dashboard allows you to organize tests in relationship to project phases, and to organize tests that relate to all processes/test cases assigned to project-phase-incorporated work packages. Test plans are assigned to project phases the same way that work packages are assigned to project waves. Whenever a project and a project test wave is assigned to a test plan, a test request is created in the background that creates a task within the project test phase, transferring status, date/time, and resource request data. In Solution Manager standard there is a test defect that can be created out of the text-execution UI. Next to the test defect there is a defect correction as part of ChaRM, allowing you to create and move transports. Both transactions are decoupled from each other. As part of the Requirement-to-Deploy application, both transactions are integrated and exchange data and statuses with each other.

ITPPM Projects – Release Management

Up to now I have described the Requirement-to-Deploy process from a work-package and work-item point of view, with work packages bundled in waves, work items bundled in sprints, and tests assigned to project phases. Now I look into project management and release management more from a project manager and a release manager point of view. Since I already assigned work packages to projects and waves, a release assignment was inherited from the project wave to work packages and work items. There are two project types. One is a single (master) project hosting the allover structure of project activities. The other is a nested project, with the header project for the program manager providing main timelines, milestones/Q-gates, and sub-build projects, providing structures for build activities (one build project for each build area, such as ERP or CRM). In the master project build project case, waves of the master project are mapped to waves of the sub-build projects. Depending on the size of a release, multiple projects, either single or nested, can be assigned to one release. In addition to assigning a release to one project with all related waves, releases can also be assigned on the wave level. Releases on the wave level can make sense if a project cannot finish all developments for a particular release, but there are plans to release non-finished work packages in one or multiple open waves in the next release. Also in Solution Manager 7.2, a wave with a next-coming release assigned is also required if work items that belong to a release cycle are not finished at the end of a release and thus need to be copied to the next coming release. Figure 26 shows a project structure of type master project with sub-build projects. Figure 27 shows a master project header in which phases of the master project are mapped to phases of the sub-build projects. Figure 28 shows a single project structure with all waves and sprints within the project structure and the release assigned to the project header. Figure 29 shows a release assignment redefined on the wave level. Work packages can be moved from one wave to another and work items can be moved from one sprint to another, centrally managed by the project manager. A solution architect or a development manager can reassign a wave or sprint as well from within the work package or work item directly, or by using the grid mass maintenance application for executing the changes. Within a PPM project, milestones can be defined by the project manager on the wave level for work packages or on a sprint level for work items. Milestone data is replicated from a project to related work packages and work items. Figure 30 shows a milestone date’s definition on the wave level that will be distributed to all related work packages. This way, milestones are replicated from IT PPM to CRM. As shown in Figure 31, the Focused Build solution delivers three predefined milestones as task types in ITPPM and date types in CRM for work items and work package, whereas two ITPPM task types and two CRM date types are defined for a test request. A test request is a transaction type that manages the communication between test management and ITPPM. Within ITPPM projects there are two more CRM transactions that can be assigned in addition to work packages and work items. They are risk and issues. Figure 32 shows the risk assignment within a project and phases, whereas Figure 33 shows issues being assigned to project and phases. Figure 32 shows the Category as Budget, the Risk Strategy as Mitigate, and the User Status as migration plan (MIP) Open. The Risk Severity, Risk Impact, and Risk Level are High. As noted earlier, Requirement-to-Deploy uses ITPPM projects especially for structuring waves, sprints, and cross-wave testing, as well as for managing milestones centrally. Risk management and issue management are other aspects of project management that are added. Figure 33 Figure 28 already showed how a release is assigned to a project header, and Figure 29 shows how releases are assigned to project waves. After the assignment of a release to a project header or project wave, the release is replicated to assigned work packages and the work package-related work items. In the next section I describe the release management process and how a release relates to projects, work packages, work items, and defect corrections, as well as how releases are managed. In addition, I describe how release management allows for deployment automation.

Release Management

Figure 34 shows the release management phases. Releases are either in the phases Prepare, Build, Test, Deployment Preparation, Deploy, Hypercare and Completed. The phases represent release management phases. Thus in the Prepare phase all design and development/configuration takes place whereas Build means the build of the release, comprising all finished work items. In Solution Manager 7.1 there is no Operate phase after hypercare, but Solution Manager 7.2 provides an Operate phase prior to release closure. The Operate phase allows assignment of an RfC for the release that is currently productive. Figure 34 shows a Solution Manager 7.1 release-cycle transaction. Future releases as well as releases in the design phase can be assigned to projects or work packages. Releases in the Design, Build, or Test phase also allow you to assign defect corrections. This is different from standard ChaRM, which only allows defect corrections to be assigned during the Test phase of a ChaRM cycle. The main misunderstanding is that the Build phase has something to do with software build. The meaning of the Build phase of a release is that no new development can start and any work package that is assigned needs to finish release handover prior to starting the test phase. This rule applies only for major releases, not minor releases. Within the Build phase all relevant work packages and related work items are collected and bundled for release test deployment. Releases can be hierarchical, thus defining a structure of a major and minor release sequence. Whereas major releases allow you to manage work packages, minor releases only allow the assignment of RfCs. RfCs can be created in a minor release in any release phase except in the go-live phase. Major releases in the Hypercare phase (and in the Operate phase as of Solution Manager 7.2) allow only RfCs, but no more assignment of projects or work packages. Releases can be planned in a release calendar. Figure 35 shows a release calendar as of Solution Manager 7.1. Figure 36 shows a release calendar as of Solution Manager 7.2. Release management supports the definition of a sequence of equidistant releases, such as monthly releases as well as major-minor release hierarchies. The typical use of release management in the context of Requirement-to-Deploy is that work packages only assign major releases, whereas RfCs only allow the assignment of minor releases and major releases in the hypercare phase (and operations phase as of Solution Manager 7.2). The major difference between Solution Manager 7.1 and Solution Manager 7.2 release management is that in 7.1 only one active release cycle exists. In Solution Manager 7.2 each planned release can have its own cycle. The release phase of a future release can be set at a maximum of to prepare, but not to any further phases. Different from ChaRM, even in Solution Manager 7.2 standard release management has only one task list for each landscape. Thus, in the case of a dual landscape, one task list exists for a major release landscape, and one task list exists for a minor release landscape. The two task lists operate for both active and planned releases for a minor and major release.

Deployment Automation

Release-management deployment always follows the status of work items in relationship to release phases and systems to which transports are supposed to be deployed. Imports can be scheduled for single systems-clients from the task list, especially for production imports. Deployment automation can be scheduled, especially for non-productive systems-clients in cross-cycle/task list/releases. Figure 37 shows a release task from within the task list of a release deployment. When scheduling the release import in the task list of system L71 client 804, all release phase-compliant transports that are related to release-related work items will be deployed to production. The release phase is checked. In Solution Manager 7.1, release-related work items are selected through their belonging to an additional document flow between release cycle and work item. In Solution Manager 7.2 only the status of the work item determines whether it’s ready for deployment. The collective import task in the task list allows you to import work items/changes with the preliminary status for production import in the status released for production. In addition, urgent changes can be imported with the status handover to production in case of a minor release. The Collective Import in Figure 37 thus allows you to import all work packages or work items in the status handover to production into system L71 and client 804. No release phase is checked for Collective Import. Figure 38 The deployment automation allows parallel imports into systems, but also allows you to sequence imports such as: All imports go into ERP, CRM, Supplier Relationship Management (SRM), and Supply Chain Management (SCM) first, then the Business Warehouse (BW) import is next. The import is executed against all systems that are configured as unit test systems-clients. The imported transports will be logged and the job automatically reschedules after 15 minutes. Downgrade Protection is on but downgrade-prone transports will be skipped for import. If the Downgrade Protection on check box is selected, the program checks whether there is any version conflict between objects to be deployed and objects that still reside in system buffers of the system landscape. Interrelationships of work packages are taken into account by the batch-import program if the parameters Enable Relationship Check and Check predecessors of Work Packages is selected. The same applies for Work Items/Changes in case Check Change Doc Predecessors is selected. If predecessors are missing, the import of the respective work items/changes is skipped. The automatic-deployment tool can also be used for ChaRM standard optionally. It is a mandatory part of the Focused Build solution. Different to standard ChaRM, in the release task list there are two import tasks, one called Release Import and the other called Collective Import, as shown in Figure 37. The typical use of Collective Import is the daily import of standard changes and urgent changes with the priority of high. If release management is used in a dual landscape with minor releases being executed in an N landscape and major releases in an N+1 landscape, retrofit can be automated similar to release deployments. Automatic retrofit is executed if no version conflict exists for a changed object in an N development system and in the N+1 development system. Customer experience indicates that up to 80 percent of retrofit objects are automatically retrofitted, highly reducing the workload for developers. Next I focus on those customizations that many users expect to be done. All customizing is preconfigured. Thus only the differences to the described process have to be configured.

Major Customization for Requirement-to-Deploy

The Requirement-to-Deploy application requires multiple mappings between PPM projects and CRM transaction types, such as work packages, work items, risks, and test requests, as well as between release and work packages, RfCs, work items/changes, and release cycles. Automatic deployment also needs to be adjusted to customer systems-clients as well status schema if the status schema is customized. All customizing settings are delivered as preconfigured as part of the ST-OST Add-On and provide a running application as described in this article. If transaction types are enhanced or the ITPPM project template structure is extended or changed, relevant mapping customizing might need to be done. The following list of customizing mappings are the most relevant for custom adjustments. Call transaction SM30 and then select table /SALM/BRITR_STAT (Figure 39). Figure 39 defines what requirement statuses are mapped to what work-package statuses. This is only relevant for Solution Manager 7.1 with Signavio used for creating requirements. For example, the status E0017 equals in development (build in progress). If the work package sets the status as in development, the predecessor business requirement status is set to build in progress. Within Solution Manager 7.2 the requirement is a CRM document and the requirement and work package status dependency are defined in CRM customizing for follow-up documents. Call transaction SM30 and select table SALM/APPT_TYPEV (Figure 40). Figure 40 shows how to map Milestone Type tasks in ITPPM to CRM appointment types in CRM. A CRM appointment type defines the date types within the date assignment block of CRM transactions. It shows the date types in S1CG (general changes), S1IR (scope changes), S1IT (work packages), S1MJ (normal changes), and S1IT (test requests) are mapped to the Milestone Type of IT PPM project tasks. Call transaction SM30 and select table SALM/V_ROLE_MAP (Figure 41). Figure 41 shows how to map the Role Type in ITPPM projects to a resource type in CRM. In ITPPM role types, define the type of user roles, such as Solution Architect or Project Manager or Developer, to which people are finally staffed. In CRM, resource types are an analog type that can be assigned to the resource-assignment block requesting resources for a work package or RfC. The maintenance of the mapping allows you to request resources from a CRM transaction to be copied to ITPPM as a demand for a certain role. Then, in ITPPM, people can be staffed for respective work packages or RfCs. Figure 42 shows how to map task types of ITPPM to transaction types of ChaRM, enabling you to generate ITPPM project tasks for respective ChaRM transaction types such as work packages. Call transaction SM30 and select table SMCP_V_MAP_RFCTS. Example: Task type /SALM/ITR is mapped to Trans Type S1IT Work Package. This allows you to generate a task within ITPPM projects for each work package that assigns a respective project with the task type /SALM/ITR configured. Those projects are project types Single and Build. Call transaction SM30 and select table MCP_V_MAP_STATS (Figure 43). Figure 43 shows how the status of CRM transaction types that are mapped to project tasks can also directly set the status of the related ITPPM project tasks. Figure 44 shows how to integrate test defects with defect corrections and map their statuses to each other. Call transaction SM30 and select table /SALM/FOLDOCMAPV (Figure 44). Call transaction SM30 and select table /SALM/TP_STA_CRM (Figure 45). Figure 45 shows how the test-plan status is directly linked to a test-request status. A test request is automatically generated if a project is assigned to a test plan within the test-management dashboard. The test-plan status sets the related transaction-type status, such as test-plan status NEW, that will create a test request (transaction type S1TR) with the status create (E0001). The test-request status, on the other hand, can be mapped to a project-task status as shown in Figure 43. Call transaction SM30 and select table /SALM/_C_ITR (Figure 46). Figure 46 shows how to configure the transaction types that are used on the customer side if the Focused Build solution-delivered transaction types are copied to a Z* namespace. If a standard S1* transaction type is copied and has to be taken as a work package, work item, or defect correction transaction, then it has to be maintained. If the status schema varies from the Focused Build solution, the status semantics must be adjusted to the new status schema numbers for the new transaction type created as a copy of the Focused Build solution transaction type. A mapping of status values for transaction types to their semantical meaning must be maintained. Call transaction SM30 and select table /SALM/_C_ITR_stat (Figure 47). Figure 47 shows what status is used in what transaction type to represent the semantic status, such as handover to release or IT scope finalized. The status semantics must be adjusted if the user changes the status schema. The adjustment is used in all dashboards. Example: S1IT as the transaction type for a work package has status E0004 for the IT scope finalized function. With reaching IT scope finalized within a work package, work items are automatically generated. The batch-import trigger program uses import strategies that need to be adjusted to the custom landscape. If the user changes the status schema for a work item (S1MJ), a defect correction (S1TM), or an urgent change (S1HF), then import customizing must be adjusted. Call transaction SM30 and select table /SALM/IMPCUST_V (Figure 48). Figure 48 shows a batch-import variant /SALM/UNIT_TEST and the respective status values that are taken into account for various transaction types, allowing the import into systems related to system role T. Figure 48 shows that import variant /SALM/UNIT_Test of System Role ID T will prepare the import of all transports related to transaction types and their statuses as shown in import-customizing status. The first status column (UsrST) shows the status that allows you to import its related transports into systems of type T, whereas the second UsrST status defines the status the work item is set to when the import is successful. Example: Transaction type S1MJ (normal change) with status E0017 (in repair) defines that transports related to it will be imported to systems of type T. When an import is successful, the status is set to E0004 (to be tested).

Standard ChaRM and Build Focus Solution Comparison

This comparison in Table 1 of the main features of the Focused Build solution with ChaRM shows what the Focused Build solution provides that is not part of ChaRM. However, it does not represent all the differences. The comparison is intended to help you make a decision about whether the solution described is relevant or whether standard ChaRM is sufficient.

Function	ChaRM	Focused Build solution
Work package and work item interdependency	Change has independent flow from RfC	Work item can only be released to production with all other work items together depending on the work package status
Work package and work items can interrelate to each other (predecessor, postprocessor, … )	RfC and changes cannot be dependent on other RfCs or changes	Work package and work item interdependencies can be used to control deployments as part of a batch import program
Master work package concept	No master RfC concept exists	Work packages can be part of a master work package. A master work package can control whether sub-work packages can move forward and thus controls whether deployment can take place.
Integration of ITPPM	An RfC can be created and assigned to an ITPPM project task. A resource request can be replicated from RfC to a task. Task-based resource management is used in ITPPM.	In ITPPM, waves and sprints can be managed with related release assignments and milestones. Release and milestones will be replicated from ITPPM structures to related work packages and work items. A resource request from within a work package or work item can be replicated to a task. Role-based resource management is used in ITPPM.
Defect correction usage	Defect corrections must be created in addition to test defects and are only operational during the test phase of the ChaRM cycle	Defect corrections are interrelated to test defects and can be actively used during prepare, build, and test phases of the release cycle
Release management	ChaRM does not have a release management capability as of 7.1 but can optionally use release management as of 7.2	Release management is an inherent part of the Build Focus Solution in 7.1 and 7.2
SAPUI5	No SAPUI5-based UI exists for an RfC or change	SAPUI5-based UI is available for requirements, work packages, and work items
Dashboards	RfC and Change Status analysis views exist. No Solution Readiness type of dashboard exists. A release dashboard is supposed to be released for ChaRM as of SP1 7.2 as part of the Focused Build solution.	A Solution Readiness Dashboard exists for management to analyze project progress and a release dashboard exists as an operational dashboard for a release manager and administrator
Deployment automation	No deployment automation exists other than a batch run of ChaRM cycle tasks	Batch import allows status-compliant deployments into all systems automatically, taking into account downgrades and dependencies. Parallel deployment into clients and systems is supported.

Roadmap Plans

Finally, if you plan to implement Requirement-to-Deploy in Q4 2016 or later, I recommend you do so with Solution Manager 7.2, although it is possible with Solution Manager 7.1. The maintenance of Solution Manager 7.1 ends at the end of 2017. On the other hand, if Solution Manager 7.2 is not available, you can evaluate and implement/configure Requirement-to-Deploy in Solution Manager 7.1 and then upgrade to 7.2. The migration effort after the upgrade is simple. Compared with a full ChaRM introduction, the application comes ready to run unless the best practice process does not fully fit a company’s needs. If companies need to enhance transaction types or change project structures, they have to execute the customization described in the last section.