Excel ablösen mit SharePoint und Co: Wie ein Citizen-Developer-Projekt das Millionenrisiko entschärfte
- Marcus Machon
- vor 6 Tagen
- 7 Min. Lesezeit
30 Personen aus verschiedenen Abteilungen. Mehrere Excel-Dateien pro Monat per E-Mail. Ein manueller Konsolidierungsprozess mit Copy-Paste und Formeln. Und ein Fehler in den Daten hätte einen zweistelligen Millionenbetrag kosten können. Das war 2020 die Realität bei einem großen Kunden. In diesem Beitrag beschreibe ich, wie ich Excel mit SharePoint ablösen konnte, welche Bordmittel dafür reichten und was beim Rollout wirklich passiert ist. Und warum sogenannte U-Boot-Projekte oft erfolgreicher sind als offizielle Projekte.
Warum laufen geschäftskritische Prozesse immer noch über Excel?
⚡ Weil Excel keine Genehmigung braucht. Es ist verfügbar, es funktioniert, und niemand fragt nach einem Business Case. Genau das macht es so riskant.
Der Prozess, den ich 2020 vorfand, dürfte vielen bekannt vorkommen. Einmal im Monat trugen rund 30 Personen aus verschiedenen Abteilungen ihre Daten in Excel-Dateien ein und schickten sie per E-Mail an eine zentrale Stelle. Dort wurden die Dateien manuell zusammengeführt: Copy-Paste, Formeln, Querverweise. Das Ergebnis war ein Report für ein Entscheidungsgremium.
Das klingt beherrschbar. War es nicht. Die Daten in diesem Report hatten direkte Auswirkungen auf Investitionsentscheidungen. Wenn Termine oder Werte falsch gewesen wären und es niemandem aufgefallen wäre, hätte das einen zweistelligen Millionenbetrag kosten können. Kein theoretisches Szenario. Ein reales Risiko.
Wie realistisch solche Fehler sind, zeigt die Forschung. Eine Meta-Studie von Poon et al. (2024, Frontiers of Computer Science) hat über 35 Jahre wissenschaftliche Literatur zu Spreadsheet-Fehlern ausgewertet. Das Ergebnis: 94 % aller geschäftlich genutzten Spreadsheets im Entscheidungskontext enthalten Fehler. Der Spreadsheet-Forscher Ray Panko (University of Hawaii) erklärt warum: Die menschliche Fehlerrate bei komplexen Aufgaben wie Formeln schreiben liegt bei 1–5 % pro Eingabe. Bei einem typischen Sheet mit 200 Formeln nähert sich die Wahrscheinlichkeit, dass mindestens ein Fehler im Ergebnis steckt, 100 %. Weitere "Anekdoten" zu teuren Excel Fehlern hier: Excel ablösen mit Microsoft 365: Risiken, Alternativen, Praxisanleitung.
Das Unternehmen wusste um das Risiko. Es gab mehrfach den Versuch, ein IT-Projekt aufzusetzen, um den Prozess mit einer professionellen Datenbanklösung zu digitalisieren. Jedes Mal wurde es abgelehnt. Zu teuer, zu komplex, andere Prioritäten. Der Excel-Prozess lief weiter.
Wie lässt sich ein Excel-Reporting mit SharePoint ablösen?
⚡ Mit Microsoft Lists als strukturierte Dateneingabe, Power Query für die automatische Zusammenführung und Power Automate für den Datenimport. Alles Bordmittel, die in den meisten Microsoft-365-Lizenzen bereits enthalten sind.
Irgendwann kamen die Beteiligten auf mich zu. Nicht über den offiziellen IT-Dienstweg. Sondern als das, was man ehrlich ein U-Boot-Projekt nennen muss: „Können wir das nicht mit Bordmitteln besser lösen?“ Ich habe mich alleine hingesetzt. Vier Monate hat es gedauert. Die Kosten lagen im niedrigen fünfstelligen Bereich (vorwiegend meine Arbeitszeit). Hinweis: ich habe das Projekt auch "nebenbei" gemacht.
Die Lösung bestand aus mehreren Bausteinen, die alle bereits im Microsoft-365-Paket des Unternehmens verfügbar waren:
Eine SharePoint Teamwebsite zwecks Rollen- und Rechtemanagement und zur Dokumentation bzw. Anleitungen in Form von SharePoint Seiten.
Die Excel-Dateien wurden durch eine zentrale SharePoint-Liste mit knapp 4.000 Einträgen ersetzt. Statt in individuelle Tabellen trugen die Beteiligten ihre Daten direkt in diese Liste ein. Microsoft Lists (oder auch als SharePoint-Listen bezeichnet) bot dafür eine strukturierte Oberfläche mit Validierungsregeln. Zusätzlich habe ich mehrere Referenzlisten (sogenannte Lookup-Listen) angelegt, die für einheitliche Eingaben sorgten. Das Ganze funktionierte wie eine kleine Datenbank innerhalb von Microsoft 365. Jede Änderung war auch über die Versionshistorie lückenlos dokumentiert: Wer hat wann welchen Wert geändert? Siehe auch hier: Microsoft Lists vs Excel: Dateneingabe im Team strukturieren
Power Automate übernahm den Import von Daten aus Quellsystemen.
Als Backup (inkl. mehrerer automatisierter CSV Exporte) und für die Nachvollziehbarkeit und Änderungshistorie gab es eine Archivliste. Die hatte irgendwann mehrere hundertausende Zeilen. Ja, es gibt einen Schwellenwert von 5.000 Zeilen in Microsoft Lists, dies ist aber kein hartes Limit!
Zum Stichtag wurden alle Daten dann automatisiert mit Excel Power Query zusammengeführt und in einen fertigen Report überführt, inklusive Gegenüberstellung zum Vormonat. Siehe auch: Power Query: Das mächtigste Excel-Tool, das fast niemand kennt.
Und später kam Power BI hinzu: nicht als Reporting-Tool, sondern zur Qualitätssicherung. Sind alle Einträge vollständig? Gibt es Unstimmigkeiten? Fehlen Datensätze? Eine solche Prüfebene hatte es im Excel-Prozess schlicht nicht gegeben.
Was passiert, wenn die Belegschaft „nur Excel“ kennt?
⚡ Widerstand. Immer. Aber er legt sich, wenn die Vorteile im Alltag spürbar werden. Der entscheidende Moment ist nicht der Go-Live, sondern die ersten vier Wochen danach.
Der Rollout war nicht reibungslos. Die häufigste Rückmeldung: „Ich kenne nur Excel, da kann ich direkt in die Zelle schreiben. Wie funktioniert das hier?“ Das ist nachvollziehbar. Menschen arbeiten seit Jahrzehnten mit Excel. Eine SharePoint-Liste sieht anders aus und fühlt sich anders an.
Aber der Widerstand hat sich gelegt. Nicht durch große Change-Management-Workshops, sondern weil die Vorteile im Alltag spürbar wurden. Einheitliche Eingabemasken statt freier Zellen. Keine doppelten Dateiversionen mehr. Kein „Welche Datei ist die aktuelle?“-Problem.
Die häufigste Beschwerde danach: „Die Daten sind falsch.“ Meine Antwort war jedes Mal dieselbe. Ich bin in die Versionshistorie gegangen und konnte zeigen: Nein, ein Kollege hat die Daten heute früh geändert. Ob die Änderung korrekt war, konnte ich nicht beurteilen. Aber das System hatte keinen Fehler gemacht. Diese Transparenz war neu. Und ehrlich gesagt für manche auch unbequem.
War die Lösung perfekt? Nein. Das größte Problem blieb bestehen: Menschen müssen Daten eintragen, und manche tragen sie nicht ein oder tragen sie falsch ein. Kein Tool der Welt löst das. Aber die technische Fehlerquote (Formelfehler, Kopierfehler, veraltete Versionen) ging auf nahezu null zurück. Und das Rückmeldung nach einigen Monaten war eindeutig: standardisiertes Reporting, nachvollziehbare Daten, und eine Grundlage, auf der sich aufbauen ließ. Siehe auch diesen Blogbeitrag: Excel ablösen mit Microsoft 365: Risiken, Alternativen, Praxisanleitung
Citizen Developer vs. IT-Großprojekt: Was kostet die professionelle Alternative?
⚡ Ein Schwesterunternehmen digitalisierte einen ähnlichen Prozess mit einer klassischen IT-Lösung. Dauer: vier Jahre. Kosten: mehrere hunderttausend Euro. Die Citizen-Developer-Lösung: vier Monate, ein Bruchteil der Kosten.
Das Interessante an diesem Projekt war der direkte Vergleich. Ein Schwesterunternehmen hatte einen ähnlichen Reporting-Prozess und ihn 2012 mit einer professionellen IT-Lösung digitalisiert. Damals waren vier bis fünf Entwickler vor Ort, das Projekt lief über mehrere Jahre, und die Kosten lagen geschätzt im hohen sechsstelligen Bereich.
Ich will das nicht kleinreden. 2012 war eine andere Zeit. Die Microsoft-Plattform hatte nicht annähernd die heutigen Möglichkeiten. Power Query war in den Kinderschuhen. Microsoft Lists existierte nicht. Eine individuelle Entwicklung war damals oft die einzige Option.
Aber der Vergleich zeigt, was sich verändert hat. Heute sind die Bordmittel von Microsoft 365 so leistungsfähig, dass eine einzelne Person mit Fachbereichswissen in vier Monaten eine Lösung bauen kann, die im Ergebnis der teuren Individuallösung nicht nachstand. In der Flexibilität war sie sogar überlegen: Änderungen mussten nicht durch einen externen Dienstleister laufen, sondern konnten direkt umgesetzt werden.
Die Lösung lief übrigens fünf Jahre im Produktivbetrieb, von 2020 bis Ende 2025, und wurde dann planmäßig von einer echten Datenbanklösung abgelöst. Fünf Jahre für einen Bruchteil der Kosten.
Warum sind kleine Projekte oft erfolgreicher als IT-Großprojekte?
⚡ Laut Standish Group CHAOS Report haben kleine IT-Projekte eine Erfolgsquote von rund 90 %. Bei großen Projekten liegt sie unter 10 %. Der Grund: kurze Wege, weniger Komplexität, schnellere Rückkopplung.
Dieses Projekt war ein U-Boot. Es lief an sämtlichen offiziellen IT-Prozessen vorbei. Keine Freigabe, kein Pflichtenheft, kein Lenkungsausschuss. Compliance-technisch war das nicht ideal. Aber die Alternative war: weitermachen mit Excel. Also ein reales Risiko gegen ein formales abwägen.
Die Forschung gibt diesem Vorgehen recht. Der Standish Group CHAOS Report 2020, eine der größten Erhebungen zu IT-Projekterfolg mit über 50.000 Projektprofilen, zeigt ein klares Muster: Kleine Projekte erreichen rund 90 % Erfolgsquote. Bei großen Projekten liegt sie unter 10 %.
Und es wird nicht besser. Eine McKinsey-Studie in Zusammenarbeit mit der University of Oxford (Analyse von über 5.400 IT-Projekten) zeigt: Große IT-Projekte überschreiten das Budget im Schnitt um 45 % und liefern 56 % weniger Nutzen als geplant. 17 % der Projekte gefährden sogar die Existenz des Unternehmens. Eine BCG-Erhebung aus 2024 bestätigt: Mehr als zwei Drittel der großen Tech-Programme verfehlen ihre Ziele. Keine Verbesserung seit zehn Jahren.
In meiner Erfahrung sind U-Boot-Projekte nicht die Ausnahme, sondern die Regel für erfolgreiche interne Digitalisierung im Mittelstand. Das typische Muster bei offiziellen Projekten: Jemand hat eine Idee und ein konkretes Problem. Aber Gremium A versteht die Materie nicht. Gremium B vertagt die Entscheidung. Person C muss das Budget freigeben. Person D hat kein Interesse, weil sie nur Risiko sieht, aber keinen Nutzen. Und eine Initiative, die technisch in Wochen umsetzbar wäre, erstickt in Abstimmungsschleifen.
Bei einem U-Boot-Projekt passiert das nicht. Kleines Team, kurze Wege, keine Politik. Die Beteiligten kennen das Problem, wollen es lösen und stimmen sich direkt ab.
Dazu kommt: Die verwendeten Werkzeuge (SharePoint, Microsoft Lists, Power Query, Power Automate) sind vom Unternehmen freigegebene Bordmittel. Es wird keine unsichere Schatten-IT (wenn man sich mit den Tools auskennt!) eingeführt. Im Gegenteil: Die Lösung ist deutlich sicherer als die Excel-Realität, die sie ersetzt. Differenzierte Zugriffsrechte statt „jeder sieht alles“. Eine Versionshistorie statt „wer hat was wann geändert?“. Eine zentrale Datenquelle statt 30 Kopien auf verschiedenen Laufwerken.
Laut Gartner (2022) werden bis 2026 rund 80 % der Low-Code-Nutzer außerhalb der IT-Abteilung sitzen (ich bezweifle aber, dass die Zahlen 2026 wirklich eingetreten sind 😉). Was ich 2020 gemacht habe, ist kein Einzelfall. Es ist ein Megatrend. Die Frage für Unternehmen ist nicht, ob Citizen Development passiert, sondern ob sie es ermöglichen oder blockieren.
Fazit: Die größte Gefahr ist nicht die Bordmittel-Lösung
Dieser Prozess lief fünf Jahre produktiv, entschärfte ein konkretes Millionenrisiko und kostete einen Bruchteil der professionellen Alternative. Er war nicht perfekt. Aber er war besser als die Realität, die er ersetzt hat. Und das ist der Maßstab. Hier ist mein alter LinkedIn Post zum Projekt.
Heute wäre eine solche Lösung übrigens noch schneller realisierbar. Nicht weil KI den Prozess automatisch baut (das tut sie noch nicht), sondern weil Werkzeuge wie Microsoft 365 Copilot als Lernhilfe fungieren können: Power-Query-Formeln erklären, SharePoint-Strukturen durchdenken helfen, Fehler schneller finden. Die Einstiegshürde für Citizen Developer sinkt weiter.
Wenn Sie ähnliche Prozesse in Ihrem Unternehmen haben (und die Wahrscheinlichkeit ist hoch), dann stellt sich eine ehrliche Frage: Ist es riskanter, einer Fachkraft mit Bordmitteln (und einer kompetenten Beratung...) eine Lösung bauen zu lassen? Oder jeden Monat einen geschäftskritischen Report auf Copy-Paste und Excel-Formeln zu stützen?
Marcus Machon berät Mittelständler bei Microsoft 365 Governance, Prozessautomatisierung
