openSAP Agile Project Delivery with Focused Build for SAP Solution Manager (Update Q3/2021) Week 2 Unit 1

00:00:06 Hello and welcome to Week 2 of this openSAP course on Agile Project Delivery with Focused

Build

00:00:12 for SAP Solution Manager. My name is Stefan Koerner,

00:00:16 and I am an SAP ALM expert, and I will be your host for this unit and for this week.

00:00:24 This week consists of five units and focuses on the activities of a process expert

00:00:30 using Focused Build during the explore phase. So let's now start with Unit 1,

00:00:36 in which I will talk about the basics of Solution Documentation.

00:00:44 So, let me start from the Focused Build process flow in order to introduce Solution Documentation.

00:00:52 The full picture was explained at the beginning of Week 1 already.

00:00:57 So I want to focus on the typical activities of a process expert or a business process owner.

00:01:05 This might be also your role currently in a project at your customer or your company.

00:01:14 You might lead the fit-to-standard workshops in order to review business processes

00:01:20 or model and redefine them if necessary. Your activities will be supported

00:01:28 by the Solution Manager documentation functions, and this is what I'm going to show you now.

00:01:39 So what do we think about your responsibilities, basically, and tasks in your role as a process expert?

00:01:48 You should know the business needs and you should be able to communicate

00:01:54 and translate them into the project team. So you are responsible for the documentation

00:02:01 of business processes and use cases. So with your participation in fit-to-standard workshops,

00:02:10 you will design future processes and applications together with the project team.

00:02:18 So, end result, you will follow certain project principles in order to produce process descriptions,

00:02:25 maybe also BPMLs in SAP Solution Manager. And you will focus

00:02:34 on the usage of Focused Build functions to document all necessary information

00:02:39 for requirements to be implemented with your project. So since I already spoke about Solution Documentation,

00:02:52 you might know that this is very important in your project and also with Focused Build,

00:03:02 based on that picture here. In general, what is a solution all about?

00:03:08 The solution in an SAP context contains the complete business description,

00:03:14 the complete system landscape or business processes and their versions.

00:03:21 That's it, that's the solution. Everything you have is one solution.

00:03:26 You don't have many solutions, you only have one solution. The term Solution Documentation means, for example,

00:03:37 all the artifacts, documents, diagrams, test cases that you create doing your project,

00:03:45 and it allows you to structure and organize process models on as many levels as required.

00:03:54 With Focused Build, we deliver already documentation templates

2

00:03:59 that will help you to standardize the documentation produced by your project.

00:04:08 We see the other term of branches. The term branches is used to separate different versions

00:04:13 of Solution Documentation. For example, a production branch

00:04:18 will only contain productive documentation. And other branches, like development or design,

00:04:27 will contain information about to-be processes and applications that are to be built

00:04:33 or currently under construction. And what are those terms of change control landscape,

00:04:41 system landscape, and sites all about? You could say that is the technical basis

00:04:50 for any business process, and the use case is described by the Solution Documentation.

00:04:57 Especially with sites, you can tag which documentation content is relevant

00:05:02 for a specific location and it offers access to the corresponding systems.

00:05:14 In Solution Documentation, you need to know the term of libraries.

00:05:20 This can be the library of business processes, business process steps, interfaces,

00:05:28 which is more function-oriented and independent from the business context.

00:05:35 Those might be reused in various end-to-end processes, for example.

00:05:42 Then we have the documentation and about the development libraries,

00:05:48 so documentation about development objects, which is more component-oriented,

00:05:55 as well as the executable library. It contains all technical objects and their documentation.

00:06:03 It might be, for example, Fiori applications or specific programs.

00:06:13 The configuration library then provides reusable configuration elements

00:06:19 or building blocks for configuration tasks like, for example, typical IMG activities

00:06:26 in an S/4HANA system. And the library of processes

00:06:34 is the business-oriented documentation of processes. So, you'll build those based on the various process steps

00:06:42 and interface in your libraries. By that, all the relevant technical information

00:06:48 will be linked automatically. As I have already mentioned to you,

00:07:00 you can reuse documentation templates from Focused Build. So those are templates for

00:07:09 functional specification documents, for example, configuration guides, or test case descriptions.

00:07:17 And with Solution Manager, you can clearly define

00:07:22 for which elements of your Solution Documentation those can be used.

00:07:28 So in your build projects, you can also find out, for example, what documents are expected but missing.

00:07:39 So, this is a very important feature of Focused Build as well.

00:07:45 Since it is, for example, controlled by a KPI framework which documentation must be delivered

00:07:51 in a certain stage of a build activities. In Unit 3 in Week 6 of this course,

00:07:59 we will explain some more details about the administration of document types

00:08:04 and templates, as well as the documentation, the KPI framework itself.

00:08:15 Now let's go to branches for Focused Build. The following branch setup is required and recommended.

00:08:25 So, let me start with the production branch. You will always have a production branch,

00:08:31 and that will represent the productive solution at the end. So when starting, for example,

00:08:38 your S/4HANA implementation project, you take care of the import of

00:08:45 best practice documentation package from SAP Activate or Model Company

00:08:51 into the input branch first. Within the environment of the design branch then,

00:08:59 you will start designing your operating model and processes, and you will have documentation of requirements

3

00:09:10 right through the functions of Focused Build. And in the context of the development branch,

00:09:18 you will then build the defined operating model, processes, and systems of application behind.

00:09:27 And hereby, everything you do is change controlled in order to make sure

00:09:33 that the delivery of documentation content to the productive branch will be complete.

00:09:40 So, overall, we recommend at least the four-system landscape,

00:09:47 maybe plus a sandbox system for an S/4HANA implementation project when using Focused Build.

00:09:54 And those physical systems are represented by logical component groups in terms of Solution Manager.

00:10:08 It is somewhat important that you learn how to work with the Solution Documentation interface.

00:10:18 As you see here on the slide, on the picture, on top of the header, it shows information

00:10:26 about the solution name and the branch you are in. For example, as you see here,

00:10:33 the Global Functions provide an access to embedded search functionality,

00:10:39 as well as different views like browser, list, and reports. And right below, there is a breadcrumb,

00:10:51 and this shows the last navigation path to the last selected structure in the

00:10:58 element in the column browser. So what is a column browser all about?

00:11:04 The column browser in the middle section, as you see here,

00:11:09 is your main area to review or maintain your Solution Documentation structure.

00:11:16 So here you can browse, for example, through your libraries.

00:11:20 And when browsing through the libraries, when selecting something,

00:11:26 you need to look at the elements list shown below. This gives related information

00:11:33 for a selected structure element, for example. So here you will find further details,

00:11:40 information about diagrams, different documents, the executables and configuration units assigned to it.

00:11:52 On the right-hand side, you will see the Attribute Pane, and this will show further attributes of a

00:11:59 specific selected element. So, here, for example, you can maintain the description

00:12:06 or status of an element or other attributes like people responsible,

00:12:13 site information, and related documents. So, having said that and explained that in a nutshell,

00:12:27 I will show you a demo of what that looks like in a system itself.

00:12:36 Here you see the SAP Solution Manager launchpad. And based on your roles and authorizations,

00:12:44 you are navigating, first of all, to a tile called Solution Documentation.

00:12:50 So by that, you enter the Solution Documentation of SAP Solution Manager.

00:12:57 It opens a screen as you have seen already on the screenshot.

00:13:02 And here, for example, if you navigate to the upper right-hand side,

00:13:09 you can drop down the list of branches that are currently set up for the solution.

00:13:15 And you here you would navigate, switch, and jump through the branches typically.

00:13:24 Let's stay in the design branch here. That's typically where your activities

00:13:30 reviewing the processes starts from. So you see the areas for the column browser,

00:13:37 the area for the attributes and the elements. Currently no element is selected, so this is empty,

00:13:43 but you can maximize or hide some certain areas of the screen.

00:13:49 So, in this example, I want to just quickly show you the libraries.

00:13:53 So if you navigate to the libraries, here's what I tried to explain before.

4

00:14:00 We have well-structured information. You will always have a Process Step Library,

00:14:06 where all the process steps sooner or later will be described and maintained.

00:14:12 You will have the Interface, Executable, Development, Configuration Library.

00:14:17 And if you are going forward, soon or later, you will also have

00:14:21 Analytics and Alerting Library. So in this example,

00:14:29 once the Process Step Library is selected, the perfect starting point is to create folders here,

00:14:37 so structuring items. Let's say we have the predominant modules

00:14:45 also represented in the Process Step Library to make sure later on when you create content,

00:14:51 when you create your own process models, for example, and creating process steps,

00:14:56 you should always think about linking them to the functional areas you are working in.

00:15:04 When working with SAP best practices and processes, you will normally find a folder like this here

00:15:12 for the SAP Best Practice Process, and there all the steps are collected

00:15:16 that come with the Best Practice Package from SAP Activate. Further on, the other part of the libraries

00:15:26 is more for the business end users. So this is describing the business processes.

00:15:34 And your first activities could be reviewing the content that will scope based on the SAP Best Practice Import.

00:15:44 So, let's say there was already the import into the import branch of Solution Manager,

00:15:53 and based on the scoping that happened in the prepare phase,

00:15:57 already the scope items, so the best practice processes, like BD3, BD9, and all the others,

00:16:04 are already made available for design, so fit-to-standard workshops

00:16:10 can start right from that information. So you see S/4HANA on premise

00:16:17 and the underlying typical scope items, best practice processes.

00:16:22 Like, in this example, you could say: I want to review BDH - Sales Order Processing for Prospect.

