Zunächst sollte man sich klar darüber werden, worin die immanente Komplexität von Data-&-Analytics-Projekten liegt und was diese ausmacht. Es ist vor allem die Vielschichtigkeit, die sich dadurch ergibt, dass die Daten, die man analysieren möchte, in aller Regel in fachbereichs­übergreifenden Prozessen entstehen. Dies bedeutet, sie lassen sich nicht einem einzelnen Fachbereich zuordnen. Ebenso werden diese Daten auch von mehreren Unternehmens­bereichen benötigt. Was entsteht, sind also crossfunktionale Datenströme, bei denen es erst einmal zu definieren gilt, wer für sie verantwortlich sein soll. Hinzu kommt eine technische Komplexität, für die bei den Anforderungsgebern oft das Verständnis fehlt: Mögen Inhalte in fertigen Berichten und Dashboards, in Diagrammen und Tabellen oft einfach aussehen und auch logisch nachvollziehbar sein, so sind sie es nicht mehr, sobald man sich die zugrundeliegenden Datenflüsse und -strukturen anschaut. Es lohnt also, bereits ganz am Anfang des Projekts zu überlegen, wie man die Komplexität reduzieren kann und wen es zu involvieren gilt.

Ambitioniert ins Chaos? Lieber mit ehrlichen Antworten auf klare Fragen eine Basis schaffen.

Unabhängig vom Reifegrad oder der Branche ist die Ausgangssituation vielerorts sehr ähnlich: Das Management hat, zumeist mit dem hehren Ziel, die Wettbewerbsfähigkeit des Unternehmens zu steigern, ambitionierte Vorstellungen und Wünsche. Die oben skizzierte Komplexität verkennend wird dann der Fachbereich (welcher denn eigentlich?) mit der Erfüllung dieser Wünsche beauftragt. Während der Fachbereich versucht, die Anforderungen des Managements zu konkretisieren und dabei auch durchaus eigene Anforderungen einflicht, unterstützt die oftmals notorisch unterbesetzte IT-Abteilung ob des auf sie einprasselnden Fachbereichs-IT-Kauderwelschs nur widerwillig und halbherzig. Und am Ende hat man dann vielleicht eine Lösung entwickelt, die niemand(em) nutzt, und alle bleiben frustriert zurück.

Diese Misere lässt sich vermeiden, wenn man sich bereits zu Beginn darüber klar wird, wohin genau die Reise gehen soll, man also erst mal eine Data-&-Analytics-Strategie entwickelt. Die Gedanken können dabei – frei nach dem Motto „think big, start small“ – durchaus visionär sein. Wichtig ist es allerdings, deutliche Aussagen zu Zielen, Motivation und Ausrichtung zu treffen. Basis hierfür sind ehrliche Antworten auf kritische Fragen: Welche Bedeutung haben Daten im Unternehmen? Was genau soll die zu entwickelnde Lösung leisten können? Welche Zielkonflikte und Abhängigkeiten gibt es? Welche Technologien sind erforderlich, beispielsweise damit die Lösung am Ende auch skalierbar ist? Wer sind die Beteiligten? Welche Rollen und Verantwortlichkeiten sind zu definieren? Und eben weil sich das Thema Data & Analytics viel komplexer gestalten kann, als man im Vorfeld erwartet, und es einen durchaus überfordern kann, sollten schon in dieser frühen Phase die Schlüsselpersonen sowohl aus dem Fachbereich als auch aus der IT-Abteilung mit am Tisch sitzen. So werden alle – auch das Management – bereits von Anfang an nicht nur für die besagte Komplexität, sondern auch für den damit einhergehenden Zeitbedarf eines solchen Projektes sensibilisiert.

Wer macht was? Ein Projekt ist ein Projekt ist trotzdem ein Projekt.

Doch selbst wenn die Strategie steht, die Richtung also vorgegeben ist und auch schon Rollen definiert wurden, warten Fallstricke, wenn man sich nicht darüber im Klaren ist, dass es sich bei dem Vorhaben um ein Projekt handelt. Es gilt, eine Projektaufbau- und -ablauforganisation festzulegen, also beispielsweise wer zum Projektkernteam gehört und dabei welche Rolle ausübt, wie das Projekt gesteuert wird, welche Tools dafür notwendig sind und in welchen Abständen und wie das Management über Fortschritte informiert wird. Ebenso sollte Einigkeit über das Projektvorgehen und die Roadmap herrschen. Beantwortet man diese Fragen nicht bereits vor Beginn des Projekts, sind Missverständnisse im Projektverlauf praktisch unausweichlich.

