🏉 🌂 🈶 Caractéristiques de la data-driven dans la pétrochimie 🎒 🌌 💶

Lors de la création d'une entreprise, chacune de ses divisions s'automatise. En règle générale, les flux de données de bout en bout entre eux sont uniques. Cela conduit au fait que les données ne peuvent pas être comparées entre elles, car chaque département les considère à sa manière. Pas de problème si vous collectez des métriques pour l'ensemble de l'entreprise, mais quand il s'agit de calculer des indicateurs de bout en bout, de prévoir ou de résoudre des problèmes de modélisation et d'optimisation, le chaos commence.

L'entreposage de données (DWH) n'est pas une nouvelle histoire. Traditionnellement, ils ont été utilisés pour les rapports. Mais la modélisation et la prévision à part entière des processus métier de bout en bout sur les données DWH ont commencé relativement récemment. En utilisant les données collectées, les outils d'analyse modernes permettent non seulement de créer des tableaux de bord avec des fenêtres déroulantes, mais également de configurer des algorithmes de prévision et d'optimisation pour chaque attribut, de mettre à l'échelle des algorithmes de théorie des jeux pour l'ensemble de l'entreprise dans son ensemble. Et également construire et tester immédiatement des hypothèses sur le développement futur de l'entreprise sur des données réelles.

Et il semble que tout sonne bien. Mais toutes les entreprises ne sont pas pressées de prendre l'exemple des meilleurs experts (Booking.com, Amazon.com) et continuent de travailler comme d'habitude. Alors qu'est-ce qui les arrête? Au minimum, comprendre la faisabilité d'investissements à grande échelle dans les outils de traitement des données, la lourdeur de la mise en œuvre des processus de description des données, l'émergence de nouveaux rôles (conservateurs de données responsables de la qualité des données, ingénieurs et architectes de données, etc.), apprendre à considérer l'effet économique de la mise en œuvre de la gestion des données , isoler clairement les inducteurs de coûts, comment rendre le bureau autonome, se réconcilier avec la stratégie de l'entreprise et choisir ceux qui feront avancer l'entreprise, et bien plus encore.

Je m'appelle Victoria Krasnova, je suis responsable de la gestion des données d'entreprise de SIBUR. Avec mon collègue, le chef de l'équipe de gouvernance des données, Rinat Abdurakhmanov, nous vous expliquerons comment nous procédons.

Lorsque les grands détaillants (Wallmart) ont commencé à numériser, ils ont dû déterminer quelles empreintes numériques et artefacts un processus commercial laissait derrière et ce que le suivant prenait comme entrée. Autrement dit, décrivez le processus opérationnel de bout en bout. La même chose est requise pour la numérisation de toute autre entreprise. Une façon de répondre à cette demande est le concept de gestion et d'architecture des données.

Dans un sens appliqué, cela signifie: rassembler les données les plus importantes et les moins importantes de l'entreprise en un seul endroit, les décrire dans un langage clair, les relier aux processus métier et créer des méthodes conviviales d'accès à ces données.

L'architecture des données, parmi ses autres fonctions, fournit des réponses claires aux questions «où est-elle considérée?», «Qu'est-ce qui est considéré?», «Pourquoi est-elle considérée?», «Qui est responsable de la qualité?» et "où est-il situé, dans quel système se trouve-t-il?".

Il est important que les réponses à ces questions soient distinctes de l'entreprise elle-même. Cela se passe souvent de cette façon: l'analyste veut tester une hypothèse. Pour ce faire, il doit aller demander les données nécessaires à leur propriétaire, prouver pourquoi et pourquoi cela est nécessaire et important, y passer une demi-journée. Le meilleur cas de scenario. Et finalement obtenir un refus. Pourquoi? Parce que le propriétaire des données est responsable de fournir l'accès aux données et leur diffusion ultérieure, car on ne sait pas comment les données seront interprétées par l'analyste et cela peut ne pas lui convenir, etc.

Par conséquent, il est nécessaire de construire une telle structure et une logique qui seront intuitives, fonctionneront selon des règles uniformes et ne détourneront ni l'analyste lui-même ni le propriétaire des données des tâches immédiates.

À ces fins, un modèle de données logique est excellent - une description des données dans le langage métier de détail aux détails techniques, en combinaison avec un modèle de rôle flexible. Dans ce cas, l'analyste accède au référentiel et à l'ensemble de données en fonction de son rôle dans l'entreprise. Et il recueille l'ensemble des données requises sur la base du bon sens, et non en sachant qu'en 2005 un certain camarade a travaillé dans l'entreprise, dont le fichier contient les données requises.

