openSAP

Agile Project Delivery with Focused Build for SAP

Solution Manager (Update Q3/2021)
Week 3 Unit 1

00:00:06 Hello, and welcome to week three of this openSAP course about
00:00:12 Agile Project Delivery with Focused Build. My name is David Birkenbach,
00:00:17 I'm a solution expert at SAP for application life cycle management tools,
00:00:23 and I will be the host for this week. This week is about realization,
00:00:31 mainly focusing on the architects and the developers. So we will get to know how we will
transfer
00:00:37 the requirements that we have created in the previous week into so-called work packages, and
later on,
00:00:44 scope them down into work items. But, for this unit, we would like to start now,
00:00:51 how we're going to create, or how we're going to build, a new work package. First of all, we
would like to
00:01:03 start again with the big picture, with this best practice process that we have defined
00:01:08 within Focused Build. And you could see that we have passed already
00:01:12 the first two weeks with the project manager view, last week was about the process
documentation
00:01:20 from the business point of view, and in this week, we will definitely focus on
00:01:26 the view of the Solution Architect, and later on, also from the developers
00:01:31 or the consultants who do the configurations. The first part of that week is now
00:01:36 how we're going to create work packages out of a requirement, and then also we will see
00:01:42 how we're going to decompose a work package into smaller work items,
00:01:47 and hand them over into the development teams. The typical outcomes of these activities are
that we have to
00:01:55 create and have to take care of documentation, such as functional specification documents,
00:02:01 or configuration guides, or even we will start now producing test cases that we will later on
use,
00:02:08 also at the end of the waves, when we're going to start testing our work packages.
00:02:14 The activities I'm going to explain here are of the realization, are typically grouped in sprints,
00:02:21 so they will be repeated for each sprint. That does mean we will not have all the work
packages
00:02:27 available by the beginning of the project, but this will be an agile aspect of our work
00:02:34 that we're going to produce work packages all through our project life cycle.
00:02:39 Of course, after each sprint or several sprints, we will also have waves, and we will have
00:02:45 some additional activities that will happen at the end of a wave, which is mainly driven by
testing.
00:02:52 So this will then be explained in the next week. Let's recap a picture that I introduced already
00:03:01 in week one with you, which explains, from an SAP Activate perspective,
00:03:06 how we work with requirements and how these requirements will be
00:03:09 transferred into work packages. As this is really one of the crucial activities
00:03:14 in a Focused Build project, I would like to explain it quickly again.
00:03:20 So, first of all, the requirements that have been designed or defined in the two standard
workshops from the business
00:03:28 have to be approved, or of course also, estimated from an effort perspective.
00:03:35 So let's say we are starting here at this step number five, which is still in the responsibility
more of the business,
00:03:42 to approve the requirements. So this is really the scope for our project
00:03:47 that we will use in our work package. We only will look at those requirements
00:03:52 that have been approved. Whatever happens to the others,
00:03:54 if they are postponed or rejected, is maybe just a backlog for future waves
00:03:59 of future activities of the project. Now, we're going to look at those that are approved.
00:04:05 And those requirements that have been approved, will now be transferred into one or several
work packages.
00:04:14 And that's exactly the task then, which is more on the responsibility
00:04:17 of the architects or of the IT. Of course, this is always the case in close relationship
00:04:25 with the business guys, because it should be aligned with each other.
00:04:31 So, the backlog - our requirement backlog - represents the whole requirement list,
00:04:38 the backlog of our business. So we will now, as a work package owner
00:04:42 or the work package architect, take these approved requirements and we will
00:04:46 create work packages out of them. These work packages are now for the first time
00:04:50 assigned to a project, so the requirements are maybe across several projects,
00:04:56 but here, when we take it into a work package, we should definitely know in which wave
00:05:01 and in which project we would like to get it realized. So, this is definitely a must-do activity
00:05:09 that in the work package you have to assign a project, and also a wave. Also important is the
classification,
00:05:17 because the work package will later on give us guidance on what type of documents we have
to provide.
00:05:23 So from that perspective, we should decide if our work package will be treated like a
configuration, like a fit,
00:05:30 or is it something where we have to develop something in a smaller case like in a WRICEF,
00:05:35 or maybe in a bigger development case like a Gap. This classification will be done of course
then
00:05:43 on the header data of the work package. Also this picture was already shown in week number
one,
00:05:52 but it again explains the major story of Focused Build. We will transfer the perspective of the
business
00:06:00 from out of these Fit/Gap or Fit- to-Standard workshops into requirements, and from the
requirements,
00:06:06 we will do a transformation into a work package, and later on decompose the work package
again
00:06:12 into smaller, so-called work items that can then be realized in the sprints, and also, during the
sprint.
00:06:20 So this tailoring of work packages is really one of the crucial activities of Focused Build.
00:06:26 To do so, we definitely recommend that this should happen in cooperation between business
and the architects.
00:06:38 So what are the main activities or main tasks of an architect? We have again a predefined
launch, or group
00:06:46 in our launchpad of the Solution Manager, and you already see, it has a lot of tiles in it,
00:06:52 so the architect is really one of the core roles in Focused Build, and has therefore also the
most tiles available.

2
00:07:02 In the project, an architect might be a Workstream Lead, could be an Integration Architect,
00:07:07 or is already one of these functional experts for a specific element of the SAP solution.
00:07:16 He is involved in the review, of course, already in the explore phase - with defining the
requirements,
00:07:24 also in the effort estimation, but also one of his major tasks is to provide a design,
00:07:30 how these processes will now be realized - based on the applications, based on
00:07:36 the infrastructure that is available. He's involved in all the phases,
00:07:42 but the main activity will take place here in the realize phase, so here's really
00:07:48 where we will start creating the work package or decide on the right size of a work package,
00:07:53 and then providing, or writing the function specification and upload them into the work
packages,
00:08:00 decide how many work items and what details about the work items
00:08:04 we need to get this work package done, and of course also prepare the test cases
00:08:09 ready for function integration tests, and later on acceptance testing.
00:08:17 The typical outputs from an architect are the work packages, at least those that must be ready

00:08:25 for the next wave, the functional specifications have to be ready because they give guidance
on
00:08:30 what has to be done, how many work items are needed to get a work package done, and of
course,
00:08:37 all the tasks that may be distributed to the development team - so to decide which team should
take over which work item.
00:08:47 The work package is typically defined by a requirement, so this is also where the relation or
the reference
00:08:56 to our process model is coming from. It means the work packages have also a direct reference

00:09:03 into our existing process, or solution documentation structure.

00:09:08 This is handed over because we will create our work package out of a requirement,
00:09:13 so this is then a direct link also back into the solution documentation.
00:09:18 The other relationship is a project. That's something we have to define manually,
00:09:22 because we can now decide to which project this work package should be assigned.
00:09:27 So this is a manual activity and we have to decide to which.
00:09:32 Later on, when we have provided all relevant documentation, we will break down the work
packages into one to n work items.
00:09:39 We will create as many work items as we need to get all the activities done,
00:09:44 so that the work package is finalized. And just for reference, information,
00:09:50 because many people are more familiar with these agile tools, so that you can compare work
packages,
00:09:58 it's like an epic, typically in the agile terminology. In the header data, and also in the tabs of
00:10:07 the work package - we will see that in the demo now - is a lot of information that is directly
00:10:13 bundled with the work package. We will see who is involved in the work package,
00:10:19 like who's the owner, who's the process expert for it, but also who might be the development
team, who's realizing it.
00:10:28 We can do effort estimations, we can plan the efforts but we can also maintain the actual
efforts.
00:10:36 We have the link into the project, which gives us also then the planned dates,
00:10:42 because in our project, we know the milestones, and the milestones are then transferred back
into our work package,

3
00:10:49 so the work package owner can always see by when he should deliver functional
specifications,
00:10:54 test cases, or by when the work package should be finally tested. We have the wave assigned,

00:11:03 so this is a mandatory field so that we definitely know in which wave this work package should
be realized,
00:11:09 and we will upload here all related documents, such as specifications, test cases, and so on.
00:11:16 The work package, like the requirement, is tracked with the status, and we will see later on
00:11:21 by which workflow statuses we will pass this work package through.
00:11:30 Here's the big picture of our three main document types: the requirements, the work package,
and the work items.
00:11:38 As you can see, we have started with the requirements and our current status of the
requirement is,
it is approved.
00:11:45 So from here, we will now manually create our work packages. And the initial status of the
work package will be "Created".
00:11:54 From here, we will then continue working on the level of work package,
00:11:58 and you see that the status of the requirements will be automatically updated,
00:12:03 depending on which status we will go through the work packages. So this will continue until we
handover to development,
00:12:11 and that will trigger then, later on, the creation of work items. Then, we will be on the level on
the work items,
00:12:17 and certainly continue working here. And also here, you can see,
00:12:22 depending on the statuses of a work item, this will trigger an update of
00:12:26 the status upon the work package. But we have not got that far yet.
00:12:31 In this first unit, we would like to start with creating a work package.
00:12:35 We will come back to this picture again. So let's go to the demo and I'll show you
00:12:42 how you can create a work package out of a requirement. We will start again in the UI, in the
Solution Manager,
00:12:54 the Launchpad, in the starting UI, and select the role of Architect.
00:13:01 You can see there are a lot of roles available. be careful, the user Agatha Bauer,
00:13:06 which will be also the user that you can use for the exercises, has a lot of authorizations,
00:13:12 so therefore select the right one. Going to the Architect shows me all the tiles
00:13:18 that are typically relevant for the work of an architect, and we will start in the requirements
management app.
00:13:24 Of course, we would like to create our work package out of a requirement: That's the usual
case.
00:13:30 Of course, you could also create a work package without reference to a requirement,
00:13:35 but also this would happen here in this app. So keep in mind: This is the place
00:13:40 where you create the work package. First of all, we will select the right requirements,
00:13:45 and I just choose here, the status "Approved" of my requirements.
00:13:50 That's certainly something it should be. I could then use further filter criteria
00:13:55 to make the list a little shorter. For instance, I could here, in this case,
00:14:00 just take all requirements, but you can also select only those requirements that have not
already
00:14:05 been assigned to a work package. In this case, I just select all and hit go,
00:14:12 and I get a list, you see, I don't have that many so far, but here, in this case, I would like to
create
00:14:18 a work package for this requirement. I just click in the requirement so that I can read again,

4
00:14:23 what was written from the business, how have they explained what should the requirement be.
00:14:30 So I get all the data, just go back again, and then I can select here, by setting this flag,
00:14:37 that I would like to create a work package for explicitly this requirement.
00:14:42 This is now also the possibility where you can pretty easily select more than one requirement,

00:14:48 just by setting more flags, and click Create a work package. In this situation, you would have a
bundle of
00:14:55 three requirements that are realized by one work package, which might be the case also often
in a project.
00:15:02 Here, we go in the one-to-one relationship, so we go to the bottom, and we create a work
package here.
00:15:08 So just click on work package, create a new one, you see you can also assign a new one,
00:15:15 or later on, also decouple a work package again from a requirement.
00:15:23 In this case, we create a new requirement, and we give it a short title.
00:15:29 Typically, we will reuse the process name somehow, so that we can better identify to which
process
00:15:35 this work package belongs. So we take the name of our process into it,
00:15:42 we select the priority, in this case let's take Very High, it's a very important one, we can again

