Showing posts with label internal order. Show all posts
Showing posts with label internal order. Show all posts

Sunday, November 27, 2011

SAP Enterprise Asset Management (EAM) Benefits


The latest water cooler talk at HPC was about Enterprise Asset Management. By combining elements of Plant Maintenance, Project Systems, Materials Management, and Warehouse Management, SAP EAM enables utilities to realize much higher productivity from PM orders compared to Internal Orders. After setting up a Functional Area hierarchy and identifying the location of all assets, utilities can create orders more efficiently via notifications (what we'd call a "pre-order"). So if the inspection of a pump, for example, identifies necessary corrective maintenance work, the order for that work can be created automatically. Tight integration with the MM module, plus records of prior labor and parts history, also mean that repair kits with all relevant parts can also be identified easily.

For utilities that are considering transitioning from their legacy CMMS to SAP EAM, we would make two particular recommendations. First, ensure that your project team includes subject matter experts from Engineering, Construction, Generation, Transmission and Distribution Maintenance—that is, the people who know what it takes to fix things that break. Their knowledge and requirements will ensure the success of the initiative beyond the needs of IT and Finance. Second, conduct a thorough review of all equipment so that nothing is inadvertently left out of Plant Maintenance. For selected assets, seriously consider bringing in a year or two of work history from the external CMMS.

Tuesday, November 9, 2010

SAP Internal Order (IO) Settlement and the FERC module

We recently had a discussion about Internal Order (IO) settlement and how it impacts the FERC module. In one scenario, a utility uses allocation structures that assign multiple primary cost elements to single secondary settlement accounts. This process results in no alignment of final settled costs in a cost center between the source primary cost elements and the secondary settlement cost elements, which concerns some users. The configuration combines the standard FERC solution results with the final fund ID from the Public Sector (PS) solution.

A question was raised. What would happen if the allocation structures were changed so that all cost elements settle on themselves and eliminate the secondary settlement cost elements? How would that impact the FERC solution?

In this example, the change should not impact FERC. While we do look at the fund assigned to the receiving cost center for each IO, we don't care if the cost elements have changed or are the original ones. When an IO is charged with either primary costs (e.g., materials, contracts, and employee expenses) or secondary costs (e.g., labor and overheads) the FERC solution ignores the settlement transaction in CO altogether. So whether a composite cost element is used for settlement or the original ones are used, settlement is not relevant.

In another scenario, a utility is settling to the original cost elements. There will be more records in the database when crediting the original cost elements. Settlements (and any reversals) will therefore take longer to process. Another drawback to crediting the original cost elements is that it will be harder to find the amount of each cost element capitalized. So if you wanted to see total labor, you would have to look in cost centers excluding the CO settlement transaction—you couldn't simply use the G/L to find total labor, since only the net to expense can be found there. For these two reasons, most utilities use the design in the first scenario, in which one composite cost element is credited for labor, one for materials, etc.

For utilities considering a change in allocation structures, we recommend looking at the budgeting model to see if the budget should be assigned a different set of receiving cost centers from the ones charged for labor. In one scenario we know about, original cost centers receiving the work from the IOs make the CO cost flow very circular. This can confuse users trying to monitor the budget by cost element.