The Leading2Lean MES/Dispatch solution can be integrated to a wide range of external 3rd party
systems. These include Enterprise Resource Planning (ERP), Computerized Maintenance
Management Systems (CMMS), Manufacturing Execution Systems (MES), Time & Attendance,
Document Control, Traceability, and Training solutions. This document describes the most
common integrations methods and data (application areas) and for integrating 3rd party
applications to the Leading2Lean MES/Dispatch application. You should use it as a planning tool
to help identify the areas of integration and the methods/scenarios that most closely correspond
to the business process you are trying to support.
Dispatch has an open web service Application Programing Interface (API) that is based on the
HTTP, REST, and JSON standards. It is very easy to use and provides the flexibility required for
most needs. (For more information on the API please refer to the API documentation.) While this
API allows integration in many different ways, most companies are interested in the exchanging
data in one or more of the following application areas:
- Spares parts list, inventory levels, and usage
- Machines/assets and lines/cells/cost centers
- Preventative maintenance orders, work orders, and reactive calls (dispatches)
- Employee records/logins
- Production schedules and actuals
- Labor hours, material, and other costs
In each of these areas, we have several standard integration methods that range from fully
automated to partial automation augmented with some manual processes. To determine which
of these methods is right for your company depends on the integration functionality available in
the 3rd party application and the business purpose you are trying to accomplish. A combination
approach may be needed where the 3rd party applications have easy mechanisms for reading
data out, but no functionality to write data back in.
When to Integrate
When integration is appropriate, it can enable the flow of data between systems, improve data accuracy, and drive efficiency. However, before you sprint headlong into your integration plan, it’s important to pause and evaluate the expected benefits.
Manufacturers can often fall into the trap of viewing systems integration as the solution to their data problems. Just because integration is possible does not mean it will unlock any additional value for the business. Appropriate integration means only integrating when and where it makes sense for your business.
Integration makes sense when it:
- Provides visibility to hidden problems
- Automates the collection of production data or machine cycles
- Triggers an important human process (i.e. Signals material handlers)
- Makes data from unseen siloed systems more accessible by operators/technicians
- Saves time for large numbers of users
Integration done for other reasons can be a waste of resources. Integration does NOT make sense when it:
- Only saves a few button clicks
- Automates infrequent tasks where current methods suffice
- Moves data to unseen, siloed systems
- Further entrenches outdated legacy systems or corporate “system of record” mandates
- Is driven by aspirations like, “totally integrated,” “no double entry,” or “lights out operations”, where there is no clear cost savings or additional business value.
- Means spending dollars to save pennies - No clear return on investment (ROI)
One Way Replication
The most common method is where data is maintained the one system and pushed to the other
system. All editing of that data is done in the first system. This synchronization happens
automatically in the background by the integration application without any intervention by the user
of the systems.
One way replication tends to simplify the integration effort and the training required for end users
by having one system responsible for maintaining a given set of data. While two way replication
is possible, we’ve found in practice that end users prefer to have one system of record for any given set of data.
For example: In a typical CMMS or ERP system integration we see “master” data such as
Machines/Assets or Spares Parts lists already being maintained by accounting and purchasing
departments. That data can be used in Dispatch by providing a one way replication into the
dispatch system. In this case the system of record for adding new Machines or Parts is the
CMMS or ERP system. The typical integration syncs that master data one way to the Dispatch
Another example: Dispatch or Work Order events are typically created and maintained in the
Dispatch system. Based on your companies business requirements this event records can be
synced one way to the CMMS or ERP system based on record creation, on update, or just when
closed out in Dispatch. Syncing individual events can provide an additional copy of the work
history and spares/labor detail. But since that is already widely available in Dispatch most
companies choose to just sync aggregated costing information on a per machine per time
Possible Location for Common Master Data
* NOTE: Dispatch can function as the master in any or all of these areas if needed.
|3rd Party CMMS / ERP||Dispatch|
|Spares: Parts List, Costs||X||*|
|Spares: Inventory levels||X||*|
|Spares: parts usage / issues||X|
|Machines / Assets||X||*|
|Lines / Cells / Cost Centers||X||*|
|Preventative Maintenance (PM) Schedules||X||*|
|Work orders (planned work)||X||*|
|Dispatches (reactive calls)||X|
|Employee Records / Logins||X||*|
|Production Schedules / Demand||X||*|
|Production Numbers / Actuals||X||*|
|Labor hours, material, and other costs||X|
Partial Automation / Manual Processing
With some 3rd party tools there doesn’t exist a good integration method or API to
programmatically synchronize data as described above. In these cases we have a number of
best practices to consider:
- Take advantage of any file import / batch processing functionality. If your 3rd party
application can import or export data from a file, we can utilize that functionality.
- Consider using Dispatch as the system of record and using aggregated costing
information only in 3rd party system to ease data entry requirement. Many 3rd party
applications can achieve roughly the same functionality by entering aggregated
transactions for the time periods required. For example: ERP systems that need labor
and spare cost information, you might consider entering one transaction per week/month
with that data based on the reports from Dispatch. This method transfers the information
the ERP system needs without requiring all of the detail information.
- Centralize any data entry to a designated low cost resource. If you have no ability to
programmatically import the data and still need to use the 3rd party system, you should
consider centralizing the data entry. Thereby lowering the impact to the user of the
system and gaining an auditing advantage of using a separate employee to transfer the
data from those using the system.
Summary of Integration Best Practices
|Full API Access
|Partial API Access
|No API Access
|Use One Way
|One way replications will still work where the 3rd Party system is the system of record for items like Machines, Spare Parts Lists, etc.||One way replications will still work where the 3rd Party system is the system of record for items like Machines, Spare Parts Lists, using database access to collect the data.|
|(None required)||File/Batch Import, Manual
Data Entry, and/or Transfer only aggregated information.
|File/Batch Import, Manual Data Entry, and/or Transfer only aggregated information.|
Typical Integration Scenarios by Application Area
Spares parts list, costs, inventory levels, and usage
Here are the common scenarios we’ve seen for integrating Spares with a 3rd party CMMS or
- The master parts list, costs, and inventory levels reside in the 3rd party system and are
synced to Dispatch regularly. The usage is tracked in Dispatch and passed back to the
3rd party system to be taken out of inventory. Spares usage costs are provided via
aggregate reports or detailed records back to the 3rd party system.
- Dispatch tracks the parts list, costs, inventory, and usage. Dispatch provides reporting
for purchasing to reorder parts that cross a min stock level. Purchase Orders are tracked
in the 3rd party system. Spares usage costs are provided via aggregate reports or
detailed records back to the 3rd party system.
Machines/assets and lines/cells/cost centers
These record areas are not transactional in nature and are typically synced one direction or the
other based on the companies preferences for where they want to edit them.
- Records are added and maintained in the 3rd party system and synced to Dispatch for
- Records are added and maintained in the Dispatch and synced to 3rd party system.
Preventative maintenance orders, work orders, and reactive calls (dispatches)
Most of our customers are migrating to using our PM scheduler for planned work. Here are the
few options we’ve seen.
- PM’s and work orders are scheduled and maintained in Dispatch. Completed PM’s, work
orders, and reactive calls (dispatches) generated in dispatch are synced back to the 3rd
party system as detail records or aggregated cost/labor information.
- PM’s are scheduled in the 3rd party system and launched as dispatches in the Dispatch
system. Completed PM’s, work orders, and reactive calls (dispatches) generated in
dispatch are synced back to the 3rd party system as detail records or aggregated
Employee records / logins
We have the ability to sync employee records to the Dispatch system via the the API. We also
support LDAP integration with customer servers for authentication. And/or the ability to
integration with customer web portals for Single Sign On (SSO) capabilities.
Production schedules and actuals
Companies can integrate via the API with Dispatch to provide the following:
- Production schedule (pitch schedule, demand).
- Production actuals (actual parts produced, scrap quantities, product sku, and operator
This data is also available via the API for export.
Labor hours, material, and other costs
Labors hours spent working on PMs, work orders, and reactive calls (dispatches), along with any
material or external costs can be provided back to the 3rd party system in the following ways:
- As detail labor/cost records for each PM, work order, or dispatch in the system.
- As aggregated labor/cost records on a per machine, per line, and/or per day/week/month
This data can be provided via automatic integration or manually with users running reports and
manually entering the data.
This document provides an overview of the common integration methods and scenarios we see
with our customers. Many other scenarios are both possible and in use today. If you don’t see
the integration listed above that you are looking for, please ask us and we’ll be glad to provide