00:15:49 make use of this categorization field. Keep in mind that's a categorization schema
00:15:54 that you can freely define to just define better filter criteria, or later on in the Solution
Readiness Dashboard
00:16:01 also better grouping criteria that you can use. Free to define: we have used ours here.
00:16:08 This is, let's say, functional, and then the level: user interface,
00:16:12 because we would like to enhance the UI here in this case. The process expert, I typically take

00:16:19 here the expert from the requirement, because that's the person I would like to talk to
00:16:25 when I have questions about the process. So I take Julie Armstrong, and at the same time,
00:16:30 I also assign myself as the owner. Now comes the important part:
00:16:35 we also have to assign a project to it. In this case, we have two projects available.
00:16:40 I just select Freight Management, which is prepared in our demo environment.
00:16:45 Then, we have to decide in which wave the work package should be delivered, also here,
00:16:50 I select the first wave because if you remember, in week one we already maintained some
milestones for wave one.
00:16:59 Last is then the classifications - so we decide if it's a fit, like only configuration
00:17:05 or is it a Gap, or in our case, we decide it's just a WRICEF and with a smaller enhancement.
00:17:13 The last field gives you the possibility to enter some additional descriptions.
00:17:20 It will be mainly taken over from the requirement. So in our case, I just give a quick hint
00:17:25 that I will describe all my requirements in detail in the specification.
00:17:31 And by that, I just click on Create, and we see now immediately here,
00:17:35 with an additional number, that for this requirement we have created another work package
00:17:42 which is now directly assigned to it. If we click on it, you directly can see:
00:17:49 Here is my work package, and all the header data that I have maintained is available in the
work package.
00:17:57 At the bottom, you can see if you change toEedit mode, you can still change all the details
00:18:03 of your work package, because we are still in creation mode or creation status,
00:18:10 which makes it still possible to do modifications on the header data.
00:18:15 With that, I could show you hopefully how you can create a work package,

5
00:18:19 and in the next unit, we will then continue with how we're going to provide documents in the
work package.
00:18:26 Thanks for your attention, goodbye.

6
Week 3 Unit 2

00:00:06 Hello, and welcome back to unit two of week three about Realization in Focused Build.
00:00:14 In this unit, I will explain mainly about project documentation and how we can upload
00:00:20 and create new documents into work packages. We see that picture - probably you know it
from the previous week -
00:00:32 which represents our library structure and the process hierarchy that we have defined here on
top of this library structure.
00:00:41 What we have done in the previous week is we have created requirements
00:00:46 that have a reference, directly, to either a process step or even the process step where it's
originally stored in the library.
00:00:55 Out of this requirement, we have then, in the previous unit, created a work package
00:01:00 in this one-to-one, but you can see it's also possible in a one-to-m relationship.
00:01:06 So, we now have our work package, which is typically in the status "Created" in the beginning.

00:01:14 What we will now do is we will upload a functional specification

00:01:18 and a test case into the work package. But these documentations will not be stored only in this
work package,
00:01:27 but they will be only referenced in the work package itself. But physically they will be stored,
00:01:32 as you can see here, directly in the library. That is something which the system
00:01:36 automatically will provide for us, and which is one of the biggest benefits
00:01:41 also of Focused Build, that the documentation is produced where the people are working with
it, but it's stored
00:01:50 where it can later be found: in the libraries. Also in Focused Build we will limit the
documentation
00:01:57 a little so we will not produce thousands of documents. We will monitor the most important
ones
00:02:03 like the functional specification and also test cases, and we will document them where they're
also produced.
00:02:16 So, in this example, we have now several document types that we will upload into a work
package, and we will see
00:02:24 how the system will then automatically know where they will be stored. This picture represents,
again, our library structure,
00:02:33 like the Development library, the Executable library, Process Step library,
00:02:37 but also on the level of the processes, where we just use the references
00:02:43 of these process step libraries. So an example we have, for instance,
00:02:49 here a functional specification that we will upload in a work package.
00:02:54 This functional specification is typically stored in the Step origin, so in the Process Step library,
that means here.
00:03:03 Then we have maybe a single functional test that we're going to upload in the work package.
00:03:07 A single functional test is also relevant to all the process steps: It doesn't matter in which
process they will be used.
00:03:14 So, therefore, we will also store them typically in the Process Step library.
00:03:21 The technical design document, as we can see here, is usually based on development or
executable elements.
00:03:28 So therefore, it's also uploaded to the work package or work item,
00:03:33 but it will be stored in the library here - in the development. And last but not least, just as an
example,
00:03:39 we also have documents like a use case document, a use case description, that is something

7
00:03:45 which may only be relevant to this particular process and therefore it will not be stored in the
original,
00:03:51 but only in the step reference, meaning in this process, where this process step is used.
00:03:58 So this can be predefined in the system, so that the different types will automatically be stored
in the right library.
00:04:06 You can also keep it open so that the user who's uploading it can still define
00:04:10 if he would like to have it in the original or stored in the reference.
00:04:16 Another nice functionality of Focused Build is our documentation KPI, which is included
00:04:22 in the work package and in the work item. For instance, we are in the status
00:04:28 of a work package of scoping, and we will see which documents we have to provide.
00:04:35 In our example here, the system or the work package will tell me, I have to provide at least a
functional specification.
00:04:43 So when I now start scoping, so go to the next status, it will tell me, okay, the functional
specification
00:04:52 is now available; I have it uploaded here into my work package. It's "In Progress", that's the
initial status of my document.
00:05:01 And it is available, so all is green. If I now switch one step further
00:05:06 and go with my whole work package into "Scope Finalized" status,
00:05:13 the KPI will certainly tell me, oh, it's not okay, we need something more,
00:05:18 because the expected status will be "Released". I would like to have a document in "Released"
status,
00:05:25 and not only In Progress. So that KPI would show me a red indicator
00:05:30 saying, you have to do something. And what you have to do is you have to release it.
00:05:35 That's later on possible also in the Four Eyes concept, so that you can decide who releases
the documents.
00:05:42 All this can be activated in the system. So now my document is in status "Released",
00:05:49 and my KPI displays green, meaning everything is okay. Another functionality which also
makes it easier
to work with documents
00:05:59 is the Solution Documentation My Documents. As it will be possible, and we see here
00:06:05 the screen out of a work package, it will be possible to assign the documents
00:06:10 to a specific owner or to somebody who's processor of it, just in case you would like
00:06:16 to get a functional specification released. So you hand it over for processing
00:06:22 to the appropriate process owner. He would then find this document in the tab, My Documents,

00:06:31 and could then read, review, edit, or even approve it finally, so that the status of the document
can also be continued.
00:06:40 So therefore, you have this additional tile in the launchpad available for my documents,
00:06:45 where you will find all the documents for which you are either the processor or the owner.
00:06:51 That also makes it a little easier for you to work on documents that you have to approve.
00:06:59 Here's a screenshot, and we will see it also in the demo again, about the document upload
area.
00:07:06 So the so-called drop docs, so this is where we can drag and drop documents in.
00:07:12 But not only drag and drop: Of course, you can also use the Browse button to search in your
library,
00:07:19 to upload any kind of documents. Or you could also, using this button, create a new document.

00:07:27 This is a benefit because when you create a new document, it will automatically make a
proposal based on a template.

8
00:07:34 So you can reuse a template given from your project or from even SAP and start working on it

00:07:41 and then upload the final version again. You also have the appropriate button
00:07:46 when you mark your document here to set the status of your document,
00:07:51 to search if you have a long list of documents, or even to define here the sort criteria of your
list of documents
00:07:59 that are assigned to a work package. This Assign button is also a very nice additional
functionality.
00:08:07 You see it here: This document is assigned. That means it belongs to this specific work
package.
00:08:13 But in the demo, we will also see that we sometimes have documents that we can see,
00:08:18 but they are not assigned, because they are not produced directly with the work package,
00:08:24 but maybe with another work package which references the same process or the same
process step.
00:08:30 So to have very high transparency here, it is possible to see them, to see what other
00:08:38 work packages are producing our documentation, but you don't have to assign to it.
00:08:43 You can, but it's not a must. In this example, we see now
00:08:49 how you typically produce a document. So after you have maybe used a template,
00:08:56 you will download it, you start processing the document, editing it, bringing your content in
00:09:04 and then later on drag and drop it back into the area here, which then updates the current
version.
00:09:13 In this case we have a configuration guide template that we get from the system, we process it

00:09:19 and at the end, it is our final configuration guide that we then upload into the system.
00:09:26 Last but not least, I would like to mention one very important thing
00:09:29 also for the documentation aspects between requirement work package and work items.
00:09:36 As you can see here, all the documents that we are uploading to a requirement
00:09:41 will remain linked to the requirement itself. So this is like a typical attachment
00:09:46 that you maybe upload to an email. If we now go one step further, the work packages,
00:09:53 like the functional specifications and test cases that we upload here to the work packages,
00:09:58 will not be stored any more in the document itself, but they will be stored in the library,
00:10:04 in the process structure of our solution documentation. In the design branch - this is the level
00:10:12 where we are working in the work package - it is still possible to change anything we want.
00:10:18 But as soon as we hand over these documents into work items and hand over into
development,
00:10:25 it will only be possible to change something in the development branch on the level of a work
item.
00:10:32 So it won't be possible any more then at work package level. So we would need for each
change that we would like to do, a work item
00:10:39 that we assign to it or we create a new one. In the work item, we see we hand over,
00:10:45 from the work package, the documents and the work item. So these three existing ones are
still there, of course.
00:10:52 And if you would like to change something in our functional specification,
00:10:55 we can then only do it at work item level. Here in the work item, we maybe add additional
documents
00:11:02 like technical design documents. And this is also from here, it will be transport- controlled
00:11:08 to be released later on into production. This gives you a very clear structure
00:11:14 of your solution documentation and the versioning to have only those documents

9
00:11:20 in a productive branch that are really valid. To mention it, we also have, in these presentations,

00:11:30 some additional slides that we are not showing here now. But just for your reference,
00:11:35 if you download the PDFs later on from the Download Center, you will sometimes find some
hidden slides
00:11:42 that give you some further explanation and some more details. But now, let's go into the demo
of
00:11:48 how we're going to produce documentation into work packages. We will start again in our
launchpad,
00:11:59 in the view of the architect. And we'll this time go or start in our My Work Packages tile.
00:12:07 My Work Packages shows me I have currently two work packages that I'm somehow assigned
to.
00:12:13 Either I'm the owner or I'm the process expert, or whatever. I get this list of these two.
00:12:20 But there's also the possibility, with this filter button down there,
00:12:25 if you search for another work package that is maybe not assigned directly to you,
00:12:31 you can extend the filter criteria here, saying, show me all work packages or those from my
team,
00:12:36 or as the default, only mine. We keep it for better transparency here for those two,
00:12:44 and we select the one that we have created in our previous unit. Going down to the area, I
change to Edit mode.
00:12:53 And I can see here all the fields that I can still change. We'll keep them for now and go to the
next step,
00:13:01 which is the Dates tab. And we can see here that we have certain dates
00:13:06 coming from our project, like Functional Specification Released, Build Finished,
00:13:11 Single Functional Tests Completed. If you remember, these were milestones
00:13:15 that we maintained in the first week in our project plan, and they are now handed over into the
work package,
00:13:21 and show me very clearly when there are certain due dates for my deliverables. But now, let's
go into the documentation.
00:13:30 I would like to skip to the text and the attachment part because it has less relevance in work
packages.
00:13:37 Nevertheless, you can still use them. But keep in mind: For uploading documents
00:13:41 we definitely prefer the Documentation tab and not the attachment area.
00:13:48 In the Documentation tab, you see here I have a link into my structure.
00:13:52 So this has been referenced from my requirement, and it's also needed in the work package.
00:13:57 If I don't have this structure reference here, it will be difficult for me to upload documents
00:14:02 because I would not know where the target is to store them. So let's have a look, and I see this
is exactly my process step
00:14:10 that I have selected - I can just click on it, and it will open up the solution documentation
00:14:16 and show me exactly the structure where I can find my process step.
00:14:22 What we can see here is that for this process step, documents already exist:
00:14:27 You see there's already a functional specification and some other documents available.
00:14:33 Closing this one, you can see down there they are exactly those that are present here, as well.

