Logistics: Würth Establishes Transit Warehouse

At its European hub, Würth is consolidating its flows of goods from suppliers and its own internal production to its international subsidiaries.

This global specialist in assembly and fastening materials is also planning to send its packages out to end customers through a series of 10 shipping points – all with the help of the transit warehouse function of SAP Extended Warehouse Management (SAP EWM).

The southwest German town of Gaisbach features more than just the headquarters of Adolf Würth GmbH & Co. KG. Here, halfway between Stuttgart and Würzburg, the company also operates its main load transfer point. Well over 40,000 packages roll out onto Reinhold-Würth-Straße every day – that’s more than 10 million each year. Some 1,400 suppliers also send their wares here before they are shipped on to Würth’s international subsidiaries and end customers along with the company’s own products.

Adolf Würth GmbH & Co. KG, or simply AW KG, is the parent company of the global Würth Group, which employs over 74,000 people and generated €12.7 billion in revenues in 2017 (based on its preliminary year-end closing). To further optimize its flows of goods, AW KG recently began focusing on its European hub and its plans to implement a new approach to hub and loading management. In cooperation with the new internal service provider Würth Logistics, the European hub is tasked with serving as a central consolidation point for goods flows from suppliers and AW KG itself to the Würth group’s subsidiaries elsewhere in Europe.

The objective of the new hub and loading setup will be to coordinate the 10 shipping points on the AW KG premises and create overarching plans for the group’s end-customer business.

Optimizing Procurement for 35 International Subsidiaries and Counting

Today, when Würth Logistics plans a truckload for the group’s Italian subsidiary, the load is created and shipped out in the space of a day. Most trucks leave the grounds with a full load as well. In the past, the fact that the pallets coming from AW KG were often not enough for full truckloads presented a dilemma. The external logistics providers commissioned to handle these shipments thus resorted to taking on additional orders to fill out their trucks. The drawback was that these trucks had to stop on the way to their destinations to pick up new goods and transfer their loads at their own hubs. A group logistics study Würth conducted then revealed significant potential to reduce both costs and the flows of incoming goods while improving its unloading processes.

Würth Logistics: Taking Control to Ensure Full Loads

Since then, Würth Logistics has replaced the group’s external logistics providers and set its sights on ensuring that as many trucks as possible leave Gaisbach with full loads in tow. This is now possible because Würth Logistics has begun factoring in goods from suppliers in Germany along with the “base load” of shipments it handles from AW KG. Besides making better use of truck capacity and eliminating the need for stopovers, this enables Würth Logistics to align loads with the trucks’ axle weight limits and establish the order in which goods are to be unloaded in advance.

“When trucks are bound for an international Würth subsidiary, we now only have to load them once,” reports Jörg Hollstein from Würth IT. “In terms of quality, that’s a quantum leap for us.”

Four months after an initial handful of suppliers and select subsidiaries were connected to Würth’s European hub, their numbers have grown to 1,400 and 35, respectively. This corresponds to 80 percent of the group’s flows of goods in Europe, which is the highest level of efficiency currently attainable.

“We just don’t have the space for further optimizations right now,” Hollstein admits. “On the other hand, you’re probably going to see Würth establish similar hubs for the Asian and U.S. markets.”

SAP EWM 9.3 Provides Technology for Transit Warehouse

The key technology enabling Würth to speed its suppliers’ goods through its facilities is a new warehouse management function that has been available since the release of 9.3. version of SAP Extended Warehouse Management.

“The application can manage packages even when it doesn’t know what they contain,” explains SAP consultant Christine Bossert, pointing out a key characteristic of the technology that is geared in particular toward transportation providers. Incoming packages are marked with a number, the intended recipient, and an address, which meets one of the main requirements of a transit warehouse. Since the pallets are loaded straight back onto trucks whenever possible, goods receipts and issues are not even posted.

“We’d been maintaining something resembling a transit warehouse based on our existing systems, but weren’t happy with it,” Hollstein recalls. “In SAP Extended Warehouse Management, we’ve now got an application that offers transit functionality right out of the box.”

