print this page
Latest Post

S/4HANA- Why Sourcing and Procurement Will Never Be the Same with SAP S/4HANA?

Imagine for a moment that you are a procurement officer working for a national retail chain. You just learned that your marketing team is gearing up to launch a national promotional campaign for a product line. The promotion is a very big deal for the company, and many executives are relying on it to meet revenue and profit targets.
But wait a minute: It’s Friday, and you have already planned an exciting weekend off. The last thing you want is this promotion overshadowing it. Now, what if you had all the information you need right now that can help you ensure that the promotion is successful without running out of stock or ending up with lots of excess inventory?
Let’s compile a quick list of critical information you might need:
  • Which vendors currently supply the materials that are part of the promotion?
  • When do their contracts expire, and what are their consumption rates?
  • What are the historic performance scores of these suppliers?
  • Are there other suppliers that were used in the past that you could procure form?
  • How long will it take to onboard these alternative suppliers, if needed?
I’m sure you can think of a few more questions but let’s work off of these for the time being. Now, revisit the above list again and mark down how many of these questions you can answer right now at this very moment. How many of them you can answer within the next 24 hours. How many in 48 hours? More important, how many cannot be answered at all?
…How is that weekend looking so far?

SAP S/4HANA: Three Ways to Make Sourcing and Procurement Strategies More Productive

A significant burden falls on procurement leaders who have to deal with an ever-increasing number of materials, suppliers, and contracts. Real-time insights into supplier spend, evaluations, scores, and contracts can have an immediate impact on their company’s bottom line and competitive position. Yet, many procurement executives are left with legacy technologies that hamper their productivity and diminishes their ability to spot gaps in suppliers’ performance and act immediately.
In sourcing and procurement, SAP S/4HANA can help procurement leaders be more productive by enhancing their ability to manage and optimize operational procurement. Let’s have a deeper look at how S/4HANA is different from classic procurement approaches enabled by pre in-memory enterprise resource planning (ERP) applications running on classical databases. (To find out how SAP S/4HANA is different from pre in-memory solutions in the supply chain line of business check out my previous blog here.)

Instant Material Search

With SAP S/4HANA, you can instantly search for a specific term – such as a supplier, material, or rate – by using a Google-like search field. From there, you can drill down and navigate to various object pages, navigating from supplier object pages to materials pages. This level of insight uncovers suppliers that are delivering the same material and provides alternatives that you can onboard with ease, if needed.  In classical ERP system users had to deal with isolated displays of documents and lacked the ability to execute searches across all documents and master data which sapped their productivity and limited their ability to quickly respond to material shortages.

Supplier Evaluation and Spend Management

SAP S/4HANA brings new real-time insights and advanced analytics to procurement officers. A wide array of real time analytical views are now provided through the Fiori User Experience for Supplier Analytics such as On-time delivery,Price Variance and Quantity Variance, Contract Analytics such as Unused ContractsContract Expiry, and Contract Leakage and Spend Analytics such asNon-Managed SpendPurchasing Spend and Of-Contract Spend to name a few. By running on data in real time without extracting the data into a separate data warehouse, you receive alerts from key performance indicators whenever thresholds are affected. In turn, procurement managers can make instant decisions about which suppliers to choose based on up-to-the-minute information.



Proc.png
















Figure 1- Lab preview of SAP S/4HANA Procurement overview page showing filter cards across suppliers, materials, material groups, purchasing category, purchasing, group, plant, company code

Supplier Collaboration

SAP S/4HANA also benefits from native integration with the Ariba Network. In the past, with SAP ERP running on a classical database, a separate add-on was used to integrate into the Ariba Network. Unfortunately, this made the IT system too complex. Now with SAP S/4HANA, integration with the Ariba Network is prebuilt natively into the solution. Order creation, order change, order confirmation, advanced shipping notification, and invoicing can now be sent directly to the Ariba Network from within the software facilitating supplier collaboration.
This allows procurement officers to create orders in SAP S/4HANA and then send them to their suppliers on the Ariba Network for processing. Suppliers can then confirm orders or let their customers know if items are back-ordered. Suppliers can also notify their customers that items have shipped, and send an invoice for payment. Business rules can help enforce process and document compliance. For example, procurement officers can require that a supplier must confirm an order, create a ship notice, or wait for a goods receipt notice before they can send an invoice. Future functionality is planned such as supporting Variable Supplier Response in case suppliers can’t commit to the full order and Advance Shipping Notification in cases where special handling requirements are needed (e.g. special forklift or storage temperature for the delivered items).