00:14:40 But if you remember, as I said already this assign is not given.
00:14:45 So they are just there because I can read now the documents from maybe another work
package
00:14:50 that's referencing into the same process. Let's switch into the current status.
00:14:57 This is a subtype here of our documents. The current status now shows me

10
00:15:02 what is expected based on the classification. I have chosen WRICEF, you remember.
00:15:08 And for WRICEF, I have defined in the system - this comes pre-configured, but you can
change this, if you like -
00:15:16 that there is a function specification of type WRICEF expected and a single functional test.
00:15:23 So, when we now go into our next status: So far we are still in the initial status.
00:15:31 So, let's say we start defining the scope. Defining the scope means now we will produce
documents
00:15:37 and we will define how many work items we will need. So, we will now be in the scoping phase

00:15:42 and the system tells me, look, we need these kinds of document,
00:15:46 and they are not available yet. So, let's go back into our Documents tab
00:15:52 and start producing them. Here is our Create button.
00:15:56 Here I can start creating a new document. So I select this one, and I get this small popup
00:16:02 where I can give a name. Also here a best practice is that we use some tags
00:16:07 in the beginning of a new document like in this case, FS for functional specification.
00:16:15 Then I select which document type it is. We expect to deliver a functional specification of type
WRICEF.
00:16:23 This is now also giving me the appropriate template. So each type might have a different
template available.
00:16:30 I select this one for WRICEF. And now I also can decide if I would like to store it
00:16:36 in the original of my process step reference or directly in the process step reference.
00:16:41 I said this can be controlled from the system, but here I have the freedom to choose myself.
00:16:48 I select original, because it's the specification, and this is, of course, relevant to everybody.
00:16:54 Then I click on Create and I have here, as you can see, a new document type - with my name.

00:17:02 Just click on it and it will open it up here, within the download area, and I open it in Word.
00:17:09 So here you can see there's a template and you can now start writing your own specification
within the document.
00:17:15 If you're finished, just click Save. And close your document. Then you will just upload it again,

00:17:24 you can either use drag and drop, or, in our example, we click here on the Browse button
00:17:31 and then it will be here in our download area, I just select it and say Open.
00:17:37 The system will now, based on the name, recognize that there is already the same document
available.
00:17:43 So I can now decide if I would like to overwrite it with a new version.
00:17:47 Keep in mind also: The old versions are kept
in the system, of course. But in this case, this is exactly what I want.
00:17:54 I don't want to have the template. I would like to use my version of it.
00:17:58 So I select here New Version. And then Create ...and close this one again.
00:18:07 So I have now created exactly my functional specification. And what you also can see is
00:18:12 this one, as I produced it immediately here, is also directly assigned to my work package.
00:18:18 I will now continue and create another document. You remember we also needed a single
functional test.
00:18:24 So select the file name, type was Single Functional Test.
00:18:31 In this case, we just assign it to the reference, and create it. And close.
00:18:40 So, I will not again go in the document and upload it again. But you now know how it works.
00:18:46 So this is the way you would do it - with all of your document types in each of the work
packages

11
00:18:50 and also later on in your work items. Furthermore, what I would like to do is
00:18:55 to select the status of them, so just flag these two documents
00:18:59 and then go here with this button in the status of my documents.
00:19:03 As you can see, currently, the status is In Progress. So ...here I can select many in one go
00:19:13 and then I say, okay, my functional specification is in the status In Review,
00:19:18 and my single functional test is only in Copy Editing. I change it and go back again.
00:19:27 And if I now go to my solution documentation structure again, I can now see that the
documents
00:19:33 that we have created now are also available here. So we have the single functional test,
00:19:40 and we have our functional specification. For those of you who are really looking carefully,
00:19:46 they can see a little, and the paths that we see here, that they are stored in different sources.
00:19:53 You see, for instance, our functional specification is stored in the library of the process step.
00:19:59 But the single functional test, we decided it should to be stored in the reference area.
00:20:06 So here you see the path of the library is different. I close the solution documentation again
00:20:13 and go back in my current status to see if I have now provided what is expected from me.
00:20:18 And you can see, yes, the two documents are now available. The expected status currently is
In Progress.
00:20:26 I have even more: I have In Review and Copy Editing, so the overall rating is green at the
moment.
00:20:37 With this, I hopefully could show you how you can upload and produce documents into your
work packages.
00:20:46 In the next unit, we will now see how we will continue with scoping work items in the work
packages.
00:20:53 Thanks for your attention. Goodbye.

12
Week 3 Unit 3

00:00:06 Hello, and welcome back to our unit three of this week about Realization in the openSAP
course,
00:00:14 Agile Project Delivery with Focused Build. In this unit, I would like to introduce
00:00:20 how we're going to scope work items that we need to fulfill the processing of a work package.
00:00:29 Let's start again with the whole overview, how work items at the end will be produced.
00:00:35 They will result out of, of course, our requirements that are produced out of the Fit/Gap
workshops,
00:00:42 still in the Explore phase. So, in the beginning, maybe we have really Fits and Gaps
00:00:47 after the show-and-tell sessions to the business. These so-called Fits and Gaps will be
prioritized, ranked,
00:00:56 and the effort estimated, so that we come out with a ranked requirements list. Already in these
requirements, keep in mind
00:01:03 it is possible to classify them. If we know it, we can do. If we don't know it, we can keep it open

00:01:10 and just do it later on in the work package. Then we come to one very crucial element of
Focused Build,
00:01:16 which is the functional analysis and the release planning which handed over from the
requirements,
00:01:23 then into the work packages. This doesn't have to be always a one-to-one relationship.
00:01:29 It could be one requirement into many work packages, but it could also be the other way
around:
00:01:35 that we have multiple requirements in one package. After that, these work packages will,
00:01:43 for each sprint, be decomposed into several work items, and that is exactly what we will do in
this unit.
00:01:52 As you can see also in the graphic, the work packages are typically related to waves.
00:01:58 That means we should define the work packages in that size, that they should be able to be
fulfilled within one wave.
00:02:07 Of course, it's not a big issue if they cannot be completed in one wave,
00:02:12 but then we have to do some manual action and transform them from the current wave into the
next one.
00:02:18 So therefore, keep it as a rule of thumb that the work packages should be possible
00:02:25 to be handled within one wave at least. Of course, you can also define multiple work packages
for one wave.
00:02:34 When we now decompose our work package into as many work items as we need to get the
work package running,
00:02:42 we define them here in these work items. The work items should have the size
00:02:46 that they can be fulfilled in one sprint. So this is based on the Scrum methodology
00:02:51 or Agile methodology which relates to what, in other tools, is called a User Story. So, work
items should have kind of the size of a User Story,
00:03:03 while the work package has maybe the size or the definition size of an Epic.
00:03:09 And the work items, of course, should also be possible to be processed within one sprint.
00:03:14 If it's not fulfilled there, of course also here we take over this work item into the next sprint,
00:03:21 but we will not postpone the waves and the sprints. That is against the Agile concepts.
00:03:29 We have two types of work items defined in Focused Build. The first work item, NC, stands for
Normal Change,
00:03:39 will be used mainly for development of WRICEFs or Gaps, anything that has something to do
with transportation,

13
00:03:48 could also be Fits when they result in any customizing or workbench transport requests.
00:03:56 So, the normal changes will therefore always have a relationship with a transport request,
00:04:01 which we will then create out of the work item only. Of course, non-ABAP developments are
also possible.
00:04:09 This is then related to our CTS+, which runs in the background. But in the work item, we will
see no difference on that.
00:04:18 The other work item that we have is the GC, so the General Change.
00:04:23 This one is used, or is not directly related to any software deployment.
00:04:27 We use that for any non-functional work activities that we would like to track,
00:04:32 maybe also in the Solution Readiness Dashboard, but they are also maybe relevant
00:04:37 to get the work package done, in the end. One example is that we often use such work items
00:04:43 just to transport certain test documents into the development branch,
00:04:48 because we will need a work item always as a transport for getting documents into the next
branch.
00:04:59 All work items of a work package have to be at the end successfully tested. Keep that in mind,
because there is no possibility to change the status
00:05:08 of a work package any more. They will be automatically set by getting all work items done.
00:05:16 That means, every work item which relates to a work package has to have the status
Successfully Tested,
00:05:22 so that the status of the work package also switches. We see again here our big picture of the
status flow
00:05:33 of our requirement, our work package, and this time, the work item. So we are now at the
status,
00:05:39 that we are in the scoping phase of the work package. So, the scoping phase means here
we're going to define how many
00:05:47 work items of which content we will use or we will need to get the work package finally done.
00:05:53 We will then have an additional status check - so like an approval step to check if all
documents
00:06:00 and if all work items are really available - so that we can start working on the level of a
developer or a configurator.
00:06:09 So when this status Scope Finalized is set, we will then set a status which is called
00:06:14 Handover to Development. And this will trigger something in the background.
00:06:19 First of all, we will physically generate these work items. So far they were just scoped:
00:06:25 We just planned to have these work items. But when we set the status To Be Developed,
00:06:29 they will be physically created automatically here in the system. So, we will then have, in our
work items, the status Created.
00:06:41 From there on we start developing, and later on also do our unit test.
00:06:46 But this is something I will explain in the next unit. What typically happens in the scoping
phase -
00:06:57 you remember what we saw in the previous unit is that we are uploading documents to the
work package.
00:07:02 The documents that we are uploading here, as you can see in this green box,
00:07:07 are so far only uploaded into the design branch of our solution documentation.
00:07:13 When we hand over to development, these documents will be transported into the work item,
00:07:19 and will then be automatically released from the design branch into the development branch.
00:07:25 This happens automatically, just by switching the status from Scope Finalized to Handover to
Development.
00:07:33 In the work item later on, of course, we will additionally create documents,
00:07:37 such as a technical design document, or maybe later on also test cases