Loading Hub Serving End Customers in the Age of Amazon

While Würth’s European hub is concentrating on optimizing procurement flows for its international subsidiaries, its loading hub is consolidating flows of goods for its end-customer business in a single location – AW KG’s facilities in Gaisbach. Here, the typical order — from a small trade business, for instance — involves one or two packages containing just a few different items.

“Regardless of how many packages we have to process, every customer expects theirs to arrive on schedule and contain everything they ordered,” Hollstein points out. “The number of packages that need to be shipped out the very next business day has also increased significantly.”

At the moment, many different warehouse management systems are in use at AW KG’s shipping points, and trucks have to stop at several of them to pick up packages. This is why the company has now turned its attention to gradually harmonizing its system landscape. The first step is to involve controlling goods flows across 10 shipping points, with the first set to go live in the first quarter of 2018.

Centralizing Package Management at a Transit Warehouse

The transit warehouse function in SAP EWM is designed to receive information on packages that are ready to ship and manage them centrally, which means trucks from transportation companies only have to stop at a single loading point to pick up packages from all 10 shipping points. This frees up time that can be used to optimizing picking.

Saving Time for Picking

Let’s say a package needs to be delivered to the Ruhr region of northwest Germany. GLS, DPD, and other shipping companies pick up the packages at seven in the evening and take them to collection centers. From there, they are allocated to regional distribution centers. After being resorted, the packages are loaded onto delivery vehicles the following morning and brought to their recipients over the course of the day. Thanks to SAP’s new application, trucks can pull away from the loading ramp as late as 9:00 p.m.

“Besides enabling us to take some pressure off our pickers, this is making us a lot more flexible because we’re no longer constrained by grid traffic,” adds Hollstein, who is particularly pleased with the later last-order times Würth has introduced.

In the age of Amazon, speed is of the essence – and even those in small trades have long since grown used to receiving their packages the very next day. http://bit.ly/2FnR59l #SAP #SAPCloud #AI

Enterprise applications with optimized costs – SAP HANA-based systems on Hetzner Online

In this article I would like to share my experience  of building our company SAP infrastructure and hardware costs optimization that we  have managed to achieve. Currently we have over 20 internal sap systems in our internal  landscape, including about 15 HANA-based installations. We use a combined approach with Hetzner Online and Amazon web services, and our average monthly expenses  for hardware rental are about EUR 1,000.  In fact, this is not a productive landscape, so most of those tricks  will not work once you have mission-critical systems. However, in many production  scenarios serious costs saving can be achieved, and this is what I am going to describe below.

For a long time enterprise applications  have been associated with expensive (and complicated in maintenance) hardware, mainframes,  committed technical teams and so on. For the last  few years  the role of cloud solutions has increased, where a customer either only rents equipment  (i.e. virtual servers), or complete application service. However, the main feature of cloud – elastic resource allocation  resulting in costs saving  –  is not required with many scenarios typical for small- and mid-size sap installations.

The most popular idea is to optimize costs  thanks to elastic capacity – disable non-required servers, change resource allocation (i.e. memory and CPU). Those make sense in case  you have scale-out environment (i.e. multiple application servers). However, for most cases (except BW) you will have a single “large” HANA instance that requires one solid (and expensive) instance. Once you decide to install SAP – in many cases you do not have  to dynamically resize or start/stop it on request – you just need to have it up and running, and probably you would like to have an option to increase hardware resources in case  your system load grows. So, it looks like a regular  server rental, the only difference is that those servers are located in cloud.

For example, a cloud instance with 256Gb RAM will cost about EUR 1,200-1,700  monthly, depending on the specific cloud provider, geo location and so on.  Even  if we decide to use a 8×5 schedule, in a very optimistic scenario (without taking into  consideration necessary time for updates, long-time background jobs usually scheduled for night time or weekends) we still get about 400-500 EUR monthly.