00:16:30 And if you select this, it opens much more information in the elements list below.

00:16:38 So as you see here, you have reference to a lot of building blocks.

00:16:43 So this is activation content configuration packages that you would technically then activate

00:16:52 in a specific sequence, in a specific order in the SAP back-end system.

00:17:00 But right now, I would be, as a process expert, interested in information about the best practice document.

00:17:10 As it was shown here, you can use the filters or the sorting

00:17:16 to get the relevant information. And one could be a link to the document

00:17:24 and the best practice in the SAP Service Marketplace. Here you click on the element itself.

00:17:36 This would start another browser window for example. You see you are somewhere in the Service Marketplace.

00:17:44 This is then showing you a little bit more detailed information

00:17:48 about what this best practice and this sales order processing for prospect

00:17:55 in SAP terms is all about. As you could imagine here, you also have then

00:18:01 access to some more information, like, for example, the test scripts that

00:18:09 you then want to consume already later on. If you leave that screen, back to the Solution Manager,

00:18:20 another important thing is the process diagram. So the process diagram is

00:18:26 straight away available in the Solution Manager itself. So you don't have to consume it

00:18:30 from the Service Marketplace. You will see that sooner and later.

00:18:36 When reviewing the process diagram, you open it so it is embedded in the

5

00:18:44 Solution Manager interface. What you can do here is maximize the screen a little bit,

00:18:50 and then, with plus and minus, scroll in and scroll out. And that might be your starting point,

00:18:59 or I would expect it based on project experience. You go through the fit-to-standard workshops,

00:19:07 you open the screen, and you get an idea of what is intended to be

00:19:14 done with the sales order processing based on SAP best practice implementation.

00:19:19 And here is a sequence of activities, a sequence of process that you might take

00:19:26 as a communication basis and discussion basis with your customer or with the process experts

00:19:35 and the key users at the end. Good, that's all for now.

00:19:43 With this, we come to the end of this unit. And in the next unit, we will focus on

00:19:50 using best practice content from SAP Activate. So, thank you for your attention,

00:19:56 and see you in the next unit. Have a nice day.

6

Week 2 Unit 2

00:00:06 Hello and welcome to Unit 2 of this week, Week My name is Stefan Koerner,

00:00:11 I'm a Solution Manager expert consultant, and I will be the host of this session today.

00:00:18 So what I'm going to tell you is now how to use the best practices

00:00:24 that are available with SAP Activate as well as with SAP Model Company.

00:00:29 So remember you are in the role of the business process expert,

00:00:34 and as I've already introduced in Unit 1, you should now work with the Solution Documentation

00:00:41 to review the content that is delivered by SAP or partners, and you follow up with the fit-to-standard workshops

00:00:49 to collect then, based on that, the requirements. Before I jump into the details,

00:00:57 let me explain one more time in a nutshell what SAP Activate provides.

00:01:03 As you know, there are three pillars in SAP Activate. These are SAP Best Practices.

00:01:09 This is what we are going to focus on more in this course. There are tools available and methodologies.

00:01:14 So Best Practices is, for example, about process definition,

00:01:19 process documentation content, and also integration and migration content.

00:01:26 And the tools, more a look at the implementation itself.

00:01:31 So for S/4HANA cloud, for example, there are our configuration tools like

00:01:39 self-service configuration that you make use of. That doesn't play so much a role

00:01:44 in an on-premise implementation. There we normally look at a tool of Solution Manager,

00:01:50 Focused Build, helping to implement and document besides. And you know there's methodology behind SAP Activate.

00:02:00 So what we see as roadmaps and project template that we also heavily make use of in Focused Build.

00:02:09 This is content that is enriched by SAP, not only in SAP Activate,

00:02:14 but also coming from the Model Company approach. In addition to SAP Activate,

00:02:24 you might have heard already about SAP Model Company. In a nutshell, what is this all about?

00:02:30 You know the digital business framework is the framework all about,

00:02:35 so we have SAP Activate. Based on Best Practices, we come

00:02:40 with predefined reference structure and architecture for industry specifics.

00:02:47 And Solution Manager plays an important role here. With Model Companies, you are purchasing,

00:02:56 you are demanding engineered services, so follow-up packages by SAP

00:03:02 to make use of accelerators. So accelerators could be predefined systems

00:03:10 and configuration packages. So when you purchase a Model Company service, for example,

00:03:17 you can also start from a trial system to deploy a predefined,

00:03:22 pre-installed, and configured system to find out what S/4HANA Suite

00:03:28 on premise, for example, is all about. And this can also support directly

00:03:33 your early stages of the projects. And with Model Companies, in contrast to SAP Best Practices,

00:03:40 with SAP Activate you also have then more business-oriented process definitions and documentation,

00:03:50 like, for example, modular and end-to-end processes, which I will talk about later on during the next unit.

00:04:00 The most important point is that you're going to get predefined content

7

00:04:05 that can be actually a very good accelerator for your project.

00:04:10 So let me give you an example. So what you might see in SAP Activate

00:04:16 when you review the content as I introduced in Unit 1 already,

00:04:21 you come with Best Practice Processes, so structures and process models.

00:04:26 You can review configuration guides, configuration units that you need to consider

00:04:33 when activating and implementing best practice and standard processes.

00:04:38 And we also come with test cases. So predefined test cases written in Word

00:04:45 that you can easily consume from Activate and start also your journey for preparing

00:04:52 the tests later on, already based on that content. And the level that Model Company puts on top of that

00:05:00 is we are now looking at modular or end-to-end processes like you would see in the line-of-business

00:05:07 or in the end-to-end scenarios when it crosses functional borders

00:05:14 or functional organizations. And here, one more time, you will see

00:05:18 predefined package and information for configuring the solution.

00:05:24 So we would talk about building blocks that you will see there.

00:05:28 Matching also the terms in Solution Manager. You will see special configuration guides,

00:05:34 and also user and training material. And you'll see all sorts of tools

00:05:39 to combine that information, to review that from a business perspective

00:05:44 and also from IT and implementation partner perspective, is then the Solution Manager.

00:05:50 To give you an example of that, what that could look like. So if you are in the shape

00:05:57 and if you are utilizing services from Model Company, there's a piece of it, the solution documentation content.

00:06:06 Like, for example, process documentation for a Model Company that you will see,

00:06:13 as an example, in SAP Oil and Gas. So you could imagine you browse

00:06:18 through their solution documentation, as you have seen in Unit 1 already,

00:06:23 you're just reviewing the content, and you would see a process like this, for example,

00:06:29 for planning in a DPS environment. And this is a combination then of modular processes.

00:06:40 You would see there is an interface showing you the business process model.

00:06:45 You can drill down, further navigate to find out that first it starts somehow with planning.

00:06:52 If you drill down, open the underlying sub- process, you will see then the specific activities

00:07:01 and underlying business activities for that process. And when selecting, for example,

00:07:10 a process step here in this picture, the application in Solution Manager will also show you

00:07:17 and link what you have to think about when touching the system, the application.

00:07:23 So here in that case, a Fiori application that is accessible,

00:07:29 so if the Solution Manager is typically integrated with the back-end system,

00:07:34 it might be an evaluation system, a sandbox system where also

00:07:38 the predefined packages are deployed, there you can easily navigate to the Model Company system.

00:07:44 And from an end-user perspective and from your process expert perspective,

00:07:52 you can directly touch and feel that system and the application that you are going

00:07:58 to talk about with the key users from the business side. So doing that course, we are not going much more detailed

00:08:09 into the Model Company content and environment, we are more focusing on the Best Practices by SAP.

00:08:16 But it doesn't matter what content you are utilizing, it's the Best Practices, and the approach

00:08:22 of working in that content is always the same. So a typical starting point, one more time,

8

00:08:30 you will see preparing, or running actually, the fit-to-standard workshops.

00:08:37 You could imagine you have your Solution Manager open, and you browse through your solution,

00:08:43 and you navigate to the import branch. And somebody thinks let's have

00:08:47 a look at the Best Practices provided by SAP. So before, for sure, there were some activities to import

00:08:55 that bunch of information into the Solution Manager. And then you're utilizing the solution documentation UI

00:09:02 to, for example, look at the business processes and the folder containing the Best Practice import.

00:09:09 And here you would find for each version that you decide to load to your Solution Manager,

00:09:15 it might be S/4HANA Suite on premise for 1809, or later on packages.

00:09:23 And then, for each and every imported solution package and scenario,

00:09:28 you would easily find out what processes and underlying scope items are lying behind.

00:09:34 So here you would navigate to a process and then think, okay, these are the process steps,

00:09:42 I can work with that. But let me show or think about more information

00:09:49 that comes from SAP or the solution package that's predefined.

00:09:53 So on the lower sections, as you know, in the elements list, you would have access already

00:09:58 to the building blocks, for example. So the configuration packages that you would activate

00:10:05 in the system, in the back end, when configuring that process.

00:10:12 Or if you are interested in the process diagram, you actually look at the process diagram

00:10:19 embedded in the Solution Manager UI and start to think, touch, and feel

00:10:27 in the system environment and already think about and collect

00:10:32 the ideas for the requirements later on. And what is necessary before any follow-up activities

00:10:43 in maintaining the content, moving the content, so structuring this according to the business needs,

00:10:51 what needs to be prepared? Remember what I told you

00:10:54 and explained already in Unit 1 about the branch,

00:11:00 and the recommended branch set up in Solution Manager? We are now focusing on the import branch.

00:11:06 This is where the initial load of the Best Practices happened.

