S. 49631. Wie man nicht Software kauft - und wie doch

31.1. Warum das Thema wichtig ist

Die Auswahl neuer Software ist eine dieser scheinbar harmlosen Aufgaben, die sich rückblickend als Stolperstein herausstellen können - oder als entscheidender Hebel für Effizienz und Zufriedenheit im Kanzleialltag. Trotzdem wird diese Aufgabe oft als etwas betrachtet, das man „so nebenbei“ machen kann, in der Hoffnung, dass die Anbieterinnen schon erklären werden, wozu man ihr Produkt braucht. Der Markt an Legal-Tech-Produkten ist mittlerweile groß und manchmal auch unübersichtlich. Auf Konferenzen und oft auch im Gespräch mit Kollegen erhält man den Eindruck, dass es wohl für jede Aufgabenstellung auch ein entsprechendes Softwareangebot gibt. Das verleitet, sich einfach mal ein paar Termine mit Legal-Tech-Anbieterinnen auszumachen, am liebsten natürlich bei denen mit dem besten Marketing und den überzeugendsten Verkaufsberaterinnen.

Dieser Ansatz ist jedoch gefährlich und nahezu eine Garantie für Frust und unnötige Aufwendungen.

Software ist kein Selbstzweck. Sie soll bestehende Probleme lösen oder Potenziale heben. Wenn der Auswahlprozess allerdings nicht strukturiert wird oder die Einführung nur halbherzig angegangen wird, ist das Ergebnis Frust, Schattenprozesse und vergeudete Ressourcen.

Dieses Kapitel ist eine Einladung zur Selbstreflexion und zum Perspektivenwechsel: Statt nur über Best Practices zu sprechen, werfen wir doch einen ehrlichen Blick auf die Fehler, die wir immer wieder machen - und wie man es besser lösen kann.

31.2. Wie man nicht Software kauft

31.2.1. Ohne Zieldefinition

Ein Klassiker: Man weiß, „da müsste es doch was geben“. Vielleicht rauft man sich gerade vor Wut die Haare, weil ein Arbeitsprozess mühsam und zeitraubend ist - „die Technik“ wird da doch sicher etwas liefern können, womit man sich diese Arbeit sparen kann. Vielleicht hat man aber auch gerade ein Posting zu einem Tool auf LinkedIn gesehen, bei einer Konferenz mit Providern getratscht oder eine Empfehlung von Kolleginnen bekommen. Was fehlt: eine konkrete Zieldefinition.

Wer ohne klare Vorstellung davon startet, was verbessert werden soll, landet leicht bei einer Lösung, die viele Funktionen bietet - aber keinen echten Nutzen. Wer direkt mit Produktdemos startet, riskiert dabei auch von enthusiastischen VerkäuS. 497ferinnen das Blaue vom Himmel versprochen zu bekommen. Dabei wird gerne vergessen, dass das Sales Team nicht dafür da ist, der Kundin die beste Lösung für ein individuelles Problem zu liefern, sondern aus einem bestimmten Grund: um zu verkaufen.

31.2.2. Aus reiner FOMO (Fear of missing out)

FOMO - die Fear of missing out - macht auch vor Kanzleien nicht halt. Gefühlt jeden Tag erscheint eine neue Pressemitteilung oder ein Social-Media-Posting zum Thema Legal Tech und Legal Tech Investments und auch die Reports von Gartner, Lexis Nexis und Thomson Reuters zeigen, dass Kanzleien immer mehr in Technologie investieren. Wenn ein Tool gerade „hip“ ist, erscheint es logisch, es ebenfalls einzuführen. Leider ist das keine Strategie! Denn was in einer Großkanzlei funktioniert, kann in einer Boutique-Kanzlei schnell zur Überforderung führen - sowohl technisch als auch kulturell.

31.2.3. Entscheidung ohne Einbindung des Teams

Nicht selten entscheidet eine Person über ein Tool, das am Ende das gesamte Team betrifft. Das Problem: fehlende Akzeptanz. Die Bereitschaft zur Nutzung sinkt, wenn Mitarbeiterinnen keinen Einfluss auf die Auswahl hatten oder keinen Input liefern konnten. Das Tool wird zum Fremdkörper oder sogar zum Störenfried oder zur Bedrohung - und bleibt in der Folge ungenutzt.

