Selber machen oder kaufen?

Die Diskussion in Unternehmen

Werkzeuge sagen mehr über ihre Nutzer aus als über sich selbst. Wer zum Akkuschrauber greift, denkt anders als jemand, der Möbel fertig kauft. Auch in der Datenanalyse ist das nicht anders: Manche Werkzeuge lassen sich flexibel und tiefgreifend anpassen – erfordern aber technisches Know-how. Andere funktionieren per Mausklick, sind sofort einsatzbereit – aber eben auch limitiert in ihrer Anpassbarkeit.

Zwei jeweils gegensätzliche Paare bestimmen die Diskussion in vielen Unternehmen: «Low-Code vs. Programmierung» und „Open Source vs. proprietär”. Dabei geht es nicht nur um Technologie, sondern um Zugänglichkeit, Kontrolle, Kosten und strategische Weichenstellungen im Controlling.

In diesem Abschnitt beleuchten wir beide Spannungsfelder. Wir zeigen, was hinter den Begriffen steckt, welche Auswirkungen sie in der Praxis haben und wie Controller fundierte Entscheidungen treffen können, wenn es darum geht, den eigenen Werkzeugkasten nicht nur zu füllen, sondern auch nachhaltig zu gestalten.

Low-Code vs. Programmierung

Wer heute Daten analysieren möchte, muss nicht zwangsläufig programmieren können. Low-Code-Tools wie KNIME, Alteryx oder Power BI versprechen, komplexe Analysen mit wenigen Klicks aufzubauen. Statt Zeile für Zeile Code zu schreiben, werden Bausteine verbunden, Formeln konfiguriert und Diagramme zusammengeklickt. Für viele Controller ist das eine enorme Erleichterung: Sie können ihre fachliche Logik direkt umsetzen, ohne sich durch Syntaxregeln oder Datentypen kämpfen zu müssen.

Vorteile von Low-code

Low-Code steht dabei für eine visuelle, zugängliche Form der Datenbearbeitung. Der Fokus liegt auf schnellen Ergebnissen, Wiederverwendbarkeit und geringem Einarbeitungsaufwand. Besonders wenn oft Ad-hoc-Analysen oder wiederkehrende Reports gefragt sind, kann Low-Code die Effizienz massiv steigern. Workflows in KNIME oder Power BI sind transparent, dokumentierbar und im besten Fall sogar teamfähig und damit leicht weiterzugeben.

Doch die Medaille hat eine zweite Seite: Low-Code ist zwar einfach, aber nicht beliebig flexibel. Wer tiefergehende Modelllogik, individuelle Schnittstellen oder algorithmische Entscheidungen umsetzen will, stößt schnell an Grenzen. Zudem neigen visuelle Tools bei wachsender Komplexität zur Unübersichtlichkeit: Ein KNIME-Workflow mit 80 Nodes kann schwerer zu warten sein als 100 Zeilen sauber strukturierter Python-Code.

Vorteile klassischer Programmierung

Hier beginnt das Terrain der klassischen Programmierung. Tools wie Python oder R erfordern zunächst mehr: technisches Denken, Syntaxverständnis, Fehlersuche. Doch der Aufwand zahlt sich aus. Denn mit Programmierung lassen sich hochgradig individuelle, modulare und skalierbare Lösungen bauen, die sich in moderne IT-Landschaften mit Datenbanken und APIS nahtlos einfügen.

Vor allem aber schärft Programmierung das Denken. Wer einmal gelernt hat, eine Schleife zu schreiben, versteht Prozesse anders. Wer eine Funktion abstrahiert, lernt, sauber zu modellieren. Wer ein Modell trainiert, überlegt, wie man es testet. Programmierausbildung – auch autodidaktisch – bedeutet nicht nur, Maschinen zu steuern, sondern logische Strukturen zu erkennen, zu optimieren und zu erklären. Diese Fähigkeit ist im datengetriebenen Controlling von unschätzbarem Wert.

So sollten Controller abwägen

Viele Controller haben das intuitiv erkannt und sich mit Google, YouTube und Forenbeiträgen VBA-Makros zusammengebastelt, die ganze Monatsreports steuern. So bewundernswert der Pragmatismus auch ist: In der Praxis entstehen daraus oft schwer wartbare Lösungen voller Workarounds, Copy-Paste-Logik und kryptischen Zellreferenzen. Wer einmal das Excel-Monster eines Kollegen übernommen hat, weiß: Low-Code ist kein Ersatz für sauberes Denken, sondern eine Abstraktionshilfe, die klare Logik voraussetzt.

