Verzeichnis " Firmenstruktur» enthält eine Hierarchie funktionaler Abteilungen eines Unternehmens aller Art – Verwaltung, Produktion usw.

Das Verzeichnis kann eine beliebige Hierarchietiefe haben und es wird eine Hierarchie von Elementen verwendet. Dies bedeutet, dass eine Abrechnungseinheit und ein Planungsobjekt jede beliebige Abteilung in der Hierarchie sein können.

Hier ist ein Beispiel für eine Hierarchie von Abteilungen:

Aus diesem Beispiel wird deutlich, dass die Produktion in Abteilungen (Abschnitte, Sektoren, Gruppen, Abteilungen) mit beliebiger Verschachtelungsebene strukturiert werden kann.

Aus Sicht des Produktionsmanagement-Subsystems wird die Abteilung als Ausführender der Phasen des Produktionsplans interpretiert; dementsprechend wird in den Ressourcenspezifikationen für jede Phase die Abteilung bestimmt, die die Phase ausführt.

Lassen Sie uns die Details der Produktionseinheit auflisten, deren Werte im Subsystem „Produktionsmanagement“ ermittelt werden müssen.

Zeitplan. Ausgewählt aus dem Verzeichnis „Arbeitspläne“.

Ein Element dieses Verzeichnisses definiert den Arbeitsplan – die Start- und Endzeiten der Arbeit separat für jeden Wochentag und separat für alle Vorfeiertage. Für jeden Wochentag können Sie die Start- und Endzeiten der Arbeit gemäß Zeitplan separat festlegen, und es kann pro Wochentag mehrere Arbeitszeiten geben, zum Beispiel von 8.00 bis 13.00 Uhr und von 14.00 bis 18.00 Uhr . Ein Arbeitsplan für eine Abteilung ist erforderlich, damit das Prodie Anzahl der in der Abteilung für jeden Kalendertag verfügbaren Arbeitsstunden ermitteln kann.

Materiallager. Ein Lager, in dem der Materialbedarf entsprechend dem Produktionsplan für die geplanten Phasen in der Abteilung generiert wird. Dieses Lager prüft die Verfügbarkeit von Materialien, um die Phase abzuschließen. Bei Bedarf können Sie für die Nomenklatur und Eigenschaften des Materials separate Materiallager einrichten, in denen deren Verfügbarkeit geprüft wird.

Planungsintervall. Legt fest, welches Intervall für die Abteilung bei der Berechnung des Produktionsplans pro Phase verwendet wird. Optionen: „Tag“, „Woche“, „Monat“.

Bei Bedarf ist die Option „ Stunde„Um dieses Intervall nutzen zu können, muss die entsprechende Funktionsoption aktiviert sein.

Kriterien für die Wahl eines Planungsintervalls für eine Abteilung sind die Einhaltung der Dauer typischer in der Abteilung durchgeführter Phasen und die Dauer des Intervalls. Wenn beispielsweise die meisten Etappen in einer Abteilung nicht länger als ein paar Tage dauern, ist es sinnvoll, das Intervall „Tag“ zu verwenden. Wenn die typische Dauer einer Etappe eine Woche deutlich überschreitet, ist es sinnvoll, das Intervall „Woche“ zu verwenden.

Eine Verlängerung des Intervalls über das notwendige Maß hinaus führt zu einer spürbaren Verlängerung der Produktionsdauer, d. h. den Produktionsplan im Laufe der Zeit zu „dehnen“.

Eine übermäßige Verkürzung der Intervalllänge führt zu zu vielen Zeitdetails im Produktionsplan, was die Arbeit des lokalen Disponenten erschweren kann.

Methode zur Verwaltung von Routenblättern. Diese Einstellung wird bei der Verwaltung von Routenplänen verwendet, die in der Abteilung ausgeführt werden.

Optionen:

„BBV/UBVV-Methodik“. Der ML-Ausführungsplan wird für wichtige RCs generiert; die ML-Ausführung wird durch den Durchgang des vorläufigen und letzten Puffers durch den ML überwacht.

"Einsatzplanung". Der Zeitplan wird für alle DCs und Routenblattvorgänge generiert. Darüber hinaus müssen Sie klären „Planungsmethode“- „Vorwärts“ oder „Rückwärts“.

Lagerhallen (Lagerflächen)

Aus Sicht der Produktionsplanung ist ein Lager ein Objekt des Produktionssystems, das den Bedarf der Produktionsabteilungen an Materialien und Halbzeugen deckt.

Bei der Terminberechnung wird ein Bedarfsplan in den Lagern für Materialien und Halbfabrikate erstellt (Artikel, Merkmale, Menge, Planungsintervall).

Das Lager, von dem aus die Produktionseinheit standardmäßig „mit Strom versorgt“ wird, wird durch die Einheitendetails bestimmt.

Aber nicht umgekehrt: Das Attribut „Abteilung“ im Verzeichnis „Lager“ hat keinen Einfluss auf die Planung (und dient der Buchhaltung).

Sie können eine detailliertere Definition des Versorgungslagers angeben – für Abteilung und Artikel, Merkmale der Quellkomponente.

Brigaden und Brigadezusammensetzung

Das Team ist der direkte Ausführende der Arbeit in der Phase (Betrieb) in der Werkstatt. Um die Leistung der Mitarbeiter gemäß dem Routenblatt zu berücksichtigen, erstellt der örtliche Disponent ein Dokument „Brigadebefehl“, in dem er das Team und die Art der Arbeit angibt, die das Team gemäß dem Routenblatt ausgeführt hat.

Das Team besteht aus Mitarbeitern. Die Zusammensetzung der Brigade wird durch das Dokument „ Bildung der Brigadezusammensetzung", und ist ab dem im Dokument angegebenen Datum gültig.

Ist eine Detaillierung der Aufträge auf einzelne Mitarbeiter erforderlich, werden im Verzeichnis „Brigaden“ Brigaden bestehend aus einem Mitarbeiter gebildet.

Arten von Arbeitsplätzen, Arbeitsplätze

Arbeitsplatztypen sollen die Produktionskapazität einer Abteilung beschreiben. Arbeitsplatztypen verfügen über einen verfügbaren Arbeitszeitvorrat in Planungsintervallen, der bei der Zuordnung von Produktionsstufen zu Intervallen bei der Berechnung des Produktionsplans ausgefüllt wird.

Eine Arbeitsplatzansicht besteht aus bestimmten Arbeitsplätzen, beispielsweise Ausrüstungsgegenständen. Ein Synonym für die Art der Arbeitsplätze ist „Gruppe austauschbarer Arbeitsplätze“.

Beispiele für Arbeitsplätze:

- Geräteeinheit

- Arbeitsplatz

- Gruppe von Arbeitnehmern (Team oder Berufsverband)

- Mitarbeiter

- Geräteeinheit

Um einen realisierbaren Produktionsplan zu berechnen, der dem maximalen Produktionsdurchsatz entspricht, ist es notwendig, für die Ressourcenspezifikationsstufen in jeder Abteilung ladbare Arten von Arbeitszentren zuzuweisen, die den Durchsatz der Stufe begrenzen können.

Die Einzelheiten zur Art der Arbeitsplätze lauten wie folgt:

Flag „Arbeit planen“. Wenn das Flag aktiviert ist, kann dieser RC-Typ in der Stufe als geladener RC-Typ ausgewählt werden. Die Flagge ist für RC-Typen der Division aktiviert, was sich als „Flaschenhals“ der Division herausstellen kann.

Maximale Verfügbarkeit (Stunde, Minute, Sekunde). Bestimmt die maximale Bearbeitungsdauer einer Charge einer Stufe im Intervall der Division, zu der der RC-Typ gehört. Für eine Charge einer Stufe kann keine Verarbeitungsdauer in einem Intervall zugewiesen werden, das größer als die maximale Verfügbarkeit ist.

In der aktuellen Version von UP2 haben sich die Einstellungen für RC-Typen unter Beibehaltung des beschriebenen Wesens bereits etwas geändert. Jetzt können Sie die Kontrollkästchen verwenden, um:

- Ob die Verfügbarkeit von RC-Zeit bei der Planung auf der obersten Ebene berücksichtigt werden soll. Und wenn ja, wird dieser DC herunterladbar sein oder nicht?

