In our company - a large consumer products firm - we implemented Modeller/Monitor under 6/6.1 a few years back, but have struggled to bring our business users ‘on board’ with the concept of actively managing and controlling “their” own business processes. They are very ERP-centric, and are used to using their ERP system(s) as their source-of-truth for order and shipment status. We handle in excess of 3 million orders per calendar year, and are about to consolidate 6 ERP platforms into one (SAP ECC6).
For example, one major retailer sends us around 1,500 multi-line purchase orders every day, via EDIINT/AS2. Many of these orders we ship via a 3rd party logistics company, and then the retailer requires both a Purchase Order Acknowledgement, Advanced Shipping Notice, and electronic Invoice - classic full EDI supply chain.
Given the number of transactions flying around, it is my desire to lead our business users towards making greater use of tools such as Monitor (or whatever it is called now under 6.5) to provide a ‘dashboard’ for handling in-exception transactions.
I am interested in learing from forum members what solutions you have put in place using webMethods to assist your business users in similar circumstances.
The picture I have in my head is one of a simple web interface - probably .dsp pages driven out of the back of WmMonitor package - that refreshes every 30 seconds or so, and provides probably two “action panes” - one of a list of transactions where the process model has “failed” and requires human intervention, and one that keeps a heartbeat track of trading partners - and has red/amber/green traffic light indicators that give a heads-up display of the last time contact was available with a trading partner, etc.
If anyone has any practical thoughts/examples of this matter [ screen shots always welcome ] it would be great to hear from you.
Al,
The one suggestion I have is to not build anything custom on 6.1. The WmMonitor functionality that is there has been removed (no more DSPs) in 6.5 and replaced with the my webMethods Server (MwS).
The other item is the 7.0 release due at the end of this year. The main focus of that release is on the Modeler and Workflow components. I am not sure if anything is changing on the runtime side of that including the MwS but it is probably worth a question to webMethods before you go the custom route.
I worked with a large company that had made significant use of Modeler and Monitor to do the very same thing. They are more or less abandoning that effort. Exposing the integration layer to business users seemed like a good idea–as you say, it is their process after all–but the specifics of the integrations wierded them out too much. Technically, the solution worked fine. They worked with it for a couple of years. Business user and support-wise, it was less of a success.
What they are doing now is following these guiding design principles:
Resubmission/reprocessing within the integration layer is to be avoided. Such activity needs to be done from the end points.
The integration layer provides status information to the end points or to a business-focused monitoring tool. In this case, the company started to write their own BPM tool (where the M in this case was Monitoring) and could be fed from multiple sources, including the integration layer and the applications. The thinking here is that the application end points are in a much better position to provide status–within the right context. Part of the challenge of using the integration layer to provide monitoring is that one ends up reproducing some of the logic of the end point applications–to provide the context of the transaction. This is where the trouble lies.
Monitor and other integration tools are to be used by the integration teams. Business users do not use these tools.
Bottom line for them was: the integration team (and its tools) wasn’t really in a position to provide the application support that the business users (in the various business units) need. The application teams were in a much better position to do that. The integration layer becomes the “UPS” or “Fedex” that delivers the package and sends status–the status was managed outside of the integration layer.
Mark – Yes – we are upgrading to 6.5 shortly. We have some minor models built in 6.1, but these are more for the benefit of the integration team, and to provide a restart-the-process button to end users where a process has failed due to a non-tech issue (i.e. master data inconsistency that requires a refresh to be pushed down by the business). Interested to see what 6.5 has to offer with MwS…have only heard of brochure-ware on the wM 7 front so far…and am more than happy to let someone else “go first”.
Rob – Good advice, thanks. The comparison to Fedex/UPS is a good one, however at the risk of extending your analogy a little too far, even Fedex provide their “end users” with a portal/query tool to glimpse inside their “integration layer”. It is not that customers don’t trust them…they just want to know where their precious cargo is, and not just “its left here and its coming to you”…they like to see it bunny-hop across the globe from waypoint to waypoint.
It is the same with our end users…with close to 10,000 multi-line transactions per day, in a near-just-in-time outbound distribution environment, MOST of the transactions fly through and never touch the sides. It’s the exceptional transactions, or exceptional events, that cause the grief.
I agree with you that the single-source-of-truth for transaction status (and as much as possible, resubmission control) should be the ERP system/origin points. However, we lose control of transactions that pass outside of our organisational boundaries either side of our extended outbound supply chain (retailers one side, logistics partners on the other) and that is where the users need reassurance. It will be a case, for us, of educating our business users to monitor-by-exception, and that is a tough one for them.