Productividad=Organización+Documentación

Básicamente se define productividad como la relación entre la producción obtenida (servicios, productos, ..) y los recursos empleados en la producción (materiales, personal, tiempo, etc.).

Lamentablemente, en muchas ocasiones se asocia mentalmente “productividad”,  a “lo que produce cada empleado”, es decir, “lo que se obtiene de cada sueldo” por lo que la forma de aumentar la productividad es que los empleados “trabajen mucho y cobren poco”. Aunque eso desde luego reduzca los costes, es tan erróneo como plantear que “se aumentará la productividad si no se compran ordenadores”, ya que “reducimos los costes” o que “el reparto se haga andando, para evitar la compra y mantenimiento de vehículos”.

Creo que en ámbito de las TI (como casi en cualquier otro sector por otra parte) los elementos más importantes para mejorar la productividad son la organización y la documentación. Desde luego también es importante el contar con buenos profesionales y con buenos instrumentos (tal como he argumentado anteriormente [La "barrera del sonido"]y[El altísimo coste del “ahorro” en ordenadores y equipamiento], aunque no dentro del enfoque de la productividad).

Sin embargo el mejor técnico y el mejor ordenador son casi inútiles en una entorno de trabajo desorganizado e ”indocumentado”, y lamentablemente eso es algo demasiado habitual.

 

Algunos ejemplos

Quizá el ejemplo más claro que conozco de cómo mejorar la productividad es este:

Un banco de alimentos creado tras unas inundaciones en Nueva York, organizado por una persona de buena voluntad y con mano de obra voluntaria mejoró espectacularmente su productividad  (cantidad de lotes de comida repartida) simplemente organizando mejor su trabajo y con unos mínimos costes.

Por otra parte, en el aspecto negativo, hay muchos ejemplos de tiempo perdido por falta de organización o documentación.
Por ejemplo:

• ¿Quién no ha tenido que rehacer un proyecto porque, tras estar parcial o incluso totalmente desarrollado, un área con la que no se ha contado introduce nuevo requisitos o vetos debido a que no se cumple ciertas características? Si el proceso de definición de un nuevo proyecto (con todos sus intervinientes y momentos de intervención) estuviera definido, no se produciría esta pérdida. Todo esto es un coste evidente que  afecta negativamente a la productividad Ya que el resultado obtenido puede haber costado en ocasiones el doble de lo que costaría con un circuito bien definido.

• ¿Quién no ha sufrido retrasos debido a que no está especificado quien debe aprobar/revisar/arreglar/instalar algún elemento? En ocasiones todo un equipo implicado en un proyecto tiene que esperar a que se confirme (o improvise) un circuito. De nuevo, son muchas horas perdidas debido a esta carencia. Incluso aunque el equipo implicado pueda ocuparse en otras tareas, siempre hay un tiempo empleado en la búsqueda, hay una pérdida de tiempo hasta que se decide que ”no se sabe” y sobre todo, de oportunidad al no cumplirse plazos.

• Otro ejemplo habitual es la no disponibilidad de un ordenador cuando se incorpora un empleado. Estos retrasos pueden llegar a ser de 1 mes, y es evidente que, dado que es necesario un preaviso en su empresa por parte del futuro empleado, preparar el nuevo contrato en la empresa contratante, etc. se dispone de al menos 15 días desde que se sabe que se va a contratar a una persona concreta para un puesto concreto. Un circuito bien organizado puede asegurar que todo el equipo y elementos necesarios estén disponibles. De nuevo es un problema organizativo que, de no estar bien estructurado, es muy costoso.

 

Realmente no es tan difícil y merece la pena 

 

Todos estos escenarios representan costes que hacen que la productividad (recordemos, producto obtenido frente a costes/recursos aportados) se reduzca y que con un mínimo de organización pueden minimizarse. Puede argumentarse que es difícil calcular los costes, pero no lo es tanto.

Por ejemplo que un nuevo empleado esté 2 semanas sin ordenador (es decir unas 80h improductivas), asumiendo un salario de solo 24.000€, lo que implica unos costes de unos 20€/h, equivale a 1600€. En el caso de un proyecto que hay que modificar o retrasar, desde luego es más difícil, pero puede hacerse una estimación de riesgos (al igual que las compañías de seguros con los accidentes) teniendo en cuenta el coste total del proyecto y la probabilidad de cambio (que puede afirmarse que es casi “inversamente proporcional a la calidad de la organización”).

En cuanto a la documentación, suele estar igualmente “olvidada”. La documentación, en el mejor de los casos está en una herramienta de colaboración, y en la mayoría, en una carpeta de red o incluso en los equipos personales. No es demasiado habitual que esté en un gestor documental, que como su nombre indica, es la herramienta adecuada para gestionar documentos. Parece ridículo tener que recordarlo, pero lamentablemente pocas empresas tiene su documentación en un gestor documental. 

