Engineering Changes

Änderungswesen (ECRequest und ECOrder)

Wikipedia
EC werden gehasst, wenn die Dokumentation die Überhand gewinnt ! 

Herausforderung

Ein sehr wichtiges, wenn nicht so gar das wichtigste Thema beim Zulieferer. Davon hängt der Profit, die Kundenzufriedenheit, die Anlaufperfomance , etc. ab. Leider wird recht viel Schindluder damit getrieben und es wird versucht, in einem EC System alles mögliche abzubilden, jedwede Personen ein zu beziehen, damit der EC ja nicht durch die Lappen geht bzw. etwas unter dem Tisch fällt. Hochkomplexe Systeme gibt es zu Hauf am Markt, aber sie sind wenig praxistauglich, weil immer wieder versucht wird, dem Ec Steller zu sagen, was zu tun ist. Dabei kann dies gar nicht gelingen, da die Welt der Änderungen so komplex ist, dass ein System zu komplex wird, um auch nur ansatzweise Änderungen ganzheitlich zu erfassen. Mit der Komplexität des Systems steigen natürlich auch die Widerstände, es anzuwenden. Selbst wenn diese überwunden sind, ist meist der Aufwand zu hoch und es dauert zu lange, um es einzupflegen, was ja wider der Natur von Änderungen ist. Also muss ein EC System möglichst einfach sein und sollte wenig Abfragen haben. 

Lösungsansätze

Zunächst einmal sollte klar sein, dass alle Änderungen ab einer bestimmten Phase kosten- und preisauswirkend sind, damit muss sich ein EC System zwangsläufig immer an den Kosten orientieren. Kommt nun ein Änderungsanfrage hinein, sollte Diese möglichst einfach durch den Antragsteller (welcher ja im Allgemeinen der Produktentwickler ist) ins System gegeben werden. Hier sollten gerade mal die Projektnummer, der Änderungsgrund und das Produkt verlangt werden, Datum der Anlage ist ja durch das System vorgegeben .... Alle weitere Angaben sind zu diesem Zeitpunkt zunächst einmal nicht nötig und sollten weggelassen werden. Dann greift ein hoch agiler Ansatz: der Ersteller entscheidet, welche Informationen er braucht und sucht sich sein Team zusammen, dass er braucht. Ziel ist es natürlich, ein Angebot an den Kunden zu erstellen ! Um damit ist auch klar, wo grundsätzlich jeder ECR endet, nämlich beim Account Manager, der dann entscheidet, ob er es dem Kunden anbieten kann sprich Geld dafür bekommt oder nicht ! Damit ist das vier Augen Prinzip gewährleistet und der Projektleiter hat nur noch die Aufgabe, die ECs in seinem Projekt zu verwalten und zu kontrollieren. 
Ist das Angebot nun raus, sollte auch nur der Accountmanager entscheiden, ob die Änderung jetzt gestartet wird oder nicht. Er löst damit direkt den ECO aus und übernimmt die Verantwortung für die Umsetzung der Änderung. Im allgemeinen wird er warten bis der Kunde bestellt oder er signalisiert, die Änderung durchzuführen. Auch sind dann eventuell noch weitere Schleifen zu fahren, wenn der Kunde dies nicht bezahlen möchte oder er noch Änderungen möchte. Praktibel erweist sich dann noch einen weiteren Schritt zu definieren und zwar den ECC (Confirmation), also den Termin, bei dem man dann die offizielle Kundenbestellung bekommt, als klar definiertes Datum für alle Beteiligten im Prozess.
Für den Fall, der Account manager sieht keine Chance, dies dem Kunden anzubieten, muss dann natürlich ein Senior Management Approval erfolgen, der auch abhängig und agil vom EC Ersteller gewählt werden muss, liegt eine Prozessänderung vor, so ist dies zb der Werksleiter als operativer Umsetzer, ist die Änderung aufgrund eines Design Fehlers entstanden, so sollte der Entwicklungsleiter freigegeben.
Abzusichern ist das Ganze durch entsprechende kommerzielle Grenzen des Ec‘ , zb wenn bestimmte Investitionsgrenzen überschritten sind oder der Teilepreis sich signifikant ändert. Diese Angaben sind in jedem Fall vor der Freigabe des Account Managers einzupflegen, sollten aber auch nicht gleich systemisch zu Anfang gefordert sein. Die Definition der Grenzen sollte auch variabel sein, z.B. Abhängig von der Größe des Projektes oder der Erfahrung des Projektteams.  Der Vorteil dieses Grenzen ist klar auch die Kostentransparenz jeder Änderung auch für die Techniker, dies folgt auch klar agilen Grundsätzen und ist in der traditionellen Projektbearbeitung ungewohnt (warum soll ich mich als Techniker denn mit den Kosten beschäftigen, das ist Aufgabe des Projektleiters !).

Ablauf EC:
  • Start EC (beliebig Person, Angabe des Projektes, der Grund und die Ursache, die Betroffenen Liefereinheiten)
  • EC Ersteller sammelt alle nötigen Information und Freigaben, die für eine Angebotsabgabe nötig sind -> AGIL gfs mit ScrumMaster
  • EC Ersteller gibt kommerzielle Daten in das System 
  • EC Ersteller stimmt mit Account Manager ab, ob ein Angebot herausgeht oder nicht (hier gelten dann natürlich die vorgegebenen Grenzen und Abstimmungen für Angebote im Unternehmen)
  • Accountmanager entscheidet dann, ob der EC umgesetzt wird und macht aus dem ECR einen ECO und definiert den Termin des ECC, der gfs identisch ist mit dem Start des ECOs
  • Der ECO wird vom Programm Manager aufgenommen und umgesetzt

Fragen zu Engineering Changes