OT? ISO9000 -- The Big Picture

On 2 Sep, 17:28, DSP-Newbie <N...@way.invalid> wrote:
> Rune Allnor wrote:
> > Client: "On what grounds did you bid fro the contract?
> > You stated that you were able to deliver commodity
> > which pass test X in time frame Y. You are an ISO
> > certified company. If you claim that you could meet
> > the contract, you will have a set of procedures to
> > that effect. Let's have a look at them."
>
> When entering ISO9000, it is of the utmost importance to very, very
> carefully think about the figures you'll be stating. It would be
> completely insane to mention "guaranteed" delivery times.

The newspaper example has already been mentioned, in
other businesses the turn-around is fast enough that it makes
sense to specify a time for delivery. These rules are to
be applied with reason. If the newspapers are specified to
be delivered at a specific newsstand at 8 AM but arrives at
8.05 AM, that may or may not be acceptable, depending
on how many potential buyers pass by the stand between
8 and 8.05. If the newspapers arrive the next day, it is
unacceptable, no matter what.

The force of ISO is that if the newspapers consistently arrive
at 8.05 and the newsagent looses a lot of sales to the
commuters on the 8.04 train, the distributor has a tool
to check ot what goes wrong. Can the newsstands be
served in a different order? Does the truck driver drive
the quickest way? Or does he visit his mistress while
on tour?

The documents state how things are supposed to be done.
If things are not done that way, the execution of the method
must change. If things are done as stated, the method must
change. It's as simple as that. In principle.

> A client looking into a manufacturer's internal 9600 procedures? Forget
> it, the competetion might be listening in...

One can get very far without getting into the sensitive details:

- There *is* a procedure / plan in place. Right...?
- The plan has stated certain delivery parameters;
e.g. prior conditions needed to secure a for fluent
production, target volume delivered per time unit, etc.
- Are these conditions / targets met?
- The plan is known to everyone who need to know
- The plan has been implemented
- The plan has been executed

Using only this seemingly superficial level, one can
put some serious pressure on amateurs. The pros
will have no problem dealing with these sorts of
inquiries, nor would they have any problems reviewing
their existing procedures and plans to handle
problems.

There is a proverb attributed to Eisenhower, which in my
twisted memory is something like: "The value of plans
is not in the documents but in the planning."

Rune

On 2 Sep, 20:20, DSP-Newbie <N...@way.invalid> wrote:
> Peter K. wrote:
> > DSP-Newbie <N...@way.invalid> writes:
>
> >> When entering ISO9000, it is of the utmost importance to very, very
> >> carefully think about the figures you'll be stating. It would be
> >> completely insane to mention "guaranteed" delivery times.
>
> > One thing that customers usually (always?) appreciate is on-time
> > delivery.
>
> Sure, but how can this be specified in an ISO9000-context??
> "Delivery will take place at noon, on the Nth working day after receipt
> of order"? What if a severe blizzard/hurricane/whatever makes
> transportation by road/rail/air impossible?

That's a "force majeur" which has to be dealt with when it
happens. Unless you live in a part of the world where these
sorts of things are more ordinary, in which case one need
to plan for the possibility.

> A factory producing steel bearing balls OTOH, could specify that:
> "99.0 % of balls produced will have a diameter within 0.001 mm of
> specification". The customer knows he can expect 1% outliers.

So what? What prevents that there are 0.1% outliers?

> Rule #1 in ISO9000: do not specify requirements that cannot be met (all
> of the time) or you will be in deep trouble.

Nope. That's rule #1 of writing contracts. The difference is that
a contract is between two involved parties, while ISO in addition
is overlooked by a (supposedly) independnet 3rd party. Hence,
it's far more difficult to get away with sloppy work if you become
subject to an impartial audit...

Rune

>ISO9000 was intended as a tool to ensure that
>managment has a clue what is going on in the
>company.

I think something is wrong if management always needs a clue.. why don't
they come directly and look into real issues and suggests something
good.Technical things don't care what management thinks about them.The
hardware + the software in it form a system and it is a diferent entity
with its own rules.What ISO does to understand the system?


>> The main reason for companies to implement ISO9000 was/is to be ahead
>> of the competition: "We are ISO9000-certified, thus we make a better
>> product". Untrue of course, but its a strong marketing argument...-

I fail to understand how ISO guarantees quality?


>At some point quality *was* a marketing issue and a
>competitive point. Not so anymore, because companies
>in a true competition who do *not* make quality
>products will die. These days, if you want to play,
>you have to make a quality product. Or somebody
>else will, and take your customers away from you.
>

Right, customer is , weel , God.

now , use six sigma instead.
Being a six sigma green belt, here is my thought about it.
If the "sense of quality" is put on black and white the bullet points
would be, in my opinion,

1) The system has to pass the corner case tests.( use design of
experiments in six sigma)
2) In case of trade off favor the practical cases rather pathological
cases.
3) find root cause by fish diagrams and solve real issues.
4) the spread of output should be very close to mean.
5) In case the present technology can not satisfy the requirement go for
new technology/algorithm.

