"Das Schicksal mischt die Karten und wir spielen."
(Arthur Schopenhauer)

Funktionale Anforderungen

Bei der Geschäftsprozessanalyse kommen über die strategischen Ziele bereits die ersten Hauptanforderungen an das zu erstellende Softwaresystem durch. Eigentlich beginnt es aber noch viel früher, nämlich bereits bei dem ersten Kennenlerngespräch beim Kunden. Dieses läuft häufig sehr unstrukturiert ab und der Kunde will sich erst mal ganz viel von der Seele sprechen. Als potentieller Anbieter sollten Sie hier zuhören, sich Notizen mit einem Stift auf Papier machen und später im Büro alles sortieren.

In einem solchen Erstgespräch mit dem Kunden wird also zunächst über Wünsche und Vorstellungen gesprochen, die in aller Regel noch nicht konkretisiert oder zumindest noch nicht abschätzbar sind. Meistens ist sich der Kunde sehr unsicher über Realisierbarkeit und Aufwand. Als Auftraggeber wird der Kunde zum Anforderungssteller und liefert oft ein Fachkonzept mit den funktionalen Anforderungen (engl.: functional requirements, FR). Dies geschieht in Form eines protokollierten Gesprächs, als Handschrift-Zeichnung, als unstrukturierter oder auch strukturierter Text oder vielleicht sogar schon als Software-Lastenheft - in der Regel aber leider als irgendeine Sammlung von Irgendwas.

Oft denkt der Kunde leider, dass bereits genügend Informationen zur Entwicklung der Software vorliegen, aber davon darf sich der Anbieter auf keinen Fall beeindrucken lassen, weil dies wirklich praktisch nie so ist. Der Anbieter sollte hier den Kunden unbedingt über mögliche weitere Vorgehensweisen aufklären und erläutern, welcher immenser Detaillierungsgrad noch erarbeitet werden muss. Es gibt halt nur zwei Möglichkeiten: entweder lernt der Kunde, wie professionell Software entwickelt wird oder der Softwareentwickler lernt die Fachlichkeit und die Geschäftsprozesse des Kunden; in aller Regel ist Letzteres einfacher und billiger! Dabei kann es von Vorteil sein, wenn der Anbieter Branchenkenntnisse besitzt, aber genau dieses Wissen kann auch hinderlich sein: Oft sehen sich die Kunden nämlich selbst als einzigartig an, arbeiten nach einer ganz eigenen Methode und möchten keinesfalls mit anderen in einen Topf geworfen werden.

Sollte das Fachkonzept bereits als fertige Spezifikation aller Details ausgeprägt sein (beispielsweise bei Ausschreibungen auf Basis bereits erstellter Analysen), kann vielleicht direkt eine Aufwandsabschätzung für das Implementierungsangebot folgen. Legt der Kunde immerhin eine ausdiskutierte Anforderungsliste vor, sollte diese in der Pre-Analyse-Phase auf Vollständigkeit, Widerspruchsfreiheit und Implementierbarkeit geprüft und anhand eines Fragenkatalogs abgerundet werden. Meistens enthält das Fachkonzept aber so viele Lücken und Unklarheiten, dass in einer Geschäftsprozessanalyse die wirklichen Anforderungen erst noch erarbeitet und gesammelt werden müssen. Hier sollte auch darauf geachtet werden, ob der Anforderungskatalog mehr einer Weihnachts-Wunschliste entspricht, in der alles enthalten ist, was man schon immer mal haben wollte oder jemals gebrauchen könnte, aber nicht sinnvoll abgegrenzt wurde, was wirklich in der ersten Stufe implementiert werden sollte. Hier sollte dann die Regel "Reduce to the Max" ("Reduziere auf das Maximum") befolgt werden. Gemäß dem Spruch oben auf dieser Seite haben Sie als Auftragnehmer zunächst keinen Einfluss darauf, was Ihnen alles vorgelegt wird, aber sehr wohl einen Einfluss darauf, was Sie daraus machen. Und wenn in der Spezifikation die technische Anforderung steht, dass "ein generischer Ansatz für jedes gängige Datenbanksystem" enthalten sein muss, dann hauen Sie die sogenannte Spezifikation halt in die Tonne.

