Sie müssen kein Datenblatt lesen, um ein IoT-Projekt gut zu führen. Sie müssen den Umfang ehrlich abstecken, die Arbeit so anordnen, dass die riskanten Teile früh sichtbar werden, und den richtigen Leuten die richtigen Fragen stellen, bevor Geld fließt. Projektmanager, die mit IoT kämpfen, behandeln es meist wie eine Software-Einführung mit ein paar angeschraubten Sensoren. Wer Erfolg hat, behandelt es als physisches Projekt, das nebenbei Daten produziert, und steckt seine Energie in die Teile, die kein Ingenieur abnehmen kann: Anforderungen, Abstimmung, Risiko und Lieferanten.
Dieser Leitfaden richtet sich an den Projektmanager ohne Hardware-Hintergrund, dem gerade ein IoT-Projekt und eine Frist zugeteilt wurden. Es geht darum, wie Sie den Umfang abstecken, ihn in Phasen mit belastbaren Zeitplänen zerlegen, wo Sie persönlich den größten Beitrag leisten und welche Fragen verhindern, dass ein Projekt aus dem Ruder läuft.
Das Ergebnis abstecken, nicht die Technik
Der schnellste Weg, die Kontrolle über ein IoT-Projekt zu verlieren, ist, beim Gerät anzufangen. Fangen Sie bei der Entscheidung an, die die Daten stützen sollen. Ein Facility-Team will keine Temperaturwerte, es will wissen, welche Kühlgeräte kurz vor dem Ausfall stehen, bevor die Ware verdirbt. Ein Flottenbetreiber will keine GPS-Signale, er will Kunden korrekt abrechnen und das nächstgelegene Fahrzeug disponieren. Schreiben Sie das Ergebnis in einem Satz auf, den ein Geschäftsverantwortlicher unterschreiben würde, und arbeiten Sie sich dann rückwärts vor: was gemessen werden muss, wie oft und wer darauf reagiert.
Dafür müssen Sie nicht wissen, wie ein Sensor funktioniert. Die Fragen sind betrieblich, nicht technisch. Welche Entscheidung ändert sich, wenn die Daten eintreffen? Wie aktuell müssen die Daten sein, damit die Entscheidung noch zählt? Wer sieht sie, und in welcher Form? Was passiert, wenn ein Gerät verstummt? Beantworten Sie das, und Sie haben das Projekt definiert. Das Engineering-Team übersetzt Ihre Antworten in Hardware und Firmware, das ist deren Aufgabe, nicht Ihre.
Die Falle, die Sie vermeiden müssen: ein Umfang, der Sensor für Sensor wächst. Irgendjemand will immer noch einen Messwert hinzufügen, weil das Gerät ihn technisch erfassen kann. Halten Sie sich an das Ergebnis, das Sie aufgeschrieben haben. Zusätzliche Daten, auf die niemand reagiert, sind Kosten ohne Ertrag, und nichts ist leichter, als in einem Meeting Ja dazu zu sagen.
Die Arbeit in Phasen gliedern
IoT-Projekte scheitern, wenn sie von der Folie direkt zu tausend Geräten im Feld springen. Die Lösung ist, in Phasen vorzugehen, jede darauf ausgelegt, eine bestimmte Art von Risiko auszuräumen, bevor Sie mehr ausgeben.
Discovery kommt zuerst. Sie bestätigen das Ergebnis, wählen die Kennzahlen und lassen das technische Team prüfen, ob die Messung in Ihrer Umgebung überhaupt machbar ist. Das sind vor allem Meetings und ein wenig Tests auf dem Labortisch, und es dauert ein paar Wochen.
Der Pilot ist die Phase, die sich wirklich auszahlt. Sie setzen eine kleine Anzahl echter Geräte an einem echten Standort ein und beweisen, dass die ganze Kette funktioniert: Gerät zu Konnektivität zu Plattform bis zu der Person, die auf die Daten reagiert. Ein Pilot misst sich in Wochen, nicht in Monaten, und hier entdecken Sie die Dinge, die kein Plan vorhersieht. Das Gateway hat im Keller kein Signal. Der Sensor liest sauber, bis ihn die Laderampe mit Staub überschüttet. Der Alarm geht um 3 Uhr morgens los und niemand hat Rufbereitschaft. Besser, Sie finden das mit zehn Geräten als mit zehntausend.
Der begrenzte Rollout weitet den Pilot auf einen größeren Ausschnitt der realen Umgebung aus: genug Standorte und Bedingungen, um die Schwankungen sichtbar zu machen, die der Pilot übersehen hat. Der Produktivbetrieb ist der skalierte Einsatz, sobald die früheren Phasen aufgehört haben, Sie zu überraschen. Der Betrieb ist keine Phase, die endet, sondern der Dauerzustand, in dem das Projekt nach dem Start lebt, und er braucht von Anfang an einen Verantwortlichen und ein Budget.
Widerstehen Sie jedem Druck, von Discovery direkt in den Produktivbetrieb zu springen. Die Phasen existieren, um Unbekanntes in bekannte Kosten zu verwandeln, solange die Rechnung noch klein ist.
Ehrlich über Zeitpläne sein
Senior-Stakeholder wollen ein Datum. Geben Sie ihnen stattdessen einen Verlauf, und erklären Sie, warum der Verlauf die ehrliche Antwort ist. Ein Pilot steht in wenigen Wochen. Ein begrenzter Rollout kommt auf Wochen bis Monate, je nachdem, wie viele Standorte und wie viel physische Installation im Spiel sind. Der Produktivbetrieb läuft über Monate, und die Lücke zwischen Pilot und Produktivbetrieb ist fast immer größer als erwartet, weil die Skalierung die Schwankungen von Standort zu Standort offenlegt, die ein einzelner sauberer Pilotstandort verborgen hat.
Der Grund, warum IoT-Zeitpläne aus dem Ruder laufen, ist selten die Software. Es ist die physische Welt. Genehmigungen, Zugang zum Standort, Elektriker, Montage, Funklöcher und Geräte, die sich im Feld anders verhalten als auf dem Schreibtisch. Planen Sie Puffer für die physische Arbeit ein, bestehen Sie auf einem Pilot vor dem Produktivbetrieb, und Sie werden sich auf Termine festlegen, die Sie tatsächlich halten.
Wo Sie den größten Beitrag leisten
Die Engineering-Arbeit ist nicht Ihre Aufgabe, und sie selbst machen zu wollen, ist der Weg, auf dem nicht-technische Projektmanager an Glaubwürdigkeit verlieren. Ihr Wert liegt an vier Stellen, die darüber entscheiden, ob das Projekt liefert.
Die Anforderungen sind die erste. Sie sind derjenige, der sich mit dem Geschäft zusammensetzen und festnageln kann, was das Projekt leisten muss, in einer Sprache, gegen die das technische Team bauen kann. Ein klares Anforderungsdokument verhindert mehr Nacharbeit als jedes Werkzeug.
Die Abstimmung der Stakeholder ist die zweite, und sie hört nie auf. IoT-Projekte berühren Betrieb, IT, Finanzen und oft einen Kunden. Sie alle auf dasselbe Ergebnis auszurichten, ist Arbeit, die nur ein Projektmanager gut macht.
Das Risiko ist das dritte. Sie sind die Person, die verfolgt, was schiefgehen kann und welcher Plan dann greift. Konnektivität, Geräteausfall, Daten, auf die niemand reagiert, ein Lieferant, der einen Termin reißt. Die Risiken früh zu benennen und Verantwortliche zuzuweisen, ist Ihre Aufgabe.
Das Lieferantenmanagement ist das vierte. Sie arbeiten mit Hardware-Lieferanten, einem Konnektivitätsanbieter, einer Plattform und möglicherweise einem Integrator. Sie auf Umfang, Termine und klare Schnittstellen zwischen ihren Teilen festzulegen, ist eindeutig Projektmanager-Arbeit, und dafür braucht es keinen Ingenieurabschluss.
Die Fragen, die Sie stellen sollten
Gute Fragen gleichen viel fehlendes technisches Wissen aus. Stellen Sie diese Ihren Lieferanten, bevor Sie sich festlegen. Wie lang ist Ihre tatsächliche Lieferzeit für Hardware, auch in den schlechten Monaten? Was passiert mit meinen Daten, wenn ich aufhöre, Sie zu bezahlen? Wie werden Geräte im Feld aktualisiert, sobald sie installiert sind? Wie sieht der Support um 2 Uhr morgens aus, wenn ein Standort ausfällt? Wer verantwortet die Integration in meine bestehenden Systeme, Sie oder ich?
Stellen Sie eine entsprechende Reihe an Ihr eigenes Team. Was ist die größte einzelne technische Unbekannte, und wie testen wir sie im Piloten? Welchen Teil davon hat keiner von uns je gemacht? Wenn der Pilot scheitert, woran erkennen wir das, und was ist der Plan B? Die Antworten zeigen Ihnen, wo das Projekt fragil ist, solange Sie noch Zeit haben, etwas dagegen zu tun.
Die Fallstricke, in die die meisten Teams tappen
Ein paar Fehler tauchen bei fast jedem problematischen IoT-Projekt auf. Teams behandeln es wie ein reines Software-Projekt und vergessen, dass Hardware Lieferzeiten hat, physisch ausfällt und sich an verschiedenen Standorten unterschiedlich verhält. Sie unterschätzen die Schwankungen im Feld und nehmen an, ein guter Pilotstandort stehe für jeden Standort. Sie überspringen den Piloten, um Wochen zu sparen, und zahlen es im Produktivbetrieb vielfach zurück. Und sie kalkulieren das Projekt als einmaligen Aufbau ohne Betriebsbudget, sodass es ein Jahr nach dem Start dunkel wird, wenn niemand den laufenden Betrieb verantwortet.
Jeder dieser Punkte ist ein Planungsfehler, kein technischer, was bedeutet: jeder liegt in Ihrer Verantwortung, ihn zu verhindern.
Wie eine Managed-Plattform verkleinert, was Sie selbst verantworten müssen
Jeder Teil eines IoT-Systems, den Ihr Team von Grund auf baut, ist ein Teil, den Ihr Team für immer betreiben, absichern und reparieren muss. Eine Managed Application Platform wie TagoIO nimmt Ihnen die Dashboards, das Gerätemanagement, die Datenspeicherung, die Alarmierung und die APIs ab und setzt auf der Gerätekonnektivität auf, sodass Ihr Team eine Anwendung ausliefert, statt einen Stack zu betreiben. Für einen nicht-technischen Projektmanager zählt das, weil es die technische Fläche verkleinert, für die Sie verantwortlich sind. Es gibt weniger eigenes Backend abzustecken, weniger bewegliche Teile im Betrieb am Leben zu halten und einen kürzeren Weg vom Piloten zum Produktivbetrieb.
Es hilft auch bei den Teilen Ihrer Arbeit, die kein Engineering sind. TagoIO ist nach ISO 27001 zertifiziert und GDPR-konform, was Ihnen eine belastbare Antwort gibt, wenn Finanzen oder ein Kunde nach Sicherheit und Datenverarbeitung fragen. TagoRUN lässt einen Integrator ein White-Label-Portal als Konfigurationsaufgabe statt als Eigenbau liefern. TagoCore deckt Open-Source-Edge-Verarbeitung ab, wenn Sie sie brauchen. Nichts davon nimmt Ihnen die Notwendigkeit, das Projekt abzustecken, anzuordnen und zu steuern. Es nimmt Ihnen eine Schicht technischen Risikos, die Sie sonst allein tragen würden.
