Although this narrative has been covered before I will post it here for
educational purposes.
For those of you that feel you understand the process for determining if 860
transactions could and should be electronically integrated with the back office
system you can stop reading here.
Integrating the 860 with the back office application can be accomplished; the
real questions revolve around a number of factors that for the most part are
outside of the EDI process.
These are some of the questions that need to be answered before you can make a
case for seamlessly integrating the 860 transactions with the back office system
How many 860 transactions do you receive during the sample periods?
Select sample periods based on any seasonal peaks and valleys of
transaction volume. As an example if company A builds widgets and they supply
company b and company b's customers only buy widgets during the second quarter
of the year and you require a 30 day lead time from Order to Delivery you would
want your sample period to start March 1st and continue until May 31st. This
sample period should provide enough data to determine whether the volume of
changes warrants further research.
For this discussion we will assume that the volume is great enough during the
`peak' period to warrant this additional research. The second sample period
would be the period of the year with the smallest number of transactions. We
will assume that the ratio of 860's to 850's is roughly equal to the ratio
identified during the `peak' period. Warning: Business Decision Ahead.
Now that we have the metrics on volume we need to determine how long it takes
and how much it costs currently to successfully manage these changes. Let's
say the number of changes per 100 orders is 30 and it takes 6 minutes to
provide that change information to the responsible human and have that human
process it. This human makes $20/hour and they can process 10 (60/6) changes in
an hour, each change costs $2. If the total number of transactions per day is
1000, the number of changes is 300, multiply that by $2 (the human resource
cost) giving you a cost of 600.00 per day, multiply that by 5 (days in a week)
time 13 (number of weeks in a quarter) to give you an unburdened cost of
$39,000 for the peak quarter. Now I will assume that the other 3 quarters of
the year are equal in transaction load and that load is 50% of the peak period
load. So we now have $39,000 + (19500*3) = $97,500 unburdened human resource
cost. To roughly calculate the burdened cost we'll multiply the unburdened cost
by 1.25 to give us a burdened cost of $121,875 (roughly 2.5 FTE's).
The business now needs to decide if it is worthwhile to spend the capital to go
to the next step.
This next step is very critical to the success of the initiative and the burden
should be on the order entry and order change personnel.
This step will be best accomplished with as much raw data from the peak period
and at least one of the other 3 quarters. As we analyze the 860 transactions
relative to the originating 850 and the specific business requirements
pertaining to if, when where, how and why the changes are processed. We are
going to group these changes into these 3 groups:
1) 860's that meet all the current criteria to enter the transaction
against the originating PO/SO.
2) 860's that have to be modified to meet the criteria
Document what modifications needed to be made (example the Sales order
has line numbers 1,2,3,4 and the 860 transaction uses a,b,c,d)
3) 860's that are rejected (no associated 850, closed SO, S0 beyond the
point of no return (built, picked, packed, or shipped depending on the business
process rules governing sales order changes)
Let's assume that 80% of the 860-transactions fall into group 1, 10% fall into
group 2, and 10% fall into group 3.
In addition you will want to document the transactions into these 3 groups for
use in the design phase of the initiative if you get that far.
.
1) 860's that include all of the information in the originating 850 with
the changes incorporated
2) 860's that have only the changed information.
3) 860's that don't fall into group 1 or 2. An example would be an 860
that completely changes the original 850 and the business decides that it is
better to cancel the original order and create a brand new one.
Now that we have the metrics we have to do the math. 860's that can be
processed electronically are those in groups 1 and 3, group 1 meets the
criteria and a sales order acknowledgement needs to be transmitted to the
customer documenting the acceptance of the change and group 3 are rejected and
a rejection notice has to be transmitted to the customer. These two groups can
be dealt with programmatically
Group 2 contains the 860's that need to be modified to meet the acceptance
criteria this can often times be done programmatically utilizing a rules based
EAI (Enterprise Application Integration) process. For those changes that cannot
be processed programmatically an exception report needs to be created and
provide to the responsible human.
This process is referred to as management by exception. So now we have all the
data we need to make a viable decision on what is the best way to move forward.
Currently it costs $121,875 to process these changes. We know that 90% of the
860 transactions can be dealt with programmatically (meets criteria or
rejected) and let's say that 50% of the 860's that need modifications to meet
the criteria can also be done programmatically. So now 95% of the 860
transactions have been processed electronically without human intervention.
Upon implementation of an integrated process the cost savings per year would be
$115,791.25.
Now we have to determine how much it will cost to build the integration module,
test it, train the users on the new process and acquire any additional
materials. For our discussion we will have the following numbers.
1) Research 10hrs/week for 26 weeks @ $25/hr = 260 * 25 = $6,500
2) Design, build and test interface module - 320 hours @ $60.00/hr =
$19,200
3) Training - 16 hours @ $60.00/hr. = $960
4) EDI Mapping and testing tasks 160 hours @ $60/hr = $9,600
This brings us a grand total of $36,260 to implement the integrated exception
managed 860 process with an ROI of approximately 90 days and you are in a
position to re-task the current resources to other endeavors.
Obviously these numbers are for educational purposes only, your numbers may be
different.
If you think this is a pain try integrating the 830/862 transaction combination
for automotive replenshment changes.
Jim
--- In [email protected], David Frenkel <frenkel@...> wrote:
>
> Don't forget your friends in telcom who use the 860 for their unique purposes.
> http://www.atis.org/obf/docs/esoc/edi/sosc/elms4/elms4860.pdf
>
>
> David FrenkelÂ
>
>
>
>
> ________________________________
> From: Michael Mattias/LS <mcmlserve@...>
> To: EDI-L <[email protected]>
> Sent: Tuesday, November 29, 2011 3:06 PM
> Subject: Fw: [EDI-L] Re: EDI Software and handling the 860 (PO Change)
> business process
>
>
> Â
> 11/29/11
>
> FWIW, this is a reasonable thing in my client's operation... "processing
> inbound orders" - the ones which are not canceled -
> results in immediate preparation of master pick lists, shipping labels, FedEx
> manifests, customer-logoed packing slips (these are
> all drop-ship orders) , generation of order acknowledgments (ANSI '855') and
> allocation of inventory.
>
> Total elapsed time between "start processing orders" and all this stuff being
> completed? Maybe 10 minutes depending on volume.
>
> That is, it really is true that an order reaches a "not possible to cancel"
> status quite quickly!
>
> Michael C. Mattias
> Tal Systems Inc.
> Racine WI
> mmattias@...
>
> > Just for the heck of it, but not "generally" applicable...
> >
> > I have one client who has a customer who *frequently" uses the '860' to
> > cancel an '850 PO'....
> >
> > We only pick up mail from this customer once per day and it's not unusual
> > that the same "batch" of inbound documents will contain
> > both the '850' ("please enter our order for...") *AND* the 860 (" never
> > mind that order I sent earlier").
> >
> > What I do is scan the inbound 'batch' and delete any '850' for which I find
> > a cancelation '860'
> >
> > What my client (the seller) did is make a business rule that says "if you
> > have not sent the cancelation by the time we process
> > purchase orders each day at <whatever time it is> , we cannot accept a
> > cancelation of that order."
> >
> > It works in this trading relationship. YMMV.
> >
> > Michael C. Mattias
> > Tal Systems Inc.
> > Racine WI
> > mmattias@...
>
>
>
>
> [Non-text portions of this message have been removed]
>
------------------------------------
...
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work: <JOBS> IS
REQUIRED in the subject line as a prefix.Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/EDI-L/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
