Digitalización exitosa

La digitalización se plantea muchas veces como una actividad extremadamente
simple. Lamentablemente no es así y este reducionismo hace que muchos
proyectos no tengan éxito. Alternativamente la digirtalización exitosa
requiere un diseño como un proceso complejo con múltiples activades

Si es exitosa, la digitalización, actividad por la cual se pasa a un formato digital, la información que residía previamente en otro medio, típicamente el papel, el resultado visible y tangible tiene que ser, más allá del cambio de formato o de media, la mejora sustancial de la eficiencia con que se realizan los procesos de manejo de esa información. Para la institución donde la actividad se realiza debe haber un antes y un después, un cambio tan grande en el funcionamiento que no cabe la duda el sentido que tiene la actividad recién realizada. Lamentablemente, como apuntamos la semana pasada, esto no siempre ocurre, por lo que vale la pena preguntarse cómo es que se garantiza que en un proyecto que incluye un componente de digitalización el resultado sea exitoso.

La respuesta tiene que ver con una lista de tareas que deben incluirse dentro de los  procesos. Cuando estas tareas se realizan, luego de la digitalización la información digitalizada es efectivamente recuperada en forma cotidiana por las personas que la requieren, en el momento y forma en que la necesitan. Cuando se subestima la digitalización y se trabajan con una planificación incompleta, la magia no ocurre, y la digitalización produce el cambio de formato, pero no pasa nada trascendente institucionalmente.

Entre las actividades que deben incluirse están, así pues, las siguientes:

1. Diseño de Arquitectura de información
2. Planificación del proceso de digitalización
3. Definición de políticas de organización, digitalización y registro.
4. Conformación de unidades de organización, registro y digitalización.
5. Establecimiento de ruta de documentos.
6. Instalación de equipos.
7. Pueba de imágenes.
8. Entrenamiento.
9. Producción con aseguramiento de la calidad.
10. Fiscalización.
11. Soporte técnico.
12. Certificación de calidad de base de información final.
13. Entrega de base de información 
14. Retiro de equipos
15. Garantía

El sólo examen de la lista permite apreciar lo complejo de un proceso que requiere estas quince actividades, donde la producción o captura digital es sólo una de ellas y además debe se calificada con aseguramiento de la calidad.

Por ahora cerremos con el mensaje de que en esta lista todas las actividades son necesarias y dejemos para una siguiente oportunidad el trabajo de explicar el aporte de cada una de estas tareas en el proceso de digitalización exitoso.

La digitalización no siempre funciona

Muchos proyectos requieren de un trabajo de digitalización
 de volumen. Lamentablemente no siempre se logran resultados exitosos.