Une telle approche de la structuration permet aux gens d'analyser rapidement, rend les données comparables et, par conséquent, permet d'obtenir des avantages secondaires - de numériser l'ensemble de l'entreprise par étapes.

Quels sont les défis auxquels nous sommes confrontés

Au SIBUR, certains processus sont assez bien numérisés, par exemple, la préparation des données pour le marketing, la finance, la gestion de la chaîne d'approvisionnement, les données de production et les contournements des usines de production. Tout le reste est plus difficile, car SIBUR est une production avec un cycle dans lequel, du point de vue des affaires, il n'est pas nécessaire de collecter des informations à la même vitesse que celle nécessaire dans le commerce de détail, les télécommunications ou les banques. En conséquence, la question de la rapidité dans l'analyse des données n'a pas non plus été soulevée. Mais difficile - ne signifie pas impossible. Cette année, nous prévoyons d'optimiser les processus, de rendre le calcul des données plus transparent, d'augmenter le taux de transfert de données pour la prise de décision, et également de commencer à collecter des pistes numériques à toutes les étapes des processus, si possible.

Pourquoi les entreprises numériques sont-elles très précises et rapides pour la prise de décision? Parce qu'ils n'ont pratiquement aucune marge pour faire une erreur si les données s'avèrent soudainement fausses. En production, tout est différent - cela ne s'arrêtera pas, les usines ne resteront pas debout s'il y a une inexactitude dans les données pour l'analyse. L'architecture des données est donc la force même qui, contrairement à tout, conduit la production dans le sens numérique. Et la gestion des données est une bibliothèque qui vous permet de rationaliser le flux de données dans toute l'entreprise.

Récemment, nous avons lancé une ligne qui traite de la description des données. Pendant que nous sommes à la recherche d'un outil pour décrire les données, stocker et accéder confortablement aux descriptions. Si l'outil de description n'est pas pratique et que, pour cette raison, nous ne pourrons pas tenir à jour le catalogage, son utilisation n'aura plus de sens. Par conséquent, les données elles-mêmes dans le référentiel peuvent ne pas être pertinentes. Pourquoi devons-nous construire quelque chose sur la base de données dont la date d'expiration a déjà expiré?

Ici, nous avons encore une autre tâche: comment motiver les architectes accompagnant les systèmes d'information existants, décrire les données et les tenir à jour. Le principe «vous le construisez, vous le gérez» est populaire dans les entreprises numériques. Notre implémentation historique le fait que certaines personnes le présentent, mais d'autres le soutiennent. Souvent, la documentation n'est pas à jour et certains algorithmes ne vivent que dans l'esprit des anciens. Par conséquent, la description des systèmes est un travail qui prend beaucoup de temps, en particulier lorsqu'elle est effectuée à partir de zéro (comme dans notre cas). En effet, en réalité, l'effet de ce travail leur arrivera beaucoup plus tard, seulement après avoir décrit une masse critique de données. Mais au final, lors de l'introduction d'un autre nouveau système, ils n'auront pas à rechercher de données pour l'alimenter. Maintenant, il faut en moyenne deux semaines ou plus pour rechercher ces données.

Des données sont nécessaires non seulement pour introduire de nouveaux systèmes, mais aussi pour tester des hypothèses. Ils surviennent généralement beaucoup et sont testés par lots. Et en fait, il s'avère qu'il y a des données, il y en a beaucoup, elles sont diverses, mais seulement beaucoup de temps et d'argent sont dépensés pour leur recherche.

Un autre point lorsque vous modifiez des données «sans avertissement» à un endroit entraîne une erreur dans les données de l'autre endroit. Par exemple, l'indicateur «Volume de production» tenait compte des pertes aux stades de redistribution, puis s'est arrêté. Ils ont changé le système, mais les autres ne sont pas à jour et continuent d'utiliser l'indicateur comme auparavant. Par conséquent, les données pour prendre une décision de gestion sont incorrectes. Ou à un moment donné, il s'avère que les données ne sont pas comparables, les gens commencent à rechercher des erreurs. Et c'est aussi du travail, seulement invisible et incalculable.

En général, comme vous le comprenez, nous avons été confrontés à la question du choix d'un outil pour travailler avec des données. Et avant d'aller choisir un instrument, vous devez écrire des critères adéquats pour un tel choix.