Beim Analyseprozess muss genau ein definierter Ansprechpartner des Kunden mit repräsentativen Vertretern aller Endanwendergruppen (Akteure) aktiv mitarbeiten, um auch wirklich den echten Bedarf zu ergründen und nicht an den Bedürfnissen der Anwender vorbei zu entwickeln. Nur so können die während der Entwicklung auftretenden gefürchteten Änderungsanforderungen (englisch "change requests") vermieden werden. Auch auf Anbieterseite sollte genau ein direkter Ansprechpartner benannt werden, damit die Verantwortung wirklich auf einer 1:1-Beziehung liegt. Sollte das Projekt so groß und komplex sein, dass eine Person nicht ausreicht, muss über genau ein Komitee auf beiden Seiten gesprochen werden, dass jeweils quasi als eine Person auftritt. Dabei ist auf eine extrem verbindliche Dokumentation zu achten, d.h. alle Absprachen werden als Beschlüsse von Sitzungen in schriftliche Protokolle gefasst.

Die Zeitschrift CIO schreibt in ihrer Ausgabe 6/2002: "Caper Jones, Chef-Forscher beim PM-Software-Anbieter Artemis, hat herausgefunden, dass sich in 90 Prozent aller Fälle die Anforderungen während der Projektlaufzeit verändern. Um dieses Problem zu begrenzen, rät er, IT-Lösungen gemeinsam mit den Endbenutzern zu entwickeln, wodurch sich die Hälfte der Änderungswünsche eliminieren lasse. Prototypen könnten weitere 10 bis 25 Prozent der Änderungen in eine frühe Phase verlagern. Für große Projekte empfiehlt Jones so genannte Change Control Boards aus Management, Benutzerrepräsentanten und Entwicklern."

Aber was tun, wenn Sie den Kunden gar nicht so einfach direkt fragen können, weil Sie ein Massenprodukt für den freien Markt entwickeln? Nun, dann benötigen Sie einen Produktmanager (oder Produktkoordinator), der den Markt und damit den Endbenutzer vertritt und dabei von den Abteilungen Marketing und Vertrieb unterstützt wird. Der Produktmanager stellt dann also die funktionalen Anforderungen.

Wenn Ihnen die bisherige Darstellung zu den funktionalen Anforderungen nicht konkret genug ist, kann ich Sie beruhigen, denn ich werde noch sehr genau auf Anforderungslisten zu sprechen kommen und dort auch Beispiele mit verschiedenen Instrumenten zeigen. Zurzeit sind wir ja im Erstgespräch (oder vielleicht auch zweiten oder dritten Gespräch während der Pre-Analyse-Phase) zwischen Kunde und Anbieter und zu dieser Zeit gibt es in aller Regel halt noch keine brauchbaren Anforderungslisten. Genau diese gilt es aber zu erstellen, indem Anforderungen erkannt, hinterfragt und gesammelt werden.

FRs aufnehmen   Reduce to the Max     1:1-Beziehung     Was/Warum statt Wie     EAI berücksichtigen     Typische FRs     SPO / Glossar     OUTs listen

Beim Sammeln von Anforderungen steht immer die Frage im Vordergrund: "Was soll das Softwaresystem leisten?", und nicht die Frage "Wie soll es das leisten?" (s. auch Geschäftsprozesse). Ignorieren Sie also als Analytiker zunächst möglichst alle Implementierungsvorschläge und Prototypen und Lösungsversuche und Altsysteme des Kunden - und zwar möglichst ohne ihn das merken zu lassen, denn Sie wollen sich ja nicht unbeliebt machen. Später werden diese Aspekte wichtig, aber im Moment geht es noch darum, überhaupt erst mal die wesentlichen Anforderungen zu erkennen. Hier ist es eher noch hilfreich, mit "Warum?" nach dem Grund der Anforderung zu fragen, denn so erfahren Sie, was mit der Anforderung genau erreicht werden soll. So können Sie oft die Akzeptanzkriterien finden, die Sie später auch noch für die Erstellung der Testfälle und die Abnahme sehr gut gebrauchen können.

