Conversion From ECC To SAP S/4 HANA

This note lists the minimum requirements and limitations for different platform options. Key points from the note are:

• In order to convert to SAP S/4 HANA with DMO of SUM 2.0, you should be running on SAP ERP 6.0 or higher and system should be a Unicode system. If you happen to be on older version of SAP ERP or on non-Unicode system, you need first upgrade to SAP ERP 6.0 (any EHP level) or do Unicode conversion. However, most of the customers are running on SAP ERP with Unicode, so this is not an issue.
• The latest SAP S/4 HANA version is 1809 running on SAP HANA DB 2.0, which is based on SAP NetWeaver 7.52. Technically this is your target version against which you should map your current system and plan your steps.
• If want to move to latest SAP S/4 HANA version and you are running on Oracle database, the source database must be Oracle version 12 or higher, or if you are running on MS SQL database, the source database must be MS SQL 2012 or higher. In other case, you need first do a database upgrade.
• If you are running on Windows operating system, MS Windows Server 2012 or higher is required if you want to move to latest SAP S/4 HANA version. If you have older Windows operating system, you will need to do OS upgrade first.
• “DMO with System Move” scenario allows to switch the application server, which means that you can move your system to different data center. Earlier there were limitation for DMO with system move scenario, but currently all source databases and any unix-based or windows operating systems are supported.

Everything really starts on where you are now and that dictates how your transition path can be planned. When you want to start planning your path to SAP S/4 HANA, minimum information you need to share with your partner is EWA reports for your SAP systems. EWA reports contain details for your systems and based on that your partner can plan what steps are needed for you to move to SAP S/4 HANA. The actual schedule and sequence of tasks can then be aligned with your own plans of how functional transformation should be handled: would you do only the technical conversion with minimal mandatory application side changes or include implementation of new functionality along the conversion project.

More ( Link) On Click of the link..it can take to below information

Conversion from ECC to SAP S/4HANA

The digital economy of today makes it necessary for enterprises to persistently and periodically engage with their global customers. Enterprise environment being Digitized results in organizational impact mainly in terms of a Business model or the way an organization does business. This implies that enterprise victory depends on two prime elements – the capability of an organization to flawlessly connect with its customers and the capability of the organization to manage changes in its business models as quickly as they come along.

This is where S/4HANA comes into the picture – with its design focused on thriving in the digital economy of today. The Digital Core of S/4HANA enables the organization to carry out its business processes aligned with the new Digital economy by using a barrage of simplifications in User Interface, Data models, and Applications. The flip side of this is that S/4HANA also empowers the enterprise to connect to the outside world at an accelerated pace, in this context machines and customers.

Enterprises can migrate to SAP S/4HANA making use of the standard migration road. And these businesses have previously been running on SAP ERP 6.0 the correct method is system conversion. SAP S/4HANA is said to be the next generation of business suite enterprise software from the house of SAP.  SAP developers have painstakingly customized the solution to meet the challenges and requirements of the digital economy, especially with the help of the SAP Hana in-memory platform. Enterprises can enhance the current processes along with realizing brand-new processes to benefit from the edge against their opponents in the digital economy.

SAP S/4HANA can serve as the digital code of enterprise it architecture with said Enterprises being able to emphasis on digital processes. This is where enterprise situations are implemented efficiently and promoted with equal efficiency.  Therefore, SAP S/4HANA does not just serve as the next version of the SAP Business Suite but it also stands for a brand-new product line. Therefore, the migration to SAP S/4HANA is not a unique task like database migration or upgrade.  Conversely, it includes the complete system landscape and this is why companies should plan, such a transformation by measuring their optimal future SAP architecture. This will make the user’s life much easier. Since the transformation is comprehensive in nature, it enables heterogeneous and complex IT system landscapes to be taken out of the picture.  This will lay the foundation for processes which are more streamlined and simple.

Three Paths to the Destination:

Just like SAP Business Suite organizations can select from three possible routes for migration to SAP S/4HANA- landscape transformation, system conversion, and Greenfield implementation.  While evaluating the best part of the enterprise the target architecture under consideration is very essential.  As mentioned before Enterprises that are already using SAP ERP 6.0 with an improved package and higher can directly migrate to SAP S/4HANA using a system conversion.

 

 

Options to adopt S/4HANA:

