Kaizen 2 go 282 : Lastenhefte im Produktentstehungsprozess

Inhalt der Episode:

Wo ordnet man Lastenhefte im Produktentstehungsprozess ein?
Welche Rolle spielen Wiederholungs- und Einmaligkeitsaspekte dabei?
Wie kann eine kontinuierliche Verbesserung bei eher einmalig-individuellen Vorgängen gelingen?
Wie gelingt es die Beteiligten unter den Bedingungen der Einmaligkeit und Distanz zusammenzubringen?
Wie lässt sich der weite Bogen von Lastenheften zu Beginn der Produktentstehung in der Anforderungsphase zur den Bedürfnissen der Produktion und ggf. auch des Kundendienstes am Ende der Produktentstehung schließen?
Was sind typische Ursachen dieser Distanz und der Folgen daraus?
Welche Empfehlungen können daraus abgeleitet bspw. dem Produktmanagement und Systemdesign-Abteilungen gegeben werden?
Wie kann sich die Produktion und der Kundendienst angemessenes Gehör verschaffen und ihre Anforderungen geeignet in Lastenheft unterbringen?
Wer sollte sich wie als ggf. unabhängige Instanz um diese Lücke und die Verringerung der Distanz kümmern?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 282 : Lastenhefte im Produktentstehungsprozess

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Björn Schorre bei mir im Podcast-Gespräch. Er ist freiberuflicher Systemingenieur, hat sich auf Lastenhefte für mechatronische Systeme spezialisiert und ist auch noch Mentor für die Einführung von Systems Engineering. Hallo Björn.

Björn Schorre: Hallo Götz. Schön, dass ich da sein darf.

Götz Müller: Ja schön, dass du dabei bist heute. Ich habe schon kurz ein paar Stichworte gesagt, aber stell dich ruhig nochmal in ein paar Sätzen intensiver vor.

Björn Schorre: Okay. Also du hast ja gesagt, was ich jetzt aktuell mache. Ich komme ursprünglich aus der Softwareentwicklung, habe dann bisschen Softwarearchitektur gemacht, ein paar Jahre lang und bin dann in die System-Entwicklung gekommen, weil ich gemerkt habe, da ist noch einiges zu heben, einiges an Potenzial zu heben und meine damalige Firma hatte dann auch entsprechend da Stellen geschaffen. Ja, und dann bin ich nochmal gewechselt in Richtung Projektleitung. Das habe ich dann zwei Jahre lang gemacht, bin dann in die Selbstständigkeit gegangen, weil ich einfach gemerkt habe, Lastenhefte und Systems Engineering, das ist so das, was ich gerne mache, wo ich mein Wissen weitergeben will und deswegen habe ich mich darauf jetzt auch fokussiert, ja.

Götz Müller: Jetzt könnte ich mir vorstellen, dass vielleicht nicht jeder so hundertprozentig verorten kann, wo denn Lastenhefte speziell dann in diesem, doch meiner Ansicht nach, sehr breiten, sehr langen Produktentstehungsprozess, wo man die verorten muss und was für eine Funktion sie da im Grunde auch einnehmen.

Björn Schorre: Ja, Lastenhefte sind so das allererste Dokument, was quasi für den Entwicklungsprozessprozess gestartet wird oder geschrieben werden, abgesehen von irgendeiner Projektidee, wo vielleicht etwas mal skizziert worden ist und ein grobes Budget genannt worden ist, um mal eine Richtung anzustoßen, aber im Lastenheft wird dann drinstehen, was wünscht sich der Kunde denn überhaupt. Egal, ob das jetzt ein interner Kunde ist, zum Beispiel das Produktmanagement oder ein externer Kunde, also da steht drin, was soll das Produkt oder das System, das am Ende des Produktentstehungsprozesses da herauskommen soll, was soll das leisten. Und dafür benötigt man ein Lastenheft.

Götz Müller: Ja. Jetzt haben wir gerade schon in unseren ersten Sätzen im Grunde zwei, meiner Ansicht nach recht wichtige, Begriffe verwendet, einmal natürlich den Begriff des Prozesses und da steckt für mich ganz zentral dahinter, dass es eine Sache ist, die sich wiederholt und andererseits aber den Begriff des Projektes und so einer der zentralen Aspekte von einem Projekt ist die Einmaligkeit und vielleicht fangen wir mit dem Aspekt an, hier diesen, ja, diesen vermeintlichen Widerspruch einmal aufzulösen.