- Sollte der DC mithilfe von Route Sheets auf der unteren Ebene in das Produktionsmanagement eingebunden werden?

Das folgende Diagramm zeigt die Struktur und Beziehung der Verzeichnisse „Unternehmensstruktur“, „Arten von Arbeitszentren“, „Arbeitszentren“.

Eingabe der verfügbaren Arbeitsplatzzeit

Um den Bestand an verfügbarer Zeit von Arbeitsplätzen nach Intervallen zu erfassen, verwenden Sie das Dokument „Verfügbarkeit von Arbeitsplätzen“. Wählen Sie im Belegkopf die Abteilung, die Art des Arbeitsplatzes und den Belegzeitraum aus.

Der tabellarische Teil des Dokuments wird um Spalten erweitert – Unterteilungsintervalle (z. B. Tage) im Dokumentzeitraum.

In der Zeile des tabellarischen Abschnitts müssen Sie ein Arbeitsplatzzentrum auswählen, das zum Arbeitsplatztyp gehört, und nach Spaltenintervallen die Anzahl der Verfügbarkeitsstunden für jedes Intervall angeben.

Ressourcenspezifikationen

Ressourcenspezifikation als Netzwerkdiagramm

Es sind verschiedene Arten von Spezifikationen bekannt, beispielsweise Designspezifikationen, Betriebsablaufpläne von Routen, „Workouts“, als Routen für den Durchgang eines Teils durch Abteilungen.

Die gebräuchlichste Art, den Herstellungsprozess eines Produkts zu beschreiben, ist ein Netzwerkdiagramm.

Ressourcenspezifikation beschreibt den Netzwerkplan für die Herstellung eines Produkts.

Netzwerkknoten In dieser Beschreibung handelt es sich um miteinander verbundene Produktionsschritte, die von Abteilungen im Prozess der Herstellung eines Produkts oder Halbzeugs nacheinander oder parallel ausgeführt werden. In einer Abteilung müssen eine oder mehrere Phasen durchgeführt werden.

Bögen– Interdependenz zwischen Etappen, zeigen, nach Abschluss welcher Etappen die folgenden Etappen beginnen können.

Es ist praktisch, ein Netzwerkdiagramm zu verwenden, um jeden Produktionsprozess zu beschreiben – in der diskreten, kontinuierlichen Produktion, im Bauwesen, bei Designaktivitäten.

Im Allgemeinen kann ein Netzwerkdiagramm nicht nur Fakten zur Produktübertragung zwischen Abteilungen, sondern auch Fakten zur Übertragung von Arbeitsergebnissen enthalten.

Das Ergebnis der zwischen Workshops übertragenen Arbeit hat nicht unbedingt einen materiellen Ausdruck. Die Übertragung eines Ergebnisses von einer Abteilung an eine andere Abteilung, damit die andere Abteilung ihren Teil der Arbeit erledigen kann, bedeutet nicht unbedingt die Übertragung bestimmter Produkte. Das Produkt kann sich beispielsweise in einer Abteilung befinden oder bei Bedarf verschoben werden, während die Arbeit am Produkt von anderen Abteilungen durchgeführt werden kann.

Die Produktionsphasen können nicht nur die Herstellung von Produkten umfassen, sondern auch Produktionsvorbereitung, Geräteeinrichtung, Dokumentationsentwicklung, Schulung, Installation usw.

Im Extremfall kann eine Ressourcenspezifikation alle Phasen der Herstellung eines Produkts umfassen, entsprechend dem hierarchischen Baum der Produktstruktur. Im einfachsten Fall besteht eine Ressourcenspezifikation aus einem Produktionsschritt. Diese Ressourcenspezifikation wird als einstufig bezeichnet.

Ein Beispiel für eine Ressourcenspezifikation als Netzwerkdiagramm mit Knotenstufen ist im folgenden Diagramm dargestellt:

Struktur der Ressourcenspezifikation

Der Aufbau einer Ressourcenspezifikation als Konfigurationsobjekt ist in der folgenden Abbildung dargestellt:

Die Ressourcenspezifikation enthält:

Liste der Ausgaben,

Liste der Materialeinsätze,

Liste der Arbeitskosten (nach Art der Arbeit),

Liste der Etappen.

Für jeden Input, Output und Arbeitseinsatz in einer mehrstufigen Ressourcenspezifikation muss die Phase angegeben werden, in der der Input (Arbeitseinsatz) verbraucht bzw. der Output produziert wird.

An den Eingängen der Stufen werden die in der Spezifikation beschriebenen Ausgangskomponenten (Materialien, Dienstleistungen) angegeben, die von außen in den Produktionsprozess einfließen.

Diese. Hierbei handelt es sich um Komponenten, die für eine bestimmte Stufe keine Ergebnisse anderer Stufen derselben Spezifikation sind.

Für einen Materialeingang – ein Halbzeug – können Sie das Flag „ Produziert im Prozess» und wählen Sie entsprechend die Ressourcenspezifikation aus, nach der dieses Halbzeug hergestellt werden soll. Dadurch wird diese Ressourcenspezifikation ab dieser Eingabe „abwärts“ durch eine andere Ressourcenspezifikation „vervollständigt“. Somit ist es möglich, aus einzelnen Spezifikationen einen vollständigen Baum fertiger Produkte in Form einer Spezifikationskaskade zu erstellen.

Diese Spezifikationskaskade wird beim Generieren einer Spezifikation für eine bestimmte Produktionsauftragsposition verwendet. Die gesamte Kaskade zusammengehöriger Ressourcenstücklisten wird in die Auftragspositionsstückliste kopiert.

In den Requisiten“ Optimaler Transfer zwischen den Stufen» Sie können die Menge einer Produktcharge (Arbeitsergebnis) angeben, die zwischen den Phasen übertragen werden soll. Bei der Berechnung des Produktionsplans wird die Stufenmenge in Chargendaten aufgeteilt und jede Charge wird basierend auf der Verfügbarkeitszeit der geladenen DC-Typen separat geplant.

Die Standardarbeitsintensität in der Ressourcenspezifikation sowie in den technologischen Operationen von Streckenkarten ist im Abschnitt „ Arten von Arbeiten».

Art der Arbeit - Analyse, nach der die Arbeitspreise für Arbeitnehmer erfasst und die Leistung der Arbeitnehmer berücksichtigt wird. Die Bezeichnung der Art der Arbeit kann neben einer Beschreibung der Arbeit selbst auch die erforderliche Kategorie der Arbeitnehmer und deren Beruf enthalten. Für eine Arbeitsart wird deren Maßeinheit angegeben, zum Beispiel Stunden oder Stück. Produkte.

Für jede Art von Arbeit im periodischen Informationsregister " Preise» Sie können den aktuellen Preis pro Einheit der Art der Arbeit angeben.

Phasen der Ressourcenspezifikation

Eine Ressourcenspezifikation kann einstufig oder mehrstufig sein.

Handelt es sich um eine einstufige Spezifikation, werden die Details einer einzelnen Stufe direkt im Spezifikationsformular bearbeitet. Wenn die Spezifikation mehrstufig ist, enthält die Spezifikation eine Liste von Stufen. Um die Phasendetails zu bearbeiten, müssen Sie ein separates Phasenformular aus der Liste der Phasen öffnen.

Die Reihenfolge der Etappen wird durch die Etappendetails bestimmt: „Stufennummer“, „Nächste Etappennummer“. Basierend auf der Stufennummer und der Nummer der nächsten Stufe werden Verbindungen zwischen Stufen in Form eines Stufennetzdiagramms erstellt.

Bühnendetails bestimmen die wesentlichen Parameter der Bühnenplanung:

Unterteilung, in dem die Bühne aufgeführt wird. Für eine Stufe ist nur eine Abteilung definiert. Wenn die gleichen Schritte in verschiedenen Abteilungen durchgeführt werden können, ist es notwendig, unterschiedliche Ressourcenspezifikationen zu erstellen

Auf einmal produzierte Menge. R Losgröße oder Arbeitsvolumen, für das die Fertigstellungszeit der Phase standardisiert ist. Wenn beispielsweise eine Einheit im Attribut angegeben ist, wird die Ausführungszeit der Stufe auf eins normalisiert.

Flag „Planen Sie die Arbeit von DC-Typen“. Bestimmt die Methode zur Normalisierung der Dauer der Phase.