Critères de sélection des instruments

Nous sommes à la recherche d'un outil qui prendrait en charge la description des métadonnées sous la forme d'un modèle d'objet avec la possibilité d'ajouter indépendamment de nouveaux types d'objets. Tous les produits n'offrent pas cette fonctionnalité. Par exemple, certains outils vous permettent d'afficher uniquement les tables physiques en tant qu'objets, mais il n'y a pas de classe d'objets pour les entités conceptuelles ou logiques.
Une configuration flexible des connexions entre les objets est très importante. Par exemple, nous avons aujourd'hui trois niveaux d'abstraction logiques, mais nous devrions être limités dans notre capacité à supprimer ou à ajouter un nombre quelconque de niveaux.

Un autre critère important est la présence de connecteurs intégrés aux systèmes sources, en particulier à SAP. Nous avons beaucoup de SAPa (je pense que toute grande entreprise, en principe, a beaucoup de SAPa) - une énorme installation, et pelleter avec vos mains est une tâche complètement ingrate. Idéal s'il y en a un. S'il n'y a pas un tel connecteur, vous pouvez l'écrire vous-même.

N'oublions pas la recherche en texte intégral, la recherche sémantique avec la possibilité d'ajouter vos propres dictionnaires de synonymes (par exemple, Elasticsearch intégré).

Un rôle important est joué par la possibilité de rétroaction. De plus, il faudrait , la possibilité de commenter, évaluer sur le principe de 1-5 étoiles, communication directe avec la personne responsable de l'entité ou l' attribut d'une entité particulière, ainsi que la mise des drapeaux et des balises pour attirer l' attention, ainsi que l' ajout d' objets aux favoris.

En outre, il est bon aurait un connecteur natif vers SAS DQ ou tout autre outil pouvant être utilisé pour évaluer la qualité des données et afficher l'indice d'intégrité d'une entité particulière, afin que l'utilisateur puisse immédiatement voir que les données peuvent être approuvées, car elles ont été exécutées avec vérification. Et donnez votre avis à ce sujet.

En général, vous avez besoin de quelque chose comme ceci:

Voici un exemple de cas typique pour vous: une personne a vu que vous pouvez faire confiance aux données, a regardé de plus près et a trouvé une erreur, et a écrit directement au propriétaire pour lui demander de la corriger. Il s'avère qu'une telle vitrine de la santé des données. Cette ouverture et cette large disponibilité des données réduisent progressivement le degré de méfiance des utilisateurs et des propriétaires. Un analyste disposant d'un accès aux données, même le plus élémentaire, peut rapidement obtenir les informations nécessaires qui ont été vérifiées et, en même temps, cela ne dépend pas du propriétaire des données qui fournit ces informations. Gagnant-gagnant.

Mais généralement, tout le monde a tout dans Excel, et c'est un gros problème (pas Excel lui-même, bien sûr, mais une telle situation). Les gens ont compté les indicateurs, puis ils les ont corrigés dans leur propre tablette, mais rien n'a changé dans le système général. Et l'analyste a peur de prendre un chiffre à partir de sources d'entreprise accessibles au public, il est plus facile d'aller voir un collègue et de demander un fichier. C'est assez difficile à gérer. En fait, le critère de réussite de la mise en œuvre d'un bureau de données peut être considéré comme la création d'environnements dans lesquels les employés, en règle générale, s'appuient sur les résultats de l'analyse pour prendre des décisions, et préfèrent SQL et Python à partir d'outils.

Par ailleurs, il convient de mentionner le maintien des statuts actuels des données «Secret commercial», «Données publiques», «Données personnelles», «Données d'entreprise à distribution limitée». Autrement dit, pour un analyste de données, il est important de savoir exactement ce qu'il est en train de parcourir et de décharger, ou de laisser voir à ses collègues.

Après tout, lorsque la personne moyenne se tourne vers la législation relative aux secrets commerciaux et aux informations confidentielles, elle voit des informations généralisées sur ce qui peut nuire aux entreprises. Dans de nombreux cas, ils commencent à considérer comme des données critiques en général tout ce qui contient des chiffres (du coup quelque chose). En conséquence, lorsqu'on lui demande de fournir des données pour analyse, le propriétaire commence à se demander: «est-ce un secret commercial?», «Les actions du demandeur demanderont-elles un préjudice?», Et, étant réassuré, il refuse souvent. Après tout, il est responsable de ces informations et ne sait pas comment l'analyste les utilisera.