My point is six sigma atleast promotes these concepts which are more
practical the ISO which assumes software development is nothing more than
factory assemby line.
Ha Ha Ha !!

Rune Allnor <allnor@tele.ntnu.no> writes:

> Hi all.
>
> I am a bit curious about the ISO9000 system. Having
> been involved with various companies and organizations
> inside and outside the ISO9000 system over the past 20
> years, I find that the ISO9000 system -- if used and utilized
> correctly -- is a huge asset to everybody:
>
> - To the client, since he has a tool to demand that procedures
> are established prior to a job, and thus can demand
> them to be reviewed and revised if and when necessary
> - To managment, since they have a tool to give them the
> full picture of what goes on in their company
> - To the staff, since they have a tool to see if management
> do their job.
>
> Now, those are my very personal views. I would like to
> see some book "ISO9000 for engineers" or something like
> that, to give the broader picture of exactly what ISO9000
> is all about.

In my opinion, how a contractor operates should be irrelevent to a
client. The important thing for the client is that the contractor
deliver product of the specified requirements on time. Period.

Within an organization (or "contractor"), I think, and it has been my
experience, that ISO9000 is so extremely inefficient, and overburdens
the company so much that it is worse than useless - it actually costs
a company a great deal more than it returns.

If I had a company I would run like hell from ISO 9000. However, I
might take a couple of high level, good ideas, like how to close the
loop around important processes.
--
% Randy Yates % "Rollin' and riding and slippin' and
%% Fuquay-Varina, NC % sliding, it's magic."
%%% 919-577-9882 %
%%%% <yates@ieee.org> % 'Living' Thing', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

On 3 Sep, 15:44, Randy Yates <ya...@ieee.org> wrote:
> Rune Allnor <all...@tele.ntnu.no> writes:
> > Hi all.
>
> > I am a bit curious about the ISO9000 system. Having
> > been involved with various companies and organizations
> > inside and outside the ISO9000 system over the past 20
> > years, I find that the ISO9000 system -- if used and utilized
> > correctly -- is a huge asset to everybody:
>
> > - To the client, since he has a tool to demand that procedures
> > are established prior to a job, and thus can demand
> > them to be reviewed and revised if and when necessary
> > - To managment, since they have a tool to give them the
> > full picture of what goes on in their company
> > - To the staff, since they have a tool to see if management
> > do their job.
>
> > Now, those are my very personal views. I would like to
> > see some book "ISO9000 for engineers" or something like
> > that, to give the broader picture of exactly what ISO9000
> > is all about.
>
> In my opinion, how a contractor operates should be irrelevent to a
> client. The important thing for the client is that the contractor
> deliver product of the specified requirements on time. Period.

Sure. But how do you as client deal with the situation
when -- not if -- you understand that the contractor is
unable to deliver to spec on time? What are your "power
tools"? What does it take before you use them?

Rune

"pal.debabrata123" <pal.debabrata123@gmail.com> writes:

> My point is six sigma atleast promotes these concepts which are more
> practical the ISO which assumes software development is nothing more than
> factory assemby line.

It seems you don't understand ISO9000 at all.

ISO9000, in essence, says:

1. Write down what you do.
2. Measure what you do.
3. Improve the measurements.

ISO9000 certainly can be implemented as you suggest; that just means
the company that implemented it didn't understand either how to make
software or how they make software.

As someone else said, be very careful with what you write down (step
1).

Ciao,

Peter K.

--
"And he sees the vision splendid
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Rune Allnor <allnor@tele.ntnu.no> writes:

> On 3 Sep, 15:44, Randy Yates <ya...@ieee.org> wrote:
>> Rune Allnor <all...@tele.ntnu.no> writes:
>> > Hi all.
>>
>> > I am a bit curious about the ISO9000 system. Having
>> > been involved with various companies and organizations
>> > inside and outside the ISO9000 system over the past 20
>> > years, I find that the ISO9000 system -- if used and utilized
>> > correctly -- is a huge asset to everybody:
>>
>> > - To the client, since he has a tool to demand that procedures
>> > are established prior to a job, and thus can demand
>> > them to be reviewed and revised if and when necessary
>> > - To managment, since they have a tool to give them the
>> > full picture of what goes on in their company
>> > - To the staff, since they have a tool to see if management
>> > do their job.
>>
>> > Now, those are my very personal views. I would like to
>> > see some book "ISO9000 for engineers" or something like
>> > that, to give the broader picture of exactly what ISO9000
>> > is all about.
>>
>> In my opinion, how a contractor operates should be irrelevent to a
>> client. The important thing for the client is that the contractor
>> deliver product of the specified requirements on time. Period.
>
> Sure. But how do you as client deal with the situation
> when -- not if -- you understand that the contractor is
> unable to deliver to spec on time? What are your "power
> tools"? What does it take before you use them?