Das Flag ist aktiviert. In der Phase muss angegeben werden, welche Arbeitsplatztypen von der Phase geladen werden und wie lange die Verarbeitung der gleichzeitig produzierten Menge auf dem geladenen Arbeitsplatztyp dauert. Diese DC-Typen können sich bei der Erfüllung des Produktionsplans als „Engpässe“ erweisen, weshalb ihre Belastung im Zeitplan berechnet wird. Darüber hinaus ist die Angabe der vorläufigen (vor der Verarbeitung auf der geladenen RC-Ansicht) und endgültigen Pufferzeit erforderlich. Puffer belegen separate Intervalle im Produktionsplan. Erinnern wir uns daran, dass, wenn die Verarbeitungszeit vor oder nach dem geladenen RC-Typ viel kürzer ist als die Dauer des Intervalls, die Angabe von Pufferzeiten zu einer ungerechtfertigten Erfassung ganzer Intervalle durch Puffer und dementsprechend zu einer ungerechtfertigten Verlängerung der Dauer führen kann einer Phase im Produktionsplan.

Die Flagge ist ausgeschaltet. Die Stufe gibt die Zeit an, die für die Fertigstellung benötigt wird, und zwar für jede Chargenmenge. Es wird davon ausgegangen, dass die Etappe in dieser Zeit auf jeden Fall abgeschlossen wird, unabhängig von der Anzahl der Etappenteilnehmer. Das Flag kann in Phasen deaktiviert werden, deren Ausführung nicht mit der Verarbeitung geladener RC-Typen zusammenhängt („die sogenannten „Engpässe“). Dementsprechend wird davon ausgegangen, dass die Abteilung bei der Durchführung einer solchen Phase (relativ) an Abteilungen mit „Engpässen“) unbegrenzte Produktionsleistung.

Flagge « Kontinuierlich» Stufe legt fest, ob die Stufenausführung im Zeitplan in mehrere nicht benachbarte Intervalle unterteilt werden kann.

Wenn das Flag aktiviert ist, wird die Phase kontinuierlich ausgeführt und kann nur in benachbarten Intervallen im Zeitplan aufgeführt werden.

Wenn das Flag ausgeschaltet ist, kann die Ausführung der Stufe unterbrochen werden, d. h. Ein Teil der Zeitstufe kann im Diagramm in einem Intervall und ein Teil in einem anderen, nicht an das erste angrenzenden Intervall liegen.

Kontinuitätskriterium – mindestens ein Vorgang innerhalb einer Phase ist kontinuierlich und mit der Dauer des Intervalls vergleichbar. Zu diesen Vorgängen gehören beispielsweise Wärmebehandlung, Lackieren, Trocknen usw.

Der Unterschied zwischen der Planung „diskontinuierlicher“ und „kontinuierlicher“ Phasen wird in der folgenden Abbildung dargestellt:

Während wir an großen Automatisierungsprojekten arbeiteten und neue Informationssysteme erstellten, standen wir jedes Mal vor der Notwendigkeit, ein Subsystem zur Verwaltung von Verzeichnissen, Klassifikatoren, Registern und anderen ähnlichen Objekten zu implementieren, die die Referenzinformationen (RNI) des Kunden bilden. In den 15 Jahren unserer Arbeit bei LANIT mit Datenmanagementsystemen hat uns das Leben Kunden mit den unterschiedlichsten Anforderungen beschert. Und natürlich ergaben sich bei diesen Projekten unterschiedliche Situationen. Ich werde Ihnen einige lehrreiche Geschichten erzählen, die uns passiert sind. In dem Artikel finden Sie Beispiele, die für viele, die sich mit der Softwareentwicklung befassen, nützlich sein werden. Nun, für diejenigen, die direkt mit dem NSI zusammenarbeiten, wird es noch interessanter – das eigene Hemd liegt näher am Körper.

Besonderer Dank geht an die wunderbare Künstlerin Vasya Lozhkin für die Illustrationen.

Fall eins. So beladen Sie einen Wagen und einen kleinen Karren

Ziel des Projekts– Erstellen Sie eine einheitliche Datenbank der Kontrahenten für alle Abteilungen. Das Kontrahentenmanagement erfolgt auf Basis von Anfragen, denen Prioritäten von niedrig bis dringend zugeordnet werden. Ein Eilantrag muss von NSI-Experten innerhalb von 2 Stunden bearbeitet werden, unabhängig von der Zeitverschiebung zwischen den Abteilungen.

Lebende Geschichte
Das Projekt wurde mit allen Interessenten abgestimmt (hiervon hat uns die Geschäftsführung des Kunden überzeugt) und im vorgegebenen Zeitrahmen entsprechend den genehmigten Anforderungen entwickelt.

Die Präsentation des geschaffenen Kontrahentenmanagementsystems verlief reibungslos, bis eine prominente Frau – die Leiterin der sibirischen Niederlassung – aufstand und die Versammelten sehr energisch und mit russischen Redewendungen darauf aufmerksam machte, dass ein Eisenbahnwaggon zum Beladen zu ihr kam Bei fertigen Produkten würde sie nicht zwei Stunden warten, bis jemand in Moskau den Antrag prüft, um einen Käufer hinzuzufügen.

Sie wird nicht für die Ausfallzeit des Autos aufkommen, während der Antrag genehmigt wird, sondern wird die Daten des Käufers unverändert in das System eingeben und die Ware versenden, und die Moskauer Genossen können sich dann genauso um die Informationen über den Käufer kümmern wie sie wollen.

Diese Aussage wurde von mehreren anderen Leitern der Niederlassungen des Unternehmens unterstützt, wodurch die zentralisierte Methodik zur Führung eines einzigen Verzeichnisses der Gegenparteien auf der Grundlage von Anträgen fast vollständig zerstört wurde.

Dadurch wurde das Projekt so modifiziert, dass alle Filialen Zugriff auf die Kontrahentendatenbank hatten und direkt Änderungen daran vornehmen konnten, gleichzeitig aber eine automatische Suche nach ähnlichen Datensätzen durchgeführt wurde, die dem Filialmitarbeiter angezeigt wurden, und er traf eine Entscheidung über die Notwendigkeit einer Anpassung der Daten, die später von einer Expertengruppe überprüft wurden.

Fall zwei. Wir nutzen es, wie wir wollen

Ziel des Projekts– Aufbau eines konsolidierten Kundenstamms für den Einsatz in analytischen Anwendungen. Die Datenbank wurde aus allen Filialen zusammengetragen, die Daten verifiziert, ergänzt und doppelte Objekte eliminiert. Die Anzahl der Kunden in einer Filiale liegt zwischen tausend und mehreren Millionen. Gleichzeitig gibt es praktisch keine Überschneidungen bei den Kunden zwischen den Filialen.

Lebende Geschichte

Sobald eine konsolidierte Kundendatenbank erstellt wurde, musste diese regelmäßig mit den Filialdatenbanken verglichen werden, um Unterschiede zu identifizieren, diese dann zu verarbeiten und Änderungen in die konsolidierte Datenbank hochzuladen. Das Wachstum des Kundenstamms zwischen den Abstimmungen belief sich auf mehrere tausend Datensätze.

Um den Abgleich durchzuführen, wurde ein spezielles Modul erstellt, dessen Architektur darauf ausgelegt ist, schnell eine große Anzahl von Datensätzen zu vergleichen und eine relativ kleine XML-Datei mit Änderungen zum Herunterladen zu generieren. Das XML-Format wurde vom Kunden gewählt.

Nach der Implementierung des Systems erhielten wir eine Nachricht vom Kunden, dass das Abgleichsmodul extrem langsam arbeitet und eine riesige Datei zum Laden in die konsolidierte Datenbank generiert, die er auf keine Weise öffnen kann.

Was ist daraus geworden? Der Kunde führte das erstmalige Laden der Daten aus den Filialen in das konsolidierte Verzeichnis durch. Diese Arbeit empfanden die Experten als mühsam und zeitaufwändig und fütterten das Abgleichsmodul einfach mit den kompletten Daten der neuen Filiale, die noch nie in das konsolidierte Verzeichnis geladen worden waren.

Das Abgleichsmodul, das gemäß den technischen Spezifikationen Informationen über Unterschiede in der Anzahl von mehreren tausend Datensätzen generieren sollte, erhielt als Eingabe zwei Millionen Datensätze, die alle im konsolidierten Verzeichnis fehlten.