Going by the reasons and context stated above, the S/4HANA adoption of Enterprise Application with regard to processes is desirable, to say the least. In the future, it may very well be inevitable. Businesses new to SAP can go straight ahead with implementation of S/4 HANA. But enterprises already powered by previous versions and products of SAP will need to get some queries out of the way first.

It is essential that a prospective customer should analyze all options with regard to key parameters and decision factors when it comes to adopting S/4HANA effectively.

System Conversion:

Enterprises already running on SAP (ECC), will find that adopting S/4HANA is simple. This is by using the system conversion method. A pre-existing SAP ECC instance can be transformed into a S/4HANA instance with all the historical data complete when supported by efficiently documented processes going hand in hand with System conversion tools which are inbuilt. This migration scenario is standard and established and has detailed protocols for execution, including numerous technical steps to reach S/4HANA and steps for code optimization for the Custom code created in the pre-existing system.

New implementation of S/4HANA:

The scenario discussed above is an idealistic one not applicable to most businesses currently in the market. Such enterprises do not have an optimal SAP deployment leading to accumulation of massive amounts of data. In this case, it is best to drop efforts which are too cumbersome and resort to a brand-new S/4HANA implementation.

A new implementation is most often the path of least resistance because of the factors stated below:

Sub-optimal Enterprise Structure:

The most significant part of an SAP implementation is the definition of organizational elements. This is strange as element definition typically occurs at the start of the implementation. And when an implementation begins there usually is no comprehensive understanding of processes involving SAP.

Process controls and reporting structure emanate from an enterprise structure; hence its importance cannot be stressed enough. The true value proposition within Enterprise Structure definitions will reveal themselves only after the system attains a level of maturity. And for a considerable amount of time would have elapsed, making changes at such a later stage becomes problematic at best. In particular, the cases of the original implementation, Enterprise Structure definition will be affected due to the constraints posed by SAP, which may lead to a sub-optimal setup. Brand new functionalities mean some of the older SAP constraints will not pose a problem opening up the scope for a more practical Enterprise Structure definition.

Poor Data Quality:

Another frequent scenario that one can observe is enterprises running on SAP instances face problems with Master Data.

The problem with the quality of Master Data is two-fold:

Inaccurate and sub-par structural definition of Master Data is a major issue. This problem can be from numbering logic for the Material Masters or even the definition of Customer and Vendor Account Groups. Another issue that could be of concern is structuring for Chart of Accounts. This might create inflexibility in fresh business processes and reporting requirements which in turn will lead to restricted businesses by adopting unsound workaround solutions or buggy permanent fixes.

The lack of governance of Master Data:

Several instances can be observed with the unmonitored generation of Master data prior to the installation of a proper governance system and policy. This means data duplication and an unwanted accumulation of unneeded data in the system, leading to inaccurate processing of transactions. This might also create problems with regard to inefficiency resulting from confusion. Such a scenario will also call for a fresh implementation.

SAP has not fully leveraged: Many reasons contribute to a lesser than full utilization of SAP features and functionalities:

• Business needs have changed considerably over time, but the ERP dealing with the corresponding needs has not evolved in time due to reasons of insufficient time, budget or other resources keeping enterprises from updating to suit modern IT landscapes.
• An idealistic and original implementation of SAP is bound to be simplistic and not flexible enough to adapt to volatile market scenarios which have become common place with exponential developments in IT. The full potential of SAP systems can only be harnessed with the aid of a customized implementation.
• Insufficient competency in particular topics such as Materials Planning Credit Management, Cash Discounts, Rebate processing, Actual Costing, etc. Leads to poor data for these processes, therefore, making these processes either redundant or leading to complete elimination.

High level of Custom developments:

Many scenarios see processes out of alignment with standardized best practices. This will lead to the re-introduction of older and outdated processes through the original SAP implementation. Therefore, there will be a larger number of custom developments, which will be responsible for running mission-critical business processes. When you incorporate a high degree of customizations it might lead to some problems as mentioned below:

• Insufficient flexibility to adapt to changes is a possible hassle since every change that has to be implemented will have associated costs and segregated and distinct efforts and resources.
• Heavy maintenance might result since a highly customized environment necessitates a whole sub-department for its periodic maintenance and troubleshooting hence choking the resources and bottom line of the enterprise.
• Inability to harness new innovations is also a byproduct of high customizations since businesses don’t adopt the standard processes frequently in this case, missing out on key innovations that are expected in the standard processes.
• In such an environment, the movement to S/4HANA presents a good opportunity to have a re-look at the customization done and adapt to standard best practices through a fresh and new implementation.

