SAP S/4HANA Cloud Fit-to-standard approach for technical areas

Introduction

There are lot´s of good SAP blog posts, which describe Fit-to-standard methodology. Many of them highlight main points for business-related topics. I would like to sum up my experience in relation to SAP S/4HANA Cloud Implementation Fit-to-standard methodology for technical topics. There are following streams in SAP S/4HANA Cloud implementation projects, which require more technical knowledge, rather than business:

• Integration
• Migration
• Output Management
• Embedded Analytics
• Master Data Management
• Extensibility
• Security

In this blog post I will focus on the first 4 points, as MDM, Extensibility and Security streams require separate articles.

General remarks

As well as in any other project, distribution of responsibilities is one of the most important topic from the start. In terms of SAP S/4HANA Cloud implementation projects two main approaches are possible:

1. SAP/Partner “enables” a customer at the early stages and follows-up with support activities. It means, that as much as possible “know-how” information is provided to a customer during discover, prepare and explore phases and customer is ready to do the majority of implementation and development activities during realize and deploy phases on its own (here and further we are talking about technical “streams” first of all), addressing to SAP/Partner specific questions, which cannot be resolved based on the various available sources of information (SAP Help, SAP Notes, SAP Blogs, etc.). On the one hand, this can decrease cost of the project. On the other hand, it is important to understand, that in this case full responsibility for the real implementation of, for example, integration flows, output forms, master data rules and other is laying on the customer side. Therefore this approach makes sense, when following pre-requisites are in place:

• Customer has extended and experienced technical department for all development and implementation activities
• Instead of SAP Integration Suite 3rd-party integration middleware is planned for usage and customer knows how to work with it better, than SAP/Partner
• Cooperation between customer business and technical departments is well-built – this is critical for data migration activities, for example
• Other than SAP S/4HANA Cloud Embedded Analytics solutions is available in customer landscape
• Customer is at least familiar with Adobe LiveCycle Designer
• Comprehensive MDM system already exist in landscape, in case the landscape is complicated and contains many different systems

2. SAP/Partner plays the main role in the project and does both: enablement and implementation. This approach has following disadvantages for a customer:

• This, for sure, increases project´ cost
• Business-related information is anyway necessary for the technical activities. And as far as SAP/Partner in many cases does not know customer´ business in details, lot´s of questions will be stated to business colleagues, what could distract them from daily business
• Implementation project will end at some point of time anyway, and customer will need to “live” with the system on it´s own. Therefore enablement phase remains critical and it is important for customer´ developers and key users to get their questions replied. As far as SAP or partner will be in charge of all implementations, this point could be mistakenly missed.

In the same time, following pluses have to be mentioned:

• This approach significantly decreases risks of go-lives postponement, as the timelines will be calculated based on SAP/Partner experience for every topic of the project
• Customer can be sure, that provided solutions will be SAP Best Practice-based, rather then individual, custom workarounds, which imply complications for the later support will be used
• From a customer perspective we can say, that enablement phase will be “extended”, as active transfer of knowledges will happen alongside all the project and not only in the 3 first phases
• Developments in all technical areas will be properly documented – preparing of development´ specifications is one of the most frequently missing activity by the first approach, described abov
• Time, spent for development activities will be also decreased, as involved developers will have experience with similar/same tasks in past and will be familiar with all available information sources. In some cases this can even decrease final project cost

As you can see, both approaches have advantages and disadvantages. But regardless of which approach will be selected, distribution of responsibilities has to be stated in the very beginning of project and remain unchanged.

Now let´s move to observations, valid for separate technical “streams”.

Integration

Building or re-building of integration landscape, aimed to SAP S/4HANA Cloud becomes quite often the most problematical area for the project due to the following reasons:

• Development of every integration scenario requires knowledge from both sides – technical and business (for data mapping first of all)
• New requirements to an integration flow appear often after start of development
• Available APIs could work differently, comparing to existing in customer landscape mechanisms and searching for workaround is necessary. For example, it could be the case, that S/4HANA Cloud expects to receive some information via posting via API and customer 3rd party system cannot send this information
• Customer could decide not to use SAP Integration Suite, but it´s own middleware. In this case SAP consultant can assist very limited with building of integration flows, and customer should plan significant resources for development from it´s side.

Here are the ways to keep integration stream on track and to develop high-quality integration flows:

1. Obviously, integration specifications should be ready before start of development activities and remain unchanged. As well as for any other developments, implementing new requirements in process of development increases significantly development costs and decreases development quality.
2. For work on every integration scenario at least 2 colleagues should be available: business and technical expert. Optimally 4 experts are necessary:
1. Technical expert from customer side, who knows overall landscape and company policies well
2. Business expert from customer side, who understands well all business requirements
3. Technical expert from SAP side (integration developer) to understand, how existing integration scenario can be reworked and improved with latest innovations or how to build the new one in the best way
4. Business expert from SAP side to reply questions regarding S/4HANA Cloud system “expectations”
3. The next kind of “obvious advise” is to use SAP Integration Suite. It is fair to mention, that this tool allows more options and contains more innovations, comparing to many middleware tools, which are in use at customer landscapes. Decision to use SAP Integration Suite automatically leads to increase in number of consultants and developers, who can participate in implementation and support activities, what speeds up project and decreases go-live risks.
4. Dedicating integration scenarios to different go-lives could be really helpful. In the majority of cases it is possible to identify business critical flows and develop them in a first row, postponing the others for implementation in a month or two.
5. SAP Integration Suite provides versioning functionality, what means, that changes in integration flows can be easily tracked. However, this is it – tasks´ and bug´ tracking functionality is missed. And project experience shows that, unfortunately, standard for SAP S/4HANA Cloud implementation projects backlog file does not meet all needs of integration streams. Therefore it is highly recommended to use for this stream 3rd party tasks´ and bugs´ tracking tool or prepare separate excel file for this at least.

