Was sagt Dir das Kürzel poc? Der proof of concept. Vermutlich kennst Du das Instrument poc oder setzt es auch ein.
Kürzlich habe ich den Begriff p o v als Abkürzung für proof of value gelesen und fand schon alleine die Formulierung spannend.
Daher schauen wir heute auf die Intentionen dieser beiden Tools, wo die Unterschiede liegen und beschreiben eine Idee, wann deren Einsatz Ziel führend ist.
Starten wir mit dem proof of concept, dem poc.
Die Zielsetzung des poc ist zu überprüfen, was technisch machbar ist. Nehmen wir als Beispiel einmal an, dass ein Kunde seine Prozesse automatisieren möchte. Ihr evaluiert eine Business Process Engine und nehmt einen Workflow heraus, den ihr damit modelliert und laufen lasst. Damit habt Ihr dann an einem Beispiel gezeigt, dass die technische Lösung funktioniert.
Oder der Kunde möchte seine Systeme automatisiert gepatched haben und ihr setzt auch hierfür ein erstes Testszenario auf, das die technischen Wirkweisen und Zusammenhänge klärt.
Der Fokus des poc ist die technische Machbarkeit und eine Sache ist nicht im Fokus: nämlich der Nutzen oder auch der Wert gleich der Value für den Kunden aus diesem technischen Einsatz. Es wird nicht darauf geschaut, wie das Business aus diesem technischen Einsatz profitiert.
Und hier kommt der pov der proof of value ins Spiel.
Denn er beschäftigt sich mit der Frage, welchen Nutzen das Unternehmen aus der neuen Lösung ziehen möchte und dieser Nutzen ist eben nicht damit gesichert, dass eine Lösung technisch machbar ist, sondern diese Frage erfordert ein sich Hineinversetzen in den Kunden und seine Ziele.
Nehmen wir ein Beispiel aus der Nicht-IT Welt, um den Unterschied aufzuzeigen.
Nehmen wir an, wir produzieren Spezialregale für Lieferwagen und unsere Nutzenaussage ist, dass mit unseren Spezialregalen schneller be- und entladen werden kann und auch, dass mehr Pakete pro Wagen transportiert werden können. Das sind beides Faktoren, die einen Business-Nutzen beschreiben.
In einem poc untersuchen wir jetzt die technische Umsetzbarkeit. Wir nehmen einen Lieferwagen eines potenziellen Kunden und testen die folgenden Fragen:
- Lässt sich das neue Regalsystem einfach einbauen?
- Werden die auszuliefernden Pakete sicher gehalten, auch bei schnellem Anfahren und Stoppen?
- Fährt das Auto weiter sicher, auch auf unebenen Strecken?
- Ist das Beladen und Entladen einfach?
- Bleiben die Pakete am Platz oder schieben sie sich hin und her und stellen ein Risiko dar?
Auch wenn alle diese Fragen bejaht werden, ist der Business-Nutzen der Value für den Kunden damit nicht sichergestellt, das macht aber genau der proof of value.
Hier werden andere Werte gemessen. Die Anzahl der Pakete pro Wagen, die Dauer zum kompletten Beladen, die Dauer für das Entnehmen vor dem Ausliefern, vielleicht sogar die dauerhafte Fitness des Fahrers in einer Selbsteinschätzung, weil das neue Entladen so viel einfacher ist.
Bis hin zu Fragen in einem ausgeweiteten Test:
- Melden sich die Fahrer weniger krank?
- Werden mehr Pakete in der realen Welt ausgeliefert?
Ihr seht, beide Ansätze ein poc oder auch ein pov können Ziel führend sein. Das hängt von der Ausgangssituation des Kunden ab. Wichtig ist im Moment mitzunehmen, dass wir zwei unterschiedliche Ansätze haben.
Schauen wir also einmal zum Einsatz im Projekt oder auch im Managed Service Bereich.
Da Projekte in der Regel individuell sind, wird der proof of concept als Leistung gezogen, wenn sichergestellt werden soll, dass die angedachte Lösung auch funktioniert und mit der Gesamtumgebung des Kunden zusammenarbeitet
Da wir mit dem Kunden über ein einmaliges und wichtiges Unterfangen sprechen, ist dem Kunden meistens die Absicherung der technologischen Basis wichtig und es besteht eine Bereitschaft, den Weg eines poc zu gehen.
Gibt es poc oder pov auch bei MSP Aufträgen?
Wenn wir an die vielfach genutzten Standard MSP Leistungen wie Managed Server oder Managed Firewall denken, wird der Kunde sich vielleicht wundern, wenn wir die technische Machbarkeit testen wollten, oder?Wenn der Kunde aber eine Betriebssituation auslagern möchte, die einen individuelleren Ansatz benötigt, dann kann auch hier neben einer Infrastrukturaufnahme mit einem poc gearbeitet werden. Wenn die Systeme des Kunden zum Beispiel stark voneinander abhängen oder große Volumina automatisiert werden sollen.
Nehmen wir einmal an, wir haben entschieden, ob es aus technischen Gründen einen poc geben soll, bevor wir die kompletten Systeme in Betrieb nehmen.
Doch haben wir damit alle wichtigen Fragen geklärt? Ist nicht der proof of value vielleicht wertvoller für den Kunden? Also die beispielhafte Untersuchung, welchen Nutzen der Kunde mit der Dienstleistung eines MSP erreichen möchte?
Das ist eine ganz andere Fragestellung als die technische Machbarkeit.
Welche Nutzenaspekte könnte ein MSP proof of value überprüfen?
- Hat der Kunde mehr Zeit für andere Aufgaben?
- In der IT Abteilung
- Darüberhinaus in der GL
- Die Anwender
- Keine weiteren Einstellungen notwendig und Personalbudget geschont
Hat der Kunde eine bessere IT?
- Läuft die IT robuster?
- Ist die IT sicherer?
- Ist die IT schneller?
- Ist die IT mehr compliant?
Liefert die IT bessere Arbeitsprozesse und Daten?
- Durch den gezielteren Tooleinsatz?
- Durch mehr geteilte Datenzugriffe
- Durch mehr Video- & Chatkommunikation
- Können die Mitarbeiter jetzt beliebig remote gearbeitet werden?
Für diese Punkte ist mit dem Kunden im Sinne eines pov zu klären, wie die gewünschten Nutzenaspekte gemessen werden können und welche Vorstellung vom Ergebnis der Kunde hat.
Abschließend habe ich mir die Frage gestellt, wie und wann der pov bei den gängigen MSP Abläufen integriert werden kann?
Wie sieht eine vielfach aufgezeigte Standard-Prozesskette für MSP Leistungen aus? Wir haben
- Infrastrukturaufnahme
- Change Projekt
- Onboarding
- Transition
- Betrieb
Wo kann da jetzt ein proof of value integriert werden? Der poc ist relativ klar zwischen Infrastrukturaufnahme und Change Projekt positioniert, aber wann machen wir einen proof of value?
Nähern wir uns über eine andere Frage: Hat der Kunde wirklich seine Ziele erreicht, auch wenn der IT Betrieb fehlerfrei läuft? Wie sicher sind wir da?
Zum Abschluss hier eine Idee für Dich:
Am Ende der ersten Betriebsphase bspw nach 6 Monaten einen bewussten proof of value machen und nicht “einfach so” in die weitere Betriebsphase rutschen und weitermachen.
Also die Ziele des MSP Betriebs schon vor dem Onboarding klären, damit sie nach 6 Monaten im pov geprüft werden können.
Und rechtzeitig dafür sicherstellen, dass der Nutzen auch wirklich messbar ist. Damit wird dem Kunden klar, wo in seinem Unternehmen der „wahre“ Nutzen des MSP Betriebs entsteht und das ist vielfach eben außerhalb der IT beim Anwender oder gar beim Kunden unsere Kunden.