¿Existe el Necronomicón de la gestión (o "Gestionomicón")?

El Necronomicón es un libro ficticio creado por el escritor H. P. Lovecraft en donde se narra la historia de unos seres extraterrestres que gobernaron la Tierra en el pasado y que algún día regresarán. También guarda rituales mágicos y profecías. La etimología de la palabra daría un significado similar a "de lo relativo a las leyes de los muertos". De hecho, la frase más citada de este libro ficticio es:

"Que no está muerto lo que yace eternamente, y con los eones extraños incluso la muerte puede morir"

Ahora, un "Gestionomicón" vendría a ser el tratado definitivo sobre "lo relativo a las leyes de la gestión". ¿Podría existir realmente algo así? Muchos creen que sí. Por ejemplo, en dirección de proyectos tenemos el PMBOK, considerado por bastantes como LA guía de dirección de proyectos. Otros tantos dirán lo mismo de PRINCE2. En gestión de operaciones tenemos a ITIL, ISO 9000/2001, COBIT, eSCM, etc., las cuales cubren áreas distintas de conocimientos. Existe al parecer un permanente mercado para el siguiente Gestionomicón definitivo, lo cual podría indicar que aún no ha sido escrito, por mucho que les duela a algunos. Esta tendencia se puede estar alimentando de la naturaleza humana por disminuir la complejidad de las cosas y generalizar, lo que nos lleva a confiar de manera ciega en "balas de plata" a nuestros problemas.

Como señala Bjarne Stroustrup en su artículo "What Should We Teach New Software Developers? Why?" (vía Barrapunto), la mayoría de empresas de hoy en día tienden a buscar soluciones rápidas, económicas y a corto plazo, lo cual les ocasiona dificultades para manejar sucesos improbables de alto impacto (o "cisnes negros" como los llama Taleb) como la reciente crisis financiera. Bueno, para ser sinceros, la aplicación de las guías y metodologías arriba mencionadas no es ni rápida, ni económica, ni su impacto es a corto plazo, pero comparten una característica: dan la sensación de estar protegidos a quien las usa, por lo que se baja la guardia.

Al parecer, un Gestionomicón es tan ficticio como un Necronomicón. Al menos por ahora.

Preveer la salida del personal clave

Un problema típico en las áreas de IT surge cuando el experto sabelotodo sale de la organización, dejando tras de sí una faltante difícil de rellenar por toda la experiencia y conocimiento que poseía la persona. El superar esto puede ser un difícil reto para el área, que lo enfrenta por lo general desprevenida.

Tal situación puede ser evitada si se realiza una correcta gestión del conocimiento mediante repositorios que almacenen la información con un cierto orden y que permita accederla rápidamente. Por ejemplo, sistemas de apoyo al service desk permiten tener un registro de los incidentes que surgen con los usuarios y de las soluciones que fueron utilizadas para cada caso. Otros ejemplos serían: 

• Un wiki interno donde se vuelque cualquier información relevante y con peligro de ser olvidada o perdida. 
  
  
• La utilización de mapas mentales para registrar conocimiento de manera rápida y ordenada.
  
  
• Plataformas de enseñanza virtual que permita al usuario aprender o revisar la utilización de las herramientas informáticas y computacionales de manera efectiva y con mínimos recursos para la empresa.
  
  
• Mejora de la comunicación entre el personal mediante teleconferencias, soluciones de VoIP y/o mensajería instantánea, que facilite el flujo de información y conocimientos. También soluciones para acceso remoto seguro a los recursos informáticos de la institución, como VPN o SSH, pueden ayudar a lo mismo. Mientras mejor fluya el conocimiento, menos probable es que se pierda.
  
  

Cualquier medida que se tome implica un cambio cultural en la unidad de TI (y en la empresa) y requiere del apoyo comprometido de la gerencia para su continuidad en el tiempo y la posterior cosecha de beneficios a mediano plazo. 

Aplicando la trilogía de Jurán, tenemos primero el diseño de todo este entorno para la gestión del conocimiento en una arquitectura coherente que permita la interoperabilidad; luego tenemos el control, que es el definir y obtener indicadores de desempeño a fin de analizar su eficacia (por ejemplo, cantidad de incidentes abiertos, número que fueron cerrados, tiempo medio de atención al usuario, etc.); finalmente se realiza el análisis de los indicadores para realizar cambios profundos que se traduzcan en mejoras significativas, con una nueva planificación que abra a su vez un nuevo ciclo.

El beneficio visible para la gerencia de este proceso sería una atención más efectiva del área de TI y la continuidad de los servicios informático tras la falta de cualquiera de sus integrantes. 

“Si no esperas lo inesperado, no lo reconocerás cuando llegue” 

Heráclito de Éfeso (540 a.C. – 470 a.C.)