Infolgedessen generierte das Abgleichsmodul nach mehreren Stunden übermenschlicher Anstrengung dennoch eine Datei zum Herunterladen, die alle Filialdaten enthielt. Und ja, diese Datei war riesig.

Das Abgleichsmodul wurde vom Kunden nicht für den vorgesehenen Zweck verwendet, aber dem Kunden gefiel gerade die Tatsache, dass der Abgleich das anfängliche Laden von Daten ermöglicht, und er würde auf diese Weise weiterarbeiten, nur bat er darum, die Arbeit deutlich zu beschleunigen das Modul und machen Sie etwas mit der erstellten Datei, damit sie in einem Texteditor geöffnet werden kann.

Daher mussten wir Änderungen an der Architektur des Abgleichsmoduls vornehmen, um große Datenmengen zu verarbeiten und eine Ausgabedatei im CSV-Format zu generieren, da der Kunde auf ein so komfortables Tool auf keinen Fall verzichten wollte.

Fall drei. Kein Elefantenbaby, sondern ein Elefant, und der muss auch fliegen

Ziel des Projekts- Schaffung eines zentralen Systems zur Pflege von Verzeichnissen und Klassifikatoren mit Verteilung von Änderungen an interessierte Systeme und Datenbanken. Bereitstellung des Zugriffs externer Systeme auf Verzeichnisse über die Webdienste unseres Systems.

Typischerweise haben Kunden eine durchschnittliche Anzahl von Einträgen pro Verzeichnis von mehreren Hundert bis mehreren Tausend. Unser aktueller Rekordhalter ist ein Verzeichnis mit 11 Millionen Einträgen. Doch dieser Kunde hat uns überrascht. Sein Verzeichnis enthielt über 100 Millionen Einträge. Wir haben es mehr als einen Tag lang heruntergeladen, weil... Beim ersten Laden wurden zahlreiche Datenprüfungen durchgeführt. Dies wäre kein großes Problem gewesen, aber der Kunde verlangte, dass der Download des Verzeichnisses in wenigen Minuten erfolgen sollte.

Daher mussten wir die Funktionsweise des Systems mit diesem Nachschlagewerk stark ändern. Tatsächlich wird es außerhalb des Systems verwaltet und wir stellen nur eine Schnittstelle für seine Verwendung bereit. Wir entwickeln derzeit neue Möglichkeiten für unser System, mit sehr großen Verzeichnissen zu arbeiten. Wir hoffen, dass es dem Kunden gefällt.

Fall vier. Schwieriger Trick mit Dateien

Ziel des Projekts– Schaffung eines zentralen Systems zur Pflege von Verzeichnissen und Klassifikatoren mit Verteilung von Änderungen an interessierte Systeme und Datenbanken. Eine Besonderheit des Projekts sind die sehr komplexen Prozesse der Propagierung von Änderungen, die viele Systeme betreffen.

Da ich in Zukunft unsere eigene Lösung zur Verwaltung von Referenzdaten erwähnen muss, erlaube ich mir einen kleinen lyrischen Exkurs.

Lesen Sie mehr über das NORMA-System.

Die Aufgaben unserer Kunden sind weitgehend ähnlich und wir haben uns entschieden, die Softwareentwicklungskosten zu senken und die Projektzeit zu verkürzen, indem wir eine eigene universelle Plattform für die Pflege von Stammdaten und Stammdaten (Reference Data Management & Master Data Management) geschaffen haben. Das System existiert seit mehr als 10 Jahren und wir bei LANIT haben es in all den Jahren aktiv weiterentwickelt.

NORMA unterstützt eine zentrale und verteilte Referenzdatenverwaltung. Alle Daten und Metainformationen werden unter Berücksichtigung der Änderungshistorie gepflegt und das System ermöglicht Ihnen die Anzeige und Änderung der gesamten Referenzdaten für ein beliebiges Datum in der Vergangenheit oder Zukunft. Für Verzeichnisse können Prozesse zur Koordination und Genehmigung von Änderungen konfiguriert werden. Das System umfasst einen dedizierten Änderungsverteilungsserver, der es Ihnen ermöglicht, über verschiedene Schnittstellen mit externen Systemen zu interagieren und ziemlich komplexe Integrationsgeschäftsprozesse zu erstellen (eine Art Mini-BizTalk-Server). Wir verfügen über Datenexport-/Importpakete, die Verzeichnisdaten in Datenbanken und Dateien verschiedener Formate hochladen/laden können. Die Pflege von Konvertierungstabellen für externe Systeme wird unterstützt.

NORMA umfasst einen grafischen Abfrageersteller und Berichtsdesigner. Neben der Arbeit mit eigenen Verzeichnissen ermöglicht das System über seine Schnittstelle die Anzeige und Änderung von Verzeichnissen, die sich in externen Datenbanken befinden, sowie die Verwendung dieser Verzeichnisse im Abfrage-Builder und in Export-/Importpaketen.

Als Reaktion auf das Auftreten verschiedener Ereignisse im System, zum Beispiel Ereignisse von Verzeichnisänderungen, können in C# geschriebene Plug-in-Softwarekomponenten gestartet werden, die sowohl Daten prüfen als auch mit externen Systemen interagieren können und zwar die NORMA-System selbst. Nahezu alle Systemfunktionen sind über Webservices verfügbar.

Das System kann sowohl vertikal durch Erhöhen der Leistung des Anwendungsservers und der Datenbank als auch horizontal durch die Verwendung eines Anwendungsservers mit mehreren Knoten skaliert werden, bei dem jeder Knoten oder jede Gruppe von Knoten für die Ausführung einer separaten Funktion verantwortlich ist. Zur Speicherung von Referenzdaten kann das System Microsoft SQL Server, Oracle oder PostgreSQL verwenden.

Nach einiger Zeit kontaktierte uns einer der Spezialisten des Kunden mit der Beschwerde, dass seine Daten nicht in das System geladen würden. Als Bestätigung erhielten wir ein Datenimportpaket, eine Quelldatei mit den zu ladenden Datensätzen und eine Fehlermeldung, dass die zu ladenden Daten vom falschen Typ seien.

Beginnen wir damit, es herauszufinden. Wir verdrehen das Paket hin und her, probieren verschiedene Optionen zur Darstellung der Quelldaten aus, aber wir können den Fehler nicht wiederholen. Wir wenden uns mit Fragen an den Kunden: Vielleicht enthält das Importpaket verbundene Softwarekomponenten, vielleicht sind dem Verzeichnis zusätzliche Einschränkungen auferlegt, vielleicht stammen die Daten nicht aus diesem Prozess? Wir bekommen auf alles eine Antwort – so etwas gibt es nicht, alles sollte problemlos laden und vorher funktionieren.

Woran wir uns erinnern:Überprüfen Sie immer die Informationen, die Sie erhalten, auch wenn Ihnen gesagt wird, dass wir hier ein kleines Problem haben, und das schwöre ich bei meiner Mutter! Analysieren Sie das Problem im Kontext.

Fall fünf. Ich gewöhne mich an die Ungereimtheiten

Ziel des Projekts– Schaffung eines Systems zur Pflege von Referenzdaten in einer Verwaltungsgesellschaft mit vielen Niederlassungen, Fabriken und Designabteilungen.

Dieses Mal kamen wir nicht über ein paar Präsentationen hinaus. Den Technikern gefiel unser NORMA-System sehr. Sie deckte alle bestehenden Probleme ab. Dann war es an der Zeit, dem Management das System zu zeigen, und hier geschah der Mist des Jahrzehnts. Der hochrangige Manager schaute zu, hörte zu und sagte: „Wir arbeiten hier alle an Apple-Produkten, sie haben einen bestimmten Stil, und Ihr System passt nicht in diesen Stil.“ Wir werden es nicht einmal in Betracht ziehen.“

Ähnliche Geschichten passieren in verschiedenen Projekten. Was war in Ihrem Projektleben interessant? Was war für Sie eine unerwartete Lektion? Teilen Sie es in den Kommentaren.

Tags: Tags hinzufügen

Landesbildungseinrichtung

Höhere Berufsausbildung

Nationale Forschungstechnische Universität „MISiS“

