It used to be that validating an old piece of information meant manually searching through a warehouse full of storage boxes and hard copies of documents; in other words, trying to find a needle in a haystack. These days, we can, as Robin Sloan said, simply “ask the hays to look for it”. The digitizing of documents allows companies to maintain a massive backlog of records and data, as well as to easily retrieve them.
To manage this massive volume of data, most companies have implemented a document retention policy which states that documents need only to be maintained for a set period of time. However, even with these policies, storage and organizations systems are still incredibly labor and time intensive for workers. Automating the storage and retrieval process is crucial not only for filing and maintaining the data, but also for maximizing the efficiency of your employees.
Fortunately, there are a lot of options for companies looking to do this. FileNet is a great IBM content management system and a large number of Oracle EBS clients use it as their content repository. It provides a high-level of document security, classification and metadata for its files, and is also searchable and retrievable via FileNet workbench and APIs.
Unfortunately, many companies struggle with creating a synchronous bridge between these two servers that would allow the FileNet Content Engine to receive documents paired with metadata from Oracle EBS. Without this bridge, digitally storing, filing, and retrieving these documents becomes as labor-intensive as that warehouse used to be.
In the case of one client, they first had to print all the documents they had as soft copies before scanning them through KoFax with its respective first page template. After being scanned, the documents could be manually loaded into FileNet through programs that would read the first page templates and identify the respective document class for placement within the program. The employee was required to identify the URL for these documents before finally attaching them to their respective Journal Entries or transactions.
Whew…we’re exhausted just writing about it! Can you see why our client had such a significant backlog? To integrate these two disparate systems into one, Value Global consultants designed an application that would allow users to upload documents and would automatically connect them with existing transactions. Although there are innumerable design options, we utilized the following components:
Oracle Application Framework (OAF) Based Web Interface: This webpage was the primary means to load files from the desktop. We internally linked it to the Journal Entry, Invoice, or Purchase Order from which it was initiated, which helped the interface pass metadata related to the transaction to FileNet.
FileNet Utilities (Java API): These components connected to the FileNet content engine and worked with the Oracle interface in a seamless and synchronous way. The utilities interacted with FileNet to save documents to its respective document class and help to retrieve document URLs for those documents not attached, thereby separating Pl/SQL packages that were needed to perform the attachments to the transactions.
Schedulable Java Program: This concurrent program used the same FileNet utilities and packages to retrieve document URLS for “loose” documents and attach them to its transactions in Oracle EBS.
As a result of this bridge, the client saved over $3.2 million in operational cost, and now has a much better grasp of the EAM.
Digitizing your documents, when done thoroughly, can drastically increase ease of use with your historical data. Software, such as FileNet and JAVA API’s, can be called upon to connect to the content engine and work with the Oracle interface in a synchronous way. This opens up accessibility to the files or file URLs, which, in turn, can do all the work in finding that pesky needle, just like it’s supposed to.
Document Class: A category for documents in an object store or library. Every document belongs to a document class such as Purchase Orders. The document class determines the document’s versioning (where applicable), properties, storage location, security and lifecycle.
Metadata: Data that describes other data. Content Engine stores metadata, which describes classes and properties, in the object store’s database.
Content Engine: The FileNet P8 component that provides an object-oriented repository for managing content and other business-related data, collectively referred to as objects.