In thinkBI Folge 40 teile ich zwei Situationen aus meinem Arbeitsalltag. Beide zeigen, wie schnell wir über eine technische Lösung sprechen, während die fachliche Frage noch offen ist.
In einem Kundentermin ging es um die Datenbereitstellung aus Business Central für Power BI. Die bestehende Strecke greift über APIs auf das ERP zu und muss die Daten umfangreich transformieren. Das macht die Verarbeitung komplex und anfällig für Abbrüche oder Zugriffslimits.
Der vorgestellte Ansatz war, die Daten als Spiegel in Fabric bereitzustellen und die Transformationen dort vorzubereiten. Operatives System und analytische Verarbeitung könnten dadurch besser getrennt werden. Power BI müsste weniger Aufbereitungslogik selbst übernehmen.
Der Kunde erkannte den Nutzen. Seine Einordnung war trotzdem deutlich: Die Technik sei Beiwerk. Entscheidend sei, ob am Ende sein Business-Problem gelöst werde.
Das war eine hilfreiche Rückmeldung. Ich war für die technische Perspektive hinzugekommen. Den fachlichen Beitrag, den der Kunde brauchte, konnte ich in diesem Termin damit noch nicht leisten.
Welche Aussage sollen die Daten ermöglichen?
Das eigentliche Problem lag in der Aussagekraft der vorhandenen Daten. Der Kunde wollte über den Zeitverlauf nachvollziehen, welche Umsätze ursprünglich erwartet wurden, welche später tatsächlich fakturiert wurden und welche Kosten dagegenstanden. Daraus sollte ein Deckungsbeitrag entstehen.
Dazu braucht es mehr als einen zuverlässig geladenen Datenbestand. Die Werte liegen im Vorsystem auf unterschiedlichen Ebenen. Außerdem muss das Fachwissen über das konkrete Geschäft in die Aufbereitung einfließen.
Besonders deutlich wird das beim Pauschalgeschäft. Wenn ein Umsatz als Gesamtpauschale erfasst ist, aber ein Deckungsbeitrag auf einzelnen Artikelpositionen ausgewiesen werden soll, stellt sich zuerst eine fachliche Frage: Welche Aussage kann ein solcher Wert überhaupt tragen?
Eine Berechnung lässt sich technisch umsetzen. Damit ist ihre Bedeutung noch nicht geklärt. Die Zuordnung von Umsatz und Kosten auf die gewünschte Ebene muss fachlich diskutiert werden. Erst dann kann das Modell eine belastbare Aussage liefern.
In diesem Projekt mussten andere Beteiligte die analytische Anforderung weiter spezifizieren. Teilweise waren auch Änderungen im Vorsystem erforderlich, damit benötigte Werte passend erfasst oder vorgehalten werden konnten. Die Anforderung an eine Analyse reicht damit bis in die Entstehung ihrer Daten zurück.
Den Zeitverlauf bei der Erfassung mitdenken
Für die zeitliche Betrachtung finde ich eine Postenlogik besonders interessant. Dabei werden Zugänge, Änderungen und Abgänge mit einem Zeitbezug festgehalten. Aus diesen Bewegungen lässt sich ein Stand zu einem bestimmten Zeitpunkt ableiten.
Übertragen auf erwartete Umsätze: Zunächst wird eine Erwartung erfasst. Später reduziert ein fakturierter Umsatz den noch offenen erwarteten Betrag. Eine verbleibende Erwartung kann zu einem weiteren Zeitpunkt verfallen. Werden diese Veränderungen nachvollziehbar protokolliert, lässt sich ihre Entwicklung auf dem Zeitstrahl abbilden.
Das ist zunächst ein Modellierungsgedanke. Welche Ereignisse dafür erfasst werden müssen und wie sie fachlich zusammenhängen, muss für den jeweiligen Prozess geklärt werden.
Meine Präferenz ist, diese Informationen möglichst bereits bei der Erfassung im Vorsystem mitzuprotokollieren. Dann bleibt die zeitliche Entwicklung aus den dort vorhandenen Daten ableitbar. Die analytische Plattform kann diese Grundlage aufbereiten und auswerten.
Die praktische Frage lautet deshalb: Ist die benötigte Entwicklung in den Daten überhaupt nachvollziehbar? Eine stabilere Übertragung hilft uns wenig bei einer Zeitfrage, deren relevante Veränderungen bisher gar nicht erfasst wurden.
Wenn Bedeutung erst im Bericht entsteht
Der zweite Fall begann mit einer scheinbar überschaubaren Anforderung: Ein bisher manuell erzeugter SAP-Export sollte automatisiert werden. Die Daten wurden anschließend in Excel ausgewertet.
Zunächst sah es nach einer Auswertung von Abweichungen aus. Durch Rückfragen wurde deutlich, dass dieselbe Datengrundlage möglicherweise auch für Margenanalysen genutzt werden sollte. Der Ausschnitt, den ich gesehen hatte, beschrieb die Gesamtheit der Anforderungen also noch nicht. Fachlich deutete sich eher ein gemeinsames Finanzmodell an, aus dem verschiedene Auswertungen entstehen könnten.
Die vorhandene Grundlage war eine breite Tabelle. Ihre analytische Bedeutung entstand erst im Excel-Bericht: Der Fachanwender filterte bestimmte Werte zusammen und benannte Inhalte um. Diese Schritte gehörten zur fachlichen Logik, blieben aber im einzelnen Bericht und im Verständnis des jeweiligen Anwenders.
Wird lediglich der Export automatisiert, bleibt diese Verteilung der Logik bestehen. Die Daten kommen regelmäßiger an. Wie daraus eine bestimmte Aussage wird, muss weiterhin aus den Berichten und dem Wissen der Anwender erschlossen werden.
Meine Empfehlung war deshalb, die Semantik in einem gemeinsamen semantischen Modell festzuhalten und darauf die Berichte aufzubauen. Dafür müssen Datengrundlage, fachliche Bedeutung und Anzeige bewusst getrennt werden. Eine Berichtsansicht darf weiterhin filtern. Die fachlichen Regeln, auf denen ihre Aussage beruht, sollten im Modell nachvollziehbar sein.
Das betrifft auch die Sprache. Im Bericht wurden teilweise andere Begriffe für Entitäten verwendet als im sonstigen Sprachgebrauch. Solche Synonyme gehören zur Klärung der Bedeutung. Werden sie im semantischen Modell berücksichtigt, können sie später auch eine sprachbasierte Abfrage unterstützen. Ob eine KI die gemeinte Entität zuverlässig erkennt, muss im konkreten Einsatz geprüft werden.
Der Beratungsauftrag bleibt auch im technischen Ausschnitt
Die beiden Fälle führen zur gleichen Frage: Welche fachliche Klärung fehlt noch, damit die technische Arbeit das gewünschte Ergebnis ermöglicht?
Im ersten Fall braucht der Kunde eine tragfähige Betrachtung von Umsätzen, Kosten und ihrer zeitlichen Entwicklung. Im zweiten muss die Bedeutung aus einzelnen Excel-Berichten erschlossen und in ein gemeinsames Modell überführt werden.
Im Arbeitsalltag sehen wir oft nur einen Ausschnitt. Wir kommen für eine technische Aufgabe hinzu, kennen noch nicht alle Anforderungen oder haben keinen Zugang zu allen Beteiligten. Das begrenzt, was wir unmittelbar lösen können.
Trotzdem können wir Rückfragen stellen und die Lücke benennen. Was soll ausgewertet werden? Auf welcher Ebene ist die Aussage fachlich sinnvoll? Welche Veränderungen müssen erfasst sein? Welche Logik entsteht bisher erst im Bericht?
Business Intelligence verbindet Entscheidungen systematisch mit Informationen. Dafür brauchen wir zuverlässige Technik und ein gemeinsames Verständnis davon, welche Aussage die Daten tragen sollen.
Wenn eine Datenstrecke morgen stabil läuft: Welche fachliche Frage können wir damit tatsächlich besser beantworten?
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
