CMMS/EAM AND FINANCIAL INTERFACES. Joe Grassi, Grassi & Associates

Transcription

1 CMMS/EAM AND FINANCIAL INTERFACES Joe Grassi, Grassi & Associates Early this year I had the opportunity to address a number of Mainsaver customers at the 32 nd Annual User Conference and discuss the use of financial Interfaces with their ERP or Accounting software applications. The following is a detailed recap of the discussions. Interface Defined The place at which different things meet and communicate with or affect each other, for example: Mainsaver User Conference The Mainsaver Interface. The place at which independent and often unrelated systems meet and act on or communicate with each other. Objectives of Interface Simply stated the objective of an interface is to provide an ability for independent systems to meet and act on or communicate with each other, while maintaining the quality of the data exchanged and minimizing the human effort to do so. Some examples of Interfaces User Interface How a person works on a computer, a monitor, keyboard, etc. Machine Interface CNC milling machine, how a machine is connected to a computer for control. System Interface Fuel Island interface for fuel consumption monitoring and reporting SCADA system to share supervisory control and data acquisition from a complex system RemStar, AS/RS (storage and retrieval system) to automate warehouse and distribution functions For the purpose of this paper let me narrow the focus to the connecting of a CMMS/EAM to a financial systems such as: SAP, Oracle Financials, or Microsoft Dynamics ERP to name a few. The objectives of this kind of connection might include one of the following cases which I will elaborate upon: Case 1 Maintenance Service Recharge Case 2 Accounts Payable Case 3 Asset/Maintenance Cost Collection Case 4 Payroll 1

2 CMMS/EAM Conceptually CMMS/EAM s are software systems that are modular. Often organizations pick and choose which modules of a software application will be required in order to solve and manage specific functional requirements. In my experience smaller, self-contained, business units of larger corporations tend to use more of a CMMS/EAM s modules where a larger business tend to have many existing systems and use less of their CMMS/EAM systems. The figure below illustrates the basic modules of a CMMS/EAM software application. M- Maintenance Work Order I Inventory P- Purchasing IM Invoice Match F - Financials The following cases discuss various scenarios for interfacing CMMS/EAM s with a financial system. You will note that depending on the number of modules in use effects the complexity of the interface. The more modules in use in the CMMS/EAM typically the simpler the interface becomes. Case 1 Service Recharge Interface The work order system becomes the system of record for the interface and is the repository for the end user activity and cost of work performed. The objective is to send the cost of providing maintenance and facility services to the: End user (Internal Cost Center or External Customer) Done periodically by GL journal entry or Account Receivable System interface Replaces manually extraction, checking, sending, validating and re-keying of data. 2

3 Case 2 Accounts payable interface The system of record for the receiving and purchasing transactions is the CMMS/EAM system. The objective is to send receiving and/or purchasing information from one system to the other for supplier payment. Could be a matched invoice in CMMS/EAM sent to an ERP system for payment which represents the simplest method to accomplish the interface. Without invoice match in the CMMS/EAM individual receiving records and purchase orders may need to be transferred to the ERP making for a more complex interface. Case 3 Asset Management Cost Management Similar to Case 2 but in reverse The objective is to send the cost of maintenance goods and services from the financial system to the CMMS/EAM. Work order system only in CMMS/EAM. Generally, this case is one of the more complex interfaces to accomplish because of the number of transactions and the need to replicate the basic functionality in CMMS/EAM such as: bill of materials (spare list) at the work order planning level, current stock levels to support maintenance scheduling, supplier delivery dates and other logistics needed for accomplishing maintenance, and usage reports for analyzing maintenance effectiveness. 3

4 Case 4 Payroll Interface The objective is to send labor cost accounting from one system to another Could be time cards in CMMS/EAM s sent to Payroll Includes hour types, holidays, premiums, etc. Could be payroll time records sent to CMMS/EAM s Includes work order numbers and time charges This interface is relatively straight forward but proves to be a critical business system. Where the CMMS/EAM is the system of record for time card records the challenge becomes one of ensuring that the maintenance system provides the checks and balances, supervisory oversight, security and needed functionality to satisfy payroll requirements. When the ERP is the system of record the challenge becomes one of capturing work order information so that redundant data entry is not required. Basic Methodologies Going back to the definition of an interface discussed earlier as the place at which independent and often unrelated systems meet and act on or communicate with each other, the question of how do systems communicate? Some communication concepts include: API s (Application Programing Interface) Instructions for a software application to create, send or receive data files, process files including reading, checking, and deleting files when no longer needed. These api s are triggered by events or by a fixed schedule, i.e., run every 5 minutes or once a day and are usually controlled by the operating system. There are 2 sets of instructions, One for the application sending the data Another by the application receiving the data Flat File Transfers (Comma Separated Values) from one application to another where the data then gets stored locally. The files include all of the individual data elements required to satisfy 4