Proc 2.PNG
















Figure 2 – example of a purchase order and invoice automation between SAP S/4HANA cloud edition and the SAP Ariba Network (note the SAP HANA Cloud Integration layer is optional).

The Before and After Picture

For a quick side by side explanation of how SAP S/4HANA can transform your sourcing and procurement processes compared to pre in-memory solutions (and free up your weekend), check out the “before and after” infographic below.



SAP_S&P_Final


This story originally appeared on SAP Business Trends.

HANA to Netweaver Gateway - Connectivity Steps

High Level Step-by-Step Procedure 
  1. Install the SAP HANA DBSL kernel files on the SAP NetWeaver Gateway application server
  2. Install the SAP HANA client on the SAP NetWeaver Gateway application server
  3. Maintain DBCON Table in Gateway System
  4. Create Model Class
  5. Configure a service
  6. Implement a BAdI Class for DB determination
  7. Register a Service and test it


SAP ERP 6.0 to SAP S/4HANA in Four Steps

First Published on SAP News

You can migrate to SAP S/4HANA using the standard migration paths. For those already running SAP ERP 6.0, a system conversion is the correct method.
SAP S/4HANA is the next generation of the SAP Business Suite enterprise software from SAP. Based on the SAP HANA in-memory platform, SAP developers have carefully tailored the solution to meet the needs and challenges of the digital economy. Not only can companies optimize existing processes, but they can now also realize new processes to assert their advantage in the digital competition.

By employing SAP S/4HANA as the digital core of their IT architectures, enterprises can firmly focus on digital processes, where business scenarios are effectively implemented and powerfully marketed. As such, SAP S/4HANA is more than just a successor to SAP Business Suite, it represents a completely new product line.

The migration to SAP S/4HANA is therefore not a one-off project such as an upgrade or database migration. Instead, it involves the entire IT system landscape. Enterprises should always plan the transformation in terms of their optimum future SAP target architecture. This makes life much simpler for users: Thanks to the holistic nature of the transformation, it allows often complex and heterogeneous IT system landscapes to be eliminated (unlike a pure migration to SAP HANA), laying the foundations for simpler, more streamlined processes.

Three Paths to the Destination
As with the SAP Business Suite, enterprises can choose from three possible methods for migrating to SAP S/4HANA: greenfield, system conversion, or landscape transformation. In assessing which path is the right path, the target architecture alluded to above is very important (more on this topic later in the first article of our series “SAP S/4HANA: Chart the Route for Digital Transformation”). Companies that are already running SAP ERP 6.0 (enhancement package 0 and higher) can migrate directly to SAP S/4HANA with a system conversion.

S4HANA_MigrationScenarios
Which path is the right path for my company? A decision matrix illustrates the various paths for migrating to SAP S/4HANA.

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.

Migration via SAP S/4HANA Finance
The migration to SAP S/4HANA can also be performed with an interim step for SAP S/4HANA Finance. The logistical processes have not yet been simplified in this step. In technical terms, this is an add-on that is available as an add-on for enhancement package 7 for version 1503, or an add-on for enhancement package 8 for version 1605. Again, the migration is possible in one step, and the system must be a Unicode system. SAP provides customers with an ABAP report to check the requirements for this type of migration. This report must be run in the local SAP ERP system.

Post by  Andreas Schmitz

SAP Fiori vs SMP [SAP Mobile Platform]

Look at the differences between the two, most focused mobility offerings of SAP, namely SMP and SAP Fiori. The table below will guide you, on which of the two approaches to choose from.