Nach dem Motto „Planung ist das halbe Leben“ ist es darüber hinaus unerlässlich, dass sich alle Beteiligten über die konkreten fachlichen und technischen Anforderungen Gedanken machen. So müssen sie möglichst genau formulieren, was sie von der zu entwickelnden Lösung erwarten. Dazu gehört nicht nur die Frage, welchem Zweck beispielsweise ein Bericht dienen soll, sondern auch, wie er verteilt wird, wie das Berechtigungskonzept aussieht und ähnliches. Probates Mittel hierfür ist ein kleiner Fragenkatalog, der als eine Art Leitfaden dem Anforderungsgeber aufzeigt, was überhaupt zu definieren ist und in welcher Form dies idealerweise geschieht. Auf diese Weise kann die IT-Abteilung verstehen, was der Fachbereich erreichen möchte, ehe es an die technische Umsetzung geht. Am Ende dieses Prozesses muss sichergestellt sein, dass auf allen Seiten dasselbe Verständnis herrscht. Frühestens zu diesem Zeitpunkt ist dann auch eine grobe Schätzung des Aufwands möglich – davor ist es eher nur ein Raten.

Vertrauen ist gut – Vorbereitung, Zuordnung, Wissensaufbau und Zeit zudem.

Für Data-&-Analytics-Projekte wird immer häufiger festgelegt, dass ihr Weg in die Cloud führt. Dabei unterschätzt man aber vielerorts, dass das Thema Cloud sogar für viele IT-Abteilungen noch immer Neuland ist. Und selbst für ausgewiesene Cloud-Profis gestaltet sich die Einrichtung einer serviceorientierten Cloud-Infrastruktur deutlich aufwendiger als etwa das vergleichsweise simple Einrichten virtueller Maschinen. Wird dies nicht von vornherein berücksichtigt, kommt es bereits in dieser Phase des Projekts zu ersten Verzögerungen. Dies gilt umso mehr, wenn (Teile der) IT-Abteilungen ausgelagert sind, wodurch sich zusätzliche Schnittstellen und erhöhter Abstimmungsbedarf ergeben. Weitere Probleme drohen, wenn zum Beispiel nicht klar definiert, was – bezogen auf einzelne Anforderungen/Aufgaben, aber auch auf das gesamte Projekt – eigentlich „fertig“ bedeutet, es keine Testpläne oder Referenzwerte gibt oder plötzlich neue Anforderungen auftauchen; schnell ist da trotz seriöser Aufwandsschätzung das Budget überzogen.

Solchen Komplikationen lässt sich jedoch durch entsprechende Vorkehrungen vorbeugen. Dazu zählen insbesondere die bestmögliche Definition der Anforderungen und das grundsätzliche Vertrauen in die Experten, die das Lösungsdesign vornehmen. Nach Möglichkeit sollte man darum auch diese mit der Aufwandsschätzung betrauen. Ebenso müssen sich die Fachbereiche bewusst sein, dass sie nicht nur für das Formulieren der Anforderungen, sondern auch für das Testen der entwickelten Lösung benötigt werden. Entscheidend ist weiterhin ein guter Infrastrukturpartner, denn angesichts der vielfältigen und komplexen Themen, die sich schnell ändern können, stößt die eigene IT-Abteilung in Sachen Know-how und Kapazität oftmals schnell an ihre Grenzen. Noch ein Punkt: Eine vertrauensvolle, positive Atmosphäre im Team gepaart mit einer offenen Fehler- und Feedbackkultur bildet über alle Schritte hinweg die Basis für eine konstruktive Zusammenarbeit. Auch ist es wichtig, den betrauten Kollegen die notwendige Zeit zu geben, damit sie in der Lage sind, die gewünschte Qualität zu liefern, sowie Übergangsphasen von der Entwicklung in den Betrieb zu planen. Apropos Betrieb: Nicht zuletzt muss rechtzeitig Klarheit darüber bestehen, wer die Lösung nach ihrer Fertigstellung betreiben wird. Dabei ist abzuschätzen, ob interne Ressourcen einen reibungslosen Betrieb gewährleisten können oder ob ein Dienstleister damit beauftragt werden sollte.

Auch in Data-&-Analytics-Projekten bewahrheitet sich wie so oft, dass eine durchgängige Transparenz Akzeptanz und Vertrauen schafft. Unternehmen sollten dabei auf die Stärken ausgewiesener Experten bauen, solche Projekte aber gleichzeitig auch als beste Chance für die Mitarbeiterbindung nutzen, indem sie bestehende Potenziale identifizieren und diese in der Folge auch nutzen. Und ganz wichtig: allen Dingen die notwendige Zeit lassen!