To me it is a simple matter: If you are using a new contractor
for the first time, then make the first delivery short and simple.
If they deliver this on-time and to-spec, then you've established
some confidence. Wash and repeat.
--
% Randy Yates % "So now it's getting late,
%% Fuquay-Varina, NC % and those who hesitate
%%% 919-577-9882 % got no one..."
%%%% <yates@ieee.org> % 'Waterfall', *Face The Music*, ELO
http://home.earthlink.net/~yatescr

On 3 Sep, 17:11, Randy Yates <ya...@ieee.org> wrote:
> Rune Allnor <all...@tele.ntnu.no> writes:
> > On 3 Sep, 15:44, Randy Yates <ya...@ieee.org> wrote:
> >> Rune Allnor <all...@tele.ntnu.no> writes:
> >> > Hi all.
>
> >> > I am a bit curious about the ISO9000 system. Having
> >> > been involved with various companies and organizations
> >> > inside and outside the ISO9000 system over the past 20
> >> > years, I find that the ISO9000 system -- if used and utilized
> >> > correctly -- is a huge asset to everybody:
>
> >> > - To the client, since he has a tool to demand that procedures
> >> > are established prior to a job, and thus can demand
> >> > them to be reviewed and revised if and when necessary
> >> > - To managment, since they have a tool to give them the
> >> > full picture of what goes on in their company
> >> > - To the staff, since they have a tool to see if management
> >> > do their job.
>
> >> > Now, those are my very personal views. I would like to
> >> > see some book "ISO9000 for engineers" or something like
> >> > that, to give the broader picture of exactly what ISO9000
> >> > is all about.
>
> >> In my opinion, how a contractor operates should be irrelevent to a
> >> client. The important thing for the client is that the contractor
> >> deliver product of the specified requirements on time. Period.
>
> > Sure. But how do you as client deal with the situation
> > when -- not if -- you understand that the contractor is
> > unable to deliver to spec on time? What are your "power
> > tools"? What does it take before you use them?
>
> To me it is a simple matter: If you are using a new contractor
> for the first time, then make the first delivery short and simple.
> If they deliver this on-time and to-spec, then you've established
> some confidence. Wash and repeat.

OK, that establishes the cooperation. But some time
the contractor takes on more than he can deliver -- all it
takes is to hire a new sales manager or CEO.

Then what?

Rune

>"pal.debabrata123" <pal.debabrata123@gmail.com> writes:
>
>> My point is six sigma atleast promotes these concepts which are more
>> practical the ISO which assumes software development is nothing more
than
>> factory assemby line.
>
>It seems you don't understand ISO9000 at all.
>
>ISO9000, in essence, says:
>
>1. Write down what you do.
>2. Measure what you do.
>3. Improve the measurements.

Great, but "improving the measurement" is nothing but the process of
testing, but how do I improve the things which are being tested, the
devices under test( DUT) ?


>ISO9000 certainly can be implemented as you suggest; that just means
>the company that implemented it didn't understand either how to make
>software or how they make software.
>
>As someone else said, be very careful with what you write down (step
>1).
>
>Ciao,
>
>Peter K.
>
>--
>"And he sees the vision splendid
>of the sunlit plains extended
>And at night the wondrous glory of the everlasting stars."
>
>
>

On Mon, 03 Sep 2007 09:44:51 -0400, Randy Yates <yates@ieee.org>
wrote:

>Rune Allnor <allnor@tele.ntnu.no> writes:
>
>> Hi all.
>>
>> I am a bit curious about the ISO9000 system. Having
>> been involved with various companies and organizations
>> inside and outside the ISO9000 system over the past 20
>> years, I find that the ISO9000 system -- if used and utilized
>> correctly -- is a huge asset to everybody:
>>
>> - To the client, since he has a tool to demand that procedures
>> are established prior to a job, and thus can demand
>> them to be reviewed and revised if and when necessary
>> - To managment, since they have a tool to give them the
>> full picture of what goes on in their company
>> - To the staff, since they have a tool to see if management
>> do their job.
>>
>> Now, those are my very personal views. I would like to
>> see some book "ISO9000 for engineers" or something like
>> that, to give the broader picture of exactly what ISO9000
>> is all about.
>
>In my opinion, how a contractor operates should be irrelevent to a
>client. The important thing for the client is that the contractor
>deliver product of the specified requirements on time. Period.
>
>Within an organization (or "contractor"), I think, and it has been my
>experience, that ISO9000 is so extremely inefficient, and overburdens
>the company so much that it is worse than useless - it actually costs
>a company a great deal more than it returns.
>
>If I had a company I would run like hell from ISO 9000. However, I
>might take a couple of high level, good ideas, like how to close the
>loop around important processes.

A lot of companies don't bother with ISO9000 any more for exactly the
reasons you mention. When it was getting rolling many companies
pretty much had to become ISO9000 compliant because their customers
demanded it. Since it's become pretty clear that there's not a lot
of correlation between companies that don't have ISO9000 certification
and companies that produce crappy products (or however you want to
frame that statement), and because it is a bit counterproductive to
implement, it's not nearly as big a deal as it was for a while.

Kept a lot of consultants in business for a long time, tho...


Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org