Using SAP's software as a foundation for Predictive Maintenance practice at the asset-intensive enterprise

[former_member599102]

The intro

The shop-floor of the Asset-Intensive enterprises is a very closed part of the World, especially for the annoying IT and crappy IT-guys. It operated by a heterogeneous community of people, who usually understand each other without words, which helps them to go beyond the language barrier.

As a rule, people of the community hate IT-industry, because IT-guys have no idea about their business, and always want to learn it in 2-3 minutes. Obviously, it is impossible to transfer 25 years of experience in 2 minutes, even of yet another IT-youngster read "The Mom Test" book from Rob Fitzpatrick.

But still, there is a backdoor, that allows us to penetrate the industry with the right IT-tools: SAP.

Once the SAP software is widely adopted by the industries, we have a great chance to run break-through functionality over it.

Today I will speak about predictive maintenance - PdM. PdM is not software, but a maintenance approach, that guides technicians on what and when to do, in order to guarantee production asset uptime with the lowest possible expenditures.

What is PdM

PdM is a practice, organized similar to the Center of Excellence at consulting companies. Let's start with examples:

• Predictive Maintenance practice at BNSF described in the company's sustainability report:

"BNSF is engaged in partnerships with original equipment manufacturers (OEMs) of locomotives that help us determine how often purchased locomotive parts need to be replaced and assist us in predicting when maintenance is needed throughout the asset’s lifecycle. In general, the period between overhauls for the long haul fleet is eight to ten years. Keeping these lifecycles in mind helps us in our predictive maintenance strategy for our fleets."

• Predictive Maintenance practice at Amtrak, described in the company's mechanical services report:

"... this practice is known as Condition-Based Maintenance (CBM). Amtrak Mechanical Services is an industry leader in CBM. Using advanced evidence-based methods developed by the industry’s foremost maintenance personnel, our staff of engineers, technicians, and facilitators is able to eliminate costly and unnecessary maintenance procedures. Working with the OEM vendors, we determine specific component life cycles and work aggressively to ensure components are replaced before they fail. This enables the maintenance program to focus resources on truly essential maintenance tasks..."

Let's conclude - PdM is a practice, that contains:

• People: technicians, inspectors, managers, analysts


• Contracts with OEMs and other suppliers


• Software for monitoring and analytics

We are lucky, all three items managed at existing SAP environments, usually already bought by customers.

The foundational functionality for the PdM from SAP

The software part of the PdM usually built around automatic equipment diagnostics, or so-called prognostics. This software represents itself as a number of algorithms, based on equipment manuals and academic researches of machines' reliability. All the time it looks like the following example:

All the algorithms put to SAP Predictive Maintenance and Service will be never seen by the end-user, who works with the fleet from bird-view:

With single-click drill down to asset-level view:

Those of my customers who have too much equipment, to be tracked by a single operator, just use the Parks-Fleets approach to make an easy-to-use structure inside the SAP's tool. The fewer people coordinate PdM practice - the quicker decisions being made, the more personalized responsibility people have.

For the cases, when software faces something unusual (for example, due to extensive degradation of parts, the equipment quickly becomes significantly different from a data point of view), the analysis functionality takes into the game:

And of course, the quickest way to find a source of any deviations is to check the KPIs/OKRs from the dashboard:

Once we clarified the circumstances we a moving forward to research the equipment, find clues to the problem, develop the solution, put it to validation, and once validated - put it to production and roll-out to cover all similar parts, components, and equipment:

Being analyzed as it should, equipment represents its health index - formal KPI for operability & availability:

Usually, diagnostics and maintenance engineers use these interfaces in one case only - when they are not sure whether the software says really necessary things, like "stop the operation and check bearings urgently!". Of course, it causes losses, and everybody wants to double-check the necessity of.

Of course, SAP has a dashboard, that helps to understand the priority for maintenance:

Very often we face very strange unexplainable deviation in vibrations, output power, and fuel consumption. The map here can not only inform us where the fails going to appear, but also generate the right hypothesis, that we will check with python-code later:

Being consolidated whole the information, and analysts work (I am talking about analysts distributed by various locations, actually) the big picture of the asset serves as actionable intelligence for the dispatcher, who now becomes operator and diagnosticians at the same time (communications reduced by 100 times):

In order to quickly check for the nearest our actions (to keep the equipment availability high) we are, once in the role of the dispatcher) drilling down:

Being a dispatcher we do not need deep maths and machine learning knowledge, as well as coding experience. But skills to understand the degradation graphs are essential nowadays:

And moreover, in the role of dispatcher we have to be ready to understand the errors, coming for numerous types of equipment in order to fit the role's requirements:

Once something goes wrong (or going to start to), we are checking for the spare-parts:

But in most cases, the software checks for available spare-parts by all locations automatically and creates a new work-orders from the lists of standard jobs (either OEM's manuals or internal maintenance documents):

The instruction could look like the following or in any other view:

But all this manual will not help if we do not have relevant educations, pieces of training and knowledge to understand them. So, there still a number of particular situations when human beings still should be used - as a rule, in remote control rooms, which could cover whole the global business of giants like Saudi Aramco or GE manufacturing.

At the end of the day

Once the existing SAP landscape already mature enough and penetrated the markets successfully, the only challenge the world have are software on top of SAP, that could do continuous diagnostics 24/7, which have the answers to the following questions:

1. What, when, and why will fail?


2. Could the maintenance be postponed? If yes, how much additional costs will be generated?


3. Could the CAPEX be postponed due to the prolongation of the equipment lifespan?


4. What skills are needed to fix the issue?


5. What spare-parts are needed? What absent items could be substituted?


6. What spare-parts should I buy in advance? To what warehouse should I deliver it?


7. What MRO risks do I have? Who to evaluate them in $?

The software on top of SAP, I am talking about, is failure prediction models. That is exactly the enabler of autonomous operations for those companies who moved to SAP completely.