🥘 💱 🦖 Características de los datos en petroquímicos ✌🏿 🍔 📫

Al crear cualquier negocio, cada una de sus divisiones se automatiza. Como regla, los flujos de datos de extremo a extremo entre ellos son únicos. Esto lleva al hecho de que los datos no se pueden comparar entre sí, porque cada departamento los considera a su manera. No hay problema si recopila algunas métricas para toda la empresa, pero cuando se trata de calcular indicadores de extremo a extremo, pronósticos o resolver problemas de modelado y optimización, comienza el caos.

Data Warehousing (DWH) no es una historia nueva. Tradicionalmente, se han utilizado para informar. Pero el modelado completo y el pronóstico de los procesos comerciales de extremo a extremo en los datos DWH comenzaron relativamente recientemente. Utilizando los datos recopilados, las herramientas de análisis modernas hacen posible no solo crear paneles con ventanas desplegables, sino también configurar algoritmos de pronóstico y optimización para cada atributo, para escalar algoritmos de teoría de juegos para toda la empresa en su conjunto. Y también construya y pruebe de inmediato hipótesis sobre el desarrollo posterior del negocio con datos reales.

Y parece que todo suena genial. Pero no todas las empresas tienen prisa por tomar el ejemplo de los principales expertos (Booking.com, Amazon.com) y seguir trabajando como de costumbre. Entonces, ¿qué los detiene? Como mínimo, comprender la viabilidad de inversiones a gran escala en herramientas de procesamiento de datos, la laboriosidad de implementar procesos de descripción de datos, la aparición de nuevos roles (curadores de datos responsables de la calidad de los datos, ingenieros y arquitectos de datos, etc.), aprender cómo considerar el efecto económico de implementar la gestión de datos , aísle claramente los factores que impulsan los costos, cómo hacer que la oficina sea autosuficiente, conciliar con la estrategia de la empresa y elegir los que harán que la empresa avance, y mucho más.

Mi nombre es Victoria Krasnova, soy la directora de la gestión de datos corporativos de SIBUR. Junto con mi colega, el líder del equipo de Gobierno de datos, Rinat Abdurakhmanov, le diremos cómo lo hacemos.

Cuando los grandes minoristas (Wallmart) comenzaron a digitalizar, tuvieron que averiguar qué huellas digitales y artefactos deja un proceso comercial y qué le resta al siguiente. Es decir, describa el proceso comercial de extremo a extremo. Lo mismo se requiere para la digitalización de cualquier otra empresa. Una forma de responder a esta solicitud es el concepto de gestión de datos y arquitectura de datos.

En un sentido aplicado, esto significa: reunir los datos de la empresa más importantes y no muy importantes en un solo lugar, describirlos en un lenguaje claro, vincularlos a los procesos comerciales y crear métodos de acceso fáciles de usar para estos datos.

La arquitectura de datos, entre sus otras funciones, proporciona respuestas claras a las preguntas “¿dónde se considera?”, “¿Qué se considera?”, “¿Por qué se considera?”, “¿Quién es responsable de la calidad?” y "¿dónde está ubicado, en qué sistema está?".

Es importante que las respuestas a estas preguntas estén separadas de la empresa misma. A menudo sucede de esta manera: el analista quiere probar una hipótesis. Para hacer esto, debe ir y pedir los datos necesarios a su propietario, demostrar por qué y por qué esto es necesario e importante, dedicar medio día a esto. En el mejor de los casos. Y, finalmente, obtener un rechazo. ¿Por qué? Porque el propietario de los datos es responsable de proporcionar acceso a los datos y su posterior difusión, porque no se sabe cómo interpretará los datos el analista y puede que no le convenga, etc.

Por lo tanto, es necesario construir una estructura y una lógica que sean intuitivas, que funcionen de acuerdo con reglas uniformes y que no distraigan al analista ni al propietario de los datos de las tareas inmediatas.

Para estos fines, un modelo de datos lógico es excelente: una descripción de los datos en el lenguaje comercial que detalla los detalles técnicos, en combinación con un modelo de rol flexible. En este caso, el analista obtiene acceso al repositorio y al conjunto de datos en función de su rol en la empresa. Y recopila el conjunto de datos requeridos sobre la base del sentido común, y no sabiendo que en 2005 cierto compañero trabajó en la empresa, cuyo archivo contiene los datos requeridos.

