Dienstag, 24. Dezember 2013

Der Kunde ist für die systematische Erarbeitung der Kundenanforderungen zuständig

Gute Software benötigt gute fachliche Anforderungen.

Bevor ich meinen Artikel starte, möchte ich Ihnen ein frohes und besinnliches Weihnachtsfest im Kreis Ihrer Liebsten wünschen. Vielleicht kann man einige Wünsche an das menschliche Miteinander, die man in das Weihnachtsfest projiziert, lieber auf das ganze Jahr verteilen, um so diese wenigen Tage nicht zu überlasten. Unsere Branche wurde dadurch nicht ärmer werden. Doch jetzt zu meinem Weihnachtswunsch.

In meiner Diplomarbeit [BAU09] aus dem Jahre 2009 habe ich den nachfolgenden Artikel zur Diskussion gestellt. Damit der Kunde bekommt, was er sich wünscht, ist eine enge Zusammenarbeit zwischen Auftraggeber und Auftragnehmer notwendig. An diesem Grundsatz halte ich auch heute noch fest. Mein Wunsch wäre es, dem Kunden zeigen, wie wichtig seine Mitarbeit ist, damit am Ende ein wirklich gutes Produkt erschaffen wird. Doch jetzt zu meinem damaligen Artikel:



Riko Pieper stellt die These auf, "die systematische Erarbeitung der Kundenanforderung ist Sache des Kunden" [RUPP07]. Die Realität sieht für ihn jedoch anders aus. Dort erstellen die Auftragnehmer die relevanten, für den Vertragsabschluss wichtigen Vertragsdokumente. Das ist seiner Meinung nach aber Sache des Auftraggebers.

"Dass sich der Auftraggeber für die Klarheit, Korrektheit, Vollständigkeit, Widerspruchsfreiheit und Prüfbarkeit seiner Anforderungen verantwortlich fühlt, sollte als Alternative in den Vorgehensmodellen mindestens als Möglichkeit erwähnt werden." [RUPP07] Im folgenden Diskussionsbeitrag zählt er mehrere Gründe dafür auf, die den Sinn dieser These unterstützen. Die Erarbeitung der Kundenanforderung durch den Kunden würde eine klare Schnittstelle zwischen Auftraggeber und Auftragnehmer benötigen. Auf beiden Seiten der Schnittstelle würden die Definitionsleistungen vollbracht werden, die im wirklichen Interesse der jeweiligen Seite liegen.

Ein Kunde hat ein hohes Interesse an der Verwirklichung seiner Kundenanforderungen. Wie diese in der speziellen technischen Lösung spezifiziert sind, liegt nicht in seiner Aufmerksamkeit. Über die von ihm gestellten Anforderungen behält er jedoch die Kontrolle.

Ein weiterer Grund, den Riko Pieper nicht benennt, ist das gestörte System des Interessenausgleichs zwischen Auftragnehmer und Auftraggeber. Gibt der Auftraggeber die Definitionsmacht für die Anforderungen an den Auftragnehmer, wird es oft ein mühseliger Prozess, seine Interessen durchzusetzen. Beim Auftragnehmer ist dann das Was und das Wie konzentriert. Im Prozess der Umsetzung entscheidet der Auftragnehmer über das Was und Wie, so dass es für ihn größtmöglichen wirtschaftlichen Sinn ergibt. Der Auftraggeber minimiert seinen Einfluss, agiert nur noch als Berater. In einem System, in dem verschiedene Akteure unterschiedliche Interessen vertreten, ist es effektiver, wenn diese von den jeweiligen Akteuren wahrgenommen werden und sie so zu einem Interessenausgleich gezwungen sind.

Ein weiterer nicht erwähnter Grund ist die Hoheit über das fachliche Wissen. Ein Auftraggeber beabsichtigt meist, seine Geschäftsprozesse zu optimieren. Die Geschäftsprozesse bilden Arbeitsabläufe in einer Organisation, die erledigt werden müssen, sie sind Bestandteil seines für ihn notwendigen fachlichen Wissens. Teile dieser Geschäftsprozesse lassen sich unter Umständen automatisieren. Verzichtet der Kunde darauf, diese Prozesse selbst abzubilden, überlässt er diese Arbeit dem Software erstellenden Auftragnehmer, kann dringend benötigtes Wissen verloren gehen. Dass das kein Hirngespinst ist, zeigen Altsystemanalysen, bei denen Prozesse alter Software analysiert werden sollen, um sie in neuen Systemen einzusetzen. Die mit dem Altsystem arbeitenden Mitarbeiter wissen im Extremfall nur noch, dass man etwas eingeben kann und dass am Ende etwas rauskommt. Welche Schritte zur Produktion des Ergebnisses durchlaufen werden, ist verloren gegangen.