14
00:07:43 that might be relevant for the work package. But all these will then be directly assigned to the
work item,
00:07:49 and by that referenced into the work package. That means we will not work any more on the
level
00:07:54 of the work package for uploading documents, but we will do that on the work item level.
00:08:04 Let's have a look what the scoping looks like. When we click on this, on the plus to create a
work item,
00:08:10 in the Scope tab, we will get a popup where we can decide if we would like to create an NC, a
Normal Change work item, or a GC.
00:08:19 We give a short description. And important, now we have to decide in which of our sprints we
plan to have this done.
00:08:26 This is like our sprint backlog. We say, "In Sprint 1, 2, 3," and so on.
00:08:31 The delivered system, if it's related to a transport, is automatically shown, but can still be
adapted if required.
00:08:40 Then on the left lower part, we have then to decide which documents and which process
structure
00:08:45 we would like to hand over in this work item. Keep in mind, by that we are transporting also
00:08:51 these documents from the current design branch to the development branch. So here you can
divide and decide which document
00:09:00 should be related to which work item. But it doesn't matter if you have them redundant,
00:09:05 like assign the same document into work items multiple times. On the right side, you have then
the possibility
00:09:14 to already assign a work item either to a development team, or directly to a developer.
00:09:20 And if you like, already even assign a tester, who should do the unit test, at least, for this work
item.
00:09:30 So, we see the relationship of our work item - here on the right - to our work package.
00:09:37 That means, as I said already, a one-to-n relationship of work items to get the work package
fully fulfilled.
00:09:48 The work items correspond to User Stories in Agile, and of course also the link to the process
is given
00:09:55 by choosing the appropriate documents and the process structure when we scoped the work
items.
00:10:01 That means, whatever we are doing on the work item level will also have a direct reference
back to our initial process structure.
00:10:12 For the developer or configuration consultant - they're probably using the same launchpad -
00:10:20 we also have a group designed, where they have direct access to the work items that are
assigned to them,
00:10:27 but later on also how to manage the defects that maybe will occur during testing.
00:10:32 But this will come at a later stage of the course. So just click on the work items,
00:10:39 and we can start processing the work items. Let's have a look in the system, how it looks.
00:10:56 Here we are again in the launchpad, and we still see the role of the architect.
00:11:03 So we will go into the tile for the My Work Packages, and we will go back into the work
package
00:11:10 that we have defined in the previous units. So, now we will go directly into the tab of the scope.

00:11:18 Click on Scope. So far, we haven't defined any work items yet, so we go on the right side, on
the plus,
00:11:25 and keep in mind, we have to be in the status Scoping. If this plus is maybe grayed out,
00:11:31 you should double-check if you are in the right status already. So, click on the plus.

15
00:11:37 And I get this popup where I can now decide which type of work item I would like to scope.
00:11:43 We will start with a Normal Change. Give it a short title.
00:11:46 In this case, maybe for development of our web service. We plan to have this done in the first
sprint,
00:11:55 so we assign Sprint 1. The delivered system was automatically given,
00:12:00 and now I can classify. And keep in mind, we defined the work package
as a WRICEF,
00:12:04 so we have now the option only to select Enhancement. Then we can already assign specific
users,
00:12:16 so in this case we say the developer should be John. And here we hand over the documents
00:12:22 and the process structure by selecting here, in this case All:
00:12:26 That means we hand over the process structure and all documents in this related work item.
00:12:32 Click on Save. And now we have the work item scoped.
00:12:37 You see it - it's still only in the status To Be Approved. So now we will create another one.
00:12:43 Just click again on the plus. This time, we will create a work item of type GC.
00:12:49 Again, we give it a title. Here, we only would like to have a placeholder
00:12:53 for transporting test cases later on. So, to be delivered also in Sprint 1.
00:13:00 This is, of course, also relevant, but the system is not relevant because it is a general change.

00:13:05 We can give a short comment, like "Only for test cases." And also here, we can now hand over
maybe just
00:13:12 the test case document to it. And Save ...
00:13:18 And now we have two work items scoped to get one work package fulfilled. If we now go to the
Effort tab -
00:13:27 this is probably the same as you could see in the work package - we can now also record the
efforts that we have done, that we have had.
00:13:35 So maybe here, for the architect, we just maintain, we did some scoping.
00:13:43 The effort was eight hours. And it happened on the following date ...
00:13:56 Save ... We will later see that these recordings of the efforts
00:14:01 also will be aggregated up into My Project Plan, so I can see for each wave what were
00:14:06 the real efforts that we have spent. Let's have a look in the Relations tab, and what does it
mean.
00:14:13 Relations show me either previous or successor documents to my current work package.
00:14:19 The previous document is, as you can imagine,
the requirement. So from here, I can always link directly back
00:14:27 into my requirement, which this work package is related to. But, of course, what I always can
do is,
00:14:34 I can create additional relationships. This is sometimes relevant if you would like to have
00:14:39 a relationship to another work package, to say this one has to be done first,
00:14:44 or this one definitely has to be done after this work package. So you just click here on the plus,

00:14:50 and make a successor or predecessor relationship to another work package. I will not do this
here now on the demo,
00:14:58 but just that you know this is possible here with this plus. Going in the Action area, where I
change my status flow,
00:15:07 I will now approve the scope, saying I have all documents available,
00:15:10 I have all work items defined that I need. So I can approve this work package.
00:15:17 And we see now the scope is finalized. But now we can see that in the documentation,

16
00:15:23 something has changed: There is still a red alert. And let's see what is happening under
Current Status.
00:15:30 It clearly says, "The expected status of my functional specification should not be reviewed. It
should be Released."
00:15:37 So, we have to go back, of course, to our document, our specification, and set the status of the
document to Released,
00:15:46 because this is the expected status. As we cannot change anything any more in the status,
00:15:52 you can see the fields are grayed out, because we have Scope Finalized already.
00:15:57 Just wanted to show you that it's also possible to go back in the status, via the Action button.
00:16:03 So instead of continuing, we could also go one step back and say, we go back to the scoping.

00:16:10 Now, back in the scoping, I have still the possibilities to change something.
00:16:15 So here, we will now change the status of our document, from Review to Released.
00:16:24 Of course, this would have been possible also to change the status of the document, later on,
in the work item directly.
00:16:30 But I just wanted to show you that it's usually always possible also to go one step back in the
workflow.
00:16:37 So we changed that status of the document to Released, and we will then see that my
indicator here of the work
00:16:45 on the documentation has been switched to green. So now all is okay. Now, I approve the
scope again.
00:16:56 And go back into my Relations tab. When we now hand over to development,
00:17:01 which will be the next status flow that we are taking, I will definitely do something in the
background.
00:17:06 As I said already during the presentation, I will now create the work items physically.
00:17:12 So let's do it. I click here on Handover to Development.
00:17:17 And you see immediately there are two new documents as our successors of our work
package,
00:17:23 and these are the two work items. So I could navigate directly from here,
00:17:28 or I could also go here in the Scope. And I see with the blue links that now
00:17:33 this is also a physical document. So clicking on it, like Develop Web Service,
00:17:37 will open up a new tab for me, and now I can see the work item.
00:17:46 Good. That is the unit on how to scope the work items.
00:17:51 In the next unit, we will explain how the configurators or the developers
00:17:55 are working with these work items in terms of creating transport requests
00:17:58 and do their development work. Thanks for your attention.
00:18:03 Goodbye.

17
Week 3 Unit 4

00:00:06 Hello, and welcome back to unit four of this week. In this unit, Development and
Configurations,
00:00:15 we will see mainly how the developers or the configuration consultants
00:00:21 will now use the work items to start their configuration in the managed system, such as an
S/4HANA system,
00:00:29 or even do their developments. Let's first start again with our big picture.
00:00:42 We are now switching again the role from our solution architect to the build team -
00:00:47 as I said, the developers or the consultants. They have work items available that have been
scoped by the architect,
00:00:57 so they can start using them, and perform all the activities according the specification that has
been done
00:01:04 by the workstream leads or the functional experts. That means they will use their work items
00:01:10 to document what they have done, but also as a single point of access to the target system.
00:01:17 We will see that in the demo. Additionally, they will upload any required documents
00:01:22 where the Focused Build will also guide them on what to do and what they should look like,
00:01:27 and finally, they will also perform the unit test, which is not a structured test
00:01:33 like we will do later on with the integration test, but there should be at least an informal test
00:01:37 between two developers to see if the single function at least works.
00:01:44 At the end of a sprint, we typically manage show and tell sessions back to the business or to
the owners,
00:01:52 so that they can see what has been done in the sprint and can maybe give their feedback
00:01:57 so that it can be modified at the right point of time. That is one of these Agile concepts.
00:02:04 The outcome is, of course, either the documentation, like a technical design paper,
00:02:10 and, of course, also all developed and configured objects in the system. The typical roles, as
usual, are, in this case,
00:02:20 the developer or the consultant, and they have the responsibility
00:02:24 to execute all of the tasks that have been assigned to them, like in all the work items,
00:02:30 but also perform or provide the technical designs, perform the unit tests, and later on, also
when we are in the testing phase,
00:02:39 to be involved again when it comes to defect corrections, that they recap the tests.
00:02:45 The tasks, as you can see, are mainly happening in the Realize phase.
00:02:49 So they are not so much involved in the Explore, but even more in the Realize,
00:02:53 where it comes to plan and document all their activities and perform them, of course, do the
unit testing,
00:03:00 and later on, the defect corrections. As usual, we have again, in the launchpad,
00:03:06 an appropriate role group for the developer, in this case, available. As we are now starting to
actually work in the systems,
00:03:17 let's have a look at our status flow, but this time with an additional view -
00:03:21 from a system landscape perspective. We had our status flows, as we have usually here, from
our work package,
00:03:29 and keep in mind, the last status of our work package was To be Developed. With that, we
have handed over into the responsibilities of our development teams.
00:03:40 So now, we are working on the level of the work items. Here, we have the work items in the
initial status, Created.
00:03:47 First, what a developer is doing is taking a work item into the progress status -
00:03:53 we call it In Development. So here all the work is typically happening:

18
00:03:58 the coding and also provision of the documents
that we need. When we then hand over the status
00:04:07 into the status To be tested, something happens in the background.
00:04:12 As Focused Build is a semi-automated scenario, we will trigger automatic activities.
00:04:19 In this case, we will automatically trigger the first transport. It's only a transport of copies.
00:04:26 That has a special meaning because we will only provide here the first transports into the Q
system for a unit test.
00:04:36 So the tester can now run the tests directly in the QA system already. Of course, he's also free
to do it in the development system,
00:04:45 but at least he could do it already in the QA system. If then, some things have to be adjusted,
00:04:52 the developer has maybe to do some corrections, he will continue providing some further
transport tasks
00:04:57 and release them every time he sets the status from In Development to To be tested.
00:05:04 As you all probably know, this could happen a few times until the single feature is working as
expected.
00:05:11 Only when the tester - and we're talking about the unit tests - sets the status to Successfully
tested, this will now trigger -
00:05:20 and we symbolize it here with these green buttons - the release of the final transport to the Q-
system
00:05:25 so that at the end, we will only continue for further deployments with this final transport
00:05:32 and not with all the transports of copies that we had before. This certainly also benefits the
release manager later on
00:05:40 in handling much fewer transports than usual. When we then, later on,
00:05:46 have all the work items tested successfully, as you can see, that will automatically trigger
00:05:54 a status update here, back up in my work package. So my work package will then be switched
to the status To be tested.
00:06:03 Of course, if all my work items are working fine individually, now I would like to see if they all
work together in my work package.
00:06:12 So that means my work package now has to be tested. A work package is usually tested at the
end of a wave, at the latest.
00:06:20 Of course, it can be done earlier, but at the latest. So here, we definitely also would like to
have more structured testing -
00:06:28 not like the unit test, where it's more two developers in a pair, but with a test case planned, and
a test plan,
00:06:38 and with the generation of test packages. So this is something we will explain next week,
00:06:44 but just that you see it already, the work package will be in the status To be tested,
00:06:48 and only when all these test cases were run successfully, we will set the status on
Successfully tested,
00:06:56 which will then - and this time, this is a major difference - not automatically trigger the transport
to the pre-productive.
00:07:04 We definitely do it via a release manager. So don't be scared: Only between the DEV and the
Q-system
00:07:11 will we automatically release via status flow, but the releases from the Q-system into the
PrePRD
00:07:17 and also, of course, later on, from the pre-production into the production system,
00:07:21 will happen through a batch import, which is triggered after a few checks by a release
manager.
00:07:28 But as I said, we will have a separate week for all these deployment options
00:07:33 for the release manager, in week five. Important is definitely in the work item