El resultado es que se emplea mucho tiempo buscando documentación (o bien porque puede estar en múltiples localizaciones, o bien porque no puede localizarse al estar incorrectamente catalogada y clasificada, con los metadatos adecuados o no está clara la última versión.

Todo ello conlleva pérdidas de tiempo, y en el peor de los casos, toma de decisiones incorrectas al basarse en documentación obsoleta, por ejemplo asumir comportamientos de versiones anteriores, o funcionamiento bajo versiones de infraestructura (Sistema Operativo, base de datos, versiones de java, servidores Web o J2EE,..) obsoletas o fuera de soporte.

Mención aparte merece la “calidad” de la documentación, independientemente del lugar en que se almacene o la corrección de su catalogación. Aunque cada vez es menos frecuente, sigue siendo bastante habitual que el “becario” o alguien “que pasa por allí”, se encargue de la documentación de muchos proyectos tecnológicos. Como consecuencia, esa documentación en muchas ocasiones simplemente detalla lo que hace la aplicación (cosa que por otra parte puede verse viéndola trabajar) y los componentes que tiene (lo que puede verse revisando el código fuente y el paquete de instalación) pero no explica realmente el funcionamiento interno, o porqué se han tomado ciertas decisiones. Es decir la información realmente importante y que conocen los perfiles más implicados en el desarrollo y con más experiencia.

Al final la productividad en muchos casos se reduce a la mitad (y no es exageración, he visto proyectos que han duplicado la carga de trabajo prevista, debido a problemas como los anteriores), algo que podría evitarse simplemente con mejor organización y documentación.

La "barrera del sonido"

Recuerdo haber oído esta expresión a dos empleados de recursos humanos tomando un café, hace muchos años en una consultora en que trabajaba. Se referían a un candidato que había “traspasado la barrera del sonido”, es decir, había superado cierta edad (desconozco si podían ser 40 o 50 años), lo que prácticamente lo descalificaba para el puesto.

Aunque el tema de la edad laboral se ha tratado en numerosas ocasiones por especialistas, y aunque parece ridículo tener que argumentar sobre algo tan evidente, especialmente en el ámbito de las Tecnologías de la Información que es el que mejor conozco, creo que no está de más volver a reflexionar sobre el alto coste económico que tiene para una empresa de Tecnologías de  la INFORMACIÓN el “tirar a la basura” toda esa INFORMACIÓN y experiencia que albergan empleados a los que se prejubila o que tienen esos candidatos a los que no se contrata.

Quizá lo primero a destacar que es creo que este modelo es principalmente aplicable a España. Los datos de que dispongo, tanto obtenidos desde Internet como directamente de otros profesionales (compañeros o proveedores) que trabajan en otros países, muestran que no ocurre, o no con tanta frecuencia, en otros países.

By Internet Archive Book Images, via Wikimedia Commons

Escenarios de “derroche”

Creo que en las empresas de TI hay tres formas en que se desperdicia el capital humano por la edad:

• Estructura de la carrera profesional
• Prejubilaciones y despidos
• No contratación por edad

 

Estructura de la carrera profesional

En la mayoría de las empresas de TI no existe REALMENTE una carrera profesional PROLONGADA que permita a un buen técnico seguir evolucionando en su carrera aumentando el RECONOCIMIENTO profesional y el SUELDO.
En gran parte de las empresas de tecnología la evolución implicar dejar de ser técnico y convertirse en gestor (si se desea que el sueldo y el reconocimiento aumenten). Esto provoca que, en ocasiones, la empresa pierda un buen técnico y adquiera un mal gestor (según el clásico Principio de Incompetencia de Peter ).
Por supuesto no quiere decir que todos los jefes de proyecto deban proceder carreras de gestión (es habitual ver resultados desastrosos cuando alguien que no conoce las singularidades y características del desarrollo de software intenta gestionar o dirigir el trabajo, por lo que es recomendable que la gestión la realicen personas con experiencia en tecnología), sino que la evolución debe ser por convencimiento e interés y no de forma “forzada” para no quedarse estancado.
El resultado es que esa experiencia y conocimientos se pierden y la empresa, que posiblemente ha sustituido en  su “pool” de técnicos un perfil “caro” por uno “barato”, en lugar de aumentar su beneficio, pierde en eficiencia (produce más barato pero probablemente  más lento y con peor calidad) y posiblemente pueda tener más errores o retrasos, con los costes asociados.

Esto desde luego no ocurre, o no de forma tan acusada, en otros países (basta comparar las bandas salariales o las ofertas de empleo habituales en España y otros países). Esto se evitaría si, como ocurre en otros países, puedes encontrar un programador con 60 años al que todo el mundo consulta y respeta  al que se encarga los proyectos difíciles y pide asesoramiento.

Prejubilaciones y despidos

A lo anterior hay que sumar los despidos o prejubilaciones a partir de una edad. El argumento, que en algunos casos puntuales es cierto, de dificultad o incapacidad para reciclarse, en la mayoría de los casos no tiene ningún soporte objetivo.
El mundo de las TI ha cambiado radicalmente cada pocos años y la mayoría de los profesionales han tenido que aprender nuevas herramientas y sobre todo nuevos paradigmas y tecnologías.

El despido de esos profesionales que conocen los proyectos y herramientas de la empresa, dado que muchas veces la documentación es incompleta, o incluso no existe, hace que se pierda mucho valor y mucha productividad.

En el mejor de los casos, se perderán varios meses hasta que una nueva persona, sin experiencia, aprenda todos los detalles, por lo que el ahorro en salarios debe minorarse restando todos esos meses improductivos.

En el peor, no habrá nadie capaz de asumir la tarea, o quien la asuma lo hará con errores que tiene un coste.
Y ese coste puede ser muy grande (indemnizaciones a clientes, perdida de muchas horas de trabajo de empleados,..).
Lamentablemente no se suele imputar esos errores o pérdidas al departamento que “ha ahorrado” sino que en ocasiones parece atribuirse a “una conjunción de astros” o a “lo complicada que es la informática” por lo que no hay forma de comparar el impacto real de esos “ahorros”.
Una imputación real de lo que cuesta esos “ahorros” sustituyendo a profesionales avezados por becarios posiblemente mostrara cifras mucho peores y probablemente costes mayores.

Nadie responsable plantea usar tornillos de mala calidad para utilizarlos en piezas estructurales y sin embargo sí se considera “normal” prejubilar a profesionales “de calidad” y sustituirlos por profesionales sin experiencia. La diferencia es que cuando un tornillo se rompe y la empresa tiene que pagar indemnizaciones, las responsabilidades y la causa suele ser más clara, mientras que si un desarrollo falla y la empresa tiene que asumir indemnizaciones, la causa no siempre se plantea de forma tan clara.

Por último, como ejemplo claro del absurdo a que se llega, conozco al menos dos casos de empresas que prejubilaron a técnicos (con su indemnización correspondiente) y tras descubrir que nadie conocía cómo hacer su trabajo, tuvieron que contratarles de nuevo como consultores externos (con sus costes extras).

No contratación por edad

Los casos anteriores se producen con empleados dentro de la empresa, pero un porcentaje importante de los casos se produce por la no contratación de profesionales que han superado cierta edad.
Desde luego en este caso no aplica la obsolescencia de conocimientos o imposibilidad de reciclar, ya que si no conocen la tecnología o disciplina para la que se les requiere, no hay por qué contratarles, independientemente de su edad.

Por tanto el único motivo puede ser la edad, y en ocasiones, su banda salarial, que puede ser más alta que la de un recién licenciado. Como en el caso anterior, parece claro que la productividad y calidad compensan (en gran parte de los casos) el coste sobre un recién licenciado.

Lamentablemente, parece que estas “manías” (no he encontrado en mi vida nadie que sea capaz de dar una argumentación coherente a este tema, por lo que solo puede tacharse de “moda” o “manía”)  se extienden a algunas empresas que mantenían un criterio coherente: https://www.elconfidencial.com/alma-corazon-vida/2018-05-04/empresas-trabajar-discriminacion-edad_1558692/

0 A.D. game Wildfire games (CC)

Es curioso, que ahora que está tan de moda la gamificación, y que además hace tiempo que se considera que los juegos permiten aprender técnicas y estrategias luego aplicables a la vida empresarial, no se recuerda algo que cualquier jugador de juegos de estrategia conoce:

En la mayoría de juegos de estrategia, la táctica ganadora pasa siempre por tener pocos soldados muy bien equipados y con mucha experiencia  (“caros”) y no en tener muchos  “baratos”. 

Y eso se lleva aplicando desde hace siglos al juego de estrategia por antonomasia, el ajedrez. Ningún jugador cambiaría una reina por dos o tres peones.

By User:Mutante [CC], from Wikimedia Commons

Como en otros casos, esperemos que una revisión crítica de los costes e impacto real de los “ahorros” en personal, al igual que he comentado respecto al material de trabajo  reconduzca la situación.

Por qué Bigdata no es para todo el mundo.

En estos últimos años ha “subido como la espuma” el interés por Bigdata. Parece que no hay empresa que no considere que debe invertir en Bigdata ni profesional que no considere que es un sector de futuro. Sin embargo, como indica el título de esta entrada, creo que Bigdata “no es para todos”, por su propia esencia.

By Magnai17 (Own work) [CC], via Wikimedia Commons

 

Repasando Bigdata.

Como es sabido, Bigdata (llamado en ocasiones Macrodatos en castellano) es un concepto que hace referencia a enormes volúmenes de datos, que no pueden ser tratados con las bases de datos tradicionales.
Los proyectos de Bigdata no solo se caracterizan por la cantidad de datos; tradicionalmente se ha definido que tienen tres características, las 3 V: Volumen, Velocidad, y Variedad.

• Volumen hace referencia a la cantidad de los datos. Cuando se habla de Bigdata, estamos hablando de volúmenes MUY  grandes, de las decenas de TERAS en adelante, es decir hablamos de almacenar un mínimo de 10.000.000.000.000 caracteres. Los expertos en Bigdata suelen recomendar otras tecnologías para volúmenes inferiores, aunque sean “muy grandes”.  Para hacerse una idea de lo que implica, si pensamos que una llamada de teléfono se puede almacenar usando 11 dígitos del “llamante”+11 dígitos del llamado+5 de la duración+12 de la fecha hora, es decir 40 dígitos (realmente sería la mitad en base de datos, pero obviamos eso de momento) y dividimos 10Teras/40/50 Millones de habitantes, eso nos da que estaríamos hablando de 5.000 llamadas de cada habitante de España. Otra comparación podría ser el pensar en movimientos bancarios. Si contamos 50 caracteres por movimiento y pensando en un banco que tenga 10M de cuentas, nos da 20.000 movimientos (transferencias, entradas, etc.) de cada cuenta/cliente.

• Velocidad hace referencia a la cantidad de datos que deben incorporarse por unidad de tiempo. Se trata de sistemas donde se puede generar cientos de miles de entrada por hora. Lógicamente, para alcanzar esos volúmenes no puede alimentarse con unos pocos registros cada hora, ya que se tardaría años en rellenarla la información.

• Variedad hace referencia a la variedad de datos a manejar INCLUSO para la misma tabla/entidad. Es decir, no se trata de manejar 10 millones de asientos contables todos iguales sino de intentar manejar “juntos” elementos caracterizados por distintos metadatos.

Estos requerimientos han provocado que se utilicen tipos de herramientas distintas a los gestores de bases de datos tradicionales. Generalmente se utilizan Bases de Datos NoSQL como MongoDB , Cassandra o HBase  que utilizan un modelo no relacional .

El hecho de prescindir de la normalización de la base de datos  y de recursos habituales en las bases de datos “tradicionales” como transacciones (es decir poder agrupar las operaciones en paquetes de operaciones coherentes, de forma que se haga todo o nada), claves únicas (es decir asegurar que no se introduzca dos veces el mismo valor) o claves ajenas (que asegura que no se referencia una entrada que se borra por otra operación) elimina muchas de las sobrecargas sobre los sistemas  tradicionales, permitiendo velocidades de ingestión de los datos mucho mayores (al no tener que realizar comprobaciones de los valores), y una escalabilidad muy grande (al poder distribuirse la carga entre muchos nodos que no deben mantener la coherencia).

En cualquier caso, aunque no sean bases de datos “tradicionales” que tengan un modelo totalmente normalizado hasta la 3ª o 5º forma normal, siguen siendo bases de datos, es decir tiene una estructura de información, la diferencia es que podemos tener, por ejemplo, una factura con todos sus ítem en una “tabla”, algo que en un modelo normalizado requeriría dos o tres tablas.

En ocasiones surge cierta confusión en cuanto al uso, asumiendo que, por ejemplo, pueden utilizarse para clasificar textos, área para la que están mucho más preparadas herramientas como las herramientas de NLP (Natural Language Processing: Procesamiento del lenguaje natural), Machine Learning,  o Content Analytics. Ese sería otro ámbito de trabajo con otras características.

Courtesy NASA/JPL-Caltech [Attribution or Public domain], via Wikimedia Commons

Por qué no es para todas las empresas o instituciones.

La variedad de datos se da en muchos ámbitos y modelos que puedan realizarse de actividades humanas, sin embargo,

 ¿Cuántas actividades humanas generan esa cantidad de datos?

Y lo más importante

¿Cuántas empresas e instituciones tienen acceso, generan o reciben esa cantidad de información?

Como puede verse por las cifras, no es muy habitual manejar esa cantidad de información.
Y si se trata de cifras inferiores, NO es Bigdata, o NO es adecuado tratarlo con herramientas de Bigdata.
Debe además descontarse los escenarios donde se manejan millones de datos pero son texto (por lo que aplicarían las herramientas de manejo de textos antes citadas).

Por último un detalle menor.
Aunque después de frases famosas como la atribuida (incorrectamente ) a Bill Gates acerca de que “640K deben ser suficientes”  o la del presidente de IBM  Thomas J. Watson en 1948 de “Creo que habrá mercado mundial para cinco computadores” es muy “arriesgado” hacer previsiones, y aunque los costes de almacenamiento e infraestructura de ordenadores han bajado mucho y siguen bajando, a día de hoy manejar toda esa información de forma rápida y eficiente sigue siendo caro y complejo.

En cualquier caso es un obstáculo menor, que perderá cada vez más peso frente al problema principal de cualquier empresa o institución: ¿De dónde obtengo información que justifique el uso de Bigdata?

By Magnai17 (Own work) [CC], via Wikimedia Commons

Por qué no es para todos los profesionales.

En ocasiones se leen opiniones de profesionales que manejan otros tipo de información (contenidos, documentación, etc.) acerca de lo cercano o adecuado que es su perfil para volcarse en el mundo de Bigdata. Sin embargo, aunque sea un nuevo sector, no hay que olvidar que se trata de manejar bases/volúmenes de datos. No seguirán un modelo relacional, pero siguen un modelo, con sus columnas, conjuntos de metadatos, sus relaciones, su integridad mayor o menor, incluso sus transacciones (recientemente MongoDB ha cubierto esa carencia  ).
Quien no haya manejado esos conceptos, reflexionado sobre como optimizar un modelo de datos, crear índices o resolver problemas de rendimiento en una base de datos con 20 millones de registros, posiblemente no pueda sacar rendimiento de un proyecto de Bigdata.
Al igual que no es lo mismo un pintor que tras dominar el arte figurativo evoluciona hacia el abstracto que alguien que no sabe pintar y hace cuadros “abstractos”, no es lo mismo alguien que domina las bases de datos y evoluciona a Bigdata que  alguien que nunca ha trabajado con bases de datos.
Por supuesto todos podemos reciclarnos, formarnos y aprender nuevas disciplinas, al igual que puede haber expertos en bases de datos que se queden anclados y no sepan dar el paso a Bigdata (como puede ocurrir a un pintor que no sepa dar el paso a arte abstracto), solo quiero resaltar que, en principio, por su  experiencia y bagaje técnico, los profesionales especializados actualmente en bases de datos (administradores de bases de datos, diseñadores de bases de datos, expertos en data DataWarehouse, etc.), así como los expertos en análisis de datos y estadística son los que tendrán más facilidad para poder enfrentarse con proyectos de Bigdata.

Conclusión

Para no dejarse arrastrar por la ola de entusiasmo, creo que lo más recomendable para las empresas e instituciones, antes de plantearse iniciar un proyecto de Bigdata, sería reflexionar sobre:

1. ¿Tengo en mis procesos y sistemas de información esos volúmenes de datos?
2. Si se trata de información que no puede/debe tratarse con un modelo relacional ¿no bastaría plantearse el uso de una base de datos NoSQL con un modelo no normalizado?

Y para los profesionales que se plantean acercarse a ese mundo:

1. ¿Pretendo CONOCER Bigdata (una disciplina nueva e interesante) o TRABAJAR en Bigdata?
2. Si pretendo trabajar, ¿Mis conocimientos y los cursos que estoy evaluando son suficientemente profundos y adecuados?

La "Maldición" de la Gestión Documental.

Si a cualquiera se le cuenta que hay "ALGO" que TODAS las empresas e instituciones necesitan, o que, si no necesitan literalmente, de su uso obtienen unos enormes ahorros y eficiencias, creo que a los más emprendedores les surgiría la pregunta: “¿Qué es eso? Vamos a dedicarnos a ofrecerlo y nos ‘forramos’ ”.

Si además se añade que TAMBIÉN lo necesitan gran parte de los autónomos y que, una vez instalado, dadas las normativas o la dificultad de migración es posible que deba usarse un mínimo de 6 años y hasta 30 o 40 años, según a qué se dediquen la empresa o institución, la siguiente exclamación sería: “ ¡ Pero esto es la ‘gallina de los huevos de oro’ !, Millones de clientes potenciales que además del software necesitarán servicios añadidos durante años, y, dado que  produce grandes ahorros y eficiencias, se venderá muy bien, ya que enseguida recuperas la inversión. Las personas y empresas que se dediquen a esto deben estar muy solicitados”.

Por supuesto me refiero a la gestión documental (entendida como la implantación de procesos y herramientas que permitan registrar, almacenar, automatizar y compartir documentos), y no, tristemente la respuesta es que, aunque racionalmente debería haber mucho “movimiento” en torno al software y servicios de gestión documental, esta no se “vende” nada bien.

Las empresas e instituciones:

• Pueden invertir miles de euros en aplicaciones o proyectos que no les reportan beneficios, mientras mantienen una gestión de la documentación del siglo XV; a nadie se le ocurre actualmente llevar la contabilidad o la gestión “a mano” y sin embargo la documentación se sigue manejando en papel y sin un gestor documental que la albergue; o los documentos electrónicos se envían por correo y se “guardan” en una carpeta de red.
• Pueden cambiar cada 3 años de aplicación de contabilidad, ERP o nóminas cuando no tienen un solo software gestor documental para manejar los documentos electrónicos.
• Pueden tener falta de espacio en las oficinas (con los enormes costes que ha ido alcanzando los alquileres) cuando podrían eliminar miles de papeles (en muchos casos fotocopias) simplemente digitalizando.
• Siguen enviando los documentos en papel por medio de la valija interna (con los costes de transporte asociados) y retrasando los procesos hasta que se reciben los originales cuando podrían digitalizar, destruir las fotocopias y enviar los pocos originales a un centro de custodia situado “en medio del campo” y con costes mínimos.

Mientras tanto, no hay demasiadas empresas ni profesionales que se dediquen a ello, no hay demasiadas ofertas de empleo, los profesionales no están bien considerados y se cierran facultades y grados.

Y todo ello en un sector maduro tecnológicamente, donde existen muy buenos productos de gestión documental, tanto gestores documentales (el núcleo de la gestión documental) como herramientas de clasificación automática de documentos, conversión de formatos, procesos/BPM, gestión de expedientes, Record Management, motores de búsqueda por texto completo, etc.

Document-management-workflow (By Silver Blue)

Donde además de software con licencia comercial, hay software libre y/o gratuito, lo que, junto con la continua ampliación de la capacidad de almacenamiento y proceso de los ordenadores y abaratamiento de precios, permite que lo que hace años requería sistemas costosos y propietarios (como los Jukebox de discos ópticos) para almacenar imágenes, represente costes muy inferiores de puesta en marcha actualmente.

Parece como si hubiera una especie de “maldición” que hace que la gestión documental se mantenga en un agujero.

Dado que la idea de “maldición” repugna a cualquier espíritu racional, quería reflexionar sobre alguno de los posibles motivos que provocan este atasco. Como grandes razones, creo que puede resumirse en la combinación de tres factores:

• Complejidad
• Desconocimiento
• Inercia

By KNOWLEDGE BASED SYSTEMS, INC. [Public domain], via Wikimedia Commons

 Complejidad:

Quizá el principal motivo es la complejidad. La gestión documental es MUY compleja en sí misma. Diseñar un proyecto de gestión documental tiene limitaciones y problemas que no tiene otros proyectos de tecnologías de la información:

Volumen: Abrir una cuenta en un banco o un siniestro enuna compañía de seguros puede representar unos pocos registros en una base de datos, totalizando 1000 o 2000 caracteres (1Kb o 2Kb). Sin embargo los documentos asociados a esa cuenta (contrato, DNI, Nómina, cartulina de firmas, documentos Mifid,..) o ese siniestro (fotos, grabación de audio, parte amistoso,..) pueden representar varios megas de información, es decir cerca de 1.000 (MIL) veces más de información, que hay que almacenar, clasificar y procesar. Eso representa un esfuerzo de dimensionamiento, infraestructura, diseño y rendimiento mucho mayor. Si además se desea buscar por el contenido de los documentos, deben crearse índices, lo que puede doblar el almacenamiento necesario, siendo entonces de 2.000 veces mayor. Ese volumen además de almacenarse debe subirse y descargarse en un tiempo razonable, lo que representa  un esfuerzo en infraestructura (servidores, ancho de banda, almacenamiento,..)

Legislación y normativa: Dado el carácter “legal” de muchos documentos (una entrada en una base de datos no demuestra nada, pero un contrato firmado, una carta o una grabación, sí) hay muchas normas que pueden aplicarse y que hay que tener en cuenta al diseñar el sistema. Como complicación adicional, hay documentos utilizados para un proceso que, aunque el proceso en sí pueda no ser complejo o confidencial, pueden arrastrar restricciones propias del documento. Por ejemplo, una declaración de la renta o una nómina, utilizada para abrir una cuenta, pedir un crédito o solicitar una plaza escolar, puede contener datos de desgravaciones por discapacidad, donaciones a un partido político o a una congregación religiosa, lo que podría considerarse como información cubierta por el nivel 3 de la L.O.P.D., y sujeta a unos procedimientos y tratamiento específicos. El caso, cada vez más frecuente, de los documentos electrónicos firmados electrónicamente o que contienen datos biométricos, estaría igualmente sujeto a una serie de restricciones, independientemente del contenido en sí del documento, que puede ser trivial.

Seguridad: La seguridad en los gestores documentales es muy sofisticada, para poder dar soporte a todos los condicionantes legales, así como a las necesidades propias del proceso de la institución (permisos restringidos en función del departamento o función del usuario, del estado o tipo documental del documento, traza de operaciones, control y bloqueo de versiones, etc...). El diseño y mantenimiento de esa seguridad (que además puede cambiar por normativas, reorganización o cambios de personal) es muy complicado.

Distribución: Al no estar aún legislada la validez de los documentos electrónicos, salvo excepciones en algunos ámbitos como la digitalización certificada de facturas, la mayoría de los intercambios de documentación entre empresas, instituciones y personas se sigue realizando en soporte papel. Esto implica que puede recibirse documentos en papelen diversos lugares, repartida por delegaciones y ciudades, lo que complica el diseño de los procesos. ¿Desplegar escáner por diversos puntos? ¿Enviar documentos a un centro de digitalización? ¿Quién y donde clasifica y asigna metadatos? Si quien asigna metadatos no es quien recibe el documento ¿Cómo se transmite esa información de la persona o expediente a que corresponde el documento, ya que podrían no estar en el propio documento?...

“Autoservicio”: Cada vez es más frecuente que los usuarios de un servicio, empresa o institución, puedan trabajar con un modelo de “autoservicio”, reservando viajes, abriendo cuentas, contratando seguros o declarando siniestros, y eso implica en muchos casos el suministro y descarga de documentos.  Que un usuario aporte sus documentos, por una parte elimina trabajos (no hay que digitalizar, registrar ni asociar el documento a un usuario o expediente) pero añade otras tareas y problemas asociados a este “autoservicio” (¿Qué ocurre si no se suministra el documento solicitado sino “una foto de las vacaciones”? ¿Y si el documento está caducado? ¿Y si está incompleto? ¿Y si esta borroso u oscuro y no es legible? ¿Y si es de otro usuario? ¿Y si el formato es obsoleto y no puede abrirse?...). El diseño de proyectos de este tipo implicará procesos más complejos de verificación, conversión, clasificación y extracción de metadatos, etc. Tareas todas ellas que pueden hacerse de forma manual o automática (existen productos que permiten hacerlo con muy buenos resultados) pero que en cualquier caso implican un proceso, infraestructura y software más complejos. A todo lo anterior, hay que añadir que el usuario cada vez tiene más acceso a su “expediente” de alguna forma (sea ante la Administración de Hacienda para ver las declaraciones, ante la operadora de telefonía o ante la compañía de seguros) lo que aumenta el número de usuarios del sistema desde unos pocos usuarios internos a miles de usuarios potenciales, con las implicaciones de seguridad, formación y rendimiento.

Múltiples formatos: A todo lo anterior, hay que añadir que los documentos pueden estar en múltiples formatos. Puede almacenarse un contrato como grabación de audio mp3, un parte de accidente puede contener un video como mp4 y desde luego podemos tener documentos en diversos formatos de imagen (tiff, png, jpg,..) o documentos ofimáticos (pdf, docx, odt, xls,..). Pero es que además, para “rizar el rizo”, cada uno de esos formatos suele tener múltiples variantes, como ha sufrido todo el mundo, al intentar abrir documentos ofimáticos (incluso con software del mismo fabricantes) que se distorsionan o no pueden abrirse, o al comprobar las múltiples variantes de codificación de ficheros del mismo formato/extensión, ya sea de audio, video o imagen. Esto obliga a un esfuerzo de conversión/normalización al recibir, visualizar o enviar, o incluso al procesar en las distintas piezas del proyecto (por ejemplo puede ocurrir que el escáner o dispositivo multifuncional solo genera imágenes tiff en formato lzw, el componente de clasificación REQUIERE tiff en codificación CCITT G4 y el programa de visualización REQUIERE tiff en codificación jpg).

Transversalidad: El último aspecto de la complejidad es la transversalidad. Otros proyectos tecnológicos pueden estar más acotados a un área o departamento, pero los proyectos de gestión documental, por su propia esencia, rápidamente se extienden e implican múltiples áreas (horizontales y verticales). Por ejemplo un proyecto de digitalización de expedientes afectará, por supuesto a la propia área implicada que maneja esos expedientes, pero también a Logística (al variar el volumen de papel almacenado al momento y en su caso al transporte o valija usado), a Seguridad (al tener que definir un modelo de seguridad nuevo), a Legal (ya que hay que revisar si los documentos están cubiertos por alguna normativa), a Marketing/comunicación (ya que si se diseña correctamente los documentos y formularios que genere la institución, puede automatizarse enormemente el tratamiento automático de los mismos cuando se reciben digitalizados, llegando incluso al 95% ) y  además a otras áreas, ya que lo más habitual es que se compartan documentos entre expedientes  de diversas áreas, que deben coordinarse por eficacia y eliminación de duplicidades.
Por ejemplo si se contrata un seguro de hogar y un seguro de automóvil, no tiene sentido que se solicite varias veces el documento de identidad y otros documentos, aunque la gestión la lleven diversas áreas, o el paradigma que se ha planteado repetidamente de que “la administración no debe pedir al ciudadano documentos que ya tenga de él”.

Es normal que, con todo lo anterior, los proyectos sean complejos y las herramientas sean complejas. Para poder realizar un buen diseño hace falta que tanto los profesionales que diseñan el sistema/servicio (ya sean internos o externos) como los usuarios que solicitan/adquieren el proyecto o actúan de patrocinadores del mismo, dominen el tema o al menos tengan una visión clara de su complejidad e implicaciones.

Lo que nos lleva al siguiente punto.

Desconocimiento:

Ante un escenario tan complejo, lo lógico sería acudir a especialistas y estudiar con detenimiento el problema y sus soluciones, sin embargo, todos manejamos documentos en papel, escribimos documentos ofimáticos, tomamos fotos y guardamos documentos en carpetas del ordenador, lo que crea una errónea sensación de dominio.
Empezando cronológicamente por el primer eslabón de la cadena, los usuarios de la entidad que requeriría el sistema, es habitual que se desconozca tanto las posibilidades técnicas que ofrecen las herramientas y tecnologías actuales, como las normativas aplicables o las recomendaciones y estándares internacionales. El resultado es que lo que se solicita en ocasiones no es lo que realmente necesita la entidad.
Esto se complementa con que en ocasiones la empresa que realizará el proyecto no aclara las dudas o alternativas y a veces directamente no propone la solución adecuada (ya sea por desconocimiento o por vender SU solución).
Si la empresa encargada del proyecto no cuenta con técnicos especialistas en gestión documental, es posible que, aunque cuente ton técnicos excepcionales, no construyan una buena solución debido a las complejidades antes indicadas, así como a la riqueza y complejidad de desarrollo de muchas de las herramientas.
Finalmente, el despliegue de las soluciones por parte de los administradores, debido a los volúmenes y rendimientos implicados, requiere un ajuste y dimensionamiento adecuado de los servidores e infraestructura, para lo que se requiere, de nuevo, cierta especialización.

Por supuesto que hay usuarios con las ideas muy claras y gran conocimiento de la gestión documental, buenas empresas con grandes técnicos, y administradores de los sistemas capaces de obtener buenos rendimientos, pero no es el caso mayoritario, y además no siempre coincide, de forma que aunque quien solicita una solución la especifique bien, no siempre se construye tal como se deseaba, o en ocasiones un técnico bien conocedor de la gestión documental se ve obligado a construir una solución poco adecuada por exigencias del usuario.

Inercia:

Finalmente, para acabar de crear la “tormenta perfecta” debemos contar con la inercia humana.
En lugar de aprovechar la implantación de una solución documental para hacer una reingeniería de los procesos y para aprovechar las posibilidades que ofrecen las diferentes herramientas, se suele trasladar un modelo existente, basado en papel, a un soporte electrónico. Lo que en ocasiones es incluso menos eficaz que el original.
Mientras, algunos ciclos universitarios de documentación siguen dedicando muchas más horas a asignaturas como "Paleografía"  o "Archivos Históricos", que a "Gestores Documentales", "Clasificación Automática de Documentos", "BPM" o "formatos de imágenes y documento", lo que no ayuda a enfrentarse a un proyectos cada vez más "tecnológicos" y complejos.
A ello se une la dificultad por parte de los usuarios finales de los sistemas a adaptarse al nuevo circuito, generalmente motivado por varias causas: Desconfianza del sistema, falta de formación, inercia en la forma de trabajo y mal diseño de los sistemas. Seguro que no soy el único que ha visto personas digitalizar expedientes e introducirlos en un circuito documental y ADEMAS hacer una fotocopia para “quedárselos por si hay problemas y no se encuentran o no se puede acceder al gestor documental”.
Sin una formación a los usuarios y participantes de todos los niveles y una gestión del cambio adecuada, incluso el proyecto mejor diseñado puede fracasar.


El triste resultado de la combinación de todos los factores anteriores es que la Gestión Documental sigue sin “arrancar” totalmente. Se llevan a cabo menos proyectos de lo que sería esperable y en muchos casos con una mala calidad que solo sirven para descorazonar a los usuarios y aplazar de nuevo.

Esperemos que este nuevo año 2018 traiga un príncipe o princesa que "bese" a la gestión documental, rompa la maldición y despierte a la gestión documental de ese sopor en que lleva tanto tiempo....
   :-)