Predictive Asset Management – getting from where you are to where you want to be.
Historically preventative and scheduled asset management has used the general case, based only on a limited number of criteria, to define replacement and maintenance schedules. This means that an asset of a certain type usually gets a fixed, standard maintenance interval such as every 6 months, every 10000 km and so on. And usually this is based solely on obvious characteristics such as machine type. When investigating individual assets this then leads to one of two types of inefficiencies: either we intervene too early and incur unnecessary costs or too late which results in unplanned equipment failure.
We’ve always known that planned maintenance is better than unplanned. One of the key metrics in managing a good maintenance organisation is the ratio of planned to unplanned maintenance. To help maintenance practitioners focus and improve this area many tools have been developed over the years. These include Reliability Centered Maintenance (RCM) tools that have been used to document and record accepted performance and to manage failure to meet this performance requirement. But behind those activities I’ve always thought we could do better. On individual assets are we sure we’re not maintaining too early, could we have been more proactive to prevent a failure? Are we analysing enough data to make the right decision, backed-up by robust statistical analysis?
In projects that Deloitte has done recently it turns out that we can do better. In fact, just looking at cost savings, customers are realising reductions in both operating and capital costs. We can do better because of advances in the tools and methods used to understand data and tools to query, visualise and analyse data better. With these tools we can now analyse the performance of all individual assets within an organisation and with clear statistically valid confidence levels estimate the life of the asset.
So how does an organisation go about moving to a predictive asset management regime? There are 5 steps:
- Collect, integrate and validate data (ERP, GIS, SCADA, publicly available info)
- Analyse cause and effect relations
- Refine predictive models and predict probability of failure
- Visualise outcome of the analysis
- Act on insight and update individual asset maintenance plans
During recent project work we’ve seen – and this is not surprising – that organisations have various levels of readiness to perform predictive asset management. A clear view of the benefits that can be realised from predictive asset management helps define current gaps and frames a roadmap to reduce both risk and cost.
In 2011 SAP bought a New Zealand company called Right Hemisphere. Right Hemisphere’s claim to fame was the ability to generate 3D graphics that were rich, deep and full of meaning with really small files. Their viewer was embedded in the Adobe reader. So CAD packages have been able to render 3D images for a long time but Right Hemisphere, through clever use of vector graphics, were able reduce these to a size that were globally accessible (think Cloud and mobile) and still maintain information to enable querying (think visual reporting) and manipulation of the files (and here you need to think of 3D works instructions).
An example of VE visualisation
Where SAP ERP uses CAD drawings (or for that matter any documents created in another package, including Word, Excel etc) it has always been necessary to ensure that the correct (most recent, approved) document is presented when executing the SAP ERP transaction. This could be for works instructions on a work order, technical drawings on a piece of equipment or a 3D parts catalogue. To achieve this various options to convert the document have been implemented. The most common is to use a pdf conversion engine to convert the document once it has been approved to a pdf documents with watermarks, including version numbers, approved by, etc. SAP DMS is a great solution within the SAP Business Suite that can be used for the management of ALL documents especially when the document is linked to SAP ERP objects. SAP DMS contains metadata, controls the revisions and versions, manages redlining and has a comprehensive workflow engine for approvals and escalations. But it does need to be set-up and configured correctly. And as the VE / DMS admin guide mentions “Some customizing steps are performed in DMS as this is the triggering point for conversion.” This configuration is part of a standard DMS implementation.
SAP Visual Enterprise Foundation Integrated Product Stack with CAD Package and Content Server (image from SAP)
As of Enhancement Pack 4 there is native SAP Document Management System functionality to convert the original CAD file to a Visual Enterprise (.RH) and then if needed the RH file to a pdf document. And so what does this mean? It means, at least, that there is now a standard SAP solution to link 3D CAD drawings to business objects and present these in a controlled way.
The real value of this software will be in linking it to business transactions in SAP. Give us a call if your company could benefit from this and are ready to explore opportunities – we’re ready to run.
Some features of the SAP PPM IT RDS
And just to translate: that’s SAP’s Portfolio and Project Management (PPM) IT Rapid Deployment Solution (RDS). In the PPM space the RDS comes in two ‘flavours’: PPM for Capital Management and PPM for IT Management. Let’s run through what’s in the PPM for IT Management RDS and discuss some of the cases in which it would be used.
- The IT Management RDS covers both portfolio AND project management functions.
- The portfolio part of PPM for IT management is used to create strategic financial, capacity and resource management budgets.
- Metrics, which are used to track the success of the project, can be captured against the portfolio items.
- Project Management is used for day-to-day operational project management. The creation, against templates if needed, of phases, task and checklists is done for the project.
- The Project is used for role and resource management. The roles and resource can be planned against tasks and available, qualified individuals.
- PPM for IT can back-end into SAP PS WBS elements but often easier , and just as useful, to link to an internal order as the ERP financial object.
An example of the resource management capabilities in SAP PPM for IT
An example of a Gantt chart of an IT project in PPM
There are a few features to look for in an organisation which will indicate whether or not SAP PPM IT is a good fit for the IT department. And, briefly, these are:
- The organisation has a PMO which is a ‘central’ team for the management of projects.
- The organisation is planning to, or is currently, using a solution in this space such as CA’s Clarity, HP PPM, MS EPM and/or MS Project – and would like to replace this with an SAP solution.
- There is a need for IT projects to be integrated with the SAP ERP system for the tracking of actual time and costs.
- SAP ERP has been or is currently being implemented. Stand-alone SAP PPM is possible but the real value comes from integrating to the operational system. (And it is possible to use PPM to consolidate a portfolio that has multiple ERP operational system)
And lastly, a brief word about the RDS part. The PPM for IT solution can be implemented within 13 weeks on a fixed price, fixed scope. I think it’s an important solution in SAP’s portfolio and can be used to reduce an IT organisation’s, often disconnected, project management systems footprint.
Some people may (and often do) argue that from a project management point of view the capex/opex split is not important; it’s the project manager’s job to deliver the project on time and within budget irrespective of whether or not its capex or opex. While this is true it is also very helpful for the portfolio manager to be able to check variances in capex AND opex budget vs. actual. Particularly in the regulated utility industries where capex adds to the asset base and is a key reporting requirement to the regulator and opex is expensed and has a direct impact on shareholder profitability. When balancing the selection of projects for a portfolio it would be necessary to ensure that the appropriate capex and opex spend is incurred and that the correct projects are delivered.
Within core SAP ERP it has traditionally been awkward to split capex and opex at the cost element level. What I mean by this is that the cost element can in some cases, but does not generally, represent capex or opex. So when consuming material, buying from 3rd parties or using internal labour the cost element that hits the cost object (order, network, etc.) doesn’t indicate if the spend is capex or opex. It’s only on settlement that the cost is ‘marked’ as capex or opex based on the receiving object. Cost centres (or other non-asset receivers) are opex and those settled to an asset (or an asset under construction) are capex receivers. What some organisations do to assist in identifying capex or opex before settlement is to create either project types in PS or order types in PM to indicate whether the expense is a capital or operational cost.
Now SAP PS is being used to collect actual costs and settled to either capital cost receivers (assets or assets-under-construction) or operational cost receivers (cost centres) and the question is: can SAP PPM be used to provide a portfolio wide view of both capex and opex. The answer is yes, but it’s tricky because the financial planning is shown by a combination of view/category/group and when feeding PPM with the costs from SAP PS the costs are characterised by, amongst other things, cost element, cost element type, version, value type, controlling area and date. None of the characteristics specifically allow us to mark the cost as capex or opex and hence on the portfolio item we cannot report by capex or opex. Although, from a portfolio management view, this is the requirement.
How did we do the ‘split’? Well before the project cost IDoc was sent to the PPM system the cost needed to be ‘marked’ as either capex or opex by manipulating one of the standard fields. The BAPI was used to change the contents of the IDoc based on the project type that the cost was incurred on, which was either of capex or opex type.
So with the correct configuration of the view/category/group structure in PPM5.0, a small enhancement on a standard BAPI to update the generated IDoc with a capex/opex indicator for all the costs and running the standard extract and roll-up programs, like magic, the capex/opex split will appear in the correct place within the portfolio item financial reporting. And one last point. This split is needed when costs come from SAP ERP (or another ERP system) but for top-down budget distribution the split is done within PPM in the correct capex or opex group.
Over the last year or so SAP has released a number of Rapid Deployment Solutions. What are these things? Well they are a way to make it easier to consume SAP software. SAP have realised that having the best business software in the world* is no good if the software is not used. SAP has a long history of providing tools (usually as part of the software sale) to help customers consume their software. Look at the evolution of ASAP, Focus ASAP, Solution Manager, Best Practices and now the RDS. It’s part of the evolutionary process of making the implementation of business software less risky, quicker and cheaper.
All these methodologies are enablers that help get the job of software implementation done. None of them come wrapped as a silver bullet; none of them is the ultimate panacea for a business problem. This, obviously, is the SAP markeing message and most of the information on the RDS encourages this view*. In our expericnce we’ve found that the reality is a little more complex. Nonetheless what the RDS does is to provide a fixed price, fixed scope implementation of a solution. In my discussions with SAP customers I’ve used the analogy of building your own designed house but getting the kitchen delivered as a fixed price, fixed scope kit. You’ll need more than the kitchen to live in the house but buying it as a kit will certainly make the construction of the entire house quicker and cheaper. When buying SAP customers hope to address a business problem. Let’s use an example the capital planning process. A customer needs improve their capital planning, management and governance processes (they need to build the house). To implement an enterprise wide consolidated view of the capital management process a number of things need to be done. The SAP PPM solution needs to be installed and configured, but there are also requirements to do business process mapping, training, change management, ‘non-standard’ developments, reporting enhancements, etc. At the moment the PPM for Portfolio Management RDS is the best (lowest risk, cheapest, quickest) way to get the SAP technology up and running for the majority of the capital planning and monitoring business requirements – but the rest of the implementation still needs to be done. The implemented PPM RDS is then used as the basis for ensuring that the business has a clear understanding of what the tool can offer and is the foundation for focused, useful improvements and enhancements of the implemented core.
What’s behind the RDS? There’s a standard START, DEPLOY, RUN methodology, a definition of what gets delivered, a detailed WBS with required roles and effort from each role, templates for training, testing, acceptance and some other accelerators.
So if you have a business need that can be met by one of these RDSs consider the following:
• Does the RDS substantially meet my needs?
• How can the RDS reduce the time and cost of achieving my business requirements?
• How can the RDS be slotted into the organisations IT implementation methodology (ASAP, Agile, etc)?
Given that you have business objectives to meet, and a budget in which to deliver, using the RDS can strengthen your business case and certainly provide a better solution than implementing without using the RDS.
*In my humble opinion
Almost 10 years ago I was involved in a start-up that used mobile devices to record inspection results at an oil refinery. The business benefits were indisputable: by scanning a bar-code we could record the time the technician was at the equipment, work could be given to the technician without him having to come back to the workshop and results would only need to be entered once and would be available for analysis immediately. But then, and until about a year ago, it was a struggle to get better traction for mobile. Why? Because even occasional connectivity did not exist in some places, devices weren’t cheap and robust enough and the synchronisation technology was slow and unreliable. This is all changing. SAP has moved into the on-device space fairly aggressively over the last year. There has been the acquisition of Sybase, a co-innovation agreement with Syclo and a closer relationship with Clicksoftware (particularly relevant here is the ClickMobile component). The broad uptake of Apple’s iPad and the resultant easy access to just about any information from a mobile device has changed the expectations of ERP users. In response SAP has a wider deployment of Apple’s products internally and is now able to show a number of business transactions and reporting solutions on Apple devices. But during this time SAP has also backed away from its Mobile Asset Management (MAM) solutions – announcing that while the currently available software can still be used, it won’t be developed in the future. What does all of this mean for SAP Enterprise Asset Management (EAM) customers and what options are currently available from SAP to mobilise a maintenance workforce? If I’m running SAP EAM how do I push information to my workforce and enable them to execute transactions?
Will your workforce always be connected? Will they be entering a very limited amount of information while they are off-line? If you’re always connected the mobile device is, in effect, no different to a wirelessly connected laptop. The design issues then focus only on small screen usability, presenting a screen to a user which is easy to navigate and can accommodate all information needed to support the process. For EAM mobility this is technically the easiest case. For these types of mobile transactions it makes most sense to design your screen for the appropriate device and ‘send’ the information to SAP using a webservice (of which there are enough to support just about all EAM transactions). Development of these ‘on-line’ types of applications can be done with the relevent development kit. Here is an example of this for an Android device. The diagram below shows the key components needed for mobile applications. I’ve shown the ‘connected’ and ‘disconnected’ devices as separate, although the same device could be used for both,’disconnected’ applications would need the MEAP to manage the data flow.
Components needed to support mobile EAM applications.
What happens when your workforce is not connected? Despite an increase in network coverage there are still many cases where full off-line EAM functionality is needed. There is the obvious case for remote sites, but think also of the Telco technician who’s off-line because the tower he is working on is the one that would usually provide him with connectivity. In these cases the technician will need to access large amounts of SAP information while off-line. He might need to look at historical jobs done on the piece of equipment, search for materials needed to repair the equipment and read related documents and operating procedures, all while off-line. He might also want to complete a job with the right failure codes for that equipment and maybe even create another work order to perform work on a related piece of equipment. All of this needs to be done off-line. To be able to do this a considerable amount of thought needs to go into the synchronisation of the data between the handheld device and the ERP back-end. In the first instance only the appropriate data must go to each of the handhelds – each technician should only be able to see their equipment and their work orders. Once ‘sent’ to the handheld orders (and for that matter any changeable data) should be locked so that there is no conflict on subsequent synchronisation. It should be possible to manage the application on the handheld, to remotely delete data, to resend information if a device is damaged and a range of other ‘management’ functions. It is for these situations that a robust middleware (or Mobile Enterprise Application Platform, MEAP) is needed. There are a few SAP options for full off-line EAM functionality.
- ClickMobile is most appropriate if using ClickSchedule Workforce Scheduling and Optimisation for SAP (WS&O) for schedule optimisation. ClickMobile can be used to deliver all the standard EAM use cases. They also recently announced that they will partner with Sybase to deliver mobile functionality.
- Syclo delivers all the standard EAM use-cases and will provide an EAM solution with many references within short implementation timeframes.
- Sybase is the best longer term strategic choice for a MEAP, there are currently no standard EAM applications available (Sybase does however provide the tools to develop these). I suspect it won’t be too long (6 to 8 months) before standard EAM applications get delivered.
- SAP Mobile Asset Management (using NetWeaver Mobile Infrastructure middleware) is dated and doesn’t appear to be a long-term mobile strategy.
So, as you embark on mobilising your EAM workforce, consider the transactions that you need your workforce to perform. If they are always connected or are performing low-complexity transactions consider building an input screen for the handheld device and submitting these to SAP with one of the standard webservices. If your workforce operates in an ‘occasionally connected’ mode and needs full EAM functionality then consider either Syclo or ClickMobile (with pre-built EAM use cases) or Sybase as a MEAP (and build your own EAM applications).
This article is based on a presentation I did at the Mastering SAP PM conference last year. The organisers of the conference have a rigorous process of SAP user based input to the agenda. And guess what? Yes rotables are a perennial favourite and are back as a proposed agenda topic for this year’s conference. Not too surprising I suppose, considering that rotables make up a large value of the spare parts in many industries. They are also usually items critical to your operations and necessary to guarantee acceptable up-time. But why does the topic keep popping up and why, as an industry, are we not taking advantage of improvements in technology to better control rotables. If you’re reading this and are struggling to define how to improve your rotables process here are some ideas on where to look to identify improvements. Okay, to start you should look at your rotables process from three angles: usability, functionality and visibility. Why? Because if any one of these areas is not up to scratch the entire process will fall over. For usability the questions you need to ask are who is actually using the system, who (and when) does a rotable get received into the workshop? What does that person have to do to make sure that sufficient information is recorded? Go and have a look at the process – as it is actually occurring and jot down the information that needs to be recorded. I suspect that you’ll find that it’s not very much information – it’s getting it into the system timeously and accurately that’s the difficult part. Okay now select the easiest way for the user to enter this into the system. Depending on the volume of transactions I’d build an Adobe Interactive form or consider using a digital pen which will record the transaction directly in SAP or other ERP system. What you don’t want to do is to get the user (or someone else who’s been given a scrappy piece of paper) to log onto a system and work through the transaction.
This is the form I’d convert to an interactive form or digital pen for direct entry into SAP. Taken from here
Now that we’ve made it easy to capture the item and movement what functionality do we need to deliver to support the back-end processing? Remember building out this functionality only makes sense if we have very high process compliance and the recording of all movements. There are 3 groups of users who take an interest in rotables and who need specific functionality to meet requirements.
The Maintenance or Reliability Engineer, who needs to know what items to maintain the plant with, why they fail, what it costs to fix them and how the operations of the plant can be improved with this knowledge. This information will mostly be captured on the repair work order, the work order that is created to manage the ‘change-out’ of the rotable item. This order will link to failure codes, damage codes, MTBF, etc. and allow for analysis of reliability data.
Stores need to have visibility of all rotable items wherever they are, in stores, in operation or at sub-contractors for repairs. This visibility is only possible if the recording of movements is enforced. Once the process is enforced, and made easy to use the location of each rotable is updated at time of movement and it becomes easy to report on.
A diagram showing the process, specifically the requirement for a repair and a refurbishment order and where ‘split’ valuation of the same item is used.
And finally the accountants need to know what the value of rotable stock is, whether or not the stock is capitalised and depreciated and what is expensed on consumption. This is often the most contentious area and also the area where we see the most amount of debate without decisions being made. Now read through this and make those decisions.
Firstly, will I use moving average cost or will I use standard cost (SAP addresses both options). Often, during workshops on this, the cost accounts are asked what the company policy is on this and that is then taken as the standard. The decision has slightly deeper consequences – fundamentally the choice will drive who’s responsible for the cost of repair. If the same person managing the material is responsible for ensuring that the rotables are repaired to budget then moving average cost needs to be selected as the efficiency of the repair process will be reflected in the cost of the repaired item. If the maintenance engineer (or some other 3rd party) is responsible for the costs of repair then standard cost is to be selected. With standard cost under- or over recoveries will be sent to a ‘price variance’ account which can then be managed by the responsible owner. While it is probably best practice to keep to a single cost method SAP derives this from the material number so both standard and moving average can, if needed, be used across the organisations.
Secondly, with either standard or moving average methods, what should the actual dollar value be of the ‘new’, ‘repaired’ and ‘to-be-repaired’ valuation? The ‘new’ value is pretty easy; it’s whatever you pay your supplier for the item. To determine the ‘repaired’ value you need to look at the specification of what a repaired rotable needs to deliver – are the items repaired to good-as-new standard? If so then the value should be close to the value of a new item. For ‘to-be-repaired’ items the decisions is slightly more difficult since the cost to repair is based on what caused the failure and hence hoe badly damaged the item is. Generally, and for most items, I’d take the historical repair cost and average this. Sure some repairs will be more expensive than others but, on average, they should be this average cost and will be shown when comparing the moving average at the start of the period with the moving average at the end of the period (for standard cost no price variance). If the moving average is changing or you have a price variance this is then cause to analyse your costs and either accept the moving average or standard variance or work on understanding why it’s costing you more than expected. The most important point here is that you make a decision, draw a line in the sand, and start transacting against this. This will be your best bet on the costs and if it’s not right you’ll at least be tracking all the costs and have the insight to improve.
Thirdly and lastly the vexing issue of depreciation. At heart is the schizophrenic nature of a rotable – it is both capital and expense item. When received in stock we need to keep the value in the balance sheet under stock, but when it’s issued to an order the stock value must go down but the item must remain on the balance sheet as a ‘fixed’ asset and start depreciating. Maintenance spares are usually expensed when issued to a work order. The decision here is then on where the costs go when the rotable item is issued to a job. In SAP these items can be settled to an asset and hence depreciated. I’ve seen a number of solutions built for this part of the process and will be dependant on your local accounting rules, the granularity of your financial assets and the specific requirements of your accounting department.
To improve your rotable process go and find areas where you can improve usability, value the items the best you can and use standard reports to show you where the items are. Go, go and do it now.