Construyendo una empresa de ensueño: gestión de la calidad de los datos

Se considera que el error más costoso de la historia, causado por datos iniciales incorrectos, fue el accidente del cohete Ariane 5. El daño total resultante de este incidente se estima en $ 500 millones a precios de principios de 1996.



Otro, quizás el más curioso, fue el error en el enorme pedido de los ferrocarriles franceses SNCF por 2 mil trenes en 2014. El equipo que formó los requisitos técnicos midió personalmente las dimensiones de las plataformas en varias docenas de estaciones. Queriendo aumentar la comodidad, fijaron el ancho de las composiciones al máximo. Llevaron a cabo mediciones en las cercanías de París, y que en las regiones en muchas estaciones las plataformas están más cerca de las vías, ya aprendieron durante las pruebas. El precio de un error es la modernización de toda la infraestructura por cientos de millones de euros. Estarían allí MDM con las características de las estaciones ...



imagen



A esto le sigue una gran cantidad de errores bancarios y cambiarios, cuando los datos incorrectos en los detalles, en los números y el valor de las acciones que se colocan llevaron a miles de millones de dólares en pérdidas o incluso a la quiebra.



Este artículo es la continuación del artículo " Datos maestros e integración " y, con más detalle, trata el tema del control de calidad de los datos, principalmente los datos maestros. El artículo será de especial interés para los ejecutivos de TI, arquitectos, integradores, así como para todos los que trabajan en empresas bastante grandes.



Contenido



1. Diccionario, tipos de datos comerciales: datos maestros, información de referencia regulatoria, datos operativos.

2. Brevemente sobre qué son los errores.

3. Arquitectura de soluciones DQS.

4. Métodos técnicos y no técnicos para hacer frente a los errores:

4.1. NSI.

4.2. Datos maestros.

4.3. Sistema operativo.

5. Qué hacer cuando nada de lo anterior ha ayudado: implementar DQS.

6. ¿Y cómo compartir la responsabilidad?



Si ya está familiarizado con la terminología y los problemas, pase directamente a la Parte 3, sobre la arquitectura DQS.



1. Diccionario, tipos de datos comerciales



Desde hace un par de décadas, los evangelistas de TI nos han convencido de que los datos son el nuevo petróleo. Que cualquier negocio depende cada vez más de la información que posee. Los departamentos de análisis y datos aparecen no solo en las empresas de TI, sino también en los sectores industriales e industriales en la medida de lo posible de la "figura".



Muchas personas ya se han molestado con el ejemplo de cómo General Electric y Boeing crean subsidiarias "digitales" y ganan con la enorme cantidad de información recopilada de los propietarios de sus equipos: aviones, turbinas, centrales eléctricas. Estos datos les permiten aumentar la confiabilidad del equipo, predecir posibles fallas, ahorrar mucho en daños potenciales y, finalmente, ¡simplemente salvar la vida de las personas!



Los datos son cada vez más y su acumulación no depende linealmente del crecimiento empresarial, el crecimiento está superando. Cualquier empresa en crecimiento en una determinada etapa de su desarrollo (aproximadamente en el nivel 6-7 en la escala del artículo anterior ) enfrenta problemas con datos incorrectos, y siempre hay varios casos en los que el costo de estos errores resulta ser bastante alto.



imagen

La imagen tradicional del crecimiento de los datos es casi siempre exponencial.



En el curso del negocio, tres tipos de datos son de particular importancia para la empresa:



  • - — , , . , ( : , , ), , , ..;
  • - () — -, . , : () , , , ;
  • datos operativos (también conocidos como transaccionales) : el hecho de la venta de un producto específico a un cliente específico, facturas y actos, cursos tomados, pedidos de mensajería y viajes en taxi, dependiendo de lo que esté haciendo su empresa.


Si NSI se puede comparar con un esqueleto de soporte, datos maestros con venas y arterias, entonces el sistema operativo es la sangre que corre por estas venas.



La diferenciación de los tipos de datos comerciales es necesaria por la razón de que cada uno tendrá su propio enfoque para trabajar en los errores, sobre esto a continuación.



imagen



2. Brevemente sobre qué son los errores



Los errores son inevitables, surgen siempre y en todas partes y, aparentemente, reflejan la naturaleza caótica del propio universo. Puedes considerarlos algo malo, enojarte por ellos, pero piénsalo: ¡los errores están en el corazón de la evolución! Sí, cada especie siguiente es la anterior con varios errores aleatorios en el ADN, solo las consecuencias de estos errores resultaron ser útiles bajo ciertas condiciones.