19
00:07:41 to have at the end of all the activities to set the status Confirm Successful Test
00:07:48 because only if all of the work items are successfully tested, will the corresponding work
package
00:07:53 be in the status To be tested. As we also could see in the work package,
00:08:02 we have the same feature here in the work item: that it's possible that a developer or
configurator
00:08:08 is able to maintain the efforts that he had. In this case, we have some analysis,
00:08:14 or documentation, or coding, or whatever. This can be tracked or maintained here in the
system directly
00:08:19 and will be aggregated up into the project plan
that we will see later. A pretty new feature in Focused Build
00:08:29 is the possibility to use even one level lower: the so-called Tasks. That was triggered because
so many developers
00:08:38 are used to work with daily scrum and daily tasks. So that means a work item which should be
fulfilled in one sprint
00:08:46 can be further decomposed into even smaller tasks. This is now possible also with Focused
Build since SP2,
00:08:54 that we have these tasks available and can define who's the processor of it
00:08:59 and what is the current status, but it's not overdesigned with too many features:
00:09:03 It's pretty flat functionality, and can be used optionally or not. Finally, we will, also in our last
unit of this week,
00:09:15 see how all this influences our Solution Readiness Dashboard, and we can see here already
that we have, for instance,
00:09:22 a tile which is called Technical Design, which is showing me, in the Solution Readiness,
00:09:27 if the technical design documents for each developer are available in the system or not.
00:09:33 It's also combined with a due date. If you remember, we maintained, in Sprint 1,
00:09:38 when certain functionalities or technical design documents should be available, and this is then
reflected here against this due date.
00:09:45 So here, we can see that still 100% of all our technical designs have to be delivered,
00:09:52 but it's still okay because the due date is not yet reached. That would mean here, this yellow
bar.
00:10:01 But let's go into the demo, and we see how we do this really in the system.
00:10:08 So we will start again at the launchpad, and we go first in the role of our developer here,
00:10:18 Focused Build - Developer. And we can see, we have here seven different tiles available.
00:10:26 We use the first one, where we have the work items that are assigned to us. So, opening the
work items ...
00:10:33 and you see here are the two work items that we have scoped in the previous unit.
00:10:40 Let's start with this Develop WebService work item. So I click on it, and I'm here first in the
header data,
00:10:48 and the first thing I do is I switch the status from currently just Created
00:10:52 into In Development, so Start Development. Then, we can have a look into the dates,
00:11:01 and we can see when certain things should be provided. For instance, here we see this
technical design
00:11:07 should be released by 15th of April at the latest. So this is my due date also for the Solution
Readiness Dashboard,
00:11:14 and I have a clear guidance by when certain things have to be completed. The same applies to
when the unit test should be finished,
00:11:21 and when the whole work item should be finished. Let's switch into the Documentation tab,
00:11:28 and we also know that one. The functionality here is exactly the same

20
00:11:32 as we had in the work package, two units before. We can first of all check what is the current
status
00:11:40 and what is expected - what type of documents are expected here. We see a technical
specification is expected from me.
00:11:50 So going back here, but from technical design, from type technical design.
00:11:55 So going back now to my document, and I can see here is my functional specification
from the work package.
00:12:03 Of course, I need that as a developer. I need to read what my architect expects from me.
00:12:08 So I have here the specification, and I can click on it, just open it,
00:12:13 and read the specification that is provided to me. So based on that documentation,
00:12:21 I can then also create a new document. In this case, we would like to create a technical design
document.
00:12:31 So give it again a short tag like TD for technical design, select the right template - in this case,
technical design template -
00:12:40 and just simply Create. So you see it here, it's now available, and just mark on it,
00:12:51 and then, I could read it and start maintaining it. As we saw all of that already in the unit on the
work package,
00:12:58 I think I don't need to show all of that again. Looking more in the interesting part, which is the
Transport,
00:13:04 this is something we didn't have in the work package. Well, let's go in this tab.
00:13:10 The Transport tab is to create transport requests. So far, we don't have them.
00:13:16 But what we can see already is our transportation landscape between all of our systems.
00:13:21 And currently, as we are in the development, Relevant for Logon for doing the development
00:13:26 is the first one: S/4HANA, client 820. To now create a transport request,
00:13:34 which I need to really store my development on the objects, I click here on the plus,
00:13:40 not on the Create Transport, Transport of Copies - that is just additional transport of copies -
00:13:46 you simply click on the plus. You get this popup.
00:13:52 In the best case, you just leave all the Short Description, which has been generated by the
system automatically.
00:13:57 So only decide, if beside yourself, other developers should also be assigned to this transport
request.
00:14:03 So we'll additionally assign John Lee to it, and save. All the rest is automatically pulled,
00:14:11 and you see we will generate two different transport requests: one Workbench and one
Customizing.
00:14:18 You see them now here with two different numbers - they're now available. What I now can do
is directly from here,
00:14:25 I can navigate to the development system and start my work there. So just simply click on this,
on the first line here, on that link,
00:14:35 and that will open up the target system, an S/4HANA system ... directly where I can start my
work.
00:14:45 Let's go into the IMG, SPRO, and just do a very, very easy and little example
00:14:54 so that you see how this in general works. We will simply go here into some general settings,
00:15:02 and as we don't want to harm anything in the system, we just do something where we maintain

00:15:08 a naming adjustment in the region. So just a little change in the system,
00:15:14 but of course, any change is recorded, and if I click on Save, I now get my transport request
popup.
00:15:22 And here, I can now choose between those transport requests that are assigned to me, and
you can see it's the one that we have created in our Solution Manager system.

21
00:15:34 So I assign it to the one that we have created and save and go back.
00:15:43 So now, let's see what we have to do after we have done all of our configuration in the target
system.
00:15:49 Let's go into the Transport Management, SE10. In the Transport Management System,
00:15:55 I can now check all my transports and my tasks. So just show mine here in the display,
00:16:01 and I can see, here is, for instance, exactly the transport request which is assigned to me.
00:16:06 I open it up, and I can see the tasks that are produced by me. What I, as a developer, have to
do is
00:16:13 I have to release the task - but only the task. So I mark the task, say Release Directly, and
that's it.
00:16:21 You don't have to, and you cannot, release the transport request, because this is happening
automatically through the system.
00:16:29 So now, I can close here and continue in the system with my unit test for the tester.
00:16:37 But this is something I will do in the next unit, so stay tuned and thank you for your attention.
00:16:43 Goodbye.

22
Week 3 Unit 5

00:00:05 Hello, and welcome back to unit five of this week, about Realization.
00:00:12 In this unit, we will get to know the unit testing, how we're going to do the testing
00:00:18 on the small developments that we are doing
on the level of a work item. As you can see, Focused Build covers a lot
of different test concepts.
00:00:32 We will get to know all of these in much more detail next week. But for now, for the work item,
the unit test is already relevant,
00:00:42 so let me quickly explain about it. The unit test is happening on the level
00:00:47 of a work item, so usually during the sprints. So whenever a developer or a configuration
consultant has finished something,
00:00:56 he should hand over to a tester - maybe a colleague of his - to check if what he has done is
working correctly.
00:01:05 So, the unit tests are therefore not too much structured and too much defined from Focused
Build.
00:01:14 We just keep it simple and easy. Nevertheless, it is two status flows
00:01:20 that we track on, and we will also trigger some transportation on that. In our big picture of the
status flow,
00:01:29 you can see on the level of the work item that we have the status To Be Tested.
00:01:36 So, the work item is usually in development where the documentation will be prepared
00:01:41 but also the development or the configuration will be done. If a developer thinks he would be
ready,
00:01:47 he hands over to the status To Be Tested. With that - remember we talked about it in the last
unit -
00:01:55 we will already release some transports into the queue system. So, now it's the task of the
tester
00:02:01 to test, according to some test instructions, what has been developed. If he thinks it's okay, he
just confirmed
00:02:10 by setting the status, Successfully Tested. If all of the work items are successfully tested,
00:02:16 the appropriate work package is also automatically set on the status To Be Tested. On the
level of the work package,
00:02:25 we will then continue with signel functional tests
and acceptance tests, but this usually takes place at the end of a wave,
00:02:32 and not for each sprint, of course. And you also can see: We have a specific test phase later
on,
00:02:40 when we hand over the release, so this is then more the integrational tests
and the regression tests,
00:02:46 but as I said, more about that in the next week. What are you doing as a developer now to
hand over for unit testing?
00:02:57 Usually you take your work item and you just set the status Passed To Test.
00:03:02 With that, we release this transport of copies
into the Q system. So now the unit tests can take place in the Q system.
00:03:10 Of course you can also decide to just do them in the development system - wherever.
00:03:16 In our Readiness Dashboard, we will see the effect of the status change immediately.
00:03:21 So, the development tile is then automatically counted here as completed. So if you pass to
test, it will be counted here as completed.
00:03:32 We definitely recommend that a tester and a developer should be different persons, so in the
system you can even activate here
that you will get a warning

23
00:03:41 if the tester is the same person as the developer. You can ignore it, but at least you get a
warning here.
00:03:51 To do the unit test now, the tester would also find this work item in his work list and he just
reads the test instruction
00:04:02 in a text that has been provided by the developer. So, this is optional, but it helps a little to
communicate
00:04:09 on the level of the work item, if they're maybe not sitting close to each other.
00:04:14 If the functionality works as expected, or whatever has been developed,
00:04:19 he can then confirm with Successful Test status. In the Readiness Dashboard, this will also be
monitored.
00:04:28 We will later see that in the next status here for unit test, it will be counted as completed.
00:04:36 That way, even in the Solution Readiness Dashboard you always have an overview of
progress on your work items and tests.
00:04:45 At the end of all of your sprints, it's certainly relevant to check if all of your technical design
documents
00:04:54 are there, if your development is completed and all unit tests are completed.
00:04:59 So this kind of quality gate, you can easily just monitor here, based on the Solution Readiness
Dashboard.
00:05:09 So, let's have a look at how we can run the unit tests in the system. As we learned in our
previous unit,
00:05:20 we have done our development in our managed system. From there, we have released the
tasks,
00:05:27 and we are now back in the system, at the level of our work item. We can now use the Text tab
to inform or give some simple guidance to our tester.
00:05:43 I'm just creating here a new text type ... We could select the test instruction we have prepared
here for you,
00:05:52 and just use the text format to write any quick guidance on whatever should be tested.
00:06:02 We select Save, and with that we have at least a little guidance
00:06:07 without an over-structured test case production. But for a tester, a little hint on how he should
perform.
00:06:16 Then we set the status, down there in our action area, to Pass to Test. And you can see now
the status of our work item is To Be Tested.
00:06:31 If we have a look in the Transport tab, we also can see that now the relevant logon system
00:06:37 has now changed to the Q system. So, in our previous unit it was still Development here,
00:06:42 but now we are here on the level on the Q system. So, this is also a good hint:
00:06:47 When the tester now starts testing, he would immediately log in directly
00:06:51 from this tab into the system to perform the test. We should check in the details if we have
nominated a tester for it.
00:07:02 So, let's see ... Oh, we have not done that yet. So, it's pretty easy: just in the header data, we
go on Change,
00:07:08 and will assign a tester who maybe could test my functionality. I select John Lee here, and go
and set it now on Successfully Tested.
00:07:24 So, of course, I don't do it, but it is now the same UI as the tester would use. He would log in,
he would find a work item,
00:07:32 and then Confirm Successful Test. I just skipped these tests now to show you what happens
00:07:37 if we have confirmed the test. So, see: Successfully Tested is now based on the work item.
00:07:47 As we have produced two work items for my work package, keep in mind we have also to
successfully test
the other work item
00:07:55 to continue with our work package. So, let's go to the other work item,