Software libre para lograr calidad

El desarrollo de sistemas complejos debe ser realizado con un pensamiento sistémico para lograr el éxito. Al igual que el cerebro humano, compuesto por millones de neuronas donde ninguna es indispensable sino que el sistema como un todo se adapta a la situaciones internas y externas (recuerdo haber escuchado del caso de una persona que vivía con medio cerebro), así se adapta un equipo de desarrollo de software libre: el conocimiento se gestiona y comparte de tal manera que ningún integrante es indispensable. Para su ejecución, estos tipos de proyectos se basan en la conformación de una comunidad de individuos que tienen a ese software como la intersección de sus intereses heterogéneos, y que lo enriquecen con sus visiones complementarias. En este esquema, nadie es el dueño de la verdad, ni siquiera el que coordina el proyecto; como máximo se tienen a los que sirven de catalizadores, que con sus ideas individuales inspiran al grupo y generan funcionalidades más completas que la idea original. En ese sentido, el grupo se autoregula para obtener el resultado más óptimo y simple que, primero, cumpla con el objetivo del programa, y segundo, satisfaga de la mejor manera los distintos intereses de los involucrados en su desarrollo. Creo que esto es lo que más dificulta de entender para las personas acostumbradas a los proyectos jerarquizados, necesidades estáticas y conceptos etiquetados: un proyecto de software libre puede subsistir en el tiempo y presentar resultados de calidad por el pensamiento sistémico implícito que surge, con el tiempo, en todo grupo humano lo suficientemente grande que es libre de autoregularse. Este tiempo depende del coordinador, de su pericia en ser un catalizador de preguntas más que un dictador de respuestas.

Creo que lo anterior se podría resumir en: el software propietario se basa en el dinero y para su desarrollo depende de una cabeza que sepa dar órdenes claras, mientras que el software libre se basa en el ego y para su desarrollo depende de la comunicación y gestión del conocimiento entre varias cabezas.

Ahora, lo dicho puede resultar preocupante para una persona que confíe en el dinero más que en el ego, y puede provocar sofismos del tipo “no confío en su forma de desarrollo, por lo tanto su producto tiene que ser de baja calidad”. Ambos conceptos, filosofía de desarrollo y calidad del producto, son hasta cierto punto independientes ya que en ambos bandos hay buenos y malos productos. Todo se basa en la simple pregunta de que si el software satisface o no mis necesidades o las de mi organización, y qué tan confiable es la solución. Con el software privativo se tienen soluciones que “nunca” se dañan, que “siempre” cuentan con soporte. Y bueno, cuando se dañan es que nos hemos topado con la aguja en el pajar, pero el fabricante siempre nos da una solución para que eso nunca más vuelva a pasar. Lamentablemente, la solución es como el amor: eterno mientras dura. Y así se va parchando y parchando el software, agradecidos que existe ese proveedor que nos ofrece su maná del cielo en medio de nuestro inevitable desierto-purgatorio de software. Lo malo es que con el software libre pasa exactamente lo mismo: tal vez su maná no sabe a coca cola sino a limonada. Pero se tiene el poder para discernir mentiras y verdades, ya que a más de la respuesta ante el fallo nos dan los fundamentos de tal respuesta y la posibilidad de verificarla. Sin esta capacidad se aumenta el riesgo de que pase un hecho altamente improbable, y su correspondiente impacto fuera de toda previsión. La única forma de minimizar tal tipo de riesgo es disponiendo de la mayor cantidad de información disponible, lo cual cumple el software libre ya que entrega el código fuente de la aplicación y una comunidad de desarrolladores abierta a preguntas.

De lo relativo a la gestión

Gestión. En nuestros tiempos, la habilidad de gestionar se convierte de una ventaja a una necesidad. Los cambios profundos e inesperados, sumados al bombardeo constante de información heterogénea por distintos canales, crea una presión sobre los individuos y sus grupos para manejar de manera óptima este contexto. Tal vez el concepto de individuo deba perder su relevancia ya que la complejidad de tal tarea puede implicar la utilización de inteligencia colectiva para su correcto manejo, al igual que una colonia de hormigas o un panal de abejas. O tal vez el individuo deba redescubrirse como un tomador de decisiones dentro de un contexto al que influye y que lo influye, en un equilibrio regido principalmente por la anarquía. Sea cual fuere la respuesta, algo es muy claro: la sociedad está cambiando en algo nunca antes visto en la historia humana.

¿Estaremos listos? ¿Cómo nos prepararemos a los cambios por venir? ¿Qué deberemos aprender, y qué sacrificar?

Este blog intenta hechar una mirada a este mundo que se viene, a las nuevas formas de hacer las cosas, adentrándose en las oscuras olas del vasto mar de cambio que se precipita con violencia sobre todos nosotros.