Um was geht es in dem Artikel?

Dies ist ein allgemeiner Artikel darüber, was "Budgetierungsautomatisierung" ist, aus welchen Problemen dieser Bereich besteht und welche IT-Tools darin verwendet werden.



Wenn Sie verstehen möchten, wie BI, Data Warehouses (DWH) und Budgetautomatisierungssysteme (Cognos, Anaplan, 1C: Holding Management, Bit.Finance) miteinander verbunden sind und wie sie sich von anderen Unternehmensinformationssystemen unterscheiden, sind Sie hier.



Wenn Sie ein technischer Architekt sind, der noch nie mit dem Themenbereich Unternehmensplanung gearbeitet hat, ist dieser Artikel auch für Sie.





Ich warne Sie sofort, dass ich versucht habe, den Artikel in der einfachsten Sprache zu schreiben, damit er für alle verständlich ist.

Warum habe ich beschlossen, es zu schreiben?

Heutzutage gibt es praktisch keine kurze systematische Beschreibung dieses Bereichs, die klare Antworten auf die Fragen geben würde:

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

Der architektonische Unterschied zwischen Buchhaltung und Planung besteht darin, dass Buchhaltungsdaten von unten nach oben fließen. Um eine Qualitätsberichterstattung zu erhalten, müssen Sie die Aufzeichnung so detaillierter Fakten wie möglich organisieren. Dann können alle zusammenfassenden Informationen (wichtig für Manager) durch einfache Aggregation erhalten werden.



Daher funktioniert in der Buchhaltung das Schema Dokument -> Tabelle (Register) -> Bericht optimal (das lange vor der Automatisierung in der mittelalterlichen Buchhaltung verwendet wurde).





Zahl: 1. Abrechnungsschema "Dokument -> Registrieren -> Bericht"





Die Pläne wurden zunächst erweitert. Daher ist es zweckmäßig, sie genau "von oben" einzugeben (dh in denselben Formen, in denen Berichte erstellt werden).



Wenn Unternehmen versuchen, eine Budgetierungsautomatisierung in Analogie zur herkömmlichen Buchhaltung aufzubauen (Abb. 3), stehen sie daher sofort vor drei Hauptproblemen.





Zahl: 3



Problem 1: Regeln verwalten . Es ist sehr unpraktisch und arbeitsaufwendig, die im Berichtscode geschriebenen Regeln für die Datentransformation (von den niedrigsten Buchhaltungsebenen bis zum Budgetierungsformat) zu verwalten.



Problem 2: Geschwindigkeit des "Sammelns von Fakten" . Pläne werden sehr schnell in Berichten angezeigt (da sie bereits in vergrößerter Form gespeichert sind), und die tatsächlichen Daten werden sehr langsam berechnet.



Problem 3: Planen Sie Anmeldeformulare... Die bequemste Form für die Eingabe von Plänen ist ein Plan-Fact-Bericht. Berichte in Informationssystemen erlauben jedoch normalerweise keine Dateneingabe.



Die ersten beiden Themen beziehen sich nicht nur auf die Budgetierung, sondern bilden im Allgemeinen die Grundlage für den gesamten Themenbereich Data Warehousing, Datenintegration und ETL.



Das dritte Problem ist ein spezifisches Planungsproblem. Dies ist in der Tat eines der wichtigsten Probleme von ERP-Systemen als Echtzeit-Tools (nicht nur für die "posthume" Abrechnung aufgetretener Ereignisse, sondern auch für die Planung und operative Kontrolle des Geschäfts).

Problem 1: Verwalten von Transformationsregeln

In Abb. 1-3 sind alle Regeln für die Transformation tatsächlicher Daten (von der niedrigsten Buchhaltungsebene zur oberen Berichtsebene) direkt im Berichtscode geschrieben.



Das ist schlecht:

• Regeln können nicht verwaltet werden, ohne den Code zu ändern.
• Sie können nur in diesem Bericht verwendet werden.
  was bedeutet:

  – , , ,
  
  – - ,
  
  

Komplexität von Transformationsregeln

Es ist sehr wichtig zu berücksichtigen, dass die Transformationsregeln tatsächlich sehr komplex sein können. Transformation ist nicht immer eine einfache Aggregation von Daten (von Tag zu Monat; von Abteilung zu Organisation; von Lager zu Region; von Produktlinie zu Artikel usw.). Dies zeigt sich insbesondere in der GUS, wo das Management Accounting häufig auf dem Rechnungswesen basiert. Dann können aus einer Vielzahl von Kombinationen verschiedener Buchhaltungsdetails unterschiedliche Werte für das Management Accounting bestimmt werden.