Björn Schorre: Gerne, klar. Ich sehe das so … ich verstehe, was du meinst, das Projekt, das mache ich einmal und dann habe ich einen Produkt, was ich in Serie produzieren kann, das ist ja der Hintergrund von einem Projekt, aber das, was ich, um ein neues Produkt entstehen zu lassen, nutze ich ja Methoden, nutze ich irgendwelche Tools um in meiner Firma dieses neue Produkt entstehen zu lassen und da sind Tätigkeiten notwendig, die ich ja vielleicht schon mal gemacht habe bei einem vorhergehenden Projekt, weil die Produkte, die dann aus diesen Projekten rausfallen, die sind ja nicht grundverschieden, weil in einer Firma baue ich ja ähnliche Produkte. VW baut immer Autos, auch wenn die dann irgendwann mal elektrische Antriebe haben, ist es trotzdem weiterhin ein Auto und diese Prozesse dienen dann dort der Standardisierung. Also zu standardisieren, welche Methoden werden im Anforderungsmanagement, in der Softwareentwicklung genutzt oder im Test genutzt, welche Tools werden in den jeweiligen Abteilungen genutzt usw. Dafür dienen aus meiner Sicht dann die Prozesse.

Götz Müller: Ja. Und ich kann mich ja eben auch auf, nennen wir es mal Meta-Ebene bewegen, wo ich dann auf meinen Projektmanagement-Prozess zum Beispiel runterschaue oder eben auf diesen vielleicht kleineren Ausschnitt, wie entsteht ein Lastenheft. Auch wenn das inhaltlich immer wieder anders ist, glaube ich eben doch, dass auch da immer wieder ähnliche, ja, auch Fragen gestellt werden.

Björn Schorre: Mhm ja. Genau. So ist das, genau. Also wir haben das damals dann auch für uns, also bei einer meiner letzten Firmen, wo ich dann in dieses Systems Engineering reingekommen bin, da haben wir anderthalb Jahre wirklich eng zusammengesessen und überlegt, wie sehen denn jetzt diese Prozesse aus. Wir haben verschiedene Methoden ausprobiert und Tools evaluiert, um herauszufinden: Was ist denn für unsere Firma da jetzt die beste Methode? Wie kommen wir denn jetzt an die Anforderungen dran und wo dokumentieren wir sie? Und das haben wir dann in diesen Prozess reingeschrieben und dann konnte man das erste Produkt, ich sage mal den Piloten, den man dafür genutzt hat, darauf konnte man den Prozess anwenden, konnte man nochmal ein bisschen schleifen und dann konnte der wiederverwendet werden, dieser Prozess, also im nächsten Projekt.

Götz Müller: Genau und den Punkt möchte ich auch gleich noch ein bisschen vertiefen, weil ich jetzt halt primär die Prozessbrille mal aufsetze und ich glaube auch einige der Zuhörer natürlich, aufgrund ihres Lean-Kontextes auch eben die Prozessbrille aufhaben natürlich, du hast das Stichwort auch schon genannt, Verbesserung. Und was ich manchmal immer wieder erlebe, das ist so diese Pauschalaussage: „Ja, wir bauen ja keine Autos in Serie, wie sollen wir denn da etwas verbessern?“ Und jetzt glaube ich aber eben, du hast es schon angedeutet, kann ich auch in so etwas, quasi einmaligen wie einem Lastenheft, das ist ja inhaltlich immer wieder neu ist, trotzdem darüber nachdenken, wie kann ich den Prozess der Erstellung eines Lastenheftes betrachten.

Björn Schorre: Genau, genau. Es gibt da super viele verschiedene Methoden, wie ich an die Anforderungen komme. Ich kann auf Branchentreffen gehen und mit den Leuten sprechen, die da rumlaufen. Ich kann zu meinen Kunden hinfahren und denen über die Schulter gucken und schauen, wie die jetzt das Produkt von uns bedienen und das analysieren und überlegen, kann ich denen dann noch irgendwie etwas Gutes tun, indem ich das Produkt in irgendeine Richtung verbessere. Das sind also Methoden, wie ich an Anforderungen komme und jetzt habe ich nur zwei genannt. Da gibt es aber noch zehn, fünfzehn weitere. Das muss ich aber für meine Firma, für mein Unternehmen, für meine Abteilung heraussuchen, welches das Beste ist, dann schreibe ich das in einen Prozess rein, da schreibe ich dann dran: Hier ist das Lastenheft-Template. Da habe ich dann zum Beispiel auch schon eine entsprechende Struktur vielleicht drin, dann habe ich die Methode, mit der ich an die Anforderungen komme und die ich dann in die entsprechenden Kapitel reinschreibe und so habe ich einmal den Prozess, ich habe diese Inputs, ich hab Outputs, ich habe die Methoden, die ich dort benutze und wenn ich das jetzt mehrfach mache, dann stelle ich ja irgendwann fest: Ja, das, was wir damals vor einem Jahr uns überlegt haben, das hat zwar da funktioniert, aber wir haben jetzt rausbekommen, dass wenn wir nicht auf Branchentreffen gehen, sondern die Kunden zu uns kommen lassen und die bei uns im Labor ausprobieren lassen, das funktioniert für uns viel besser, also kann ich doch da den Prozess dann anpassen. Also da sehe ich dann, also so sehe ich dann die kontinuierliche Verbesserung.