Tal enfoque de estructuración permite a las personas analizar rápidamente, hacer que los datos sean comparables y, como resultado, permite obtener beneficios secundarios: digitalizar todo el negocio por etapas.

¿Cuáles son los desafíos que enfrentamos?

En SIBUR, algunos procesos se digitalizan bastante bien, por ejemplo, preparación de datos para marketing, finanzas, gestión de la cadena de suministro, datos de producción y derivaciones de plantas de producción. Todo lo demás es más complicado, porque SIBUR es una producción con un ciclo en el que, desde el punto de vista comercial, no hay necesidad de recopilar información a la misma velocidad que se necesita en el comercio minorista, las telecomunicaciones o los bancos. En consecuencia, tampoco se planteó la cuestión de la velocidad en el análisis de datos. Pero difícil, no significa imposible. Este año planeamos optimizar los procesos, hacer que el cálculo de datos sea más transparente, aumentar la tasa de transferencia de datos para la toma de decisiones y también comenzar a recopilar pistas digitales en todas las etapas de los procesos, cuando sea posible.

¿Por qué las empresas digitales son altamente precisas y rápidas para la toma de decisiones? Debido a que prácticamente no tienen margen para cometer un error si los datos de repente resultan ser incorrectos. En producción, todo es diferente: no se detendrá, las plantas no se mantendrán firmes si hay alguna inexactitud en los datos para el análisis. Por lo tanto, la arquitectura de datos es la fuerza que, al contrario de todo, lidera la producción en la dirección digital. Y la gestión de datos es una biblioteca que le permite optimizar el flujo de datos en toda la empresa.

Recientemente, lanzamos una línea que se ocupa de la descripción de datos. Mientras buscamos una herramienta para describir los datos, almacene y acceda cómodamente a las descripciones. Si la herramienta para la descripción es inconveniente, y debido a esto no podremos mantener la catalogación actualizada, entonces usarla ya no tendrá ningún sentido. Como resultado, los datos en sí mismos en el repositorio pueden no ser relevantes. ¿Por qué necesitamos construir algo sobre la base de datos cuya fecha de vencimiento ya ha expirado?

Aquí tenemos otra tarea más: cómo motivar a los arquitectos que acompañan a los sistemas de información existentes, describir los datos y mantenerlos actualizados. El principio de "lo construyes, lo ejecutas" es popular en las empresas digitales. Históricamente lo implementamos para que algunas personas lo presenten, pero otros lo apoyen. A menudo, la documentación no está actualizada, y algunos algoritmos viven solo en la mente de los veteranos. Por lo tanto, la descripción de los sistemas es un trabajo que lleva mucho tiempo, especialmente cuando se lleva a cabo desde cero (como en nuestro caso). De hecho, en realidad, el efecto de este trabajo les llegará mucho más tarde, solo después de describir una masa crítica de datos. Pero al final, al introducir otro nuevo sistema, no tendrán que buscar datos para potenciarlo. Ahora toma un promedio de dos semanas o más para buscar estos datos.

Se necesitan datos no solo para introducir nuevos sistemas, sino también para probar hipótesis. Por lo general, surgen mucho y se prueban en lotes. Y de hecho, resulta que hay datos, hay muchos de ellos, son diversos, pero solo se gasta mucho tiempo y dinero en su búsqueda.

Otro punto al cambiar los datos "sin previo aviso" en un lugar hace que los datos en el otro lugar se vuelvan incorrectos. Por ejemplo, el indicador "Volumen de producción" solía tener en cuenta las pérdidas en las etapas de redistribución, y luego se detuvo. Cambiaron el sistema, pero el resto no está actualizado y continúan usando el indicador como antes. Como resultado, los datos para tomar una decisión de gestión son incorrectos. O en algún momento resulta que los datos no son comparables, las personas comienzan a buscar errores. Y esto también es trabajo, solo invisible e incalculable.

