On Thursday, May 17, 2012 3:54:44 PM UTC-4, Cliff wrote: > > Let's inject manufacturing into the order processing scenario you were > using before. It's a three step process. Step one fabricates widgets. > Step 2 attaches the widgets to widget bicarackets, purchased from another > vendor. Step 3 packages the assemblies for shipment. > > If the last batch of widgets from the fabricator won't fit the brackets > because they are oversize, obviously the guy in assembly wants to send them > back for rework. How would the system handle this? >
In this case, assembly would reject their step, and enter a short message to explain why they rejected it. Assembly would also select a previous step in the workflow to send it back to, in this case the fabricator (step 1). The message from assembly goes into the workflow_comments table as needing to be resolved. Once the fabricator fixes the problem, they mark the problem resolved and send the workflow on to the next step (which in this case would be to step 2). > > And how would it avoid forcing the guy in charge of assembly to take > action on every batch of good widgets, assuming the system's intent is to > manage by exception? > Let's say the guy in assembly has 5 work orders to assemble for the day and each work order makes 20 assemblies (for a total of 100 things to make for the day). He would come in with the parts waiting for him for all 5 work orders, and he would have 5 workflows waiting on him. When he completes one work order (20 assemblies), he marks that workflow as completed and the workflow moves on to the shipping department. If we wanted, we could even add a "progress" field that allows him to enter a percentage of how close he is finishing the 20 assemblies for the one work order. The great thing about doing it this way is allows management to track where everything thing is. My implementation puts an emphasis on accountability and making sure nothing gets lost or forgotten. Most manufacturing places have computers on the floor, so asking the assembly guy to click a button isn't a stretch for most places. In fact, by making this whole implementation generic like this, you could even put a simple keypad out there in assembly, shipping, and other places that don't have full computers to manage workflows. Nothing about the implementation forces you to use a GUI. You could program a keypad to accept a work order number that marks the associated workflow as complete via a REST call or something. And worst case, you could always have the assembly supervisor handle the workflows for the guys in assembly. That's what supervisors are for, right? :)