Los principales tipos de errores que sufre una empresa:



  • Factor humano. Errores tipográficos de todo tipo, campos confusos e información fuera de lugar. Acciones y pasos olvidados o perdidos accidentalmente al ingresarlo (¿también tiene 50 campos en su tarjeta de cliente?) Estáticamente, este es el tipo de error más probable, por lo que la frecuencia y el efecto de los mismos pueden llegar a ser los mayores. Afortunadamente, se ha inventado la mayor cantidad de métodos para combatirlos;
  • . , , . , — , . , , . … , , ? , , , CRM : ! !
  • errores deliberados. El empleado se transfirió deliberadamente varios millones a sí mismo y desapareció. Este es, por supuesto, un ejemplo extremo, un crimen, pero hay muchos pasos en el camino hacia él. Por ejemplo, a uno de los clientes de CRM se le asigna un descuento inmerecidamente alto o el costo del artículo se establece por debajo del precio de costo.


Y si el tercero es el tema del servicio de seguridad de la información, tiene sus propios métodos, entonces trabajaremos de manera sustantiva con el factor humano y la incompletitud.



3. Arquitectura de las soluciones DQS



DQM: gestión de la calidad de los datos, gestión de la calidad de los datos.

DQS - sistema de calidad de datos, sistema de [gestión] de calidad de datos.


Antes de hablar directamente sobre los sistemas de gestión de la calidad de los datos (DQS no es tanto un software específico como un enfoque para trabajar con datos), describiré la arquitectura de TI.



Por lo general, cuando surge el problema de la gestión de la calidad de los datos, el panorama de TI es el siguiente:



imagen

(diagrama del artículo anterior)



Donde MDM es un sistema para mantener datos maestros y regulaciones, y ESB es un bus de datos empresarial único. Una situación frecuente es cuando no todos los flujos de datos e información entre sistemas todavía están involucrados en un bucle común y algunos sistemas se comunican directamente entre sí; esto deberá resolverse, de lo contrario, varios procesos serán un "punto ciego" para DQS.



Tradicionalmente, en la primera etapa, DQS está conectado al sistema MDM, ya que la gestión de la calidad de los datos maestros se considera una prioridad más alta que el sistema operativo. Sin embargo, en el futuro, se incluye en el bus de datos común como una de las etapas de los procesos, o presenta sus "servicios" en formato API. En cifras concretas, hay una diferencia de aproximadamente diez veces en la cantidad de datos entre el primer y el segundo esquema, o un nivel en la escala del artículo anterior.



4. Métodos técnicos y no técnicos para hacer frente a los errores.



La siguiente oración contendrá el pensamiento más triste de este artículo. No hay bala de plata. No existe tal botón o sistema que usted coloque y los errores desaparecerán. En general, no existe una solución simple e inequívoca para este complejo problema. Lo que funciona muy bien para una vista o conjunto de datos será inútil para otra.



Sin embargo, la buena noticia es que el conjunto de métodos técnicos y organizativos descritos en este artículo a continuación reducirá drásticamente los errores. Las empresas que implementan el enfoque DQM reducen el número de errores detectados entre 50 y 500 veces. La cifra específica es el resultado de un equilibrio razonable entre efecto, coste y usabilidad.



4.1. Informacion de referencia.



En el caso de la información normativa y de referencia (de hecho, clasificadores estatales), existe una solución máximamente categórica y es universal: ¡no tiene que mantener los documentos normativos usted mismo! ¡Nunca, bajo ninguna circunstancia!



El estándar debe cargarse siempre y estrictamente desde fuentes externas, y su tarea principal es implementar dicha carga y establecer un monitoreo operativo en caso de fallas.



#1. . : ( ), ( ), ( ).



, , ( - ) . , — ( ).



, : . - , . , . , , … .



( — ), (), (), (), , ( ) — API , .


Como resultado de estas medidas, nadie en su empresa debería pensar en ingresar, por ejemplo, el tipo de cambio dólar / rublo de ayer manualmente. Solo una selección de guías descargadas de fuentes oficiales.



imagen



La naturaleza categórica de este punto se debe al hecho de que su implementación elimina casi todos los errores en la norma. Y si los errores en los datos maestros no se pueden superar por completo, entonces en el NSI de esta manera es posible reducir el número de errores a uno o dos por año, y estos ya no serán sus errores, sino errores en los datos estatales.



4.2. Datos maestros



La estrategia principal para los datos maestros puede parecer paradójica: ¡conviértala en normativa!



#2. — , ( 5-6 — , ).



MDM, : , . — .



, . . . (, , ) — (). — . -, (, -). , , .



, . , .
#3. , . , , . , , .



- . ? — . . : . , .