00:11:10 So somebody provided this already. And the easy part is here

00:11:15 to review the content and decide what should be in scope of the project.

00:11:23 So what are the scope items that will be activated primarily in the system later on,

00:11:29 and then the redesign, maybe the redefinition, the renaming start from.

00:11:36 So somebody goes to the solution documentation again, and as you see here, just in the picture,

00:11:42 you pick up, you select the scope items that you want to bring into your project.

00:11:50 And then the right mouse-click, and an activity that's called Release Changes

00:11:55 breaks it further up to the design branch. It's always push up, from the bottom to the top,

00:12:04 so the next level will be the design. And in the design branch,

00:12:07 this is, as I explained already, your playground later on

00:12:11 to define, rename, restructure your processes, and then provide that information

00:12:19 further on for the fit-to-standard workshops, to collect possible requirements

00:12:26 that we talk about later on. So having said that on the slides,

00:12:33 let me show you an example of what that looks like in Solution Manager.

00:12:42 So, one more time, your starting point is the launchpad of Solution Manager.

9

00:12:47 And, as I already told you, there's a predefined role and authorization concept

00:12:52 that might show you the tiles necessary for the business analyst or the process expert

00:12:59 you are capable of. So we start from the Solution Documentation tile.

00:13:08 You jump into your Solution Documentation, and consider you scoped your scope items already,

00:13:16 you brought it to the design branch in your solution, and you navigate first of all to the business processes.

00:13:25 And here you see already it's somehow following the Best Practice approach

00:13:31 that we typically implement in our projects. We have end-to-end processes,

00:13:35 so this is a folder, a structure that makes sure that there,

00:13:40 the top five or top 10 processes are maintained, which are really end to end

00:13:47 with crossing the boundaries of any functional domain, and we have the modular processes.

00:13:53 And here you could imagine this is a typical project activity

00:13:57 that the process experts do. They provide with modular folders

00:14:03 for the different scenario and functional domains. Like in this example, in the Sales area,

00:14:10 we will create a new structure item, and as you see here, it's giving a name,

00:14:18 and the scenario for that structure item is now more in the area of sales order processing.

00:14:24 So we take care of the scope items that have something to do with sales order processing.

00:14:32 So having done that, you navigate to the folder,

00:14:37 to the structure of the SAP Best Practices Import. And here we would see the Best Practices import

00:14:47 and the scope items delivered by SAP Activate. And it might be of interest to say

00:14:54 we are making use of this sales order processing, so scope item BDH, for example.

00:15:03 Here you would see it's selected, and let's now show you how the restructuring works.

00:15:14 Here we have a move control, so it's like cut and paste.

00:15:19 So right mouse-click on the process element, as an example here,

00:15:23 click on move that process, and you need to navigate back to your process structure

00:15:30 where you want to insert it. So here in Modular Processes,

00:15:36 one more time, back to the structure we prepared for the sales order processing.

00:15:40 And here the empty part, this is where you do the right mouse-click

00:15:45 and insert your sales order processing scope item delivered by SAP.

00:15:52 So you take it from the Best Practice and import this to your own structure.

00:15:57 And if you like, you can do then a renaming of that.

00:16:02 So, a typical project situation, I would expect that you are thinking

00:16:08 about naming conventions. So how the structure should be named later on

00:16:16 so that it's much easier to define the scope or find information later on.

00:16:22 As you see here in the attributes pane on the right-hand side,

00:16:26 you could change the name according to a naming convention, save it,

00:16:34 and by that, you see already in the column browser here, that is now successfully done.

00:16:42 So you moved one or many scope items to your new structure. You rename if you like,

00:16:48 and now that prepares for follow-up activities like redefinition of the process,

00:16:55 inventing new process steps if required from key user from business end side.

00:17:00 All the things that you are now going to perform actually in the fit-to-standard workshops

00:17:06 to find out maybe the gaps or the things that need to be configured.

00:17:12 And how that is done I will show you in the next unit. So Unit 3 is then

00:17:20 all about the business process modeling. So some information about structuring,

10

00:17:25 and maintaining the solution documentation. Down to actually modeling also

00:17:30 the business process diagrams inside your Solution Manager. So that's all for now.

00:17:38 Thank you for watching and listening. I hope you enjoyed it, and have a good day.

00:17:43 Cheers and bye-bye.

11

Week 2 Unit 3

00:00:06 Hello and welcome back to Week 2 and Unit 3 of this course.

00:00:11 This unit is all about business process modeling, and I will explain and show you in detail

00:00:17 what that looks like with SAP Solution Manager. Before we talk about the modeling itself,

00:00:24 let me explain the key principle of dealing with process hierarchy and process diagrams

00:00:31 in SAP Solution Manager. You see in the Solution Documentation,

00:00:37 we typically touch and navigate through the Solution Documentation structure, first of all.

00:00:45 Either through the libraries of process steps or executables, or you are navigating

00:00:50 through the business process and your end-to-end or modular-based structures.

00:00:58 And normally, you are telling the end users this is what the process looks like,

00:01:08 based on the process diagrams. So it's a good medium to manage then

00:01:17 the expectations of what a solution is going to look like. And first of all, you look at the SAP Best Practices

00:01:26 that you might consume from SAP Activate or from the Model Company.

00:01:33 And utilizing then the interface for the process diagram, you will start discussing, is that how it can be applied

00:01:42 to the customer solution? Is that what the end users can work with?

00:01:49 So, in a nutshell, both need to be considered as two sides of the same coin.

00:01:55 So they are managed as a whole, in a process hierarchy as well as process diagrams.

00:02:07 You have seen already I've been talking about modular processes and end-to-end processes.

00:02:16 Let me summarize one more time what this idea and these recommendations around

00:02:23 are all about. Typically, a modular process on the one hand,

00:02:30 it's a flow of activities that is restricted to one functional domain.

00:02:37 It's not like this is exceeding the functional domain of one organization.

00:02:44 Typically, we would see one process owner. So, you will have, for example,

00:02:52 a key user named as a process owner for any financial processes or sales processes,

00:02:59 purchasing processes. This is then a guy or a lady being responsible

00:03:08 for knowing from what business perspective and the underlying applications this is all about.

00:03:16 On the other side, you have the end-to-end processes.

00:03:20 This typically might be the five or ten most important processes that run in the company.

00:03:29 And it's typically a comprehensive flow of activities needed to solve large business matters

00:03:35 across the organization. In contrast to the modular processes,

00:03:41 that does not stop at the boundaries of the organization, and typically, it would involve then

00:03:49 multiple functional domains and underlying systems. And as you would expect maybe,

00:03:56 there is a shared process responsibility. So there are more than one process-responsible people

00:04:04 that talk to each other when defining the end-to-end processes and knowing about the interfaces

00:04:10 and the boundaries that are crossed. And since we are one more time making use of the libraries,

00:04:19 it's very important to ask yourself if you have reusable artifacts like process steps or interfaces

00:04:32 that are already existing in your interface library or process step library that you are going to reuse

00:04:40 whenever possible. And this is actually what also happens

12

00:04:45 when you look at the Model Company content. Here's an example of what that could look like.

00:04:51 We can compare this easily with the best practice content delivered with SAP Activate.

00:04:58 If you are in the situation to utilize services and content from Model Company, this is what it looks like

00:05:05 later on in the Solution Manager. So the procedure is more or less the same.

00:05:10 Content will be delivered to your Solution Manager. It's like a Model Company content import into your solution

00:05:17 that you prepared already. And when navigating through the Solution Documentation,

00:05:22 you can find something like this: a process area. It would be represented by a folder in Solution Manager.

00:05:30 It could be something about procurement of materials and services.

00:05:35 So this is a typical process area, and following, some naming convention,

00:05:43 as you see on the right-hand side here. There could be an example PMS,

00:05:48 standing for procure materials and services. And underlying this, you have then

00:05:56 functional groups of supplier management and direct procurement. Since that is not restricted in Solution Manager,

00:06:05 one more folder underneath to say we have PMS-10 and PMS-20 for the different process groups.

00:06:15 And now, that's going to be interesting how to maintain the structure for the processes at the end.

00:06:26 As you know, in Solution Documentation, we will have then a collection of processes

00:06:32 and underlying process steps at the end. And they are controlled and structured

00:06:38 underneath what are known as scenarios. A typical scenario name for processes in this area

00:06:47 could be, for example, here Request and Buy. And then you see that also on the icons

00:06:58 in your Solution Documentation, the process at the end, that might be based on the scope item, a classic J45,

00:07:07 Procurement of Direct Materials is structured accordingly in process steps,

00:07:14 and a process step could be an activity like analyzing material document.

00:07:20 And making use of the interconnection in the libraries and the elements information, as you see here,

00:07:28 also a transaction could be directly linked. For example, a Fiori application that is now

00:07:35 a simplified Materials Document Overview. So this happens in one functional domain,

00:07:44 in one functional organization. And it might be in total that one process owner

00:07:50 is now responsible for direct procurement. Another example when we talk about end-to-end processes...

00:07:58 so it might be that sales, sales of refined products,

00:08:04 that is a good example of an end-to-end process coming from a Model Company predefined solution

00:08:10 for one line of business. And here we see, actually, a grouping

00:08:17 and a scenario group, and underneath, an example of sales of refined products by pipeline.

00:08:25 So that is an element of a process that is then making use of the libraries of

00:08:35 the Solution Manager documentation. So it might be that here you're making use

00:08:42 of the process for planning, then a process of schedule pipeline transportation

00:08:47 and last but not least, then the process of performed billing.

