Most manufacturing facilities use multiple pieces of software to keep things organized. Each system has a specialized purpose that provides value to a specific segment of the work force. Having many pieces of software presents a challenge which can result in what seems like a maze of softwares that requires a map to navigate. Often a map does exist in an ERP or a document store.
Fortunately, L2L's architecture makes it easy to manage assets that are defined and maintained in other systems. All of our top-level objects can be defined in another system and synchronized to L2L:
- Product Orders
- Cost Centers
- Value Streams
In order to make life a bit easier, each of these items can be synchronized using L2L's API. Automating the synchronization of these objects breaks down many barriers to data management.
Here are a few ways in which L2L makes Master Data Management simple to implement:
Each and every top-level object in L2L contains a "code" property. Codes are not automatically generated by L2L - they are defined by the administrator that adds an item in L2L. Codes in L2L are usually pulled from an ERP system. This avoids confusion and allows for a simple lookup for updating assets in L2L.
Codes cannot be re-used in L2L. Maintaining this unique constraint makes it possible to synchronize data to L2L.
Some items, such as Product Orders, do not have a code in L2L. Instead, they have an External Id. External Ids, like codes, are defined in a system other than L2L. They are also used to synchronize objects between systems. The main difference is that External Ids don't have the unique constraint, so more than one object can share the same External Id.
The following are some helpful tips when synchronizing data across many systems:
- Always choose a single system of record to be the master point of data. This master record will define a code that will be used across all systems. When the master record is update, all child systems should be updated with the new information.
- Synchronize your systems frequently. The frequency should be defined by how often an object is updated. For instance, a Product Order may be updated many times in a single day, but a Machine may only get updated once every few years.
- Provide a clear map of all systems to your users. Make it clear where data comes from so as to avoid confusion.
Please sign in to leave a comment.