Softwareauswahl: Ist ein Proof Of Concept (POC) erforderlich?

Einige Softwarehersteller und Integratoren bieten Ihnen einen POC (Proof-Of-Concept) an, um die Machbarkeit eines Projekts zu bestätigen. Meistens ist es der Kunde, der dies beantragt. Ist dies eine Komfortphase, um den Kunden zu beruhigen, oder ist es ein obligatorischer Vorgang, um die Risiken zu verringern?

Alle Organisation und Planung Software ansehen

Vor- und Nachteile eines POC für den Kunden.

Es gibt eine Reihe von Vorteilen bezüglich eines Proof of Concept (POC) für den Kunden, hier die wichtigsten :

• Die Synchronisierung der Erwartungen mit dem Anbieter ;
• Ein besseres Verständnis des Implementierungsprozesses;
• Die Identifizierung von funktionalen Mängeln oder Überbewertungen ;
• Ein besseres Verständnis der erforderlichen Investitionen. Ein genauerer Rahmen ermöglicht ein besseres Verständnis der Investitionen, die zur Vervollständigung der Umsetzung erforderlich sind ;
• Die Bewertung des Implementierungspartners. Der inhärente POC-Prozess ermöglicht es dem Kunden, die Software und den Implementierungspartner zu bewerten.

Es gibt auch Grenzen des POC-Prozesses, die beachtet werden sollten. Diese sind:

• Die kommerzielle Flexibilität. Die in einigen POC-Vereinbarungen eingebaute Flexibilität, die es dem Kunden ermöglicht, aussteigen zu können, ohne die Software zu kaufen, wird in der Realität selten in Betracht gezogen, da eine große Investition an Geld und Zeit getätigt wurde. Außerdem trifft der Kunde aufgrund des geringen Risikos dieser Option häufig die Entscheidung, in ein POC einzusteigen, ohne alle Lösungen vollständig zu bewerten.
• Die Übung für den Verkauf. Je nach den bestehenden Handelsvereinbarungen kann das POC in den Verkaufszyklus integriert sein, so dass die Fähigkeit des Anbieters, diese Informationen vollständig offenzulegen, eingeschränkt ist. Darüber hinaus kann die im POC erstellte Dokumentation Marketinginhalte haben, die dem Projekt keinen Wert hinzufügen.

Dieser Artikel ist der zweite Teil eines zweiteiligen Tutorials. Im ersten Teil ging es um die Analyse der Struktur eines POC und wie diese mit dem Auswahlprozess korrespondiert.

Vor- und Nachteile eines POC für den Anbieter.

Die Vorteile für den Anbieter sind folgende:

• Einen Wettbewerbsvorteil im Verkaufsprozess haben. Der POC ist ein weiteres Werkzeug im Werkzeugkasten des Verkaufs. Der POC kann verwendet werden, um den potenziellen Kunden in die nächste Phase des Verkaufsprozesses zu bringen, ohne dass er sich voll engagieren muss.
• Bessere Umsetzung und zufriedene Kunden. Ein zentraler Erfolgsfaktor für jeden VAR oder Softwareanbieter ist es, Kunden zu haben, die bereit sind, als Referenz zu dienen. Jedes Tool, das die Kundenzufriedenheit verbessert, sollte geprüft werden.

Die Nachteile für den Verkäufer sind folgende:

• Der Zeitrahmen für den Verkauf. Das POC kann den Verkaufsprozess verlängern. Außerdem wird der Zeitplan (wichtig für börsennotierte Unternehmen) unsicherer, was zu einer weiteren Preissenkung führen kann.
• Anfragen nach Ressourcenberatung. Aufgrund der Natur des POC können die Beratungsanfragen umfangreich und ressourcenintensiv sein. In der Regel sind erfahrenere Berater verpflichtet, dafür zu sorgen, dass das POC zu einem Bestellschein führt.

Alle Organisation und Planung Software ansehen

Wann sollte ein POC durchgeführt werden?

Ein POC sollte als Teil des Auswahlprozesses durchgeführt werden , wenn das Risiko, dass das Projekt scheitert, relativ hoch ist. Das Risiko kann anhand von zwei Schlüsselvariablen gemessen werden. Diese Variablen sind die Komplexität der Anforderungen und das Niveau der Fachkenntnisse innerhalb des Auswahl- und Umsetzungsteams (EOM). Je komplexer die Anforderungen an das System sind, desto größer ist der Nutzen, der aus einem POC gezogen werden kann. Die Komplexität lässt sich anhand der Anzahl und Art der implementierten Module, des Anteils der Anpassung, der Anzahl der Schnittstellen sowie der Menge und Qualität der umzuwandelnden Daten messen.
Die Anzahl der zu implementierenden Module (z. B. eine reine Finanzimplementierung im Vergleich zu einer Finanz- + Vertriebs- + Speicherimplementierung) erhöht den Umfang der Implementierung und damit das Risiko. Darüber hinaus wirkt sich auch die Art der einzusetzenden Module auf das Risiko aus. Module wie Sales Force Automation (SFA) in einer Customer Relationship Management (CRM)-Suite haben tendenziell ein höheres Risikoprofil als Finanzmodule wie Debitorenbuchhaltung.
Der Grad der Fachkenntnis innerhalb des Auswahl-/Implementierungsteams ist ebenfalls ein wichtiger Indikator. Zu berücksichtigende Faktoren sind :

• Die Kenntnis der Branche
• Die Kenntnis der bestehenden Geschäftsprozesse.
• Das Verständnis des Auswahlprozesses für hochwertige Software.
• Das Wissen über das Management von Softwareanbietern.
• Die Kenntnis von ERP/CRM-Systemen.

Anhand dieser Faktoren sollte die Kompetenz Ihres Teams gemessen werden. Ein Team mit den besten Fähigkeiten hilft, den Risikofaktor für das Projekt zu verringern.
Die folgende Tabelle stellt diese Faktoren dar und zeigt, wie Sie feststellen können, ob ein POC für den Auswahlprozess erforderlich ist :

Über den Autor

Robert Rudd ist ein fachkundiger Berater für ERP-Lösungen mit mehr als neun Jahren Erfahrung in der Implementierung von ERP-Systemen. Seine Erfahrung umfasst auch die Informationstechnologie, die Kunden im Finanz- und Bankensektor unterstützt. Er hat ERP-Systeme in einer Reihe von Branchen implementiert, ist aber auf das Lieferkettenmanagement spezialisiert. Rudd arbeitet für das in Australien ansässige Unternehmen Scalable Data System. Scalable Data Systems implementiert seit über zwanzig Jahren Unternehmenslösungen für den mittleren Markt.