Michael Darnieder

Michael Darnieder ist Geschäftsführer und Gründer der TEDEXA GmbH und bringt KI, Daten und Prozesse so zusammen, dass daraus messbarer Nutzen für Unternehmen entsteht. Sein ganzheitlicher Blick auf KI verbindet Strategie, Technologie, Recht, Ethik, Kultur und Umsetzung – damit aus Ideen wirksame Lösungen werden.


Über

Michael Darnieder hat Diplom-Informatik in Wiesbaden studiert und bereits während seines Studiums individuelle Softwarelösungen und datengetriebene Anwendungen für Mittelstand und Konzerne aus Handel, Banken, Medien und Telekommunikation entwickelt.

Seit 2010 liegt sein Fokus auf der Erneuerbare-Energien-Branche – dort, wo komplexe Prozesse, Daten und digitale Transformation direkt aufeinandertreffen. Mit TEDEXA entwickelt er individuelle Softwarelösungen, die Unternehmen helfen, Prozesse besser zu verstehen, Entscheidungen datenbasierter zu treffen und digitale Potenziale nutzbar zu machen.

Seit 2017 beschäftigt er sich intensiv mit Data Science und Künstlicher Intelligenz. Um in einem sich rasant verändernden Umfeld nicht nur mitzuhalten, sondern fundiert beraten zu können, bildet er sich regelmäßig an renommierten Universitäten weiter.

Heute verbindet er technologische Tiefe, Branchenverständnis und strategische Beratung zu einem ganzheitlichen KI-Ansatz. Sein Anspruch: KI nicht als Tool-Hype zu behandeln, sondern wirtschaftlich wirksam, rechtssicher und kulturell tragfähig im Unternehmen zu verankern. Besonders in der Erneuerbare-Energien-Branche sieht er darin einen wichtigen Hebel, um den Weg zu 100 % erneuerbarer Energie zu beschleunigen.

Sein Motto: Every company needs to think AI-first.

IBCS® Certified Consultant

Michael Darnieder hat im May 2026 erfolgreich die IBCS®-Zertifizierung zur Gestaltung von Berichten und Präsentationen im IBCS® Institut abgeschlossen.

IBCS Arbeitsprobe – Vom Excel-Chart zum entscheidungsorientierten Report

Die größte Herausforderung dieser Arbeitsprobe bestand nicht darin, einen bestehenden Report IBCS-konform umzuwandeln. Die eigentliche Schwierigkeit lag darin herauszufinden, was der ursprüngliche Report überhaupt zeigen sollte.

A. Ausgangslage

Die vorhandenen Auswertungen basierten auf einer Excel-geprägten Datenstruktur. Es gab viele Varianten sehr ähnlicher Charts, pivotiert je Rolle oder je Status.

Inhaltlich blickten diese Darstellungen auf dieselben Daten, nur aus leicht unterschiedlichen Perspektiven. Weiterhin war die Datenmenge sehr klein. In vielen Diagrammen bestand der Wert fast überall nur aus „1“. Dadurch war auf den ersten Blick schwer zu erkennen, ob eine Häufung, ein Trend, eine Belastung oder ein Projektfortschritt dargestellt werden sollte.

Hinweis: Der Begriff Meilenstein wurde synonym zu Status verwendet.

Zentral war deshalb zunächst die Frage: Welche Management- oder Steuerungsfrage soll der Report beantworten?

Diese Frage ließ sich in zwei wesentliche Perspektiven übersetzen:

A.1 Wie verteilen sich die betreuten Projekte nach Rolle, Person und Projektstatus?

Hier geht es um Transparenz über die operative Projektverantwortung. Wer betreut welche Projekte? In welchem Status befinden sie sich? Und wo entstehen mögliche Belastungsschwerpunkte?

A.2 Wie entwickelt sich die Projektpipeline über Meilensteine und Quartale?

Hier steht die Frage im Mittelpunkt, wann Projekte bestimmte Meilensteine erreichen und welche Leistung damit verbunden ist. Wichtig war dabei die Trennung zwischen Anzahl der Projekte und installierter Leistung, da beide Kennzahlen unterschiedliche Aussagen liefern.

A.2.a Die Anzahl Projekte zeigt die Menge der Vorgänge

Wie viele Projekte erreichen einen bestimmten Meilenstein in einem Quartal?
Das ist wichtig für operative Belastung, Prozessdurchlauf, Bearbeitungsaufwand und Kapazitätsplanung.

Beispiel:
Wenn in Q2 fünf Projekte zur Genehmigung eingereicht werden, bedeutet das viel Koordinations-, Dokumentations- und Abstimmungsaufwand — auch dann, wenn die dahinterstehende installierte Leistung vergleichsweise gering ist.

A.2.b Die installierte Leistung in MW zeigt dagegen die wirtschaftliche bzw. strategische Bedeutung