Götz Müller: Ja. Also das ist für mich Wasser auf die Mühlen, weil im Grunde ist jetzt eben Projekt- oder als noch eine weitere Fokussierung Lastenheft ja der maximale Ausdruck von Einmaligkeit und wenn dort, wie du es gerade schon angedeutet hast, wenn dort diese Prozessdenke funktioniert, dann kann im Grunde keiner mehr ums Eck kommen und sagen „Ja, wir machen halt immer wieder etwas neues.“, nein, macht ihr halt nicht oder ihr bildet es euch vielleicht ein.

Björn Schorre: Jein. Also was ja neu ist dabei, sind ja andere Anforderungen. Also du hast, bestes Beispiel, ich habe neulich einen Lastenheft geschrieben für ein Ladegerät, für eine Firma, die baut schon seit Jahren Ladegeräte. Da fragt man sich doch, wenn du das jetzt so hier aufziehst, warum brauchen die denn dann ein Lastenheft? Ja, weil sich die Technologien geändert haben, weil die andere Batteriesysteme anschließen müssen, weil die neue gesetzliche Vorschriften und das muss dann alles irgendwie dort einfließen.

Götz Müller: Ja, aber die einzelnen Elemente, über die ich nachdenke, sind eben immer wieder die gleichen. Also ich denke zum Beispiel drüber nach, was habe ich denn für gesetzliche Anforderungen, was habe ich für Sicherheitsanforderungen, dann in der Realisierung, ich meine, da würden wir jetzt sehr tief reingehen, was habe ich für elektrische Themen, EMV, so ein beliebtes Thema von jemanden, die wir ja beide kennen, immer wieder Dinge, die auftreten und trotzdem habe ich manchmal das Gefühl, es ist das erste Mal, dass jemand über so etwas nachdenkt.

Björn Schorre: Ja, gut. Ich glaube, da fangen wir jetzt ein Thema an, das ist, das habe ich auch schon beobachtet, dass viele Firmen wirklich immer über diese Projektdenke kommen und sagen: Okay, das ist ja einmalig, das machen wir einmalig. Und das, was ich versuche mit dem Systems-Engineering-Mentoring-Programm zu etablieren ist, dass man halt sich überlegt: Moment mal eben, das war doch schon mal, das haben wir doch schon mal vor zwei Jahren gehabt, können wir da nicht die Sachen wiederverwenden von. Und dann bin ich ja in dieser Prozessdenke und durch die Wiederverwendung sehe ich ja auch zu, dass ich weniger Aufwand in die neue Definition oder in die Definition von neuen Anforderungen stecken muss. Das heißt also, ich nehme mir einen Baustein von irgendwoher und sage, okay, das sind jetzt alle Anforderungen, die der Kunde oder die unser Produktmanagement an die äußere Hülle des Gerätes stellt, die sagen: Wir wollen das immer in einer bestimmten Blaufarbe haben, weil wir uns damit vom Marktkonkurrenten dann abheben. Das nehme ich dann immer wieder und dann brauche ich das ja nicht neu zu erfassen, sondern ich habe das einmal schon da und das ist für mich so diese Kontinuität, die ich dann da reinkriege und das kann ich auch nach und nach immer weiter verbessern.

Götz Müller: Ja, und selbst wenn ich jetzt mal ganz extrem irgendwann mal sage: Unsere bisherige, weil du Farbe gesagt hast, unsere Firmenfarbe hat sich verändert. Trotzdem werde ich immer wieder darüber nachdenken, egal in welcher Farbe will ich das Ding dann gestrichen haben will, um es mal so ein bisschen flapsig auszudrücken.