Die Frage nach dem "was" liefert Ihnen bei der Analyse die Funktionen (engl.: feature) des neuen Systems, die Sie dann sehr schnell zu den Anwendungsfällen bringen wird. Andere praktische "was"-Fragen sind: "Was kann das System noch tun, um Ihnen bei der Lösung Ihrer Probleme zu helfen?" (führt oft zu Randaspekten) oder "Was ist Ihnen denn jetzt das Wichtigste am neuen System?" (fokussiert nach einiger Diskussionszeit wieder auf die hohen Prioritäten) oder "Was haben sich denn die Anderen für das System gewünscht?" (weitet zwischendurch mal wieder den Horizont und bringt den Gesprächspartner in eine andere Perspektive oder Rolle).

Ein sicherlich wesentlicher - aber auch sehr schwieriger - Aspekt bei der Aufnahme der funktionalen Anforderungen ist die Berücksichtigung eines EAI-Ansatzes (Enterprise Application Integration, dt.: Unternehmensweite Integration von Programmen). Dabei geht es um die Schaffung von Identitäten im Unternehmen und dadurch gleichzeitig um die Vermeidung von Redundanzen. Wenn beispielsweise ein Softwaresystem die Projekte des Unternehmens verwaltet und ein anderes die Stabsstelle für Qualitätsmanagement unterstützt, so wird genau dieses Qualitätsmanagementsystem Informationen zu den Projekten des Unternehmens speichern wollen. Es wäre sicherlich Wahnsinn, wenn in das neue Qualitätsmanagementsystem wieder eine Projektliste mit womöglich weiteren Informationen zu den Projekten eingebaut würde. Stattdessen sollten natürlich die Funktionalitäten und Informationen des Projektverwaltungssystems im neuen System genutzt werden. Wenn das Projektverwaltungssystem bereits aus gekapselten Komponenten besteht, die über definierte Schnittstellen verfügen, die auch noch dokumentiert sind und kompatibel gewartet werden, so liegt sicherlich eine perfekte Ausgangssituation vor. Ist die nicht gegeben, was leider eher der Standardfall ist, so sollte zumindest über eine Punkt-zu-Punkt-Schnittstelle der beiden Applikationen nachgedacht werden. Was nutzt es schließlich dem Kunden, wenn er ein weiteres neues tolles Softwaresystem erhält, in dem gewisse Daten zum wiederholten Male redundant gepflegt werden müssen und gewisse Geschäftsprozesse zum wiederholten Male programmiert werden? Damit werden direkt wieder neue Baustellen aufgemacht, die später nur mit sehr viel Aufwand abzuschließen sind. Es sollte in diesem Zusammenhang auch geklärt werden, ob die Wiederverwendbarkeit von Funktionalitäten und Informationen des neuen Systems eine technische Anforderung an das neue System darstellt, denn dann sollte für das neue System direkt ein komponentenorientierter Ansatz gewählt werden.

Es gibt typische funktionale Anforderungen, die immer wieder vorkommen und keinesfalls vergessen werden dürfen, denn trotz ihres häufigen Auftretens spielen sie bei späteren Aufwandsschätzungen oft eine entscheidende Rolle. Es macht daher durchaus Sinn, hierfür im Laufe der Zeit eine Checkliste aufzubauen und den neuen Kunden direkt abzufragen, welche Anforderungen davon bestehen und welche nicht. Ich möchte hier aus meiner eigenen Erfahrung ein paar Beispiele dafür nennen, die Sie direkt in Ihren Fragenkatalog mit aufnehmen sollten; denn wenn diese Anforderungen nachträglich aufkommen, steht oft eine Totalrenovierung der Software an, womöglich bevor sie überhaupt das erste Mal installiert wurde.

Typische   Unterschriften     Mehrsprachigkeit     Zeitzonenreferenz     Währungsreferenz     Unternehmenskalender     Revisionssicherheit     Netzwerkfähigkeit

