Archive for August, 2016

SAP S/4HANA Logistics: A Functional Perspective

August 30th, 2016

As of the latest releases (May/June 2016) for S/4HANA packages both On Premise (Edition 1511 FPS02) & On Cloud (Edition 1603), there have been certain significant enhancements & extensions on the functionalities under logistics. In this piece, I will focus on the business value & benefits of different offerings under Sourcing, Procurement, Supply Chain & Manufacturing along with key functionalities provided in S4/Hana under each of them. I am not at all going to touch on the technical differences between OP & Cloud editions but at a broader level will highlight the functional aspects which are quite similar for both sort of deployments.

SAP has tried to make it clear that SAP S/4HANA is a new product line & not the successor of any pre-existing business suite but the sort of functionalities covered under S/4HANA Enterprise Management edition directs one to think that if at all they will be migrating to S/4HANA which is inevitable, they have to leave the existing business suite behind to fully harness the capabilities S4/HANA has to offer. I also totally understand that the offerings under On Premise & Cloud edition may differ a bit but not to such an extent that we have to have separate write-ups from point of view of covering logistics functions.

I will be discussing the Key Innovations under each area in S4/HANA as per the mapping into product map & I will also try to go deeper wherever needed into exactly how these innovations will work for any business based on the best practices adopted into S/4HANA.



Simplicity – Procurement is an area is well known for the complexity, manual work, time-consuming processes with high volume of purchasing documents and line items. S/4HANA lowers the procurement operation cost by providing a simple yet efficient procure to pay process facilitated by Fiori apps i.e. for Analytics, Spend KPI’s. User experience is simplified & enhanced by role based apps. Business value is added by real time analytics.

Visibility – S4/HANA gives ultimate visibility at fingertips by using Fiori apps, providing Ad-hoc supplier transparency & performance evaluation based on detailed data points & most importantly integrating with SAP Ariba network for transactional data.

Adoption – Procurement process is supposed to be manual or semi-automatic leading to slow cycle time & error prone. S/4HANA has Self-Service Requisitioning leading to higher business user adoption through a consumer-grade user experience. It also offers five times less interaction steps to get the procurement information leading to faster & accurate data.



Accuracy – Due to missing real time analytics, process & data redundancies one can’t be sure of the accuracy of valuation or Inventory figures. S/4 HANA is capable of more timely & detailed real-time processing of Inventory postings leading to higher accuracy of Inventory. Parallel inventory posting for standard price-driven materials is also possible. This also helps in Improved On time delivery. Valuation is more accurate since it’s based on one valuation method (Material Ledger) instead of 2 (MM-IM and ML). All of this is simplified by use of Fiori apps for Mangers as well as warehouse resources.

High Inventory Turnover – S4/HANA gives more visibility & accuracy of Inventory across the board & hence lesser Safety stock can be an option which will help to have better Inventory turnover ultimately leading to reduced Working capital cost to company.

Segment of One – S4/HANA offers real-time processing instead of batch processing & support to manage dynamic demand fulfillment for even lot size of one & facilitate this throughout the logistics operations.



Flexibility – It’s is common to have revenue loss due to stock-outs & poor on time delivery performance. S4/HANA offer prioritized view on material flow issues with clear visibility. It also gives system-generated solution proposals & automated creation of procurement proposals. It’s flexible in tailoring of available capacities and receipts to meet required quantities.

Quick – Accelerated MRP run on S4/HANA can be 10+ times faster along with faster demand propagation along the supply chain giving more chances for simulation & better planning quality.

Real Time – S4/HANA offers Real-time alerting based on current stock requirements situation as well as Real time Inventory picture.


MRP Fiori apps offers managing and monitoring external and internal requirements, material coverage, monitoring production or process orders. It’s planned to have one MRP system for planning including the APO PP/DS into S/4 Hana & Live cache-based, finite-capacity planning as an integral part of the SAP HANA platform, requiring just one database to manage along with simplified data integration, advanced analytics. It will also offer Intuitive maintenance of master data and integration models. This will be a great innovation & edge for planning aspect on S4/HANA since this will lead to fulfillment of an order on time with accurate quantity using various checks for different business scenarios along with performing automatic back-order processing.



On Time – S/4HANA enabled mass product availability check for sales, planned and production orders i.e. ATP check for all items of an order at once which leads to fulfill an order on time and in the desired quantity using different kind of checks for different business scenarios. It helps to promise accurate and reliable order dates & to fulfill orders from the entire network or to substitute products automatically.