En general, como comprenderá, nos hemos enfrentado a la cuestión de elegir una herramienta para trabajar con datos. Y antes de elegir un instrumento, debe escribir los criterios adecuados para tal elección.

Criterios de selección de instrumentos

Estamos buscando una herramienta que apoye la descripción de metadatos en forma de un modelo de objeto con la capacidad de agregar independientemente nuevos tipos de objetos. No todos los productos ofrecen esta característica. Por ejemplo, algunas herramientas le permiten mostrar solo tablas físicas como objetos, pero no existe una clase de objetos para entidades conceptuales o lógicas.
La configuración flexible de las conexiones entre objetos es muy importante. Por ejemplo, hoy tenemos tres niveles lógicos de abstracción, pero deberíamos estar limitados en nuestra capacidad de eliminar o agregar cualquier número de niveles.

Otro criterio importante es la presencia de conectores incorporados a los sistemas de origen, especialmente a SAP. Tenemos una gran cantidad de SAPa (creo que cualquier empresa grande, en principio, tiene una gran cantidad de SAPa): una instalación enorme, y palearla con las manos es una tarea completamente ingrata. Ideal si hay uno. Si no existe dicho conector, puede escribirlo usted mismo.

No olvidemos la búsqueda de texto completo, la búsqueda semántica con la capacidad de agregar sus propios diccionarios de sinónimos (por ejemplo, el Elasticsearch integrado).

La posibilidad de retroalimentación juega un papel importante. Además, idealmente debería existir la posibilidad de comentar, evaluar según el principio de 1-5 estrellas, comunicarse directamente con la persona responsable de la entidad o atributo de una entidad en particular, así como establecer banderas y etiquetas para llamar la atención, así como agregar objetos a Favoritos.

Además, es bueno tendría un conector nativo para SAS DQ o cualquier otra herramienta que pueda usarse para evaluar la calidad de los datos y mostrar el índice de salud de una entidad en particular, de modo que el usuario pueda ver de inmediato que los datos son confiables, ya que se procesaron con verificación. Y da tu opinión sobre esto.

En general, necesitas algo como esto:

Aquí hay un ejemplo de un caso típico para usted: una persona vio que puede confiar en los datos, miró más de cerca y encontró un error, y escribió directamente al propietario pidiéndole que lo arregle. Resulta un escaparate de salud de datos. Tal apertura y disponibilidad generalizada de datos reduce gradualmente el grado de desconfianza tanto de los usuarios como de los propietarios. Un analista con el acceso más básico a los datos puede obtener rápidamente la información necesaria que ha sido verificada y, al mismo tiempo, no depende del propietario de los datos que contribuya con esta información. Ganar-ganar

Pero generalmente todo el mundo tiene todo en Excel, y este es un gran problema (no Excel en sí, por supuesto, sino una situación así). Las personas contaron los indicadores, luego los corrigieron en su propia tableta, pero nada ha cambiado en el sistema general. Y el analista tiene miedo de tomar alguna cifra de fuentes corporativas disponibles al público, es más fácil ir a un colega y pedir un archivo. Esto es bastante difícil de manejar. De hecho, el criterio para el éxito de la implementación de una oficina de datos puede considerarse la creación de entornos en los que los empleados, como regla, confían en los resultados del análisis al tomar decisiones, y prefieren SQL y Python de las herramientas.

Por separado, vale la pena mencionar el mantenimiento del estado actual de los datos "Secreto comercial", "Datos públicos", "Datos personales", "Datos corporativos de distribución limitada". Es decir, para un analista de datos, es importante saber qué es exactamente lo que está navegando y descargando actualmente, o echar un vistazo a sus colegas.

Después de todo, cuando la persona promedio recurre a legislación relacionada con secretos comerciales e información confidencial, ve información generalizada sobre lo que puede dañar a las empresas. En casos frecuentes, comienzan a considerar como datos críticos en general todo lo que contiene números (de repente algo). En consecuencia, cuando se le pide que proporcione datos para el análisis, el propietario comienza a preguntarse: "¿es esto un secreto comercial?", "¿Solicitarán daños las acciones del solicitante?", Y, al reasegurarse, a menudo se niega. Después de todo, él es responsable de esta información y no sabe cómo la usará el analista.