00:08:50 And those processes are then already controlled and connected via the structure view itself.

00:08:58 But also via the business process model that is also attached to this end-to-end process

00:09:05 called the Sales of refined products by Pipeline. You would see in the process model later on

00:09:11 this is then a calculation, an interconnection of several sub-processes.

13

00:09:19 So just to show you some examples of customers and customer projects that are

00:09:27 following that naming convention actually, especially when receiving and using Model Company content.

00:09:36 That's already a big advantage to start with here. And when we look at the Solution Documentation again

00:09:48 in Solution Manager, now where do we find a process definition and diagrams?

00:09:56 Let me show you and explain it one more time. In your column browser,

00:10:02 this is your structure of your end-to-end and modular processes that is basically showing

00:10:10 what processes are in implementation or what processes are scoped so far.

00:10:18 And then you might have one or more diagrams for each process.

00:10:25 So following different purposes at the end, you want to utilize this information, maybe,

00:10:33 for end user training or new business users that will receive that information

00:10:40 and will use it for onboarding. Then you have a streamlined or easy-to-read process diagram

00:10:48 showing just the details of what a business end user needs to know about the process overall.

00:10:54 In contrast to that, you could have a more IT- related or implementation-related perspective,

00:11:02 meaning you combine then much more information like, for example, data objects or transaction information,

00:11:10 application information that is linked to processes and underlying activities, and an activity

00:11:16 could be starting your Fiori application and underlying system.

00:11:23 And last but not least, a future vision, a future goal also could be to support the productive

00:11:34 and the operation mode of your solution. Then a diagram for the business process modeling

00:11:41 could be used for the monitoring, meaning you can look at the process end to end,

00:11:49 you are linked with your monitoring items, and in the corresponding interfaces

00:11:55 for business process monitoring, you will see IT-related information

00:12:00 combined with business and user-related information. Last but not least, let me show you just some guidelines on

00:12:15 what we think is important to know about the modeling in Solution Manager.

00:12:22 I don't think that this should be the approach, to be a master in business process modeling

00:12:29 and creating fancy and very intensive and detailed process models.

00:12:38 Based on my experience from customer projects, it's more like

00:12:43 knowing what is really necessary to visualize and document a process that is not too complicated

00:12:51 and everyone should be able to read. So within some seconds, you should be able to understand

00:12:59 what's being told by the diagram. So let me give you some guidelines accordingly.

00:13:07 On that picture on the right-hand side, you see the typical artifacts and objects

00:13:15 that I would see in usage when modeling processes. For example, activities.

00:13:22 Activities represent our process steps. We have events, gateways, sequence flows, message flows

00:13:30 and so on and so forth. And the process model that you are creating

00:13:38 should be concentrating on the process logic itself. It should only show the order of activities

00:13:50 which are executed. So whenever an activity happens, it should show us.

00:14:00 And with the gateways, for example, or events at the end, you will also depict

00:14:08 under what conditions the activities will happen. For example, when showing then the participants.

00:14:15 So the roles involved in a process. The pool is showing the process, and the lanes

00:14:21 are showing the roles and responsibilities in the process. You are not telling in detail what the function

14

00:14:35 of the role itself is. It's always expressing what flow of activities the process

00:14:44 will execute instead of really showing what happens inside. So what am I really doing specifically in this activity?

00:14:57 That's very important. It's not necessarily to integrate annotations

00:15:05 and texts to explain why and when a specific activity is performed.

00:15:14 This is something that you can take for other end user documentation, not in the process itself.

00:15:21 And last but not least, for the end user, it's not interesting what data objects will be maintained.

00:15:31 So you have a variant for the more end-user-related information.

00:15:34 But on the other hand, you have a variant of your process, as I told, for the IT people,

00:15:40 the implementation team. And that might be interesting to assign more information,

00:15:46 like what data inputs for the process or the data outputs of the process.

00:15:52 And maybe what data stores and what applications or data objects are touched by the process.

00:16:05 Having said that, I think it's a good idea to see what that looks like in Solution Manager.

00:16:12 So let me show you a quick demo about that in SAP Solution Manager.

00:16:21 One more time, your starting point would be the launchpad of SAP Solution Manager.

00:16:29 One more time, you are navigating down to the Solution Documentation.

00:16:34 You should find that tile somewhere on your launchpad screen.

00:16:39 In this example, we are still in the design branch of this documentation area, and here we are

00:16:47 interested in the Sales Order Processing for Prospect. So you might wonder how can I enrich that screen here?

00:16:57 Just click on the little icon here on the top to bring that to the larger screen,

00:17:04 so you can drill down and drill up using plus and minus in the screen.

00:17:11 And the use case could be directly within or after the fit-to-standard workshops.

00:17:19 You are thinking about the process, you are discussing the necessary changes,

00:17:25 and someone says, I need a process step here. So there's something happening

00:17:31 on the Post Goods Issue. That's not available so far in the best practice.

00:17:37 So when you click on that activity, you would see, as you see here,

00:17:45 the basic process steps that are existing and registered in Solution Manager already.

00:17:53 But we want to create a new step. So, here, a kind of good practice

00:17:59 I recommend to do is searching in the library first of all. So we go to the Advanced link here

00:18:08 in the new Process Step application, and first of all you should search for

00:18:16 a search item that you are interested in. Here, it's about recording of QM examples.

00:18:26 But it's not shown in the list, so it might not exist already in the process step library.

00:18:33 So that's a valid use case to create it from scratch. So create a New Process Step Original.

00:18:42 And let's say it's structured in a good way. So the library of originals also consists of folders,

00:18:50 as you see here, an example. It's also a kind of good or best practice

00:18:56 to say we have also modular information here, Sales or Service.

00:19:03 And here we are talking about quality management function that should be executed.

00:19:11 Let's say we focus on that folder. So any new item, new process step,

00:19:16 we are going to create now is located in Quality Management.

00:19:21 You should know already what basic system environments or application

00:19:28 is lying behind that. That is represented by the Logical Component Group.

00:19:34 So in that case, it was configured as S4HANA to represent the application for the S/4HANA Suite.

15

00:19:43 And the new step here is Record results from inspection. So you enter the name,

00:19:49 then click on OK, and you have it.

00:19:53 So in the library, in the background, this new process step was created.

00:19:58 All you have to do now is click on the activity, so the process step you want to enrich.

00:20:06 Then this context icons and menu bar opens. Then you should find, or you will find now,

00:20:14 the process step that you created before. So this is Record results from inspection.

00:20:22 And the easy part of the modeling is now, after posting the goods issue,

00:20:30 somebody responsible here would record results from inspection.

00:20:34 This is, according to the sequence flow, the next activity.

00:20:39 That means now we are changing the sequence here. So drag and drop the arrow to the Record results from inspection.

00:20:49 And then afterwards, once that was done, once this activity is complete, the billing is performed.

00:20:58 And here's a cool feature, obviously, of Solution Documentation. Let me show you that.

00:21:06 You could imagine that there's a specific application, so a transaction or Fiori application, existing

00:21:16 for recording results for inspection. In this example, we have now the possibility

00:21:23 to right-click on the elements list. And this opens a context menu.

00:21:29 You would say, my target is to specify what executable, so what transaction is being executed

00:21:35 in this particular step and activity? So let's select New and then click on Executable.

00:21:44 This will open this small dialogue window, and by navigating to Specify Executable,

00:21:51 you will be able to say, okay, this is a new library element.

00:21:56 So, in the executable library, we have different element types,

00:22:00 like programs and transactions and Fiori applications. Here is a classic SAP transaction,

00:22:09 obviously happening in the S/4HANA environment later on. And the object itself that must be known

00:22:16 should be QE51N. So you are entering this information

00:22:24 in the background of the check against the system, which might be connected to the Solution Manager already,

00:22:30 that checks the explanation of the transaction from a business end user perspective.

00:22:36 So this is Results Recording Worklist. And finally, you move this to the original.

00:22:47 I always recommend that if you create these process steps and you know that typically

00:22:54 these executables are executed, then you link it also to the library.

00:23:01 That makes sure that, whenever you are reusing that transaction and the corresponding

00:23:07 process step from the library, this information will always be linked and

00:23:10 interchanged to all the processes where this appears. So, easy step.

00:23:20 You go back, finally, to your process model to complete your maintenance of your process model

00:23:28 that is based on that scope item BDH. Don't forget to save here before closing the diagram view.

00:23:38 And if you're willing, or that's, I think, the typical use case,

00:23:43 to say based on the naming convention that you have decided and defined for the project,

00:23:50 you're also changing now the name of the diagram here. To speak in business end user words,

00:24:00 say it's SA01, for sales order processing. Save that in the attributes pane one more time.

00:24:10 And that's all. So that's an easy example, a day-to-day project example

16

00:24:17 directly maintaining the process structure in Solution Manager, maintaining the process diagrams,

00:24:25 and by that, calculating and capturing all the business needs for what that looks like

00:24:35 in the business environment. That's actually the end of today's session.

00:24:43 So that completes Unit 3 of this course. Thank you very much for listening one more time.

00:24:50 I hope you enjoyed and take your time and have a good day.

00:24:56 See you in the next unit.

17

Week 2 Unit 4

00:00:05 Hello and welcome back to this unit, Unit 4 of Week 2.

00:00:10 This unit is all about recording the requirements using the Solution Manager

00:00:16 embedded features of Focused Build. Typically, you are going to run fit-to-standard workshops,

00:00:27 and we are discussing processes and applications that are implemented

00:00:35 based on SAP Best Practices. You're reviewing the process models,

