Warum eine technische Funktion noch kein einlösbares Kundenversprechen ist – und Feature Parity deshalb keine Produktstrategie.
Feature Parity beantwortet nur die erste Frage
„Kann die Plattform das?“
Die Frage begegnet mir bei der Arbeit an SD-WAN, Automatisierung und Managed Services immer wieder. Und sie ist erst einmal völlig berechtigt. Wer Technologien bewertet, muss wissen, was sie können, wo ihre Grenzen liegen und welche Funktionen fehlen.
Ich schaue mir solche Unterschiede gerne ziemlich genau an. Manchmal wahrscheinlich genauer, als für die erste Diskussion nötig wäre. Der technische Teil macht mir eben Spaß.
Trotzdem sind wir mit einem „Ja, kann sie“ noch längst nicht fertig.
Der Router kann es. Der Service damit noch lange nicht.
Dafür braucht es keinen Herstellervergleich. Der Unterschied entsteht auch innerhalb einer einzigen Technologieplattform: zwischen dem, was die Technik grundsätzlich ermöglicht, und dem, was ein konkreter Service verbindlich zusagt. Der Hersteller kann längst feststehen. Die Arbeit am Produkt ist damit nicht erledigt.
Feature Parity fragt, ob Lösungen dieselben Funktionen mitbringen. Das ist ein sinnvoller Vergleich. Er beantwortet aber noch nicht, was wir daraus für wen anbieten sollten.
Die Netzfunktion steht. Der Service auch?
Ein bewusst vereinfachtes Gedankenbeispiel: Ein Kunde möchte an mehreren Standorten einen Gastzugang bereitstellen, der vom internen Netz getrennt ist. Die eingesetzte Technik unterstützt diese Trennung. Zentrale Verwaltung und APIs sind ebenfalls vorhanden.
In der groben Vergleichstabelle wäre damit einiges abgehakt. Aber schauen wir auf zwei Arten, dieselbe technische Fähigkeit umzusetzen – ausdrücklich auf derselben Plattform.
In einer individuell betreuten Umsetzung kann ein Engineer die Konfiguration einrichten, testen und dokumentieren. Spätere Änderungen werden ebenfalls einzeln bearbeitet. Das kann ein bewusst gewählter und sauber kalkulierter Service sein.
Ein standardisierter Service verspricht einen wiederholbaren Ablauf: Eingaben werden geprüft, Konfigurationen abgeleitet und Änderungen nachvollziehbar ausgeführt. Der Betrieb sieht, welchen Zustand der Auftrag tatsächlich erreicht hat. Auch Fehlerbehandlung und Rückbau sind berücksichtigt.
Die Netztrennung kann technisch in beiden Fällen identisch sein. Eine standardisierte Bereitstellung über viele Standorte ist trotzdem ein anderes Versprechen als „unser Engineering bekommt das eingerichtet“.
Feature vorhanden und Service verfügbar sind zwei unterschiedliche Aussagen.
„Hat eine API“ ist noch kein Bestellprozess
Genau an dieser Stelle wird es interessant. Zwischen einer Funktion auf dem Gerät und einem nutzbaren Service liegt die Arbeit, mit der ich mich viel beschäftige: Service-Design, Automatisierung, Integration, Tests und Betrieb.
Eine vorhandene API ist dabei ein guter Anfang. Mich interessiert aber, ob sie den Ablauf trägt, den wir anbieten wollen. Dafür hilft mir ein zweiter Blick auf die Haken in der Tabelle:
| Feature-Check | Service-Check |
|---|---|
| „Eine API ist vorhanden.“ | Unterstützt sie den vollständigen Ablauf: anlegen, ändern, auslesen und zurückbauen? |
| „Der Auftrag wurde angenommen.“ | Woran erkennen wir, dass der gewünschte Zustand tatsächlich erreicht wurde? |
| „Fehler werden gemeldet.“ | Was ist bei einem Teilfehler bereits verändert? Wie setzen wir kontrolliert fort oder nehmen Änderungen zurück? |
| „Der Auftrag lässt sich erneut senden.“ | Können wir nach einem Timeout wiederholen, ohne doppelte Ressourcen oder widersprüchliche Konfigurationen zu erzeugen? |
| „Der Status ist abfragbar.“ | Wie aktuell ist er? Sehen wir Soll- und Ist-Zustand sowie die Abweichungen dazwischen? |
| „Es gibt Rollen und Berechtigungen.“ | Sind die Rechte für Kunde, Betrieb und Automation passend begrenzt? Ist nachvollziehbar, wer was geändert hat? |
Das ist keine vollständige Abnahmecheckliste. Aber diese Fragen zeigen ziemlich schnell, wie viel zwischen „Schnittstelle vorhanden“ und „Service lieferbar“ liegt.
Es muss übrigens nicht jeder Schritt von Anfang an vollautomatisch sein. Auch ein standardisierter Service kann bewusst manuelle Schritte enthalten. Dann müssen sie allerdings beschrieben, personell abgedeckt und im Preis sowie im Leistungsversprechen berücksichtigt sein.
Was nicht funktioniert: manuell liefern und so planen, als wäre es schon automatisiert.
Promise Parity: Können wir dasselbe Versprechen einlösen?
Bevor ich Umsetzungen vergleiche, muss das Kundenversprechen klar sein. Bei einer einzelnen Plattform lautet die erste Frage deshalb schlicht: Können wir mit dieser Umsetzung das liefern, was wir zusagen?
Wenn ich anschließend mehrere Umsetzungen bewerte, kommt ein zweiter Maßstab dazu. Den nenne ich Promise Parity: Können unterschiedliche Umsetzungen dasselbe vereinbarte Kundenversprechen einlösen – einschließlich Bereitstellung, Änderungen, Betrieb und klar benannter Grenzen?
Dafür müssen weder Hersteller noch Plattform wechseln. Schon unterschiedliche Integrations- oder Bereitstellungswege auf derselben Technik können zu unterschiedlichen Ergebnissen führen. Und nicht jedes Angebot muss dasselbe versprechen. Vergleichbar wird es dort, wo wir tatsächlich dasselbe Ergebnis zusagen wollen.
Nicht dasselbe behaupten. Dasselbe liefern können.
Vom Versprechen zum Nachweis
Dafür muss das Versprechen konkreter sein als „sicher, flexibel und einfach“. Beim Gastzugang möchte ich wissen, welche Trennung zugesagt ist, an welchen Standorten sie verfügbar sein soll, wie Änderungen beauftragt werden und wie der Kunde ihren Status erkennt. Welche Voraussetzungen brauchen wir? Was ist ausdrücklich nicht enthalten?
Daraus leite ich die benötigten Fähigkeiten und die passende Umsetzung ab. Ist die Plattform vorgegeben, prüfe ich, was sie selbst leistet und was Integration, Automatisierung und Betrieb ergänzen müssen. Anschließend brauche ich einen Nachweis, dass das Ergebnis die Anforderungen auch erfüllt.
Technik bleibt entscheidend. Der Maßstab für ihre Umsetzung ist das vereinbarte Kundenversprechen.
Der Gedanke dahinter ist nicht neu, und Promise Parity ist hier mein Arbeitsbegriff, kein neuer Standard. Auch MEF 70.2 – SD-WAN Service Attributes and Service Framework setzt beim nach außen sichtbaren Verhalten des Dienstes und bei den zwischen Kunde und Anbieter vereinbarten Serviceeigenschaften an. Diese Blickrichtung finde ich hilfreich: nicht beim Produktnamen stehen bleiben, sondern klären, was der Service tatsächlich leisten soll.
Für den Nachweis reicht mir nicht nur ein erfolgreicher Labortest. Ich möchte beispielsweise sehen, ob Bereitstellungen ohne ungeplante Nacharbeit durchlaufen, Änderungen den gewünschten Zustand erreichen und die zugesagten Eigenschaften auch im laufenden Betrieb bestehen. Welche Messgrößen dafür sinnvoll sind, muss aus der Nutzung entstehen. Den gleichen Ausgangspunkt beschreibt das Google-SRE-Kapitel zu Service Level Objectives: erst verstehen, was Nutzern wichtig ist, dann passende Messgrößen und Ziele festlegen.
Feature Parity: Nicht jede fehlende Funktion ist eine Produktlücke
Das ist der Teil, bei dem es unbequem werden kann.
Eine neue Herstellerfunktion gehört nicht automatisch ins eigene Angebot. Genauso wenig ist jede Funktion des Wettbewerbs automatisch eine Lücke im eigenen Produkt. Vielleicht brauchen sie unsere Zielkunden nicht. Vielleicht löst sie ein Problem außerhalb unseres Angebots. Vielleicht wäre sie eine sinnvolle Zusatzoption, aber kein Bestandteil des Standardservices.
Anders sieht es aus, wenn die Funktion für eine verbindliche Kundenanforderung oder das zugesagte Sicherheits- und Leistungsniveau notwendig ist. Dann ist sie eine echte Lücke. Die lässt sich nicht mit „wir denken jetzt in Kundennutzen“ wegmoderieren.
Ich möchte die Entscheidung deshalb bewusst treffen: Gehört die Fähigkeit in den Standard? Ist sie eine klar beschriebene Option? Eine individuelle Lösung? Oder bieten wir sie nicht an?
Dabei gehört der gesamte Aufwand auf den Tisch. Nicht nur die Lizenz, sondern auch Integration, Tests, Schulung, Migration und späterer Betrieb. Ein Workaround ist nicht kostenlos, nur weil keine neue Hardware bestellt werden muss.
Und jeder Aufwand bindet Zeit, die anschließend für etwas anderes fehlt. Deshalb ist „der Wettbewerb hat es auch“ ein Anlass zur Prüfung, aber noch keine ausreichende Priorisierung.
Die Technik wird dadurch nicht egal
Aus Kundensicht zu denken bedeutet nicht, technische Unterschiede kleinzureden. Ich komme aus dieser Welt und weiß, wie entscheidend sie für die Umsetzung sein können.
Wenn eine Lösung die benötigte Leistung, Isolation oder Integration nicht ermöglicht, hilft auch die schönste Servicebeschreibung nicht weiter. Manche Unterschiede lassen sich durch Engineering ausgleichen. Andere nicht. Und manche nur zu einem Aufwand, den man vernünftigerweise nicht dauerhaft tragen möchte.
Eine festgelegte Plattform macht diese Fragen nicht überflüssig. Sie gibt den Rahmen vor, in dem wir sie beantworten müssen. Mein Ziel ist nicht, Hersteller für austauschbar zu erklären, sondern technische Möglichkeiten und Grenzen am Kundenversprechen zu bewerten.
Bei den SASE-Fragen, mit denen ich mich beschäftige, wird das besonders deutlich. Sobald Standortanbindung, Zugriffe, Sicherheitsrichtlinien und Betrieb zusammenkommen, möchte ich nicht nur wissen, welche Bausteine vorhanden sind. Mich interessiert, ob Bestellung, Änderungen, Fehlerbehandlung und Verantwortlichkeiten zusammenpassen. Das ist eine Frage der Servicegestaltung, kein Plädoyer für eine bestimmte Plattform.
Bei Nexus ist es dieselbe Frage, nur kleiner
Auch bei Nexus, meinem eigenen Managed-IT-Plattformprojekt für kleine Organisationen, lande ich bei derselben Frage. Dort geht es unter anderem darum, Geräte zuzuordnen, einzurichten und ihren Zustand verständlich zu machen.
Nehmen wir als Beispiel einen Geräte-Onboarding-Ablauf: Ein Gerät ist registriert und erreichbar. Die vorgesehene Konfiguration ist aber noch nicht bestätigt. Was sieht der Nutzer jetzt? „Erfolgreich hinzugefügt“? „Einrichtung läuft“? Oder einen grünen Punkt, der mehr verspricht, als wir gerade wissen?
„Gerät registriert“ wäre als abschließende Erfolgsmeldung zu wenig, wenn der Nutzer darunter „Gerät einsatzbereit“ versteht. Ich möchte erkennbar machen, was bereits erledigt ist, was noch fehlt und wer als Nächstes etwas tun muss. Und wenn keine aktuelle Rückmeldung vorliegt, ist der Zustand eben unbekannt – nicht automatisch in Ordnung.
Das ist ein gedachter Ablauf und ein Anspruch an das Produkt, kein Bericht über einen konkreten Fehler. Der Punkt ist derselbe wie beim Gastzugang: Die technische Funktion kann vorhanden sein, während der versprochene Ablauf für den Nutzer noch nicht abgeschlossen ist.
Feature Parity bleibt nützlich – ich werde weiter Featurelisten vergleichen
Natürlich werde ich weiterhin prüfen, welche Plattform welche Funktion unterstützt. Ich werde mich auch weiter für APIs, Routing, Policies und die technischen Grenzen interessieren. Das ist kein Wechsel weg von der Technik.
Es ist eher eine zusätzliche Frage, bevor ich mich in ihr verliere: Was wollen wir damit eigentlich zusagen, und können wir das anschließend auch liefern?
Feature Parity hilft, technische Funktionen zu vergleichen. Ob daraus ein lieferbarer Service wird, muss jede Umsetzung für sich zeigen. Promise Parity fragt beim Vergleich mehrerer Umsetzungen, ob sie dasselbe Kundenversprechen einlösen können – auch auf derselben Plattform.
Keine dieser Prüfungen ersetzt die eigentliche Produktentscheidung: Für wen bauen wir etwas, welches Problem lösen wir, was bieten wir bewusst nicht an und welchen Aufwand wollen wir dafür tragen?
Der Haken in der Tabelle ist dafür ein Anfang. Kein fertiges Produkt.
Persönliche fachliche Einordnung. Ich schreibe hier nicht im Namen meines Arbeitgebers. Die Beispiele beschreiben keine konkreten Kundenprojekte oder internen Plattformentscheidungen.