Una continuación natural de esta historia será un flujo de documentos de personal electrónico: un libro de trabajo electrónico, licencia electrónica por enfermedad, etc., que ahorrará significativamente los costos laborales de los oficiales de personal. En el límite, esto permitirá que un oficial de personal atienda no a 200-300 empleados, sino a más de 1000.



Además, todos los empleados reciben automáticamente claves de firma electrónica y podrán utilizarlas tanto en los procesos comerciales internos como en la gestión de documentos con los clientes.



Información sobre deudas, condenas, etc. disponible en forma abierta a través de API acc. servicios gubernamentales, la integración con ellos es sumamente sencilla y permitirá a su empresa cerrar una gran cantidad de riesgos a la vez.


4.3. Sistema operativo



Ya hay más enfoques aquí. El primero es similar al anterior: para conectar fuentes externas de información.



#4. — , — , — — . - ? .



. . , — , . , , .. .



— -. , . ( , !)



(, ).



, - - ? ( , ) — . , -, , .
#5. : , .



— , , -, ( , ). -, API , . — , . .. , .


Sí, no en todos los procesos será posible encontrar rápidamente las fuentes de información necesarias, se requerirá búsqueda y análisis. Además, las fuentes pueden resultar pagadas y luego se sopesan los pros y los contras, pero el enfoque está funcionando y se ha probado repetidamente en la práctica.



La información (datos) es un aceite nuevo, y todos los estados se esfuerzan por obtener la mayor cantidad posible de información sobre sus sujetos, incluidos los negocios, sobre todos los procesos en los que participan.



Incluso es difícil para nosotros imaginar qué información recopila el estado, solo puedo decir que en el momento de escribir este artículo, se presentan alrededor de 20 mil conjuntos de datos en el portal de datos abiertos de Rusia. Y Rusia está solo al comienzo de este camino, por lo que, en un portal similar de la Unión Europea, ¡hay más de un millón de conjuntos de datos abiertos disponibles!



imagen

www.europeandataportal.eu/en



- ¿Dónde está DQS aquí? - preguntará un lector atento.



Y todavía no había nada sobre ella.



Todos los anteriores son, de hecho, herramientas y métodos estándar para organizar procesos comerciales con un número mínimo de errores.



5. Qué hacer cuando nada de lo anterior ha ayudado: implementar DQS



Sun Tzu enseña que la mejor batalla es la que se evita.


La situación con la implementación de DQS es algo similar.



Su tarea es tratar de maximizar la transformación de datos maestros e incluso sistemas operativos en datos de referencia, y en algunas industrias, especialmente en el sector de servicios, esto es casi 100% posible. Sobre todo en el sector bancario, por lo tanto, el grado de automatización de los procesos comerciales en él es mucho mayor que el de muchos otros.



Sin embargo, si no se puede evitar la batalla, debe prepararse para ella lo mejor posible.



¿A qué nivel de desarrollo empresarial debería introducirse DQS? Como proceso DQM - por 4-5 (¡antes que los sistemas MDM!), Como función dedicada organizacionalmente - en 7-8.



5.1. DQM como proceso



Si su empresa tiene un sistema de contabilidad o de personal, entonces tendrá un proceso DQM de alguna forma. Todos estos sistemas tienen un conjunto integrado de reglas para los datos de entrada. Por ejemplo, el formato obligatorio y estricto de la fecha de nacimiento del empleado, el nombre obligatorio de las contrapartes.



Su tarea en esta etapa será construir el proceso DQM. El es el siguiente:



  • inventa una regla;
  • probar la aplicabilidad y adecuación de la regla, probarla en los casos;
  • desarrollar regulaciones para la aplicación de la regla, comunicarse con los usuarios, justificar;
  • implementar en producción;
  • El monitor intenta eludir la regla.


Si ha logrado implementar MDM en la empresa, entonces los puntos a partir del segundo en adelante no deberían causarle ninguna dificultad especial, este es el trabajo sistemático actual.



Las mayores dificultades en este caso surgen con la creación de nuevas reglas.



5.2. reglas



Si para una entidad como un nombre completo, su imaginación se limita al nombre y apellido obligatorios, y para una fecha, para verificar "no más de cien años", ¡no se desanime!



Existe una gran técnica para desarrollar nuevas reglas para probar los datos más inimaginables. Para dominarlo, no necesita tener siete pulgadas en la frente y, como muestra la práctica, cualquier sistema novato o analista de negocios, incluso los operadores que ingresan datos maestros, pueden dominarlo.



De hecho, este es un script paso a paso, que en la entrada tiene la definición de sus datos, y en la salida, un conjunto de reglas para todas las ocasiones. La técnica, conocida como taxonomía de datos sucios, fue desarrollada por un grupo de científicos de datos europeos a principios del siglo XXI.