(Imagen tomada de http://www.toonpool.com/cartoons/Digitalization%21_8897)

Es común en la transición, desde un mundo donde la cultura estaba basada en el almacenamiento en papel a un mundo donde el almacenamiento es digital, que muchos proyectos de gestión de información incluyan, como una parte del trabajo, la digitalización de miles, decenas de miles, centenas de miles o, incluso, millones de páginas. Hay una nueva solución de gestión digital de información y la idea natural, así pues, es poder transformar la operación de los archivos para manejarlos digitalmente. Una parte del trabajo resulta directo: La información que se va produciendo se almacena ahora en bases de datos. Pero el caso es que en numerosas ocasiones se requiere el manejo, de forma similar, de la información que se gestionaba a través de archivos donde, hasta el presente, documentos y transacciones descansan en soporte de papel. La solución del problema se menciona en forma simple: “Hay que digitalizar”… pero hay muchos detalles en el camino.

Hay tantos detalles que muchos proyectos de digitalización bien intencionados no logran sus objetivos y realmente no mejoran el funcionamiento, con lo cual toda la inversión realizada de recursos y de tiempo se convierte en un fracaso. Sucede mucho más de lo que uno muchas veces se imagina, lo cual expresa que hay alguna complejidad en la digitalización que no es conocida por muchos gerentes responsables de servicios de información. Afortunadamente también hay los casos donde las cosas se hacen bien y los resultados son impresionantemente buenos.

¿Cuál es la diferencia? ¿Cómo se debe hacer un buen proyecto de digitalización? ¿Qué debe ocurrir en ellos? ¿Cómo se gestiona la calidad en este tipo de proyectos? Entremos en estos temas en este post y en algunos de los siguientes.

Dos cosas deben distinguir el resultado de un buen proyecto de digitalización:

1.       La información crítica digitalizada debe ser confiable en un altísimo porcentaje

2.       Se debe agregar valor en la información digitalizada

Para conseguir ésto los proyectos de digitalización deben ser muy bien planificados y desarrollados. En la práctica hemos visto que muchas veces se falla en todas las fases, en la planificación, en el diseño de las actividades y en la ejecución.  Algunos proyectos comienzan a desviarse desde que son formulados. De hecho la digitalización debe entenderse como una actividad, la gestión digital para una mejora del funcionamiento es (o debe ser) la meta a perseguir.

En el inicio de un proyecto de gestión digital hay, consecuentemente, algunas preguntas que contestar: ¿Cuál es la información crítica que debe ser digitalizada y cuál es el porcentaje de confiabilidad que debe tener la información digitalizada?

Hablamos de la información crítica porque muy probablemente no toda la información tiene que ser digitalizada y entre la que requiere el manejo digital hay información que es absolutamente necesaria que sea fidedigna e información que tiene un peso relativamente menor en el funcionamiento institucional o en la atención de casos. La calidad de la digitalización se gestiona, pero involucra recursos y, en última instancia, esto se traduce en costos de proyecto. Por eso la respuesta no es tan simple como plantearse digitalizar todo o el plantearse hacerlo siempre con un 100% confiabilidad.

Por eso es pertinente preguntarse, en lugar de dar por obvio, el para qué queremos manejar esta información en forma digitalizada. De qué forma agregamos valor. Esas son, en el inicio, las preguntas fundamentales a responder en un proyecto de digitalización.

Roles en el servicio de digitalización

La captura digital puede requerir equipos especiales, pero la digitalización
 de volumen de miles, o centenares de miles de páginas,
es un proceso complejo que requiere el concurso de diferentes roles
cuyo trabajo se suma para obtener un resultado de calidad

Muchas nuevas soluciones de gestión digital de información implican resolver la transición al espacio digital de la información que antes se manejaba en papel. Esto puede significar la captura digital de miles o centenares de miles de páginas. Son tareas adicionales, casi completamente paralelas al desarrollo y a la implementación de la nueva solución y un trabajo especializado de un tipo diferente y por ello requieren de nuevos roles, que definiremos en este post para complementar las conversaciones recientes sobre los roles en los equipos de desarrollo y los roles de contraparte.

Cuando el proyecto en desarrollo incluye la digitalización de un conjunto significativo de registros se requiere una actividad de captura digital estructurada, esto implica personas que digitalicen, que cataloguen, que transcriban, que clasifiquen, que aseguren la calidad de la digitalización y de la transcripción y que coordinen el servicio. Particularmente importante para el éxito de un proyecto de digitalización de volumen es la planificación del proceso y el diseño de las normas de digitalización.

Los roles típicos son, así pues, los siguientes:

Coordinador de Servicios de Digitalización/ Transcripción
Es la persona que funge como responsable en forma integral de la ejecución del servicio de Digitalización/ Transcripción. Es un rol comprometido con la ejecución de la actividad en todos los aspectos involucrados: tecnología, procesos y gente.

Analista de procesos de digitalización
Es la persona que debe analizar las necesidades particulares del proceso de digitalización, definir el proceso específico requerido y escribir las normas de digitalización.

Digitalizador
Es la persona responsable de la captura digital, del convertir los documentos originales en el formato digital convenido en las normas de digitalización.

Catalogador/Transcriptor
Es la persona responsable de registrar los campos de información acordados, usando las herramientas definidas en el proyecto: Una aplicación desarrollada, una hoja de trabajo genérica, una Plataforma o Manejador de Información y/o Documentos, etc.

Clasificador
Es la persona responsable de la valoración y clasificación de registros que son sometidos al proceso de digitalización. Debe tener criterios claros para que el resultado de su actividad sea adecuado.

Aseguramiento de la calidad de la digitalización/ catalogación/  transcripción
Es la persona responsable de asegurar los compromisos establecidos en el proyecto sobre la calidad de la información digitalizada, catalogada y transcrita.

Aseguramiento de la calidad de la clasificación/indización
Es la persona responsable de asegurar los compromisos establecidos en el proyecto sobre la calidad de la clasificación/indización de la información procesada.

Los roles de contraparte

Para tener éxito en una nueva aplicación siempre se requiere
 la motivación y la participación de los usuarios

A veces leemos algunos textos donde se habla del desarrollo de aplicaciones, de las tareas y las personas como si el trabajo de desarrollo fuera un trabajo exclusivamente técnico y fuese posible obtener buenos resultados sin una clara participación de los usuarios en ello. Pero las cosas no son así y sin una participación de los usuarios no se llega a la meta de tener aplicaciones bien hechas, que cumplan con todos los requisitos de diseño, que dejen a todos satisfechos y que entren efectivamente en producción, mejorando el hacer cotidiano en algún lugar. Continuando pues la conversación sobre roles hablaremos hoy de los de contraparte.

A los roles típicos en los equipos de desarrollo que definimos la semana pasada vamos pues a sumar tres roles muy diferentes, del lado de los usuarios. Ellos complementan el trabajo de los desarrolladores: la Contraparte institucional, la Contraparte representante de la unidad informática y la Contraparte representante de los usuarios.

Contraparte institucional
Es la persona que hace el trabajo de representar formalmente a la institución u unidad que se convertirá en usuario de la aplicación que se desarrolla. Es responsable de fungir como contraparte del proyecto en términos contractuales, si el caso involucra una contratación externa. Si el desarrollo es intra institucional es responsable por el lado de la unidad que recibirá el desarrollo, del seguimiento de los acuerdos y de los compromisos contraídos durante todo el ciclo de vida de la aplicación.

Contraparte representante de la unidad informática
Es la persona responsable de validar el cumplimiento de los requerimientos provenientes de la unidad de informática de la institución, entendiendo cuál es el sentido de esto ya que el objetivo final debe ser la satisfacción de las necesidades de los usuarios y no los intereses técnicos de los informáticos.

Contraparte representante de los usuarios
Es la persona responsable de colaborar en la extracción del conocimiento tácito de los usuarios finales de la aplicación. Valida en nombre de ellos el cumplimiento de los requisitos y mantiene permanentemente una comunicación estrecha que proporciona feedbacks de usabilidad a los desarrolladores.

Típicamente se requieren los tres roles en una relación de colaboración muy cercana con quienes trabajan en el diseño y construcción de la aplicación. Un proyecto no se puede realizar sin la participación entusiasta y decidida de los usuarios. No se trata simplemente de encargar, esperar y recibir. El trabajo debe ser conjunto y cooperativo. Cuando no es así, los resultados no son buenos.

Un aspecto muy importante a tomar en cuenta es que la participación de los usuarios genera identificación y motivación y eso se requiere para que haya el interés en los cambios de prácticas que se introducen. Toda aplicación nueva involucra maneras distintas de hacer las tareas cotidianas. Muchas veces se habla resistencia al cambio, pero en realidad, el problema se origina en que desde que se inició el desarrollo no se trabajó con los usuarios y por ello éstos no sienten suyo los resultados de un proyecto que creció sin ellos.

Otro problema típico que se presenta es el que ocurre cuando los usuarios, en cualquiera de los roles definidos arriba, no se involucran como colaboradores sino como jueces. En realidad, las cosas sólo salen bien si hay cooperación en lograr la nueva aplicación. Es muy difícil imponer desde arriba un cambio de prácticas. Es mucho más sencillo y productivo el trabajo colaborativo.

Los roles en los equipos de desarrollo

Un rol es una definición de una papel que debe desempeñarse. Hay roles
que típicamente son necesarios cuando se desarrolla una aplicación de
teleinformación

La semana pasada entramos en el tema de los roles y mencionamos como es importante entender los que son necesarios cuando se desarrolla una aplicación de teleinformación y se quieren hacer las cosas bien con el objeto de lograr un resultado que sea una solución de excelente calidad, que cumpla con todos los requisitos planteados. Continuando esa conversación presentamos en este post alguna definiciones sucintas de un poco más de una docena de roles típicos en los equipos de desarrollo. Dejamos para otra oportunidad los roles de contraparte.

Líder de Proyecto
Responsable de la gestión del proyecto, de los acuerdos formales e informales, del cumplimiento de fechas, de la comunicación entre los equipos involucrados y la actualización del sitio Web del proyecto durante todo el ciclo de vida de la aplicación.

Gerente de cuenta
Responsable de la relación institucional entre las contrapartes durante la vigencia de los acuerdos que las vinculan.

Planificador del Proyecto
Responsable de la planificación del proyecto. En particular, de las estimaciones preliminares de recursos.

Revisor de la Planificación del Proyecto
Responsable de revisar la planificación del proyecto y su conformidad con la experiencia acumulada en las ejecuciones previas.

Especificador de requisitos
Responsable de recabar toda la información pertinente, organizarla, hacer la especificación detallada de los requisitos de la aplicación, determinar los casos de uso.

Revisor de las definiciones de requisitos
Responsable de revisar la consistencia formal y semántica de las definiciones detalladas de los requisitos y casos de uso.

Analista de procesos de información
Responsable de analizar la información recabada y los requisitos para, a partir de allí, conceptualizar el problema de gestión de información que se quiere resolver.

Diseñador de la base de información
Responsable de traducir la solución planteada al problema de gestión de información en los términos del modelo preliminar de la base de información.

Revisor del diseño de la base de información
Responsable de revisar la consistencia formal y semántica del modelo preliminar de la base de información.

Desarrollador de la Aplicación
Responsable de traducir el modelo preliminar de la base de información en un prototipo ejecutable.

Coordinador del desarrollo
Responsable del equipo de personas a cargo de la implementación del prototipo y de asegurar que se cumple con los objetivos del diseño y se satisfacen todos los requisitos planteados.

Revisor del desarrollo
Responsable de revisar la implementación del prototipo y el aseguraramiento de que se satisfacen los procedimientos de verificación establecidos.

Diseñador de la experiencia del usuario
Responsable de conceptualizar la experiencia del usuario con el sistema: usabilidad, navegación y estética.

Revisor de la experiencia del usuario
Responsable de revisar la experiencia del usuario con la aplicación y contrastarla con las buenas prácticas en el área.

Documentador del sistema
Responsable de escribir la documentación específica que será entregada con la aplicación.

Revisor de la Documentación del Sistema
Responsable de revisar la documentación específica que será entregada con la aplicación.

Asegurador de la calidad
Responsable de garantizar que la calidad de proyecto está alineada y se gestiona de acuerdo con las buenas prácticas y los procesos organizacionales de aseguramiento general de la calidad de la organización que desarrolla y que, de acuerdo con ello, cada proyecto contribuye al mejoramiento continuo de los desarrollos emprendidos.