Wenn Ihnen beispielsweise auffällt, dass im Unternehmen Dokumente existieren, die unterschrieben werden müssen, so hilft es dem Unternehmen oft nicht unbedingt viel weiter, hier eine super tolle Unterstützung aufzubauen, wenn die Dokumente am Ende doch für die juristisch verbindliche Unterschrift gedruckt und als Papier aufbewahrt werden müssen. Soll auch die Unterschrift papierlos geleistet werden können, fallen evtl. erhebliche zusätzliche technische Aufwände an.

Ähnlich ist es mit der Mehrsprachigkeit. Wenn der Kunde beispielsweise Niederlassungen in Ländern hat, in denen verschieden Volks- oder Amtssprachen gesprochen werden, so kann eine Bedienerführung in mehreren Sprachen erforderlich werden. Dabei muss nicht nur die unterschiedliche Länge von Texten auf dem Bildschirm beachtet werden, oft sind auch ganz andere Schriftzeichen zu verwenden, in der Regel müssen Währungen umgerechnet werden und manchmal ist sogar die Schreibrichtung anders. Auch die Vorlagen für Berichte und Formulare sind dann in verschiedenen Sprachen zu pflegen und die Einweisung für Administrationen und Pilotanwender sowie das Erstellen des Handbuchs werden ebenfalls viel aufwändiger. Wenn Ihre Software kalendarische Daten verwalten muss, kommen auch noch die unterschiedlichen Feiertage mit ins Spiel. An verschieden Formatierungen für Tausender- und Dezimaltrenner in den Zahlen sowie in den Datumsangaben sind die meisten Softwareentwickler mittlerweile zum Glück eigentlich schon gewöhnt.

Spannend wird es auch, wenn der Kunde ein weltweit operierender Konzern ist und eine eigene Zeitrechnung für unternehmensweite Termine besitzt. Dann können Sie so etablierte Dinge wie GMT (Greenwich Mean Time) oder PST (Pacific Standard Time) vergessen, weil irgendwo im Konzernnetz ein Server steht, der die absolute Zeit innerhalb des Konzern vorgibt.

Das gleiche kann es für Währungsumrechnungen geben, wenn in einem zentralen Konzernserver täglich zu einem festgelegten Zeitpunkt die Faktoren eingespielt werden, die von allen Standorten des Konzerns für offizielle Umrechnungen zu verwenden sind. Das kann eine simple Datenerfassung plötzlich viel komplizierter machen, als dies zunächst vermutet wurde.

Noch spannender kann es werden, wenn Sie auf Unternehmenskalender stoßen. Dann hat ein Monat womöglich nicht mehr 28 bis 31 Tage, sondern vielleicht immer 30 Tage und dafür am Jahresende ein paar Schalttage. So was nennt sich dann vielleicht "Produktionsmonat" oder "Lieferungsmonat" und ist ggf. die Grundlage vieler Anwendungsfälle in der Software. Sie sollten auch immer darauf achten, wann eigentlich das Geschäftsjahr des Kunden anfängt. Viele größere amerikanische oder internationale Konzerne starten ihr Geschäftsjahr gerne am 1.7. oder 1.6., weil es dann im Markt am ruhigsten ist und dann noch am ehesten Zeit für das Erstellen der Statistiken, Abrechnungen und Pläne vorhanden ist.

Sie sehen also: Die Erfahrung von Unternehmen übersteigt teilweise deutlich die persönliche Erfahrung. Man wird in der Zusammenarbeit gerade mit größeren Unternehmen und Konzernen oft mit Problemen konfrontiert, die ein einzelner Mensch in seinem persönlich Alltag nie träumen würde.

