ERP: Una historia real de boicot en los datos

La necesidad de tener un sistema de auditoría y control de datos en un ERP es evidente. Para justificarlo, pretendo contaros una historia real (aunque tenga un cierto aire de novela de espionaje), con solo unos ligeros cambios para proteger la privacidad de los afectados. Aviso que es larga, pero creo que es suficientemente atractiva por los hechos que se narran. No puedo recordar evidentemente todos los detalles de cada conversación ni los tiempos entre los sucesos, pero es seguro que la historia refleja los acontecimientos tal y como han pasado. Lo más sorprendente de ella es su dilatación en el tiempo, y las fases por las que pasó de actividad e inactividad.

Comienza la historia así …

Hace aproximadamente 12 años, un cliente llegó a las oficinas donde trabajábamos para expresarnos una queja acerca de su descontento hacia el ERP. Sí es cierto que su implantación requirió más tiempo del habitual (3 años atrás), aunque nada anormal, debido a una cierta complejidad en su fabricación, productos muy distintos que requerían configuraciones totalmente distintas y demasiados cambios sobre la marcha. Esa dilatada y compleja implantación, de alguna forma había predispuesto a usuarios en contra del proyecto, que finalmente derivó en una programación a medida, fuera de los estándares que teníamos en la época. Todos sabemos que el terreno del software a medida suele conllevar más inconvenientes que ventajas en el caso de los ERP.

Cuando esperábamos que nos trasmitiera el descontento tal y como he indicado, nos sorprendió con una queja un poco «absurda» desde nuestro punto de vista: ‘El ERP hace cosas raras, se borran asientos contables solos’. Tratamos de explicarle que en la aplicación, por aquel entonces no había nada programado con respecto al borrado de asientos que no fuera el borrado manual por el usuario, y que por tanto, no había ningún proceso ni en la aplicación, ni en base de datos, que hiciese un borrado de estas características. Aun así, por no contrariar demasiado al cliente, le comentamos que se revisaría en profundidad aplicación y base de datos, pues podría haber algún tipo de deterioro de la base de datos que produjese ese efecto.

Se procedió a revisar aplicación y base de datos, y no encontrándose nada anormal, se informó al cliente que seguiríamos tratando de localizar el error, pero que en principio siguiera trabajando con normalidad, observando los datos con precaución y realizando la copia de seguridad diaria (se pasó a dos copias diarias en ese momento).

Al cabo de varios meses, yo diría que un año mínimo, el tono del cliente cambió. La queja se había convertido en algo de un tono mayor. El error era más grave ahora (no es que antes no lo fuera): las órdenes de fabricación desaparecían aleatoriamente, otras órdenes no se correspondían con los pedidos ingresados en el sistema, los precios de los pedidos se cambiaban solos, etc. Este cúmulo de errores, alguno de los cuales podría ser efectivamente del ERP, y otros técnicamente imposibles, pensando que fueran de la propia operativa del ERP o por error de los usuarios, nos llevó a establecer ciertos controles para evitarlos.

PhotoXpress

Volvió a pasar un tiempo, tampoco sabría cuantificar, pero muchos meses, y ahora el problema surgía, ya no en esos procesos, sino en otros: cambios en los consumos de escandallo, variación de precios de materias primas, facturas que no cuadraban con contabilidad, etc. Por supuesto con la indignación lógica del cliente.

Fue por primera vez que nos llevó a pensar en acciones deliberadas de algún o algunos usuarios. En aquel entonces, los niveles de acceso de la aplicación eran bastante «escuetos» por nuestra parte, además, nuestro cliente no había hecho una gestión de los perfiles de usuario, si bien es cierto que tampoco daba mucho juego éstos pues se encontraban francamente limitados. Es el primer momento que se habla al cliente claramente de fallos posiblemente intencionados, pero siempre teníamos que mencionarlo con mucha cautela, porque quedaba la puerta abierta a errores nuestros, por supuesto (para eso los informáticos son los que más se equivocan en este mundo, ¿no?).

El cliente barajó entonces la posibilidad de que se estuviera boicoteando datos desde accesos externos malintencionados a la propia instalación por algún operario descontento, coincidiendo con algún despido meses atrás, aunque a nosotros no nos cuadraba, porque el problema venía de bastante más atrás.

En este punto, les recomendamos-obligamos a establecer perfiles de usuarios, a no intercambiar los usuarios y contraseñas, cosa que habían hecho hasta entonces, y nosotros, a establecer, con absoluto secreto, encriptación de contraseñas a varios niveles (usuarios, empresas, etc.) y controles de auditoría (accesos a cada opción de menú, hora, usuario y nivel de acceso) de los cuales solo estaban informados gerencia y el responsable de administración.

Una vez realizada estas modificaciones y controles, todo pareció calmarse y no volvió a suceder ningún problema ni error… hasta 2 años después.

Los controles que se pusieron comenzaron a evidenciar a un usuario, pero tuvimos un fallo, ¡la auditoría no contenía la dirección IP! (Realmente no fue un error sino que la mayoría de usuarios accedían por Terminal Server, por lo que la IP no habría dado ninguna información, así que no se controló). Cuando se informa al cliente del usuario al que nos apuntaba la auditoría, éste nos indica que eso era literalmente imposible, que esa persona es de total y absoluta confianza, mayor incluso que de algunos responsables de área. Fue incluso una ofensa por nuestra parte, tal era el grado de implicación con esa persona. Tuvimos que transformar el mensaje, ‘La auditoría apunta a un usuario, no a una persona’, es decir, otra persona puede estar accediendo con un usuario distinto al suyo.

Esto nos dejaba de alguna forma en evidencia, porque todos los esfuerzos que se habían realizado, parecían no conducir a obtener el resultado que esperaba nuestro cliente.

Lo que sucedió durante los siguientes años no puedo contarlo porque escapaban del ámbito del ERP (excepto que añadimos IP, algún control de cambios y de bajas, etc.), y además, lo desconozco, pero supuso un gran esfuerzo personal y económico por parte de nuestro cliente, así como nuestro, pues no todas las acciones se pudieron facturar debido a las dudas generadas, y aparte del sentido de responsabilidad / culpabilidad que nos afectaba enormemente, y con el consiguiente desprestigio que sufría nuestra organización en cuanto a credibilidad.

Todas esas acciones internas y externas al ERP, ninguna condujo a nada claro, y el tema se olvidó durante aproximadamente 3-4 años, sobretodo porque no aconteció nada de interés.

Pasado ese tiempo, «el señor topo» se volvió a activar, y en unas semanas comenzamos a tener nuevos registros de acciones similares a las pasadas (aunque ahora con más datos, incluidos la IP),  por lo que parecía corroborar que nuestro dardo fue certero. La mayor parte de los operarios fueron rotando, reduciendo también las posibilidades. Asimismo, se cotejó nuestros datos con otros datos presenciales, y parecían corroborar finalmente lo que ya se había anticipado.

Nuestro cliente, terminó por aceptar los datos, que ya eran totalmente objetivos, lo que nos afianzó en nuestra mutua relación. Finalmente, tomó las decisiones que ya podéis imaginar con respecto al operario.

Hoy día, cualquier ERP que se precie tiene un módulo de auditoría, pero eso es otra historia que ya os conté en el siguiente artículo ‘ERP: niveles de seguridad y auditoría de datos’.

Os invito a participar en los comentarios si habéis tenido experiencias similares.

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email