The decision to implement an integration solution usually leads to more requirements, more questions and more complexity. Overall, implementing an integration solution, large or small, can be a daunting task. Many factors must be considered, such as:
- Types of integration
- Business to business (B2B)
- Application to application (A2A)
- Business processes
- Activation methods
- Source and target Endpoints (partners and/or applications)
- Human approval stages
- Source and target data formats
- Flat file (proprietary or non-proprietary)
- Data translations/transformations
- Data conversion
- SQL look-up
- Special processing
- External programs
- Communication methods
- Web Services
After all of the system and environment assessments and analyses, planning, configuration, implementation, testing and deployment phases are complete; there are still the daily operations that have to be managed. This final phase of system auditing or day-to-day monitoring can be handled internally, externally by trained system specialists, or both. One of the tools that can aid in simplifying this phase of the integration is a web-based dashboard.
So, how can dashboard technology used in conjunction with integration, help to simplify the daily operations of an integration project? Let’s look at some of the common strategies utilized in this phase and apply dashboard technology to each.
The first case we will look at is a B2B scenario. You are trading hundreds of EDI documents with your trading partner and then it happens; one of your partners sends you a purchase order document, expects an acknowledgement that it was received and accepted (or rejected), but doesn’t receive one. Traditionally your trading partner would pick up the phone and call your customer service department to verify that the purchase order was received. Customer Service would look in their system to see if the purchase order was there and if not, call their EDI coordinator. The EDI coordinator would then search for the transaction in their integration software’s logging system, relaying the information to Customer Service and eventually back to your trading partner. With a dashboard running against your integration software database, you could create reports containing this information. Then, you could create custom users or roles with specific data restrictions for each of your trading partners and safely expose the dashboard to your external trading community. This would provide your trading partners with access to the dashboard system, allowing them to perform “self-serve” look-ups using the document status reports that you have exposed.
If you aren’t comfortable providing this type of external access to your internal systems, instead of creating multiple users or roles with data restrictions for each trading partner, you could instead create one role with full data access for your customer service department. Your trading partners would then call your customer service department and instead of contacting the EDI coordinator for the requested information, customer service would perform “self-serve” look-ups for each trading partner.
Finally, what if your trading partner sends you a purchase order, the order is entered into the system, shipped and invoiced, but accounts receivable needs to verify the status of the invoice document? Instead of customer service contacting the EDI coordinator, it would be Accounts Receivable. Using the same dashboard system, you could create additional reports and different roles with access to these reports for the Accounts Receivable department.
All of these scenarios can exist in any business environment and be addressed by using dashboard technology. And, since all of these scenarios provide some form of self-service capability, they have the potential to save a lot of time and money for your company.