SAP HANA Virtualization Platforms Supported

SAP HANA is supported on bare-metal and virtualized platforms.

VMware --> vSphere

IBM  -------> PowerVM

Hitachi ----> LPAR

Huawei----->FusionSphere

RedHat RHEL ---> KVM Hypervisor

SUSE Linux ------> Enterprise Hypervisor












SAP HANA Supported Hardware Platforms

SAP HANA is available for:
● Intel-Based Hardware Platforms
● IBM Power Systems


Note:
The supported hardware for SAP HANA depends on the deployment method (appliance or TDI).


High Availability for SAP HANA: Cost-optimized scenario

First Published on SUSE Blog 




SAP HANA contains a feature called System Replication: it replicates all data to a secondary SAP HANA system, and the data is then constantly pre-loaded into memory on the secondary system to minimize recovery time objective (RTO). More information on SAP HANA System Replication see here. While System Replication is running, the secondary system, which is configured identically to the primary, is on standby until a takeover takes place. The secondary server can normally not be used for anything else.


How the failover between 2 HANA instances in the cost-optimized scenario is automated leveraging SUSE HA technology is explained in this new Whitepaper.

Whats Covered in this White paper?
1 About This Guide 1
1.1 Introduction 1
Scale-Up vs. Scale-Out 1 • Scale-Up scenarios and resource
agents 2 • The concept of the Cost Optimized Scenario 3 • Customers
Receive Complete Package 4
1.2 Additional Documentation and Resources 5
1.3 Feedback 5
1.4 Documentation Conventions 6

2 Supported Scenarios and Prerequisites 7

3 Scope of this Documentation 9

4 Installing the SAP HANA Databases on both cluster
nodes 11
4.1 SAP HANA Installation 11
4.2 Postinstallation configuration 12
Back Up the Primary Database 12 • HDB System Replication 13 • Reducing
memory resources of the productive SAP HANA system on node2 15 • Implementing
the srTakeover-Hook 16 • Manual SAP HANA takeover
test 19 • Manual re-establish SAP HANA SR to original state 19 • Install
the non-productive SAP HANA database (QAS) 20 • Shutdown all SAP HANA
databases 21

5 Configuration of the Cluster and SAP HANA Database
Integration 22
5.1 Installation 22
iv SAP HANA SR Cost Optimized Scenario
5.2 Basic Cluster Configuration 22
Initial cluster setup using ha-cluster-init 23 • Adapting the Corosync
and sbd Configuration 23 • Cluster configuration on the second
node 27 • Check the Cluster for the first Time 27
5.3 Configure Cluster Properties and Resources 28
Cluster bootstrap and more 28 • STONITH device 28 • Using
IPMI as fencing mechanism 29 • Using other fencing mechanisms
29 • SAPHanaTopology 29 • SAPHana 30 • The virtual IP address
32 • Constraints 32 • Add the cluster resource for the non-productive
SAP HANA database 33 • Adding the cluster rules for the automatic shutdown
of SAP HANA QAS 33

6 Testing the Cluster 35

7 Administration 37
7.1 Do and Don't 37
7.2 Monitoring and Tools 37
HAWK – Cluster Status and more 37 • SAP HANA Studio 38 • Cluster
Command-Line Tools 38 • SAP HANA LandscapeHostConfiguration 39
7.3 Maintenance 40

Updating the OS and Cluster 41 • Updating SAP HANA 41 • Migrating a
HANA primary 42
A Useful Links, Manuals, and SAP Notes 44
A.1 SUSE Best Practices and More 44
A.2 SUSE Product Documentation 44
A.3 SAP Product Documentation 45
A.4 SAP Notes 45

B Examples 47
B.1 Example ha-cluster-init Configuration 47
B.2 Example Cluster Configuration in Format 48
v SAP HANA SR Cost Optimized Scenario
B.3 Example for /etc/corosync/corosync.conf 49
B.4 Example for the IPMI STONITH Method 51




#SPS12 #S4HANA #SLES #HA #HIGHAVAILABILITY 