Björn Schorre: Genau, genau. Das kann man ja, kann man wieder drüber nachdenken. Man könnte auch sagen, okay wir haben jetzt hier eine Fusion gehabt, mit einer anderen Firma und wir müssen jetzt unsere Gehäusefarbe in gewissen Rahmenbedingungen abändern, und dann überarbeite ich dort an der Stelle dann die entsprechenden Anforderungen.

Götz Müller: Ja. Aber ich werde halt weiter ein Gehäuse haben, um es mal so auszudrücken.

Björn Schorre: Genau. Du wirst auch weiterhin ein Gehäuse haben, aber das Gehäuse an sich, das ist ja auch vielleicht Teil von dem Produkt, was dem Projekt herausfällt und was doch diese Einmaligkeitsaspekte hat, aber dass sich ein Gehäuse brauche, dass ich die Breite, die Länge, die Höhe bestimmen muss, dass ich das Gewicht, das maximale Gewicht, vielleicht festlegen muss und so weiter. Das ist etwas, was immer wieder kommt.

Götz Müller: Ja. Das sollte dann keine Überraschung mehr sein.

Björn Schorre: Genau, genau.

Götz Müller: Ja. Gut, jetzt hast du auch angedeutet ein bisschen, die Kunden und die, in Anführungszeichen, anderen, die halt ein Produkt in welcher Form auch immer entstehen lassen, am Anfang erstmal gedanklich und dann im Austausch. Was ich da auch immer wieder erlebe, das ist, ja, nennen wir es mal eine gewisse Distanz, die da herrscht zwischen Systemingenieuren vielleicht auf der einen Seite, die ja am Anfang über Sachen da nachdenken, die sie nur im Kopf haben und dann irgendwann mal im wirklichen Produktionsprozess, wenn irgendetwas zusammengeschraubt wird in irgendeiner Form zum Beispiel, dass da eine gewisse, ja, Distanz eben besteht, was ist so deine Erfahrung in dem Kontext und vielleicht auch schon ein erster Tipp, wie bringt man da die Menschen zusammen, von diesem, also ich kenn’s durchaus so dieses, ja „die da“, aber unterm Strich sitzt man ja gemeinsam in einem Boot dann, weil nur wenn es gemeinsam gelingt, das Ding vom Hof zu schieben, wird man auch etwas dafür einnehmen.

Björn Schorre: Genauso so ist es. Das ist auch immer meine Aussage, wenn ich mit verschiedenen Leuten im Betrieb spreche und ich beobachte das auch, dass es da wirklich eine große Diskrepanz gibt in dem Verständnis: „Ach, ja und produzieren müssen wir es auch noch, aber das können die schon“. Ja. Mit großem Aufwand können die das dann nachher produzieren, weil sie im selben Boot sitzen, machen sie das dann für uns, aber viel besser wäre es, wenn ich … Ich habe das Lastenheft auf der einen Seite, ich habe jetzt ein gutes Systemingenieurshaus, muss ich vielleicht dazu sagen, ich habe auf der einen Seite das Lastenheft bekommen von meinem Produktmanager, von meinem Kunden, und da steht drin, ich möchte das in Europa verkaufen und in Nordamerika, dann weiß ich, welche Normen ich dazu anziehen muss. So etwas schreibe ich dann ins Pflichtenheft. Damit ist das Pflichtenheft aber noch nicht vollständig, denn jetzt muss ich mir noch mal Gedanken dazu machen, wie kann ich das Ding denn produzieren, Was wir denn da haben wollen. Hat unsere Produktion vielleicht irgendwelche besonderen Anforderungen an Verschraubungen zum Beispiel, weil die irgendein spezielles Werkzeug dort einsetzen? Bei meiner letzten Firma war es so, dass die dann sich gewünscht haben, ich möchte dieses Gerät immer nur, also wenn es im Schaltschrank hängt, immer von vorne schrauben können, egal welche Schraube doch kommt, die soll so ausgerichtet sein, dass ich von vorne schrauben kann, weil wenn ich mich von unten an das Gerät annähern muss, dann habe ich eventuell keinen Platz oder von der Seite, dann passt dieser Schraubapparat, der Akkuschrauber dann halt nicht zwischen Seitenwand und unserem Gerät. Also war die Anforderung, das muss immer von vorne zu schrauben sein. Schreibe ich das nicht ins Pflichtenheft als Anforderung aus unserer Produktion, weiß natürlich der Mechanikentwickler nicht, wie er das Gehäuse zu konstruieren hat oder diese Tragstruktur. Das Gleiche mit dem Service. Der Service möchte natürlich auch nicht für einen simplen Lüfterwechsel dem Kunden eine halbe Stunde in Rechnung stellen. Das könnte vielleicht auch in 15 Minuten gehen. Dann muss ich aber auch den Lüfter, weil das vielleicht ein großes Verschleißteil ist, so einbauen, dass ich den innerhalb von 15 Minuten wechseln kann. Keiner will heutzutage mehr so viel Geld dann für diesen Service ausgeben oder das vielleicht nachher auch selber machen, aber immer eine halbe Stunde einen Elektriker abzustellen, ist natürlich auch für eine Firma immer Kosten. Also das sind für mich so Anforderungen, die ich als Systemingenieur aufnehmen muss und die müssen in Pflichtenheft landen, weil nur so kann ich es schaffen, diese Anforderungen auch in die Entwicklung zu tragen, an die entsprechenden Stellen in die Entwicklung, und umsetzen zu lassen.