Hubo otro caso: cuando estábamos trabajando en una lista de información confidencial para un proyecto de democratización de datos, resultó que esta lista contiene datos que los propietarios llaman confidenciales, y la ley nos exige que los proporcionemos en el sitio web oficial. Y, por supuesto, se publican allí. Es decir, en condiciones en las que no existe una herramienta única en la que todos puedan ver información claramente verificada a la vez, muchas personas trabajan en el modo "pase lo que pase" y están muy reaseguradas.

Entonces, esto se trata de los criterios. Pero de lo que elegimos exactamente.

Busca una solución

Decimos "elegir" porque aún no hemos elegido, todavía estamos en busca de la herramienta perfecta. Inicialmente, elegimos entre Collibra, SAS DG, Alation, Alteryx Connect e Informatica. También examinamos proyectos extranjeros de código abierto, pero los barrieron casi de inmediato, porque nadie sabe cómo trabajar con el alfabeto cirílico.

Luego hubo una experiencia infructuosa con Collibra. Casi completamos el acuerdo, pero fracasó: no estábamos de acuerdo con las condiciones. A corto plazo, se trasladarán por completo a la nube, y para cualquier empresa rusa esto no es una opción. De hecho, no proporcionarán un producto, sino un servicio: Collibra proporciona una suscripción y nosotros proporcionamos nuestros datos. Formalmente, esto no es un secreto comercial, sino metadatos, pero de hecho, si algo sale mal, el negocio quedará completamente paralizado.

Después de esta historia, nos dimos cuenta de que elegiríamos la caja durante mucho tiempo: tenemos procesos largos, abordamos cuidadosamente las transacciones, las condiciones y los contratistas, verificamos todo muchas veces para asegurarnos de que el riesgo sea mínimo. Conociendo todas estas características, iniciamos nuestro propio desarrollo para crear al menos una solución temporal para los usuarios. Después de todo, los datos se están vertiendo, ¡y es imposible usarlos sin una descripción! Paralelamente, analizamos más de cerca Alation y Alteryx Connect y comparamos su funcionalidad y costo con nuestra solución.

Nosotros inventamos el modelo lógico de almacenamiento, es un poco más complicado para nosotros aquí que para otras industrias. Por ejemplo, para bancos y telecomunicaciones, existen arquitecturas de datos de referencia, estructuras generalmente aceptadas y recomendaciones sobre qué y cómo descomponer datos. Para los productos petroquímicos, no existe un ciclo completo de fuentes para préstamos creativos en el dominio público. Solo tomó un año entender cómo funciona el negocio en general. SIBUR tiene una producción compleja, una gran cantidad de nomenclatura, procesos, negocios, que se refleja en los sistemas, lo que significa que requiere análisis.

Aquí nos ayudó que existe el llamado liderazgo intensivo en conocimiento. Por ejemplo, en otras industrias con bastante frecuencia, los gerentes y gerentes no están muy versados en la industria misma. Esto sucede, en principio, esto no es algo directamente terrible, al final, su negocio es administrar proyectos, y resulta que el enlace de cada nuevo gerente generalmente sabe un poco menos que el anterior. Pero resultó que los gerentes son personas que pueden explicarle con los dedos todos los procesos que pueden ocurrir con el butadieno a lo largo de su vida, por ejemplo.

Entonces, sobre la decisión. Una búsqueda creativa es tal que puede llevar un año, dos o un par de vidas. Por lo tanto, la búsqueda es buena, pero debe trabajar en algo ahora mismo.

Entonces, fuimos a nuestro propio desarrollo, lo llamamos dg_light. El desarrollo del frente tomó 4 semanas (para decir la verdad, no desde cero, reutilizamos los logros de la herramienta de análisis de tiempo compartido que recientemente había salido de la línea de montaje).

Composición del proyecto:

Backend: Docker, Node.js, NGINX, Crossbar.io
Frontend: React, Redux, Material UI, Highcharts, Autobahn.js
Almacenamiento de datos: PostgreSQL
Protocolos: WAMP, WebSocket, HTTP (S)
OS: CentOS 7

