La digitalización bien entendida, empieza por uno mismo

En estos tiempos en que la mayor parte de las empresas están hablando de “Digitalización” y de “Transformación Digital” (que, no nos engañemos, sigue siendo la forma de moda para describir lo que se lleva diciendo y haciendo muchísimos años, “introduzcamos Tecnologías de la Información para optimizar/mejorar nuestro trabajo”) conviene llamar la atención sobre una “curiosa” contradicción.

Esa “Digitalización” en las diferentes empresa la realizan/dirigen/orientan empresas (o departamento internos) del sector de las Tecnologías de la Información (Empresas de Software, Consultoría, desarrollo, etc). Dado que es una mejora de procesos y ahorro de costes evidente, se supone que la empresa o departamento especializada que ofrece a un cliente (u otro departamento) implantar el proceso y herramienta, lo tiene implantado y utiliza internamente. Sin embargo, tristemente, en muchos casos no es así.

Aunque la he observado en distintas áreas (Procesos, BI, portales,..), voy a profundizar en esta contradicción en el ámbito documental, no solo porque es mi ámbito de especialización sino porque es un área especialmente descuidada y sin embargo tiene un gran impacto en la organización y productividad.

Como ejemplo de esta contradicción, he visto consultoras o departamentos de desarrollo vendiendo proyectos de implantación documental cuando tiene su documentación interna, como se dice popularmente, “hecha unos zorros”.

Por supuesto que los fuentes de los programas se controlan con software de control de versiones como git, SVN o Fossil, pero eso no es “la documentación de un proyecto”.

En ocasiones también se cuenta con una herramienta para gestionar backlog, pero son productos orientados a la gestión de tareas, no a manejar y recuperar la información adecuadamente. Eso tampoco es “la documentación de un proyecto”

En torno a un proyecto hay multitud de documentos (tanto internos como externos) sin los cuales se pierde una visión del proyecto, por qué se ha construido como se ha hecho, las decisiones (tanto técnicas como funcionales) que se han tomado, los problemas surgidos, los acuerdos con el cliente (que alteran plazos e implementación).

Sin toda esa información, no podrá realizarse un correcto mantenimiento de la aplicación, ni podrá minimizarse el riesgo de que en el próximo proyecto no se cometa los mismos errores, ni evitar que se incumplan plazos o que se realice un trabajo innecesario ya realizado en el proyecto anterior.

Toda esta información debería mantenerse en un gestor documental (DMS), asignando a cada documento insertado el tipo documental adecuado (“Planificación”, “Manual”, “Requerimientos”, “Pruebas de Carga”, etc) cada uno de los cuales podrá tener distintos metadatos/campos para describirlo. Esto nos permitirá posteriormente buscar no solo toda la documentación de un proyecto (que es lo mínimo exigible), sino por ejemplo, buscar todos los documento de tipo “Prueba de Carga” (de cualquier proyecto) o buscar todos los documentos de “Requerimientos” que incluyen las palabras “oAuth o kerberos”, acotando además la búsqueda, por ejemplo, a un determinado departamento o dirección.

Y también por supuesto, ese gestor documental debe incluir todo tipo de documentación. No tiene sentido que los documentos “económicos” estén en un sistema, los “contractuales” en otro, los “técnicos” en otro, los de “planificación” en otro, etc. Cualquier gestor documental mínimamente serio permite asociar permisos diferentes de forma que toda la documentación esté en un único expediente, pero cada perfil (directores, jefes de proyecto, arquitectos, consultores externos,..) vea los documentos que debe ver y tenga los permisos adecuados para su función. En la época de la visión integrada y unificada de los “Data Lake”, del “Business Intelligence” y de la “Visión 360 del Cliente”, que alguien tenga que acceder a tres o cuatro sistemas para ver todos los documentos relativos a un proyecto o aplicación parece absurdo.

Algunos ejemplos de los tipos de documentos que deberían crearse y gestionarse podríamos citar:

• Requerimientos: Lo que nos permitirá trazar, de forma formal y sistemática lo implementado y la funcionalidad de cubre.
• Planificación y seguimiento: Que complementada con una linea base, permitirá evaluar el esfuerzo adecuadamente en próximos proyectos
• Solución Técnica: Para disponer de un mapa global de piezas y tecnologías, algo que no está en los fuentes ni Backlog.
• Manuales: Manuales tanto de la aplicación desarrollada como de los productos integrados.
• Documentación de pruebas de productos o librerías: lo que nos permitirá entender por qué se utilizo determinadas productos en la solución.
• Contratos: Tanto con el cliente como productos adicionales adquiridos para el proyecto.
• Informes de pruebas de carga: De forma que para proyectos similares pueda reutilizarse información y procedimientos de las pruebas.
• . . .

Son algunos ejemplos de los tipos que deberían crearse, cada uno con su estructura de información y metadatos adecuados.

En muchos casos nada de lo citado existe, los documentos están en un disco compartido o una carpeta de red (o en una herramienta de colaboración que en muchos casos no aporta más beneficios que una carpeta de red) o en el peor de los casos, en los equipos personales de los implicados.

Desde luego esto redunda en la calidad del trabajo que se ofrecerá, en la competitividad (al tener que rehacer trabajo o buscar de nuevo) y en el soporte (¿cómo corregir o mejorar algo si no puede conocerse y analizarse los motivos por los que se tomo una decisión o se implementó de una forma concreta?)

Mi recomendación cuando alguien nos ofrezca “digitalizarnos” no sería (solo) pedir referencias de otros clientes sino pedir “Muéstrame cómo has aplicado tu producto/proceso en TU empresa/departamento, el comportamiento en producción y las mejoras que has conseguido,..”.

En particular en el ámbito de la gestión documental, pediría “Muéstrame como tienes organizada la documentación de TUS proyectos, cuanto tardas en localizarla, cómo la archivas, quien puede acceder a ella, cómo recuperas todos los Contratos (o NDA o ..), etc.”.

Si lo que se muestra no es MUY satisfactorio, yo no confiaría en esa empresa/departamento que intenta vendernos lo que no es capaz de realizar a la perfección en un ámbito que conoce perfectamente, su propio trabajo.

Por supuesto, como toda regla, tiene su excepción, una empresa de software que desarrolle, por ejemplo, “aplicaciones de diseño de motores” difícilmente podrá utilizarlo internamente.

Sin embargo en el caso de los gestores documentales, TODA empresa o departamento maneja documentación y debería organizarla adecuadamente, tanto para mejorar sus procesos como para cumplir normativa y ahorrar costes.

Como dice el dicho tradicional, “La caridad digitalización bien entendida, empieza por uno mismo”.