viernes, 22 de febrero de 2013

Analizando la información


Al inicio del proyecto hay que recabar la información,
pero luego hay que organizarla
La semana pasada conversamos acerca de la importante actividad de recolección de información que se necesita al acometer un proyecto de gestión: Hablamos sobre la entrevistas y reuniones con las personas involucradas, la inspección del ambiente físico, la revisión documental sobre los procesos existentes y sobre otros procesos relacionados. Mencionamos el muchas veces necesario inventario documental. Hoy queremos señalar lo que sigue a partir de allí: el análisis. Veremos que no se trata sólo de acopiar información sino de comprenderla, en sus coherencias e incongruencias, lo definido y lo realizado, lo actual y lo posible.

Efectivamente, el obtener la información (Ver: Obteniendo la información) que se requiere para conceptualizar un proyecto de gestión de información no es un fin en si mismo sino un medio para realizar una serie de análisis que servirán para sintetizar los dos productos principales de la primera fase en el ciclo de visa del proyecto: la definición misma del proyecto, su justificación, objetivos, métodos, organización, etapas y estructura, por un lado y el modelo preliminar de información, por el otro (Ver:  Identificación de la solución que se desea).

¿Que se requiere al inicio del proyecto?

En primer lugar el análisis de los procesos de gestión actuales. Bien se trate de un proyecto de automatización, de mejora o de sustitución de los procesos actualmente vigentes es necesario conocerlos en un alto grado de detalles. Para ello hay que tener presente, como dejamos entrever la semana pasada, que siempre puede haber dos versiones de un proceso, el teóricamente definido y el realizado en la práctica por las personas integrantes de la institución en la que se trabaja. De allí la necesidad de explorar lo que piensan y hacen las personas, en entrevistas y reuniones, y la documentación institucional que estable lo que, en principio, debería hacerse.

Después de analizar los procesos de información actuales hay que detectar las necesidades. Las percibidas por los usuarios y coordinadores de los procesos y las que subyacen como necesidades, que no son vislumbradas por las personas involucradas cotidianamente, pero que pueden salir a flote gracias a que el ojo del arquitecto de información experto las puede detectar.

Detección de posibles incongruencias:

Procesos de información actuales y necesidades pueden ser incongruentes. Los procesos pueden estar alineados con las necesidades y de lo que se trata es entonces de aumentar la eficiencia de operación en los mismos o pueden orientarse a implementaciones muy diferentes, por lo que se plantea la obligatoriedad de tomar decisiones sobre cambios más radicales.

Un aspecto muy importante son las mediciones que se realizan en la operación actual. Ellas sirven para aterrizar los juicios sobre los procesos actuales y la conversación sobre las necesidades. Cuando hay mediciones las opiniones y recomendaciones pueden ser más sustentadas y hay un criterio natural para evaluar la mejora. El que no las haya expresa una gran debilidad.

La incongruencias entre procesos actuales y necesidades es la base para proponer nuevos procesos de gestión. Esto supone un cambio y dirige la formulación del proyecto a partir de este punto. De lo que se trata entonces es de crear un nuevo modelo de gestión de información. Para ello son de gran ayuda todas las conversaciones sobre Arquitectura de información, sobre la definición de objetos de información y sobre el mapa preliminar de información que hemos realizado en otras oportunidades (Ver).

viernes, 15 de febrero de 2013

Obteniendo la información

Para realizar un proyecto se requiere recoger y analizar información.
El reto comienza en el saber dónde y cómo buscarla.

Una vez que tomamos la decisión de realizar un proyecto de gestión de información comienza el trabajo de conceptualización. El resultado de la conceptualización será una idea concreta de lo que queremos obtener, un proyecto bien definido y una visión compartida. Lo que la continuará será un modelo de información, el diseño detallado de lo que queremos lograr como cambio situacional en la gestión. Pero no podremos hacer una buena conceptualización o definición del problema a resolver y su solución, y mucho menos, diseñar una gestión apropiada con un modelo sintonizado con las necesidades si no obtenemos la información que se requiere. Por eso, todo proyecto comienza planteándonos el reto de obtener la información. ¿Cómo lo hacemos?

Lo primero que tenemos que preguntarnos es donde está la información que requerimos y cómo podemos obtenerla. Dedicamos este post a este problema.