24
00:07:59 the general change, which was called Collection
of test cases. If I switch to another work item, the system will, of course, tell me that I have to
save first.
00:08:11 So, let's do that ... And now I'm on the work item Collection of test cases.
00:08:16 Let's see what happens on the level of the documentation there, because we are using this
work item mainly
00:08:21 to transport our documentation through the branches. We can see here that we have a single
functional test available.
00:08:34 But this work item is still in the status Created, so the first thing we do is we take it also into
development.
00:08:43 That's the same status flow as in our normal changes, which includes transports. So, we start
development and with that, my buttons are active.
00:08:56 Now I switch back to my single functional test, mark it, and it's still in copy editing,
00:09:03 but of course now it should be ready - I should finalize it. So, I could work on this document,
00:09:09 on the test case and finally, set the status to Released. So, that means, as you can see, it's
still possible to work on the documents
00:09:20 that we have assigned on the work package, but still continue working on them on the level of
the work item.
00:09:26 So it's not necessary to go back to the work package to process them, because in the end, it's
the same document
00:09:32 as we are just using the reference to these documents - they are stored in the Solution
Documentation.
00:09:38 So, I have now set the status to Released, and, just so that we see what now happens to our
related documents -
00:09:49 our work package for instance - when we now transfer to test - so, this is the first step -
00:09:56 but finally, of course, we would like to confirm test. In this case, such a work item doesn't really
need to be tested,
00:10:04 but nevertheless, we also need the status to have it completed. So, Confirm Success of Test,
and you will then immediately see
00:10:12 what happens to the status of my work package which is currently in development.
00:10:18 When I set Confirm Successfully Tested, my related work package will immediately switch to
To Be Tested.
00:10:25 Now we continue working on the level of a work package. We can open it here, and also see,
that is the status of my work package.
00:10:38 Let's go back again to our work item, just to show you some additional features
00:10:42 that are optional: They can be used, but are not mandatory. We have a tab which is called
Tasks in the work item.
00:10:50 So, with the task, it is possible to define further sub-tasks for each work item. That might be
typical tasks that you can process in one day,
00:11:01 so you can do in your scrum meetings, your daily meetup, and check the status of your tasks.

00:11:09 These tasks are pretty easy, so we just provide here a title that you can maintain.
00:11:16 You can select a priority. You can select who is the current processor of it - maybe here John
Miller -
00:11:29 and a short description, if you want. So, this is one task, and this way, you can also subdivide
your work item
00:11:36 into further tasks - like this one is now a check for the authorization that has to be done. Also
here we set a priority and a processor,
00:11:53 a short description ... and that's it. That is an option that you have to use further tasks.
00:12:00 And later on if you maybe use a scrum board tool that can be integrated with the solution
manager,

25
00:12:06 it is then easier to also manage the tasks on such a scrum board view. Another tab that we
already know from a previous unit is the F4 tab,
00:12:16 from the work package, we know it already. But the work item works pretty much the same.
00:12:21 To just record the efforts that I had, but maybe here more from a development perspective, I
just can track them here
00:12:29 with my role, a short note for configuration, how many hours did I use ... and on which date.
00:12:45 Save ... and that's it. Also this data will be aggregated later on in our project plan,
00:12:51 so I can monitor what were the efforts. Let's go back in the details
00:12:57 and also here we have one field available, which is the completion rate
00:13:01 where you can manually define what percentage of the work item is now done, from your
perspective.
00:13:08 So we decide it's 80% and we save that. With this, the processing of the work item
00:13:19 is finished, and we will later on continue with the testing. But before we go, next week, to the
testing,
00:13:26 I would like to show and summarize all the things that we have now produced, and how we
can monitor them in the Solution Readiness Dashboard.
00:13:34 But this is something for our last unit of this week. Thank you for your attention, and goodbye.

26
Week 3 Unit 6

00:00:06 Hello everybody, welcome to unit six of week three of this openSAP course
00:00:11 about Agile Delivery with Focused Build. In this last unit of this week, I will give you an
overview
00:00:20 of the Solution Readiness Dashboard again. If you remember in week one, you were already
introduced
00:00:26 to the Solution Readiness Dashboard - more from the project management perspective.
00:00:31 But now we will see how all the activities that we have now done over the last units can be
monitored
00:00:38 and tracked with the Solution Readiness Dashboard. By now, you definitely should know our
status flow.
00:00:49 But this time I have added some milestones that are relevant for us. And these milestones are
dependent on the status changes
00:00:58 that we are doing between these steps - for instance, when we are uploading certain
documents,
00:01:05 or when we change the status from Created into Scoping, or from Scope Finalized to To Be
Developed.
00:01:13 The same happens, of course, also on the level of our work item. So when we are in
Development and Handover for Testing,
00:01:21 or even when we have Successfully Tested, these are all milestones that have a direct impact
on our KPIs on the dashboard.
00:01:33 We can see here how these milestones are influencing our dashboards. So for instance, the
Requirement reviewed milestone
00:01:43 that we have maintained in the project plan is directly influencing our Requirements Backlog
KPI in the dashboard.
00:01:52 The ones in red are even also combined with our milestone in the project plan. So for instance,
we have defined a milestone
00:02:02 which was called Functional specification completed, with a certain date, and this is now
shown in the dashboard
00:02:09 if the functional specification was really delivered in time, or if it's maybe overdue. So this
appears either in a green or yellow bar,
00:02:19 or if it's overdue it will appear in a red bar. The same happens of course also
00:02:25 for the availability of our technical design documents. Even here we have decided about a
milestone.
00:02:32 And we can now track in the dashboard directly if these documents have been provided on
not.
00:02:38 Other KPIs are maybe not rated against the due date. But we only check if the current wave
00:02:46 is already in a certain status or not. Or similarly, if a unit test is completed or not.
00:02:54 Here we can see which impact they have then directly in the Readiness Dashboard. The first
ones - like the work packets and the work items -
00:03:02 just show the amount of work packages we have. So you see the KPI is also in a neutral blue
color, same for the work items.
00:03:12 But if we look at the functional specification here, which is combined with the milestone that we
have defined
00:03:20 we can see that we have either Completed, To be done, or Overdue. So here we see them
overdue if the milestone is already reached
00:03:30 but the functional specification is maybe not yet provided. Those that are completed, like a
function specification,
00:03:38 are assigned to the work package, and in time would appear automatically here,

27
00:03:43 and show the percentage of those that are completed. Those that are to be done, but the
milestone is maybe not yet reached,
00:03:52 will appear here in this middle bar. And the same rules are, of course, valid for our technical
design.
00:03:59 And we can also see, based on the milestones, if the status of our work item is in Passed to
Test for development,
00:04:07 or even Successfully Tested, and we would see it for the completed unit tests.
00:04:14 Let's look at some examples in this Rreadiness Dashboard. So when I click here on the work
package tile in my Readiness Dashboard,
00:04:24 I will get a list of work packages here in a subwindow which shows me all the work packages
in an overview.
00:04:34 I can then also click and find the details about them. I have here the direct link,
00:04:39 and I can see that the status of my work packages are as follows. Sometimes you see that
statuses are aggregated.
00:04:49 Even in this table view, I can already see how many work items
00:04:54 are directly connected to my work package. So this gives me just the information about my
work packages.
00:05:02 If I now have a look in the tile of the functional specification, here, also, I would get a list of
work packages,
00:05:11 because this is the document type which typically applies to my functional specification.
00:05:18 So here I get all of the list, depending on if I have clicked on Completed. And I would get all the
work packages
00:05:25 where the functional specification is provided. Or I click here on Overdue,
00:05:30 which shows me the percentage of functional specifications that are overdue. In this case,
maybe three of 30 functional specifications are overdue.
00:05:40 So I got 10% here. Then this list is shown here - these three are shown here - and I can see
the date,
00:05:48 or the milestone, which was relevant for it, and I might be overdue. So I can then navigate from
here into the details, to follow on.
00:05:58 The same is relevant also for the technical design. But if we click on the Technical Design,
00:06:03 we typically would be navigated into the work item list. So here we can see that this work item
in the status To be done
00:06:12 maybe does not have the status In development, or even the technical design hasn't been
assigned to a work item,
00:06:20 or the document has not even been released. So you can see sometimes these statuses here
00:06:26 are aggregated depending on their different statuses. The meaning of the Development tile:
00:06:35 it shows me how many of my work items are completed, but in terms of ready from a
development perspective.
00:06:44 So he passed it over for testing, so therefore it is completed from his perspective.
00:06:50 The Unit Test is then showing me if this work item has been successfully tested. So this is then
shown here in Completed,
00:06:57 and mapped against the milestone of unit test completed. You remember we entered this
milestone in unit two of week one.
00:07:08 The follow-up tests, like for single functional tests, or functional integration tests, are then on a
very high level shown here in this KPI for the test status, shows me
00:07:21 the percentage of all successful tests, and the Defect Details shows me only those in priority 1
and 2.
00:07:30 A much more detailed overview about the test status is then shown in the Test Management
Dashboard,
00:07:37 which we will explain in the next week. Let's have a look in the system and see