00:00:41 you're looking into the process diagrams, and this relates to the creation of,

00:00:48 actually, requirements with information about what fits, what needs to be configured accordingly,

00:00:56 what customizing can be applied to, change a little behavior of one or the other settings,

00:01:04 or it leads to documentation of gaps. So whatever it is,

00:01:09 we start from the requirements gathering to fill at the end, as you see here,

00:01:16 our product backlog. And it's a good opportunity

00:01:21 and the target to match the business requirements. I would say, typically, if you are in the role of

00:01:31 the process expert or the business analyst, you should already have good knowledge

00:01:37 about the application or the specific function that is lying behind the business process activity.

00:01:44 And therefore you will build up your understanding of the business needs

00:01:52 and combine it with the application itself

00:01:56 to define good requirements at the end. They will be analyzed, categorized,

00:02:04 prioritized later on, and once approved and staged to work packages and work items,

00:02:15 sooner or later, architects and developers and the implementation by SAP or partners will be ongoing.

00:02:24 So in classic terms, we say that there are some principals. I will come back to those later.

00:02:33 It is interesting to efficiently document the requirements in one place.

00:02:39 And this is obviously sometimes the question: where to add requirements.

00:02:47 So do I do it somewhere in an Excel sheet? No, obviously not a good idea.

00:02:54 Here, the idea is to go down to the Solution Manager one more time, look at the process documentation,

00:03:01 go to the level of process or process steps, and the underlying process diagrams

00:03:08 will help in the discussion to identify requirements.

00:03:14 And the most relevant elements to assign requirements to

00:03:22 are normally process steps in the library as I said. You are free to assign requirements

00:03:29 also to other items like, maybe, configuration elements in your configuration library,

00:03:39 or you might assign them to the process variants themselves in your process world.

00:03:50 So once you create requirements throughout Solution Documentation,

00:03:56 normally it's a question of is there something existing already?

00:04:01 Or where do I start from creating the requirements? First of all, you navigate, for example,

00:04:09 to your business process. So you open the process diagram directly.

00:04:14 Maybe you have invented some changes to the process flow itself,

00:04:19 or you redefine the process step, you invented new activities.

00:04:24 And now you need to capture also the documentation on what specific

00:04:32 function is desired by the key user, by the end user. Based on the user story or use case description,

18

00:04:38 however this is defined and available. And if you look at the interface in Solution Documentation

00:04:47 on the right-hand side, there is this attributes pane. And a nice section, the Related Documents section,

00:04:54 shows you a link to the requirements. And if you click on that link,

00:05:01 that opens the requirements app. And sooner or later, if you work with the interface,

00:05:08 maybe you navigate to another process, you will recognize there's a counter maybe.

00:05:15 So it's not counting 0, it's counting 1, 2, 3, 5, or whatever. And this directly indicates there is existing requirement.

00:05:23 And for you as the user utilizing the tool, it's easy to find out if there's maybe

00:05:30 already an existing requirement for the same purpose, or if it is maybe

00:05:38 an additional requirement that comes from another key user in the same area of process.

00:05:45 So as you see here, from throughout the Solution Documentation,

00:05:50 this is your single source of truth, this is your single access point.

00:05:55 In your design branch, you have access to the related documents.

00:05:59 It will always show you the requirements that exist. So you can do that for one

00:06:05 object type or for one object in a minute, or if you are utilizing the reporting capabilities,

00:06:14 the Solution Documentation UI offers you a reporting functionality.

00:06:19 That means you are running a specific report, a standard report that is delivered by default

00:06:26 in the Focused Build context, and this shows you a list. The report is called Related Documents.

00:06:33 And this list shows you for a specific folder in your structure, or a process, a process step,

00:06:41 all existing related documents, basically, based on the type.

00:06:48 You see that here on the screen, based on the type: Requirements, for example, in that use case.

00:06:55 You see all that is existing at a specific process. That can be one to many.

00:07:03 And this gives you an indicator, or an opportunity later on, to work with, at least for further discussion

00:07:11 and approval procedures. For you, yourself, if you want to see what

00:07:22 requirements were created by you in Solution Manager, there's also a possibility to navigate through the

00:07:30 launchpad again to the My Requirements app. The My Requirements app will always indicate

00:07:37 with a number how many requirements you already have created.

00:07:42 And when launching that little application, it's showing you a screen comparable to this

00:07:49 on the right-hand side here. You can browse and search and navigate,

00:07:54 filter through your requirements. And you could imagine that, during the project phase,

00:08:01 maybe the end user or yourself, you're asking what happens with the requirement.

00:08:07 So remember, if you are interested in what the current development stage or approval stage is

00:08:15 of my personal requirement or the requirement of the end user, you can utilize that app,

00:08:23 search and filter for maybe the naming convention and the process area you are interested in.

00:08:31 And from that, you can start reviewing the details, textual information,

00:08:36 or maybe just the status of the requirement, if it's still to be approved

00:08:42 or if it is later on in development. So, last but not least, let me summarize

00:08:53 some best practices, some recommendations we outline during the projects,

00:08:59 how we see the dos and don'ts for requirements recording. The first one is that you the project,

19

00:09:11 so together with the project team, you establish and define clear naming conventions for requirements.

00:09:19 So later on, for example, it is easier to calculate and find out

00:09:25 for a specific process or functional area what requirements exist, and everyone knows already,

00:09:34 based on the requirements description, what the content might look like.

00:09:40 The second is also to discuss upfront with the project team, with the key users,

00:09:48 so that is individual from project to project, discuss how you will utilize

00:09:58 key information like priorities. I will show you that in a second in a demo, what that looks like.

00:10:04 The priority obviously is a key indicator to later on also sort for requirements.

00:10:12 And there will be a field for categories and some other attributes that are not mandatory to maintain,

00:10:19 but it's necessary from project to project. So if you have a clear definition of that, everyone knows

00:10:27 throughout the project teams how that will be maintained, and then there's no misunderstanding or rethinking

00:10:34 about how to manage the full bunch of requirements later on. The third of our dos and don'ts

00:10:44 refers to the categories of requirements themselves. So when starting the requirement gathering,

00:10:54 at first glance, it might not really make necessary an entry

00:11:02 from an end user perspective. But later on, you will find out that this

00:11:07 is simpler to use for searching and filtering if you have clearly defined categories that everyone follows

00:11:14 and maintains, if necessary, in the requirement. And if you're filling out the description of requirements,

00:11:26 especially when working in bigger teams, there are some good definitions

00:11:35 that you should follow when adding meaningful

00:11:40 descriptions to the name of the requirements. So this should be as precise as necessary so that

00:11:48 the next participant in the project or the teams approving the requirements

00:11:55 can work with the information without playing ping pong to understand what the requirement is.

00:12:05 Information like use case descriptions, mockups, maybe drawings

00:12:12 to explain in some more detail what the requirement is all about might help in that.

00:12:18 You will see that also in the demo. There's a section directly in the app

00:12:23 that gives you the opportunity to assign and upload additional documentation to the requirement.

00:12:32 And last but not least, this is also somewhat predefined,

00:12:38 as you would expect by the tool itself, but also from the organizational point of view,

00:12:44 you should make sure that the sign-off procedure by a key user or the customer

00:12:53 who is ultimately paying for that implementation is clearly defined.

00:12:59 So, for example, you are capturing all the requirements

00:13:04 and you have already made sure that there is a round of people that

00:13:10 are looking at the requirements and taking the categories

00:13:16 and the priorities into consideration will actually approve on that.

00:13:27 To cut a long story short, now I want to show you and demonstrate

00:13:32 how to create a requirement in SAP Solution Manager using the Focused Build extension.

00:13:39 Therefore, let me switch... to our demonstration system one more time.

20

00:13:47 We start from the launchpad of SAP Solution Manager. And regarding your role,

00:13:54 you will find predefined tiles and application links again. As you might expect already,

00:14:04 you will jump into the Solution Documentation first of all, because we recommend to always

00:14:13 link the requirements from the beginning to your library elements.

00:14:18 That might be processes or process steps or other configuration or development items.

00:14:26 In that example, we link a typical requirement to a process.

00:14:34 You see here, the process that you modeled already in Solution Manager is selected.

00:14:42 It's a Sales Order Processing for Prospect. And we already see, on the right-hand side,

00:14:48 the related documents. It indicates three requirements are assigned already.

00:14:56 So what you can do is you can click on that, you will jump directly into the Requirements Management app,

00:15:03 and you will see the solution, the branch is still Design. And a filter is on the element of the process itself.

00:15:11 So the list now shows those requirements that are registered by different people or you.

00:15:22 They are still in Draft status in that case. So if you like, you can directly click on that

00:15:29 and review the content. But now let's see how to create a new requirement.

00:15:35 That's the main target. So let's think about... there's really a new requirement.

00:15:40 So from the bottom right, you click on Requirement and then Create New Requirement.

00:15:49 This changes the screen a little bit. And let me explain what you see here.

00:15:55 The most important point, obviously, is a title. Remember what I said about

00:16:02 naming conventions, so you might already follow here a certain naming convention for the title.

00:16:08 It makes it easier to scroll over the requirements later on in the list.

00:16:14 Next thing would be priorities, to say we have the well-known priorities from 1 to 4.

00:16:22 And in your mind, you can control this, or understand this with

00:16:32 must-have, should-have, and could-have requirements. In that case, it's a should-have.

00:16:41 And the owner is initially the one who's creating the requirement.

00:16:44 So if necessary, you can still change it. But the owner, I would say, is then the process expert