Why customers are switching from ECC6.0 of the SAP Business Suite to SAP S/4HANA?

Because
  • SAP HANA has a 6x smaller footprint on disk
  • 1.5x-2x smaller footprint in-memory
  • Traditional pre aggregation of transactional data can be completely avoided. 
This has a huge impact on the flexibility of the applications and is one of the primary reasons why customers are switching from ECC6.0 of the SAP Business Suite to SAP S/4HANA.



Additional Advantages
As a byproduct backup/restore runs 5 times faster and systems for development and testing are much smaller.




#S4HANA #ECC60 



SAP HANA Must Be Hurting Oracle

Everybody has seen it: SAP cloud apps run on Oracle instead of SAP HANA, Oracle in-memory works instantaneously while with SAP HANA you have to rewrite the application and by the way Oracle runs twice as fast as SAP HANA.



This comes from a company whose CEO doesn’t remember SAP’s name and has said that this company hasn’t done anything in the last ten years. The ex-CEO claims that they are not monitoring SAP anymore as a competitor … interesting. A competitor whose name you forgot, a company, which hasn’t done anything in the recent past all of a sudden is worth front page ads in the Wall Street Journal? There must be more.

SAP HANA will soon pass 10,000 customers. Many large companies are migrating away from Oracle and putting their enterprise systems on SAP HANA. Do they want to advertise this? Definitely not, why should they? A database switch takes time and you need both suppliers as partners during this process. And here we are with SAP runs on Oracle…..The database replacement process is well under way, but not a day or an hour of services lost are acceptable. The analytical parts of the SAP cloud applications are running on SAP HANA. And the data entry ones will follow, no interruption of the services for the users allowed. Does SAP have to rewrite the apps? No, but Oracle doesn’t allow SAP to cross compile the hundreds of stored procedures and exactly these have to be rewritten. Other than that SAP HANA works nearly in full compatibility.

Can you write different and better algorithms with SAP HANA? Yes, because SAP HANA is so fast and needs only the columnar store in-memory and on disk in contrast to Oracle, where the primary data storage still is the row store and the columnar in-memory store works as an accelerator.

This means SAP HANA has a 6x smaller footprint on disk and 1.5x-2x smaller footprint in-memory and the traditional pre aggregation of transactional data can be completely avoided. This has a huge impact on the flexibility of the applications and is one of the primary reasons why customers are switching from ECC6.0 of the SAP Business Suite to SAP S/4HANA. As a byproduct backup/restore runs 5 times faster and systems for development and testing are much smaller. But perhaps Oracle likes the fact that their own systems or the ones which run on the Oracle database need more hardware to support the larger data footprint. Let’s not forget that Oracle bought Sun Microsystems a few years ago and therefore hardware is still one of its key businesses.

And Oracle wants to reverse exactly this newly acquired flexibility by dropping pre aggregation with the reintroduction of transactionally managed aggregates in the data warehouse. It is the wrong way to address the requirements of the future. Therefore SAP should let them march in that direction. The biggest challenge for enterprise systems in the future lies in their flexibility.

Reporting and analytics cannot be preconfigured and remain unchanged for longer periods of time anymore. To transfer the complexity from database structures to algorithms – using a variety of different hierarchies – is a breath of fresh air into enterprise computing, which today is still based on the management information system ideas of the sixties. Back then we believed all questions management will ever ask can be anticipated and therefore supported by hierarchical aggregations of transactional data, maintained in real time.

It is really flattering when the market leader in database technology pays you so much attention.

That shows how worried they are and how real the threat from SAP HANA already is. A new wave of changes in enterprise computing is happening right now and the early adopters will have a huge advantage in quality of products, customer interaction and service, optimization of processes and financial control. The simplification of the enterprise data models is one key element to become ready for the wave of changes. And while Oracle sees SAP HANA as a threat, our customers understand its potential and have already embarked on major application overhaul projects.

Oracle’s great concept that the application doesn’t have to change when the underlying technology changes, lasted for more than 25 years, but is coming to an end now.



Source:  Blog from Hasso Plattner