Götz Müller: Das würde ich ganz gern insofern noch ein bisschen vertiefen, weil ich mich immer, also ich erlebe das natürlich genauso, wie du es gerade berichtest, was ich mich dann immer frage: Warum muss das so sein? Und jetzt einfach mal an dich dann die Frage, hast du da, ich habe keine, hast du eine Theorie dafür, warum das so ist, warum diese Distanz existiert?

Björn Schorre: Eine der Theorie dafür, warum diese Distanz existiert? Vielleicht … das ist jetzt so ins Blaue geschossen, weil du mich da gerade so ein bisschen überraschst mit der Frage, aber wenn ich so darüber nachdenke, ist es auch, liegt es an der Distanz. Also, was ich immer erlebt habe, Entwicklungsabteilungen waren dann in irgendwelchen Entwicklungszentren oder in irgendwelchen Türmen unterhalb von der Geschäftsleitung oder vielleicht sogar ganz woanders, also richtig in einem ganz anderen Ort angesiedelt. Das heißt also, du hast eine große Distanz zwischen auf der einen Seite Entwicklungsteam und auf der anderen Seite die Leute in der Produktion und dass da dann nicht der Austausch so flüssig gelaufen ist und so direkt gelaufen ist, wie es vielleicht dann zwischen dem Produktmanagement und der Entwicklung passiert ist, das wäre für mich so eine, wenn ich jetzt so darüber nachdenke, die Erste, die warum das nicht passiert.

Götz Müller: Ja, der rein räumliche Aspekte. Was ich dann durchaus auch mal wieder wahrnehme, das sind vermeintlich unterschiedliche Sprachen, die, die manchmal gesprochen werden, also jetzt nicht im Sinne von Schwäbisch und Hochdeutsch oder Englisch und Italienisch, sondern, dass unterschiedliche Begrifflichkeiten, dass man in unterschiedlichen Welten auch manchmal denkt, also das ist so mein Eindruck manchmal.

Björn Schorre: Ja. Ich will keinem auf die Füße treten, aber es kann natürlich auch sein, dass es dann natürlich einen Unterschied gibt zwischen dem Studierten und dem Facharbeiter, dass die sich vielleicht nicht auf den Pelz gucken können oder dass der eine meint, er wäre etwas Besseres als der andere. Das sehe ich zum Beispiel so überhaupt nicht. Natürlich hat vielleicht der Mensch in der Entwicklung eine etwas andere Verantwortung zu tragen, weil er Spezialist ist in der Entwicklung von einer speziellen Elektronik und der Facharbeiter kann nach kurzer Anlernzeit vielleicht ausgetauscht werden. Aber nichtsdestotrotz müssen doch beide, wenn sie längerfristig in dieser Firma arbeiten wollen, ihre Leistung bringen und dann müssen sie entsprechend zusammenarbeiten, dann muss man sich gegenseitig wertschätzen und wie geht Wertschätzung? Wenn ich als derjenige, der gerade am Vordenken ist, das machen ja die Entwickler, die denken ja sich dieses Produkt erstmal im Kopf aus, dann muss ich doch mal hingehen in die Produktion oder zum Service und sagen: Erzähl mir doch mal, was sind hier so eure Anforderungen, wie baut ihr die Systeme zusammen, damit ich das bei meinem nächsten Produkt, was ich da entwickle, beachten kann?

Götz Müller: Ja. Ja, das sehe ich definitiv genauso. Vielleicht noch ein bisschen in die Richtung vertieft, was wäre dein Tipp an die, nennen wir es mal an die Produktionsleute, wie sie sich vielleicht auch mehr Gehör verschaffen können?