Äußerst schwierig kann auch die Forderung nach Revisionssicherheit sein, d.h. die Software muss jederzeit an einen ganz bestimmten Zeitpunkt zurück versetzt werden können, um dann die Datenkonstellation zu prüfen. Koppelt man dies noch mit Was-Wäre-Wenn-Szenarien, also Fallstudien, Variantenberechungen oder ähnlichen Späßen, so kann sehr schnell ein sehr kompliziertes Datenmodell auf dem Tisch liegen. Allein schon die Forderung, dass gewisse Änderungen eine verfolgbare Spur hinterlassen sollen (also im einfachsten Fall eine Historisierung), ist unangenehm, wenn diese Forderung erst nachträglich aufgestellt wird. Sowas sollte man möglichst von vornherein berücksichtigen und deshalb sollte man als Analytiker frühzeitig danach fragen.

Netzwerkfähigkeit ist heutzutage eigentlich selbstverständlich, aber nicht unbedingt immer erforderlich. Selbst wenn 1000 Mitarbeiter gleichzeitig mit der gleichen Software im gleichen Netz arbeiten, kann es seltene Funktionen mit besonderen Berechtigungen geben, die nicht netzwerkfähig sein müssen. Wenn Sie bei automatischer Nummernvergabe in einem festen Nummernkreis netzwerkfähig sein wollen, erfordert dies eine sofortige Reservierung, damit es im Netz nicht zu mehrfach gleicher Nummernvergabe kommt. Beim Abbrechen ist dann ein Rollback der Reservierung, ggf. mit Nummernfreigabe, erforderlich. Falls diese Lücke wieder geschlossen werden muss, müssen ggf. Listen frei gewordener Nummern verwaltet werden. Soll die Nummernvergabe aber zusätzlich eine Chronologie widerspiegeln, muss hier womöglich noch geschoben werden oder mit Timestamps bzw. Zweitlisten gearbeitet werden. Deshalb sollte bei jeder Funktion genau abgeklärt werden, ob sie wirklich netzwerkfähig sein muss, oder ob vielleicht durch einen Sperrmechanismus eine Exklusivität erzwungen werden darf.

Sie sollten zur Auflockerung des Gesprächs auch mal die Unterlagen sichten, die Ihnen präsentiert werden, aber nur, um weitere funktionale Anforderungen zu finden und neue Fragen aufzuwerfen. Oft hilft dabei die alte SPO-Methode (Subjekt, Prädikat, Objekt): Suchen Sie in Sätzen nach Subjekten und Objekten und prüfen bzw. erfragen Sie, ob das wichtige Aspekte sind. Wenn Sie kein Kenner der Branche sind, können Sie sich hier gerne outen und nach Erklärung der Fremdwörter fragen. Einerseits lernen Sie dabei die Fachlichkeit des Kunden und füllen so das Glossar, andererseits stellen Sie fest, ob Ihr Ansprechpartner eigentlich selbst sein Vokabular und seine Fachlichkeit beherrscht. Es schadet dabei sicherlich nicht, wenn Sie an einigen Stellen für wenige Minuten auch mal ganz tief in Details gehen und damit auch Interesse für die kleineren Aspekte der Fachlichkeit des Kunden zeigen - oft arbeiten gerade leitende Menschen mit Begeisterung in ihrem Fach! Die Prädikate führen Sie oft zu Teilprozessen, die sie wiederum zu größeren Prozessen bringen, die neue Fragen aufwerfen oder Zusammenhänge verdeutlichen. Und immer wieder daran denken, dabei die Anforderungen herauszuhören und zu sammeln.

Und immer auch daran denken, die Anforderungen zu notieren, die unwichtig sind und vom System gar nicht berücksichtigt werden sollen, denn oft ist es einfacher, abzugrenzen, was ein System eigentlich nicht leisten soll! Dies präsentiert Ihnen ggf. ein klares Negativ von der zu erstellenden Software. Sie können in den Anforderungslisten diese Anforderungen immer noch mit "low" oder "none" priorisieren oder einfach als "out" kennzeichnen.

