Oracle & SAP Enterprise Resource Planning (ERP), Enterprise Performance Management (EPM), financial planning and analysis (FP&A), revenue recognition, risk management, governance, compliance, procurement, project planning, tax reporting, and other solutions are the technical platform choices for many organizations. Their modern, connected back-office applications deliver the functionality, analytics, security, and social collaboration tools that help foundationally run businesses.
When combined with Asset Lifecycle Management (ALM), the overall solution gives any enterprise perfect visibility, insight, and control of their asset universe.
While ALM can function stand-alone, some of the greatest value that it brings is the ability to integrate with systems like Oracle and SAP, all of which can benefit from the data that Field Data Collection solutions can harvest and store.
A good ALM system is designed for field users to collect information about assets whenever they are physically encountered or transacted. As such, integration with existing systems provides accurate and up to date physical inventory status using the ALM interface services. Oracle and SAP’s financial, planning, ordering, purchasing, warehouse, spares management, etc. all have specific sets of needs that need to be customized for the full system to work perfectly.
For example, there are several areas in the asset lifecycle that are considered financially triggering events, including initial PO receipt, installation and project go-live, repair and warranty execution, inter-business transfers, excess availability and re-use, retirement and disposition.
Oracle and SAP have a limited mobility solution that isn’t as robust as solutions like Fulcrum Technologies’ CATS ALM. This specific solution speaks the field language, not just the financial language. In simplistic terms, the field doesn’t know the finance information, the finance systems don’t know the field information, and ALM is the bridge that collects the data, reconciles it, and pushes it back to all connected systems. An example of that disconnect; part numbers from a purchase order pulled from SAP or Oracle differs from barcode labels. The field, when scanning, see the barcode information, but they cannot relate it to the finance numbers, which they cannot see. This causes errors (bad or incomplete data), the need for manual intervention, or an excessive amount of professional services to patch it.
A thorough analysis with each customer determines what is considered a financially triggering event based on their business needs and their ERP system’s needs. Once established those rules are applied to ALM data entry validation and Interface configurations.
ALM integration with Oracle, SAP, or any other back office systems includes a multi-step approach:
- Configure ALM to include Oracle and SAP systems business logic and validations rules at the point of data entry.
- Evaluate each transaction as it occurs to determine system notification needs.
- Capture an event record of the transaction and any transient data needed for Oracle systems for later processing.
- Establish processing rules applying any additional integration rules required by each Oracle system (i.e. rolling up of transactions, pending of transactions, processing order of transactions, automatic reprocessing of erred integration records, etc.)
- Schedule ALM integration services and configure the services to create interface files in required formats and delivery methods.
- Establish error handling and management methods.
One of the primary considerations when implementing the ALM application is how to populate the system with inventory and asset data. There are various options available, depending upon the client’s needs and maturity level with asset management in general. This can range from performing an initial inventory in conjunction with the ALM system implementation, all the way to a comprehensive data conversion with one or more enterprise systems.
An initial inventory may be an option for businesses which are implementing an asset tracking or asset management system for the first time. In this scenario, there is often no legacy data for assets and inventory, or if data is available, it is highly suspect for data integrity. Either a client’s internal team or a contracted team would travel between locations where trackable equipment resides and perform the initial identification of asset and non-serialized inventory into the ALM application. This option may present a higher cost either materially in contractor hours, or in changing focus of internal teams that are not typically tasked with this type of work. However, this option does present a time-boxed option for getting the asset and inventory data quickly.
Another option for those clients with little to no, or suspect legacy data is to perform the initial load of the asset and non-serialized inventory data into ALM in conjunction with performing the business processes that involve handling the trackable equipment. This is typically done by focusing on distribution centers first, where equipment moves through prior to being shipped to field locations, and at locations where excess equipment is consolidated from the field. This is often augmented with an Audit schedule of field locations, to allow for capture of those locations’ trackable equipment over a reasonable time period.
Over time the ALM system is populated with data as the system is exercised. Initial costs should be lower than dedicating an inventory team to perform the initial identification, as described in the first option. However, this option isn’t time-boxed, so there may be more ambiguity as to when the majority of trackable equipment has been identified, and the ability to realize full benefits from the asset and inventory data may take longer to manifest.
For a client that has legacy asset and inventory data available, and there is a level of confidence in that data, a data conversion plan is an attractive option. Within this approach, there are several different methods available to load the data into the ALM application. Options can include having users load Excel data files directly via web forms, setting up one time jobs that systematically ingest data, to implementing incremental loads of initial and delta data extracts through a dedicated interface.
Costs associated with performing data conversions will range commensurately with the level of systematic process needed. High degrees of system-based integration will cost more to setup and run than simple import processes used. However, a direct data conversion will preclude the need for hiring dedicated inventory teams and can provide a benefit sooner.
Implementation teams are well versed in the different options available to load the ALM system with asset and inventory data and work with Oracle and SAP enterprise clients to identify the best options for them. Often this is a combination of different options available. As an example, a data conversion and then an audit of field level locations within an initial time frame to true up discrepancies that would inevitably occur with snapshot data. The goal of the implementation team is to get the ALM system providing benefits for the client with the least amount of disruption to the user base, as soon as possible.
If you want to get visibility, insight, and control of every single asset and perfect your digital transformation of core business processes, take a look at the powerful combination dedicated ALM connected to your critical systems.