Abteilung für automatisierte Steuerungssysteme

Kursarbeit für den Kurs

„Systemtheorie und Systemanalyse“

Vollendet: Avdoshina Olga

Gruppe: MA-10-1/I810-4

Lehrer: Morozov E.A.

Moskau2014

1.Definition von normativen und Referenzinformationen 3

2. Probleme und Bedürfnisse von Unternehmen bezüglich des Stammdatenmanagementsystems. 3

3. Einheitliches Referenzdatenverwaltungssystem (EU-Referenzdaten) 5

4.Erstellung eines automatisierten Referenzdatenverwaltungssystems 8

4.1. Analyse der Stammdaten 8

4.2.Wahl der Architektur und Schätzung der Kosten für die Erstellung eines automatisierten Kontrollsystems für Referenzdaten 10

4.3.Umsetzung 15

5. Für die Pflege der Referenzdaten verantwortliche Personen 16

6. Effizienz der Umsetzung 18

7. Liste der verwendeten Literatur 20

1. Definition von normativen und Referenzinformationen

Der Betrieb jedes automatisierten Systems basiert auf regulatorischen Referenzinformationen (RNI). Stammdaten sind ein semipermanenter Teil aller Unternehmensinformationen, der im täglichen Geschäftsbetrieb des Unternehmens keinen wesentlichen Änderungen unterliegt. Zu den Stammdaten gehören: Wörterbücher, Nachschlagewerke und Klassifikatoren, deren Elemente (z. B. Codes, Namen von Materialien, Dienstleistungen, Auftragnehmern, Maßeinheiten usw.) bei der Erstellung aktueller Dokumente verwendet werden.

Referenzdaten werden in automatisierten Systemen bei der Erstellung von Betriebsdokumenten, Planung und Berichten verwendet. Dementsprechend hängt die Qualität dieser Plan-, Betriebs- und Berichtsinformationen direkt von der Qualität der Stammdaten ab. Managementfehler im Zusammenhang mit mangelhafter Informationsqualität kosten Unternehmen manchmal Verluste in Millionenhöhe.

1. Probleme und Bedürfnisse von Unternehmen bezüglich des NSI-Managementsystems.

Unternehmen nutzen in der Regel mehrere automatisierte Systeme zur Unterstützung verschiedener Geschäftsprozesse, in denen dieselben Verzeichnisse unabhängig voneinander gepflegt werden. Diese völlig typische Situation verursacht folgende Probleme:

Zusätzliche Kosten für die unabhängige Pflege derselben Verzeichnisse;

Zusätzliche Kosten im Zusammenhang mit der Gewährleistung der Informationsinteraktion zwischen Systemen, die unterschiedliche Verzeichnisse derselben Stammdatenobjekte verwenden;

Hoher Arbeitsaufwand und hohe Kosten für die Erstellung konsolidierter Berichte auf der Grundlage von Daten, in denen dieselben Referenzdatenobjekte (Waren, Dienstleistungen, Auftragnehmer) unterschiedliche Codes und Namen haben;

Geringe Qualität der Regulierungs- und Referenzdaten.

Was bedeutet „schlechte Qualität“ regulatorischer Referenzdaten? Dabei handelt es sich um Referenzdaten, die:

Haben Sie Probleme, Materialien und Ausrüstung in Gruppen zu strukturieren;

Doppelte oder widersprüchliche Angaben aus dem Verzeichnis der materiellen und technischen Ressourcen (Waren und Dienstleistungen) führen in 70 % der Fälle zu einer deutlichen Erhöhung des Unternehmensbestands und zur Bildung illiquider Vermögenswerte. Zum Beispiel:

Das Fehlen der erforderlichen Parameter in der Produktbeschreibung im Verzeichnis kann dazu führen, dass ein Produkt gekauft wird, das die erforderlichen Eigenschaften nicht erfüllt. Dadurch entstehen in Lagerhäusern illiquide Vermögenswerte;

Das Vorhandensein von Duplikaten im Verzeichnis ermöglicht es Ihnen nicht, die automatische Konsolidierung aller bestellten Materialien und Geräte mit demselben Namen korrekt durchzuführen, um einen konsolidierten Antrag zu erhalten. Dies führt dazu, dass die Bestellung in unterschiedlichen Chargen beim Lieferanten aufgegeben wird und das Unternehmen keinen Rabatt für die Aufgabe einer Großbestellung erhält und der Kauf daher zu einem höheren Preis abgeschlossen wird;

Die Verwendung unterschiedlicher Codes und Namen von Materialien und Geräten durch verschiedene Abteilungen ermöglicht es nicht, die Verfügbarkeit von Materialien und Geräten in Lagern und die Nutzung vorhandener Bestände zu analysieren, anstatt neue Materialien und Geräte zu kaufen, was ebenfalls zu finanziellen Verlusten führt.

Die geringe Qualität der Referenzdaten ist eine Folge der mangelnden Spezialisierung bei der Verwaltung von Referenzdaten. Die Aufgaben der Steigerung der Unternehmenseffizienz, die Notwendigkeit, eine moderne Grundlage für die Entwicklung der IT-Landschaft von Unternehmen zu schaffen, der Aufbau neuer Unternehmens-ERP-Systeme und die Entwicklung bestehender Systeme erfordern eine höhere Effizienz bei der Verwaltung von Regulierungs- und Referenzdaten. Die Einführung des Unified Reference Data Management Systems löst dieses Problem.

Dmitri Gulko
Cand. Technik. Wissenschaften, Präsident
NCIT „Intertech“

Wenn man das Problem der Stammdaten im Kontext der Geschäftsautomatisierung betrachtet, ist es wichtig zu verstehen, dass Stammdaten entgegen einem weit verbreiteten Missverständnis nicht Teil des ERP-Systems sind: Das Stammdatensystem stellt den notwendigen Dienst für alle Geschäftsanwendungen bereit. Und da dies so ist, erweist sich das bekannte Konzept der serviceorientierten Architektur als sehr fruchtbar, wenn es um Technologien für den Zugriff auf Stammdaten sowohl aus verschiedenen Geschäftssystemen als auch von deren Benutzern geht.

„Im Moment verfügt unser Unternehmen über so viele verschiedene Informationssysteme. Sie alle müssen informationell miteinander verbunden sein, das Problem ihrer Integration ist jedoch nicht gelöst. Wir kamen zu dem Schluss, dass die Hauptaufgabe, die gelöst werden muss, um Systeme in einen einzigen Informationsraum zu integrieren, darin besteht, die verwendeten Nachschlagewerke, vor allem das Nachschlagewerk der Materialien, in Ordnung zu bringen …“ Fast alle Kunden sagen etwas so, wenn Sie NCIT „Intertech“ kontaktieren. Im Allgemeinen sieht das Bild des Stands der regulatorischen Referenzinformationen (RNI) bei russischen Unternehmen traurig aus (siehe Seitenleiste „Probleme des aktuellen Stands der Referenzinformationen“).

Eines der charakteristischen Missverständnisse besteht darin, dass das Stammdatensystem nicht als eigenständige überstrukturelle IT-Komponente, sondern als „Anhang“ zu dem einen oder anderen ERP-System betrachtet wird. Es stellt sich also heraus, dass es ebenso viele Anwendungssysteme wie „Anhängsel“ gibt. Bei einem der größten russischen Petrochemieunternehmen wurden bei einer Untersuchung mehr als 25 unabhängige (!) Verzeichnisse von Lagerbeständen und Rohstoffen entdeckt. Von welcher Art der Informationskonsolidierung, von welcher Art der Überwachung und optimalen Planung können wir in diesem Fall sprechen?

Unserer Meinung nach ist es an der Zeit, dass Unternehmen das begreifen Stammdaten sind kein Bestandteil des ERP-Systems, sondern Teil der gesamten Unternehmens-IT-Infrastruktur. Die Qualität der Managementinformationen selbst hängt maßgeblich von der Qualität und Verlässlichkeit der Basisdaten (also der Stammdaten) ab. Schließlich hat noch niemand das GIGO-Prinzip (Garbage in – Garbage out, was in der semantischen Übersetzung bedeutet: „Wenn am Eingang Informationsmüll ist, dann ist am Ausgang derselbe Müll“).

Wenn nicht Teil von ERP, was dann?

