On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow < [email protected]> wrote:
> > One important part I'll have to work out is how to handle the inspection > department mentioned in the previous post. I think inspections can be > handled as separate production runs just like normal ticket movements. The > main difference between the inspection and manufacturing dept tickets is > that inspection dept has the ability to split a manufacturing ticket into > different quantities destined for different locations. I think this can be > handled with the WorkEffortAssoc entity. Inspection users currently select > ticketIds from a list to be inspected. I guess the ticketIds in this case > would be served by workEffortId of the previous production run. > This would have to be flexible, as different manufacturers will have different protocols. My father worked all his life in quality control, just down the hall from the engineer's labs responsible for designing new products. For any given product, there were sometimes multiple protocols, all of which would be used for a given assembly line. Each would be used on a random sample of the products coming off the line, and in some of their facilities, there'd be an extra protocol applied to every unit coming off the line. One protocol involved something like function or integration tests. Depending on the facility, and how paranoid about quality the facility's manger was, this would either be applied to a large random sample, or to all, of the units coming off the line. A second, including tests of each component in the unit in addition to the tests in the first protocol, would be applied to a much smaller, but independent, random sample. Please note, a sample generally had a minimum size of 100 units. In the most recent configuration of that company's QA infrastructure, the assembly lines was not started for a batch of less than 100,000 units, and they actually had a computer on the end of the assembly line which performed all the required tests. That is to say, every unit coming off those assembly lines was subjected to at least one suite of tests. And there were other protocols also, but I was too young at the time to remember much else. But I do know my father would say that the QA testing was not a separate process from the manufacturing process, but an integral part of it. On the other hand, my brother worked in a company that had it's own machine shop, and that shop would have to gear up to make a single unit (which of course would be tested thoroughly), because it was needed to permit another department in the same company repair an insanely expensive piece of equipment, the parts of which had not been made in decades. These techs had the product specs on file, and so, using modern equipment, made 'obsolete' parts to spec, so that the supported old pieces of equipment could have a few extra years of life; and they had to do it to perfection since a failure could cost lives. I would expect that there would be seemingly countless variants between these two extremes. I suppose, the question becomes how best to model QA in such a way that it supports the many varied QA protocols that may be encountered. Is the production run adequate, or can you derived from it something more flexible? I have not studied the code you're working with, or the books to which you referred, but from the perspective of an end user, in the place of either my father or brother, I would look for something that was flexible enough to support either of the cases I described above. Let me ask you, do you think what you have in mind is flexible enough to handle such edge cases, and if so, how? Cheers Ted