Intel’s Haswell Architecture on SAP’s HANA

The development of Intel-based hardware and the adaption by SAP’s HANA continue to improve the applicability of the in-memory technology. The cooperation between the two companies in research and development produces stunning results. Instead of just looking at the raw specifications of the Haswell CPU and it’s application in database servers, I want explain why some of the new features are so important in the HANA case.

First, the overall workload capacity and the performance of HANA depends on the number of cores per socket, the number of sockets per server chassis, the QPI bus speed and the available memory. With Haswell, we can now have a maximum of 144 cores (8×18) on one chassis with up to 12 terabytes of memory. The QPI bus speed, the L1/L2/L3 cache sizes and the very important scan speed of HANA attribute vectors increased by 20% and that has a linear effect on the overall performance of HANA. In several previous blogs we discussed the penalty for spreading data across multiple chassis. This is particularly true for the actual data partitions in an OLTP system. With the new Haswell-based servers we will be able to run all actual data partitions of 99% of all SAP S/4HANA customers on one chassis. The more and more successful compression of data and the intelligent split into actual and historical data, based on business rules, allows for this. A redundant replica of the actual data partition serves as a fast failover system and helps on the other hand to nearly double the workload capacity of the whole system. This is important since I anticipate that more analytical applications (read only) will move to the OLTP system and new applications will anyway have a much more analytical component, increasing the read only workload. The historical data is defined as data which isn’t subject to change any more and new inserts occur only periodically (quarterly, yearly). The database requirements are therefore drastically simplified (no inserts, no updates, no delta management, no back up, massively parallel map & reduce) and a scale out architecture, using cheaper servers, is appropriate.

Second, in SP10 of HANA some of the new features of Haswell are being exploited intensively. As everybody knows one of the great aspects of HANA is that it was designed for in-memory only, using primarily a columnar store with dictionary compression. The attributes of a table are stored as integers with a high compression factor in so-called attribute vectors. HANA still uses a primary key concept, but most data access has shifted from direct access to set operations (accessing a number of rows of a table) and the rows needed are identified via attribute vector scan operations. This is extremely fast (compression, integer operation), completely flexible (every attribute can be used as an index) and there is no need to get a DBA (data base administrator) involved. With the new vector operations in Haswell (AVX2) these scan operations improve significantly (on average close to 50%). Another optimization is the NUMA-aware data distribution and execution. Remember, the fastest access to data still happens when the data is in the memory of the executing CPU. HANA achieves dramatic throughput improvements especially for systems with 8 sockets (greater than 100%).

Third, in S/4HANA we don’t maintain aggregates (totals) any more but calculate them on request on the fly. The “old” predefined aggregates are not so popular any more and the flexibility to aggregate data freely along multiple hierarchies is more important. I know this is against the common practice of the last 50 years in enterprise systems, but it simplifies everything dramatically. The early adopters of S/4HANA all verify this. Since there are no updates of totals anymore, there is no need for database locks (read data for update) and the data entry transactions can now run in parallel with a huge impact on high-volume systems like physical warehouses, order entry systems etc. All what remains are the database inserts, but here HANA has to use an internal lock, when multiple inserts for the same table occur in parallel. Haswell offers now a hardware feature for synchronization (TSX) with which parallel inserts improve up to 5x. I cannot emphasize enough what that means for high-volume transactional systems – it’s a dream.

Internal benchmarks are often of limited value to customers and their real world systems, but when you see a 6x improvement for OLTP processing from an Ivy Bridge system (4 sockets) with HANA SP08 to a Haswell system (4 sockets) with HANA SP10, you can only congratulate the engineers of both companies on the work they have done. I can’t wait to see these systems in production at our customer sites or in the cloud. If there was any question about the viability of in-memory database systems, here is the answer. By the way, the pricing looks very attractive, but I have to leave this to the market.

Source: Hasso Plattner Blog


Tags: HANA , Processor, architecture, CISC, RISC, x86, HASWELL
 
Copyright © 2011. SAP HANA TUTORIALS FREE - S/4 HANA - All Rights Reserved