La esencia del enfoque, así como los ejemplos prácticos, se dan en el artículo de su sistema, afortunadamente ya publicado en traducción aquí en Habré - habr.com/ru/post/548164



Si el problema de la calidad de los datos no es una frase vacía para usted , luego, después de una lectura atenta del artículo, se encontrará en un estado cercano a alcanzar el nirvana :)



Ejemplo # 6 . Escritura fuerte. Si se utiliza el tipo de datos "fecha" en la referencia, la estructura de la fecha debe ser lo más explícita posible. Si decidió ahorrar dos segundos para los operadores e hizo una plantilla como "__.__.__" con una pista "día, mes, año", asegúrese de que el primer día los registros "18.04.21", " 21.04.18 ”y“ 04.18.21 ”.


Una buena forma de ingresar una fecha son tres campos con una designación explícita (día, mes, año) y un salto rápido al ingresar dos números en cada uno de los campos. Si alguna vez pagó algo con una tarjeta en Internet, lo comprenderá.



Ejemplo # 7 . Caracteres prohibidos en la lista de campos más amplia posible, comprobaciones de diccionario. Por ejemplo, si estamos hablando de educación (puesto) y los clasificadores de especialidades no ayudaron, permite que el usuario ingrese datos en el campo de texto, incluso si los puntos, las comillas y los guiones independientes están prohibidos allí ( la lista no está completa). Un ejemplo de información cuya calidad va en aumento: “Doctor en Ciencias Técnicas”, “Doctor en Ciencias Técnicas”, “DTN”, “Dr. ciencias ”, etc.




#8. (NULL) — . , / , / — , . — “ ”.



, , . , “”, “”, “”, “” ( .) , , . (“ ”, “, ”) (“ ”, “-”, “ ”). — . , , “” “” — , — . “”, “”…



, , . , , , .


6. DQS?



En materia de gestión y responsabilidad, no hay respuestas correctas, sino que todo depende de equipos e individuos específicos. Un ingeniero de cohetes puede ser un contador jefe, un artista puede ser un director de finanzas y un maestro de escuela primaria puede ser un jefe de seguridad.



La pregunta sobre la responsabilidad del proceso DQM es en realidad aún más general: ¿ quién es responsable de la calidad de los datos en la empresa? Tradicionalmente, los usuarios empresariales y el departamento de TI actúan como antagonistas para responder a esta pregunta.



Las empresas a menudo inician un diálogo con la afirmación "notamos un error en su sistema de datos meteorológicos".



El servicio de TI, por otro lado, cree que su tarea es garantizar el buen funcionamiento de los sistemas, y qué datos específicos ingresan los usuarios comerciales en el sistema es responsabilidad comercial.



Establecer un proceso DQM funcional y ejecutar DQS es un compromiso que satisface a ambas partes. El desafío para TI y los analistas es desarrollar tantas reglas y restricciones como sea posible en la entrada de datos para minimizar el riesgo de error.



La actitud “empresarial” suele ser causada por una falta de transparencia en los procesos de DQM. Sin embargo, si lo reduce a una demostración clara del error, la posición se suaviza. Y puede llegar a un acuerdo en el caso de demostrar las consecuencias a quien ingresa los datos primarios.



Un ejemplo sorprendente de motivación e incluso visualización de las consecuencias de los errores se da en el artículo habr.com/ru/post/347838 ; en este ejemplo, un servicio de TI con competencias avanzadas en análisis de negocios es responsable del proceso de DQM. Además, las competencias de DQM en sí no son difíciles y cualquier analista puede desarrollarlas en un par de meses.



Otro ejemplo, interesante porque el proceso DQM también incluye la gestión de la calidad del proceso empresarial, se da en el artículo habr.com/ru/company/otus/blog/526174 .



Resultados



Las conclusiones generales de este artículo son paradójicas.



Si a su empresa se le ha preguntado "quién es el responsable de la calidad de los datos", ha caído en una trampa. No hay una respuesta correcta, tk. la pregunta en sí es incorrecta. Si intenta seguir este camino, eventualmente se dará cuenta de que la única respuesta adecuada a esta pregunta ("todo") no le dará nada en la práctica.



El enfoque correcto es dividir la pregunta en dos bloques.



El primero es construir DQM como un proceso, implementar DQS, formar reglas (no de forma ad hoc, sino como un proceso continuo). Esta unidad vive donde las funciones de análisis son sólidas, generalmente en TI, pero no necesariamente.



El segundo bloque, la entrada de los datos primarios en sí, es el lugar donde se toman las decisiones sobre datos específicos, pero no al azar, sino sobre la base de todas las reglas. Por lo tanto, la implementación de DQS es un paso importante hacia una empresa impulsada por datos.



¡Te invito a la discusión!



All Articles