Ein verbreitetes Verhalten in Softwarebetrieben ist die stille Entmündigung des Kunden. Aus Sicht der erfahrenen, hoch qualifizierten und analytisch begabten Softwareentwickler hat der Kunde wenig oder keine Ahnung, einen derartigen Prozess durchzuführen. Deshalb übernimmt die dazu qualifizierte Seite den Gesamtprozess. Ist die einseitige Qualifikation oft sogar Einbildung, hilft eine derartige Bearbeitung des Gegenstandes, Kommunikationsaufwand zu minimieren und das Gefühl der Kontrolle über den Gesamtgegenstand zu behalten. In der Realität tritt jedoch das genaue Gegenteil ein. Die Kontrolle über den Gegenstand entgleitet bei nicht genügend geleisteter Kommunikation mehr und mehr. Wirkliche Kommunikation baut auf gegenseitiger Achtung auf, basiert auf Wertschätzung. Das kann nur erreicht werden, wenn beide Seiten ihre Aufgaben erfüllen.

Die oben genannten Betrachtungsweisen gelten für die Erstellung von Individualsoftware. Massenprodukte wie Word werden für einen Massenmarkt produziert. Dort sucht sich der Kunde sein Produkt im Regal aus, kann möglicherweise eine Zeit probieren, ob die Software seinen Ansprüchen genügt und sich dann entscheiden. Bei Individualsoftware ist der Abnahmeprozess sehr viel schwieriger. Der Kunde prüft an Hand der für ihn erstellten Software, ob sie seinen Ansprüchen genügt. Hat er die Kundenanforderungen jedoch nicht selbst erstellt, klafft allzu oft eine riesige Lücke zwischen seinen Ansprüchen und den Kundenanforderungen.

Erschwerend kommt hinzu, dass der Softwarehersteller nicht der Fachmann für den zu bearbeitenden Inhalt ist. Ist der Schneider im Besitz des fachlichen und des technischen Wissens, beherrscht er das Was und das Wie, sind diese Wissensformen in der Softwareentwicklung oft getrennt. Lässt sich eine Bank eine Software für den Zahlungsverkehr erstellen, besitzt sie das fachliche Wissen. Erstellt der Auftragnehmer jedoch die vertragsrelevanten Anforderungen, muss er in einem mühseligen Frage-Antwortspiel dem Auftraggeber vieles entlocken. Dabei kann er sich, aufgrund seines fehlenden Erfahrungshorizonts, niemals sicher sein, alles erfragt zu haben. Fragen, die man nicht kennt, kann man auch nicht stellen.

Der Zustand, in den die Anforderungen damit gelangen, kann dem Auftragnehmer jedoch nicht egal sein. Auch wenn er wenig zu tun hat in dieser Form von (Nicht-) Zusammenarbeit, gelangt er so zu einer unvollständigen und nur halb verstandenen Anforderungsdefinition, die breiten Zündstoff für späteren Streit liefert. Das fachliche Wissen sollte derjenige definieren, der es hat. In diesem Prozess sollte ein Analytiker beratend zur Seite stehen, da das Wissen von der Aufbereitung von Wissen etwas anderes als das Wissen selbst ist. Nicht jeder, der etwas weiß, kann es ohne fremde Hilfe weitergeben. Das, oft dafür missbraucht, ist jedoch kein Argument für die Entmündigung des Auftraggebers und der Abgabe der von ihm zu erfüllenden Aufgaben.

Neben dieser scheinbaren zeitlichen Entlastung, die allzu oft durch spätere Querelen kompensiert wird, spielt für den Auftraggeber der gewichtige Grund der Kostenabwälzung eine große Rolle. Die eigenen Aufwendungen für die Definition von Kundenanforderungen sind ein nicht zu verachtender Kostenfaktor. Die Folgeaufwände im Prozess der Anforderungsdefinition durch den Auftraggeber werden jedoch oft nicht vermerkt, werden doch auch diese auf den Auftragnehmer abgewälzt. Ein moralisches Werten eines solchen Verhaltens kann nicht Gegenstand dieser Betrachtungen sein, es überzeugt im heutigen Wirtschaftklima niemanden. Im Interesse des Auftraggebers müsste es jedoch ein Auftragnehmer sein, der seine ganzen Kräfte auf die Produktion der von ihm gewünschten Software konzentrieren kann. Der Auftraggeber sollte an der effizienten Produkterstellung interessiert sein und nicht daran, dass der Auftragnehmer ineffizienten Betätigungen nachgeht, wie dem Streit um die richtige Auslegung und die Änderung der Änderung oder dem Nichtverstehen von Inhalt und der folgenden freien Interpretation. Derartige Folgeaufwände sollten auch im Interesse des Auftraggebers vermieden werden. Dem Auftragnehmer bleibt wesentlich mehr Zeit, sich auf seine eigentlichen Aufgaben zu konzentrieren.