Es muy común que en una organización, independientemente de todo su patrimonio escrito, los procesos que realmente se ejecutan residen en las cabezas de las personas como parte de su conocimiento tácito, de sus prácticas sociales rutinarias. Esto sucede en forma independiente a la capacidad de estas personas de formular explícitamente el conocimiento implícito en sus actividades cotidianas. De allí que un sitio a donde a hay que ir a buscar la información está los actores claves de los procesos, y un método para extraer la información que suele ser ineludible, es la entrevista.

Muchas veces se requiere también de actividades de grupo diseñadas para poder cotejar datos y relaciones, validando lo que dice uno con lo que dice otro y presentando explícitamente lo que se va obteniendo a todo el conjunto de personas involucradas. Esto no necesariamente es un sustituto de las entrevistas individuales, pero en algunos casos puede reducirlas a las necesarias.

Mucha información puede obtenerse a través de la red y de hecho cada vez mas la actividad de gestión de información puede resolverse a distancia. Hoy día podemos hacer así entrevistas y reuniones de modo que no necesariamente los desarrolladores de un proyecto de gestión de información tienen que ir hasta los lugares específicos. Sin embargo, cada vez que esto sea posible, es altamente recomendable. Hay información que los ojos expertos notan en el lugar y que, como señalamos, a no ser que la visita concreta tenga un impacto significativo en los costos del proyecto, suele ser altamente recomendable porque lo que se ve en los lugares físicos muchas veces le habla elocuentemente a los observadores entrenados en las técnicas de levantar información.

Lo anterior no significa que los documentos que definen explicita o implícitamente los procedimientos organizacionales puedan ser obviados a través de entrevistas, reuniones y visitas al sitio. La buena práctica de levantamiento de información incluye la revisión de la documentación pertinente, a la profundidad requerida por el proyecto, dando tratamiento diferencial a cada documento, según su relevancia para los fines previstos.

Los procesos organizacionales normalmente se continúan o se vinculan con otros que los preceden. Por ello, es una fuente iluminadora de información que puede ser importante examinar, aunque sea rápidamente, es la documentación y las características de los procesos relacionados.

Finalmente, todo proyecto tiene una escala, un tamaño y como la cualidad de cualquier fenómeno cambia cuando cambian significativamente los números que lo definen, suele ser necesario un cierto nivel de inventario o por lo menos un muestreo que proporcione información cuantitativa necesaria para caracterizar el proyecto.

viernes, 8 de febrero de 2013

Identificación de la solución que se desea


La identificación o conceptualización de una solución de
gestión de información requiere de un conjunto de
actividades no secuenciales
La primera etapa por la que se pasa en el ciclo de vida de una solución de gestión de información es la identificación de la solución que se desea. En esta etapa se clarifica qué es lo que se necesita. Tiene que lograrse además que la visión sea compartida por todos los involucrados, los responsables del servicio, los que lo operan en forma cotidiana, los que desarrollarán la nueva solución, los que facilitan el cambio. Ahora bien, identificar completamente la solución requerida no es meramente el producto de una conversación, una reunión o un taller. Es algo mucho más complejo que requiere de una serie de pasos. Tampoco es algo que se desarrolla exactamente como una secuencia de actividades que se ejecutan uno detrás de otra.

Como ocurre con frecuencia, la comprensión de un problema y de su solución se resuelve en procesos iterativos de refinamiento sucesivo en los que se avanza con las observaciones, el análisis y el conocimiento que se desarrolla en cada iteración.

El origen de un proceso de desarrollo de una solución de gestión, como hemos señalado (ver El ciclo de vida de una solución de gestión de información), pueden ser la recopilación y análisis de los datos obtenidos del proceso gestionado actualmente, que muestra ineficiencias que pueden ser corregidas incorporando tecnologías, una necesidad de introducir un cambio en un proceso como consecuencia de otros cambios organizacionales, la conciencia que se tiene de que de ciertos factores exógenos han variado de forma tal que abren la posibilidad de que la institución mejore sus procesos, actividades o resultados si incorpora estos cambios, o algún otro.

La información recopilada es la base del planteamiento de cambio, pero también sucede lo contrario, la formulación de una solución que se desea obliga a mejorar la información base que se tiene para poder manejar todos los detalles requeridos. Es parte de lo que se logra con las iteraciones necesarias.

Cabe la pregunta entonces de cuáles son el conjunto de actividades que deben hacerse en la etapa de Identificación o conceptualización de la solución, al inicio del ciclo de vida que ha de recorrerse y en forma preliminar a la etapa de diseño que le sigue.

