Re: Benefits of OLM -- BPCS-L

Antonio:

I agree that if you are bound to the decision to use native BPCS 
mechanisms to produce the outbound 856 ASN document, then you will have to 
implement OLM. 

As to whether OLM will be a satisfactory mechanism for your purposes, here 
are some issues you can think about ...

How will you correct errors?

For example, you may have to prepare load documents before the truck 
arrives. If you planned for a full truck load, and the truck arrives 
already half-full, then you won't be able to put everything on the truck. 
What do you do then? Does OLM allow you to maintain shipment data, or do 
you have to cancel the shipment and start over at the picking stage? How 
often does this kind of thing happen? What impact does this have on 
workflow in the shipping area? How receptive will the shipping staff be to 
the extra work they have to do when this happens? Is the amount of time it 
takes to correct this situation within tolerance for loading dock staff 
and transport drivers?

For UCC128 labels, how is the label tracking file merged with shipment 
data? If somebody neglects to issue the correct number of labels, or if 
labels are damaged, is there a means to catch this error and correct it 
before final documents are produced?

Are data capture mechanisms optimized for your volume requirements?

At low volume, not much of an issue, but at high volume this can be very 
important. Our shipment data entry module reads a script that tells it 
exactly what data fields are mandatory for every trading partner, hides 
irrelevant data and requires the rest. Data entry operators don't have to 
guess about what fields are required, and errors (which lead to fines from 
some trading partners) are sharply curtailed. Once we become confident 
that our "default" business rules are near 100% reliable, we set flags to 
skip screens unless errors are detected by the program, speeding data 
entry.

For very high volume, we can insert data streams from bar code readers to 
supplement or replace data entry.

Does the solution handle all of the 856 document variations you require?

Can it produce pick-pack AND standard pack documents for the same trading 
partner?

Are you able to place Pack and Tare levels anywhere in the document 
structure? SOPI? SPOI?

How much CPU utilization overhead does ECM levy for your expected document 
volume?

In our experience, ECM is pretty costly for inbound order processing at 
high volumes due to its architecture. We have never measured ECM outbound, 
because we don't use it.

Will you be able to achieve compliance with trading partner performance 
expectations?

Trading partners expect 856 documents to arrive before the truck with 100% 
accurate content. This isn't always easy to accomplish in a hectic 
environment like shipping. Staff turnover and sick days can compound the 
challenge. In our experience, if the 856 process can't handle exceptions, 
it won't work very well.



I wish I could have provided answers instead of questions, but we have 
never had an opportunity to take a very close look at OLM. We wrote the 
first version of our shipping module before OLM was introduced. And 
although our solution has been measured against OLM, it wasn't by us: We 
weren't on engagement at client sites when OLM was considered. By the time 
we arrived, the client had already decided to use our solution instead.

That said, my impression is that OLM is problematic for some of the issues 
mentioned above.

Finally, we like to be careful about how much we exploit ECM and other ERP 
vendor-provided strategies for e-commerce integration. If you embed very 
much function within their integration mechanisms, and they modify or 
withdraw these mechanisms, it can be very damaging to your project.

I hope this helps. Please call or message if I can be of assistance.

John Dyer


John G. Dyer, CDP
Vice President
Information Management Consultants, Inc.
jdyer@xxxxxxxxxx
http://www.imcedi.com
812.421.0045 ext. 203