Migration

This topic can also become very challenging due to the following reasons:

1. The same as with the migration, strong collaboration between technical and business experts is necessary.
2. Original data structure could differ comparing to those, which is expected by SAP S/4HANA Cloud and in the migration templates correspondingly.
3. For some data sets, migration via integration flow is preferable option, rather then migration templates, what lead us to challenges from Integration chapter.
4. Error messages in Migration Cockpit are not very “user-friendly”.
5. Lack of testing in Q system.

Would could help us here:

1. As mentioned above, strong collaboration between business and technical experts is necessary for this stream as well. Ideally – two experts from each side for each data set.
2. For some reasons, available information for migration objects is quite often ignored. It is strongly recommended to use following data sources for every migration object:
• SAP Help
• SAP Notes
• SAP Blogs
• Migration templates, filled with sample data (available for limited number of objects)
• Additional information, which is available in every migration template
3. Try to do as much testing, as possible in Q system: it could be time consuming, but it certainly decreases risks by productive go-lives.
4. It is true, that it is often hard to understand error messages in Migration Cockpit, but searching for the same errors in SAP Notes and in SAP Blogs could be very helpful – for most of them example solutions are already available
5. Try to use one migration project for all migration templates/objects, related to one org structure.
6. Having separate progress, tasks´ and bugs´ tracker for this stream is also an absolute must. Again, it could be 3rd party tool or simple excel file.
7. Try to use migration templates in as many cases, as possible. This simplify process greatly, comparing to migration of data via integration mechanisms.
8. Migration templates extensibility is already available in limited cases and individual approach. Consider searching for a further information about this option in case of strong necessity.
9. Start test migration activities only once all related to migrating data system business customizing is done and checked.
10. Dedicate key users for thorough testing. This, for sure, should do other colleagues, rather than those, who do the data migration, as both of this tasks require significant efforts. Please, notice, that SAP S/4HANA Cloud applications for data checks after migration are mentioned in the end of SAP Help pages for specific migration templates.

Output Management

This area is considered quite often as less important, comparing to data migration or data integration and can be even missed during project planning. Needless to say, that this attitude is totally “unfair” and this is the technical stream has the same business criticality, as data integration and data migration. Moreover, it requires the development approach of the same quality and thoroughness, as the two previous areas. That means the following:

1. Again business and technical departments have to be involved both – technical expert as a form developer, business expert to state the requirements and to do the testing. For final customizing in SAP S/4HANA Cloud joined sessions are the best.
2. As well as for integration flows, specification of forms should be ready before development start and remain unchanged.
3. Tasks´ and bugs´ tracking would be also of great help here.
4. Additionally to them it is recommended to use graphical redactor (even simple Paint will fit) to specify necessary changes in forms.
5. It makes sense to implement minimum custom JavaScript to speed up development process and forms´ load, but developer with JavaScript knowledges is a must for this technical stream.
6. One of the key point for Output Forms development is real fitting to standard: it is clear, that old forms, which were used in a company before SAP S/4HANA Cloud implementation are much more familiar and therefore understandable to business colleagues. However, in many cases it is possible to switch to standard SAP S/4HANA Cloud forms without any negative business impact. Therefore detailed business judgement and strong reasons to implement changes in standard form have to be provided. Usage of standard SAP S/4HANA Cloud forms will speed up this stream greatly and in many cases business will benefit later from them.
7. To meet go-live dates and develop forms with high quality it is also helpful for this stream not to assign all forms to the first go-live, but only business-critical.

Embedded Analytics

Based on my experience this stream usually does not endanger go-lives due to the following reasons:

1. Quite often customers prefer to leave part of analytical scenarios in old solutions and to use for the rest SAP S/4HANA embedded analytics. Such an approach makes sense, as it helps to meet go-live dates and to enable key-users for new analytical solution more smoothly.
2. Even if all planned analytical scenarios cannot be timely implemented, it does not mean immediate financial losses or business impact, therefore they can be slightly postponed.
3. SAP provides very significant number of analytical scenarios, available out of the box, what allows to decrease efforts for this stream.
4. If customer decides to use SAP S/4HANA Embedded analytics and SAP Analytics Cloud simultaneously, enablement phase becomes corner-stone for this stream: most of customer´ requirements can be covered then by out of the box capabilities, and efforts for custom developments will be very low.

In the same time following items can improve the stream´ flow:

1. As well as for the already discussed streams, collaboration between tech and business colleagues would be of great help here.
2. Clear specifications, which are available before development and implementing are again necessary.
3. If it is necessary to reproduce reports, which were based on old ERP tables, please, take into account, that corresponding from business perspective CDS views can contain the same information, but have different names of fields. In this case judgement of SAP business expert is necessary.
4. The same as for other streams, it would be helpful to use tasks´ and bugs´ tracker – this will allow to have up-to-dated information, for example, about problematical fields, missing calculations and problems by displaying data.
5. It really helps to validate business requirements from technical limitations´ perspective to avoid performance problems in future.
6. CDS Views-based integration is certainly an option for SAP S/4HANA Cloud, but possibility to use standard APIs should be check firstly.