Sie können sich vorstellen, wie bedeutend ein Problem bei der Verwaltung eines solchen Codes für Programmierer ist. Wenn mehrere hundert solcher Artikel vorhanden sind, werden sie in einem Dutzend verschiedener Berichte verwendet, und die Regeln für deren Bestimmung im Management Accounting können alle drei bis vier Monate angepasst werden.

Lösung zu Problem 1: Mapping

Um dieses Problem zu lösen, kann die Zuordnung - Korrespondenz zwischen Feldern verschiedener Ebenen und / oder Arten der Buchhaltung und Berichterstellung - aus Berichten entfernt, als separates Objekt erstellt, separat konfiguriert und gespeichert und bei Bedarf auf diese verwiesen werden.





Zahl: 4



Dies hat zwei Vorteile gleichzeitig:

• Regeln sind einfacher zu verwalten. Sie können interaktiv gestaltet und ohne Code konfiguriert werden, was bedeutet, dass selbst normale Benutzer dies häufig tun können.
• Eine Regel kann in verschiedenen Berichten und / oder anderen Algorithmen verwendet werden

Dieser Ansatz hat keine wesentlichen Nachteile.



Es ist jedoch nicht einfach, ein Tool für die bequeme Zuordnung großer Verzeichnisse zu entwickeln.

Problem 2: Geschwindigkeit der Transformation der tatsächlichen Daten

Lösung zu Problem 2: Speichern transformierter Daten

Um die Berichtsdaten nicht "on the fly" zu berechnen, können sie bereits vergrößert und transformiert gespeichert werden.



Dazu müssen Sie zusätzlich zu den Quelltabellen (die im Unternehmen noch benötigt werden) Tabellen erstellen, um die aggregierten Istdaten zu speichern. Dies können separate Tabellen und eine allgemeine Tabelle sowohl für den "Plan" als auch für die aggregierte "Tatsache" sein.



Natürlich müssen diese Tabellen zuerst irgendwie ausgefüllt werden: Dazu führen wir das gleiche Transformationsverfahren durch, das zuvor beim Generieren des Berichts durchgeführt wurde, aber jetzt werden wir es einem separaten Hintergrundprozess zuweisen.





Zahl: fünf

DWH

Im Zusammenhang mit diesem Problem steht die Data Warehouse-Domäne (DWH).



Grob gesagt ist DWH ein Ort (eine Tabelle oder in der Praxis eine Reihe verwandter Tabellen) zum Speichern von zwischenzeitlich berechneten (aggregierten oder irgendwie transformierten) Daten.



Was sind die Profis:

• Datenlesegeschwindigkeit. Wenn Berichte bereits transformierte Daten aus der Tabelle "lesen", tun sie dies sehr schnell.
• Überprüfbarkeit. Wenn Daten im Warehouse vorgespeichert sind, ist es einfacher, sie zu überprüfen.

Minuspunkte:

• Richtigkeit. Tatsächlich ist dieses Minus eher theoretisch (maximale Genauigkeit ist genau dann gewährleistet, wenn wir Daten aus der primären Informationsquelle entnehmen).
  Auf Übung

  , ; , . , , , .
• Speicher laden. Dementsprechend verschwenden wir zusätzlichen Speicherplatz auf Festplatten, um aggregierte Daten zu speichern. Auch in der Tat eher ein theoretischer Nachteil.
• Entschlüsselung. Wenn wir Berichte mit aggregierten Tabellen verbinden (in denen die Daten nicht gemäß den Quelldokumenten detailliert sind), treten Probleme mit den Möglichkeiten ihrer Entschlüsselung auf (Drilldown).

ETL-Prozesse

ETL kann als jeder Prozess bezeichnet werden, bei dem Daten von irgendwoher entnommen, geändert und dann irgendwo geladen werden. Dies ist eine gebräuchliche Abkürzung für Extrahieren, Transformieren, Laden.



Normalerweise wird dieser Begriff jedoch genau dann verwendet, wenn Daten nach der Transformation irgendwo zur Speicherung geschrieben werden.



Dieser Ansatz hat Vorteile:

• Verteilung der Last auf das System. Der Transformationsprozess erstreckt sich über die Zeit. Wir können die aggregierte Tabelle schrittweise (wenn wir Daten in den ursprünglichen Buchhaltungssystemen ändern / hinzufügen) oder nach einem Zeitplan füllen. Beispielsweise können komplexe Berechnungen über Nacht oder andere nicht geschäftliche Zeiten verschoben werden, wenn der Server "frei" ist. Auf diese Weise können Sie die Auslastung des Systems verwalten.
• Einmalige Transformation. Sobald wir die zusammenfassenden Informationen in eine aggregierte Tabelle geschrieben haben, können wir über viele verschiedene Berichte darauf zugreifen. Daher müssen dieselben Transformationen nicht viele Male durchgeführt werden.

