It is the return of ideas with ESA and the SAP NetWeaver platform when you take the Solution Architect paradigm. Org. A is in the process of evaluating an xApp that would help achieve its EAM objectives. The focus is mainly around Plant maintenance. The need for an Asset data management and spare parts solution is glaring. However, Org.A feels that it is not ready for ACM as yet. BOMs have to be nailed down, design drawings and pictures of parts and designs have to be captured – all this requires a clean-up of its parts master data and enhancement of the data in terms of the images and inclusion into the drwaings where they fit in as yet. The solution that Org.A has in mind for this EAM system adoption includes maintenance work management and supply chain management productivity to track equipment reliability and availability as Org.A is primarily a manufacturing driven organization. Asset information and maintenance data availability on time and tracking of the same is the need of the hour spanning MRO and engineering. So, does a build approach make sense over a buy or to customize one?
The business solution that is required at Org.A defines a scope that demands easy system usability through the SAP NetWeaver Portal (the new name), one that provides both casual and serious users with a single point of access to a workplace that is driven and governed by guided procedures, roles and functions. A use for a powerful workflow is envisioned over here to simplify and guide the process execution and adherence. The roles that would play in the EAM space have been identified as operator, planner, buyer, engineer, scheduler, technician, supplier and manager to identify key roles and functions attached to it based on the nature of the work that they perform to enable these concerned personnel to gather immediate data and information on critical asset information and spare parts/services to support decision making and daily functional activities to improve operational efficiency. The scalability of such a solution would require a phased development/roll-out would need to make way for a solution that replaces an existing parts-management system. Though the initial thought process was to scale up the parts management system, which is a J2ee application, the evaluation shifted to the xApp and the additional build-approach on this spare part management system to metamorphosize it into an EAM solution. The decision is being reconsidered.
A business case:
Currentlty, the demand for spare parts within Org.A primarily depends on the output of preventive and corrective maintenance activities based on MTTF (mean time to failure) calculations within the existing java application. Frequent unanticipated breakdowns owing to out-of-step operations or failure to perform a routine maintenance activity on time as needed continuously leads to unplanned demand with no historical predictive causes and this has made it essential for Org.A to maintain a buffer inventory which, again, is an overhead. Lack of information about capital assets and their parts capture, therefore, has directly led to increase in costs. Unlike production parts, which have a predictive demand based on market demand, the spare parts for capital assets is more need based in Org.A today. Add to this the lack of historical data on consumption and repetivive breakdown and failure has only increased the need for a system that handles the enterprise assets and spare parts linked to the core ECC 5.0 engine. A solution that can generate a predictive demand for spares based on the maintained capital assets to bring it into the streamlined purchasing route. This is so as the nature of such parts for these assets have a large degree of substitution in terms of parts and vendors as well where the purchasing is more ad-hoc and serviced locally to reduce down-time of these aseerts. The need of the hour is to capture all such data in terms of Assets and parts related to maintenance, both corrective and preventive, to lower the buffer costs of holding this inventory and to improve the supply-chain efficiency.
Idea #4: Spare part handling:
Platform Approach #4: Retaining useful home-grown systems:
This solution needs to interface with the core ECC 5.0 instance and other applications like the BOB application on SFC in Org.A and most importantly, to SAP NetWeaver BI. Since PP, MM, SD, PM and FI-CO are in place in Org.A, the engine primarily needs to talk to an SAP landscape. The solution that needs to be (a)Built, (b)Bought, (c)Customized would need to keep a track of all assets within Org.A, track and report maintenance needs proactively, and plan for replenishment of spare parts and servicing and reduce buffer inventory. A tight integration with BI 3.5 to trigger off BI broadcasting and alerting is being evaluated with EP as the front-end running BEx queries scalable to incorporate a visual parts maintenance system with MDM integrated with XI in the future to predict part demand by phyical location, internal algorithms for condition based monitoring. This xApp would need be integrated with KM and Analytics to facilitate options around demand prediction, managing shifting inventory, reduction of buffer inventory and ad-hoc service requisitions, streamline procurement with more prediction and select suppliers and creating a cause-and-effect repository. It needs to continually track the life of assets based on AMCs, their retirals and depreciation. What in effect translates into a hybrid solution serviced by ECC 5.0, BI 3.5, GP based UI with EP, with the complex algorithms of the legacy application built/retained as a portal/web application or give way to the xApp available in the market – The fitment of the same is around 50% to 60% of the business need within Org.A, therefore the need for possibilities, with ACM being low on the radar towards a comprehensive EAM solution.
1. As the xApp fitment is less than 60%, leverage the existing J2ee application and deploy it on WAS, integrate with BI via EP, use GP and create a home-grown xApp.(see deployment model as in diagram above, use CAF to build on ESA.
2. Deploy the xApp as available off the shelf without ACM.
3. Customize in ABAP, extend the solution as option 1.
Potential ESA Candidates:
Candidate one could be the complex algorithms being built as enterprise services to track service levels and dynamically update users upon deviations from benchmarks maintained. Another candidate could be the ability of repair and part-substitution based on built algorithms. A futurtistic trend could be to propose design changes based orepetitive failure calls or buying. Or an enterprise service that cycle counts on the basis of models for consumption, demand and value or an enterprise service to continuously monitor and update the EAM data to proactively have master data updation by attaching serial numbers and demanding image and drwaing data integrated with other design t a viaual cleanup is set in action.
A solution like this can be built and in certain cases, may make more business sense. ESA can be leveraged to proactively set right the internals – like master data. The more you build enterprise or web services or intelligence into your supply chain, the better could be your chances of a healthy system. It reminds me of an interesting statement my daughter made the other day, forcing me to eat more carrots. Her logic was – “Dad, have you ever seen a rabbit wearing glassess?”
Have a great new year ahead!