Regulierungs- und Referenzinformationen sind in erster Linie eine intern generierte und in der Regel von außen erhaltene Informationsressource eines Unternehmens, die Standards, Anforderungen, Regeln, Vorschriften und andere Informationen enthält, die die Aktivitäten des Unternehmens normalisieren und systematisieren .
Im engeren Sinne werden in IT-Systemen Regulierungs- und Referenzinformationen (Basis- oder Stammdaten) als eine Reihe bedingt dauerhafter Daten definiert, auf denen die Prozesse zur Erstellung von Buchhaltungsbelegen in einem Unternehmen (Institution) basieren. Im Gegensatz zu aktuellen Informationen, die sich nur auf ein bestimmtes Dokument beziehen, werden Stammdaten in der Regel in verschiedenen Dokumenten verwendet, die sich auf verschiedene Geschäftsprozesse beziehen. In IT-Systemen werden Stammdaten üblicherweise durch eine Reihe von Nachschlagewerken und Klassifikatoren repräsentiert (siehe Seitenleiste „Aufbau des Stammdatensystems“).

Wir sollten nicht vergessen, dass das Referenzdatensystem neben den Informationen als solchen eine Reihe von Mitteln zu deren Suche, Speicherung, Verarbeitung und Verteilung, Methoden zu ihrer Pflege und Aktualisierung sowie eine Reihe von organisatorischen und organisatorischen Maßnahmen umfasst Verwaltungsdokumente und Vorschriften zur Nutzung und Pflege von Referenzdaten.

Reis. 1. Schema eines einheitlichen Referenzdatensystems

Einheitliches Referenzdatensystem

Derzeit kann man durchaus sagen, dass das Konzept eines Referenzdatensystems in seiner modernen Interpretation durch die zentrale Speicherung relevanter Daten in einem Repository, das Vorhandensein von Unternehmensstandards für die Pflege und Nutzung von Referenzdaten sowie die ständige Aktualisierung der Daten durch gekennzeichnet ist der Referenzdatendienst und natürlich der automatisierte Prozess der Datenpflege und Bearbeitung von Benutzeranfragen. Das allgemeine Diagramm des einheitlichen Systems (EU) von Referenzdaten ist in Abb. dargestellt. 1.
Und da es sich um Automatisierung handelt, ist die Bereitstellung von „Informationsdiensten“ für ERP-Systeme und andere Geschäftsanwendungen eine Eigenschaft, die eng mit der Bearbeitung von Benutzeranfragen verbunden ist. Der Service der EU-Referenzdaten für Nutzer und ERP-Anwendungen lässt sich wie folgt klassifizieren:

• Zugriff und multifunktionale Suche nach Basis-(Stamm-)Daten;
• Anfragen an den Stammdatenpflegedienst zur Änderung/Ergänzung von Daten;
• Anfragen an den Referenzdatenpflegedienst zur Einrichtung von Links oder Übergangsschlüsseln;
• Funktionen zur Stammdatenpflege (Anpassungen und Ergänzungen), verfügbar für Experten – Spezialisten des Stammdatendienstes;
• Lieferung (Replikation) von Stammdaten an Anwendungssysteme – Verbraucher von Stammdaten auf Anfrage oder bei einem Ereignis.

Wir möchten auch betonen: Es ist sinnvoll, die Beziehung zwischen den EU-Referenzdaten und dem lokalen System genau nach dem Leistungserbringungsmodell herzustellen, und dies zeigt einmal mehr, dass die Referenzdaten nicht Teil des ERP-Systems sind. Es ist wichtig, dass die Umsetzung dieses Mechanismus zur Bereitstellung von Informationsdiensten durch das NSI in keiner Weise privater, lokaler Natur sein darf. Jedes Unternehmen muss sicherstellen, dass alle seine Dienste und Abteilungen ein einziges einheitliches Stammdatensystem verwenden, das unter Berücksichtigung der tatsächlichen Anforderungen der Geschäftsprozesse optimiert ist.

Anforderungen und Grundsätze der Konstruktion
einheitliches Referenzdatensystem

Um sicherzustellen, dass alle Dienste und Bereiche des Unternehmens ein einheitliches Stammdatensystem nutzen, sollten vier Anforderungsgruppen berücksichtigt werden.

Methodisch - eine wirksame Methodik zur Pflege von Verzeichnissen und Klassifikatoren innerhalb eines einheitlichen Referenzdatensystems zu entwickeln und umzusetzen, um die Daten auf dem neuesten Stand zu halten, die Vollständigkeit sicherzustellen, Fehler zu beseitigen und die Integrität und Konsistenz der Daten zu kontrollieren.

Organisatorisch - zu einer einheitlichen Regelung für die Nutzung von Verzeichnissen des Stammdatensystems durch alle Dienste und Bereiche des Unternehmens und deren Unterstützung auf der Grundlage festgelegter Anforderungen an die Zusammensetzung und Struktur der Informationen in den Verzeichnissen.

Information - zur Zusammensetzung und Struktur der Informationen im Stammdatensystem sowie zur Technologie seiner Pflege (Bereinigung, Auffüllung, Anpassung).

Technisch - auf die Umgebung des Benutzerzugriffs auf Referenzdaten und die Arbeit von Experten des Referenzdatenpflegedienstes, auf die erforderlichen Funktionen und Informationsfähigkeiten.

Tatsächlich sind all dies nichts anderes als die Anforderungen an ein einheitliches Stammdatensystem, aber darüber hinaus können wir auch über die Anforderungen an die Daten dieses Systems sprechen. Dabei spielen Kriterien, die heute für jede Art von Unternehmensdaten gelten, eine sehr wichtige Rolle. Im Hinblick auf Referenzdaten, deren Lebenszyklus per Definition den entsprechenden Zyklus für Betriebsdaten übersteigt, sind sie jedoch noch wichtiger. Wir sprechen von Vollständigkeit, Konsistenz, Korrektheit und Relevanz. Gleichzeitig gibt es neben diesen klassischen Kriterien (deren Umsetzung heute durch etablierte Datendesigntechniken und zuverlässige Softwareprodukte sichergestellt wird) auch spezifischere Kriterien, die speziell für Referenzdaten charakteristisch sind.

Das Identifizierbarkeit Und Einzigartigkeit , die eine eindeutige und eindeutige Identifizierung von Daten ermöglichen, die für die Verknüpfung mit anderen Elementen von Stammdaten und Bewerbungsunterlagen erforderlich ist. Vereinigung ermöglicht Ihnen die Anwendung einheitlicher Regeln für das Schreiben/Beschreiben von Stammdatenelementen, z. B. die Namen von Materialien im Inventarverzeichnis, die Verwendung eines einheitlichen Verzeichnisses von Maßeinheiten (und keine Textfelder im selben Inventarverzeichnis), die Verwendung der Namen von Kontrahenten im entsprechenden Verzeichnis usw.

Und endlich, Strukturierung notwendig für umfangreiche, zahlreiche Elemente/Datensätze und Informationsfelder, zum Beispiel ein Verzeichnis materieller und technischer Ressourcen (MTR).

Es empfiehlt sich auch, die Prinzipien für den Aufbau eines einheitlichen Referenzdatensystems hervorzuheben.

Unternehmensgeist sieht die Notwendigkeit vor, die EU-Referenzdaten im gesamten Unternehmen, seinen Strukturbereichen und Unternehmen zu nutzen.

Vielseitig einsetzbar - Das Stammdatensystem muss den Informationsbedarf jeder funktionalen Benutzergruppe befriedigen und ihm individuell ausgerichtete Datenausschnitte präsentieren.

Volle Funktionalität - ES-Referenzdaten müssen bestimmte funktionale Mängel von ERP- und anderen im Unternehmen verfügbaren Anwendungssystemen im Zusammenhang mit der Suche, Verarbeitung und Nutzung von Referenzdaten ausgleichen.

Zentralisierung Funktionen zum Speichern eines Referenzdatenarrays von Stammdaten, zum Verwalten, Erstellen neuer und Vornehmen von Änderungen an vorhandenen Referenzdaten.

Anpassungsfähigkeit und Skalierbarkeit Systeme, da neue Anforderungen an die Zusammensetzung und Struktur der Stammdaten entstehen, unter Berücksichtigung organisatorischer Veränderungen im Unternehmen, Änderungen in der Software- und Hardwarelandschaft, einer Erhöhung der Belastung des Informationssystems und der Anzahl der Benutzer.