La forma concreta de la respuesta puede variar, porque siempre hay consideraciones, conceptos y elementos de lenguaje que dependen de la guía que se siga, la literatura sobre la que nos basemos, la metodología finalmente adoptada pero, independientemente de estas variaciones, una respuesta genérica debe considerar las siguientes actividades:

El levantamiento de información
La definición de la visión
La especificación de requerimientos
Los casos de uso
El modelo preliminar
La estimación de tamaño
El plan de proyecto
El mecanismo de difusión y concertación de ideas y criterios

Nos referiremos más adelante a estos actividades, su caracterización, sus interacciones y sus iteraciones.

viernes, 1 de febrero de 2013

Por qué contratar sólo la conceptualización

Al principio de un proyecto complejo no es fácil estimar
el tamaño del mismo

Muchas veces los gerentes presurosos de resolver un problema de gestión se avocan a formular un proyecto de transformación, de creación o mejora, de un servicio de información existente. El proyecto requiere recursos y numerosas veces la contratación de un ente externo para su desarrollo. Suena razonable contratar pues, con el debido proceso, una organización que lleve a cabo las cuatro etapas naturales del ciclo de vida: Definición, Diseño, Desarrollo e Implementación. Si no se realizan las cuatro, la solución no entrará en producción. Sin embargo, el contratar las cuatro puede ser un problema que conduzca una parálisis peligrosa del proyecto, que puede correr el riesgo de quedar inconcluso. ¿Por qué?

El primer riesgo en un proyecto es el que planteamos la semana pasada: que el mismo se inicie sin una visión compartida entre los desarrolladores y los futuros usuarios y contratantes de la solución. Por ello, independientemente de que su tamaño sea grande o pequeño, es clave asegurar la visión compartida al inicio.

Pero el problema al que nos referimos hoy es otro: Incluso arrancando con una visión compartida, un proyecto puede ir mal, si por sus características, su tamaño, es decir, el esfuerzo que se requiere para realizarlo, es mucho más grande del que se estimó. En ese caso en algún momento será evidente que el proyecto no converge, que los lapsos de tiempo se excedieron, incluso significativamente, y sin embargo, el fin no se ve cerca.

Uno podría pensar que el problema tiene que ver con la inexperiencia de los desarrolladores en la construcción del tipo particular de soluciones acometidas, y hay veces esto es lo que ocurre, sobre todo si la comunicación entre desarrolladores y contrapartes no es fluida. Pero el problema el problema estructural en estos casos es el que nace en una estimación de tamaño inadecuada porque se hace en forma muy temprana, cuando no se tiene consciencia real de la magnitud del proyecto, de la cantidad de relaciones que implica, de los numerosos casos de uso que hay que atender, del complejo modelo de información que hay que construir, de la cantidad de salidas diferentes, de la cantidad de comunidades que hay que tomar en cuenta, etc. Este tipo de error se expresa incluso en procesos licitatorios con aspectos formales muy bien realizados.

El aprendizaje que las organizaciones, instituciones y desarrolladores de soluciones deben tener de este tipo de experiencias, es que aún cuando haya mucho interés en la realización integral de un proyecto, no es conveniente hacer contrataciones integrales a no ser que haya evidencias claras para suponer que el tamaño es efectivamente estimable con una adecuada precisión, o que se haga un acuerdo razonable para el manejo de eventuales imponderables, por ejemplo, a través de una especificación de horas que pueden eventualmente imputarse en forma adicional.

El asunto es estar consciente que sólo se tiene una idea justificada del tamaño del esfuerzo requerido después de realizar la conceptualización de la solución. Antes puede haber muchos aspectos ocultos en la formulación intuida del problema y de la solución.

Otro punto importante en el ciclo de vida de un proyecto es la validación del tamaño estimado después del diseño o modelado de la solución. Efectivamente, en ese momento hay que explícitamente revisar y eventualmente alertar y/o corregir las estimaciones de tiempos de desarrollo.

Puede notarse que todo lo conversado hoy es independiente de la calidad de la formulación del proyecto a ejecutar. Incluso un proyecto bien formulado (en términos formales) puede ser insuficiente para asegurar el éxito cuando se va a contratar. Si la complejidad es real, puede no resultar conveniente (para ninguna de las partes) hacerlo en forma completa. Sólo se debe contratar hasta la implementación cuando sea muy claro lo que se quiere y el tamaño de cada etapa pueda estimarse razonablemente. En proyectos complejos lo mejor es contratar sólo el paso inicial: la conceptualización de la solución, porque sólo después de su realización es cuando realmente se puede tener una idea relativamente confiable del tamaño de la solución.