Technologie, IT & Software

Ein Softwareunternehmen sitzt auf vielen Daten: Nutzungs-Events aus dem Produkt, Verträge und Rechnungen aus der Abrechnung, Opportunities im CRM, Tickets im Support. Jedes System beantwortet seine eigene Frage. Sobald jemand wissen will, welche Funktionen zu Verlängerungen führen, müssen die Daten zusammenkommen.

Wir bauen dafür eine gemeinsame Datenbasis und einheitliche Kennzahlen. Wer KI-Funktionen im eigenen Produkt anbietet, bekommt zusätzlich Unterstützung bei Evaluierung, Betrieb und der Einordnung nach EU AI Act.

Drei Systeme, drei Kennungen für denselben Kunden

Die schwierigste Aufgabe ist meist nicht die Technik, sondern die Zuordnung. Ein Account im Produkt, ein Kundeneintrag im CRM und ein Vertragspartner in der Abrechnung tragen oft verschiedene Kennungen, und irgendjemand muss sie verbinden, bevor eine Frage wie „Nutzen unsere größten Kunden die neue Funktion?“ beantwortbar wird. Dazu kommen Support-Tickets und, bei nutzungsbasierten Preisen, die gemessene Nutzung je Kundenkonto. Wer Marge je Kunde sehen will, braucht auch Cloud-Kosten und Betriebsdaten.

Product-Analytics-Tools beantworten Nutzungsfragen schnell, sehen aber weder Rechnungen noch Tickets. Deshalb laden wir die Quellen in ein Data Warehouse und verbinden sie dort. Das hat einen zweiten Effekt: Die Analysen laufen nicht mehr auf der Produktionsdatenbank, was das Produkt entlastet und die Auswertungen schneller macht. Der Aufbau ist in den Schwerpunkten Data Warehouse und Datenmodellierung beschrieben.

Ein Wort zu den Events. Zu viele oder unklar benannte Events machen jede Analyse mühsam. Ein Tracking-Plan mit Namensregeln, bevor die Events im Produkt eingebaut werden, spart später viel Arbeit.

Warum MRR in jeder Abteilung anders aussieht

SaaS-Kennzahlen wirken einfach und sind es nicht. Bei MRR und ARR hängt vieles an den Regeln: Wie gehen Jahresverträge, Rabatte, Testphasen und nutzungsbasierte Anteile ein, und wann beginnt und endet der Umsatz eines Vertrags? Bei Net Revenue Retention und Churn kommt hinzu, dass Umsatz-Churn und Kunden-Churn verschiedene Dinge sind und Downgrades und Erweiterungen das Bild verschieben, wenn man sie nicht getrennt ausweist.

Typischerweise rechnen Finanzen, Vertrieb und Produkt jeweils mit eigenen Tabellen und kommen auf verschiedene Zahlen. Wir halten die Definitionen deshalb in einem zentralen Kennzahlenmodell fest, auf das alle zugreifen.

Dasselbe gilt für die weicheren Größen. Welches Ereignis zeigt, dass ein neuer Account den Nutzen erreicht hat, und wie schnell passiert das? Welche Funktionen nutzen Accounts, die verlängern, und welche die, die kündigen? Viele Tickets können ein Risiko anzeigen oder engagierte Nutzung. Welches von beiden, zeigt erst der Vergleich mit Nutzungs- und Vertragsdaten.

Dashboards für Kunden im eigenen Produkt

Wenn Kundinnen und Kunden im Produkt Dashboards sehen, sollten die Zahlen mit den internen übereinstimmen, also aus demselben Kennzahlenmodell kommen. Dazu braucht es Performance, die auch bei großen Mandanten hält, und ein Berechtigungskonzept, das mit dem Produkt wächst. Am wichtigsten ist die Mandantentrennung: Ein Berechtigungsfehler, der einem Kunden Daten eines anderen zeigt, ist im Kundenkontakt besonders teuer.

KI-Funktionen: vom Prototyp zum Betrieb

Assistenten, semantische Suche, Zusammenfassungen oder Agenten sind schnell als Prototyp gebaut. Ohne Testfälle und Monitoring weiß dann niemand, wie oft die Funktion falsch antwortet. Wir gehen in dieser Reihenfolge vor: echte Anfragen mit erwarteten Antworten sammeln, bei jeder Änderung an Modell, Prompt oder Datenquelle erneut testen und im Betrieb Qualität, Kosten und Antwortzeiten überwachen. Das ist Aufgabe von MLOps. Modellwechsel von Anbietern sollten sich testen lassen, bevor sie live gehen.

Eine KI im Produkt darf nur Daten sehen, die die anfragende Person sehen darf, besonders bei mehreren Mandanten. Führt ein Agent Aktionen im Namen von Nutzenden aus, braucht es Freigaben und Protokolle.

Was Anbieter von Software und KI rechtlich beachten müssen

Wer ein KI-System entwickelt und unter eigenem Namen anbietet, ist nach dem EU AI Act in der Regel Anbieter, auch mit zugekauftem Modell. Hochrisiko-Pflichten nach Anhang III gelten nach dem AI Omnibus (VO (EU) 2026/1744, seit 27. Juli 2026 in Kraft) ab dem 2. Dezember 2027, für Anhang I ab dem 2. August 2028. Die Transparenzpflichten nach Art. 50 gelten seit August 2026, etwa für Chatbots. Zur KI-Kompetenz: Art. 4 gilt seit dem 2. Februar 2025, ein bestimmtes Niveau ist nicht mehr vorgeschrieben, und die Aufsicht der Behörden beginnt am 2. August 2026.

Für Anbieter von Cloud- und SaaS-Diensten kommt der EU Data Act hinzu. Er gilt seit dem 12. September 2025 und verlangt unter anderem, dass Kunden den Anbieter wechseln können. Wechselentgelte entfallen ab dem 12. Januar 2027. Der Cyber Resilience Act sieht für Hersteller von Produkten mit digitalen Elementen Meldepflichten vor, die seit dem 11. September 2026 gelten. Ob und wie reine Online-Dienste betroffen sind, hängt vom Einzelfall ab.

Produktnutzungsdaten sind häufig personenbezogen, beim Tracking im Produkt genauso wie bei der Weitergabe von Inhalten an KI-Anbieter. Die Einordnung für das eigene Produkt gehört zu Datenschutz und Rechtsberatung.