8 maneras de sortear [asumir] fallas

Todo profesional relacionado con las TI ha oído hablar de la ley de Murphy. Algunos creen no haberla experimentado; otros dicen no haberla experimentado; otros niegan haberla experimentado. Tal vez [aún] no se han dado cuenta.

Sabemos que un error es causa de una falla, y ambos pueden ocurrir por diferentes razones -pero, como dijo Churchill, por ni una sola excusa; y que una falla (que, dependiendo del impacto, podríamos considerar como problema), puede conducir a uno o más incidentes. Con una adecuada formación en gestión de servicios podremos determinar los ámbitos de actuación de cada uno de estos términos.

Siguiendo a Deming, luego que resolvemos la condición negativa que se presentó [y que impactó el servicio o la seguridad de la información relacionada], ¿tomamos alguna acción? ¿Evaluamos los resultados de los cambios implementados en el valor de los servicios que se entregan, y/o en la seguridad de la información? Verificar el éxito del cambio ejecutado para [al menos] mantener la calidad del servicio entregado o su seguridad es bueno pero, en adición, debemos validar que la necesidad del cambio haya sido satisfecha, desde el punto de vista de la entrega de valor del servicio (SLA, clientes) como para los stakeholder (beneficios, cumplimiento, reguladores, regulaciones, evitar demandas o pago de moras, entre otros aspectos a considerar).

La tecnología juega un papel importante en todo esto, como también lo hace la cultura [organizacional, de servicio, de calidad, de seguridad, …].

En lugar de tratar con una, digamos, oportunidad de mejora, de forma individual -y hasta aislada, ¿realmente aprendemos de esta(s) tras aplicar mecanismos sistémicos apropiados y de manera oportuna y correcta? ¿está nuestra cultura [institucional] lo suficientemente madura para esto? ¿somos realmente un referente en esto –o al menos buscamos estar en camino de serlo? ¿utilizamos herramientas apropiadas para analizar la causa raíz de las oportunidades de mejora? ¿Son estas herramientas utilizadas por colaboradores competentes? ¿Gestionamos apropiadamente el triángulo procesos-personas-tecnología? ¿Qué tan proactivos somos al respecto? ¿Están clara y completamente identificados todos los involucrados, así como los límites, restricciones, expectativas, y presiones relacionados? ¿Hay vacas sagradas o el cliente es nuestra meta, no sólo de palabra sino con acciones concretas, duela a quien le duela? ¿Entendemos que habrá efectos negativos si hacemos mal las cosas?

¿Aprendemos de los errores de los demás? A propósito de las últimas noticias sobre ransomware. ¿Están los procesos establecidos y son seguidos? ¿Tienen las evidencias necesarias –ya mismo?

¿Sabemos qué información está disponible para las personas que trabajan en resolver problemas y qué tan rápido pueden obtenerla, para que puedan desarrollar pautas claras para evitar complicar el problema debido al estrés, la confusión o la fatiga? Información contextual, oportuna, clara, correcta, vigente, y completa, así como, objetividad y enfoque en la tarea, son condiciones primordiales en estos casos.

Tal vez nos centramos en buscar culpables, primero y siempre, afectando la moral –y perdiendo tiempo valioso, sin que nos importe nuestro cliente. Evitamos, consciente (limitaciones, presiones, carencias, inexperiencia, otros) o inconscientemente (confiamos ciegamente que la acción correctiva evaluada, elegida, y llevada a cabo es la definitiva), responder a la pregunta: si asumimos que podría ocurrir nuevamente, ¿cómo responderíamos mejor esta vez? ¿Son nuestros reportes del tipo ‘lecciones aprendidas’ (en sentido positivo) o del tipo ‘post mortem’ (en sentido negativo)?

Claro, errar es humano, y las estadísticas nos dicen que el ‘error humano’ bordea el 70% como causa de accidentes de tránsito en Lima. Bueno, tenemos factores como condiciones físicas del conductor (estado de alerta/lucidez, velocidad de reacción, ingestión de elementos alucinógenos o de bebidas alcohólicas, fatiga-cansancio-somnolencia), atención a la tarea –y no al celular, a la radio, al copiloto(a), exceso de confianza, temeridad, condiciones del vehículo, velocidad, estado de las vías, [des]conocimiento del reglamento de tránsito, señalización adecuada (bueno, si ‘Pepe el vivo’ las respeta porque ‘no hay policía que me vea’ ‑cuando el policía debía estar dentro nuestro), estilos de conducta en contextos de tráfico en relación a las variables: edad cronológica; estado civil; grado de instrucción; lugar de procedencia; pertenencia del vehículo; la conducción como ocupación principal; tiempo en la conducción; accidentes de tránsito; papeletas recibidas por infracciones; problemas de salud; problemas auditivos; problemas de motricidad; problemas familiares y problemas emocionales, entre otros. Nos damos cuenta que hay fallos activos (errores y violaciones, actos inseguros que tienen un impacto directo y son cometidos por los trabajadores que operan el ‘sistema’), y condiciones latentes (resultado de decisiones de los diseñadores y gerentes, las que se expresan en las condiciones del entorno, la política y cultura organizacional; influyendo así el desempeño de los trabajadores). Listo, introduje la palabra ‘sistema’ así que no nos salvamos y aplicamos el caso a las TIC. El verdadero problema son las herramientas y los procesos que no impiden (o al menos emiten advertencias sobre) los errores inevitables que la gente hace, o la falta de automatización que significa, en primer lugar, que alguien está haciendo una labor manual –posiblemente propensa a errores y con errores en la fuente. Por ejemplo, podría haber carencia u obsolescencia de documentación, procesos, procedimientos; tal vez exista un desconocimiento del ecosistema tecnológico en la empresa; podría no existir o ser inadecuado o estar mal programado el monitoreo, control, supervisión; podría no haber auditoría interna de seguimiento o ser aceptados y trabajados sus resultados; podrían no darse de manera oportuna y completa, o no sustentarse apropiadamente las inversiones necesarias desde el punto de vista del valor para el negocio; entre otros factores de consideración.

Tengamos presente que los errores podrían ser tolerados, pero no el ocultarlos o encubrirlos. Entendamos que hay valor en invertir en el desarrollo y el fomento de una cultura en la que los colegas reconozcan errores y errores de juicio, y apoyarlos para que reporten aquellas cosas que casi originaron una falla. Tratar la TI y la seguridad como un servicio del negocio en lugar de un punto de control ayuda a crear ese tipo de cultura.

No olvidemos la deuda técnica -el costo y los intereses a pagar por hacer mal las cosas (presión en el cronograma, escasez o carencia de recursos apropiados o suficientes, entre otros factores, que obligan a saltarse pasos [o funcionalidad]) –y que no se ven desde fuera, pero causan daño dentro –no nos engañemos con la falacia del “costo hundido”. La famosa filosofía “si funciona, no lo toques”, puede ser un grave error. La modernización tecnológica (de los activos críticos del servicio) y su seguridad ([in]cumplimiento, riesgos para el negocio si el activo se ve comprometido) es algo mandatorio en estos tiempos; sin embargo, es necesario planificar esta modernización.

Recordemos que la información resultante debe transparentarse, difundirse, utilizarse, proactivamente. Evitemos reinventar la rueda. Avancemos. Contribuyamos con el conocimiento. ¿Somos lo suficientemente maduros verdad? Se nos mide por lo que hacemos, no por lo que decimos que hacemos.

¿Me comentas?