Björn Schorre: Wenn sie es nicht schon sind, also bei mir im letzten Projekt war es so, da saß auch jemand aus der Produktion, der Produktionsvorarbeiter aus der Endmontage von dem Gerät, der saß mit in unserem Projektteam, wenn das bei euch im Projekt nicht so ist, dann kümmert euch darum, dass ihr dort reinkommt in dieses Team, denn dann habt ihr wenigstens jemanden dort sitzen, der ja das Ohr an den neuen Produkten hat, der das Ohr an dem Puls der Zeit hat, was entwickelt meine Firma gerade und kann da mithören. Und wenn es dann zu Themen kommt, die Produktion betreffen, dann sollte man auch ruhig aufstehen und sagen: Hallo, ich habe da auch gewisse Anforderungen und die freuen sich die Leute, also gerade, wenn es ein Systemingenieur ist, der freut sich, wenn man dann da vielleicht schon ein Dokument aus der Tasche zieht und sagt: „Pass auf, wir haben das mal zusammen geschrieben in der Produktion“ oder ich, ich hab jetzt immer Produktionen gesagt, aber ich sehe Service und Vertrieb da ähnlich, „Wir haben diese Anforderungen hier in der anderen Fachabteilung, wir haben das mal zusammengeschrieben, das möchten wir ganz gerne bedacht haben und das fänden wir super, wenn das in die Produktentwicklung mit einfließt“. Ja, also das, da muss man vielleicht wirklich proaktiv an diese Teams rangehen, weil ohne, dass das Böse gemeint, vergessen sie das eventuell mal im Tagesgeschäft, weil die ersten Tätigkeiten im Produkt sind doch eher entwicklungslastig und dann, ja, fokussiert man sich da auf irgendwelche Lösungen, die man gerne schnell realisiert haben möchte.

Götz Müller: Ja, aber ich glaube, und da kann man im Grunde ja den Bogen wieder auf das Thema Lastenheft zurückschlagen, ich muss halt auch solche Dinge auf eine gewisse Art und Weise formalisieren. Ich meine, in viel zu wenig Unternehmen ist mein Eindruck, existiert so etwas wirklich wie ein Lastenheft aufgeschrieben. Jeder schlägt vielleicht vermeintlich oder real die Hände über dem Kopf zusammen, weil der ein oder andere schon, sagen wir mal, jetzt eher nicht positive Erfahrungen mit Lastenheften gemacht hat, ich meine, da könnte man wahrscheinlich eine eigene Episode darüber machen, was da alles drinstehen sollte und was vor allen Dingen nicht drinstehen sollte, das ist ja noch ein ganz anderes Thema, aber ich habe immer so das Gefühl, hier spart man am falschen Fleck etwas, auch durchaus Formalismus.

Björn Schorre: Ja, das habe ich auch beobachtet. Es gibt wirklich Lastenhefte, die sind nur fünf Seiten stark und davon sind drei Seiten Deckblatt und Inhaltsverzeichnis. Da kann ich natürlich kein Fünf-Millionen-Projekt mit beschreiben, da fehlt einiges dann drin. Aber es bringt auch nichts, wenn ich dann, ja, wie ich das damals dann bei Automobilisten mitbekommen habe, dass da dann ganze Paletten mit Lastenheften und Verweisen und Zeichnungen usw. dann angekarrt worden sind in Form von ZIP-Dateien, die man dann drei mal auspacken musste oder sowas, das ist natürlich auch nicht zielführend als Lastenheft. Wie oft habe ich es dann da gehabt, dass da Inkonsistenzen drin waren, die zum Beispiel Beleuchtung betroffen haben.