Ein weiteres Problem bei dieser Herangehensweise ist, dass dabei leicht Prozessanforderungen übersehen werden, die zu erheblichen - und teils sehr teuren - Mehraufwänden führen können. Nicht nur die direkten Userinnen sollten in die Auswahl miteinbezogen werden, auch andere Abteilungen, wie beispielsweise HR oder Buchhaltung, sollten die Gelegenheit haben, Input zu liefern, sofern sie indirekt mit der neuen Softwarelösung zu tun haben.

31.2.4. Fokus auf Features statt Nutzen

Software-Demos sind beeindruckend. Viele Funktionen, viele Klicks, viele bunte Dashboards. Dazu ein (hoffentlich gut) geschultes Verkaufsteam, das das Blaue vom Himmel verspricht und schon ist man überzeugt, hier „the next big thing“ vor sich zu haben und fragt sich, wie man je ohne diese revolutionäre Technologie überleben konnte. Doch was braucht man davon wirklich? Wer sich in Features verliert, riskiert es eine Lösung zu kaufen, die zwar viel kann, aber nichts besser macht. Passt das Tool überhaupt zu meinen Arbeitsabläufen? Und wenn nicht, wie viel kann ich an meinen Arbeitsabläufen verändern und verbessern, um gemeinsam mit Technologie besser zu arbeiten? Was bedeutet das an Aufwand und zusätzlichen Ressourcen? Wie viele use cases kann ich mit diesem Tool tatsächlich umsetzen?

S. 49831.2.5. Ohne Testphase oder Plan zur Einführung

Der letzte große Fehler: Das Tool wird gekauft, die Freude ist groß. Und dann? Nichts passiert - keiner verwendet es, der erhoffte Benefit bleibt aus. Warum? Es fehlt ein Einführungsplan. Pilotphasen, User Acceptance Testing, Datenmigration, Schulungen: all das wird oft unterschätzt oder sogar schlichtweg vergessen. Als Folge davon hat man vielleicht sein Kanzleilogo in der illustren Liga der Kunden des Softwareanbieters auf dessen Website, für einen selbst hat sich allerdings nicht viel verändert. Nur das Geldbörsel ist schlanker geworden!

31.3. Wie man doch Software kauft

Wer bei dem einen oder anderen Punkt im letzten Kapitel vergangene Vorgehensweisen erkannt hat, fragt sich jetzt sicher, wie man es besser machen kann. Eines vorweg: neue Wege sind anfangs immer etwas steiniger zu begehen. Eine neue Software einzuführen, kostet Zeit, Geld und auch Energie. Durch einen strukturierten Ansatz beim Softwarekauf setzt man allerdings die richtigen Weichen und bleibt flexibel - Fehlentscheidungen können leichter korrigiert werden und Erfolge werden schneller (und messbarer) sichtbar.

31.3.1. Problem erkennen - Ziel definieren

Am Anfang steht die Frage: Was soll sich verbessern? Geht es um schnellere Mandatsabwicklung, mehr Übersicht im Team, bessere Kommunikation mit Mandantinnen? Oder sollen bestimmte Arbeitsschritte automatisiert erledigt werden? Nur wer das Problem kennt, kann eine passende Lösung suchen und später auch bewerten, ob das Tool tatsächlich hilft.

31.3.2. Anforderungen formulieren

Aus der Zieldefinition ergibt sich eine Anforderungsliste. Welche Funktionen braucht es zwingend? Welche sind optional? Dazu kommen rechtliche Anforderungen (DSGVO, Serverstandort), technische Gegebenheiten (Kompatibilität mit bestehender Software) und Usability-Fragen (Sprache, Interface, Support).

31.3.3. Beteiligung des Teams

Die besten Einführungen beginnen nicht mit dem Kauf, sondern mit der Frage: Was braucht ihr? Denn die Menschen, die später täglich mit dem Tool arbeiten sollen, kennen die bestehenden Herausforderungen meist am besten. Sie haben oft klare Vorstellungen davon, was funktioniert und was nicht. Wer frühzeitig diese Perspektiven einholt, vermeidet blinde Flecken in der Anforderungsdefinition und erhöht die spätere Nutzungsbereitschaft deutlich.