Es gibt nur ein Minus:

• Die Komplexität der Steuerung der Integrität der geladenen Daten. Erstellen Sie einen ETL-Prozess, der keine Daten verliert, der ausreichend transparent und kontrollierbar ist - dies ist möglich, erfordert jedoch ein hochqualifiziertes Team, die Einbeziehung der Benutzer und spürbare Arbeitskosten.

Problem 3: Budget-Eingabeformular

Tatsache ist, dass Berichte in Softwareprodukten in der klassischen Form ein Mittel zur Datenausgabe sind. Sie können jedoch keine Daten eingeben.





Für die Budgetierung ist das klassische Schema "Eingabeformular" (Dokument) -> interne Tabellen -> Ausgabeformular (Bericht) "jedoch nicht geeignet.



Zum Beispiel haben wir einmal einen monatlichen Beschaffungsbericht erstellt (wie in Abb. 2), aber jetzt beginnen wir mit der Planung, und der CFO möchte das Beschaffungsbudget in derselben Form eingeben.



Was bleibt zu tun? Sie können ein Planeintragsformular erstellen, das diesem Bericht sehr, sehr ähnlich sieht (siehe Abbildung 3).

Lösung zu Problem 3: Interaktive E / A-Formulare

Die Lösung ist auch klar: statt der üblichen „Dokumente“ und Berichte“, sollten Sie ein Objekt erstellen , das gleichzeitig wird und lesen und Daten eingeben.



Es ist sogar noch besser, wenn es in diesem Objekt auch möglich ist, Berechnungen zwischen den eingegebenen und / oder gelesenen Daten durchzuführen, dh so zu arbeiten, wie Excel es Ihnen ermöglicht.



In diesem Fall können Pläne nach der Eingabe demselben Data Warehouse „hinzugefügt“ werden, in dem sich die tatsächlichen Daten befinden (siehe Abbildung).





Zahl: 6



Solche Formulare sind jedoch viel schwieriger zu implementieren als normale Berichte oder Dokumente in Buchhaltungssystemen.



Der Grad der Interaktivität kann unterschiedlich sein: Es ist einfacher, vorkonfigurierte Formulare zu implementieren, schwieriger - dynamisch (wobei die Anzahl der Spalten / Zeilen nicht im Voraus bekannt ist, ihre Typen jedoch vordefiniert sind). Es ist noch schwieriger, dem Benutzer das „Drehen“ von Daten, das Erstellen neuer Formulare und das Festlegen beliebiger Berechnungsformeln zu ermöglichen, wodurch die Struktur von Berichten geändert wird.

Lösung zu Problem 4: Würfel

Es gibt ein anderes Tool, das ein oben nicht angegebenes Problem löst.

Tatsache ist, dass bei großen Datenmengen, hoher Interaktivität und komplexen Formeln gewöhnliche relationale SQL-Tabellen, in denen üblicherweise Daten aus ERP-Systemen gespeichert werden, nicht die maximale Geschwindigkeit der Datenverarbeitung in Echtzeit bieten.



Um dieses Problem zu lösen, können Sie die Datenspeicherung nicht in Form von Tabellen, sondern sofort in Form von Cubes verwenden.





Wenn für die Budgetierung von Aufgaben die sofortige Organisation des Speichers in Form eines Cubes eine gute und geeignete Option ist, ist ein mehrdimensionales Speichermodell für andere Geschäftsaufgaben möglicherweise nicht geeignet, und der Speicher wird mithilfe einer anderen Technologie organisiert. In diesem Fall kann der Cube als weiterer Link in der Architektur zum "Hauptspeicher" hinzugefügt werden.

Arten von Softwareprodukten im Haushalt

Betrachten wir nun die Arten von Informationstechnologien, die Probleme lösen, die für die Budgetierungsautomatisierung wichtig sind:

• Anfangsdatensysteme (Buchhaltungssysteme, ERP-Systeme)
• ETL-Tools
• Data Warehouses (reguläre und OLAP-Cubes)
• BI-Systeme
• EPM-Systeme
• Excel natürlich

Jeder Systemtyp hat eine theoretisch grundlegende Funktion (siehe Tabelle):







In Wirklichkeit sind die Grenzen jedoch leicht verschwommen, und häufig wissen Produkte, wie man verwandte Dinge tut. Überlappende Funktionen sehen ungefähr so ​​aus:







Wichtig: Es ist zu beachten, dass die Überlappung von Funktionen normalerweise nicht 100% beträgt.



Das heißt, normalerweise führt ein Werkzeug, das zusätzliche Funktionen bietet, diese nicht so gut aus wie ein separates Spezialwerkzeug!