Die Entscheidung «Low-Code oder Programmierung» ist daher keine Entweder-oder-Frage. Vielmehr sollten Controller wissen:

• Wofür reicht Low-Code und ab wann reicht es nicht mehr?
• Wann lohnt es sicher, tiefer einzusteigen und eigene Tools zu entwickeln?
• Wie kann man beides kombinieren?

Ein Controller, der grundlegende Programmierlogik versteht, kann auch Low-Code-Tools besser nutzen: sauberer strukturieren, Fehler systematischer beheben, komplexe Anforderungen eleganter umsetzen. Umgekehrt können visuelle Tools der ideale Einstieg sein, um schrittweise zu verstehen, wie man aus Daten Entscheidungen macht.

Open Source vs. Proprietär

Neben der Frage «Wie arbeite ich?» – also mit Low-Code-Tools oder klassischer Programmierung – stellt sich eine zweite, ebenso grundlegende: «Womit arbeite ich?» Gemeint ist damit: Nutze ich ein offenes, frei verfügbares Werkzeug oder bin ich an einen bestimmten Hersteller gebunden? Diese Unterscheidung zwischen Open Source und proprietären Lösungen ist weit mehr als eine technische Fußnote – sie betrifft Kosten, Kontrolle, Innovationsfähigkeit und die strategische Unabhängigkeit im Controlling.

Open Source bedeutet zunächst: Der Quellcode des Werkzeugs ist öffentlich zugänglich, darf verändert, weitergegeben und angepasst werden. Tools wie Python, R oder auch KNIME (in der freien Version) sind Paradebeispiele dafür. Sie kosten nichts, werden von globalen Communities gepflegt und wachsen oft schneller als kommerzielle Plattformen. Für Controller heißt das: hohe Flexibilität, Zugang zu modernsten Verfahren – aber auch Verantwortung. Wer ein Open-Source-Tool nutzt, muss sich selbst um Installation, Wartung und Updates kümmern oder entsprechendes Know-how im Team aufbauen.

Demgegenüber stehen proprietäre Systeme wie Microsoft Excel, Power BI, Alteryx oder SAP Analytics Cloud. Diese Tools bieten vor allem eins: Verlässlichkeit. Sie sind meist eng mit anderen Systemen integrierbar, zentral verwaltet und gut dokumentiert. Der Support kommt vom Hersteller, die Updates automatisch. Für viele Controller wirkt das wie ein sicherer Hafen – verständlich, denn wer täglich Reports liefern muss, will sich nicht mit Paketkonflikten oder Code-Fehlern herumschlagen. Doch auch hier gibt es Schattenseiten: Lizenzkosten, eingeschränkte Anpassbarkeit und das Risiko, bei Produktveränderungen oder Preisanpassungen des Anbieters machtlos zu sein. Man nennt dies auch «Vendor Lock-in», wenn die Software eines bestimmten Anbieters so tief im Unternehmen integriert ist, dass ein Wechsel nicht mehr mit vertretbarem Aufwand möglich ist.

Gerade im Controlling wird diese Unterscheidung relevant. Denn hier geht es nicht nur um den nächsten Bericht, sondern um stabile, langfristig wartbare Prozesse. Ein Forecast-Modell in Python ist transparent, reproduzierbar und exakt dokumentiert – aber nur, wenn jemand im Team versteht, was dort passiert. Ein Dashboard in Power BI hingegen funktioniert sofort, integriert sich nahtlos ins Microsoft-Ökosystem – aber nur im Rahmen dessen, was die Plattform erlaubt.

Viele Unternehmen kombinieren beides. Sie nutzen Open Source im Backend, etwa zur Datenvorbereitung, Modellierung oder Automatisierung, und proprietäre Tools im Frontend, also zur Visualisierung und Verteilung. Diese hybride Strategie ist oft der klügste Weg: Sie verbindet technologische Freiheit mit betrieblicher Stabilität.

Die entscheidende Frage ist daher nicht, welches Tool «besser» ist – sondern wie viel Kontrolle man selbst behalten will. Open Source eröffnet große Freiheiten, erfordert aber Verantwortung. Proprietäre Tools bieten Komfort, bedeuten aber auch Abhängigkeit. Controller sollten diese Dynamik verstehen und bewusst entscheiden, welche Freiheitsgrade sie wirklich brauchen.

Tabelle: Einordnung verschiedener Tools nach Bedienung und Lizenzierung

Hinweis

Der Text ist ein Auszug aus dem Buch „ Künstliche Intelligenz und Data Science im Controlling verstehen und anwenden " von Florian Bliefert, erschienen 2026 bei VCW.