Wenn der Kunde die Kundenanforderungen erarbeitet, konzentriert er sich auf die Darstellung des fachlichen Wissens. Einer Vermengung von fachlichem und technischem Wissen ist so meist ein natürlicher Riegel vorgeschoben. Wird der gesamte Anforderungsprozess vom Auftragnehmer durchgeführt, ist das ein nicht zu unterschätzendes Problem. Für eine saubere Trennung dieser beiden Wissensformen spricht die Haltbarkeit dieser Form von Wissen. Fachliches Wissen hat einen weitaus längeren Bestand als technisches Wissen.

Aus oben genannten Gründen, ist die These von der Pflicht des Kunden zur systematischen Erarbeitung von Kundenanforderungen zu unterstützen.

So endet mein Diplomarbeitsartikel. Es fehlen nur wenige Überleitungssätze zum nachfolgenden Artikel, die in diesem Zusammenhang keinen Sinn gemacht hätten. Für meine Erarbeitung eines optimierten Requirements-Engineering-Vorgehens könnte es durchaus Sinn machen, sich noch einmal die Prozesse an der Schnittstelle zwischen Auftraggeber und Autragnehmer durch den Kopf gehen zu lassen. Ich halte diesen Übergang für entscheidend für eine Verbesserung vieler Ausgangsprozesse in der Softwareentwicklung. Durch das Nichtverstehen dieser Prozesse geht viel verloren, Zeit, Geld und Nerven.

  • [BAU09] Ralf Baumann: "Entwicklung eines Arbeitsablaufes für die Entwicklung von Anforderungen an eine Software durch den Auftraggeber.", Diplomarbeit an der FH Trier, 2009
  • [RUPP07] Chris Rupp & SOPHISTen: „Requirements Engineering und – Management“, 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Der Kunde ist nicht für die Erarbeitung der Anforderungen zuständig. In der Realität beschräftigt der Kunde für diese Fälle Systemanalytiker und Fachreferenten die genau diese Tätigkeit erfüllen sollen.

    AntwortenLöschen
  2. Systemanalytiker und Fachreferenten können jedoch unter der Verantwortung des Kunden arbeiten.

    AntwortenLöschen
  3. Danke! Ein spannender Artikel, der, wie auch einige weitere in diesem Blog, auf die tatsächlichen Probleme bei der Individualsoftware-Entwicklung aufmerksam macht.

    Die Formulierung der fachlichen Anforderungen aus der Kundensicht ist eine notwendige Bedingung, damit die Software das leisten kann, was sie leisten soll. Der Kunde sollte auch "Herr des Fachgebiets" sein und bleiben - denn sonst entscheidet die IT künftig über die Prozesse im Unternehmen.

    Ob aus Faulheit, Mangel an Wissen oder fehlendem Willen - die Realität sieht in manchen Unternehmen anders aus. Das Resultat ist dann aber immer das gleiche: eine Spirale der erlernten Hilflosigkeit auf der Seite des Kunden. Der Kunde formuliert seine Anforderungen nicht -> die IT übernimmt das für ihn -> der Kunde formuliert immer weniger Anforderungen.

    Eine IT, die sich in eine solche Rolle drängen lässt, hilft sich dabei höchstens auf kurze Sicht selbst. Denn wenn die IT die Anforderungen definiert und sie umsetzt - dann ist sie irgendwann auch für die inhaltliche Mitarbeit in den Prozessen zuständig. Und so müssen dann Mitarbeiter der IT Rechnungsläufe anschubsen, Lagerlisten ins System laden oder fehlerhafte Kundenstammdaten bereinigen.

    Ein wichtiger Punkt, den Sie hier anregen: der Kunde muss selbst erkennen, in welches Dilemma er sich und seine IT hier befördert. Letztlich muss die Fachabteilung echte "Ownership" über die eigenen Prozesse, ihre fachlichen Anforderungen und die zukünftige Weiterentwicklung von Prozessen und Systemen übernehmen.

    AntwortenLöschen