One of the things I have noticed in recent posts is that there is a significant difference between posters based upon aspects such as company size and direction for the future. Many Mom & Pop operations are not out to conquor the world and become Micro$ofts. Many (most?) don't need complicated diagrams and business models. Most are already doing Corrective Actions and management review is a couple of people (sometimes family) who meet almost every day anyway. ISO pushes them into formal 'management reviews' and does nothing for the company. In many, many large companies management review is typically a sham to begin with.
I go along with what Randy and Mike are saying.
As far as the design review: The design review is unique and in the case of the Mom baker, it is probably in her head. I doubt she needs a documented procedure on what she goes through when someone calls and asks her to make something she has never made before. On the other hand, it's doubtful any of her customers give a flying pig whether they are ISO registered or not.
Jim, in your posts you are big business oriented with a level of 'pro ISO' which approaches religious blindness fervor. I was especially disappointed in the recent post regarding 'The Process Approach' as if it is something new and different. It isn't new - it is no more than a buzzword. Businesses have been using it for years. The positives you note I agree with. What I fail to find is a lack of 'The Process Approach' in almost all businesses. They may not have the diagrams you like and have come to expect, but that doesn't matter. In an earlier post you say:
The only difference is to realize there can be many 'views' of a company. A departmental view (departmental team) is just that - a localized view. That does not discount what usually already exists which is the interaction of each department with regard to inputs and outputs at a higher level (higher level teams). You discount the fact that many times a process view is a local view and that another, higher level process view may (and typically does) tie everything together. There can be many process views at many levels. Your paradigm simply doesn't allow for this and appears to assume that if one defines a process at a lower level and it does not encompass the whole company it is not sufficient.
Poppycock. I think this is overly simplistic, if not outright a totally a false premise not based upon fact. I do not believe managing from a 'process approach' is as rare as you apparently do. I remember a great Mac program named Stella from 1986 (It was a business simulator), which unfortunately is no longer, but there are a number of them out there now. In the 1980's I used process simulators which show interactions of processes at whatever level I wish to input. Heck, you should see the historical documents showing the use of the 'process approach' used by the US military in the Berlin airlift so many years ago, including how the 'process approach' allowed them to adjust for disruptions. It evolved by reacting to a 'corrective action' system whose outputs caused requisite systems changes and the airlift ended with an extremely fine tuned and efficient (given the circumstances and the amount of cargo which had to be moved) system.
For that matter, even we as individuals use a process approach in our every day lives if you think about it. Everything we do is, to some degree, a process. But I believe here you will depart on the basis of a definition of what a process approach is. I saw this in threads where you thoroughly defended a difference between a flow chart and a process diagram (if I remember correctly) based in part upon content (such as level of detail). Heck - they're both flow diagrams. Like with text procedures, there is no 'correct' content' or layout. Whatever works is fine for an individual or a company. One company has more detail than another but the one with less detail privides the details elsewhere or is significantly less complex. Too often strict definitions blurr what is important. Call it a flow diagram. Call it a process diagram. Call it whatever you like. If it represents what you are attempting to represent and has the appropriate detail for its function, whether within or without, you can call it a Strawberry Shortcake.
Sometimes I think there is an over emphasis on 'scholarly' thought - like over categorizing and over defining. Most consultants tend to do this but then most consultants are like preachers with a religious like fervor and an agenda. You tend to rigidity. I suggest flexibility. Where others attach documents in thread posts here, you put in a redirection to your site 'bin.co.uk' - your consultancy site (which I really do not particularly appreciate, by the way - you can share here as an attachment as others do with things like Mompop.doc) - for the 'hits' I suspect. Your rigidity would scare me off, but it probably sounds good to management of monolithic companies or companies in trouble.
Steve: Congrats on your manual. All that matters is that you can explain it and that your registrar approves it. Keep It Simple.
I go along with what Randy and Mike are saying.
As far as the design review: The design review is unique and in the case of the Mom baker, it is probably in her head. I doubt she needs a documented procedure on what she goes through when someone calls and asks her to make something she has never made before. On the other hand, it's doubtful any of her customers give a flying pig whether they are ISO registered or not.
Jim, in your posts you are big business oriented with a level of 'pro ISO' which approaches religious blindness fervor. I was especially disappointed in the recent post regarding 'The Process Approach' as if it is something new and different. It isn't new - it is no more than a buzzword. Businesses have been using it for years. The positives you note I agree with. What I fail to find is a lack of 'The Process Approach' in almost all businesses. They may not have the diagrams you like and have come to expect, but that doesn't matter. In an earlier post you say:
The only difference is to realize there can be many 'views' of a company. A departmental view (departmental team) is just that - a localized view. That does not discount what usually already exists which is the interaction of each department with regard to inputs and outputs at a higher level (higher level teams). You discount the fact that many times a process view is a local view and that another, higher level process view may (and typically does) tie everything together. There can be many process views at many levels. Your paradigm simply doesn't allow for this and appears to assume that if one defines a process at a lower level and it does not encompass the whole company it is not sufficient.
Poppycock. I think this is overly simplistic, if not outright a totally a false premise not based upon fact. I do not believe managing from a 'process approach' is as rare as you apparently do. I remember a great Mac program named Stella from 1986 (It was a business simulator), which unfortunately is no longer, but there are a number of them out there now. In the 1980's I used process simulators which show interactions of processes at whatever level I wish to input. Heck, you should see the historical documents showing the use of the 'process approach' used by the US military in the Berlin airlift so many years ago, including how the 'process approach' allowed them to adjust for disruptions. It evolved by reacting to a 'corrective action' system whose outputs caused requisite systems changes and the airlift ended with an extremely fine tuned and efficient (given the circumstances and the amount of cargo which had to be moved) system.
For that matter, even we as individuals use a process approach in our every day lives if you think about it. Everything we do is, to some degree, a process. But I believe here you will depart on the basis of a definition of what a process approach is. I saw this in threads where you thoroughly defended a difference between a flow chart and a process diagram (if I remember correctly) based in part upon content (such as level of detail). Heck - they're both flow diagrams. Like with text procedures, there is no 'correct' content' or layout. Whatever works is fine for an individual or a company. One company has more detail than another but the one with less detail privides the details elsewhere or is significantly less complex. Too often strict definitions blurr what is important. Call it a flow diagram. Call it a process diagram. Call it whatever you like. If it represents what you are attempting to represent and has the appropriate detail for its function, whether within or without, you can call it a Strawberry Shortcake.
Sometimes I think there is an over emphasis on 'scholarly' thought - like over categorizing and over defining. Most consultants tend to do this but then most consultants are like preachers with a religious like fervor and an agenda. You tend to rigidity. I suggest flexibility. Where others attach documents in thread posts here, you put in a redirection to your site 'bin.co.uk' - your consultancy site (which I really do not particularly appreciate, by the way - you can share here as an attachment as others do with things like Mompop.doc) - for the 'hits' I suspect. Your rigidity would scare me off, but it probably sounds good to management of monolithic companies or companies in trouble.
Steve: Congrats on your manual. All that matters is that you can explain it and that your registrar approves it. Keep It Simple.
I've been saying much the same thing for years. A SIPOC is another method of describing the overall process. As far as your comment that procedures and work instructions sound like the same (in ISOspeak), I've seen them used interchangeably. My quick way to differentiate them is to look at procedures as multiple tasks performed by multiple people, and a work instruction is typically a single task performed by a single person. Procedures are process oriented and work instructions are task oriented. 