00:16:52 or the process owner itself. And you see on the right-hand side,

00:16:58 the possibility is given to give it a description.

00:17:04 In this example, we talk about initial requirement to set up the standard functionality

00:17:11 in the development system that exists so far. If you have ideas about

00:17:20 assumptions or solutions already, you can also maintain them here.

00:17:24 What I see in projects normally is that you take care of a good description of the requirement

00:17:29 so that someone else is really understanding what the requirement is all about.

00:17:35 And you leave other fields a little bit behind. And if you scroll down a little bit,

00:17:45 you will see the Attachment Panel. This is what gives you the opportunity to

00:17:52 browse through additional documentation, maybe, use case descriptions, or user stories.

00:18:01 Like in this example, there's some kind of Word document

00:18:06 that is showing some more details about the business view on that requirement.

00:18:14 So let's say that is now necessary for upload. You see the dialogue then

00:18:23 picks up the document types. So different document types exist in Solution Manager

00:18:29 for the purpose of maintaining the information and later on being able to filter for that.

00:18:35 So if you're interested in seeing all the use cases, for example,

00:18:39 this is what it will at least show you, your user story for sales order processing.

00:18:46 So finally, you choose the Document Type, and then you click on Create.

21

00:18:52 And last but at least, once you save your requirement, as you here, it will appear

00:19:02 in the list of requirements as you would have expected it.

00:19:06 The initial status is now Draft. And last but not least, you can

00:19:13 leave that screen, maybe reload the application for the Solution Documentation,

00:19:20 and you would recognize that now it's also properly shown up in the Related Documents section.

00:19:27 So every other process expert or people interested from the business side will recognize

00:19:33 that there are requirements, one to many, assigned for the process.

00:19:41 So that completes the demo for now. It also completes the unit,

00:19:47 Unit 4, for this week. The next unit will be about managing those requirements

00:19:52 that you create in Solution Manager. So thank you for listening and watching.

00:19:58 I hope you have a good day left and see you in the next unit.

22

Week 2 Unit 5

00:00:05 Hello and welcome back to Unit 5 of this week, Week 2, of the openSAP course.

00:00:11 It's actually the last unit of this week, and it's all about managing the requirements backlog.

00:00:17 So I want to show you and explain how you review the content of requirements,

00:00:23 and how to push it further forward to the approval. So first of all, let me show you

00:00:32 what the roles and responsibilities are expected to look like.

00:00:38 Typically, you have a joint venture between the business analyst and the architect,

00:00:44 so they're talking to each other from time to time. First of all, you have seen already in the last unit

00:00:52 how you create the requirements. So, typically, we expect that those requirements are created

00:00:59 based on the processes or the process steps directly inside Solution Manager.

00:01:05 And it could be the responsibility of the business analyst and the process expert to directly prioritize

00:01:16 those requirements or even maintain information like value points

00:01:22 to rank the priority and the value points for the requirement already.

00:01:30 And then there's a deeper analysis by the architects or the architect defined

00:01:38 to analyze, maybe, dependencies of the requirements. And sooner or later, you are going to estimate

00:01:46 the product backlog. And therefore, you see there will be another field

00:01:52 and information that you can fill out. So on top of the value points,

00:01:58 you can also maintain the effort points. And this is then a good discussion

00:02:05 and a good estimation point to think about what should be part of the next build phase.

00:02:12 So maybe the next release, what should be delivered and implemented

00:02:18 based on the full list of requirements. So there might be a long list of requirements.

00:02:25 Some of those have dependencies, and you will decide on what should be first

00:02:30 and what is maybe postponed. And that information will be maintained directly

00:02:35 in Solution Manager and will be reused later on to scope the release, create the work packages,

00:02:45 so filling out the detailed release plan for the wave that you are going to run.

00:02:58 And for you, it's interesting to understand how the process flow of the requirement

00:03:04 works in the background. So all you see on the front end is

00:03:11 information that you maintain in the requirement, and the process flow and the status

00:03:18 in the background make sure that sooner or later you want to find out

00:03:23 what is necessarily to be done on the requirements. When you create a requirement,

00:03:31 first of all, and update your information, then it's just in draft status,

00:03:37 and for definition of the product backlog, for the definition of the next content

00:03:47 of the wave, for example, it's then to be prepared.

00:03:51 So once you've approved it at the end, you will see that something happens in the background

00:03:58 then later on automatically. And this gives you the opportunity to look at

00:04:05 Solution Manager from time to time, to ask yourself or get a question from the end user,

00:04:12 from the business paying for that implementation. So, where's my requirement?

00:04:18 For example, a question like: Is it already approved? Or is the realization started?

00:04:25 So with this sequence of status and process flow, you will always see in the reporting later on

00:04:32 what your requirements are all about. For sure, you have opportunities to also postpone

23

00:04:39 or reject requirements and take them on for any other phase and rework on that.

00:04:45 And this is very important for all the reporting functions. Obviously, directly taken from Solution Manager,

00:04:54 a different dashboard's available. In order to find your requirements,

00:05:05 furthermore, you look into Solution Manager, you go through the launchpad

00:05:11 to your Requirements Management app. We're starting that app, from your launchpad.

00:05:17 You have plenty of filter options to filter on specific requirements, so maybe a status

00:05:28 or the requirement itself. And then you have the opportunity to

00:05:34 maintain further attributes. like I said. Maybe you start with maintaining the value points,

00:05:41 or you directly end up in a discussion in a larger round, and you need to decide on the implementation contents.

00:05:50 So you are thinking about your effort points that you build up based on your methodology

00:05:57 you defined for the project in order to prioritize your backlog.

00:06:02 And then you can rework each and every requirement one by one.

00:06:08 Maybe downloading this first of all in Excel and then rework on that, or later on

00:06:14 utilizing the Solution Manager tool and here the interface to maintaining

00:06:19 that step by step on a requirement. In contrast to that, or as an alternative,

00:06:26 you can also utilize a mass change app to rework on that list of requirements in a row.

00:06:34 That's something I will show you then later on in the application itself.

00:06:42 Let me come back one more time to this information about prioritizing the backlog.

00:06:49 You could imagine that in larger projects you will have a really large list of requirements

00:06:56 to maintain and manage. Especially, for example, in agile projects, the

00:07:04 process owners are responsible for processes in a functional area.

00:07:10 They, so she or he, must prioritize the list of all requirements that are in the backlog,

00:07:18 that are existing in a specific status. And it could be that there are some items

00:07:27 that might be equal on the list. For example, they have the same priority and ranking.

00:07:35 And you want to prevent at the end to have all requirement-related information and priorities

00:07:45 specified as very high. That makes it rather difficult to define what's in the

00:07:54 next release planning. Therefore, you should, one more time,

00:08:00 look at the combination of priority, the value, and the effort points.

00:08:05 So as I said, you can combine or match and map the priorities

00:08:11 in our app with Must-Have, Should-Have, Could-Have, and Would-Have prioritization.

00:08:19 So if that is in everyone's mind, it's understood by their project team

00:08:26 how to utilize that. You will then specify in the application itself

00:08:32 what is now very high in the example or is there even a very low,

00:08:37 so low priority overall. Because it was found out that this is just a Would-Have

00:08:46 requirement from the business side. And then the other steps are

00:08:52 ranking items which have the same priority. So it will be that there are a lot of

00:08:58 very high and high requirements still in the list. And then that's customer-specific, or project- specific,

00:09:09 it's always your definition of value points and effort points.

00:09:15 So with that, you should then make up your definition of

00:09:22 how to group requirements with the same priority with the help of value points.

00:09:31 Say something creates a high effort and a low value. It's likely to be at the end of the list.

00:09:42 And at the top of the list are requirements with higher priority but also significant effort

00:09:52 but high value for the business. So this is something you need to define.

24

00:09:58 That is something you need to make up with your definition of the project standards beforehand.

00:10:06 As I said before, working on the requirements everyone should know what the procedure looks like

00:10:14 to evaluate the numbers and figures for value and effort points

00:10:18 and how to utilize the priorities. The tool itself will manage and help you

00:10:30 a little bit with that. When you look at the Mass Change Operations app

00:10:35 in Solution Manager, which is available from the launchpad, you see that here, on the left-hand side,

00:10:42 so you are starting that from an end user perspective in the launchpad, and you are going to

00:10:51 review the requirements specifically, utilizing a filter for example.

00:10:58 If you are interested in all the requirements that need to be approved,

00:11:03 you are selecting that status and you will be able to change your approval, so to speak.

00:11:12 We have, for example, reviewed the list of requirements, now we picked up these 10 or 20 or couple of requirements

00:11:22 that we are willing to approve. We have maintained all the necessary information.

00:11:27 So you are going in, setting the status, and this is then switching forward

00:11:34 to the process with approving plenty or a couple of requirements.

00:11:44 And last but not least, one more time back to the Solution Readiness Dashboard,

00:11:51 we will see that from time to time this is a very powerful and very important

00:11:58 interface and dashboard, where, for example,

00:12:02 one tile of it is showing the requirements. So this is always a good indicator or starting point for you

00:12:11 to review the overall list, the requirements assigned to your project

00:12:18 that you are currently running. And basically, each bar of this tile is then clickable,

00:12:26 and it then offers you a more filtered list of the requirements on the bottom.

00:12:33 An interesting point, for example, could be reviewing the list of unassigned requirements.

00:12:42 This will then show you later on all the requirements, for example,

00:12:48 that are still not captured with work packages. But that's another story, another topic

00:12:57 that my colleague will be telling you about next week. So let me, from my point of view, show you