Il y avait un autre cas: lorsque nous travaillions sur une liste d'informations confidentielles pour un projet de démocratisation des données, il s'est avéré que cette liste contient des données que les propriétaires appellent confidentielles, et nous sommes tenus par la loi de les fournir sur le site officiel. Et, bien sûr, ils y sont publiés. Autrement dit, dans des conditions où il n'y a pas d'outil unique dans lequel tout le monde peut voir des informations vérifiées sans ambiguïté à la fois, beaucoup de gens travaillent en mode «quoi qu'il arrive» et sont très réassurés.

Donc, c'est tout sur les critères. Mais de ce que nous avons choisi exactement.

Rechercher une solution

Nous disons «choisir» car nous n'avons pas encore choisi, nous sommes toujours à la recherche de l'outil parfait. Au départ, nous avons choisi Collibra, SAS DG, Alation, Alteryx Connect et Informatica. Nous avons également examiné des projets open source étrangers, mais ils les ont balayés presque immédiatement, car personne ne sait comment travailler avec l'alphabet cyrillique.

Puis il y a eu une expérience infructueuse avec Collibra. Nous avons presque terminé l'accord, mais il a échoué - nous ne nous sommes pas entendus sur les conditions. À court terme, ils passeront complètement au cloud, et pour toute entreprise russe, ce n'est pas une option. En fait, ils ne fourniront pas un produit, mais un service: Collibra fournit un abonnement, et nous fournissons nos données. Formellement, ce n'est pas un secret commercial, mais des métadonnées, mais en fait, si quelque chose tourne mal, l'entreprise sera complètement paralysée.

Après cette histoire, nous avons réalisé que nous choisirions la boîte pendant longtemps: nous avons de longs processus, nous abordons soigneusement les transactions, les conditions et les sous-traitants, nous vérifions tout à plusieurs reprises pour nous assurer que le risque est minime. Connaissant toutes ces fonctionnalités, nous sommes entrés dans notre propre développement pour proposer au moins une solution temporaire pour les utilisateurs. Après tout, les données affluent et il est impossible de les utiliser sans description! En parallèle, nous examinons de plus près Alation et Alteryx Connect et comparons leurs fonctionnalités et leurs coûts avec notre solution.

Nous avons inventé le modèle logique de stockage nous-mêmes, c'est un peu plus compliqué pour nous ici que pour d'autres industries. Par exemple, pour les banques et les télécommunications, il existe des architectures de données de référence - des structures généralement acceptées et des recommandations sur quoi et comment décomposer les données. Pour la pétrochimie, il n'y a pas de cycle complet de sources d'emprunt créatif dans le domaine public. Il n'a fallu qu'un an pour comprendre le fonctionnement de l'entreprise dans son ensemble. SIBUR a une production complexe, un grand nombre de nomenclatures, de processus, d'entreprises, qui se reflète dans les systèmes, ce qui signifie qu'il nécessite une analyse.

Ici, cela nous a aidés à ce qu'il y ait le soi-disant leadership à forte intensité de connaissances. Par exemple, dans d'autres industries assez souvent, les gestionnaires et les gestionnaires ne connaissent pas très bien l'industrie elle-même. Cela se produit, en principe, ce n'est pas quelque chose de directement terrible, au final, leur métier est de gérer des projets, et il s'avère que le lien de chaque nouveau manager en sait généralement un peu moins que le précédent. Mais il s'est avéré que les managers sont des personnes capables de vous expliquer sur les doigts tous les processus qui peuvent se produire avec le butadiène tout au long de son chemin de vie, par exemple.

Donc, à propos de la décision. Une recherche créative est telle qu'elle peut prendre un an, deux ou deux vies. Par conséquent, la recherche est bonne, mais vous devez travailler sur quelque chose en ce moment.

Nous sommes donc allés à notre propre développement, appelé dg_light. Le développement du front a pris 4 semaines (pour dire la vérité, pas à partir de zéro, nous avons réutilisé les réalisations de l'outil d'analyse de multipropriété récemment sorti de la chaîne de montage).

Composition du projet:

Backend: Docker, Node.js, NGINX, Crossbar.io
Frontend: React, Redux, Material UI, Highcharts, Autobahn.js
Stockage de données: PostgreSQL
Protocoles: WAMP, WebSocket, HTTP (S)
Système d'exploitation: CentOS 7