Gerade in frühen Gesprächen kann es übrigens hilfreich sein, zu zweit beim Kunden aufzulaufen, sei es nun eine Kombination Vertriebler/Analytiker, Analytiker/Presales oder Analytiker/Techniker. Dann kann nach dem Gespräch bereits auf der Rückfahrt ein Meinungsvergleich stattfinden, Dubioses diskutiert werden oder Unverständliches gemeinsam ergründet werden. Manchmal stimmt ja auch einfach die Chemie nicht - dann kann der Kollege vielleicht die Gesprächsführung übernehmen und für den nächsten Termin der Analytiker durch einen passenderen Typ ersetzt werden (vielleicht doch ein impulsiver statt einem strukturierten oder kollegialen Menschen). Auch eine Kombination von Frau und Mann kann sinnvoll sein und auch ein bewusstes Rollenspiel (z.B. der dem Kunden neu vorgestellte Analytiker fragt und der bereits bekannte Vertriebler schreibt mit) kann sehr effizient sein. Es kann übrigens durchaus Monate und Jahre dauern, bis sich ein winning Team so richtig einspielt.

Beispiel

Nehmen wir an, ein Unternehmen möchte seine Verwaltung optimieren, d.h. zur Effektivitätssteigerung die Routineaufgaben für das Personal zugunsten proaktiver Tätigkeiten reduzieren und zur Effizienzsteigerung Kosten und Arbeitsschritte einsparen ohne die Leistungsfähigkeit zu gefährden. Schon mal gehört? Klar! Diese Optimierung soll unter anderem durch den Einsatz eines neuen individuellen Softwaresystems erreicht werden. So wird es Ihnen als Vertriebler eines Softwarehauses im Erstgespräch vor Ort erzählt. Dann wird das Hauptziel für dieses System sicherlich in irgendeiner Form den obigen Satz enthalten.

Ein Teilziel des Unternehmens (im Softwareprojekt in der Position des Kunden) an das IT-Unternehmen (im Softwareprojekt in der Position des Lieferanten) für das neu zu erstellende Softwaresystem lautet dabei doch sicherlich: "Die Materialbeschaffung muss optimiert werden." O.k., so wird es eine Interessensgruppe aus dem Management formulieren. Wenn Sie aus dem Interview dieser Interessensgruppe erfahren, welche Akteure im Unternehmen dafür zuständig sind (wahrscheinlich der Einkauf oder bei einem kleineren Unternehmen vielleicht ein Sekretariat oder die Buchhaltung) und diese Akteure im Interview mit diesem Teilziel konfrontieren, ist das zunächst sicherlich eine sehr komplexe Angelegenheit.

Sie werden dann als Analytiker von den operativen Akteuren wahrscheinlich zunächst an einzelnen Beispielen erfahren, wie es wirklich läuft: "Also, das Papier für Kopierer und Drucker wird im Schrank neben dem Haupt-Kopierer gelagert, der hinten im großen Flur steht, denn da ist der meiste Platz, und die Mitarbeiter sollen uns Bescheid geben, wenn nur noch 10 Pakete da sind - das klappt eigentlich ganz gut. Aber das sauteure DIN-A3-Photopapier für die Messeposter hat wohl mal einer mit nach Hause genommen und seitdem müssen wir das hier bei uns in einem Schrank unter Verschluss halten und dürfen das nur noch auf Begründung an die Mitarbeiter rausgeben. Der Bedarf ist auch sehr unterschiedlich, weil die manchmal für einen Kunden für eine große Messe ganz viel auf einmal brauchen und dann wieder wochenlang gar nichts. Wenn wir das besser steuern könnten, dann könnten wir viel mehr Gebrauch von den gelegentlichen Preisaktionen bei ... machen und richtig Kohle sparen." - Aha! Hier erkennen wir also schon Geschäftsprozesse (Selbstbedienung, Bedarfsmitteilung, Nachschub einerseits und Anfrage, Bewertung, Herausgabe andererseits), Geschäftselemente (Papier in verschiedenen Qualitäten und Werten) und Geschäftsregeln (billig=Selbstbedienung, teuer=Kontrolle).