Those costs might be acceptable (and even more than acceptable) once you are running a mission-critical  production system. However, it is quite expensive  if you are running a set of internal systems (in case if you are a sap partner), or you simply do not need  all features  offered by “big” cloud providers, and/or 2-4 hours’ system downtime is not a critical risk for your business ( which is usually the case with small and medium companies). Frankly  speaking, you  do not need 99.9999% availability of sap,  unless you have the same provisions for internet connection or electrical power in your location.  Based on my experience, I can say that it might make sense to  consider direct server rental instead of virtualized environments.

In our company we started using Hetzner Online  at the beginning of 2014 – as a cheap option to keep non-production  systems for internal needs.   Since 2016 we have been using  it for non-production  purposes together with HANA,  as for those purposes it is a nice and   quite a cheap option.

Now our internal landscape is based on Hetzner Online PX121-SSD servers with single Xeon E5-1650 v3 hexa-core and 256Gb RAM. For sure this is not a certified platform for HANA,  but  for the 2 years of usage we have never faced any hardware-related issues.  We typically run 2-3 systems on one host, including IDES versions with demo data inside. Indeed,  these are low-loaded systems, without a significant number of users logged in, and such a landscape  cannot be suggested for any production  usage.

Non-productive hosting

PX121 SSD: 256 GB Gb RAM, Intel® Xeon® E5-1650 v3 Hexa-Core
117 EUR/month

As  to production  landscape provided to clients – we use DX291 – Dell PowerEdge R730 with dual Xeon E5-2620 v4 octa-core and up to 768Gb RAM.  This one is officially supported by SAP and listed in HANA certified hardware directory. From the pricing perspective, we get instance with 256Gb RAM for 350 EUR per month, or in “maximum ” configuration –  756Gb RAM for approx. 900 EUR per month.

Let me sum up “ net” hardware costs for productive hosting:

Hosting option
Approximate  monthly price

256 Gb RAM
512 Gb RAM
756 Gb RAM

Cloud hosting 24×7
1200-1700 EUR
2500-3000 EUR
5000-5500 EUR

Cloud hosting 8×5
400-500 EUR
700-900 EUR
1400-1700 EUR

Hetzner Online – Dell Power Edge R730
350 EUR
600 EUR
900 EUR

From the technical point of view the whole production  landscape will look like this:

This solution is aligned with enterprise-level requirements. However, there is no way to measure how stable a single server is  – this is nothing without backup solution. After trying several various options we finally decided to use Amazon S3 as external backup storage. All database backups are transferred to S3; as well as redo logs are stored  in it. So, this allows keeping data for point-in-time recovery outside Hetzner Online data center and allows fast restore in case of failure.

As an additional protection option, we use reserve instance on Amazon EC2. The main idea is, that normally on SAP system only database can change, and quite rarely files on the  file system. So once a server is set up on Amazon EC2 as a copy of some production  system, it might be easily actualized via database restore.

The diagram of such protection (disaster-recovery) process will show as follows:

In such a way we have primary instance on Hetzner Online, and additional copy of it on AWS, switched-off most time, and  hardly requiring any additional payments. However, in case of failure of “primary” Hetzner Online instance, it can be easily started , updated with latest backup and redo logs, and continue production  operations. This approach allows  using  a cheaper hardware hosting option, and  at the same time keeping unplanned downtime  within 4-8 hours’ slot  in the worst case. To keep access to a system transparent for the end user, access to such a system can be organized via additional load balancing instance as  shown in the schema below:

In conclusion I would like to say that  nowadays it is possible to keep quite complicated internal landscape and take advantage of modern in-memory computing technologies without any huge investments into internal hardware infrastructure or expensive enterprise-level cloud solution.  Many scenarios   will allow using less expensive hosting options; in combination  with modern cloud services even production environment can be kept in such a way.

P.S.  Should you have any questions or inquiries,  please do not hesitate to contact me and my colleagues via our company official web site.

  http://bit.ly/2DeCUgy #SAP #SAPCloud #AI

Community Spotlight: What is it actually like using SAP Build?