28
00:07:43 how the Solution Readiness Dashboard works. We will start again in our launchpad.
00:07:54 And this time we will move into the group of an architect. We have positioned the Solution
Readiness Dashboard
00:08:02 not only in the group of the project manager, but it's also relevant for an architect, maybe.
00:08:08 So therefore you will find it several times. Let's open the Solution Readiness Dashboard.
00:08:13 And as we learned already in the first week, the first view is the one from the program, from
the master project.
00:08:21 So what we could do is we just scroll down and we find all the detailed build projects that we
would like to look at.
00:08:28 So for our project we have used Freight Management - so let's take this one. And I have now
all the data only relevant for my project.
00:08:38 Let's have a look into the Requirements tile
and the KPIs there. If we click here on these requirements that are in progress,
00:08:46 that means all requirements where we have a work package that is not yet completed, not yet
productive,
00:08:53 but still somewhere in the status flow between Created and Handed Over for Release. And we
can see here, just mark it there,
00:09:04 this is exactly our work package that we have created here. So this is our requirement, not yet
our work package.
00:09:17 But it shows the status In progress, because the assigned work package is still in
development.
00:09:27 If we look maybe into the KPI of our functional specifications, like these completed ones,
00:09:35 we will see: Here's the work package that we have used in the previous units. So our work
package to create a new UI.
00:09:44 So let's have a look in it. We create here a new flag for Checked.
00:09:49 This was our the work package we have used. So I can navigate directly out of the dashboard
also
00:09:54 into the details of each work package. Just close this one, and I will be back.
00:10:01 Going into Freight Management in the overview. Now let's have a look at those that are
overdue.
00:10:06 Ours was green: That was go So let's go in the overdue.
00:10:10 And here's the list of all the work packages that have not been delivered a functional
specification.
00:10:17 Let's have a look and just pick one of them and have a look. Take this one:
New_freight_cost_calculation.
00:10:22 And we see already in this indicator of the documentation, with this red flag, something seems
not to be OK.
00:10:30 So open this tab. I usually start looking at the current status.
00:10:34 And I can see there are two documents that should be delivered. the specification,
00:10:39 and it's not even available. If we go back, you can also see, down there,
00:10:46 that there is a specification - from another process, maybe, or from the same process but not
from this work package -
00:10:52 but this is not linked here with this work package. So there's definitely something still to do
here.
00:10:59 Let's close this work package again. In the overview we can now look at the technical design.
00:11:06 Let's have a look at the completed ones. Hundred percent: That looks good.
00:11:10 And we will see: Here are exactly our work items that we have also used in our previous units,
like our developed web service.
00:11:17 Iif we have a look, we can see the status is Successfully tested. And it also, here with this
green one,

29
00:11:25 we can see that all required documents are available. So therefore it is counted in the
completed ones.
00:11:36 From the unit test perspective, we can also check which are overdue. And we will get a list of
all the work items
00:11:44 where the milestone of the unit test, finished, is not yet reached, or even that the appropriate
status is not there.
00:11:55 You can see they're all iI development or in Created, therefore they are not finished yet. But
probably the milestone of it is already overdue, as we can see then there.
00:12:11 What we now could do is maybe we hire a a new tester and say,
00:12:15 can you please hurry up, and just take over on these overdue tests. We have a nice
functionality which is called our mass change app.
00:12:23 And it's integrated here directly in the dashboard. So I just mark now all of these that are
overdue.
00:12:29 And they go to my mass change app - just by clicking on that. So I have selected all of them
into a mass change functionality.
00:12:41 Let's open that. And of course, not everything can be changed,
00:12:45 because they are or might be in different statuses. So this warning just tells me that I cannot
change the status,
00:12:51 but other fields, maybe - which is okay for me. So I would like to change a Partner Function, so
like a user here.
00:13:00 We would like to set one tester for all of these
that are overdue. So let's say this is the tester and we assign here, Marco Rossi.
00:13:09 He's our power tester - so he can hurry up and he can now only focus on those that are maybe
overdue.
00:13:16 So by this nice mass change functionality, it's pretty easy sometimes to exchange a tester,
00:13:21 exchange a developer, setting a status in a mass, adjusting any priorities, whatever.
00:13:28 So this is a pretty helpful functionality if would like to change something in bulk.
00:13:35 Save the changes, and now I have assigned Marco Rossi as the tester for all of these work
items.
00:13:45 Let's close that and go back to Freight Management. Just to keep in mind: When you click on
this information icon here on the tile,
00:13:55 it will always tell you again how these appropriate KPIs are calculated. As I said, sometimes
they will get aggregated.
00:14:03 It is sometimes pretty helpful to read again what does it exactly mean and which work item
00:14:09 or which work package is counted where. Let's close the Solution Readiness Dashboard,
00:14:18 and quickly go back into our project plan. You remember that is here, in our tile for Project
Management.
00:14:27 We open it and we will go into the project that we have used: Freight Management. Let's open
that, to see the efforts that we have maintained in our work packages and work items.
00:14:41 We have to go in the UI of the ITPPM. So this is not available here in our Gantt chart view, but
in the details.
00:14:49 Ttherefore, we just click on the link of the project itself, and it will open another window where I
can see
00:14:57 the underlying UI of the ITPPM, with much, much more information and details.
00:15:04 In this UI, we now can see that we have here tabs assigned to our project which are called
work packages.
00:15:12 And when we open them, we will now see all the work packages that are assigned to this
project, in a summarized list.
00:15:22 And what you also can see is: The actual work is aggregated. And, if you remember, here is
also our work package that we have created.

30
00:15:31 And it includes a percentage and some information on how much work has been maintained in
the Effort tabs.
00:15:40 So this is now aggregated here. The other work packages did not have any information about
that.
00:15:46 But you have the aggregated view here, as well. If I switch into this development subtab here.
00:15:56 I've got the same information now, on the work item levels. So you see here's the list of the
work items that we have.
00:16:03 And also here is our work item of Develop WebService. And we have, if you remember right,
maintained here two or 16 hours,
00:16:12 which is, concatenated, two days of work. With that I hope I could introduce to you
00:16:26 the main monitoring or tracking functionalities
of Focused Build, which is our Solution Readiness Dashboard,
00:16:33 and some features here, in the project plan. There are further dashboards - like the release
dashboard
00:16:39 and the test management dashboard - but they will be introduced in the following weeks.
00:16:44 I hope you enjoyed this week three about Realization, you could learn how a developer or a
configuration consultant
00:16:53 is using the functionalities of Focused Build. Stay tuned for week number four.
00:16:59 I can say goodbye.

31
Week 3 Unit 7

00:00:05 Hi, welcome to the seventh unit of our week three, where we are talking about the realization
00:00:11 in our openSAP training for Agile Project Delivery with Focused Build.
00:00:15 My name is Jörg Marenk, and I'm working as a product manager and expert support engineer
at SAP.
00:00:21 So what have you already learned this week? So you got information about the different
activities
00:00:27 that an architect or a developer is actually doing in our Focused Build scenario.
00:00:32 And now in this last unit of this week, I want to tell you something
00:00:36 about the SAP Readiness Check integration in Focused Build, because it can be seen also as
an additional starting point
00:00:43 for the Requirements-to-Deploy process for those customers who want to do a current version

00:00:47 of their SAP ERP system. So first of all, I want to tell you something
00:00:53 about the need to move to SAP S/4HANA, and of course, now, the earlier you do it
00:01:00 the better it is, but of course, also, then, in the upcoming months and years.
00:01:04 So we have at the moment there identified five realities. First one is, you, as a company,
00:01:10 need to innovate before your competitors. So we are at the moment in the phase of a recovery

00:01:16 from the COVID-19 pandemic, and we have already seen in the past recoveries
00:01:20 that those companies were the winners of these recoveries that reinnovated their business
00:01:25 much faster than their competitors. So with the help of a modern ERP system,
00:01:32 you will be able to apply advanced technologies and best practices
00:01:36 within agile business processes to make organizations more resilient, more profitable,
00:01:41 and, of course, at the end, also more sustainable. Then we are also running in uncertainty.
00:01:48 So because of the COVID-19 pandemic but also other economic challenges,
00:01:53 we need to have an ERP system in place that provides instant access into your organization.
00:01:59 So you need to have a look at your end-to-end business processes
00:02:03 on a daily basis, more or less, so that you can always analyze, collaborate,
00:02:09 prepare, and plan for what's next, and then, of course, also derive decisions based on that
00:02:15 so that you can act immediately on certain changes, and also from anywhere you need to do
this act.
00:02:23 Then, of course, you need to save costs. So here, a modern ERP system delivers intelligent
automation
00:02:30 across your entire business. That means with the help of artificial intelligence,
00:02:35 with the help of machine learning, you have the possibility to get more improvements
00:02:40 in the productivity, and also at the end, in the efficiency, and there, an ERP system should help
you.
00:02:47 Then we also see a pivot at market speed. So we have unpredictable changes.
00:02:52 So maybe there's something in your supply chains that is going wrong,
00:02:55 or your key product demands are changing, and then, of course, you have to reorganize
yourself.
00:03:01 So you have to reallocate, for example, resources to your new priorities,
00:03:08 and you have to quickly adapt to these disruptions. And this must be also done with the help
00:03:14 of a modern ERP system. And then, of course, you have to move to the cloud.
00:03:19 So also this crisis has shown, or has actually accelerated, also,

32
00:03:23 the need to go to the cloud. SAP has also adapted here its strategy,
00:03:29 and we have now new consumption models in place that are helping our customers
00:03:35 to move their current ERP investments that they are having into a cloud investment,
00:03:40 and to focus really more on the business that they are driving.
00:03:45 So when you now want to go to SAP S/4HANA, you have different options,
00:03:49 so which one is actually the right one for you? So that's something that you can decide.
00:03:54 So we have the new implementation, for example, also called a greenfield implementation.
00:03:59 So you build a completely new S/4HANA system besides your current SAP ERP system,
00:04:05 or even a non-SAP system. And then, at a certain point in time,
00:04:09 when your S/4 system is ready, then you either go for a big bang scenario,
00:04:14 which means all your users are going to the system at the same point in time,
00:04:19 or you're doing something like a phased approach, if you're saying okay, first of all,
00:04:23 maybe we go with our finance department to that system, and afterwards, maybe a month
later,
00:04:28 we are going with the logistics team to that system, so it's a more phased rollout approach.
00:04:34 Second option is the system conversion. So here, you are taking your existing SAP ERP
system,
00:04:41 and then technically, you convert it into an S/4HANA system.
00:04:44 So system conversion is a one-step procedure, which means at a certain point in time,
00:04:49 all users are shifted from your so far existing SAP ERP system
00:04:54 to this S/4HANA system. And the third option that we have
00:04:58 is the selective data transition. So here, you decide that you want to take over, maybe,
00:05:02 some of your relevant business data from the SAP ERP system to the SAP S/4HANA system.

00:05:08 And with the help of this selective data transition, you're balancing a little bit
00:05:12 the advantages that the new implementation, that the system conversion is actually having.
00:05:20 Independent from which option you are choosing, Focused Build supports you in all three
ways.
00:05:26 So the new implementation, you have heard a lot about this already,
00:05:30 with the Requirements-to-Deploy process, we are supporting that step.
00:05:34 And this Requirements-to-Deploy process is available since SP0 of Focused Build.
00:05:39 Then we have the system conversion. Here we have the upload of the simplification items
00:05:44 and conversion activities available as of SP6 of Focused Build.
00:05:49 And also we are supporting selective data transition as it is a tailored approach
00:05:52 between a new implementation and a system conversion. The only thing you need to know
00:05:57 is that the data migration from ECC to S/4 also requires, at the moment, an additional data
migration
00:06:05 and landscape transformation service. So let's talk about the system conversion more in detail.

00:06:11 So first of all, we need to know, or you need to know, how to get to the information
00:06:16 what you need to do to convert your ERP system. So that's why first, we are analyzing
00:06:21 your existing ERP system. It means everything is checked,
00:06:26 which transactions you are starting, which reports are running.
00:06:30 And this information is collected, and then we compare this information
00:06:35 against the so-called simplification item database. So here we have, in this database,
00:06:40 we have all the different conversion activities in place that must be done,
00:06:44 we call them simplification items. And we compare this now with your system