La estructura de las instalaciones de almacenamiento y la metodología fueron aportadas por arquitectos de datos. Para estudiar el diseño frontal, plantaron varios analistas de varios niveles de madurez y preguntaron: "¿Cómo le gustaría que fuera?" De hecho, pintaron por sí mismos.

Todo el desarrollo tomó 6 semanas.

Una pregunta razonable, ¿qué haremos con la decisión cuando compremos la industrial? Originalmente se planeó que ambas soluciones vivirían en paralelo: en la DG "grande" habrá modelos de datos, un glosario, un modelo a seguir, y dg_light dejará chips complejos que no son fáciles de implementar en una solución en caja como el linaje de datos. Lo que sucederá en el futuro mostrará la experiencia de uso.

Modelo de datos

La física . Todo comenzó con la construcción de un modelo de datos de almacén. Discutimos durante mucho tiempo acerca de cómo construir una capa de almacenamiento detallada, y decidimos que no tomaríamos un concepto listo para trabajar, sino que combinaríamos Data Vault 2.0 y Anchor (6NF). Nuevamente, porque las fuentes de datos que tenemos son muy diferentes. Por un lado, es SAP, que en lo más profundo está en algún lugar OLAP, y en algún lugar OLTP, y la lógica empresarial que se rige por sus propias leyes y requiere el máximo detalle. Por otro lado, viven una vida agitada del sistema de control del proceso de fabricación (MES), en el que los datos fluyen y las historias de valores clave fluyen todo el tiempo.

La combinación de concentradores, satélites, enlaces de DV2.0 y la granularidad máxima de Ankor permitieron unir todo esto en un solo lugar. Sí, escribir consultas manualmente en un sistema de este tipo será difícil, pero todos sus contenidos son correctos. Y podemos garantizar la integridad del sistema, incluso si todo lo que nos rodea comienza a cambiar o colapsar de repente.

Lógicas. Una vez resuelto el problema de la organización de la arquitectura a nivel físico, pasamos a su descripción lógica. Y nuestra discusión con colegas se trasladó a un plano filosófico en un intento de determinar por nosotros mismos qué es la esencia y cómo se relacionan entre sí. Después de discutir por un momento, recurrieron a DAMA-DMBOK, sacaron las definiciones y lo aplicaron a su contexto. Como resultado, resultó que las entidades son sustantivos con los que operamos en el marco de SIBUR, que tienen un valor comercial completo y responden una serie de preguntas. Todavía hay debate sobre si incluir o no agregados e informes en las entidades. Cada arquitecto tiene su propia opinión, sus propios cálculos, y ahora estamos tratando de llevar nuestros pensamientos a un denominador común. Esta es una de las tareas que tenemos que resolver, incluidas las personas que buscamos como equipo.

Pero el modelo lógico no es todo. Además, en base a esto, también creamos el modelo conceptual que la gerencia necesita para comprender lo que está sucediendo. El modelo lógico para ellos es demasiado detallado, por lo que agrupamos todo en dominios de datos que se ajustan bien a los procesos comerciales descritos en la empresa. Ahora estamos tratando de negociar con la oficina de procesos para vincular cada grupo de entidades lógicas a los procesos en ARIS.

Además, fuimos más amplios e incluso más altos: creamos un único modelo de datos lógicos, donde ingresamos las entidades lógicas de cada sistema, al tiempo que indicamos los sistemas fuente con la relación de los sistemas entre sí.

Exportamos este conocimiento a arquitectos corporativos en Sparx Enterprise Architect, que lo necesitan para vincular entidades a flujos de integración e interfaces.
Dicha organización de la arquitectura de datos ayudará a las personas que planean participar en el análisis de impacto en el futuro, a partir de ella será posible construir un linaje de datos completo. En general, esperamos que la solución sea utilizada no solo por arquitectos de todo tipo, sino también por personas de análisis en unidades de negocios, científicos de datos y todos los que de alguna manera estén conectados con el análisis.

Ahora nos enfrentamos a una tarea más laboriosa: cómo enseñar a los empleados a usar todo esto.

Personas y datos