Efficient – S/4HANA has significant performance improvements for releasing large production orders. There are plans for data and process innovations in Backorder processing and Sales Product Allocation.


PS: All the above are personal perspective on the basis of exposure to information provided by SAP on S/4HANA.



August 23rd, 2016

Before the era of computers, we had documents. We had Sales Orders, Purchase Orders or Accounting Document. Likewise, all the business processes are represented by a document. With the invent of computers and Database, these are represented by a table called core table to represent the line item table. These tables had about 200 to 400 fields depend on the industry of record.

Whenever there is a change in these documents, the whole record is copied and created a new record. When there are series of changes in a document, there is a necessary to keep track of all the changes in a changelog table. Like who changed it or what changed in it for Audit purposes.

In those days, Data Modelers have got an idea to split the table into smaller ones like header, line and schedule line evolving to the concept of normalization. Of course the other tables have fewer fields. But the concept remains the same. If anything changes it copies the whole record and maintains the changes in the Change Log tables of their own. For this reason one business process has so many smaller (20 to 30) tables forming a cluster by having a join between them. Currently this is the process to support traditional databases.

On top of this there are database constrains like many to one issues or Join relations, DB administrators have to keep it intact to maintain and sustain it. Also, have locking, latching, deadlock, Paging issues and thus creating lot of performance issues. It has two things, massive table space usage and reading these tables is too slow. When the DB is slow, for all these tables with the method that has to be read by a query, we start adding indexes further creating new tables. On each of these tables, it is not necessarily 1, there could be many indexes. These are copy of the tables with a narrow method of access. For the fact that system is getting slower, we are trying to copy the tables taking yet more space and forcing the system to narrowly usable.  But, it turns out to be indexes are not fast enough. So we have started creating aggregates. These are whole new tables by managing the SAP code build and tested to get like daily/weekly/monthly total invoices, thus getting more complex in managing these SAP codes and customer exits. This is all to get better reporting and speeding up the system. These are the standard Indexes and aggregates. But our great DBA’s, with their experiences, they analyze the queries specific to the customers and they build additional custom indexes and aggregates. During the upgrades, service pack updates, and new releases, apart from the work what we have to do, system also has to do lot of work by rolling up the data to all these standard and custom build tables, indexes and aggregates to reflect the changes in the documents and be reportable.


Just a case, if we have to build a dashboard reporting, as a developer, we need to know what business processes change will impact what tables or trigger any change and how it is influencing down the flow. That’s why BW has become significant. SAP has integrated the flow and made a module specific or process specific extractors enabling the single source in BW. BW Extractors took care of this spider web of tables and simplified the logic which makes sense to the consumers.

This is only way we have to run the system brilliant and all the traditional databases are being the best to build and sustain the model. Now, let us talk about what different is in S4 Hana and why?

Alternatively we have to think of getting away from this complexity.

With Suite of Hana, SAP did several things, They were able to drop the need for some of the Indexes and aggregates but the fundamental aspects of all the documents and relations, tables required to maintain them was unchanged in order to have compatibility for customers.

But S4, Complete rethinking by leveraging the capabilities of Hana by simplifying it for customers and making it much more agile for development staff. Document concept is still the same. We still have the same record but it is not a row table. It is now represented as individual columnar stores for each of the fields. The big difference is, if the value changes, we just insert one field. We don’t replicate the whole record with the changed values. It is almost impossible to run this for such a 400 field tables in any relational data bases having so many table rows and indexes. We still have the same no of field changes but each field will have its own columnar storage, which means every field can act as an individual index.

We are now to 1 table from the spider web of 20 to 30 tables for each business processes. All the complexities I talked above on the table locking and latching is no more an issue.  I have to take care of only one locking issue that might happen during the multiple inserts on the same columnar table. We do not need to create whole new aggregates for a new requirement. We can run on the same table and Hana creates on the fly. No need to create any indexes to speed up the process. We don’t need any different status tables or header tables. So all these nested tables has been collapsed into one single line item document. All the SAP code in maintaining the cluster of tables is now that my understanding is all gone. Now think about the testing and regression required, all of that is radically simplified which means higher quality process. With all those variations, ups and downs, mistakes that can go wrong is traditional databases is tremendous with comparison to when we code against this S4 simpler process.