Multi-system & multi-application environment:

Massive businesses have a tendency to create a complicated and interconnected network of systems and applications for core enterprise processes. Such a complex network of systems may be a result of custom-made applications or as a result of joint ventures between companies and acquisitions and mergers. In such instances, the enterprise will have to deal with an overly complicated network of applications and Systems which will need to be interfaced. Therefore, a thorough simplification of a landscape in terms of applications and systems becomes necessary. This is when you will have to consider the journey to S/4HANA which presents an amazing opportunity to rehash the system and application landscape and simplify the same. This will again require a brand-new implementation of SAP S/4HANA.

S4HANA_Migration Scenarios

System Conversion:

System conversions to SAP S/4HANA will retain the actual system ID for customization, interface, authorizations, data, and development.  This is otherwise called an in-place migration. Systems which are powered by SAP ERP 6.0 using enhancement package and higher can undergo migration to SAP S/4HANA directly without the need for upgrading to an enhancement package which is higher. This is based on the assumption that the system is previously a Unicode system.  After the release of SAP NetWeaver 7.5, SAP is set to support only Unicode systems.  If an enterprise system is not Unicode, it has to be converted into Unicode prior to the conversion.  The system conversion to SAP S/4HANA is added by SUM-DMO which is the software update manager with the data migration option. This will support enterprises in upgrading and migrating database is in a single step, eliminating massive amounts of downtime.

Readiness Checks Pave the Way for the Migration:

To assess the readiness for migration, enterprises are required to adjust IT systems to match Framework needs of SAP S/4HANA while system conversion occurs. The best method to carry out such analysis will need adjustments in four distinct steps.  This can be called as a readiness check for SAP S/4HANA and you should be executed as soon as possible to get a bird’s eye view of adjustment that is possible. And going forward these measures which are preparatory in nature can be assessed during the live operation wherever it is applicable.

Step 1: Maintenance Planner This is used to verify and Enterprises business functions, IT system add-ons, and industry solutions.  If this particular, check does not yield a conversion path which is valid then the maintenance planner will put off the system conversion as the stack XML file cannot be created. Ok for this would be when an add-on

has not been published yet. In such a case associated partner should be informed about researching when the add-on will be released.  When it comes to sandbox system conversions it is possible to generate an exception and go ahead with the system conversion without the add-on release.

Step 2: Simplification List

This will offer a lengthy description of how SAP S/4HANA will affect individual transactions along with solution functions of the SAP ERP system and this will be done on a functional level. When such a list displays functions and transactions no longer exist, it does not essentially mean that the particular functions will be lost.  It actually means such functions will be integrated with other components are reflected in a new architecture or solutions.

Distinct objects of the above-mentioned simplification list are reliance upon the existing SAP S/4HANA feature package stack and can be classified as:

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

Presently a large number of objects within the simplification list can already be assessed through the use of Pre-checks.  There are of course leads to processes which are automated and which can be used to find whether simplification objects are appropriate or match with customer specific system usage and if such objects are being planned.  Also, you should remember that all search points are not relevant to the system instead the required effort for the conversion should be found for 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

This is a mission-critical feature of SAP S/4HANA and is the simplification of the data model. SAP office compatibility views for tables that are not required anymore while migrating to SAP S/4HANA.  SAP also offers check tool that is founded on SAP NetWeaver 7.5 which verifies required adjustments such as adjustments needed for field length extensions.  Simplifications in SAP S/4HANA can be imported from a file and contrasted with code extracts of SAP ERP systems. The reviewed customer code and the indication as to the code are required to be changed is given within a list so as to improve the chances of compatibility with SAP S/4HANA. There are also detailed plans to completely integrate such checks as a variant of the SAP code inspector in the near future. Currently, the tool is checking of adjustment of material number lengths.

Migration via SAP S/4HANA Finance:

Migration to SAP S/4HANA can also be executed along with an intermediate step for SAP S/4HANA Finance.  Simplification of Logistical processes has not yet been done in this particular step.  Technically speaking, this is actually an add-on which is made available for enhancement package 7 for the version 1503 or even as an add-on for enhancement package 8 for version 1605. To reiterate, such a migration is made possible in a single step and for this, the system must be Unicode. SAP also offers customers with ABAP reports to check needs for this type of migration, such a report must be executed in the local SAP ERP system.