Integrierbarkeit EU-NSI mit bestehenden ERP- und anderen Unternehmensinformationssystemen.

Standardisierung und Vereinheitlichung Stammdatenformate, Methoden zu ihrer Bildung und Änderung auf der Grundlage von Unternehmensorganisations- und Verwaltungsdokumenten.

Kontinuität - Bei der Erstbefüllung des Referenzdatensystems werden die im Unternehmen verwendeten Verzeichnisse und Klassifikatoren zugrunde gelegt, die nach Konsolidierung und Normalisierung Teil davon werden. Neu erstellte „Referenzdaten“ ersetzen nach und nach die alten.

Reis. 2. Phasen der Erstellung eines einheitlichen Referenzdatensystems

Aufbau des Stammdatensystems erfolgt stufenweise. In diesem Zusammenhang können wir die Konsolidierung von Daten aus Anwendungssystemen, ihre Harmonisierung hervorheben, bei der es darum geht, Daten in eine für Referenzdaten charakteristische hierarchische Struktur mit angemessener Klassifizierung zu bringen, sowie den Übergang zur zentralisierten Nutzung und Pflege von Verzeichnissen, in denen die Referenzdaten gespeichert sind Service beteiligt ist. In Abb. Abbildung 2 zeigt drei wichtige Phasen beim Aufbau eines Referenzdatensystems.

Serviceorientierte Architektur

Große Unternehmen (und nicht nur in Russland, sondern auch in fortgeschrittenen Ländern für die Implementierung von IT-Anwendungen, wie den USA, europäischen Ländern usw.) stehen vor der Herausforderung, wenn ihr Geschäft wächst, sich diversifiziert oder neu ausrichtet, sich durch Fusionen und Übernahmen vergrößert die gleichen, die gleichen Probleme: Erstens handelt es sich um eine plattformübergreifende (heterogene) IT-Landschaft, die zu Inkonsistenzen der Informationen in verschiedenen unterschiedlichen Unternehmensanwendungen führt. Es ist sehr wichtig, Folgendes zu verstehen: Die Probleme einer heterogenen IT-Landschaft sind nicht nur ein „historisches Erbe“. Dies ist ein möglicher Entwicklungspfad .

Sollten wir ein neues, universelles Supersystem mit einer Plattform aufbauen oder versuchen, bestehende IT-Anwendungen zu nutzen, wenn diese zumindest teilweise den Geschäftsanforderungen genügen? Wie baut man eine Unternehmens-IT-Strategie auf, damit einerseits der IT-Support nicht hinter dem wachsenden Geschäft des Unternehmens zurückbleibt, mit neuen effektiven Lösungen aufgefüllt wird und andererseits die bereits getätigten Investitionen in die IT-Infrastruktur erhalten bleiben? ? Das sind die uralten Fragen des CIO.

Natürlich ist das Fehlen eines effektiven Systems zur Unterstützung einheitlicher Stammdaten in großen Unternehmen vor dem Hintergrund einer heterogenen IT-Landschaft ein zentrales Problem bei der Automatisierung von Buchhaltungs- und Verwaltungsaufgaben. Ein weiteres Problem besteht darin, das Zusammenspiel der Betriebssysteme sicherzustellen. Die dritte Möglichkeit ist die Rationalisierung und Vereinheitlichung von Funktionen (Diensten) im gesamten Unternehmen, wodurch funktionale Duplikate vermieden werden. Und schließlich ist die vierte Möglichkeit die modulare Erweiterung der IT-Landschaft „Stein für Stein“.
Einer der Ansätze, der eine klare Lösung für die genannten Probleme bietet, ist die serviceorientierte Architektur (SOA). Gleichzeitig müssen Sie verstehen, dass es sich bei SOA nicht um eine bestimmte Technologie, sondern um einen Ansatz, ein Konzept handelt. Als technologische Basis für SOA dienen häufig die in Webdiensten verwendeten Technologien, Standards und Protokolle (SOAP, WSDL, UDDI etc.).

Bereits 2003 prognostizierte einer der Gartner-Berichte, dass „...im Jahr 2008 SOA zum dominierenden Ansatz in der Softwareentwicklung werden und die 40-jährige Dominanz der monolithischen Softwarearchitektur beenden wird.“ Ende 2003 führte das CIO Magazine eine Umfrage durch, bei der mehr als 50 % der Befragten angaben, in dem einen oder anderen Ausmaß an der SOA-Entwicklung beteiligt zu sein. Im März 2004 befragte Smith Barney (der Forschungszweig der Citigroup) 100 führende CIOs und stellte fest, dass SOA eine der höchsten Technologieprioritäten darstellt. Das Hauptziel der Umstellung auf SOA besteht sicherlich darin, die getätigten und getätigten Investitionen in die bestehende IT-Landschaft zu erhalten sowie:

• Schrittweiser, evolutionärer Aufbau von Services (Anwendungen) bei wachsendem Unternehmen und steigendem Bedarf an IT-Unterstützung, modulares Bauprinzip;
• Zusammenführung plattformübergreifender Anwendungen in einer einzigen Informations- und Verwaltungsumgebung;
• Plattformtoleranz, die Fähigkeit, bestehende, auch veraltete, Systeme und Plattformen beizubehalten und plattformübergreifende „Best-in-Class“-Anwendungen unabhängig von ihrer Plattform in die gesamte Unternehmens-IT-Landschaft zu integrieren;
• organische, einfache und zuverlässige Nutzung externer Dienstleistungen (d. h. Dienstleistungen, die von externen Organisationen zu Outsourcing-Bedingungen bereitgestellt werden);
• Stabilität, Funktionsfähigkeit des Gesamtsystems und anderer Komponenten der IT-Infrastruktur bei Ausfall eines der Systeme.

Probleme von Referenzdaten im Inneren von SOA

Grundlage von SOA ist das Konzept von Dienstleistungen, die in der Regel einzelne Gesamtfunktionen von Software, Unternehmensanwendungen und Systemen umfassen (z. B. Erstellung eines Antrags für den Materialeinkauf, Abfrage von Informationen über den Materialbestand im Lager usw.). . Services stellen die „Bausteine“ der gesamten IT-Landschaft dar. Eine wichtige Anforderung von SOA ist das Fehlen starrer Verbindungen zwischen „Dienst“-Modulen, was Softwaremodularität ermöglicht und die Möglichkeit bietet, einige „Dienste“ zu ersetzen und zu verbessern, ohne andere zu ändern. Alle Verbindungen zwischen ihnen, „lose gekoppelt“ genannt, laufen auf einfache Befehle zum Aufruf einiger Dienste durch andere hinaus, und das Format und die Syntax solcher Befehle sind vorbestimmt. Es muss jedoch berücksichtigt werden, dass eine solche „schwache“ Interaktion zwischen verschiedenen Systemen und Diensten nur erreichbar ist, wenn alle dieselben einheitlichen Stammdaten (MSI), gemeinsame Codes usw. verwenden. Wenn eine solche Vereinheitlichung nicht erfolgt, ist die Einhaltung der Prinzipiell sind „schwache“ Interaktionen zwischen „Diensten“ unmöglich.