33
00:06:50 so that you really then get at the end a result list which is really tailored to your system.
00:06:55 So you are not getting, like, 600 simplification items and 200 of them are not relevant for you,
00:07:00 you are only getting a list which is relevant for you. And this you can then access in a
dashboard.
00:07:06 So you are uploading this to a cloud solution, and then you have there an interactive
dashboard
00:07:12 for an easy analysis. And this analysis is our so-called SAP Readiness Check.
00:07:19 So there we are providing quite a lot of information. I'm not going through all of them,
00:07:25 but maybe the most important ones. So for example, we are checking
00:07:28 which business functions are active in your system, and which of them are compatible within
the S/4HANA system.
00:07:37 Same also for add-ons that you may have installed. Then we're talking in a few seconds
00:07:42 more about simplification items for S/4. Then we're also checking custom code.
00:07:48 So whenever you are maybe in your custom code calling SAP code,
00:07:52 it might be impacted with the new S/4HANA system,
00:07:57 we are also displaying that information. And you've got information
00:08:01 on how you have to size your S/4HANA system, so based also on the data, to be expected
database curve,
00:08:07 based on the users, maybe, that are working on the system you are getting recommendations

00:08:11 on how the sizing of your system should look. And now, how does the integration of the
Readiness Check
00:08:18 that you have then analyzed in Focused Build, look? So the Readiness Check, after you have
gone through that,
00:08:24 after you have seen all the information that is provided there,
00:08:28 you have the possibility to export that in a zip file, and the zip file contains quite a lot of Excel
files.
00:08:36 And we are now taking this zip file and import it into our Simplification Item Management UI5
application.
00:08:45 But then you have there all the simplification items, all the related conversion activities,
00:08:50 and then you can start with the evaluation and the categorization of the activities,
00:08:54 because we have there also different attributes for these ones.
00:08:57 And then, based on your evaluation and categorization, you can then decide, is it an Focused
Build project?
00:09:03 So when we are talking about simplification items with an huge implementation effort.
00:09:10 Is it a requirement? If you say, okay, first of all,
00:09:14 we need to let the business decide whether we really need that simplification item
00:09:18 covered in our conversion project, or whether it's directly a work package.
00:09:22 So with this, for example, if you need to do a certain data correction inside your system
00:09:27 otherwise the conversion would not work, then we would actually directly create
00:09:31 a work package out of it. But the simplification items and conversion activities
00:09:39 to have them inside the Solution Manager is just one part.
00:09:42 So in this slide, I actually want to show you all the different functionalities, also inside Solution
Manager,
00:09:47 that are helping you inside your conversion project. Also the selective data transition
00:09:53 is also slightly supported here with this overall architecture,
00:09:58 and this I just want to show you. So actually, what we need to bring together
00:10:03 is our Solution Manager with Focused Build. Then we have the SAP Readiness Check,

34
00:10:08 this integration I already talked about, but also the different roadmaps that SAP is providing,
00:10:14 for example, the roadmap for S/4HANA Cloud, private edition.
00:10:20 So let's start with these template project plans. So we are having our activate roadmaps,
00:10:26 so as I said, for example, for the private cloud edition. And there's always a possibility to take
these roadmaps,
00:10:32 to take these template project plans, and bring them into the Solution Manager.
00:10:37 So there's an upload functionality in place, and then you will have this template project plan
00:10:43 as the starting project plan inside your Solution Manager system.
00:10:47 We have the different activate phases. We have the Activate task.
00:10:50 We are just enhancing that with the wave and sprint information.
00:10:53 You have seen this already in the second week of this openSAP training,
00:10:58 what this is about, because later on, we need to assign
00:11:01 work packages and work items to these waves and sprints.
00:11:06 Then we have the Readiness Check integration. It means we take the Readiness Check
00:11:10 and create the simplification items and conversion activities
00:11:13 inside our Solution Manager. And then, as I said, we are starting with the evaluation.
00:11:18 So you are creating requirements, or directly work packages out of these conversion activities.

00:11:24 And of course, we are assigning these work packages, then, to the wave of our project.
00:11:31 Then we have also available, from SP8 onwards, we have the possibility to do an iterative
wave planning
00:11:38 based on the conversion phase of the activity. So there you need to know there are conversion
activities
00:11:43 that you need to do before a conversion starts. There are conversion activities
00:11:47 that are to be processed during the conversion and also after the conversion.
00:11:53 And we are now taking that information about the phase of the activity.
00:11:57 We take, then, based on that, the related work packages, and then hand them over to the
mass change application.
00:12:03 There you can assign them to the corresponding wave and then you can continue.
00:12:07 So this really helps to do the wave planning in a more efficient way.
00:12:12 Then the second, or the next, step that we need to do is we need to assign now to the work
package
00:12:18 the business process, the business process step that it is affected by that.
00:12:23 So here, always, customers are asking us, "If I don't have such a process management in
place,
00:12:29 how do I get there in a quick and efficient way?" So here, I just mention three possibilities.
00:12:36 The first one is the library generation. So here you have, then, the possibility
00:12:40 also based on the usage in your system, to generate the executables and development library
00:12:47 inside your Solution Manager, or you're uploading best practices
00:12:52 or model company content, where you get, then, pre-defined business scenarios
00:12:57 with business processes and process steps. So based on that, you have, then,
00:13:01 your individual process management, independent of whether you use now way one or way
two.
00:13:08 And then you have the possibility to assign this process, process step, or an executable to the
work package.
00:13:15 Then, with that, it is possible to upload, for example, a design document
00:13:19 like a functional specification, or the test case, which is later on required
00:13:23 during the test management. After we have done that,

35
00:13:27 we are breaking down, now, the work package into one or several work items,
00:13:31 depending on how big it is and how many developers are working on it.
00:13:35 And of course, also, this one needs to be assigned to a sprint.
00:13:41 Then, also important to know for the system conversion, there we usually have several
iterations of a conversion,
00:13:48 so usually the production system is copied into a sandbox system,
00:13:52 then the conversion is practiced, you know, doing there some additional transport requests
00:13:56 after the conversion to get the system up and running,
00:13:59 and this is done by the customer several times. And in this special phase
00:14:04 where these sandbox iterations are also done, we are supporting there the transport handling
00:14:08 with the help of the retrofit functionality inside Solution Manager.
00:14:13 Of course, also, all these sandbox iterations you need to test there some things,
00:14:17 so that's why we have the whole test management again, also in place.
00:14:22 And also the good thing is the different roles inside the systems
00:14:26 are performing their steps as usual, and in the background, we are collecting all this
information,
00:14:32 and providing then there, accordingly, the dashboards. So we have the Documentation
Reporting Dashboard
00:14:37 where you can see what's the status of your process documentation at the moment.
00:14:42 we have the Simplification Item Management Dashboard where you see how is the course of
the processing
00:14:47 of the conversion activities, and of course, Solution Readiness Dashboard
00:14:51 and Test Suite Dashboard to see what is the status at the moment, for example,
00:14:55 of the current test plan. All right, then, let's have a look at the system
00:15:01 how it looks. So we are starting.
00:15:10 And we are moving down, first of all, to the area of the conversion project,
00:15:14 and we are starting the Simplification Item Management app. And here we have a look at the
simplification items
00:15:20 and conversion activities. So here you see already
00:15:22 that we have quite a lot of conversion activities. And let's say, okay, I'm just responsible for
finance,
00:15:30 so that's why I want to filter here first of all. So in the LoB dropdown, I select Finance.
00:15:37 In the Business Area, I select Cost Management, Accounting, and Financial Operations.
00:15:43 And let's check also on the phase, so I am interested in the activities that need to be done
00:15:47 before, or before or during a conversion project. So then you see, okay, it's just 15.
00:15:55 And now let's scroll down, and let's have a look here
00:15:58 at the Conversion to S/4HANA Material Ledger. So here, first of all, I am going to say,
00:16:04 okay, this one is not so important for me right now, so that's why I'm going to postpone it.
00:16:11 And the status of that is also reflected. Let's move up.
00:16:16 So here we have an conversion activity which has the type Process Design/Blueprint,
00:16:21 So here, first of all, it seems that we need to involve our business, also,
00:16:26 to check for that. So this is then usually a requirement.
00:16:31 So I'm selecting here as the follow-up type Create Requirements. Then I click on Save,
00:16:36 and then you see the requirement is created. It's linked also to this conversion activity,
00:16:41 and the status of the conversion activity has changed to Follow-Up Created.
00:16:47 So let's select two other conversion activities. So here we have something with data correction

36
00:16:53 and data cleanup, so this seems to be a good example for a work package.
00:17:01 We can also here select the work package classification. In that case, it's WRICEF.
00:17:08 And here, it just gives me a warning that the title of the follow-up document should be unique,
00:17:13 so I'm renaming it to part one and two, and then click on Save.
00:17:19 And then also here, you see that the work packages are linked
00:17:23 and the status has been updated. Okay, then let's check how the work package looks.
00:17:30 So we go into the My Work Packages application. We check in the Texts field, okay,
00:17:35 all the text information is taken over. We have, in the attachment, also the linked note,
00:17:41 so there's always a note existing for the different simplification items
00:17:46 that are describing what you need to do and what's the solution for these simplification items.
00:17:51 So we are including that information as well. And as said, we have direct relation
00:17:56 between the work package and the conversion activity. So now I just want to change here
status.
00:18:04 I just want to make clear to you how good this integration also looks
00:18:09 when we are updating here the work package. So I'm assigning a project and a wave.
00:18:16 I then click on Save, and then I'm changing the status to scoping.
00:18:23 And then with that change of the status to scoping, we are also updating, then, the conversion
activity.
00:18:30 As you can see, the status of this one is now In Realization.
00:18:36 All right, then back to the slide. So this is just a demo of how it looks in SP7.
00:18:44 So in the meantime, then, when this openSAP training here is running,
00:18:48 we have then also launched at the beginning of August SP8, and there we have included
some more functions
00:18:55 inside this Readiness Check, in the creation. So we have there more flexibility options.
00:19:00 So you have seen that you could, in this demo, you could only see
00:19:04 that I could create a requirement and work package one-to-one relationship
00:19:08 between conversion activity and follow-up. So with SP8, it will be possible
00:19:13 that you also combine several conversion activities if they have a small effort,
00:19:17 or if they are logically belonging to each other, in one follow-up document.
00:19:23 Then in case you forgot to assign a conversion activity to a follow-up,
00:19:28 you can now do this. Or if you have done an assignment wrongly,
00:19:31 you can also reassign conversion activities from one follow-up document to another one.
00:19:37 We have integration in the mass change application, I already mentioned that.
00:19:40 And we have also the possibility to integrate custom transaction types.
00:19:44 So we know that we have customers that have a mature change request management process
in place,
00:19:50 and they don't want to use, for their S/4HANA transition, they don't want to use a new
methodology with Focused Build.
00:19:58 They want to use their change request management processes, and this is also possible with
SP8.
00:20:04 And then the last one, that we're also providing some logging information.
00:20:07 So in case something is going wrong when you create your follow-up,
00:20:10 for example, you are not authorized to do that, then this information will be provided.
00:20:17 All right, and with that, we have made it through the whole week three.
00:20:22 So now the next unit is just some slide deck information, what has changed in the meantime,
since SP3 up to SP7.
00:20:33 And then I wish you now good luck for the weekly assignment,

37
00:20:36 and then I hope you will join us also, then, next week, when we are talking about test
management.
00:20:42 All right, then, have a good day. Thanks for your attention. Bye-bye.

38
www.sap.com/contactsap

© 2021 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary softwar e components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express war ranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this docume nt or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or plat form directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time fo r any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trade marks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.