Björn Schorre: Ja, aber genau dieses Lastenheft ist schon als Start in die Entwicklung superwichtig. Was ich aber nicht ins Lastenheft schreiben würde, jetzt muss ich da doch einmal ein bisschen mehr auf die Inhalte eingehen, die Produktions- und Service-Anforderungen und wie der Vertrieb vielleicht das in seinen Vertriebskanäle reinstecken will. Das ist aus meiner Sicht kein Inhalt von einem Lastenheft, und das Lastenheft ist für mich wirklich, das Wünsch-dir-was vom Kunden, der sagt mir, wo wir das einsetzen, also in welchem Systemkontext, was ist links und rechts und oben und unten von diesem Produkt, halt auch welche Schnittstellen hat dann dieses Produkt, an welchen Stecker ist es angeschlossen, welche Protokolle sollen gefahren werden und was soll es dann machen mit diesen Informationen oder mit diesen Materialien, die zugeführt werden. Ja, also dieses ganz Grobe, das ist das, was am Ende des Tages im Lastenheft drinstehen muss. Die Service-, Vertriebs- und Produktionsanforderungen, die kommen dann, die muss dann der Systemingenieur zusammensammeln in das Pflichtenheft und ja, da werden dann halt die Anforderungen aus dem Lastenheft, die darfst du da auch nicht einfach nur kopieren, die müssen da schon ein bisschen konkreter sein, die müssen nämlich testbar werden an der Stelle, genauso wie die anderen Anforderungen, die dann noch zusätzlich reinkommen, von denen dann so berühmten Stakeholdern.

Götz Müller: Ja, ich glaube, was in dem Kontext auch ganz oft durcheinandergeworfen wird, ist das, ich meine, du hast gerade genannt, einmal einerseits das Prüfen, das Verifizieren und das Validieren, das sind scheinbar gleiche Dinge, aber man verwendet sie in einem ganz anderen Kontext. Und auch da werde ich immer den Verdacht nicht los, dass das Verständnis nicht ausreichend da ist, dass man eben auch da nicht die gleiche Sprache spricht. Der eine sagt, ich prüfe da etwas, was aber durch eine Produktionsbrille eine ganz andere Prüfung ist, wie durch eine Systemingenieursbrille.

Björn Schorre: Ja, genau. Genau, da gibt es definitiv große Unterschiede. Wolltest du da jetzt drauf eingehen? Ich denke mal, das ist dann noch mal eine eigene Episode, wenn wir da jetzt anfangen das aufzugreifen. Nein, aber ganz grob gesagt, die Anforderungen, die im Lastenheft stehen, die würde ich persönlich validieren, die dem Pflichtenheft stehen, die müssen verifiziert werden. Das eine ist: Habe ich das Produkt richtig gebaut? Das ist das, was im Pflichtenheft steht, Und wenn ich überlege, was hat mir der Kunde geschrieben und dann frage ich natürlich: Habe ich das richtige Produkt gebaut, womit ich auch den Kunden zufriedenstellen kann.

Götz Müller: Genau. Ja. Und da aber ist auch ein Stück weit meine Empfehlung, da eben gemeinsam möglichst früh eben zum Beispiel im Kontext des Lastenheftes gemeinsam darüber zu reden und da schon eine erste gemeinsame Sprache einfach zu entwickeln. Und selbst wenn es so etwas vermeintlich triviales, ist wie diese Begrifflichkeiten, die wir gerade genannt haben, dass man wirklich da schon ein gemeinsames Verständnis hat und dann weiterführend eben auch schafft und auch klare, ja, klare Zuständigkeiten und Abgrenzungen ein Stück weit auch, ohne jetzt einen Graben wieder aufzumachen.

Björn Schorre: Ja, genau. Das ist auch etwas, weil da spricht man auch gerne mal aneinander vorbei. Ich kann mich da noch gut an eine Geschichte erinnern, da haben wir mit SysML dann angefangen zu zeichnen, zu modellieren und da kam ein Element rein, das hieß Component und dann kam der Hardware-Entwickler und dann hat er die Hände über dem Kopf zusammengeschlagen und „Wie könnt ihr auf der Ebene nicht Component benutzen, als Component, also eine Komponente, das ist hier mein Transistor, mein Widerstand, mein irgendwas“. Ende vom Lied war, die Entwicklungsleitung hat uns verboten, Komponenten in SysML zu verwenden, da haben wir dann wiederum die Hände über dem Kopf zusammengeschlagen und ja. Die Lösung, die wir dann nachher gefunden haben, war, wir mussten wirklich sagen, wir sind auf Systemebene unterwegs, das sind unsere Begriffe, die wir auf Systemebene verwenden. Wenn wir jetzt in die Fachdomänen gehen, verwenden wir folgende Begriffe. In den Fachdomänen sind halt auch wieder andere Begriffe benutzt worden und wir haben einen definiert, wie wir den Übergang sauber hinkriegen, dass wir auch genau wissen, wir erwarten jetzt von der Elektronikentwicklung, dass da folgende Komponente oder der Baugruppe oder wie auch immer eingesetzt werden. Also wir haben uns dann da so ein bisschen, Silos will ich nicht sagen, aber wir haben uns so ein bisschen abgekapselt, wir haben dann halt diesen Kontext definiert, wo wir dann unsere Begriffe verwenden konnten.