Mit anderen Worten, Die Vereinheitlichung von Diensten (Funktionen) impliziert die Vereinheitlichung von Stammdaten (Stammdaten). Wenn also der Dienst „Erstellen eines Antrags für den Materialeinkauf“ durch das Modul „Bewerbungskampagne“ unterstützt wird, das von einem lokalen Softwareentwickler geschrieben wurde, und der Dienst „Anfordern von Informationen über den Materialbestand im Lager“ unterstützt wird durch B. ein ERP-System auf der SAP R/3-Plattform, dann ist es zur Bilanzierung von Salden bei der Bedarfsplanung (d. h. für die angrenzende Arbeit zweier Dienste in einem Geschäftsprozess) erforderlich, dass beide Dienste mit einem einzigen Materialverzeichnis arbeiten (bzw , was im Wesentlichen dasselbe ist, wobei die Verzeichnisse durch Übergangsschlüssel vollständig miteinander verknüpft sind.

Reis. 3. SOA-Fragmentdiagramm

Ein weiteres wichtiges Merkmal von SOA ist, dass auf „Dienste“ von überall im Unternehmensnetzwerk zugegriffen werden kann, unabhängig vom Standort – Sie müssen lediglich Zugriff auf das Netzwerk haben. Um Spezifikationen und Beschreibungen von „Diensten“ zu speichern, stellt SOA ein sogenanntes Register und Repository von Diensten (RRS) bereit, in dem die Zugriffsadressen für jeden registrierten „Dienst“, Daten über seinen Standort im Netzwerk und eine Beschreibung der Aufrufregeln gespeichert sind Gespeichert werden , Regelungen zu deren Bereitstellung usw. Neben den Diensten selbst und dem Informationsbus zum Austausch von Anfragen und Daten, der bei der Diskussion von SOA häufig thematisiert wird, ist das Portal der wichtigste Bestandteil dieser Architektur, der jedoch weit weniger wichtig ist wird oft im Zusammenhang mit SOA erwähnt.

Zum Beispiel in Abb. Abbildung 3 zeigt ein Fragmentdiagramm der serviceorientierten Architektur von Anwendungen, die am Geschäftsprozess „Application Campaign“ teilnehmen; Hier sehen Sie die wichtigsten Komponenten von SOA, darunter PPC und das Portal. Darüber hinaus verdeutlicht diese Zahl den offensichtlichen Bedarf an EU-Referenzdatendiensten (Master Data Management, MDM-Komponente) im gesamten Prozess. Gleichzeitig zeigt das Diagramm deutlich den Mechanismus zum Aufrufen von Diensten und zur Interaktion zwischen Anwendungen in SOA.

Es ist wichtig zu beachten, dass eine der Hauptanforderungen, die den SOA-Ansatz definieren, die Fähigkeit ist, alle Unternehmensanwendungen, die als Elemente von SOA betrachtet werden, an den Austauschbus anzuschließen. Bei der Beschreibung der Referenzdaten haben wir gesagt, dass Beziehungen zwischen den EU-Referenzdaten und dem ERP-System gerade in Form der Bereitstellung von Informationsdiensten hergestellt werden.

Reis. 4. Ebenen der IT-Infrastruktur
in der serviceorientierten Architektur

Unserer Meinung nach ist es interessant, die Ebenen der IT-Infrastruktur in der Servicearchitektur hervorzuheben. In Abb. Abbildung 4 zeigt sieben Ebenen, die die „tiefgreifende“ Struktur definieren. Entscheidend ist, dass Stammdaten die untere Ebene bilden – das „Informationsfundament“ der gesamten IT-Infrastruktur. Das Stammdatenverwaltungssystem (über MDM) kann auf einer separaten unabhängigen Plattform aufgebaut werden, aus mehreren Geschäftsanwendungen bestehen (einschließlich Benutzerarbeitsplatz, Expertenarbeitsplatz, Administratorarbeitsplatz) und Dienste bereitstellen, auf die über das Unternehmensnetzwerk zugegriffen werden kann. Besonders hervorzuheben ist, dass eine solche serviceorientierte Architektur sehr praktisch ist, um den Prozess der Stammdatenpflege auszulagern. Gleichzeitig erhalten die Mitarbeiter des Unternehmens, die Dienste für den Zugriff auf Stammdaten nutzen und Anfragen an den Stammdatenpflegedienst stellen, das erforderliche Serviceniveau (im SLA-SLR verankert), ohne darüber nachzudenken, wo und von wem dieser Service erbracht wird.

Schaffung eines einheitlichen Systems Verwaltung normativer und Referenzinformationen(NSI) wird dazu beitragen, eine ganze Reihe von Problemen zu lösen, die durch die Vielzahl von Referenzdaten-Eingabepunkten, das Fehlen einheitlicher Standards für die Pflege von Referenzdaten und die unzureichende Qualifikation des Personals verursacht werden.

Das Ergebnis der Implementierung eines zentralisierten Stammdatenverwaltungssystems ist die Reduzierung der Unternehmensverzeichniseinträge auf eine einheitliche, leicht identifizierbare Form, die Beseitigung irrelevanter und doppelter Informationen, die Organisation eines zentralen Einstiegspunkts sowie die Verarbeitung und Kontrolle des Verzeichnisinhalts . All dies bietet Möglichkeiten, die Qualität der Konsolidierung von Buchhaltungsdaten zu verbessern, die Aufgaben der Erstellung von Abschlüssen und der Berichterstattung nach IFRS zu vereinfachen, Vorräte zu optimieren und die Qualität von Managemententscheidungen zu verbessern.

Zentralisierte Verwaltung von Regulierungs- und Referenzinformationen mit DATAREON

Die Spezialisten von DATAREON verfügen über umfangreiche Erfahrung in der Systematisierung Regulierungs- und Referenzinformationen, Entwicklung einheitlicher Regelungen für die Nutzung und Pflege von Stammdaten, Implementierung spezialisierter automatisierter Stammdatenverwaltungssysteme auf Basis des MDM-Systems „1C: Enterprise 8. MDM Master Data Management“. Im Rahmen der abgeschlossenen Projekte führten die Spezialisten von DATAREON eine fachmännische Bearbeitung der Aufzeichnungen von Bestandsverzeichnissen, Dienstleistungen, Kontrahenten, Finanzblockverzeichnissen, Organisationsstruktur und Personalmanagement durch.

Erfolgreiche Erfahrungen im Bereich Stammdatenmanagement, effektive, in der Praxis erprobte Methoden und eigene Expertise ermöglichen es DATAREON, den Ressourceneinsatz der Kundenunternehmen durch Automatisierung des Stammdatenmanagements zu optimieren.

Um zu klären, wie die Automatisierung des Regulierungs- und Referenzinformationsmanagements für Ihr Unternehmen sinnvoll und wirtschaftlich machbar sein kann, kontaktieren Sie uns bitte.

Was sind regulatorische Referenzinformationen (RNI)?

Regulierungs- und Referenzinformationen- ein bedingt dauerhafter Bestandteil allgemeiner Unternehmensinformationen. Es dient der Regulierung der Unternehmensaktivitäten und sorgt für die „Verknüpfung“ von Daten, die die Geschäftsprozesse des Unternehmens begleiten. Mit anderen Worten, NSI- Dies ist der Kern des einheitlichen Informationsraums der Organisation, der eine Reihe von Nachschlagewerken, Wörterbüchern, Klassifikatoren, Standards und Vorschriften umfasst, die bei den Aktivitäten des Unternehmens verwendet werden.

Voraussetzungen für die Organisation einer zentralen Verwaltung von Regulierungs- und Referenzinformationen

Die Schaffung eines einheitlichen Informationsraums ist eine notwendige Voraussetzung für die effektive Führung moderner großer und mittlerer Unternehmen. Die Bildung einer einheitlichen Umgebung beinhaltet die Integration von Managementprozessen, begleitet von der Normalisierung der Informationsflüsse. Oft wird der Informationsfluss in verschiedenen unternehmensinternen Technologiebereichen durch verschiedene Informations- und Buchhaltungssysteme unterstützt. Dementsprechend besteht die Notwendigkeit, diese Systeme zu integrieren.

Die Aufgabe der Integration von Informations- und Buchhaltungssystemen besteht aus zwei miteinander verbundenen Teilen: der Datenintegration und der anschließenden Anwendungsintegration. Bei der Datenintegration sollte das Unternehmen Regulierungs- und Referenzinformationen vereinheitlichen und standardisieren.

Warum ist eine zentrale Verwaltung der Referenzdaten notwendig?

• Rationeller Betrieb des gesamten Unternehmensinformationssystems
• Erhöhung der Zuverlässigkeit und Vollständigkeit der primären Buchhaltungs- und konsolidierten Berichtsinformationen
• Sicherstellung der Kompatibilität von Buchhaltungs- und Berichtsdokumenten
• Zentralisierung der Verantwortung für die Qualität der Regulierungs- und Referenzinformationen
• Nutzung hochwertiger (aktueller, vollständiger, konsistenter, zuverlässiger, einheitlicher) Regulierungs- und Referenzinformationen durch alle Benutzer der Informations- und Buchhaltungssysteme des Unternehmens
• Erhöhte Effizienz von Managemententscheidungen und operativer Kontrolle wichtiger Produktions- und Wirtschaftsindikatoren durch die Konsolidierung standardisierter NSI-Daten