Wie viel potenzielles Leistungsvolumen steckt hinter den Projekten, die einen Meilenstein erreichen? Das ist wichtig für Portfolio-Wert, Umsatzpotenzial, Pipeline-Qualität und strategische Planung.

Beispiel:
Ein einziges großes Projekt mit 25 MW kann wirtschaftlich wichtiger sein als fünf kleine Projekte mit jeweils 5 MW. Nach Projektanzahl sieht Q2 dann „klein“ aus, nach Leistung aber sehr bedeutend.

A.3 Aktuelle Reports aus der Excel-Datei des Kunden (anonymisiert)

A.3.1 Reports

A.3.1.1 Anzahl Projekte und installierte Leistung für den Status Antragseinreichungen

A.3.1.2 Anzahl Projekte und installierte Leistung für den Status Genehmigungen

A.3.2 Reports zu betreuten Projekten und Status je Rolle

A.3.2.1 Anzahl betreuter Projekte und Status für Rolle Projektmanager

A.3.2.2 Anzahl betreuter Projekte und Status für Rolle Projektleiter Akquise

A.3.2.3 Anzahl betreuter Projekte und Status für Rolle Außendienstmitarbeiter (ADMA)

B. Umsetzung

Die bestehenden Reports wurden nicht einfach überarbeitet. Stattdessen wurden auf Basis der eigentlichen Fragestellungen komplett neue Reports entwickelt.

Im ersten Schritt wurden die vorhandenen Auswertungen analysiert und inhaltlich entschlüsselt: Welche Dimensionen werden verwendet? Welche Kennzahlen werden gezeigt? Welche Varianten sind nur technische oder Excel-bedingte Ableitungen derselben Sicht? Danach wurden die relevanten Fragestellungen herausgearbeitet und die ursprünglichen Chart-Varianten reduziert.

Im zweiten Schritt wurden die Daten so vorbereitet, dass die Reports überhaupt konsistent funktionieren konnten. Besonders wichtig war, fehlende Kategorien wie Quartale oder Projektstatus vollständig abzubilden, auch wenn für einzelne Kombinationen kein Wert vorhanden war. Außerdem musste sauber zwischen Ist-Werten und zukünftigen Forecast-Werten unterschieden werden.

Im dritten Schritt wurden zwei zentrale Reports neu konzipiert und umgesetzt.

B.1 Neue Reporte

B.1.1 Report 1 – Anzahl betreuter Projekte je Rolle, Person und Projektstatus

Der erste Report zeigt die Anzahl betreuter Projekte je Rolle, Person und Projektstatus. Dafür wurde eine Small-Multiple-Struktur gewählt. Statt mehrere isolierte Einzelcharts nebeneinanderzustellen, entstand eine einheitliche Sicht über Rollen und Personen hinweg. Dadurch wird schneller erkennbar, wie sich Projekte auf Verantwortliche und Status verteilen.

Transformation (grob)

B.1.2 Report 2 – Anzahl betreuter Projekte je Rolle, Person und Projektstatus

Der zweite Report zeigt die Meilensteinentwicklung nach Projektanzahl und installierter Leistung. Auch hier wurde eine Small-Multiple-Struktur genutzt. Projektanzahl und Leistung wurden bewusst getrennt, aber gemeinsam lesbar dargestellt. So entsteht ein klarer Blick auf die Projektpipeline: Welche Meilensteine werden in welchen Quartalen erreicht, und welche MW-Leistung steckt dahinter?

Transformation (grob)

Bemerkungen:

  1. Der Report kann wie ein Projekt-Funnel gelesen werden. Die Meilensteine bilden dabei keine harte Zeitachse ab, sondern folgen der prozessualen Ablauf- und Reifelogik eines Windenergieprojekts. Je weiter unten ein Projekt in diesem Funnel erscheint, desto weiter ist es im Entwicklungsprozess fortgeschritten – und desto mehr fachliche Arbeit, Abstimmung und Investition steckt bereits darin.
  2. FORECAST statt PLAN
    Datumsangaben in der Zukunft werden nicht als PLAN sondern als FORECAST dargestellt:
    Begründung: A plan is what you want to happen. A forecast is what you expect will happen.
    Forecast passt hier besser, da man immer abhängig von anderen ist (Arbeitsgeschwindigkeit der Behörden, Terminplanung der Lieferanten, Kooperation von Gemeinden, …)

C. Fazit

Das Ergebnis ist kein kosmetisches Re-Design bestehender Excel-Charts, sondern eine fachliche Neuentwicklung der Reports. Ausgangspunkt war nicht die Frage Wie machen wir dieses Diagramm IBCS-konform?, sondern: Welche Entscheidung soll durch den Report besser getroffen werden können?

Genau darin lag der Kern der Arbeitsprobe: aus unklaren, variantenreichen Ausgangsauswertungen eine klare Reporting-Struktur zu entwickeln, die Status, Verantwortung, Meilensteine und Pipeline-Entwicklung verständlich und vergleichbar macht.