Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Software-Analyse: Geschäftsprozesse

    Jörg Hinrichs

    Ich sitze dem stellvertretenden Geschäftsführer eines mittelständischen Einzelhandelsunternehmens gegenüber und habe gerade die neue Software präsentiert, die ich für sein Unternehmen entwickelt habe.

    “Sieht gut aus, das gefällt mir”, sagt er gerade. Ich lehne mich entspannt in meinem Stuhl zurück und freue mich, dass alles so gut geklappt hat. Dann setzt er hinzu: “Aber sagen Sie mal, wo ist denn die Software, die Sie für mich erstellen sollten?”

    Das ist jetzt mittlerweile ca. 15 Jahre her, aber es blieb mir als einer der unangenehmsten Augenblicke in meiner beruflichen Laufbahn in Erinnerung. Nachdem ich den ersten Adrenalinstoß verdaut hatte, fragte ich vorsichtig nach, was er damit meine. Im nachfolgenden Gespräch stellte sich heraus, dass die Software zwar die gewünschten Informationen verwalten konnte (es handelte sich um Artikeldaten für einen Katalog), dass sie aber die Arbeitsabläufe innerhalb der Firma nur schlecht unterstützte.

    Beispielsweise sollte die Möglichkeit bestehen, zu einem Artikel ein Foto zu hinterlegen. Nun wollten die Anwender die Fotos aber nicht alle selbst mühsam eintragen (die Datenbank war relativ groß), sondern es sollten jeden Morgen alle neu erstellten Fotos aus einem vorgegebenen Verzeichnis automatisch in die Datenbank importiert werden. Es gab noch einige weitere Fälle, wo die Funktionalität der Anwendung so nicht ausreichend war.

    Wo liegt die Problemursache…?

    Das ist etwas, was ich in der Softwareentwicklung immer wieder erlebt habe: Bei der Analyse wird aufgrund einer Anforderung eine Funktionalität erstellt, die aber hinterher den Arbeitsablauf des Anwenders nicht oder unzureichend unterstützt. Wie kommt es dazu?

    In meinem Fall gab es gleich mehrere Dinge, die das begünstigt haben:

    1. Vor der Präsentation gab es kein direktes Gespräch zwischen mir und dem Kunden, sondern die Auftragserteilung lief über einen Entwickler, welcher selbst keine Kapazitäten hatte und mich deshalb dafür engagierte. Wenn man wirklich alles komplett richtig macht, kann das vielleicht bei kleineren Aufträgen funktionieren. Aber ganz ehrlich: Ich habe das in fast 20 Jahren Softwareentwicklung noch nicht erlebt.
      Was ich dagegen ständig erlebe ist, dass auch nach einer gründlichen Analyse viele kleine Details für die Entwicklung geklärt werden müssen. Das sollte am Besten direkt zwischen dem Entwickler und dem Abnehmer der Software stattfinden. Ich habe auch schon öfter erlebt, dass sich noch eine Instanz in Form einer weiteren Person dazwischen befindet: Im besten Fall kostet das einfach nur mehr Zeit, im schlechtesten Fall gehen dabei wichtige Informationen verloren.
    2. Es gab keine schriftliche Spezifikation der Anwendung. Das an sich muss nicht unbedingt ein KO-Kriterium sein: Ich habe auch heute noch Kunden, für die ich Software aufgrund von mündlichen Gesprächen und mit relativ losen Spezifikationen entwickle. Allerdings besteht dann gleichzeitig ein enger Kontakt zum Kunden (meistens findet die Entwicklung direkt vor Ort statt). Und es handelt sich um Aufwände, die meist im Bereich von 1 Woche liegen (auf keinen Fall mehr als 2 Wochen). Ansonsten sind Probleme vorprogrammiert. Es gibt trotzdem viele gute Gründe, eine Anforderung schriftlich festzuhalten. Das hier zu beschreiben würde den Rahmen dieses Themas aber ein wenig sprengen.
    3. Die Arbeitsabläufe in Bezug auf die Funktionalität waren nicht kommuniziert worden. Das halte ich in diesem Fall für das wichtigste Problem und das ist auch das Thema dieses Artikels. Ohne die Beschreibung eines Arbeitsablaufes gibt es nur eine statische Sicht auf die Anwendung. Sozusagen eine Feature-Liste. Ich weiß, welche Daten relevant sind, aber ich weiß nicht in welcher Reihenfolge sie verarbeitet werden und in welcher Beziehung sie zueinander stehen. Das ist aber für eine Software, die für den Kunden wirklich von Nutzen sein soll, unverzichtbar.

    …und was kann man dagegen tun?

    Um in Bezug auf Arbeitsabläufe bzw. Geschäftsprozesse die richtigen Informationen vom Kunden zu erhalten ist es sehr hilfreich, von vornherein die richtigen Fragen zu stellen. Ein guter Businessanalyst mit entsprechender Erfahrung ist sich dieser Tatsache bewusst. Häufig findet die Analyse aber auch durch “ganz normale” Entwickler selbst statt, die dafür nicht speziell ausgebildet wurden und deshalb auch nicht gelernt haben, darauf zu achten.

    Softwareentwickler denken in diesem Zusammenhang eher wie Ingenieure. Sie gehen zum Kunden und sagen: “Ich bin Bob, der Baumeister, was soll ich für Dich bauen?”. Und der Kunde fängt an zu beschreiben, welche Features die Anwendung beinhalten soll. Das ist fast immer die statische Sicht auf die Anwendung. Sie ist natürlich wichtig, aber sie reicht eben auch nicht aus.

    Beschreibungen von Geschäftsprozessen erhält man jedoch eher wenn man fragt: “Was tust Du (und wie soll die Software Dir dabei helfen)?”. Durch eine Beschreibung der eigenen Tätigkeit erhält man automatisch eine Vorstellung vom Arbeitsablauf. Wenn man ganz viel Glück hat, dann gibt es auch eine Orga-Abteilung in der Firma des Auftraggebers, die Ihnen schöne Diagramme mit ausführlichen Beschreibungen, erstellt von ausgebildeten Businessanalysten zur Verfügung stellt. Na ja, ich hatte bisher noch nicht so viel Glück :).

    Also, fassen wir noch einmal zusammen:

    • Am Besten sorgen Sie dafür, dass zwischen dem Entwickler und dem Kunden ein direkter Kontakt für die Klärung von Fragen besteht.
    • Fragen Sie nicht was der Kunde braucht – fragen Sie was er macht!
    • Bestehen Sie auf einer schriftlichen Spezifikation.
    • Prüfen Sie die Analyse auf die Beschreibung von Geschäftsprozessen. Das ist ganz einfach und es kann auch jemand machen, der nicht so tief in der Materie drinsteckt.

    Zu guter Letzt

    Die Definition von Anforderungen an eine Software ist ein wirklich schwieriges Unterfangen, wenn man es gut machen will. Dazu gehört noch deutlich mehr als Geschäftsprozesse zu erfassen. Um nur ein Beispiel zu nennen: Es ist sehr schwer zu ermitteln, ob Anforderungen vollständig beschrieben sind oder nicht. Welcher Entwickler kennt nicht den Kunden, der sich die fertige Anwendung anschaut und sagt: “Toll! Könnten Sie nicht auch noch…”.

    Mit Geschäftsprozessen allein haben Sie also noch nicht alle Schwierigkeiten im Griff. Aber ohne Geschäftsprozesse ist die Wahrscheinlichkeit groß, dass Sie in Schwierigkeiten geraten.

    3 Comments

3 Responses to “Software-Analyse: Geschäftsprozesse”

  1. I’m still learning from you, while I’m improving myself. I absolutely love reading all that is posted on your website.Keep the information coming. I loved it!

  2. [...] Software-Analyse: Geschäftsprozesse [...]

  3. Hi,

    ich bin Wirtschaftsinformatik Student und dein Beitrag hat mir wirklich geholfen. Ich muss grad eine Arbeit über ein fiktive Softwareentwicklung schreiben und bin unteranderem für die GP zustädnig!
    Also danke ;)

Leave a Reply