Karte der Softwaretypen in der Budgetierung

Im Allgemeinen kann die visuelle Abdeckung verschiedener Aufgaben für die Budgetierungsautomatisierung durch verschiedene Arten von Informationssystemen ungefähr so ​​dargestellt werden:





Abb. 7



Schauen wir uns nun an, welche Art von Budgetierungsarchitektur einige beliebte Softwareprodukte bieten.

BUDGET IN ERP-SYSTEMEN

Das ERP-Konzept hat sich im Laufe der Zeit geändert, und neue Funktionen werden in ERP-Systeme integriert.



Meiner Meinung nach umfasst die "klassische" ERP-Funktionalität ein Buchhaltungssystem; Berichtsdesigner; Funktionen der operativen Kontrolle von Plänen und natürlich die grundlegenden Fähigkeiten ihrer Eingabe.



Ausgeschlossen sind: Fähigkeit, Daten aus mehreren Quellen zu sammeln; Erstellen von Cubes und interaktiver Analyse



Es besteht Grund zu der Annahme, dass das Konzept von EPM (wie BI) als etwas jenseits von ERP konzipiert wurde. Jetzt verschwimmen die Grenzen, und EPM-Funktionen oder sogar ganze Produkte können als Module in ERP-Systeme aufgenommen werden.

1C: SCP

Das UPP implementiert das folgende Schema, jedoch innerhalb einer Basis.





Zahl: 8. Architektur der Budgetierung in 1C: UPP



Vorteile der Budgetierung in UPP:

• Der SCP ist sehr transparent und leicht zu ändern. Es ist einfach, darin enthaltene Daten zu überprüfen, und es ist recht kostengünstig, neue Funktionen zu entwickeln.

Mapping - im SCP auf durchschnittlichem Niveau. Dies ist kein Plus oder Minus. Einstellen der durchschnittlichen Arbeitsintensität.



Nachteile der Budgetierung in SCP:

• Fehlen interaktiver Formen der Eingabe / Ausgabe. Die Erstellung von Daten erfolgt über Dokumente (Eingabe von Plänen; Erhalt aggregierter tatsächlicher Daten; Durchführung von Berechnungen), bei denen keine Interaktivität vorhanden ist und nicht möglich ist und die Fähigkeit besteht, das Gesamtbild zu sehen.
• Fehlende ETL-Schnittstelle. Es gibt eine Zuordnung, aber die tatsächlichen Daten werden direkt aus dem Dokumentformular geladen, was unpraktisch ist.
• Alte Plattform. Sie können die 1C Managed Forms-Technologie nicht verwenden, die dem Benutzer moderne Möglichkeiten zum universellen Filtern / Sortieren von Listen und Berichten bietet. Dies beeinträchtigt die Analysefähigkeiten des Benutzers.

Im SCP wird die Automatisierung der Budgetierung im Allgemeinen am klarsten nach dem Prinzip der normalen Rechnungslegung implementiert: Der Benutzer arbeitet nicht nach dem allgemeinen Bild, sondern nach den Primärdokumenten (Eingabe des Plans; Laden der Fakten; Schätzungen), und das allgemeine Bild ist nur in Berichten zu sehen, in denen nichts eingegeben werden kann.

1C: ERP

Soweit ich mich erinnere, lieferte ERP zunächst nur ein "Online" -Reporting-Modell. Und heute ist in vielen Unternehmen das Hauptszenario der Arbeit genau dies. Trotzdem erlaubt das Programm jetzt die Zwischenspeicherung der berechneten Werte.





Zahl: 9. Architektur der Budgetierung in 1C: ERP



Vorteile der Budgetierung in 1C: ERP:

• Ausreichend funktionale Formen der Eingabe / Ausgabe

Nachteile der Budgetierung in 1C: ERP:

• Die Steifigkeit des Modells. Wie in den meisten ERP-Systemen toleriert das Budgetmodell im Prinzip keine häufigen Änderungen und ist bei der Voreinstellung eher wählerisch
• Schwache Zuordnung. Aus irgendeinem Grund ist die Zuordnungsfunktionalität schlechter als im UPP
• Produkthärte. Im Gegensatz zu SCP ist es äußerst schwierig und teuer, den Rahmen der Methodik zu überarbeiten. Sie müssen das vorhandene gut studieren und die Budgetierung auf 1C: ERP aufbauen, wenn es wirklich zum Unternehmen passt
• Performance. Interaktive Formulare sind recht funktional, aber das technische Gerät macht sie bei großen Datenmengen extrem langsam

