Let’s jump into the Requirements-to-Deploy primarily in Focused Build, as it will be one of the first topics we will address. If you are familiar with Focused Build or attended any of our previous presentations, there are 3 phases are: 1. Fix 2. Innovate 3. Enhance.

The Fix piece- this will be your work on day-to-day basis. For example, this is if you have any type of business disruption that requires changes in the PRODUCTION environment. You can use SAP standard Solution Manager to deliver those type of fixes. Within Change Management you might have an emergency change that you can deliver to the PRODUCTION environment immediately after the application became broken.

You may also use standard Solution Manager for Enhancement. Suppose you want to enhance a business process that is defined in the current PRODUCTION environment, you may use Change Management to go through a Normal Change. You can go through all of the approvals, make the necessary changes, test the changes, and then deploy it into PRODUCTION.

Within the Innovate aspect, if you have a brand new project, like Greenfield or migration, which requires changes to the processes or a transformation project, then Focused Build Change Management would be able to help. By introducing changes to the existing processes in order to create a new business process, may have you wondering how you would deploy and capture all the requirements? How can you report on all the changes that will soon Go-Live? Will the changes be captured in one tool?

When looking a Solution Manager’s Focused Build, you can realize the requirements, work packages, work items, and major releases- which are the primary areas that make up the Change and Release Management (ChaRM) in Focused Build.

Requirements Planning

Once the project is defined, it is handed over the IT and semi-Business team to capture the Business Requirements. In Focused Build, you have a full-blown Business Process Management within Requirements Management, which allows you to capture all of the Business Process flow-based diagrams. Otherwise they can be captured in the Process Hierarchy which are illustrated in sequential order.

All of the requirements captured in Focused Build can be seen directly in the Business Process Flows or Business Process Hierarchy. Even after you Go-Live or the requirements are realized, you can go back to the Business Process Flows to see exactly how the requirement are presented and delivered. You will have that full blown traceability upon capturing requirements through to delivery in the PRODUCTION environment.

Once the requirements have been captured, the Solution Architect and/or the PMO may then go through a back-log of approvals. There may be hundreds of requirements that are ranked by the highest value with the lowest effort. Breaking down the requirements in to Waves and Sprints would adhere to the Agile methodology by quick delivery of solutions. That way, if something does not add up at the end of the day, you can go back to redo the requirements to build the system into what is needed. “Fail quickly.”

Terminology Mapping Perspective

Focused Build  follows the SAP Activate methodology phases, you would go through a Fi-Gap analysis after all of the requirements have been captured. Once a backlog is approved, then you can take use of Work Packages, which is nothing more than a solution that is delivered to the business. Consider this as a functional solution that will be delivered, which captures the functional specifications based on the requirements. Once you have all the functional specs, then you can create a Work Item, which are work instructions assigned directly to developers, configurators, or anyone who is doing configurations in the new system.

Work Packages can be broken down into multiple Work Items, so that the work is balanced amongst the developers by breaking them down into smaller, workable chunks, and then assigning them to Sprints. The Work Packages are assigned to Waves and Work Items are divided into multiple Sprints: one wave could have 3 sprints. If Work Items are based in a sequence then we can use predecessors and successors to deliver the solution. The work can then be sequentially delivered as quickly as possible. 

Tracking of Requirement Status by Live Data

There is a Solution Readiness Dashboard that will show you all of the requirements that have been entered. At any given time, you can see which business-analysis requirements have been entered into the system. In most customer cases, they have multiple spreadsheets where everyone has captured and documented their requirements. Traceability can be lost in the number of requirements that have been entered- who created the requirements, where it’s been created, etc. This is all tracked and reflected by the Solution Readiness Dashboard to prevent unaddressed statuses and metrics for work progress.