00:13:06 how to manage a requirements backlog in the system itself.

00:13:15 As I said, you start from your launchpad. So you go to a section we call here

00:13:23 Requirements Management, and once you click on the tile, you end up

00:13:30 in the Requirements Management app. And something you would do is, for example,

00:13:37 selecting the solution. Typically, we would expect only one solution

00:13:41 to be selectable here. And then the branch design is still the playground for

00:13:48 the requirements process. And obviously, we want to start with further working on

00:13:58 the requirements that were currently created in the project.

00:14:01 So you filter for the Draft status here, and if you apply the filter,

00:14:09 you click on the Go button, you will see then the list of all the

00:14:14 related requirements in the Draft status underneath. And let's assume that you are interested

00:14:22 in the first requirement here. This is what you created already.

00:14:28 And based on the discussion for this specific requirement, further information will be maintained.

00:14:35 So, for example, the value points. After discussion with the key user,

00:14:39 the end user responsible, this gets now a calculation of 30 value points.

25

00:14:48 And speaking back to the architects, we would say this is an overall effort point

00:14:56 that was decided here in the number range of 5. So this is how you easily can maintain the information

00:15:04 backwards to the requirement. And on the right lower side here,

00:15:09 you have the Action button, and by that you now complete your activities of maintaining the requirements

00:15:17 one by one, and sending this forward for the approval process.

00:15:24 So that's what it looks like at the end. So if you're switching back,

00:15:32 you see it disappears then from your Requirements Management app because that's now in another status.

00:15:42 And if you go back to your launchpad, now let me show you another section here

00:15:47 for the Mass Change Operations. Here, in the mass change app,

00:15:55 you filter for requirements. And one more time, it's important to select

00:16:03 the corresponding Corporate Solution. This is a solution that is existing here,

00:16:09 and it's obviously still in the Design branch. And now let's take an example of

00:16:22 approving our requirements. We have one or more requirements

00:16:29 existing in the system. They are categorized maybe, you will set the priorities

00:16:37 and information like effort points and value points. So based on that filtering, you'll see one more time

00:16:44 further down, a list of all the requirements. And now, before we are going to approve one or more,

00:16:54 let's see in that app for that requirement, because in the list here, as an example,

00:17:02 you can update or maintain missing information if not available so far.

00:17:09 So it might be that during the last discussions, you need to update or even maintain here

00:17:14 the effort and the value points to be able to utilize this as a ranking

00:17:21 and decision item for what should be in the next release.

00:17:29 So you see that in the column Save Status, those little icons always indicate

00:17:36 what is updated currently, and then you select all of the requirements

00:17:41 that you want to mass change, or some of those.

00:17:49 As you see here, we will just leave out the second one, and click on Mass Change in that app.

00:17:57 One more time, you see that it's possible now to specify what should be changed.

00:18:07 So instead of going through all those requirements step by step, we are now doing something

00:18:14 like from the selected requirements, result of the discussions is those four of the five

00:18:21 will be approved, to be handed over for the follow-up processes.

00:18:30 So you confirm that with saving the changes finally, and if you get the success message here,

00:18:42 you should see that finally there is a green mark, a green light

00:18:49 on the requirements. Now the status, as you see in the column for Status,

00:18:54 changed to Approved. And that completes your activity in the Mass Change app.

00:19:06 With that, the demonstration and also the unit are at an end.

00:19:13 Thank you very much for listening and good luck with the self-test.

26

Week 2 Unit 6

00:00:05 Welcome to unit number six of our second week, explore phase.

00:00:11 My name is Michael Skiba. I am a member of original implementation group

00:00:15 responsible there for process management. In the previous unit,

00:00:21 Stefan was explaining to us how to create and how to handle requirements in requirement to deploy process.

00:00:30 Well, but what if I would like to group requirements according to their responsibility

00:00:36 and according to their functional area. If I am a functional consultant, I would like to see

00:00:45 requirements that are connected to my processes. This is possible in Solution Manager by use of so-called

00:00:55 solution documentation scope. And this is the title of our unit number six.

00:01:02 Let me first explain what solution documentation scope is. As the name says, it's something that is happening

00:01:13 in solution documentation itself. So you can select a subset of documented processes

00:01:20 and group them in solution documentation scope. So you can group them according to the functional area

00:01:28 or to other criteria. Well, we will focus here on functional criteria.

00:01:35 If I am a consultant from logistics, I could highlight all processes belonging to this area.

00:01:44 And through that, I just see those processes and I do not care that much about processes

00:01:51 from finance or from HR. But this solution documentation scope can be also used

00:02:00 for reporting capabilities. So if I select my scope to see just my processes,

00:02:08 I can easily ask the system some questions in regard to show me all functional specifications from this area.

00:02:16 Are all test cases from my functional area ready to go? If you go one step further,

00:02:25 you can also assign the solution documentation scope to a project to highlight that this project

00:02:32 will focus on this documentation area. And then finally, in the test phase,

00:02:39 you can create test plans, which are referring strongly to a solution documentation scope

00:02:47 focusing just on processes from this particular scope. And then on the end,

00:02:54 we can also use the scope to export the content. This is a functionality that could be used to store your information,

00:03:05 to back up your information on your hard disk, and, if required, to restore some lost information.

00:03:15 Okay, again, the same, but based on pictures. So what you see right here is the solution documentation

00:03:22 with very many functional areas highlighted here in different colors.

00:03:28 So what you can do, you can create several scopes for the same solution.

00:03:33 And by that, you group, the processes together. This scope can be then associated and assigned to the project.

00:03:43 Highlighting that this project is dealing with this particular solution documentation.

00:03:48 And then finally, as I mentioned before, you can create a test plan,

00:03:53 which is also based on the same scope. But how does it impact the procedure of Focused Build?

00:04:01 How do we use the scope in our Focused Build requirement to deploy process?

00:04:10 Well, at the beginning, the procedure is quite simple.

00:04:15 For the Focused Build procedure, you upload, first of all, the best practice content.

00:04:22 And then you review the content. You select which processes you are interested in

00:04:28 and you regroup them into a structure, which you prepared before.

27

00:04:34 After that, it's quite easy to create solution documentation scopes. As the processes are already grouped in the structure,

00:04:44 you can just select the substructure and create out of that the scope.

00:04:52 After you have defined your implementation projects, you can assign the solution documentation scope

00:05:00 to those projects, and you can run your discovery workshops.

00:05:07 The discovery workshop would be usually organized in functional areas as well.

00:05:15 So you start your logistic workshop or HR or finance workshop.

00:05:21 For that, you select the scope in solution documentation screen,

00:05:26 and you just focus on those processes from this particular area.

00:05:33 And that's how you start to create requirements. Every requirement you create by that

00:05:41 will gets this information from which scope it has been created.

00:05:46 And this scope information can be extended while you still are processing the requirements

00:05:56 by new processes from this initially selected scope or by assignment of processes

00:06:05 or process steps from other scopes as well. If you approve the requirements

00:06:14 and create the work package, the scope information will be inherited

00:06:20 into the work package as well and highlighting for which structures,

00:06:27 for which scope are you working now. But it's not the only thing that is possible there.

00:06:35 Based on the scope assignment to your project, the project selection in work package

00:06:42 would be and is much easier. We will see that in the next slide,

00:06:49 how easy it is to detect the right project and to assign the right project to the work package

00:06:55 just based on the scope. Afterwards, you create just work items

00:07:03 and you proceed with the development procedures. Okay, let me show you that on the picture.

00:07:11 Here again, our beautiful solution documentation with the various processes from different areas.

00:07:17 But what we do first, we organize that in scopes. After that, if we create a project,

00:07:27 we assign the scope to the particular project. Here I assign HR scope to one project

00:07:34 and FI to another one. If you are now in a specific scope

00:07:43 and run the discovery workshop, the fit/gap workshop, and you started from the HR scope.

00:07:50 You create the requirement. This HR scope information will be inherited

00:07:56 into the requirement as we see here, together with the structure to which it is referring.

00:08:05 If you create a work package, this information will be passed to the work package naturally.

00:08:13 But if you start searching for the project, the right project will get detected quite quickly.

00:08:23 As the requirement has the information about this scope. And it's matching this information with the project

00:08:32 with exactly the same scope assigned. Afterwards, the work item is created

00:08:40 and you proceed to develop. So what are the advantages of using solution documentation

00:08:49 scope in Focused Build? Well, the first advantage is to assign

00:08:55 process management content to a project. And you can do one-to-one or several scopes to one project.

00:09:06 The second advantage is the possibility to assign scope to the requirement.

00:09:13 And also here, you can do that in relation one to one or many to one.

00:09:20 It's also the simplification of the project search for work packages, because it will be found

00:09:26 based on the scope assigned also to the project. And finally, it's reducing the complexity

00:09:35 of solution documentation in the process management area. Okay, let me maybe jump into the system

28

00:09:46 and show you the demo. If I would like to create a scope in SAP Solution Manager,

00:09:54 I have to go to the solution documentation area. In this area, I can jump to the right place

00:10:03 and go for new scope creation. In this particular case,

00:10:12 I would just like to reduce the visibility of processes by just one area, which is the end-to-end order to cash.

00:10:23 So my scope is focusing just on the processes, which can be found below this scenario order to cash.

00:10:32 I can save that. And by saving, I have to give that scope a name,

00:10:39 and please do not forget to highlight your scope public. If I create this scope, it's automatically selected

00:10:53 in the solution documentation screen. So what do you see right now