Was Sie als Analytiker aus einem Wiwi-Studium, aus Betriebswirtschaftsbüchern, aus langjähriger Unternehmenserfahrung oder aus einem vergangenen Projekt wissen, ist den Akteuren des Kunden wahrscheinlich auch irgendwie klar, aber nicht so systematisch bewusst: hier ist nämlich von der Klassifizierung von Artikeln in der Materialbeschaffung die Rede, d.h. eine ABC/XYZ-Analyse ist gefragt! Zur Erinnerung: Die ABC-Analyse ermittelt den Verbrauchswert des Materials: A-Material hat einen hohen Verbrauchswert (70% Anteil am Gesamteinkaufsvolumen, aber nur 15% Anteil an der Einkaufsmenge), B-Material einen mittleren (vielleicht 20% zu 40%) und C-Material einen niedrigen (beispielsweise 5% zu 60%). Meistens stellt man fest, das der Aufwand für die Beschaffung von C-Artikeln (Papier, Kugelschreiber, Toilettenpapier, Tafelschreiber, etc.) überproportional hoch ist. Die XYZ-Analyse ermittelt die Vorhersagegenauigkeit des Bedarfs: X-Bedarf hat eine hohe Vorhersagegenauigkeit (gleichbleibender Verbrauch mit geringen Schwankungen), Y-Bedarf eine mittlere (schwankender Verlauf, z.B. saisonabhängig) und Z-Bedarf eine niedrige (unregelmäßiger Verbrauch mit starken Schwankungen oder sporadischem Bedarf).

Wenn Sie aus Sicht des Einkaufs in einem Diagramm den Beschaffungswert (ABC) über die Beschaffungshäufigkeit (XYZ) darstellen und in die Schnittpunkte den Stückanteil und Wertanteil der Artikel eintragen, bekommen Sie einen guten Überblick über die Lage: AX-Artikel (teuer, wenig, konstant) sollten sicher verbrauchssynchron nach einer Regel automatisch beschafft werden, AZ-Artikel (teuer, wenig, sporadisch) sollten einzeln bei Bedarf beschafft werden und C-Artikel sollten wahrscheinlich immer bei Angeboten in Mengen auf Vorrat beschafft werden. Mehr zu diesem Thema finden Sie unter [L32]. Nach mehreren Interviews mehrerer Akteure haben Sie als Analytiker hier sicherlich konkretes Optimierungspotential erkannt, das Sie anhand eines Diagramms auch objektiv belegen können.

Vielleicht hat der Kunde vor Ihnen auch schon einen Unternehmensberater mit der Analyse und Optimierung des Geschäftsmodells beauftragt, so dass Sie diese Erkenntnisse bereits vorhanden sind (der erste Teil dieses Satzes trifft recht häufig zu, der zweite leider nicht). Man muss also zu Beginn der Geschäftsprozessanalyse mit dem Management des Kunden die eigene Rolle und Aufgabe möglichst genau eingrenzen: Eigentlich sollen wir Softwerker ja nur ein Programm schreiben, aber in Wirklichkeit müssen wir halt erst mal erarbeiten, was das Programm eigentlich machen soll! Ich sage immer: "In der Pre-Analyse-Phase stecken wir unseren Claim ab!"

Mit diesen Erkenntnissen gewappnet, kann durch ein weiteres Gespräch mit dem Management geklärt werden, welche Teile dieses Geschäftsmodellausschnitts von der Software wirklich unterstützt werden sollen; hier wird das Management natürlich von Ihnen als erfahrenen Softwerker Vorschläge zur Entscheidungsgrundlage erwarten, aber die eigentliche Entscheidung trifft natürlich letztendlich immer der Kunde! Daraus können diese Anforderungen entstehen: "Bei C-Artikeln müssen die Staffelpreise verschiedener Lieferanten verwaltet werden können, um die turnusmäßige Beschaffung optimieren zu können. Für AZ-Artikel sollten bei Bekanntwerden von Aktionen aus Presse etc. die Lieferanten, die Aktionsdauer und der Einzelpreis hinterlegt werden können, damit beim Auftreten des sporadischen Bedarfs möglichst schnell über den Einkauf entschieden werden kann. Eine Auswertung über Einkaufsdatum, -menge und -preis der beschafften Artikel muss für einen vorgebbaren Zeitraum möglich sein, damit eine weitere Optimierung möglich ist."

