Project Description
Make your S/4 transformation programme a success – Part 1, Explore Phase
SAP sell software. They generate revenue from license fees. So when SAP start giving away a major set of tools to their customers, it’s worth taking a closer look at what these tools offer. That set of tools is SAP’s Focused Build, a free add-on for Solution Manager to help their customers implement S/4HANA and on-premise/cloud hybrid implementations as easily and simply as possible.
That’s what this series of blogs is all about. A deep dive into the benefits of Focused Build for a Programme Manager who is about to embark upon a SAP transformation journey, but who doesn’t want to struggle as others have in the past and wants to make use of the best tools on the market to make this journey as smooth as possible.
Part 1 – Explore Phase. We look at how Focused Build supports the initial Explore phase, including project planning, requirements capture and supporting documentation, all via Agile techniques.
Part 2 – Realisation Phase. Managing project deliverables, documentation and SAP Transports doesn’t have to be as time consuming and painful as it has in the past. In this part of the series we will look into how this can be managed efficiently using Focused Build tools.
Part 3 – Deployment. You’re ready for go-live, but you don’t need to use spreadsheets to manage your deployment. Understand how Focused Build helps you understand your readiness and deploy your code with the minimum of effort to the production systems.
The rationale as to why Focused Build is now free is offered here – implementations were getting a reputation as costly and risky undertakings, and that image was in danger of harming the sales of software, SAP’s bottom line. By offering up Focused Build to make the whole enterprise more manageable, SAP is expecting the whole s/4 landscape transformation rigmarole will be quicker, cheaper and as painless as possible.
Focused Build – You too can be Agile.
From the narrow perspective of a project team member interacting with Focused Build, what they will each use on a daily basis is a handful of Fiori-based applications tailored to their different roles. Hard pressed project team members need not be experts in every step of the journey but only concern themselves on their particular “touch-point” with Focused Build. This is one way Focused Build simplifies. Developers, testers, business analysts and project managers each have their own uncluttered view of what a focused build is to them.
But for as easy and simple as the actual tool is to use, implementing complex projects is itself fraught with complexity “woven into” the endeavour. For this reason, Focused Build is an enabler of the Agile methodology for implementations. For those not familiar with this methodology, it is only necessary to know here that it tackles in a pragmatic, some say “agile” – manner the programme reality of changing scopes and looming deadlines. It does this by providing an internally consistent set of rules (the methodology) to allocate when a piece of work can be planned and attempted. The philosophy behind this approach is to encourage early testing and confirmation of all the modular components going to make up a go-live release before final integration testing. This bottom-up approach to testing and requirements sign-off is in contrast to the traditional waterfall approach, whereby the business typically only get insight into the solution being delivered during the official testing phase towards the conclusion of the project, with all the risks and drama that entails.
To achieve agile and role-specific implementation tasks, what SAP have done is to take several of the core components of Solution Manager (such as Change Request Management, end-to-end Solution Documentation, project task planning, Test Management, etc and brought them together in a user-friendly, project friendly and indeed ‘business friendly’ manner. One of the more innovative redesigns is a project dashboard that summaries key activities being performed by the users of Focused Build, thereby removing at a stroke the tiresome chore of updating the project plan with estimates of completeness.
Having said all this, new tooling can only go so far because the inherent complexity of project delivery still exists, although no longer in the task management. Where it now lurks is in the implications of all the clearly presented choices that must be made by the project team while using the Focused Build suite of tools.
- Good decisions need good information to base them on.
- Planning needs unambiguous setting and reporting of real-world milestones.
- Implementations need coordinated actions across the landscape.
Because of Focused Build these key success factors can be seen and tackled (As an example, se the Solution Readiness Dashboard above). These are the control levers for a Focused Build implementation that this blog will examine, starting with making good decisions based on good information.
The Explore Phase – laying the foundations
During the Explore phase, the foundation for the build activities is carved out of the bedrock of the business processes currently performed by the client.
- The Business Process Master List (BPML) is entered in the Solution Documentation as nodes in the business process hierarchy levels 1 to 3: Business Area, Scenario (grouping) and Process
- SAP Best Practices provide the accelerator for identifying the Level 5 process steps and corresponding Level 6 activities (transactions, Fiori Apps) performed by these processes.
This Explore phase foundation is achieved after two iterations:
- Solution Validation Workshops, where broad agreement is reached with what is in scope based on the definitions supplied by the SAP Best Practice scope items; the design down to level 3 of the process hierarchy; and what are the shortcomings of the SAP Best practices processes that need to filled in the next stage of workshops.
- Delta Design Workshops, a second iteration where the detail of the business process is fleshed out in terms of the activities performed by steps, and any WRICEF developments required.
It is during the explore phase that Focused Build is used to capture requirements either through an upload program, directly in Focused Build work centre by the business analyst, or via the process documentation attributes pane. Below, we will go into more detail on some of the most important Explore features that are supported by Focused Build.
The requirements capture screen is intended to be simple, with a minimum of mandatory fields. Three different text boxes are offered to capture details, but if these aren’t enough because a standard template is used, or diagrams or pictures are required, then attachments can easily be uploaded. This linkage is automatically filled if the requirement is created at the point in the Solution Documentation that it refers to. Now all documentation, both actual and planned, is documented with a requirement and the work package delivering it
In Focused Build, there are four different classifications of requirements:
- WRICEF: These are development activities driven by capability shortfalls in the standard software. The abbreviation stands for workflows, reports, interfaces, conversions (mass updates) enhancements and forms (both for input and output). They require a Functional Specification and Technical Design Document. Interfaces are handled separately in Solution Documentation, needing a linkage to the BPML for both definition and testing purposes.
- Gaps: Gaps are also identified by capability shortfalls in the standard software, but they are addressed by outside developments. An incident document is created when managing a gap, to better track the communication with a 3rd party. A special development requested of SAP is the original use case, but the most common example of a gap in an implementation project would be part of an interface development required by the owners of an external system.
- FIT: There is no coding adjustment, but only customising. The specification is often an existing standard configuration guide and only a customising document is needed in the Work Item.
- Non-Functional: Used for documentation upload or a parameter setting without the need for a SAP transport request to be generated.
When capturing a requirement in Focused build, in addition to those classifications above and the usual mandatory fields when creating a record, there is also a category level that can be assigned. This is freely definable and is used to help track or report on your requirements via the various dashboards and reports.
The Branch Concept – Exploration, realization and deployment document evolution.
The branch concept in Solution Documentation is a way of allowing one productive Solution Manager system (Production) to take responsibility for all documentation in the landscape environments simultaneously. Having the branches Design, Development and Production maps to the three project phases of Exploration, Realization and Deployment. Documents and designed process hierarchies can follow the real objects created in the transport path up to and including cut-over into Production.
Solution Documentation comes with just three branches as standard: Production, Development and Maintenance. Two more branches need to be created to map to Focused Build activities. SAP recommends a separate Import branch where the entire catalogue of SAP Best Practices is first imported, before scope selection and release into the parent Design branch for unpacking and structural alignment down to Levels to 5 of the business process hierarchy.
During requirement definition activities in the Explore phase, Solution Documentation is entered in the Design Branch. The processes given in SAP Best Practice serve as a baseline for the BPML. Once sufficiently detailed at the end of this phase they are copied into the Development branch where they come under change control (i.e. no changes allowed without assignment to an approved work package).
After deployment to go live, the entire set of documentation is write-protected in the Production Branch. To support maintenance of live objects, the maintenance branch allows documents to be to be changed independently of the same documents in any other branch.
The above may seem confusing/daunting, but again this is one of the advantages of Focused Build – As a Developer, who might be creating and storing documentation, you don’t need to concern yourself with this complexity. As you will see in a later blog, all the Developer or Functional Consultant needs to do is to ‘drag’ their document into the Work Package/Item screen and let the system worry about which branch should be used. In this way, Focused Build manages the version management of documentation automatically on your behalf.
Project plans designed to survive contact with reality
One of the more significant improvements in Solution Manager thanks to the Focused Build add-on is the assistance given to Project Managers to plan their projects. In Solution Manager 7.1 there was no project management capability to speak of, and with Solution Manger 7.2 the opposite extreme was made available with a fully functioning and licence-free Project and Portfolio Management application called IT-PPM. IT-PPM was in many ways similar to MS Project but lacked a reliable import functionality of project plans not built from the ground up with the SAP tool, limiting its appeal. With Focused Build, the user interaction with IT-PPM has been given a significant overall, making it immensely more useable because it is focused for implementing Agile project: managing units of work (waves and sprints), setting milestones and Q-gates, and tracking risks and issues.
A further improvement in usability is that the projects can be sub-divided into multiple sub-projects of a master project. With the Agile methodology positively encouraging project tasks being broken down into self-contained independent work packages without complex interdependencies, this approach makes it easy to de-centralise planning and control by functional area or product release.
With the project planning there are several key concepts to remember:
- A master project and all its sub-projects must belong to a single release. Release phases control what can be developed and transported across the landscape, so a release controls what is tested together and therefore the final make-up of what goes into Production.
- Work is divided into waves and sprints. In Agile terms a Wave is comparable to an “Epic”, and a Sprint to a “User-Story”. A wave can be considered a piece of work of around 8 to 12 weeks in duration and delivers a bounded and testable piece of functionality. Testable here means creating a measurable conclusion. At the end of a wave, a “show and tell” for user acceptance should be possible. Sprints on the other hand are more fluid, always belonging to the same parent wave, but small enough in terms of their maximum 10-day duration to have their dates flexed to suit variations in workload. Sprint completion needs only informal acceptance, a hands-off “look and feel” confirmation.
This blog has looked at the Explore phase activities of requirements gathering, process scoping and project planning. It showed Focused Build creating the foundations of consistent and aligned design information on which good project decisions can be based.
Follow the next two series of blogs, where we show how Focused Build coordinates all the implementation activities necessary for a successful implementation.
If you’d like to find out more about how Focused Build can help make your S/4 implementation project successful contact us here to arrange a no-obligation, hassle-free demo.
Leave A Comment