Hallo,
wer weiss, was Prozessorientierung nach der neuen Iso 9000:2000 bedeuten soll ? Wie ändern sich die Prozessabläufe für die Unternehmen ? Welche grundlegenden Neuigkeiten sind zu beachten ?
DANKE !!!
Gruss Markus
Hallo Marcus,
die Antworten auf Deine Fragen wären zu umfangreich.
Vielleicht schuast Du mal unter: www.dqs.de nach, oder besuchst ein Seminar zu diesem Thema, z.B. von der DGQ.
Viele Grüße
Hasenschnitte
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Markus,
ich hoffe nicht, daß ihr die Prozessabläufe in eurem Unternehmen wegen der neuen Norm ändern wollt!!! Maximal solltet ihr die Struktur der Dokumentation ändern. Aber ich denke, das hast Du auch gemeint.
Nach der 94’er waren die QM-Dokumentationen oft an den 20 Elementen (Graus!!) orientiert. Viele habe aber auch schon prozeßorientiert dokumentiert und sich zwecks Konformitätsprüfung eine „Zuweisungsmatrix“ (Mega-Graus!!) gebastelt, die die Doku den 20 Elementen zusortiert hat.
Eine prozeßorientierte Doku orientiert sich schlicht am chronologischen oder kausalen Ablauf der Prozesse im Unternehen. Grob ist das: Marketing - Vertrieb - Arbeitsvorbereitung - Produktion - Auslieferung/Installation/Inbetriebnahme - Aftersales-Betreuung
Das läßt sich weiter aufgliedern (z.B. Vertrieb):
Erstkontakt - Präsentation - Angebotserstellung - Angebotsprüfung - Angebotsversand - Angebotsänderung - (…) - Bestelleingang - Prüfung mit Angebot - Auftragsbestätigung - Übergabe an Arbeitsvorbereitung
Und so weiter. Ausführlich genug? Hilfreich?
t:o)m
Zusatzfrage Prozessorientierung
Hallo Thomas
Deine Interpretation von prozessorientiert kann ich
nachvollziehen, das macht für mich Sinn.
Ich befinde mich gerade in einer Abwehrschlacht gegen einige
Hardliner, die nur mehr Prozesse sehen wollen. Bei der
wertschöpfenden Produktion/Dienstleistung begrüße ich den
Prozessansatz, aber es gibt das ganze systemerhaltende
Drumherum, bei dem ich einfach keine sinnvollen Prozesse sehen
kann:
Den „EDV-Prozess“ zum Beispiel, in dem Regeln zum geordneten
Abspeichern und Archivieren von Daten festgelegt werden,
Passwordvereinbarungen getroffen werden und was sonst noch zur
Absicherung des Know-How relevant ist. Ebenso den
„Informationsprozess“, bei dem Regeln über die sinnvolle
Verteilung (Hauspost, Emails, neu erlerntes aus Kursen bis hin
zu zufällig bei Kunden aufgeschnappten Informationen) und für
jeden Betroffenen leicht zugänglichen Ablage von Informationen
getroffen werden.
Wo soll man da sinnvoll was in Richtung „aus einem Input wird
geordnet ein Output“ definieren, messen, bewerten und so weiter,
wenn man potentielle Anforderungen berücksichtigen muss, die
vielleicht nie eintreffen (Zum Glück wird ja nicht aus jeder
Dienstleistung ein Produkthaftungsfall, und die bei der
Datensicherungen streben wir 100% und nicht weniger an - bislang
klppt es auch noch)
Wie gehst du damit um, muss wirklich alles heute Prozess sein?
föhn-x
Hallo Föhn-x,
das ist mal eine gute Frage. Das weiß ich auch nicht. Zweifellos kann man auf Biegen und Brechen Ein- und Ausgaben eines EDV-Prozesses definieren z.B. ähnlich F&E kann man explizite, implizite und sonstige vorausgesetzte Anforderungen definieren und deren Erfüllung durch die vorhandene EDV prüfen. Allerdings will sich das ums verrecken nicht so richtig in die Wertschöpfungskette einsortieren lassen.
Es gibt ja noch mehr derartige unterstützende „Prozesse“.(Systemerhaltend ist übrigens eine sehr gut Vokabel! Darf ich die verwenden?)
Meine Privatmeinung ist, daß diese Dinge, die die gesamte Wertschöpfungskette begleiten (also keine klar begrenzten Schnittstellen mit definierten Übergaben mit der Kette haben), nicht wirklich „Prozesse“ sind. Die Norm hat ja in dem hübschen Prozeßbildchen am Anfang auch so ihre Probleme, diese Dinge grafisch unterzubringen.
Ich handhabe es so: Es gibt eine mehr oder weniger unverzweigte Kette der Prozesse, die sich toll grafisch darstellen lassen. Alles andere gebe ich zwar als „Prozesse“ an, beschreibe es aber in den entsprechenden VAen wie gehabt. Wenn ich mich da dem „extremely prozeßorientiering“ hingeben würde, würde ich mir für’s Audit doch mehr Probleme schaffen, als ich löse!
Meine Philosophie heißt: Sinnvoll! Und wenn ich EDV nicht sinnvoll als Prozeß abbilden kann, dann lasse ich es einfach bleiben.
Was ich geschrieben habe, ist natürlich (wie immer) nur meine Meinung und keine Wahrheit. Ich würde mich freuen, wenn ich dazu noch andere, gerne konträre (schreibt man das so?) Stimmen lesen könnte.
t:o)m
1 Like
Hallo Tom,
so ganz bin ich mit Deiner Meinung nicht einverstanden.
In ISO 9000:2000 ist „Prozess“ definiert als „Satz von in Wechselbeziehung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt“. Unter diese Definition passt sicherlich auch das Kaffeekochen in der Büro-Kaffee-Küche.
Das Problem, das viele mit der totalen Prozessorientierung haben (und das ich offen gestanden auch noch nicht vollständig gelöst habe), ist der Widerspruch zwischen Prozessorientierung und Abteilungsdenken. So besitzen die meisten Unternehmen eine EDV-Abteilung, die sicherlich eine Vielzahl von Prozessen handelt.
Wenn Du die Abteilung EDV ´mal gedanklich ausblendest und zum Beispiel nur den Prozess „Datensicherung“ anschaust, wirst Du diesen Prozess sicherlich in viele übergeordnete Prozesse (wie „Projektdokumentation“) einbauen können. Insofern kann konsequente Prozessorientierung auch dazu beitragen, Vorgänge aufzuspüren, die nicht wertschöpfend sind und auch keine wertschöpfenden Prozesse unterstützen.
Frank
Hallo Tom!
Zuallererst:
(Systemerhaltend ist übrigens eine sehr gut
Vokabel! Darf ich die verwenden?)
hab´ ich in meiner bundesheerzeit geklaut, möchtest du wegen dem
copyright die email-adresse von unserem
verteidigungsministerium?
Meine Privatmeinung ist, daß …
Alles andere gebe ich zwar als „Prozesse“
an, beschreibe es aber in den entsprechenden VAen wie gehabt.
Wenn ich mich da dem „extremely prozeßorientiering“ hingeben
würde, würde ich mir für’s Audit doch mehr Probleme schaffen,
als ich löse!
ich sehe dass genauso, und hab es bisher auch so gehalten. auch
dass ich mich konsequent weigere, überhaupt was für den auditor
allein zu tun. wenn er was zusätzlich zu meiner
norminterpretation will, soll er mir die sinnhaftigkeit für
unser unternehmen erst mal näherbringen oder zweifelsfrei
darlegen, dass das die norm wirklich fordert.
wir haben gerade einen personalwechsel bei auditors, und das
vorgespräch hat mich alarmiert, zusätzliche argumente zu
sammeln.
Was ich geschrieben habe, ist natürlich (wie immer) nur meine
Meinung und keine Wahrheit. Ich würde mich freuen, wenn ich
dazu noch andere, gerne konträre (schreibt man das so?)
Stimmen lesen könnte.
frei nach dem neuesten testament: „was ist wahrheit?“ - und seit
wann interessiert sowas auditor?
„konträre“: weiß ich leider nicht, bin techniker mit einem
mittelschulzertifikat über leichte legastenie, kein germanist,
gefühlsmäßig sieht das aber gut aus.
deinem frommen wunsch schließe ich mich aber an.
warum ist die welt so kompliziert: immer, wenn ich jemand in
diesen dingen verstehe, sagt er, er weiß es selber nicht so ganz
genau, und wenn ich mit jemand verhandle, der sagt, er weiß es,
dann versteh´ ich ihn nicht?
jedenfalls schönen dank für die erkenntnis, dass ich kein
einzelfall bin
föhn-x
Hallo Frank
In ISO 9000:2000 ist „Prozess“ definiert als „Satz von in
Wechselbeziehung stehenden Tätigkeiten, der Eingaben in
Ergebnisse umwandelt“. Unter diese Definition passt sicherlich
auch das Kaffeekochen in der Büro-Kaffee-Küche.
Das mit dem Kaffee wäre zweifelsfrei eine Überlegung wert, der
gehört schon längst qualitätsgemanaged.
Weil ich den Tom da in eine Aussage hineingeritten habe, fühle
ich ein wenig die Verpflichtung, da Ordnung zu schaffen:
Das Problem, das viele mit der totalen Prozessorientierung
haben (und das ich offen gestanden auch noch nicht vollständig
gelöst habe), ist der Widerspruch zwischen Prozessorientierung
und Abteilungsdenken. So besitzen die meisten Unternehmen eine
EDV-Abteilung, die sicherlich eine Vielzahl von Prozessen
handelt.
Es ist nicht um das Abteilungsdenken gegangen (Wir haben sowas
nicht mal, nur einen Administrator, dem diese Regelungen eher
Wurst sind, solange wir sein System nicht durcheinander
bringen), sondern um die schlichten Vereinbarungen „Wie legen
die einzelnen Abteilungen Daten ab, so dass sie einerseits von
allen Projektmitarbeitern leicht gefunden werden, und
andererseits nicht verlorengehen? Wie wird das dann archiviert
etc.“ (Ich arbeite in einem Planungs- und Beratungsunternehmen,
der Computer ist unser wichtigstes Werkzeug, und wir haben eine
reichhaltige Regelsammlung, wo was wie von wem und unter welchem
Namen zu speichern ist. Anmerkung: Wir haben uns einen
Standard für das Projektmanagement einfallen lassen, also einen
Prozess, mit dem wir alle unterschiedlichen, stets
auftragsbezogenen Kundenanforderungen unter einen Hut
bringen).
Ich stehe da vor der Wahl, rund 70 EDV-Subprozesse zu
definieren, oder einfach zu sagen: in der Abteilung
(Architektur, Planung, Bauaufsicht, behördlicher Einreichungen,
Rechtberatung, Beratung zum Thema Integrierte Managementsysteme,
Arbeitssicherheit, Software) gelten diese Regeln und Schluss.
Jeder hat da seine, zum Teil vom Gesetzgeber vorgeschriebenen
Ideen, wie sowas gehen muss. Die Anforderungen niederschreiben,
gut. Aber wie den/die Prozess/e sauber definieren und überwachen
(bitte Herr QM, bei den Elektroplanern hat schon wieder der
Maier ein Verhandlungsprotokoll nicht unter dem vereinbarten
Namen abgespeichert! Bitte Herr QM, der Huber hat schon wieder
eine Outlookpräsentation nur in seinem Projektordner
gespeichert, und nicht wie vereinbart auch im Verzeichnis
Präsentationen. Letzteres kann ich nicht mal mehr überwachen, da
müsste ich alle Projektverzeichnisse (ca. 2000 pro Jahr) darauf
untersuchen, ob nicht was dabei ist, das eventuell als
Allgemeingut nützlich wäre),
Regeln vorschreiben, ohne gleich einen „Prozess“ zu unterstellen
ist daher für mich sinnvoll.
oder, um extrem zu werden: wir haben Regelungen festgelegt, was
passieren muss, wenn jemand in Urlaub geht (Stellvertreter, in
die wichtigen Projekte eingewiesen, Notfalltelefonnummern
hinterlassen etc.)
Muss ich da wirklich einen Urlaubsprozess definieren, eventuell
noch messen, wie gut das funktionniert (Also den Mitarbeiter
stichprobenartig anrufen und schauen, ob sich wer meldet)??
Tschuldigung, wenn das jetzt wirklich verdammt lang war, aber
ich steh mitten in der Auditabwehrschlacht, und die Argumente
wurden den ganzen Tag durchgekaut.
gruß
föhn-x