5 the owner requirements. Field names, sizes, types, and other rules are observed when files are created. Uses API to schedule pick up & exchange of data. CMMS/EAM s uses the Windows Scheduler to run the API that retrieves data and sends it for use elsewhere. CMMS/EAM s typically deliver files to a transfer table and not directly into the database of interfaced systems. Web Services uses extensible Markup Language or XML (readable by human or machine) Is a method of using a software function using the web with an address that is always on Still uses an API but contacts a web address to send the request/file Uses SOAP (Simple Object Access Protocol) and WSDL(Web Service Development Language) or RESTful (Representational State Transfer) Linked Servers a method to retrieve, combine and display data between multiple servers. Uses database functions and SQL statements API s could still be required to start the process or use an existing software function Data typically not stored locally (but could be) so it is dependent on a network connection Project Implementation Plan The typical project plan consist of a review of the owner requirements and objectives for the interface. This includes system analysis to determine where the two systems must touch one another for the required data exchange and which system is the official system of record. How will the systems communicate? What specific data must be sent and does it need to be transformed to make it compatible with the other system? If so, which system will transform it, this process is referred to as data mapping. Once these requirements are reviewed and documented a programming specification can be developed, project cost estimates can then be prepared, and customer approvals of the details are also typically requested. Once authorized and funded programming, testing and packaging of the software occurs. Installation, pilot testing, training, final production installation and go-live then occurs. It is also important to consider on going software support to ensure that both sides of the interface are keep current with future software updates. The following are specifics for how a Case Study 1 Service Recharge Interface might be planned: Defining the Project Requirements Business Case Customer using CMMS/EAM for Maintenance, Inventory, Purchasing and Invoice Match processing and require weekly file transfers from the CMMS/EAM s to General Ledger (GL). 5

6 They plan to replace current manual journal entries with an automated process to charge out expense of work completed to the requesting cost center. There will be one touch point from work orders in CMMS/EAM to GL staging table. CMMS/EAM is the system of record for all financial transactions except for supplier payment. Case 1 Touch Points CMMS/EAM Work Order ERP Activity Staging Assumptions 1. Cost Center/Accounts valid in CMMS/EAM no touch point to keep them synchronized with ERP system is required. If cost accounts are dynamic and valid account codes change frequently a touch point that would synchronize the accounts codes could be justified. 2. Invoice Match in CMMS/EAM is in place and working so that actual cost on Work Order reflect approved invoices that have been matched and sent to the A/P system. Without this assumption the CMMS/EAM would not be the system of record for these transactions and would not require an interface for that portion of the activity cost. Case 1 Data Requirements The following is the hypothetical requirements for data needed by ERP for journal entry into the general ledger. CMMS/EAM (work order) Charge Account Code Credit Account Code Work Order Number Requested By Completion Date Work Requested Labor Cost Material Cost Special Order Cost Contract Cost T R A N S F E R T A B L E ERP Charge Department Account Code Credit Department Account Code Job Number Job Requester Job Completion Date Job Description Job Labor Job Inventory Cost Job Special Order Cost Job Contractor Cost 6

7 Mapping Considerations Field Types Character, Numeric, Date, etc. Field Sizes How big, does it fit? Field Formats Dates, Dollars Transformations Examples: Make date look like YYYY/MM/DD it currently looks like MM/DD/YY. Work requested is 2000 characters but ERP supports 256, etc. What are the rules to be followed? (Format changes, summations, default values, truncate long fields On a practical note the following screen captures illustrate where most of the data is displayed within the CMMS/EAM. Typical Work Order Add/Edit screen showing originator of request, date, work requested and status of the work. Information that is required to be transferred into the interfaced system. 7

8 Typical Work Order Edit screen once cost have been charged to a work order and shows the cost accounting and actual and planned charges on the work order that are required in the interfaced system. 8

9 A recharge cost summary report showing cost center, account code, asset number, and charges to have a journal entry created. Conclusions Keep in mind that every interface is different. Interfaces are unique to an organization. Every organization has its business practices and culture and interfaces must conform to internal practices if they are going to successfully satisfy objectives. The data requirements are also unique and are driven in combination of management preferences and software requirements. The communication protocols are however standardized but there are still choices and decisions that must be made consistent with organizational needs. Another important aspect of interfaces are that it requires two willing partners. Knowledgeable service providers can support the technical assistance required to successfully interface multiple applications. In my experience many organizations would benefit from a properly planned and executed interface with their CMMS/EAM. Justifications include reduce cost to provide the right information to the right decision makers in support of making the right decisions. 9