Auch in 1C: ERP gibt es keine ernsthaften Funktionen hinsichtlich der Einrichtung des Organisationsbudgetierungsprozesses (Workflow) und der Mehrbenutzerarbeit. Beispielsweise sind die Genehmigungsprozesse in einem separaten Produkt 1C: Workflow enthalten, das normalerweise über ERP implementiert wird.

1C: CA.

Integrated Automation ist eine abgespeckte Version von 1C: ERP. Die Entwicklung erfolgt also auf demselben Weg, und es gibt keine eigene Budgetierungsmethode.

MS Axapta / MS Dynamics AX

Es bietet nur ein "Online" -Modell zum Anzeigen der tatsächlichen Daten von Budgets - sie werden direkt aus ihren eigenen Buchhaltungsmodulen gelesen, während die Möglichkeiten einer ernsthaften Transformation nicht bereitgestellt werden.





Zahl: 10. Architektur der Budgetierung in MS Dynamics



Sowohl das Plus als auch das Minus des Systems ist das "Schärfen" seiner eigenen Buchhaltungsmodule von Dynamics und ihrer vorgefertigten Struktur.



Vorteile:

• Integration in Buchhaltungsmodule. Das Einrichten der tatsächlichen Daten von verschiedenen Modulen des ERP-Systems ist recht einfach.
• Integration. Es gibt viele Möglichkeiten, vorgefertigte Pläne von externen Systemen zu laden. Somit folgt Microsoft eindeutig der Logik der Trennung von EPM und ERP, wodurch EPM-Systeme sehr gut an Dynamics "hängen"
• Arbeitsablauf. Ausreichend funktionales und transparent anpassbares Organisationsmodell des Budgetprozesses

Minuspunkte:

• ETL. Im Allgemeinen bietet das Produkt keine aussagekräftigen Datentransformationsfunktionen
• Produkthärte. Hier wird eine vorgefertigte, aber eher begrenzte Methodik festgelegt. Und (wie im Fall von 1C: ERP) ist es nicht nur schwierig, es zu recyceln, sondern auch praktisch sinnlos.

SAP S4 HANA

Das Hauptprodukt von SAP, das das ERP-System SAP R / 3 ersetzt hat.



Für die Budgetierung wird jetzt ein separates EPM-Produkt verwendet, das in der Desktop-Version (SAP BPC) noch als separates EPM-System "über" ERP betrachtet werden kann, in der Cloud-Version (SAP Analytics Cloud) jedoch bereits endgültig in das ERP-System (in SAP S4) integriert ist HANA Cloud). Weitere Details zu SAP BPC finden Sie weiter unten.



Es ist wichtig, noch etwas über S / 4 HANA selbst zu sagen: SAP überträgt die gesamte Arbeit eines ERP-Systems von einer relationalen Datenbank in eine kombinierte (eine Mischung aus relationalen, säulenförmigen und mehrdimensionalen Datenbanken). Eine solche kombinierte Datenbank ist die proprietäre SAP-HANA-Technologie (nicht zu verwechseln mit S / 4 HANA), die je nach Benutzeraktionen entweder als Transaktionssystem (Buchhaltungssystem) oder als Analysesystem (Cube) fungiert.



Daher bewegt sich SAP zu einer Architektur, die das Gegenteil von dem ist, was heute in der "normalen" Praxis bekannt ist. Darin wird die Analysedatenbank nicht "über" dem Speicher (SAP BW) erstellt, sondern "unter" dem ERP-System implementiert. In diesem Fall überträgt das Data Warehouse (SAP BW), wenn der Benutzer mit seinen Daten aus dem EPM-System arbeitet, die Daten für Berechnungen zurück in diese ursprüngliche kombinierte Datenbank.



Tatsächlich erzielt SAP den gleichen Effekt, für den IN-Memory OLAP umgekehrt konzipiert wurde: durch Maximierung der Berechnungen aus dem RAM.

Oracle Cloud ERP

Oracle hat auch den Weg eingeschlagen, ein EPM-System in ein ERP einzubetten.



Das Unternehmen stellt seine Produkte aktiv auf die Cloud-Version um (möglicherweise sogar aktiver als SAP). Daher ist für seine Haupt EPM - Lösung, Oracle Hyperion, das Unternehmen fördert eine Alternative in Form von Cloud-basierten Oracle EPM Wolke, die (die wir auch über unten sprechen) enthalten in der Cloud-basierten Oracle Cloud - ERP.

BI-SYSTEME

BI-Systeme (Business Intellegence) in ihrer "reinen" Form sind ein Mittel zur Datenausgabe. Das heißt, BI sind Berichts- und Dashboard-Designer, die normalerweise auch grundlegende Funktionen zum Umstrukturieren und Analysieren von Daten enthalten (z. B. können Sie damit Tabellen verknüpfen, gemittelte Trends finden usw.).



