30 Jahre Softwareunternehmer

Im 1996 haben wir die Vertec gegründet, von Anfang an mit dem Ziel, Standardsoftware für Dienstleister zu machen. Heute sagt man dem «ERP und CRM», damals hiess es in unserem Business Plan: «Wir wollen eine umfassende und technologisch führende Branchenlösung für EDV-Bedürfnisse von Anwaltskanzleien entwickeln (TIM-Office), anbieten und weiterentwickeln».

Das haben wir geschafft! Am Begriff «EDV» (für die Jüngeren: das heisst «elektronische Datenverarbeitung») sieht man aber, wie viel Zeit vergangen ist. Die Firma hiess von Anfang an Vertec, das Produkt hiess in den Anfangsjahren aber «TIM» von «Time is Money». 2004 haben wir die Software dann gleich benannt wie die Firma. Auch hat sich bald gezeigt, dass es für unsere Software auch sehr gute Nachfrage bei allen projektorientiert arbeitenden Dienstleistern gibt, nicht nur von Anwaltskanzleien.

In diesem Blogartikel möchte ich von meinen Erfahrungen als Standardsoftware-Unternehmer berichten, der 30 Jahre lang seinem Produkt und seinen Kunden treu geblieben ist – und wie man das in der vermeintlich so schnelllebigen Software-Welt schafft.

Eine Organisation kann nur etwas gut

Ich bin der Meinung, dass eine Organisation oder Firma nur etwas gut kann und sich auch auf das konzentrieren sollte. In unserem Fall ein «CRM und ERP für Dienstleister». Nicht ein «ERP das alles kann™». Mit gutem Grund machen wir keine Lohnverarbeitung oder Fibu dazu, nicht mal ein Lager oder einen Webshop – das sind keine Kernanforderungen unserer Kundenbranchen. Ausserdem gibt es schon viele Systeme, die das (sehr gut) können und zweitens kommt es nicht gut, wenn ein CRM Hersteller auch eine Fibu macht; genauso wie wenn ein Fibu-Hersteller ein CRM macht, dass immer noch nach Fibu riecht.

Kann man eine ganze Organisation auf ein bestimmtes, eng gefasstes Produkt mit klaren Rändern einschwören, gewinnt man viele Vorteile, von der Produktentwicklung über Marketing und Verkauf bis hin zum Consulting, Projektleitung und Support – niemand muss sich überlegen, mit was für einem Produkt oder Produktlinie er oder sie sich heute beschäftigen soll. Man kann die gesamte Schaffenskraft aller Menschen im Unternehmen auf ein Ziel fokussieren.

Natürlich weiss ich, dass es Beispiele gibt von Firmen, die auch anders erfolgreich wurden – aber es sollte uns bewusst sein, dass alle Beispiele in der IT-Branche aus einer anderen Epoche stammen. Und Konglomerate wie Siemens sich fast jedes Jahr neu orientieren und Firmen kaufen resp. verkaufen (oder an die Börse bringen). Ob die Mitarbeitenden in jedem Fall jeden Schritt mitmachen und dabei noch produktiv arbeiten können? Und ob alle Kunden verstehen, was genau die aktuelle Ausrichtung des Unternehmens ist?

Die nächste technologische Klippe kommt bestimmt

Egal wie modern und technologisch führend man sein Produkt designt: in 10 Jahren wird es das nicht mehr sein und es kommt eine technologische Klippe, die man meistern muss. Es ist das Privileg von jüngeren Entwicklern, die Technologie, mit der man sich aktuell beschäftigt, als absolut überlegen zu betrachten und sogar zu denken, dass sie für Ewigkeit bestimmt ist. Als langjähriger Software-Unternehmer und Produktmanager weiss ich: das stimmt nicht. Schneller als man denkt, ist die Plattform, in die man so viel reingesteckt hat, obsolet oder kann mit den neuen Anforderungen nicht mehr mithalten.

Welche technologischen Klippen mussten wir in den vergangenen 30 Jahren meistern?

1. Mitte-Ende 90er Jahre: das Aufkommen LAN Technologie bei den Kunden, von SQL-Servern und Client-Server Technologie
2. ab ca. 2000: Web-Frontends als neue Anforderung
3. ab ca. 2005: mobile Applikationen, zuerst auf speziellen Geräten wie Handhelds, später dann Smartphones
4. ab ca. 2010-15: die Erwartung, dass man die Software von überall her bedienen kann (ohne Terminal Servers!), was dann auch Cloud Angebote ermöglicht.
5. ab ca. 2020 unter dem Stichwort «Digitalisierung» die Anforderung der Kunden, dass ein ERP auch ehemalige «Randbereiche» wie DMS nahtlos integrieren kann und sich sehr offen zeigt bezüglich der Integration von Daten und Diensten.

Die aktuelle technologische Klippe ist sicher die sinnvolle Integration von AI Möglichkeiten ins ERP und CRM. Obwohl es Korrekturen am Markt geben wird wegen doch sehr grossen Investitionen in AI Infrastruktur, gehe ich sehr davon aus, dass die Technologie sich breit durchsetzen wird. Zu gross ist der heute schon erzielbare und sichtbare Nutzen.

Und genau das ist der gute Ratgeber, wenn der nächste Hype naht. Sich fragen, welchen Nutzen man mit einer Technologie bei den Kunden überhaupt stiften will. Für Blockchain und Metaverse gab es zwar Anfragen zu unserer «Strategie», einen echten Anwendungsfall im Bereich ERP und CRM konnte aber niemand ausmachen. So flachte der Hype dann auch schnell wieder ab.

Architecture eats Technology for Breakfast

In Abwandlung des berühmten Zitats von Peter Drucker («culture eats strategy for breakfast») behaupte ich: die Architektur bestimmt, ob das eigene Produkt sich gewandelten Anforderungen stellen kann, nicht die Technologie. Eine zukunftsfähige und stabile Softwarearchitektur lässt neue Technologien und Anwendungsfälle zu, aber die modernste Technologie ohne eine geeignete Architektur ist auf längere Sicht eine Sackgasse.

Aber was macht denn eine zukunftsfähige Software-Architektur aus? Meiner Meinung nach muss man sich mit (mindestens) folgenden Fragen auseinandersetzen:

• Wie kapselt man die Businesslogik, damit sie niemals doppelt vorhanden ist? Ich habe «modernste» Web Apps gesehen, bei denen dann für ein REST API die SQL's nochmals wiederholt wurden. Wenn man dann noch einen Zugang auf die Objekte haben will (z.B. für einen MCP Server), wird das Problem immer grösser.
• Wie wird die (Standard-)Software an die Bedürfnisse der Kunden angepasst? Geschieht dies auf eine updatefähige Art und Weise oder hat man (im schlimmsten Fall) sogar noch spezielle Builds für gewisse Kunden?
• Software ist immer in Schichten aufgebaut, die miteinander kommunizieren. Sind diese Schichten klar benannt und bekannt und kommunizieren diese nur mit der jeweiligen Schicht weiter «oben» oder «unten»? Beispiel Datenpersistenz: Natürlich ist der eingesetzte Datenbankserver eine eigene Schicht (weil eine eigenen Software), aber welche Schichten in der eigenen Software greift unabhängig auf die Datenbank zu? Anderes Beispiel UI: wie kommt das UI an berechnete Daten ran, wie einer Laufsumme? Wird diese vom UI berechnet oder von einer Schicht weiter unten (die die Logik kapselt)?

Evolution statt Revolution – nie versuchen, alles neu zu machen

Erscheint die nächste technologische Klippe unerreichbar aus Sicht der aktuellen Architektur und Technologie, so wird häufig (aus meiner Sicht: zu häufig!) der Entscheid gefällt, alles neu zu machen. Also die ganze bestehende Software komplett neu zu bauen und das «alte» System irgendwann abzulösen. Verführerisch wirkt diese Strategie vor allem, weil die jungen Mitarbeiter gerne neue Dinge anpacken und auch der Überzeugung sind, dass sie das in kurzer Zeit hinkriegen.

Ich behaupte: Diese Strategie führt in den allermeisten Fällen in den Abgrund. Die Gründe sind vielfältig:

• Der Funktionsumfang der bestehenden Applikation und die diversen Anwendungsfälle bei den Kunden werden massiv unterschätzt. Man stelle sich eine Fibu vor: bis man nur ein «Minimum Viable Product» (MVP) hat, dauert es sehr lange, denn niemand mehr kauft eine einfache Fibu mit Soll-Haben und Kontoauszügen wie in den 80er Jahren. Nein, die Anforderungen sind gigantisch gross und was man nicht vergessen darf: die bestehenden Kunden haben jetzt eine voll ausgebaute Applikation und werden sicher nicht auf einen MVP wechseln, nur weil dieser bunter und die Buttons grösser sind.
• Weil der Funktionsumfang der bestehenden Applikation und die Anforderungen der Kunden massiv unterschätzt werden, wird ebenso massiv unterschätzt, wie lange so ein Projekt dauert. Aber wie viel Zeit und Budget hat man? Und wie lange sind die bestehenden Kunden bereit zu warten?
• Die Einführung einer vollständig neuen Produktgeneration mit neuen Ideen und Prozessen wird bei jedem einzelnen Kunden zu einem Migrationsprozess führen. Selbst wenn die neue Software (fast) alles macht wie die Alte, wird die Auswirkung bei den Kunden meistens stark unterschätzt – für die Kunden ist das wie eine Migration auf eine neue Lösung, und hier kommt dann ein anderer Grundsatz zum Tragen: Kunden sind einem Produkt treu, das ihnen laufend Nutzen stiftet, nicht einer Produktfirma. Selbst wenn die neue Lösung sämtliche bestehenden Bedürfnisse befriedigt, wird man mindestens 30% der Kunden verlieren, weil sie sich vor dem Hintergrund einer vollständig neuen Softwarelösung gleich auf dem Markt umschauen gehen.
• Auch den Effekt auf die eigene Belegschaft sollte man genau analysieren: weil die Entwicklung des neuen Produkts meistens durch ein anderes, neues Team erfolgt, hat man auf einmal 2 Teams: eines, dass die «geilen» neuen Technologien anwenden darf, Narrenfreiheit geniesst, weil das Produkt ja noch keine Kunden hat und auch strategische Priorität geniesst. Und ein anderes, welchen den «alten Scheiss pflegen und sich zu Kundenbugs äussern muss. Gleichzeitig aber die Cashcow im Unternehmen ist durch bestehende Kundenverträge. Unschwer, sich die Konflikte vorzustellen: Wer würde nicht lieber im ersten Team arbeiten?

Wie schafft man es denn nun, sich auf Basis des Bestehenden weiterzuentwickeln? Die Antwort darauf ist alles andere als trivial und hängt stark davon ab was für eine Architektur man hat, irgendwelche Lock-in Technologien (Bsp. Oracle Forms») verwendet, etc. Ich behaupte aber: egal wie desolat die aktuelle Situation ist, mit genügend Fantasie und Investition lässt sich ein Weg finden. Es fängt damit an, dass man die bestehende «Legacy» als «Asset» anerkennt, nicht als «Liability» – das Wort kommt ja prominent vor im Totschlagargument der «technical debt» oder «technische Schulden».

Functionality matters!

Neben all den Diskussionen rund um HCD («human centered design») und MVP's («minimum viable products») geht mir zu häufig vergessen, dass man (ausser im wirklichen «Start-up Szenario») bestehenden Kunden hat, die eine gewisse Funktionalität im Produkt nutzen und benötigen. Aus meiner Sicht ergibt es keinen Sinn, eine neue Version des eigenen Produkts (oder des E-Bankings, Webseite, App, etc.) zu lancieren, die zwar bunter aussieht und grössere Buttons hat, dafür aber Teile der bestehenden Funktionalität vermissen lässt.

Zwar beurteilen viele Kunden ein Softwareprodukt rein vom UI her – da ist dann schnell mal etwas altmodisch, nur weil es vor 5-7 Jahren designt wurde. Aber die genau gleichen Kunden möchten überhaupt keinen Update haben auf etwas mit modernem UX/UI, was dabei Funktionalität verliert!

Dokumentation vs. viele Support Mitarbeiter

Viele Standardsoftwarehersteller vernachlässigen die Dokumentation ihres Systems sträflich. Da gibt es dann gar nichts oder einige wenige «FAQs». Jedenfalls wird das Horten von Know-how als umsatzsteigernd angeschaut, gerade auch für Sales-Partner. Wie diese allerdings dieses Know-how vorhalten, wenn es nur in den Köpfen existiert, ist mir ein Rätsel.

Ich glaube nicht, dass das eine gute Strategie ist, aus mehreren Gründen:

• jeder Softwarehersteller hat mehr Marge auf den IP (intellectual property) als mit Dienstleistungen.
• nur explizit verfügbares Wissen lässt sich AI-mässig nutzen. Und das erwarten immer mehr Kunden.
• immer mehr Support Mitarbeiter anstellen, skaliert ausserdem sehr schlecht, auch in Bezug auf andere Länder und Sprachen.

Fazit

Die hier formulierten Prinzipien gelten für mich seit Jahrzehnten und sind damit offensichtlich nicht den Wogen des dauernden Technologiewandels ausgesetzt. Eigentlich erstaunlich für unsere «schnelllebige» Branche!