Controller untersuchen und beurteilen traditionell die Effizienz und Effektivität anderer Fachbereiche, müssen aber zunehmend den Nachweis erbringen, selber so zu arbeiten. Excel ist eines der wichtigsten Standardprogramme im Controlling und Finanz- & Rechnungswesen vieler Unternehmen. Excel wird für die Planung & Budgetierung eingesetzt, für das Reporting, für Simulationen uvm.. In zahlreichen Publikationen zum Thema Planung, Risiko-Management, Treasury-Management u.a. wird festgehalten, dass aus vielen Gründen Excel für solche Aufgaben ungeeignet sei.
Diese Kritik an MS Excel ist so nicht zutreffend, denn die Ursachen sind nicht in den „Beschränkungen“ von MS Excel, sondern in den Kenntnissen der Anwender und der Anwendungsphilosophie in den Unternehmen zu suchen!
Kaum ein Unternehmen besitzt aber Nutzungskonzepte, Definitionen von notwendigen Excel-Kenntnissen für Mitarbeiter, eine Richtlinie zur Modellierung und Nutzung von Excel (CEP).
Aus diesen und weiteren Gründen können auf Excel-Modellen basierende Entscheidungen ein großes Risikopotenzial darstellen. So werden Excel-Modelle meist unabsichtlich fehlerhaft und ineffizient erstellt und Fehler unbemerkt im Informations- und Steuerungsprozess fortgeführt (Garbage in, Garbage Out). Im schlimmsten Fall werden hier existenzgefährdende Risiken für das Unternehmen nicht oder zu spät erkannt. Ganz abgesehen von den Sanktionen, die sich aus dem Verstoß gegen gesetzliche Regelungen wie die MaRisk, KonTraG und SOX ergeben. Sie sollten also den Einsatz von Excel in Unternehmen genauer unter die Lupe nehmen. Denn nach wie vor ist Excel unverzichtbar!
In dieser Beitragsserie soll eine alternative Anwendungsphilosophie dargestellt mit der der Excel-Workflow im Controlling optimiert werden kann. Es werden keine Excel-Techniken vermittelt.
Problem des Datenimports und der Anzahl der Datensätze
Im Fachbereich Controlling werden in der Regel zahlreiche IT-Systeme verwendet. Dabei dürfte SAP das am meisten eingesetzte ERP-System sein. Aus SAP & Co. werden die ge-wünschten Daten in irgendeinem Datenformat als Datei oder unmittelbar in eine Excel-Tabelle exportiert. Bei diesem Verfahren entsteht jedoch ein erheblicher Aufwand in der Nachbearbeitung der Daten. Die Ursache dafür sind der wenig „Excel-freundliche“ Aufbau und die Struktur der exportierten Standard-Berichte .
Mit sehr hohem manuellem Aufwand, teilweise mit VBA-Programmierung oder mit Zusatz-Tools werden diese Reports in Excel-Listen verwandelt. Dies ist völlig unnötig!
Alternative 1:
Sie könnten in Ihrem Vorsystem spezielle, für den Export nach Excel vorgesehene Berichte generieren (lassen). Hier stelle ich immer wieder fest, dass in diesem Bereich die Kenntnisse der Controller zur Berichtserstellung (z.B. in SAP) oder auch die Kenntnis über die vorhande-nen Berichte, Tabellen recht gering sind. Damit besteht eine Abhängigkeit von internen oder externen Experten!
Alternative 2:
SAP & Co. werden in Verbindung mit Datenbanksystemen (z.B. Oracle, SQL Server, DB2, etc.) eingesetzt. Mit einfachen Mitteln lässt sich eine Verbindung zwischen Datenbanksystem und Excel aufbauen (ODBC), mittels der Daten nach Excel exportiert werden können. Mit diesem Verfahren entfallen die üblichen Nacharbeiten eines Dateiimports. Die Schnittstelle ODBC wird über die Sprache SQL gesteuert, wofür Microsoft im Rahmen des Office-Paketes ein Tool MS Query zur Verfügung stellt.
Alternative 3 (Ergänzung vom April 2015):
Sie erstellen mit Hilfe des Add-Inn Power Query eine Datenmodell, in das sie die exportierten (SAP-)Dateien einladen. Dabei stellt Power Query automatisiert die von Ihnen benötigen Strukturen ohne Programmierung her.
So entsteht eine dynamische Verbindung zwischen Ihrem Excel-Modell und der Datenbank, die stets die aktuellen Daten in einem genau beschriebenen Umfang „liefert“. Der Vorteil:
- Kein Datenfriedhof mit 65.000 oder mehr (Excel 2007 oder jünger) Datensätzen!
- Die Dateien, die Sie nach der beschriebenen Modellierung erstellen und über MS Query mit den notwendigen Daten befüllen, sind deutlich kleiner als 1 MB! (Beispiel 3 im Downloadbereich).
- Die Daten lassen sich auf „Knopfdruck“ aktualisieren.
„Datentopf“
Sollten Sie keine Zugriffsberechtigung auf das primäre Datenbanksystem erhalten, können Sie als Alternative den benötigten Datenbestand periodisch aus dem Primärsystem in eine zweite, dezentrale Datenbank schreiben lassen.
Sollte auch das nicht möglich sein, richten Sie sich das dezentrale Datenbanksystem (Anmerkung April 2015: Das gilt auch, wenn Sie Power Query einsetzen! Siehe dazu diesen Blog-Eintrag Single-source-of-truth) selbst ein und „füttern“ es mit den als Datei exportierten Standardberichten. Das bedeutet einen gewissen Erstellungsaufwand, zahlt sich aber durch den Zeitgewinn aus!
Wenn Ihnen dieser Beitrag gefallen hat, dann teilen Sie ihn gerne. Falls Sie Anmerkungen haben, schreiben Sie bitte einen Kommentar, oder senden Sie mir eine Mail an info@prt.de.
Eine Antwort