Beliebte BI-Systeme:

• Power BI
• Tableau
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

In der Regel stellt BI eine Verbindung zu Datenspeichern (sowohl relational als auch mehrdimensional) oder zu unformatierten SQL-Tabellen her. Sie können also auf ausreichend detaillierte Quelldaten verweisen (um diese bereits im BI zu aggregieren). Bei komplexen bedingten Transformationen (mit "Wenn" -Bedingungen) geht es jedoch nicht um "klassische" BI-Funktionalität. Wenn Sie vor der Aufgabe stehen, ein Dashboard-Visualisierungssystem zu erstellen, ist es besser, vor der Implementierung von BI eine Transformation zu erstellen.

EPM-SYSTEME

EPM steht für Enterprise Performance Management. Außerdem werden die Begriffe Corporate Performance Management (CPM) und seltener Business Performance Management (BPM) verwendet.



Ein weit gefasster Begriff, der verwandte Funktionen implizieren kann, aber meistens können solche Systeme als Konstruktoren interaktiver "Plan-Fakt" -Formen betrachtet werden. Das Konzept von EPM ist noch nicht allgemein bekannt, aber Lösungen wie IBM Planning Analytics, Oracle Hyperion und Anaplan, die manchmal im Kontext von Business Intellegence betrachtet werden, werden korrekter als EPM-Systeme bezeichnet.



Manchmal werden EPM-Systeme für breitere Zwecke erstellt (z. B. SAP EPM oder 1C: Holding Management), aber wir werden sie genau in Bezug auf Systeme zur Budgetierungsautomatisierung betrachten. Daher werden wir SAP Business Planning & Consolidation (SAP BPC) - ein EPM-System - nennen, obwohl SAP dies selbst das größere SAP EPM-Produkt nennt, das SAP BPC enthält.



Wie bereits erwähnt, erlaubt BI keine Dateneingabe. EPMs enthalten normalerweise Standard-BI-Funktionen und bieten darüber hinaus die Möglichkeit, Daten einzugeben und aufzuzeichnen.



Bemerkenswerte EPM-Systeme:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Bit.Finance
• 1C: Holding Management

Beginnen wir mit den Kleinen.

Bit.Finance

Bit. Finance basiert auf der UPP-Budgetierungsmethode, wird jedoch im Gegensatz dazu einerseits unterstützt und entwickelt und zweitens als EPM-System zusätzlich zu ERP implementiert (so können Sie Fakten aus verschiedenen externen Quellen konsolidieren).





Zahl: 11. Die Architektur der Budgetierung in Bit.Finance



Vorteile der Budgetierungsautomatisierung in Bit.Finance:

• Konstruktoren von Formularen zum Eingeben oder Lesen von Daten. Im Gegensatz zum UPP sind die Formen der Buchhaltungsbelege hier nicht festgelegt, sondern können angepasst werden, um sie in eine recht bequeme Form zu bringen.
• Schnittstelle zur Verwaltung von Kostenvoranschlägen. Sie können Budgetmodelle hier zentral neu berechnen, anstatt manuell einen Kalkulationsbeleg zu erstellen.

Mapping ist weiter entwickelt als in SCP.



Das Abrufen tatsächlicher Daten funktioniert auf drei Arten:

• Durch ein Beweiserfassungsdokument (wie in SCP),
• Parallele Abrechnung. Bei dieser Option erstellen Buchhaltungsbelege, wie sie gehalten werden, gleichzeitige Einträge sowohl in Buchhaltungsregistern als auch in Budgetierungsregistern.
• Broadcast-Methode. Bei dieser Option werden die Buchhaltungsbucheinträge in das Budgetierungsbuch übersetzt.

Nachteile der Budgetierungsautomatisierung in Bit.Finance:

• Arbeiten Sie die Formen der Dokumente durch. Trotz der Tatsache, dass die Formen von Dokumenten flexibel geworden sind (siehe das erste Plus) und in dieser Hinsicht im Vergleich zu SCP im Allgemeinen große Fortschritte erzielt wurden, hat sich das Produkt noch nicht so weit vom dokumentenorientierten Arbeitsmodell entfernt, wie wir es möchten. Was, wie gesagt, für die Budgetierung unpraktisch ist.
• Fehlen interaktiver Formen der Eingabe / Ausgabe. Im Gegensatz zu 1C: ERP gibt es hier keine.

Anaplan

Ein Flaggschiffprodukt, das in letzter Zeit auf dem Weltmarkt große Popularität erlangt hat. Wird nur in der Cloud-Version angeboten.



