Integrating Asset Lifecycle Management with Oracle

Oracle Enterprise Resource Planning (ERP) Cloud and Oracle Enterprise Performance Management (EPM) Cloud offer accounting, financial planning and analysis (FP&A), revenue recognition, risk management, governance, compliance, procurement, project planning, tax reporting, the financial close, and much more.

ERP software is the backbone of many organizations. Oracle's modern, connected back-office applications deliver the functionality, analytics, security, mobile capabilities, and social collaboration tools you need to run your business.

When combined with Fulcrum CATS Asset Lifecycle Management (ALM), the overall solution gives any enterprise perfect visibility, insight, and control of their asset universe.

While CATS can function as a stand-along asset management system, some of the greatest value that it brings is the ability to integrate with those Oracle systems that can benefit from the data that CATS Mobility collects and stores.

The CATS system is designed around field users collecting information about assets as they are physically encountered and acted upon. As such, CATS integration with existing systems provides accurate and up to date physical inventory status using the CATS interfaces services. Oracle’s financial, planning, ordering, purchasing, warehouse, spares management, etc. have specific sets of needs that we can tailor our interface records to meet. 

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.

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 CATS data entry validation and Interface configurations.

CATS integration with Oracle includes a multi-step approach:

1.    Configure CATS to include Oracle systems business logic and validations rules at the point of data entry.

2.    Evaluate each transaction as it occurs to determine Oracle system notification needs.

3.    Capture an event record of the transaction and any transient data needed for Oracle systems for later processing.

4.    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.)

5.    Schedule CATS integration services and configure the services to create interface files in required formats and delivery methods.

6.    Establish error handling and management methods.

Fulcrum’s implementation teams have a wide array of previous CATS integrations to draw on and reference providing support and guidance for our clients when determining business requirements for each integration. 

Some examples:

> Transfer integrations might exclude transactions for inventory that is inactive, at a repair location, in a disposed or retired status, “non-trackable” part type, in a pending status in external system, have not been assigned a financial asset id in external system, etc.

> Transfer integrations might include transactions on inventory that is moving from one location to another, have a change of business unit or owner, have a change of asset label, serial number or part number, etc.

> Transfer data entry validations might include preventing transfers to inactive locations, to unapproved projects, across business units, to invalid locations and business unit combinations, etc.

> Transfer integration records may be “rolled up” to bypass consecutive intermediate transfer transactions to generate a single transaction showing movement from the Oracle system assets current location to CATS current location, reducing external system processing time.

CATS can communicate in a multitude of ways to meet a wide range of needs and requirements.

With any integration between two systems, there are often numerous considerations to consider, including:

1.    Whether CATS is deployed as a Hosted or On-Premise installation.

2.    Needs for synchronous or asynchronous transmission.

3.    Batch, real-time or On-demand frequencies.

4.    Data exchange methods – HTTP or FTP/SFTP, Direct database access, JMS messaging, Web Services, etc.

The answers to any of these considerations could affect the simplicity or complexity of the implementation of the integration.

For those looking to deploy quickly, a file transfer methodology provides the most lightweight and simple integration option. CATS provides a number of options to provide data files that can be available for external systems. The following lists some options in increasing complexity.

1.    Data Forms that provide data lookups and can be used to manually export data into .csv file format. These forms are provided in the CATS Web UI and can be made available to different user groups through configuration.

2.    Query Builder results, which can be modified by users through the CATS Web UI. Query Builder results are in .csv file format, and are based upon accessing existing CATS database views. Query Builder results can be scheduled to be run and emailed to users at a desired frequency.

3.    Services can be configured that extract data into several types of file formats (.csv, .txt, .xml) and placed into a directory or JMS messaging queue accessible by users or external systems.

4.    Services can be scheduled to run on a desired frequency, and can also include additional validation and error handling options.

5.    Services can be configured to monitor directories and message queues for the existence of data files or messages in different file formats (.csv, .txt, .xml, .jms) that CATS can select and load into the CATS database. Error handling and validation options can be instituted.

6.    CATS REST API is available for external systems to post transactional data to the CATS system.

One of the primary considerations when implementing the CATS application is how to populate the system with inventory and asset data. There are a 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 CATS system implementation, all the way to a comprehensive data conversion with one or more enterprise systems.

An initial inventory may be an option for Oracle shops 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 CATS 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 into CATS.

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 CATS 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 CATS 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 CATS application. Options can include having users load Excel data files directly into CATS via web forms, setting up one time jobs within CATS 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 sooner benefit return of implementing CATS.

Fulcrum’s implementation teams are well versed in the different options available to load the CATS system with asset and inventory data and work with our Oracle 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 Fulcrum implementation team is to get the CATS system providing benefits for the client, with the least amount of disruption to the user base, as soon as possible. 

Enable your team to lead digital transformation of their core business processes and asset lifecycle management with the powerful combination of Fulcrum and Oracle.