00:10:57 is that this newly created scope is selected. And if I jumped to show all,

00:11:05 so I deselect my newly created scope, I again see all the processes

00:11:12 that have been available already before. But if I select my scope again,

00:11:21 I see that I'm just reduced to those four processes. Let me demonstrate now how the scope

00:11:33 can be assigned to the project. I jump to the project area.

00:11:39 I select one of the projects I would like to focus on. And right here I can assign my solution documentation scope

00:11:50 to my project. So I search for that.

00:11:55 It would be found, and I can assign that easily. You see that another scope is already assigned

00:12:03 to the project, but it doesn't matter. You can assign several different scopes to your project.

00:12:11 Now it's time to create some requirements. So let's go to the solution documentation,

00:12:17 we've preselected scope, and create for the process step billing

00:12:24 a new requirement. So if I do so, I jump to the requirements management application

00:12:32 and I can create a new requirement. I have to enter the title.

00:12:40 I have to enter the priority. And already now you see that the scope has been

00:12:50 assigned to the requirement simultaneously with the structure to which the requirement is referring to.

00:13:02 Okay, so I can select additional structures from any scope in addition.

00:13:15 So if I select another scope, I can assign here processes from another scope.

00:13:21 I decided not to do that right here. So then what I see,

00:13:25 I still have my process step, billing with assigned scope attributes, order-to-cash, general scope.

00:13:36 Okay, I save it and I send for approval. The next step would be to approve my requirement,

00:13:45 which I do right now. After the requirement has been approved,

00:13:54 I am able to create a work package. So I create the work package, I assign here the priority.

00:14:05 And now what do we will see here is the big advantage of working with scopes.

00:14:12 Because right now I see just one project, this project where I assigned previously my scope to.

00:14:23 So I can deselect the scope influence on the project search. Then I see in this case two different projects.

00:14:34 But if I activate that, I see that it's only one project that is fitting into that.

00:14:42 I select my wave. And I select the work package classification.

00:14:49 That's more or less everything. If I jump now to my work package and set the right status,

00:14:58 I will be able to go to the Solution Documentation tab to see that my process step billing has been associated

00:15:11 with the right scope. And if I would like to extend the scope of my work package,

29

00:15:16 I can do that. But just from this pre-selected

00:15:20 order-to-cash general scope. Okay, so here I could select another process step

00:15:30 or other process steps from another processes belonging to the scope.

00:15:34 And by that, extend the work package. So however, I will not focus on that.

00:15:48 The next step will be to create the work item. And you can guess what will happen right here.

00:15:56 So I am selecting the sprint in which these work items should be executed.

00:16:02 And I specified a classification. I assign all the documentation structures

00:16:11 and after I have created my work item, the scope information will also arrive

00:16:23 together with this structure and appropriate documentation into work item, as you can see here.

00:16:30 I still can extend the scope of my work item in case I detect that I have to do more development

00:16:37 than was previously designed. But I just can select structure from the preselected scope.

00:16:48 Okay, I was promising to you that the solution documentation scope

00:16:51 can be used for project selection, but also for test plan creation.

00:16:57 So let me show you roughly what it would look like. So if I go to the test plan area and create a new test plan,

00:17:08 I have to select here, the test plan ID, as well as the test plan description.

00:17:15 And what you see right here is the selection of the solution, selection of the branch,

00:17:22 and those quick people already see the button Select Scope. This button is allowing you to focus in this test plan

00:17:33 on the solution documentation scope and on the processes that are included in the solution documentation scope.

00:17:42 So I select that and save that. And in the background, the right processes

00:17:50 included in the scope will be included in the test plan. Thank you very much for your patience.

00:17:59 See you in the next chapter.

30

Week 2 Unit 7

00:00:04 Welcome to unit number seven. My name is still Michael Skiba

00:00:09 and I am a member of Regional Implementation Group, responsible there for process management.

00:00:16 In the previous unit, we have learned how to create

00:00:19 and how to use solution documentation scope, especially in Focused Build.

00:00:25 In the current unit, and I promise you,

00:00:28 this is really the last unit of this week, we will look into the process reporting.

00:00:35 How to figure out how far in implementation my processes are -

00:00:41 that's the scope of our current unit. But before we do that,

00:00:47 let us jump into the reporting capabilities in general,

00:00:51 in Solution Manager. The standard Solution Manager

00:00:54 is providing two ways of executing reports. The one is standard reports,

00:01:01 developed and designed by SAP. Those reports can be slightly adjusted

00:01:08 by the customers. And then on the other side,

00:01:12 we have the great list viewer in which you can combine several different filters

00:01:19 to get answers to your questions. In Focused Build,

00:01:25 we extend that by adding a new dashboard. This dashboard should answer the question,

00:01:32 how far in development your processes are. How is the current implementation status of your processes?

00:01:44 And here the solution documentation scope is playing also a big role

00:01:48 as you will see in the next slides. The result of the report is,

00:01:55 however, branch-sensitive. That means if you run the report

00:02:00 for design branch, you will get a list of requirements

00:02:04 and work packages which are right now waiting for development.

00:02:10 They are not yet under construction. If you run this report for development branch,

00:02:17 you will see all requirements, work packages, and work items

00:02:21 which are currently in development, which are being implemented.

00:02:27 And then finally, if you run this report for production branch,

00:02:31 you will see the sum of all requirements, all the work packages

00:02:35 and all the work items for a certain structure,

00:02:40 for your solution documentation scope. How can you use this report?

00:02:46 Well, you can use that as a project quality gate. At the first stage,

00:02:52 you can use that to detect your backlog list. If you execute that for the design branch,

00:03:01 you will see all the requirements and work packages which are waiting

00:03:06 to be implemented in one of the next waves. Then you can use that interface Handover to Development,

00:03:15 just to ensure that all the document KPIs of your work package stayed green,

00:03:25 and nothing will prevent you to hand over to development,

00:03:30 as your functional specification and your test cases are raised.

00:03:37 And then finally you can use that also in the Handover to Release,

00:03:42 because also in this phase, you can ensure that all the requirements,

00:03:47 work packages, and work items are providing the green rating for documentation KPIs.

00:03:55 By the way, you will also see that you can download the result

00:03:59 of the report, and then further investigate on additional information for this.

31

00:04:08 I am asking you to wait for the demo. Okay, what is the result of the report?

00:04:16 The result of the report, depending on the branch you have selected,

00:04:20 and the scope you have selected, is a list of requirements, work packages,

00:04:25 and the work items which are coming, have been created for specific process area -

00:04:32 solution documentation scope. You see at one glance what are the documentation KPIs,

00:04:40 what is the current state of them, for every and each work package and work item.

00:04:47 In addition to that, you can use several different filtering criteria

00:04:52 for requirement, work package, and work item to manipulate the results of the report

00:04:59 to see different requirements or work packages in different states.

00:05:07 Okay, let me maybe do a demo for you. How does it look

00:05:12 and how to process that? As you can see, there is a new tile available,

00:05:24 which is called Documentation Reporting Dashboard. If you open that,

00:05:30 you will see this Business Process Readiness tile. But first of all, you have to select

00:05:37 the solution you are interested in, and the branch which is relevant for your reporting.

00:05:45 In this case, I am selecting design branch.

00:05:48 In the next field, you can select the scope you are interested in,

00:05:53 and here we take over the scope from the last unit,

00:05:57 which is the Order to Cash General Scope, and we focus on that.

00:06:01 What you immediately see is the number of requirements,

00:06:04 work packages, and work items for this particular scope in this branch.

00:06:11 If I jump into this tile, I immediately see the results.

00:06:16 And I can impact the results by selecting several different statuses,

00:06:24 for example, here for requirement. So I have selected "Draft" and "To Be Approved".

00:06:29 And as a result, in the results area below that, I see the three requirements listed.

00:06:38 I can also combine this with some other statuses from work package, in addition.

00:06:50 Or I just jump to development branch to see what is the current situation for my processes

00:06:58 from Order to Cash in current development. Well, what I can see is

00:07:06 there is much, much more that is currently under construction.

00:07:12 I can focus here on work packages being in development

00:07:17 and work items being in development, and the result list will show me exactly this.

00:07:24 All the work packages in this status and all work items in this status,

00:07:29 they are maybe connected to each other, or maybe not.

00:07:35 I can always combine several statuses from one object and even report on that easily.

00:07:44 And If I jump to the production branch and press the Go button,

00:07:49 I will get the result for the entire solution. I get the sum of all the requirements,

00:07:56 I get the sum of all work packages and work items there.

00:08:01 I can also make visible the IDs for requirements and work package and work item,

00:08:10 and I can place them in the results table in the place where I'm expecting that.

00:08:17 Okay, the result is that you see also right now the business requirements IDs,

00:08:27 work package IDs. And, finally, you can download

00:08:32 the results also to Excel. By doing so, you get for sure everything

00:08:39 that you have seen before, so all the requirements, all the work packages,

00:08:44 the status, the assignment to the wave, all work items,

00:08:49 and they assigned to the sprint the project ID.

00:08:53 But in addition to what you haven't seen in the report result,

00:08:59 you will get the list of structures which are relevant.

32

00:09:03 So the process structure, it could be process or process step.

00:09:06 And you see also the structure attributes. Based on those two pieces of information,

00:09:14 you can dig into the report and even combine the results

00:09:21 outside of Solution Manager. This was the process reporting dashboards,

00:09:32 and this was unit number seven. Thank you very much

00:09:36 and see you in the next chapter.

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 distr ibutors contain proprietary software 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 document 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 for 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 trademarks 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.