Eine Beratung verkauft etwas Immaterielles: die Zeit, das Wissen und die Aufmerksamkeit kluger Menschen. Das Ergebnis dieser Arbeit verteilt sich meist über E-Mails, geteilte Laufwerke und Tabellen, und der Kunde ist nie ganz sicher, wo sein Projekt steht. Eine Delivery-Plattform für Kunden holt das an einen Ort: Sie zeigt den Fortschritt, führt Liefergegenstände durch die Freigabe und gibt einem Partner den Blick auf das gesamte Portfolio statt auf einen weiteren Posteingang.
Nach unserer Erfahrung liegt die Schwierigkeit nicht darin, ein hübsches Portal zu entwerfen, sondern darin, Komfort für den Kunden mit einer eisernen Datentrennung zwischen Kunden und einer sauberen Abrechnung zu vereinen. Das ist ein Ingenieurprojekt und kein kosmetisches. Auch wenn Sie keine eigene IT-Abteilung aufbauen wollen, bringen wir die Engineers mit, die eine solche Plattform gemeinsam mit Ihren Delivery-Leuten entwerfen, bauen und pflegen.
Warum braucht eine Beratung eine eigene Delivery-Plattform?
Fertige Projektwerkzeuge beherrschen die interne Aufgabenverwaltung gut, sind aber schwach in dem, was der Kunde tatsächlich sieht und anfasst. Beratung hat ihre eigene Gestalt: Jeder Kunde ist eine eigene Welt mit eigenen Daten, Vertraulichkeitsregeln und einem eigenen Freigabetakt, und ein generisches Werkzeug erzwingt Kompromisse, bei denen der Kunde entweder zu viel oder zu wenig sieht.
Eine eigens gebaute Plattform für Professional Services lässt Sie diese Regeln selbst setzen. Der Kunde bekommt einen einzigen, markierten Einstiegspunkt zu seinem Projekt, Sie behalten die Kontrolle darüber, was sichtbar ist, und das Team verbrennt keine Stunden mehr mit dem Zusammenstellen von Statusmeldungen.
Was genau ist ein Kundenprojektportal?
Es ist der Teil, den der Kunde sieht und der ihn am meisten interessiert. Ein Kundenprojektportal sammelt, was früher als Anhang unterwegs war:
- den aktuellen Projektstatus und die nächsten Meilensteine,
- Liefergegenstände, die zur Prüfung bereitstehen, in Freigabe sind oder gezeichnet wurden,
- Dokumente, Entscheidungen und Absprachen mit Änderungshistorie,
- einen Kommunikationskanal, der an einer konkreten Aufgabe hängt und nicht an einem E-Mail-Verlauf.
Darunter sorgt ein Backend dafür, dass jeder Kunde immer nur seinen eigenen Ausschnitt sieht; das Portal ist nur die Spitze, und die eigentliche Arbeit geschieht in der Datenschicht.
Wie entwerfen Sie den Prüf- und Freigabeablauf für Liefergegenstände?
Hier zahlt sich die Plattform aus, denn in der Freigabe versickern Geld und Zeit am häufigsten. Jeder Liefergegenstand sollte einen expliziten Status und einen klaren Weg haben:
- einen Entwurf, der nur für das Team sichtbar ist,
- eine Übergabe an den Kunden mit Benachrichtigung und Frist für Kommentare,
- Kommentare und eine Überarbeitungsrunde, festgehalten an einer konkreten Version,
- eine Freigabe mit Datum, Person und digitaler Zeichnung oder Bestätigung,
- einen Abschluss, der einen Meilenstein oder eine Rechnung auslösen kann.
Entscheidend ist, dass jeder Übergang eine Spur hinterlässt: wer, wann und an welcher Version - damit aus „aber das haben Sie im März freigegeben” ein Logeintrag wird statt eines Streits.
Wie verfolgen Sie Meilensteine und Umfang ohne Abdriften?
Der Umfang in der Beratung neigt dazu anzuschwellen, und jede zusätzliche Bitte wirkt harmlos, bis man sie zusammenzählt. Die Plattform sollte Meilensteine an konkrete Liefergegenstände und an den vereinbarten Umfang binden, damit Abweichungen sofort auffallen und nicht erst bei der Abrechnung. Bittet ein Kunde um etwas außerhalb des Vertrags, lässt das System es als Umfangsänderung markieren, bepreisen und durch die Freigabe laufen, statt die Arbeit und die Marge still zu schlucken.
Wie trennen Sie in der Praxis die Zugriffe vieler Kunden?
Das ist das Herz der Plattform und die Stelle, an der es am leichtesten schiefgeht. Multi-Tenant-Datentrennung bedeutet, dass die Daten eines Kunden niemals zu einem anderen gelangen dürfen, auch nicht durch einen Fehlgriff eines Entwicklers. In der Praxis nutzen wir eine von zwei Strategien: logische Isolation in einer gemeinsamen Datenbank, in der jeder Datensatz eine Tenant-Kennung trägt und auf Abfrage- und Berechtigungsebene gefiltert wird, oder vollständige Isolation mit eigener Datenbank oder eigenem Schema pro Kunde, wo eine Aufsicht es verlangt. Darüber hinaus setzen wir die Zugriffssteuerung im Backend durch und nicht durch das Ausblenden von Elementen in der Oberfläche, denn ein versteckter Button ist keine Schutzmaßnahme. Dieses Fundament legen wir am Anfang, denn eine echte Isolation nachträglich in ein laufendes System einzuziehen ist weit teurer, als sie vom ersten Tag an zu entwerfen.
Wie bauen Sie Rollen und Berechtigungen, damit jeder nur das Eigene sieht?
Rollen sind die Sprache, in der Sie beschreiben, wer was darf, und eine Beratungsplattform braucht mindestens einige klar getrennte Welten:
- einen Partner oder Delivery-Leiter mit dem Blick über das gesamte Portfolio,
- das Projektteam, begrenzt auf die eigenen Mandate,
- den Kunden, der nur sein eigenes Projekt und seine Liefergegenstände sieht,
- Gastrollen für Subunternehmer oder Experten mit engem, zeitlich begrenztem Zugriff.
Gut entworfene Berechtigungen arbeiten leise: Jeder sieht einfach genau das, was er sehen soll. Wir entwerfen sie als zusammenhängendes Modell aus Rollen und Regeln und nicht als einen über die Zeit angewachsenen Haufen Ausnahmen.
Warum braucht eine Beratungsplattform Audit-Trails und Versionierung?
Weil Beratungsarbeit im Streit enden kann und das menschliche Gedächtnis selektiv ist. Ein vollständiger Audit-Trail hält fest, wer ein Dokument hochgeladen hat, wer es freigegeben hat und wann sich der Umfang geändert hat, sodass eine Beanstandung auf Fakten trifft und nicht auf Vermutungen. Die Versionierung von Liefergegenständen wirkt genauso: Jede Fassung eines Berichts oder Modells bleibt erhalten, sodass Sie immer wissen, welche Version der Kunde gesehen und gezeichnet hat. In regulierten Branchen ist das oft eine Anforderung und kein Bonus, denn ein Prüfer fragt nicht, wie der Stand jetzt ist, sondern wie er an einem bestimmten Tag war.
Welche Kompetenzen stellen wir bereit, und wie schnell steigt das Team ein?
Eine solche Plattform bauen Menschen mit einem bestimmten Profil, die wir rund um Ihr Projekt zusammenstellen, nicht „auf Vorrat”:
- einen Lösungsarchitekten, der Multi-Tenant-Modell, Berechtigungen und Integrationen setzt,
- Backend-Entwickler (z. B. Java, .NET, Node), die Logik, APIs und Daten verantworten,
- Frontend-Entwickler, die das Kundenportal und die internen Panels bauen,
- einen DevOps-Spezialisten, der Cloud, CI/CD und Umgebungen aufsetzt,
- QA- und UX-Unterstützung dort, wo Sicherheit und tägliche Bedienbarkeit gleichermaßen zählen.
Wir arbeiten als Nearshore-Partner aus Polen, also in einer nahen Zeitzone, und steigen ohne langen Anlauf in Code-Reviews und Termine ein. Eine Besetzung nach Anforderungsprofil schließen wir üblicherweise in etwa drei Wochen ab, und wir prüfen die Kompetenzen vor dem Start.
Wie machen wir das bei RITS?
Wir behandeln es als Produkt, das Jahre laufen soll, und nicht als einmalige Einführung:
- wir beginnen beim Datenmodell und der Kundentrennung, denn das ist die Entscheidung, die sich später am schwersten umkehren lässt,
- wir besetzen Rollen passend zum Umfang und stellen das Team rund um den Stack zusammen, in dem Sie arbeiten wollen,
- wir verbinden Portal, Backend und Cloud zu einem wartbaren Ganzen,
- wir bleiben über den Start hinaus und entwickeln die Plattform als dediziertes Team oder über Team-Verstärkung weiter.
Meist liefern wir das als Individualsoftware, gebaut von unserem Team, und dort, wo Sie nur eine Kompetenzlücke schließen wollen, als Team-Verstärkung. Eine fehlende Referenz in genau Ihrer Nische ist keine fehlende Kompetenz: Wir wenden dieselbe Ingenieursarbeit dort an, wo Vertraulichkeit und viele Mandanten Alltag sind.
Wo beginnen Sie mit einer Delivery-Plattform für Kunden?
Beginnen Sie mit dem schmerzhaftesten einzelnen Moment in Ihrer Delivery, meist der Freigabe von Liefergegenständen oder der fehlenden Statustransparenz für den Kunden. Beschreiben Sie den Weg, den ein Liefergegenstand vom Entwurf bis zur Zeichnung nehmen soll, und welche Daten der Kunde sehen muss und welche er von einem anderen Kunden nie sehen darf. Das legt den Umfang der ersten Version, das Multi-Tenant-Modell und die nötigen Rollen fest. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen eine Delivery-Plattform für die Kunden Ihrer Beratung? Sprechen wir darüber - wir finden ein Team und eine Architektur passend zu Ihrem Delivery-Modell.