Softwareentwicklung in Großkanzleien
Andreas Hackbarth, Wirtschaftsinformatiker und seit 2019 Teil des Digital Innovation Hubs bei Noerr, berichtet über seine Erfahrungen mit selbstentwickelten In-House Legal Tech Tools.
Standard Software vs. Eigenentwicklung
Wegen meiner langjährigen Erfahrung als Wirtschaftsinformatiker, Programmierer und Projektleiter für Softwareentwicklung werde ich von Juristen häufig gefragt, ob es Sinn ergibt, wenn Kanzleien in-house Software entwickeln möchten. Hier meine Antwort.
Der Anfang
Zu Beginn scheint alles sonnenklar. Eine große Anwaltskanzlei braucht eine neue Softwarelösung und schickt ihren Projektleiter auf die Reise. Er bekommt dafür idealerweise einen Anforderungskatalog, welchen die Anwälte mit den Support-Mitarbeitern erstellt haben. Der Auftrag: Finde die passende Softwarelösung auf dem Markt. Klingt logisch, schließlich gibt es für fast jedes administrative Problem eine passende Software mitsamt Support und Weiterentwicklung. Aber eine Software von der Stange ist nur eine gute Lösung, wenn der Käufer bereit ist, vom eigenen Anforderungskatalog zumindest teilweise Abstand zu nehmen und seine Arbeitsweise an den „Standard“ der Software anzupassen. Deshalb der erste Tipp: Wer schon vor dem Kauf mit dem Gedanken spielt, bei dem Anbieter anzufragen, ob seine Software noch angepasst werden kann, sollte lieber die Finger davon lassen und sich überlegen, ob eine eigene Entwicklung nicht doch der bessere Weg ist.
Die Entscheidung
Da die Mitarbeiter einer Kanzlei individuelle Anforderungen an ihre IT haben, wird dem Projektleiter häufig klar: Für unser Problem existiert keine passende Software. Eine Eigenentwicklung müsste her. Um sicher zu gehen, dass der existierende Anforderungskatalog nicht bereits überholt ist, bzw. um die Anforderungen detaillierter zu spezifizieren, empfiehlt es sich zunächst, Einzelinterviews mit relevanten Mitarbeitern zu führen. Das Ziel: Die Bestimmung des kleinsten gemeinsamen Nenners (MVP – Minimum Viable Product) für das Produkt über alle Standorte bzw. Bereiche hinweg. Aus diesem gemeinsamen Nenner werden Use Cases entwickelt, welche jeweils einen Arbeitsablauf beschreiben sollten. Weiterhin entsteht ein Backlog für die Umsetzung und vor allem auch eine Abgrenzungsliste mit Funktionalitäten, von deren Berücksichtigung in der Entwicklung abgesehen wird. Nun kann mit der Umsetzung begonnen werden.
Wer sagt es dem Entwickler?
Bei diesem Projekt müssen zwei sehr unterschiedlich gepolte Berufsgruppen – Entwickler und Anwälte – zusammenarbeiten. Damit das nicht in lückenhafter Kommunikation endet, ist ein Vermittler wichtig. Diese Person muss relevante juristische Zusammenhänge verstehen und so übersetzen, dass ein Entwickler weiß, was zu tun ist. Diese Vermittler heißen in anderen Branchen meist Business Analyst, unter Juristen ist es der Legal Engineer.
Es kommt auf die Details an
Wie bei jeder Produktentwicklung wird man auch bei der Softwareentwicklung während der Umsetzung auf Anforderungen oder Herausforderungen stoßen, welche am Anfang nicht gesehen bzw. berücksichtigt wurden. Deshalb ist es für die Projektleitung unabdingbar, für Rückfragen zur Verfügung zu stehen und eine schnelle Klärung herbeizuführen. Details machen den Unterschied: allein das Umbenennen einer Schaltfläche kann zu einer Akzeptanz unter den Mitarbeitern führen, die vorher fehlte – obwohl sich an der Funktionalität nichts geändert hat. Anwälte wie auch ihre Mitarbeiter müssen genau arbeiten und sind detailverliebt. Das erwarten sie daher auch von ihrer Software.
Testen spiegelt nicht die Realität wider
Ist die Software testbereit, empfiehlt sich ein detaillierter Testkatalog. Er ist zugleich eine Anleitung, wie die neue Software zu bedienen ist. Die Testergebnisse sind ein wichtiger Input für das Projektteam und zeigen nicht nur, ob die Software syntaktisch funktioniert, sondern auch, ob sie Akzeptanz bei dem Benutzer findet.
Wenn die Tests erfolgreich abgeschlossen sind und es eigentlich geschafft wäre, folgt der schwierigste Part: Die Software muss das Vertrauen ihrer künftigen Benutzer gewinnen. Empfehlenswert ist es, eine Pilotphase mit einem repräsentativen Querschnitt der Benutzer durchzuführen, die zukünftig produktiv mit der Software arbeiten sollen. Dadurch wird klar, ob die Software auch langfristig die Akzeptanz ihrer Benutzer gewinnen wird.
Die Vorbereitung zum GoLive
Nach der erfolgreichen Pilotphase, in welcher die Software weiter optimiert werden kann, gilt es, den GoLive für die ganze Kanzlei vorzubereiten. Neben den Schulungen für die zukünftigen Benutzer ist es auch wichtig, die interne Kommunikation und den IT-Support an Bord zu haben. Denn die erstgenannte Einheit kennt die richtigen Worte und Wege, um alle Mitarbeiter zu erreichen und zu überzeugen. Mit dem IT-Support muss abgestimmt werden, was auf sie zukommen könnte. Schließlich werden die Benutzer dort mit ihren Problemen aufschlagen. Durch das Bereitstellen eines Katalogs mit möglichen Fragen und Hilfestellungen können die Benutzer sofort von der Professionalität des Produktes überzeugt werden.
Nach dem GoLive ist vor dem GoLive
Grundsätzlich gilt, dass eine Software niemals zu 100 Prozent fehlerfrei und auch niemals fertig sein wird. Sobald die Mitarbeiter mit der neuen Software arbeiten und erkennen, wie sie ihren Arbeitsalltag noch weiter vereinfachen und automatisieren können, beginnt die Planung für die nächste Version.
Wann ist die Software / das Projekt erfolgreich?
Im Projektmanagement spricht man vom magischen Dreieck. Die klassische Lehre besagt: Habe ich in dem gegebenen Rahmen (Zeit, Budget und Qualität) geliefert, war das Projekt erfolgreich. Der wichtigste Faktor bei einer Softwareeinführung ist aber die Akzeptanz bei den Benutzern. Was nutzt es der Kanzlei, wenn die Software rechtzeitig „Fertig“ geworden ist und das Budget eingehalten wurde, die Benutzer aber durch fehlende Funktionalität keine Lust oder Möglichkeit haben, die Software einzusetzen?
Fazit
Großkanzleien können also eigene Software entwickeln, wenn die Voraussetzungen und das Mindset gegeben sind. Dabei sollte das Projektteam interdisziplinär aufgestellt sein, um möglichst viele Facetten und Blickweisen zu vereinen. Ein weiterer Tipp: Lösen Sie sich von dem Wunsch, von Anfang an Alles planen zu können und glauben Sie nicht, genau zu wissen, was sie mit der Software wollen. Im Laufe des Projektes werden sich die Begehrlichkeiten ändern bzw. weiterentwickeln.
Mit einer agilen Softwareentwicklung kann man diesen Prozess besser abfangen und schneller und zielgerichteter die gewünschte Software umsetzen. Dieses verlangt aber auch Personaleinsatz über den Softwareentwickler und den Legal Engineer hinaus. Zudem sollte die Projektleitung einen möglichst direkten Weg zu Entscheidern haben, weil alle übrigen Abteilungen und Einheiten mit eigenen Projekten beschäftigt sind und sie das Softwareprojekt unter ungünstigen Umständen im entscheidenden Moment behindern oder gar ungewollt stoppen können, wenn es bspw. gerade auf ihre Kooperation ankommt.
Autor: Andreas Hackbarth ist Wirtschaftsinformatiker und seit 2019 Teil des Digital Innovation Hubs bei Noerr. In den 15 Jahren zuvor hat er Projekte in der Software Entwicklung zunächst durchgeführt und später geleitet (u.A. bei Arvato-Bertelsmann und Vodafone Kabel Deutschland).