Götz Müller: Ja, aber ich glaube, das ist dann schon auch die Rolle der Systemingenieure, da so ein bisschen eine Art von Dolmetscher zu spielen, zumindest habe ich das so in meinem, ich sage immer früheres Leben, in meinem früheren Leben wahrgenommen, manchmal zwischen Hardware-Entwicklung und Software-Entwicklung, manchmal zwischen Entwicklung allgemein und Produktmanagement oder gar Vertrieb und am anderen Ende natürlich auch Richtung Produktion, die halt sich zurecht alle in irgendeiner Form fokussieren, weil sie nicht, weil keiner alles beherrscht und trotzdem muss es halt ein paar Menschen geben, die so ein bisschen, die Fäden zusammenhalten auch.

Björn Schorre: Genau. Deswegen …. du hast ja diesen Dolmetscher-Begriff gerade reingebracht, den habe ich vor Jahren mal irgendwann gehört, war mir jetzt lange nicht mehr im Kopf, aber, danke dafür, das ist genau richtig, denn das ist auch eine der Fähigkeiten, die der Systemingenieur mitbringen muss. Er muss kommunizieren können zwischen diesen verschiedenen der Fachabteilungen, die die Realisierung machen müssen, aber auch zwischen dem Projektleiter, zwischen Geschäftsführung und zwischen Vertrieb, Produktmanagement, überall sitzt der dazwischen und bekommt Informationen zugespielt oder muss natürlich auch Informationen weitergeben. Ja, und wer, wenn nicht er, kann diese verschiedenen Sprachen dann auch beherrschen. Nicht bis ins letzte Detail, weil dafür ist er zu sehr zum Generalisten geworden, aber er kann sich auch oder dadurch, dass er vielleicht lange schon in der Firma ist oder sich stark mit diesen Themen auseinandergesetzt hat, also mit diesen Fachthema, kann er sich auch nicht mehr als dumm verkaufen lassen von irgendwelchen Leuten, die irgendwas, ja, die ihn instrumentalisieren wollen. Also deswegen glaube ich auch, du kannst ja nicht unbedingt einen sehr jungen Menschen hinsetzen, vielleicht kannst du den dahin entwickeln, also über ein Mentoring-Programm, aber du brauchst schon einiges an Erfahrung, um diesen Posten, diesen Job zu machen.

Götz Müller: Ja, aber ich glaube, da schlägt sich dann der Bogen auf den Einstieg unseres Gesprächs, das sind halt die Dinge, die immer wieder auftreten und einfach dieses immer wieder gleiche Sprache schaffen, gleiches Verständnis schaffen, völlig unabhängig davon, ob das Gehäuse braun oder grün oder gelb oder vielleicht auch mal gar keins, aber ich habe immer wieder solche Effekte und da immer wieder darüber nachzudenken, das ist, glaube ich, das Wichtige, was man sich bewusst machen muss.

Björn Schorre: Ja, genau. Das stimmt.

Götz Müller: Prima. Björn, ich fand das eine spannende Unterhaltung. Ein bisschen hat es mich an mein, ja, ich sage es immer so ein bisschen flapsig, ja, an mein früheres Leben erinnert und andererseits aber auch ist mir wieder bewusst geworden, manche Dinge scheinen sich doch nicht zu verändern, also da bleibt, glaube ich, uns beiden noch viel Arbeit, wo wir uns, ja, vielleicht auch verwirklichen können.

Björn Schorre: Genau. Das, ja, hoffe ich auch. Wobei auf der anderen Seite, Liegestuhl ist auch manchmal ganz gut. Ja, nein, aber mir macht das Spaß. Ich mache das mit Leidenschaft dieses Thema, weil es halt Lösungen schafft auf verschiedenen Ebenen, einmal in Richtung Produkt wirst du als Systemingenieur Lösungen schaffen, aber du schaffst auch neue Kommunikationswege, brichst vielleicht alte Kommunikationskrusten auf, also das ist eine superspannende Position, in der man sich dann dort befindet.

Götz Müller: Prima. Also ich danke dir für deine Zeit.

Björn Schorre: Jo, es hat mir Spaß gemacht und gerne wieder, wenn du da nochmal ein Thema besprechen möchtest.

Götz Müller: Das war die heutige Episode im Gespräch mit Björn Schorre zum Thema Lastenhefte im Produktentstehungsprozess. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 282.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.