La structure des installations de stockage et la méthodologie ont été fournies par les architectes de données. Pour étudier la conception avant, ils ont planté un certain nombre d'analystes de différents niveaux de maturité et ont demandé: "Comment aimeriez-vous que ce soit?" En fait, ils ont peint pour eux-mêmes.

Tout développement a pris 6 semaines.

Une question raisonnable, que ferons-nous de la décision lorsque nous achèterons l'industrie? Il était initialement prévu que les deux solutions vivront en parallèle: dans la "grande" DG, il y aura des modèles de données, un glossaire, un modèle de rôle et dg_light laissera des puces complexes qui ne sont pas faciles à mettre en œuvre dans une solution en boîte comme la lignée de données. Ce qui se passera à l'avenir montrera l'expérience d'utilisation.

Modèle de données

Physique . Tout a commencé avec la construction d'un modèle de données d'entrepôt. Nous avons longtemps discuté de la manière de créer une couche de stockage détaillée et décidé que nous ne prendrions pas en compte un concept prêt à l'emploi, mais que nous allions combiner Data Vault 2.0 et Anchor (6NF). Encore une fois, parce que les sources de données dont nous disposons sont très différentes. D'une part, il s'agit de SAP, qui dans les profondeurs est quelque part OLAP, et quelque part OLTP, et une logique métier qui vit selon ses propres lois et nécessite un maximum de détails. D'un autre côté, ils vivent une vie mouvementée du système de contrôle des processus de fabrication (MES), dans lequel les flux de données et les historiques de valeurs-clés circulent tout le temps.

La combinaison de hubs, de satellites, de liaisons DV2.0 et la granularité maximale d'Ankor ont permis de marier tout cela en un seul endroit. Oui, l'écriture manuelle de requêtes dans un tel système sera difficile, mais tout son contenu est correct. Et nous pouvons garantir l'intégrité du système, même si tout autour de nous commence soudainement à changer ou à s'effondrer.

Logiques. Après avoir résolu le problème de l'organisation de l'architecture au niveau physique, nous sommes passés à sa description logique. Et notre discussion avec des collègues est passée à un plan philosophique dans le but de déterminer par nous-mêmes ce qu'est l'essence et comment ils se rapportent les uns aux autres. Après avoir discuté pendant un moment, ils se sont tournés vers DAMA-DMBOK, en ont retiré les définitions et les ont appliquées à leur contexte. En conséquence, il s'est avéré que les entités sont des noms avec lesquels nous opérons dans le cadre de SIBUR, ayant une valeur commerciale complète et répondant à un certain nombre de questions. Il existe toujours un débat sur l'opportunité d'inclure ou non les agrégats et les rapports dans les entités. Chaque architecte a sa propre opinion, ses propres calculs, et maintenant nous essayons de porter nos réflexions sur un dénominateur commun. C'est l'une des tâches que nous devons résoudre, y compris les personnes que nous recherchons en équipe.

Mais le modèle logique n'est pas tout. De plus, sur sa base, nous avons également construit le modèle conceptuel dont la direction a besoin pour comprendre ce qui se passe. Le modèle logique pour eux est trop détaillé, nous avons donc tout regroupé en domaines de données qui s'intègrent bien dans les processus métier décrits dans l'entreprise. Maintenant, nous essayons de négocier avec le bureau des processus afin de lier chacun de ces groupes d'entités logiques aux processus dans ARIS.

Plus loin, nous sommes allés plus loin et encore plus haut: nous avons créé un modèle de données logique unique, où nous entrons les entités logiques de chaque système, tout en indiquant les systèmes sources en indiquant la relation des systèmes les uns avec les autres.

Nous exportons ces connaissances aux architectes d'entreprise dans Sparx Enterprise Architect, ils en ont besoin pour lier des entités aux flux d'intégration et aux interfaces.
Une telle organisation de l'architecture de données aidera les personnes qui envisagent de s'engager dans l'analyse d'impact à l'avenir, à partir de là, il sera possible de construire une lignée de données à part entière. En général, nous nous attendons à ce que la solution soit utilisée non seulement par des architectes de tous horizons, mais aussi par des personnes de l'analyse dans les unités commerciales, des scientifiques des données et tous ceux qui sont en quelque sorte connectés à l'analyse.

Maintenant, nous sommes confrontés à une tâche plus laborieuse - comment apprendre aux employés à utiliser tout cela.

Personnes et données

Nos plans mondiaux sont de faire de SIBUR une entreprise basée sur les données, quand tout employé peut analyser quelque chose. Nous avons divisé la stratégie générale en trois parties: les personnes, les processus et les outils. Avec les outils, pourrait-on dire, ils ont décidé du problème, ont fait leur plate-forme avec des données. Maintenant, nous avons besoin que les gens commencent à l'utiliser.

La caractéristique principale est la mentalité des employés. Ils travaillent dans une industrie pétrochimique dangereuse, où la sécurité est écrite pour tous ceux dont le sang est écrit. Et les gens sont formés pour suivre strictement les instructions, c'est littéralement imprimé sur le sous-cortex. Un tel état est fortement contraire à la libre pensée de l'analyste.

Nous avons commencé petit: sevrer progressivement les employés pour faire des présentations à toute occasion plus ou moins importante et les transférer sur des tableaux de bord. Les personnes de l'entreprise étant responsables et exécutives, elles essaient de faire une présentation toute faite et de dessiner tout de même dans une version interactive. Mais les tableaux de bord vivent selon des lois différentes, et pour une personne, il s'agit d'un niveau de coûts de main-d'œuvre complètement différent, il est nécessaire de charger l'historique complet des données et de le vérifier. Les données sont automatiquement calculées et non manipulées - vous ne les modifierez pas avec vos mains à moins de les avoir configurées correctement au départ.

En fait, toute automatisation des processus internes se termine par un tas de courrier Excel +. Et transplanter des gens avec Excel est une tâche presque impossible. Eh bien, pourquoi avons-nous besoin de Python et SQL, car dans Excel, vous pouvez tout faire! Et c'est assez difficile à gérer.

Dans les versions précédentes du système de gestion des données dans SIBUR, il y avait une chose comme le propriétaire de l'archive d'informations - un employé qui donne accès aux données et sait où quel numéro est correct. Cette approche a créé les obstacles dont j'ai parlé plus haut. Pour les briser, nous avons profité des «meilleures pratiques» de Gartner et identifié séparément un conservateur de données et un responsable de la qualité des données.

Un conservateur de données est un gestionnaire au niveau du directeur de la division qui détermine les règles selon lesquelles il est prêt à donner accès aux données. Le responsable de la qualité des données travaille directement avec les informations elles-mêmes et sait quel chiffre est correct. Nous nous efforçons désormais de faire en sorte que pour chaque chiffre il y ait une personne responsable de la qualité qui répondra aux demandes des collègues en cas d'erreur ou d'inexactitude. Déjà, nous divisons les données en informations accessibles à tous au sein de l'entreprise, informations disponibles au sein d'une unité particulière et informations représentant des secrets commerciaux.

Et si un gestionnaire souhaite fermer des données spécifiques, nous menons des négociations de navette et expliquons comment la fermeture des informations affectera les autres unités travaillant directement ou indirectement avec elles. Ainsi, le pourcentage de données ouvertes au sein de l'entreprise a été radicalement révisé. Selon les normes de SIBUR, il s'agit d'une véritable révolution.

Conclusion

Nous avons un outil prêt à l'emploi, mais jusqu'à présent, très peu de gens peuvent l'utiliser. Et nous les éduquons. Le processus s'est sensiblement accéléré après que nous ayons construit le processus de formation des fans, lorsque chaque employé que nous avons formé assume la responsabilité de la formation suivante. Nous avons choisi de former nos propres employés au lieu d'embaucher des analystes, car dans notre cas, il est plus facile d'enseigner les dieux des macros SQL et Python qu'à de formidables analystes pour expliquer la pyrolyse et ses fonctionnalités. Et regardez leurs visages en même temps.

La façon dont nous attirons les gens et les motivons à étudier est une histoire digne d'un article séparé.

En plus de former des analystes internes, nous recherchons également des architectes, des personnes connaissant bien la gestion des données. Il s'agit d'une nouvelle direction non seulement pour la Russie, mais aussi pour le monde dans son ensemble, et les gens continuent d'interpréter le concept d'architecture de données selon lequel. Il existe des histoires compréhensibles avec l'analyse commerciale, l'analyse des systèmes, l'architecture d'entreprise.

Chez SIBUR, nous définissons l'architecture des données comme une discipline à la jonction des éléments du système avec les bases de données et les processus liés aux entreprises. Une personne doit comprendre comment l'organisation dans laquelle elle travaille est organisée et comment les processus laissent des données les concernant dans différents systèmes. Et comment connecter le premier au second.