Just last week, a product line stopped completely because parts had been removed from stores by production personnel who failed to notify the inventory control team they were taking them. No requisition, no traceability, nothing. When the parts ran out and no additional parts had been ordered, the President of the company went after the Materials Manager for failing to order parts removed from stores without her knowledge.
Now that's relevant data and a good example.
change will come over time.
Yes, you're right. Changes of culture don't happen overnight, but they do and will happen with a better system, which demonstrates to the people concerned how different it can be when there's a half-way decent system in place (or even just something better than nothing!).
As Andy said:
It appears you've already identified some reasons for it - the stoppage of the line, is a great example. What you might have to do is start to gather some data on how often this happens, a log or similar. Then you can attempt to put a cost to that disruption, premium paid on getting parts/materials etc. Once you have that, the reasons for installing an inventory control system should be pretty obvious. (If you have to use a requirement of ISO to help you, 7.2.2 is the closest)
I wouldn't say the inventory control system isn't 'technically required', rather I'd say it isn't an
explicit requirement and that the reason it isn't is because 9001 is a generic standard - ie, it says what (but not how) AND it is deliberately intended to be applicable to all organisations and
not just manufacturing ones. I know this can be a bit hard to remember for those steeped in MF environments, but as an example, if it was an explicit requirement, the nice architectural practice I was meeting with yesterday would have been scratching their heads and giving me this look:
As in, Jane, are you telling us we have to have some system to control our drawing pencils and paper supplies in order to get ISO 9001? Why? (See what I mean?)
Nothing seems to work quite as well as using existing data to justify change. When "we've always done it this way" becomes a liability, change can begin.
Yes indeedy.
Incidentally, I'd be using this as a fine example of teachnig them something about the inter-relatedness of the Standard, such as:
5.3: Actually following their Quality policy (not just paying lip service) - if it's the right policy, it'll have something in it about meeting customer requirements, and you can't do that (eg, time deadline) with production lines stopping or being held up
5.4.1 Quality objectives: again, if they have the right ones, such a lack of an ICS will negatively impact those
And yes, I like 7.2.2 (as Andy already quoted) - how can they argue that they are meeting clause c)?? They can't!
And re. that President going after... I'd take a good look at 5.5.1. Sounds like responsibilities &
authorities aren't clearly delineated. And nothing but nothing is more difficult than having the responsibility for something (eg, to maintain inventory) but not the corresponding
authority.