Nuestros planes globales son hacer de SIBUR una empresa basada en datos, cuando absolutamente cualquier empleado pueda analizar algo. Dividimos la estrategia general en tres partes: sobre personas, sobre procesos y sobre herramientas. Con las herramientas, se podría decir, decidieron el problema y crearon su plataforma con datos. Ahora necesitamos personas para comenzar a usarlo.

La característica principal es la mentalidad de los empleados. Trabajan en una industria petroquímica peligrosa, donde la seguridad está escrita para todos aquellos cuya sangre está escrita. Y las personas están capacitadas para seguir estrictamente las instrucciones, literalmente está impreso en la subcorteza. Tal estado es fuertemente contrario al pensamiento libre del analista.

Comenzamos poco a poco: gradualmente destetamos a los empleados para que hagan presentaciones en cualquier ocasión más o menos significativa y los transfieran a paneles. Dado que las personas de la empresa son responsables y ejecutivas, intentan hacer una presentación preparada y dibujar de todos modos en una versión interactiva. Pero los paneles de control viven de acuerdo con diferentes leyes, y para una persona este es un nivel de costos laborales completamente diferente, es necesario cargar todo el historial de los datos y verificarlo. Los datos se calculan automáticamente y no se manipulan: no los cambiará con sus manos a menos que inicialmente los configure correctamente.

De hecho, toda la automatización de procesos internos termina con un montón de correo Excel +. Y trasplantar personas con Excel es una tarea casi imposible. Bueno, claro, ¿por qué necesitamos Python y SQL, porque en Excel puedes hacer todo! Y es bastante difícil luchar.

En versiones anteriores del sistema de gestión de datos en SIBUR existía el propietario del archivo de información: un empleado que da acceso a los datos y sabe dónde está el número correcto. Este enfoque creó las barreras sobre las que escribí anteriormente. Para romperlos, aprovechamos las "mejores prácticas" de Gartner e identificamos por separado un curador de datos y un oficial de calidad de datos.

Un curador de datos es un gerente a nivel del director de la división que determina las reglas por las cuales está listo para dar acceso a los datos. El oficial de calidad de datos trabaja directamente con la información misma y sabe qué cifra es correcta. Ahora estamos trabajando para garantizar que para cada figura haya una persona responsable de la calidad que responderá a las solicitudes de colegas en caso de error o inexactitud. Ya estamos dividiendo los datos en la información disponible para todos dentro de la empresa, la información disponible dentro de una unidad en particular y la información que representa secretos comerciales.

Y si algún gerente desea cerrar datos específicos, llevamos a cabo negociaciones de transporte y explicamos cómo el cierre de la información afectará a otras unidades que trabajen directa o indirectamente con ella. Por lo tanto, el porcentaje de datos abiertos dentro de la empresa ha sido revisado radicalmente. Según los estándares de SIBUR, esta es una verdadera revolución.

Conclusión

Tenemos una herramienta lista para usar, pero hasta ahora hay muy pocas personas que puedan usarla. Y los educamos. El proceso se aceleró notablemente después de que construimos el proceso de capacitación de fanáticos, cuando cada empleado que capacitamos asumió la responsabilidad de capacitar a los siguientes. Tomamos el camino de capacitar a nuestros propios empleados en lugar de contratar analistas, porque en nuestro caso es más fácil enseñar a los dioses de las macros SQL y Python que a analistas asombrosos explicarles sobre la pirólisis y sus características. Y mira sus caras al mismo tiempo.

Cómo atraemos a las personas y motivamos para estudiar es una historia digna de una publicación separada.

Además de educar a los analistas internos, también estamos buscando arquitectos, personas con conocimientos sobre la gestión de datos. Esta es una nueva dirección no solo para Rusia, sino también para el mundo en general, y las personas continúan interpretando el concepto de arquitectura de datos en cuanto a cuánto. Hay historias comprensibles con análisis de negocios, análisis de sistemas, arquitectura corporativa.

En SIBUR definimos la arquitectura de datos como una disciplina en la unión de piezas del sistema con bases de datos y procesos relacionados con los negocios. Una persona debe comprender cómo está organizada la organización en la que trabaja, y cómo los procesos dejan datos sobre sí mismos en diferentes sistemas. Y cómo conectar el primero con el segundo.