As you read, S4 is a huge innovation leveraging that was not possible before HANA due to both its ability to have a simple system and ability to aggregate on the fly and enabling new code pointing to this simpler structure.


Last, but not the least, Traditional Data bases with this complex structure, they are not compatible with Multi-Tenant Cloud. It has to go through a hosted service or an On Premise environment. SAP took care of this issue while upgrading from clustered table structure to new code line of S4 HANA, they designed in such a way that they can run on multi-tenant cloud or hosted or On Premise. It enables customers to go back and forth between these business models. This is not possible with any of the other ERP mates.


S4 Hana is enabling lot of business benefits leveraging the advantages from Suite of Hana.

S4 Hana Rocks!

Source : Bhanu Kishore Pulla 


Upgrade SAP S/4 HANA in 4 Steps

August 22nd, 2016

It is not a question of IF but When to upgrade to S/4 HANA. Being a SAP Partner company, at 2iSolutions, we are getting a number of enquiries to upgrade to S/4 HANA from ECC. In addition of implementation cost one shall also consider the Hardware and additional software cost.

There was a lot of confusion on SAP upgrade checks and steps. Here is a summary of steps (Source: SAP)

Source SAP

System Conversion

In technical terms, a system conversion to SAP S/4HANA retains the system ID for Customizing, development, data, authorizations, and interfaces. This is also known as in-place migration. For systems running SAP ERP 6.0 enhancement package 0 and higher, companies can migrate directly to SAP S/4HANA without having to upgrade to a higher enhancement package. This assumes that the system is already a Unicode system. Following the release of SAP NetWeaver 7.5, SAP only supports Unicode systems. If a company’s system is not Unicode, it must be converted to Unicode before the conversion. The actual system conversion to SAP S/4HANA is supported by the SUM-DMO, the Software Update Manager with Database Migration Option. This helps companies upgrade and migrate databases in one step, meaning just one period of downtime.

Readiness Checks Pave the Way for the Migration

To ensure the migration is successful, companies need to adjust their IT systems to meet the framework requirements of SAP S/4HANA during the system conversion. It is best to analyze the required adjustments in four steps. This “readiness check” for SAP S/4HANA should be performed as early as possible to obtain an overview of possible adjustments. These preparatory measures can then be analyzed during live operation where applicable.

Step 1: Maintenance Planner

The Maintenance Planner checks an organization’s business functions, industry solutions, and IT system add-ons. If the check does not produce a valid conversion path (for example, because an add-on has not yet been published), the Maintenance Planner prevents the system conversion because no stack XML file can be generated. In this case, the relevant partner should be contacted to find out when the add-on will be released. For sandbox system conversions, it is possible to create an exception to continue the system conversion without an add-on release.

Step 2: Simplification List

At a functional level, the simplification list provides a detailed description of how SAP S/4HANA will impact the individual transactions and solution functions of the SAP ERP system. If this list shows transactions or functions no longer exist, this does not mean that certain functions will be lost. Instead, these functions will be merged with other elements or reflected in a new solution or architecture.

The individual objects of the simplification list are dependent on the current SAP S/4HANA Feature Package Stack, and can be grouped into the following categories:

  • Changes to existing functions
  • Functions no longer supported
  • Functions that are no longer strategic

At present, numerous objects of the simplification list can already analyzed using pre-checks (see the next step). Other automated processes to determine whether simplification objects are relevant with regard to customer-specific system usage are currently being planned. It is worth noting that not all points are relevant for a system. Instead, the effort required for the conversion should be determined for the relevant points.

Step 3: Pre-Checks

Pre-checks review the system settings that are required to perform the actual system conversion. These are available to customers in the form of SAP Notes, and can therefore also be used in step 2.

Step 4: Review the Customer Codes

One of the most important features of SAP S/4HANA is the simplification of the data model. SAP provides compatibility views for tables that are no longer required in the migration to SAP S/4HANA. SAP also provides a check tool based on SAP NetWeaver 7.5 that checks necessary adjustments, for example adjustments required for field length extensions. The SAP S/4HANA simplifications can be imported in a file, and compared with a code extract of the SAP ERP system. A list is created showing the reviewed customer code and indicating any code that needs to be changed to make it compatible with SAP S/4HANA. There are plans to fully integrate these checks as a check variant of the SAP Code Inspector in future. The tool currently supports checks of the adjustment of the material number lengths.

Source SAP

For More Info: