Was Gründer wirklich über IT wissen müssen
Viele Gründer stehen oft vor einem großen Technologie- und IT-Berg, wenn sie keinen Tech-Hintergrund haben. IT sieht dann wie eine Blackbox aus, die schwer zu steuern ist. Gründer stellen sich Fragen zu IT-Systemen, Entwicklungsprozessen und Prioritäten und wissen nicht, wo beginnen oder worauf zu fokussieren. Deshalb möchte ich hier eine Anleitung geben und 5 wichtigsten Themen vorstellen.
Basics nicht aus den Augen verlieren
Das Wichtigste sind die Basics beim ganzen Tagesgeschäft, beim Wunsch nach Features und IT-Unterstützung nicht aus den Augen zu verlieren. Die Prioritäten eines CEOs oder Gründers bezüglich der IT sind:
- Compliance
- Verfügbarkeit
- Backups
- Security
- Disaster Recovery und Business Contingency
Während Compliance von Anfang an wichtig ist (Datenschutz, PCI und der Umgang mit Kreditkarten) werden die anderen erst mit der Zeit relevant. Mit einer Webplattform, die keine hohe Verfügbarkeit hat, wird man einerseits keinen Umsatz machen, weil die Kunden einfach nicht kaufen können. Und andererseits schreckt man Kunden davon ab wiederzukommen.
Da es aber immer wieder zu Hardware-Ausfällen kommen kann und auch menschliche Fehler (z.B. Löschen wichtiger Dateien) passieren, sind Backups das nächste Basic auf der Liste. Backups werden gerne aus den Augen verloren. Fehlende Backups haben aber bereits für das ein oder andere Startup das Ende bedeutet. Backups müssen regelmäßig gemacht und außerhalb des Unternehmens gelagert werden, verschlüsselt sein und routinemäßig getestet werden, ob ein problemloses Einspielen möglich ist.
Sicherheit wird mit dem Wachsen einer Firma immer wichtiger. Mehr Mitarbeiter vergrößern das Risiko und mehr Erfolg macht einen zu einem beliebten Ziel. Und obwohl Perimeter-Defense (Firewall, VPN etc.) wichtig ist, darf man die interne Sicherheit beim Umgang mit und dem Zugang zu Daten nicht vernachlässigen, wie zuletzt der Sony Hack gezeigt hat.
Gerne vergessen wird bei Startups dass man sich als CEO/COO ab einer bestimmten Firmengröße dringend um Business Contingency und Disaster Recovery befassen muss. Wie führt man das Unternehmen bei einem Disaster (Brand etc.) weiter und wie setzt man es nach dem Disaster wieder auf. Beim Fokus auf alle anderen Aufgaben und Anforderungen an die Technik darf der Gründer diese fünf Basics nicht aus den Augen verlieren und muss seine Technik-Abteilung bzw. seinen CTO hier auch in die Pflicht nehmen.
Eigene Prioritäten festlegen
Neben diesen Basics geht es darum, die eigenen Prioritäten festzulegen. Wenn man nicht als Gründer oder CTO klar sagt was einem wichtig ist, wird das Ergebnis nicht mit den eigenen Wünschen übereinstimmen. Leider sprechen viel zu wenige darüber, was sie von der IT erwarten. Das führt zu falschen Erwartungen und Unzufriedenheit. Daher gilt es klare Prioritäten zu definieren und zu kommunizieren. Auf diese Prioritäten ausgerichtete Mitarbeiter bedeuten einen enormen Effektivitätssprung. Prioritäten können sein:
– Kundenzufriedenheit/ NPS
– Mitarbeiterzufriedenheit/ Retention
– Organisationszufriedenheit (alle Abteilungen sind zufrieden)
– Sicherheit
– Hohe Qualität
– Einfaches Recruiting
– Wachstum
– Kurze Time to Market
– Hoher Durchsatz an neuen Features
– Innovation
– Hohes ROI
– Umsatz/ Top Line
– Kosten/ Bottom Line
– Stabilität
– Niedriges Risiko
Alle diese Prioriäten sind Tradeoffs, das bedeutet, dass der Fokus auf eine dieser Prioritäten nur möglich ist, wenn man auf andere Prioritäten verzichtet. Manche der Prioritäten spielen gut zusammen, wie “Innovation” und “Einfaches Recruiting”. Wenn man die Priorität auf Innovation legt und man seine Entwicklung und IT darauf ausrichtet, dann ist es in der Regel leicht Top-Talent einzustellen da diese von Innovation angezogen wird. Dagegen wird es mit einem Fokus auf Innovation schwierig “Hoher Durchsatz an neuen Features” gleichzeitig umzusetzen. Innovation erfordert viel Ausprobieren im Ideen-Raum, viel Kreativität und Freiraum. Ein hoher Durchsatz möglichst vieler Features dagegen bedingt eine hohe Effizienz ohne viel Freiraum. Auch “Vorhersagbarkeit/ Termintreue” lässt sich mit Innovation nur schwer vereinbaren. Abhängig von der Firmenstruktur wird eine hohe Innovationsfähigkeit und Umsetzung dazu führen, dass andere Abteilungen weniger zufrieden sind. Einfach weil sie aus ihrer Sicht nicht genug Features umgesetzt bekommen. Und Innovation schließt praktisch per Definition “Niedriges Risiko” aus. Das gleiche gilt für andere Prioritätenpaare. Viele Firmen versuchen auch sich wiedersprechende Prioritäten umzusetzen, was zu Ineffektivität und Mitarbeiterverwirrung führt.
Bleiben diese Prioritäten unausgesprochen und undiskutiert, hat jeder Mitarbeiter und jeder Abteilungen eigene Prioritäten für die IT im Kopf. Dies führt zu ständigen Reibereien und zu Unzufriedenheit bei allen Beteiligten. Der Gründer/CEO ist hier gefordert, für eine gemeinsame Ausrichtung zu sorgen und auch die eingegangenen Tradeoffs klar zu kommunizieren. Dies wird im Allgemeinen Frust minimieren, die Zufriedenheit erhöhen und den Unternehmenserfolg sehr positiv beeinflussen.
Buy Or Build
Oft stellt sich dann nach den Prioritäten die Entscheidung Buy or Build. Kauft man die Software oder das System von der Stange oder man baut es selbst. Dabei können einem mehrere Überlegungen helfen. Handelt es sich um einen Kernbaustein des eigenen Geschäftsmodells oder ist das System ein Unterscheidungsmerkmal, dann ist es besser man baut die Technologie selbst und hat die Kontrolle über den Featureumfang und die Qualität. Eine Dating Webseite würde in einen solchen Bereich fallen. Ist das System nur ein Werkzeug für das eigentliche Geschäftsmodell, z.B. den Verkauf von Tee über das Internet, dann ist Kaufen meist die günstigere und schnellere Option.
Ein weiteres Kriterium ist das Marktumfeld und die Wertschöpfungshöhe. Nach Wardley kann man IT Systeme und Technologien anhand von zwei Achsen bestimmen: Der Wertschöpfungshöhe, die die Technologie liefert und andererseits wie weit sie bereits entwickelt ist. So hat die Technologie “Strom” oder “Data Center” eine sehr niedrige Wertschöpfungshöhe, die eigene Webseite aber eine sehr hohe. Auf der Entwicklungsachse von Technologien sieht Wardley die Stufen Genesis, Custom Built, Product (+ Rental) und Commodity (+ Utility). Beispielsweise ist “Strom” heute eine Commodity, während digitale Währungen sich noch im Genesis Zustand befinden.
Vereinfacht bedeutet dies, dass Technologien, die eine hohe Wertschöpfung oder einen niedrigen Evolutionsgrad haben, selbst gebaut werden während Technologien aus dem Segment Commodity und niedriger Wertschöpfung gekauft werden sollten. Dies klingt einfach, in vielen Firmen gibt es aber keinen systematischen Ansatz für die „Build or Buy“ Entscheidung. Oft wird gebaut, was gekauft werden sollte, da man Mitarbeiter hat, die gerne etwas bauen. Oft wird gekauft, was gebaut werden sollte, weil die (Anfangs-) Kosten das primäre Entscheidungskriterium sind.
Auf das Kaufen von Systemen werde ich in diesem Artikel nicht genauer eingehen, für die weitere Diskussion werde ich mich auf das Entwickeln von Technologien und Systemen begrenzen.
Wie baut man Software
Hat man nach einem Bewertungsprozess entschieden, dass man ein System selbst bauen will, stellt sich die Frage nach welchem der vielen Prozesse man ein System baut. Auch wenn einem viele Berater etwas anderes vermitteln, hier gibt es keine pauschalen Antworten. Software kann man nach einem engen Projektprozess entwickeln, in einer agilen Art und Weise oder mittels ‘Lean’. Welchen der Prozesse man wählt hängt von den eigenen Prioritäten ab (siehe oben) und nach welchem Modus man die Software entwickelt.
Ich unterscheide primär drei Modi der Software Entwicklung:
- Wartung/Support
- Optimierung
- Innovation
Die Wahl eines Modus hängt dabei von den Zielen und den eigenen Prioritäten ab, davon in welchem Markt man sich bewegt und wie weit das eigene Geschäftsmodell ausgereizt ist. Fatal ist es wenn es hier keine Übereinstimmung gibt. Auch wenn man sich innerhalb des Unternehmens nicht einig ist in welchem Modus man entwickelt, führt dies zu viel Reibungsverlusten und Unzufriedenheit. Wenn man mehrere Bereiche der Entwicklung hat – klassischerweise Webseite und Backoffice oder neuere und ältere Produkte – dann kann auch jeder Bereich seinen eigenen Modus besitzen. Obwohl es einen primären Modus gibt, wird die Realität immer eine Mischung mit einem dominanten Modus sein.
Im Wartungs-Modus liegt der Fokus auf dem Beheben von Fehlern mit der Wartung des bestehenden Codes. Es werden primär die wachsenden Anforderungen der Geschäftsbereiche des Unternehmens wie Einkauf, Finance oder Marketing umgesetzt. Es gibt nur eine geringe Erwartung bezüglich eines Uplifts im Umsatz, der durch die Software oder Technologie erreicht wird und Umsatztreiber sind die Geschäftsbereiche.
In diesem Modus wird das Technologie-Produkt durch einen Projektmanager gesteuert und durch klassisches Anforderungsmanagement organisiert. Was umgesetzt wird ist durch die Anforderungen der Geschäftsbereiche bestimmt, die auch maßgeblich die Richtung vorgeben. Wichtige Begriffe sind in diesem Modus Projektmanagement, Budget, Zeit und die korrekte Umsetzung der Anforderungen. Die Unsicherheit ist niedrig und das Entwicklungs- oder Adminteam eher klein.
Am besten verwendet man hier einen klassisch planerischen Prozess mit klassischer Projektsteuerung. Für die Anzahl kleiner Änderungen eignet sich hervorragend ein Leaner Entwicklungsprozess, der sich auf die Umsetzung vieler, kleiner Tickets spezialisiert. Eine agile Software Entwicklung kann auch hier von Vorteil sein, benötigt dann aber viel Überzeugungsarbeit mit den Fachbereichen, die ihre Arbeit mit “Milestones” koordinieren möchten und benötigt neben der klassischen agilen Entwicklung einen Anforderungsmanagement-Prozess für die Integration vieler Geschäftsbereiche, Backend-Systeme und z.B. gesetzlicher Regelungen.
Im Optimierungsmodus liegt der Fokus auf der Optimierung von Geschäftsmetriken (KPI) wie Conversion, Clickraten, Kundenzufriedenheit usw. Die Technologie trägt hier zum Umsatzwachstum maßgeblich bei, bei etablierten Unternehmen aber eher im unteren zweistelligen Bereich.
Produkt-Manager sind hier Spezialisten für Userinterfaces und Usability (UX), haben einen guten Marktüberblick und verstehen sich auf Analytics. Was umgesetzt wird ist durch die ausgewählten Metriken bestimmt und wird vom Produktmanagement organisiert und bestimmt. Eine Verbesserung der Conversion im Checkout als Ziel wird zu einer Änderung des Checkouts in der Entwicklung führen. Die Unsicherheit ist mittelgroß und man benötigt ein signifikantes Entwicklungsteam.
Die wichtigen Begriffe für den Optimierungsmodus sind A/B Testing, UX und KPI Impact. Geeignet sind hier hoch-iterative und agile Prozesse, die durch ihre Iterationen dazu beitragen, die KPIs in die richtige Richtung zu bewegen. Das Ergebnis der Entwicklung ist hier wichtiger als die Entwicklungszeit einzuhalten. Diese Prozesse sind oft hochoptimiert um viele Iterationszyklen in kurzer Zeit durchzuführen.
Der dritte Modus ist der Innovationsmodus. Er findet sich häufig, wenn Firmen ihr primäres Geschäftsmodell ausgereizt oder fast ausgereizt haben oder groß genug sind, sich eine breite Innovation zu leisten. Es geht darum neue innovative Features und Produkte zu entwickeln oder neue Geschäftsmodelle einzuführen. Die Unsicherheit in diesem Modus ist hoch, Innovationsergebnisse kann niemand garantieren. Dafür ist hier aber auch der Umsatz Uplift am größten. Als Beispiele gelten hier Google und Apple, die signifikante neue Geschäftsmodelle laufend entwickeln. Bei Apple hat das iPhone alle anderen Geschäftsmodelle bei weitem überflügelt.
Die Entwicklung ist hier ergebnissoffen und wird durch einen Innovationsmanager organisiert. Wichtige Begriffe sind in diesem Modus Leap und Design Thinking. Prozesse sind offen und durch viel Try & Error bestimmt, man muss vieles ausprobieren, von dem das Wenigste funktioniert. Der Investitionseinsatz für diesen Modus ist generell hoch, dafür sind die Chancen die größten.
Wie man sieht bestimmt der Modus, den man für einen Bereich wählt, viele weitere Faktoren. Viele Firmen sind nicht einheitlich ausgerichtet, die Reibereien führen zu starken Effizienzverlusten. Umgekehrt kann eine firmenweite Einigkeit über den Entwicklungsmodus mit seinen Zielen ein Wettbewerbs- und Effizienzvorteil sein.
Richtiges Vorgehen für Backoffice-Projekte
Auf die Software-Entwicklung für Webseiten in Startups möchte ich an dieser Stelle nicht speziell eingehen, darüber gibt es ausreichend Literatur für aufstrebende Startups und dieser Bereich liegt oft im Fokus der Gründer. Dagegen sehe ich in der Entwicklung und Implementierung von Systemen im Backoffice Bereich immer die gleichen Fehler. Diese sind in dem meist falschen Vorgehen begründet. Ein wachsendes Startup kommt schnell in den Bereich in dem die IT Systeme (meist Excel) nicht mehr ausreichen um das Wachstum zu unterstützen. Es kommt zu hohem manuellen Arbeitsaufwand und Fehlern. In dieser Situation werden dann IT Prozesse und neue Systeme schnell und unter Zeitdruck eingeführt. Nach einem Jahr stellt man fest, dass die Systeme und Anforderungen nicht die richtigen waren. Und der Kreislauf beginnt von neuem.
Grund der Probleme ist, dass die IT Systeme nicht im Geschäftsmodell verwurzelt sind. Das richtige Vorgehen, wenn die Backoffice IT neu aufgesetzt werden soll, ist die Bestimmung der Business Ziele und die Bestimmung der Business Prozesse. Aus diesen leiten sich dann die Anforderungen und Datenmodelle ab. Dadurch kann man dann die richtigen Tools und Systeme auswählen oder entwickeln lassen. Dadurch ist eine Ausrichtung der IT auf die Geschäftsvorfälle gewährleistet.
Danach gilt das gleiche wie unter “Buy or Build” und der Softwareentwicklung beschrieben. Teile des Backoffices wird man selbst entwickeln, wenn sie einen höhen Innovationsgrad besitzen oder wenn sie ein Alleinstellungsmerkmal sind. Andere Teile wird man selbst weiterentwickeln, meistens im Modus Wartung. Eine Besonderheit im Bereich Backoffice ist das Customizing von gekauften Komponenten. Damit ist die Anpassung und Weiterentwicklung von gekauften Systemen z.B. ERP oder eCommerce gemeint. Ohne klare Vorgaben für die Anpassung und Weiterentwicklung kann es hier geschehen dass, die IT diese Komponenten so verändert, dass ein einfaches Upgrade auf neue Systeme nicht mehr möglich ist. Dies gilt es unbedingt zu verhindern und als Vorgabe klar zu kommunizieren, mit der Ausnahme, dass es sich um einen klaren, starken Wettbewerbsvorteil handelt. Dies ist aber selten der Fall.
Zusammenfassung und Fazit
Wenn man nicht den Überblick verliert, kann man Risiken deutlich minimieren und den Impact seiner IT und Entwicklung erhöhen. Dabei sollte man zielgerichtet vorgehen. Wichtig ist, dass der Gründer/CEO der Gründer/CEO den Überblick bewahrt, für eine gemeinsame Ausrichtung in der Firma sorgt und er kann den Rahmen der IT nicht delegieren. Wenn man alles richtig macht, sind Effizienz- und Effektivitätswachstum, niedrige Reibereien und hohe Mitarbeiterzufriedenheit ein klare Wettbewerbsvorteile.
Zur Person
Stephan Schmidt arbeitet mit übercto als Berater und Interim CTO für Startups. Er hebt Firmen technisch auf die nächste und hilft ihre technischen Herausforderungen in den Bereichen Sicherheit, Skalierung, Teamaufbau und Outsourcing zu meistern. Zuvor war er in technischen Managementrollen bei Immobilienscout24 und als CTO bei brands4friends/eBay Inc. tätig.