Im Gegensatz zu anderen gängigen Lösungen (einschließlich Hyperion und Planning Analytics) weist es eine leicht spezifische Spezialisierung auf: Es eignet sich am besten als Kalkulationsservice, mit dem Sie volumetrische Budgetmodelle mit einer großen Anzahl von Abhängigkeiten schnell automatisch neu berechnen können.





Zahl: 12. Anaplan-Budgetierungsarchitektur (beliebtes Automatisierungsszenario)



Vorteile:

• Kalkulation. Das Produkt konzentriert sich auf Berechnungen und speichert alle Daten in In-Memory OLAP, sodass alle Modelle online neu berechnet werden können
• Teamarbeit (im Rahmen der Erstellung von Planungsdaten)
• UX- und Freiformmodellierung.
• ETL. Eigenes und recht praktisches ETL-Tool
• Erfordert nur minimalen IT-Support. Besonders wenn es um Modellierung geht
• Kosten. Ein bisschen teuer für den russischen Markt, aber im Vergleich zu internationalen Marktführern (dem gleichen Oracle Hyperion) sind die Gesamtbetriebskosten niedriger
• Implementierungsgeschwindigkeit. Im Vergleich zu Hyperion und Planning Analytics ist das Produkt einfacher zu verwenden und einfacher zu implementieren

Minuspunkte:

• Formatierung
• Teamwork (in Bezug auf die Arbeit mit Ereignissen: Benachrichtigungen, Mailings usw.)
• Benutzerdefinierte Formelsyntax. Im Allgemeinen ist die Verwendung Ihres eigenen Codes aus Sicht der Endbenutzer immer ein Nachteil.
• Hierarchien. Früher gab es Probleme bei der Verwendung einer anderen Verzeichnishierarchie für verschiedene Budgetmodelle. Das Problem ist für viele Unternehmen nicht wichtig, für einige jedoch kritisch. Vielleicht (ich hoffe es) hat Anaplan dieses Problem bereits gelöst.
• Ad-hoc . , : Anaplan , .

Sowohl das Plus als auch das Minus von Anaplan sind die relativ klare Spezialisierung und die Tatsache, dass es nicht in das IT-Ökosystem des Unternehmens eingreift. Das Plus ist, dass das Produkt seinen funktionalen Zweck klar definiert hat und die Richtungen seiner Entwicklung ziemlich vorhersehbar sind. Es ist ein Service zur Durchführung von Was-wäre-wenn-Analysen, zur Berechnung und Genehmigung von Plänen (Budgets), auf dessen Grundlage Sie die Architektur des Kunden planen müssen. Der Nachteil ist, dass das Produkt kein vollwertiges Unternehmens-Data-Warehouse ersetzen kann, nicht alle BI-Funktionen ersetzen kann, eine komplexe Unternehmens-ETL-Infrastruktur und das gesamte Unternehmens-Computersystem nicht darauf aufbauen. All dies wäre kein Problem, wenn das Produkt nicht nur in der Cloud-Version angeboten würde.



Im Gegensatz zu Oracle und SAP (beide behaupten, Ökosystem zu sein) betont Anaplan nicht die Fähigkeit, Daten und Tools einfach zwischen der Cloud und den Servern des Unternehmens zu "verschieben". In seinem Fall treten daher die Nachteile des Cloud-Produkts (unter Berücksichtigung der Tarifierung in Abhängigkeit von der auf dem Server verwendeten Datenmenge) am deutlichsten auf.



Da es keinen universellen Unternehmensspeicher ersetzt, kann es in bestimmten Fällen als Berechnungsdienst verwendet werden, der Plandaten zum firmeneigenen DWH „hinzufügt“, von wo aus die Daten in ein separates BI-System übertragen werden, um schnelle Berichte und Dashboards zu erstellen.





Zahl: 13. Anaplan-Budgetierungsarchitektur (alternatives Automatisierungsszenario)



Im Allgemeinen ist die Verwendung von EPM- und BI-Systemen eine normale Praxis.

Oracle Hyperion

Es gibt mindestens zwei Versionen: Oracle Hyperion Planning und Oracle Hyperion Financial Management.

Wird jetzt aktiv durch das neue Oracle EPM Cloud-Produkt ersetzt.



Aufgrund des Ökosystemismus können Architekturen eine Vielzahl von Typen annehmen, aber die typische sieht ungefähr so ​​aus.





Zahl: 14. Budgetierungsarchitektur in Hyperion (mögliche Option)



In der Abbildung habe ich ein BI-System als Beispiel angegeben, da die Oracle Essbase-Analysedatenbank eine hervorragende Basis für die Analyse von Big Data in BI-Tools darstellt.



Oracle Data Integrator wird als ETL-Lösung angeboten, die als universeller Datenintegrationsmechanismus im Oracle-Ökosystem fungiert.