If you have been following along with my blogs about SAP Build, you have heard from me about why I love the product, the Product Managers on some of the latest and greatest features, and now it is time to hear from someone who actually uses BUILD in their day to day work.

I reached out to a community member who works with BUILD in their day work. Not an SAP employee, but someone from our vast ecosystem of developers. I wanted to get the outsiders perspective on SAP tooling.

So thank you to Rajen Patel for answering my questions about how he and his team work with SAP Build!

Q: With all the available design and prototyping tools available, why did you choose SAP Build?

A: Our main reason for choosing SAP Build is that it’s being promoted by SAP as a prototyping tool for developing Fiori compliant UI5 apps. We wanted to go to the source. The BUILD team at SAP did an amazing job at developing this easy to use prototyping tool. The OpenSAP course for Build was great way to learn basic functionality.

SAP Build provides integration with SAP Web IDE, so that helps us to jump start development. Whatever we developed in the prototyping phase is not throwaway work. All screen elements and UI designs can be imported directly into the SAP Web IDE and save development time. One last key feature we liked was availability of ‘Fiori compliant’ controls. It goes without saying that ability to design adaptive screen is big bonus i.e. Design one prototype that can fit all three major screen sizes: desktop, tablet and phone.

Q: Are there any features in BUILD that you have found to be very helpful? Is so, what and why?

A: SAP Build has almost all the features we needed for prototyping. Some were more useful than other in our case. Here I have listed few useful features for our last prototype.

* Screen building using ‘drag and drop’ functionality was great in creating forms (that’s bulk of our prototype)
* Data modeling tool was very helpful in creating data to mimic real life scenarios. This allowed us to make the prototype very personal for our end-user community
* Get feedback: This allowed users to test new business process ‘hands on’. We were able to view user’s interaction with the screen using the heatmap functionality and screen flow that users followed.

Q: What is your use case for BUILD?

A: We used SAP ECC scenario for building maintenance and repair functionality. Our prototype included worklist, forms (transactions), and reports.

Q: How do you (and your team) utilize it?

A: This was the first time in my career I was able to create an interactive prototype. Most of the analysts like to design screens for end-users, and BUILD allowed our inner designers to go wild. Okay not wild, but at least it brought out our creativity that can be channeled through the standard UI5 framework and the team can collaborate in meaningful way. We created a project and shared it amongst our team. Personas were defined with the key information for each user group. This helped helps us to create empathy for end-users in our project team. This also provided focal for any discussion i.e. How a user will react to this feature?

We collaborated using various collaboration features such as comments and feedback. We used the project to conduct various demos as well.

Q: Is there a feature missing from BUILD that you wish was available?

A: Yes, few extra features that could have helped us. For example: End user should be able to provide feedback without creating ‘BUILD login’ – that would have been great. One more user ID and password reduces user engagement.

From development perspective, we could have used few more ‘Fiori Launchpad’ elements like Fiori screen header. Going forward we will need to create more complex forms for desktop application. Current form design is difficult to work with when one needs to create forms with 30-40 fields. (Yes, 30/40 fields to map really complex business scenario)

Q: Would you recommend for other developers to try/use BUILD? If so, why?

A: Yes. If one is developing a prototype for SAP products then SAP Build will provide a great value. SAP Build provides all three element of high fidelity prototypes such as 1) Screen (UI) 2) Realistic data and 3) Process flow.

You can’t go wrong with Build to develop Fiori compliant UI5 screens. It’s easy to use and provide lots of values for your efforts. http://bit.ly/2FmErHm #SAP #SAPCloud #AI

Logging Spring REST APIs

In this article, I will try to explain an approach for logging Spring-based Rest APIs. Although Spring provides tracing of request and responses using its Actuator, logging the request and response body is not supported out of the box. This sometimes makes it difficult to find what is coming to and going from the Rest APIs.

There are several approaches for writing a logger for Spring applications. One of them is writing a listener. But when you write a listener, it starts to work for all the APIs. In this demonstration, we will focus on logging only the APIs that we annotate with our own logging annotation.  https://goo.gl/yoa8A1 #DataIntegration #ML