Kunden

Der häufigste Anlass ist Druck von außen: Eine Hardware-Generation läuft aus, ein Rechenzentrumsvertrag endet, eine Lizenz wird deutlich teurer, oder eine Konzernmutter gibt eine Plattform vor. Die Entscheidung, etwas zu ändern, ist dann bereits gefallen — offen ist nur, wohin und in welcher Reihenfolge.

Der zweite Anlass ist Wachstum, das die bestehende Aufstellung überholt hat. Eine Anwendung, die drei Jahre lang für vierzig Nutzer gereicht hat, verhält sich bei vierhundert anders, und die Ursache ist selten die eine Stelle, die alle vermuten.

Der dritte Anlass ist ein Team, das ein Thema zum ersten Mal macht. Kubernetes, eine Zahlungsanbindung, eine App im Store — technisch alles machbar, aber der erste Durchlauf kostet erfahrungsgemäß das Dreifache der Schätzung, weil die Fehler noch nicht bekannt sind. Da beschleunigt jemand, der sie kennt, ganz erheblich.

Nach unserer Erfahrung sind es fast nie die Technologien. Teuer werden Projekte durch fehlende Entscheidungen: wenn nicht geklärt ist, wer entscheiden darf, wenn zwei Abteilungen unterschiedliche Ziele verfolgen, oder wenn niemand benennen kann, welcher Zustand als „fertig“ gilt.

Der zweite Kostentreiber ist fehlende Testabdeckung. Ohne Tests ist jede Änderung an einem gewachsenen System ein Vertrauensakt, und Vertrauensakte werden vorsichtig und damit langsam ausgeführt. Wo wir migrieren, schauen wir deshalb zuerst, was überhaupt beobachtbar ist — das sagt den Aufwand besser voraus als die Größe des Systems.

Beides sprechen wir früh an, auch wenn es unangenehm ist. Ein Angebot, das solche Punkte ausklammert, ist billiger und stimmt nicht.

Der typische Kunde hat zwischen 50 und 500 Mitarbeitern und eine eigene IT-Abteilung von drei bis fünfzehn Leuten. Das ist kein Zufall: Darunter fehlt meist jemand, der ein Ergebnis nach der Übergabe weiterbetreiben kann, und darüber gibt es in der Regel bereits ein Team für genau das Thema.

Branchen sind gemischt — Fertigung und Handel im Westerwald und im Lahn-Dill-Gebiet, Finanz- und Dienstleistungsunternehmen im Rhein-Main-Gebiet, dazu eCommerce. Was die Projekte verbindet, ist nicht die Branche, sondern die Ausgangslage: gewachsene Systeme, die lange gut funktioniert haben und jetzt an eine Grenze stoßen.

Für regulierte Umgebungen arbeiten wir ebenfalls, mit der üblichen Einschränkung: Wo Zertifizierungen verlangt werden, die wir nicht haben, sagen wir das vorher und nicht im Audit.

Wir sitzen im Projekt neben Ihrem Team, nicht davor. Praktisch heißt das: gemeinsames Backlog statt getrennter Auftragslisten, Zugriff auf dieselben Systeme, Teilnahme an den Terminen, die es ohnehin gibt. Ein Berater, der parallel etwas baut und es am Ende hinüberreicht, erzeugt genau die Übergabe, die niemand versteht.

Wissenstransfer planen wir dabei als Arbeitspaket ein, nicht als Nebenprodukt. Das kostet sichtbar Zeit im Projekt und spart sie danach — der Unterschied zeigt sich sechs Monate später, wenn etwas geändert werden muss und niemand mehr anrufen möchte.

Am Ende steht in jedem Fall etwas Schriftliches: Architektur­entscheidungen mit Begründung, Betriebsdokumentation, und die Liste dessen, was wir bewusst nicht gelöst haben. Der letzte Punkt ist der nützlichste und fehlt in den meisten Übergaben.

Ein Teil unserer Arbeit findet unter Vertraulichkeit statt und taucht deshalb auf dieser Seite nicht auf. Wenn Sie Referenzen aus Ihrer Branche sehen möchten, fragen Sie im Gespräch danach — was wir nennen dürfen, nennen wir dann. Eine Vertraulichkeitsvereinbarung unterschreiben wir vorab, schicken Sie einfach Ihre.

Umgekehrt fragen wir am Ende eines Projekts, ob wir es nennen dürfen — und akzeptieren ein Nein ohne Nachhaken. Referenzen, für die jemand überredet werden musste, lesen sich am Ende auch so.