Vorteile der Budgetierungsautomatisierung in Oracle Hyperion:

• Ökosystem. Im Fall von Oracle werde ich dies als Pluspunkt betrachten, da Oracle einer der größten Datenbankanbieter ist und die Integration für Unternehmen, die an Oracle DBMS arbeiten (und es gibt viele solcher Unternehmen), wirklich Vorteile bietet. Insbesondere ist es bequemer, die Funktionalität zwischen der Cloud und dem Server zu verteilen. Darüber hinaus sprechen Kollegen über ziemlich schwerwiegende Vorteile in Bezug auf die Sicherheit in der Oracle-Architektur (ich bin kein Experte in diesem Bereich, falls es hier welche gibt, korrigieren Sie diese bitte).
• Ad-hoc ("Berichterstattung auf Abruf").

Nachteile der Budgetierungsautomatisierung in Oracle Hyperion:

• Ökosystem. Ich werde auch als Minus anmerken, da Hyperion nach den verfügbaren Informationen hauptsächlich von Unternehmen ausgewählt wird, die am Oracle-Technologie-Stack arbeiten, und aufgrund seiner langfristigen Verwendung in einer Nicht-Oracle-Umgebung ein geringerer Effekt möglich ist.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

Hauptsächlich für große Unternehmen gedacht, nicht sehr einfach bereitzustellen und zu verwalten, aber ein sehr funktionales EPM-System. Derzeit basiert IBM Planning Analytics auf TM1-Technologien (die das Herzstück von Cognos bilden).



Für ETL-Prozesse empfiehlt IBM die Verwendung eines separaten Produkts, IBM DataStage (zuvor von Cognos DataManager verwendet), Turbo Integrator, Cognos Integration Server oder eines externen ETL-Tools.



Die typische Architektur ist Hyperion sehr ähnlich.





Zahl: 15. Budgetierungsarchitektur in Planning Analytics (optional)



Stärken von IBM Planning Analytics:

• Prognose.
• Arbeiten mit Ereignissen.
• Flexibilität. Das Produkt kann in Bezug auf die Vorkonfiguration nicht als anspruchslos bezeichnet werden, es versucht jedoch, sich an sich ändernde Modelle anzupassen.
• Kein Ökosystem. Das Überraschende an der Zusammenarbeit mit IBM ist, dass eine große Menge von Lehrmaterialien, die vom Unternehmen erstellt wurden, darauf abzielt, die Best Practices für die Interaktion von IBM Produkten mit anderen Lösungen (einschließlich Oracle und SAP) und in einer Vielzahl von Fragen zu beschreiben. Meiner subjektiven Meinung nach ist es gut, dass das Unternehmen langfristig den Trend beibehält, die Integration in Systeme von Drittanbietern zu entwickeln (was die Unterstützung einer Vielzahl von Architekturen ermöglicht, die sich in Unternehmen entwickelt haben) und diese nicht zu reduzieren.
• Produkt Support.

Minuspunkte

• Komplexität. Wie bei Hyperion: Erfordert umfangreiche Benutzerschulungen, nicht die leichteste Infrastruktur.

SAP BPC

Im Allgemeinen sind die Besonderheiten von SAP das Ökosystem, die Komplexität der Architektur und die Infrastruktur der Lösungen.



Wie bereits erwähnt, hat SAP verschiedene Architekturoptionen zu unterschiedlichen Zeiten unterstützt und unterstützt. Nach den neuesten Informationen sieht die heute vom Anbieter empfohlene Flaggschiff-Version der Architektur folgendermaßen aus:





Abb. 15. Budgetierungsarchitektur in SAP Business Planning & Consoldation (Beispiel)



Vorteile der Budgetierung basierend auf SAP BPC:

• Datenintegration. Obwohl komplex, ist es funktional und schnell, was für große Unternehmen unerlässlich ist.
• Visualisierung.
• Arbeitsablauf.

Nachteile der Budgetierung basierend auf SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• Preis. In Bezug auf die Gesamtbetriebskosten stellt sich heraus, dass es sich tatsächlich um eines der teuersten EPM-Systeme der Welt handelt, das von Änderungen in der Architektur beeinflusst wird.

ETL-WERKZEUGE

Bekannte ETL-Tools werden zum Erstellen von ETL-Prozessen verwendet, darunter viele Produkte derselben Anbieter, die BI / EPM-Lösungen herstellen:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• SAP Data Services
• Oracle Data Integrator
• Microsoft Azure Data Factory
• und viele andere DR.

Es ist geplant, den Artikel schrittweise zu aktualisieren, möglicherweise mit Informationen zu neuen Produkten und Prinzipien der Entwicklung von Softwareprodukten für die Budgetierung "von Grund auf neu".