Zur Erinnerung: beim Sammeln von Anforderungen geht es darum, was das System können soll und warum es das können soll; wie das mit dem System gemacht wird, ist Sache der späteren Analyse. Aus den Geschäftsprozessen und Anforderungen ist aber schon erahnbar, welche Anwendungsfälle das System später bekommen wird: ein Anwendungsfallpaket "Einkauf von Verbrauchsmaterial" könnte Anwendungsfälle wie "Verwaltung von Staffelpreisen", "Aufnahme von Aktionen", "Preisermittlung für Artikel" oder "Auswertung der Einkäufe" (ein Report) enthalten.

Ggf. entscheidet das Management nach einer Abschätzung der Aufwände der Anwendungsfälle später, dass die Software in einem ersten Modul noch nicht die "Auswertung der Einkäufe" enthalten muss, so dass die Software eher einsatzbereit ist, zunächst nicht so teuer ist, weniger getestet werden muss und später in einer zweiten Version um diese Funktion nachgerüstet werden kann. Ferner könnte aufgrund der Ermittlung des Einsparpotentials die Anforderung der C-Artikel eine höhere Priorität erhalten als die der AZ-Artikel. So erhalten Sie bereits Hinweise für Releaseplan, Projektplan, Iterationsplan, etc.

Die Anwendungsfälle werden dann in der späteren Phase "Anforderungsanalyse" genauer definiert (nach den ersten Ideen kann sich da noch vieles ändern) und als Geschichten genauer beschrieben sowie mit Prototypen unterstützt. Dann kann sich der jeweilige Akteur des Kunden auch schon mal ein Bild seiner späteren Software machen, gedanklich seinen Prozess damit durchspielen und so die Software schon vor der Erstellung auf Alltagstauglichkeit testen. Parallel dazu kann aus den Geschäftselementen eine erste konzeptionelle logische Sicht auf ein Klassenmodell erstellt werden, so dass auch die Entwickler sich schon mal ein Bild von der Komplexität und Implementierbarkeit machen können. Insbesondere die Architekturvorschläge der Designer müssen mit den technischen Anforderungen zur Infrastruktur des Kunden in Deckung gebracht werden können.

Sie sehen an diesem Mini-Beispiel schon, wie man in der Geschäftsprozessanalyse und Anforderungssammlung die Sichten des Managements und der Akteure zusammenbringen kann, aus dem Speziellen das Allgemeine zur Findung von Gesetzmäßigkeiten ableiten kann, die komplexen Teilziele dadurch in konkrete einzelne Anforderungen zerlegen kann und Aussagen zur Machbarkeit und zum Aufwand sowie Empfehlungen zur weiteren Vorgehensweise ableiten kann.

Weitere Beispiele

Die Termine und Ergebnisse der Projektleitungscontrollingsgespräche müssen systematisch dokumentierbar sein. (Wie sieht hier die fachliche Systematik aus?)

Die Entwicklung der Wirtschaftsplananmeldungen muss verfolgt werden können.

Die Kostenermittlung muss nach zukünftigen Anlagegütern getrennt erfolgen können.

Eine Übersicht über die terminliche Fertigstellung der Betriebsanlagen muss abrufbar sein.

Das Leistungsbild "Baugrund" muss mitsamt den Aspekten Boden, Belastung, Entsorgung und Wege berücksichtigt werden.

Die Baustellenprüfungen müssen wegen der uneinheitlichen Durchführungen mit einer flexiblen Checkliste unterstützt werden. (Was heißt hier flexibel? Heißt "unterstützt" auch "vor Ort"?)

Im Bestellmodul von SAP können Stornos erstellt werden, deren Zuordnung zu den in ... vorhanden Aufträgen möglich sein muss.

Nachträge/Mehrkostenanmeldungen müssen geführt werden können, ohne dass dafür eine neue Nummer generiert werden muss.

Die Neuentwicklung muss auch Projekte unterstützen, die über eine Kostenstellennummer statt Projektnummer geführt werden.