Erstellen Sie in vier Schritten einen Proof-of-Concept
Gehen Administratoren ein Proof-of-Concept-Projekt an, müssen sie auf vieles achten: von den technischen Anforderungen bis hin zu den wichtigsten beteiligten Interessengruppen.
Das Designen und Entwickeln von Tools und Anwendungen ist ein aufwendiges Projekt für IT-Abteilungen und fordert erhebliche Zeit- und Kapitalinvestitionen. Aus diesem Grund sollten Unternehmen für solche Projekte eine Proof-of-Concept-Projekt durchführen, um zu überprüfen, ob ein neues Tool oder eine neue Anwendung den langfristigen Bedürfnissen der Mitarbeiter gerecht wird.
Ein Proof-of-Concept-Plan durchläuft mehrere Schritte. Ziel ist es, sicherzustellen, dass die neue Anwendung oder das neue Tool die Anforderungen erfüllt und dass das IT-Team gemeinsam mit den zuständigen Abteilungen Einschränkungen oder Mängel rechtzeitig erkennt und ausbessert.
Schritt 1: Stellen Sie genau fest, warum Sie die neue Anwendung oder das neue Werkzeug brauchen
Entscheiden Sie zunächst, was das neue Tool oder die neue Anwendung leisten muss und warum es überhaupt einen Proof-of-Concept erfordert. In der Regel besteht eine geschäftliche Notwendigkeit, den Betrieb zu rationalisieren oder die Zuverlässigkeit durch das Erstellen einer Anwendung oder eines Tools zu erhöhen. So könnte es zum Beispiel eine gute Idee sein, ein fehleranfälliges und langsames manuelles Zeiterfassungssystem durch ein automatisches zu ersetzen.
Die IT-Abteilung muss nicht mit jedem einzelnen Stakeholder in der Organisation sprechen – aber es kann nicht schaden.
Dieser erste Schritt ist entscheidend: Ohne den Zweck eines neuen Tools oder einer neuen Anwendung klar zu definieren, wird ein Projekt zeitaufwändig und kostspielig.
Schritt 2: Bestimmen Sie die Stakeholder
Stakeholder sind die Personen, die direkt – entweder negativ oder positiv – von den Auswirkungen des neuen Projekts betroffen sind. Sie benutzen das Tool direkt, pflegen es, erhalten Informationen daraus oder fügen Informationen hinzu.
Das Benennen von Stakeholdern geht Hand in Hand mit dem bereits genannten Schritt, da das IT-Personal sich mit ihnen austauschen muss, um die Notwendigkeit des Projekts zu erfassen – das heißt um etwaige Mängel einer bestehenden Anwendung, Prozesses oder Tools zu beheben.
Beim Zeiterfassungs-Tool aus unserem Beispiel wären das die Buchhaltung, die Mitarbeiter, deren Zeit erfasst werden soll und die Systemadministratoren. Die IT-Abteilung muss nicht mit jedem einzelnen Stakeholder in der Organisation sprechen – aber es kann nicht schaden. Zumindest sollten diese über den Stand des Projekts informiert werden und die Möglichkeit erhalten, mit den Verantwortlichen in Kontakt zu treten.
Schritt 3: Planen Sie die Anforderungen an die Anwendung oder das Werkzeug
Nachdem Sie festgestellt haben, warum das Projekt notwendig ist und wen es betrifft, definieren Sie seine Anforderungen und notwendigen Ressourcen. Dabei kann es sich um technologiespezifische Anforderungen handeln, wie zum Beispiel die Anbindung bestimmter Datenbanken, bestimmte Laufzeitumgebungen oder Serverarchitekturen. Nehmen Sie eine grobe Schätzung vor und definieren und entwickeln Sie die Anforderungen dann im Laufe des Proof-of-Concept-IT-Projekts weiter.
Das wären im Falle unseres Beispiels die Folgenden:
das System exportiert automatisch zum Buchhaltungssystem für die Lohnkostenabrechnung.
Zusätzlich zu den technischen Anforderungen kann es geschäftliche oder personelle Anforderungen für den Proof of Concept geben, zum Beispiel, dass bestimmte Mitarbeiter oder Abteilungen einbezogen werden müssen. Im Falle unseres Zeiterfassungsantrags könnten dies die am Genehmigungsprozess beteiligten Personen sein.
Abbildung 1: Vorsicht Verwechslungsgefahr! Proof of Concept und Prototyp sind nicht dasselbe.
Schritt 4: Entwurf eines Prototyps
Der nächste Schritt in einem Proof-of-Concept-IT-Projekt ist das Bauen eines Prototyps, um zu verstehen, wie ein praktikables Produkt aussehen könnte. Eine neue Anwendung unternehmensweit auszurollen ist teuer. Deshalb ist es aus finanzieller Sicht sinnvoller, die IT-Abteilung erst einen Prototyp entwickeln zu lassen, der sich, wenn er ausgereift genug ist, skalieren lässt.
Bei einem Zeiterfassungssystem könnte ein solcher Prototyp folgendermaßen aussehen:
Ein Low-Code-Tool zum Experimentieren mit dem Frontend und der Benutzeroberfläche der Anwendung;
Ein Benutzer-Login, das SAML-Authentifizierung verwendet und Benutzer der richtigen Rolle zuweist, zum Beispiel Standardbenutzer oder Administrator;
Ein Zeitkarteneingabe-Bildschirm, der es Benutzern ermöglicht, sieben Tage lang numerische Werte für eine bestimmte Woche einzugeben;
Eine automatisierte E-Mail, die zur Genehmigung an den Vorgesetzten des Benutzers gesendet wird;
Die Möglichkeit für den Vorgesetzten, die Eingabe zu genehmigen oder die Stunden nach Bedarf anzupassen; und
Die Möglichkeit, eine CSV-Datei für die Finanzabteilung zu generieren und zu exportieren, die in ein Buchhaltungsprogramm geladen werden kann.