Beteiligung bedeutet dabei mehr als eine symbolische Rückfrage im letzten Moment. Vielmehr geht es darum, Nutzerinnen als Expertinnen ihres Arbeitsalltags ernst zu nehmen und sie in Auswahl, Pilotphase und Feedbackschleifen einzubinden.

In der Praxis zeigt sich zudem oft: Das vermeintliche „Technikproblem“ ist in Wahrheit ein Prozessproblem - oder ein Kommunikationsproblem. Genau solche Einsichten entstehen nur, wenn man sich gemeinsam die Zeit nimmt, Bedürfnisse und Abläufe zu reflektieren. Idealerweise passiert das auch gemeinsam in Workshops statt in getrennten (Einzel-)Gesprächen. Das schafft nicht nur bessere Entscheidungen, sondern stärkt auch das Teamgefühl.

31.3.4. Tool-Shortlist und strukturierter Vergleich

Die Entscheidung für Software sollte nicht auf Basis der ersten überzeugenden Demo oder eines besonders geschickten Verkaufsgesprächs getroffen werden. Statt sich für „das Tool“ zu entscheiden, sollte man eine Shortlist erstellen: zwei oder drei Tools, die man gezielt testet.

S. 501Dabei zählen nicht nur Funktionen, sondern das Gesamtbild. Wie intuitiv ist die Bedienung wirklich? Wie gut passt das Produkt in die bestehende Systemlandschaft? Welche Integrationen sind möglich? Und wie sieht es mit dem Support aus? Auch Aspekte wie Datenschutz, Weiterentwicklungsperspektiven, Sprachoptionen und Lizenzmodelle sollten verglichen und systematisch gegenübergestellt werden. Anhand eines strukturierten Vergleichs lässt sich die Entscheidungsgrundlage auch Jahre später noch nachvollziehen - dies kann besonders bei weiteren Softwareentscheidungen oder bei notwendigen Updates sehr hilfreich sein.

31.3.5. Pilotphase mit Plan

Der eigentliche Erfolg liegt in der Einführung. Diese Phase strukturiert zu gestalten ist daher entscheidend. Eine gut geplante Pilotphase - mit klar definiertem Start- und Endpunkt, einem überschaubaren Nutzerinnenkreis und konkreten Zielen - ist der beste Weg, um Stolpersteine frühzeitig zu erkennen und die Implementierung realitätsnah zu gestalten.

Wichtig ist dabei, der Pilotgruppe ausreichend Zeit und Unterstützung zu geben, beispielsweise durch Schulungen, Anleitungen und eine direkte Ansprechperson. Regelmäßige Feedbackschleifen helfen, die Nutzung zu optimieren, Prozesse anzupassen und Akzeptanz aufzubauen. Auch technische Themen wie Datenmigration oder Rechtevergabe sollten frühzeitig vorbereitet und getestet werden. Erst wenn das Tool im Alltag funktioniert, kann es sinnvoll skaliert werden. Die Implementierungsphase ist kein „Go Live“, sondern ein Lernprozess und sollte auch so gehandhabt werden.

31.4. Fazit

Software kann vieles erleichtern - aber nur, wenn man sie bewusst auswählt, sinnvoll einführt und im Alltag verankert. Die größten Fehler passieren nicht bei der Technologie, sondern in den Schritten davor: wenn Ziele nicht klar definiert, Prozesse nicht durchdacht oder Menschen nicht mitgenommen werden.

Wer hingegen strukturiert vorgeht, vom Problem ausgeht und Anforderungen realistisch priorisiert, schafft die Grundlage für eine Lösung, die nicht nur funktioniert, sondern auch tatsächlich genutzt wird. Besonders wichtig ist, sich dabei in Erinnerung zu rufen, dass Einführung von Software kein einmaliger Akt ist, sondern ein Prozess. Fehler sind erlaubt und werden auch garantiert passieren - das ist in Ordnung, solange man daraus lernt!

Digitalisierung ist kein Sprint, sondern eine strategische Entwicklung. Wer dabei den Menschen, die Prozesse und die Kultur mitdenkt, hat die besten Chancen, dass Software wirklich zum Fortschritt wird und nicht zur Belastung.