De un tiempo a esta parte se hace evidente que la implementación de procesos de negocios, y por ende la incorporación de BPM, tiene su eslabón más débil en las comunicaciones entre las personas que participan del proyecto, y que posteriormente usaran o debieran usar el proceso implementado. Asunto que se evidencia en la dificultad de articular proyectos BPM en las empresas.
Para confirmar la existencia de esta brecha comunicacional esta tenemos la información provista por Office of Management and Budget (OMB) del Gobierno de los USA, que señala en la tabla siguiente la cantidad de proyectos en curso (lo más grandes) en la columna “Number of major federal IT projects” y la cantidad de éstos en la Watch List. Esta es una lista que incluye todos los proyectos en curso que “tienen una o más debilidades en su planeamiento” [1], de modo que por extensión podemos decir “tienen fallas de comunicación en sus definiciones”.
De la tabla se desprende que para el año 2009 el 72% de los proyectos está en la “Wach List”, y están básicamente por razones de complejidad, política y duración.
Detrás de cada una de estas razones, sostengo, que existe un problema comunicacional, algo no quedó bien especificado o con un diseño insuficiente o con una evaluación técnica incompleta o con temas de poder no resueltos.
¿Están los Usuarios comunicándose con los Consultores?
No obstante que en los últimos diez años ha habido avances notables en el mejoramiento de la tecnología, no mucho ha cambiando en la manera de hacer las cosas en estos mismos diez años. La mayoría de los usuarios y los consultores (implementadores y desarrolladores) están de acuerdo que hay intentos por generar una vía de comunicación más adecuada entre ellos, pero los intentos a la fecha han resultado poco satisfactorios [2]. Por tanto cabe preguntarse:
- ¿La actividad de implementar y desarrollar sistemas es una actividad técnica solamente?
- ¿Están los usuarios definiendo sus necesidades?
- ¿Están los consultores escuchando?
- ¿Qué mecanismos debieran existir para promover una comunicación efectiva entre los usuarios y los consultores?
¿La actividad de implementar y desarrollar sistemas es una actividad técnica?
Tradicionalmente el quehacer de, al menos, programar se ha considerado un trabajo técnico altamente especializado, y que es realizado por programadores que utilizan una jerga incomprensible para el profano. En mi experiencia, si nos remontamos a los años 70, esta aseveración reflejaba bastante bien la realidad. Cuarenta años después, si Ud. no es especialista y trata de comunicarse con un programador Java o de cualquier otro lenguaje sobre sus desarrollos, se encontrará con una situación bastante parecida. Esta realidad parece confirmar, por extensión, que la actividad de hacer sistemas, es una meramente técnica.
Sin embargo, salvo casos particulares, en las empresas los sistemas son solicitados por la gente del negocio a los informáticos, y esta acción de solicitar es un acto comunicacional, cualquiera sea el modo que se exprese: una conversación, una especificación o un diagrama. La partida es que alguien del área del negocio le “pide” al área de informática un sistema para que le resuelva algo.
Con esta simple constatación del día a día del quehacer de un Informático, podemos establecer que el meollo de un buen sistema es si éste interpreta bien lo que la gente del negocio “pidió”. Esta realidad da origen a cuestiones que al final se traducen en una permanente tensión en los proyectos de implementación, cuya solución burocrática es: Lo que no está escrito no vale. Y, de aquí en adelante en desencuentros entre las partes, que terminan reflejándose en un proceso o sistema pobremente implementado, desde la perspectiva del usuario.
Entonces aparece la necesidad de formalizar lo que la gente del negocio “pide”. Asunto que se traduce, fundamentalmente, en métodos que utilizan los Informáticos para estructurar en algún documento lo que “pide”, el ahora usuario. En el formalizar y construir esta documentación, muchas veces precaria, se parte de la base que el usuario tiene absoluta claridad de lo que necesita, y que el diseño es responsabilidad del Informático, quien conoce del tema planteado por la petición del usuario. Suposiciones que sabemos no se dan frecuentemente.
Hasta ahora, en este proceso, no han participado los programadores, lo han hecho los analistas de sistemas o los consultores. Esto lleva a que los programadores reciben una especificación del consultor, que se a su vez es una interpretación de lo que entendió del requerimiento del usuario, con el consiguiente error por pérdida de información.
Visto lo anterior, al menos podemos decir que si la petición está bien recopilada existe una buena posibilidad que el sistema cumpla con las necesidades de la gente del negocio. Caso contrario estamos en dificultades.
¿Están los usuarios definiendo bien sus necesidades?
“Los usuarios a menudo tiene dificultades para comunicar sus necesidades porque no saben que podría mejorar su trabajo o proceso – ellos no están enterados de las capacidades de las nuevas tecnologías y tienen muchas complicaciones para expresar sus requerimientos en un lenguaje tecnológico” [2].
Los usuarios expresan sus necesidades en términos de fallas o carencias, un determinado sistema no resuelve una condición de la operación o la resuelve parcialmente. O, a la fecha tiene un conocimiento parcial de su proceso de negocios; asunto que queda en evidencia por la cantidad de órdenes de mantenimiento que generará una vez con el sistema en uso.
Por otra parte los métodos de levantamiento de requerimientos no siempre cuentan con la participación comprometida de los usuarios ni con consultores con la experiencia, métodos y herramientas necesarias.
¿Están los consultores escuchando?
Asumiré que efectivamente los consultores están escuchando, porque por metodología tienen que hacer los levantamientos de requerimientos, modelamiento, o business blueprint . ¿Entonces por qué seguimos teniendo proyectos con problemas y sistemas que no responden a las expectativas de los usuarios?
Si un consultor, por ejemplo, utilizó diagramas VAC y EPC para modelar un sistema y después este no incluye toda la funcionalidad que el usuario espera. ¿Dónde está el error? La respuesta típica es “el usuario al momento del levantamiento no me mencionó estás funciones”. O, “el consultor no entendió lo que le explicamos”. Y, otra menos frecuente pero, honesta: “Es que recién nos percatamos”.
Mi conclusión, es que existiendo la conversación entre los usuarios y los consultores para establecer el alcance del requerimiento. Y, entendiendo que existen tanto las metodologías como las herramientas para especificar y diseñar un proceso de negocios; la dificultad está en la manera de hacer la conversación, en la dinámica de la interacción y en el sentido de propiedad con respecto al éxito de la implementación del sistema.
¿Qué mecanismos debieran existir para promover una comunicación efectiva entre los usuarios y los consultores?
No pretendo aquí dar solución a este problema, pero me parece que hay un camino pragmático y otro académico, para este efecto estoy partiendo del siguiente enunciado:
“Por medio de programas, los usuarios se comunican con otros usuarios, los diseñadores se comunican con los usuarios y los programas se comunican entre sí … Son esencialmente mensajes, representaciones de los significados generados por usuarios y programadores” [3]
Entonces, desde un punto pragmático el tema es como, quienes tenemos responsabilidades con la Tecnología Informática, hacemos que los usuarios y los diseñadores (consultores y/o programadores) establezcan una nueva forma de conversar para generar significados –requerimientos- que efectivamente representen sus procesos de negocios. En términos prácticos:
- ¿Cómo motivamos a los usuarios a participar en el diseño de sus procesos de negocios?
- ¿Qué métodos necesitamos disponer para contar con la efectiva participación de los usuarios en diseño de sus procesos de negocios?
- ¿Cómo implementamos el co-diseño?
- ¿Cómo separamos lo permanente de lo temporal (métodos, modas, herramientas, buzzwords)?
- ¿Cómo incluimos en el currículo de la gente de negocios el conocimiento general para utilizar el diseño y mejoramiento de los procesos de negocios como una acción de Innovación?
En cuanto a la solución desde un punto de vista académico, es un tópico que le corresponde resolver a las universidades y centros de investigación. Y, en mi opinión necesita el trabajo multidisciplinario de los especialistas en Management, Psicólogos, Informáticos y expertos en BPM, entre otros.
Referencias
[2] http://www.jmu.edu/cisr/journal/7.3/focus/townsend/townsend.htm
[3] Prof. Clarisse Sieckenius de Souza, Departamento de Informática, PUC-Rio
Estimado,
He leído un par de artículos de su blog y me parecen muy acertados sus comentarios, felicitaciones por eso!.
En mi opinión las brechas comunicacionales entre los distintos actores que participan de un proyecto software se ven afectadas por el criterio personal de cada participante del proyecto y de los intereses particulares acerca del objetivo de cada una de las etapas. Un alto directivo querrá ver hitos cumplidos dentro de las fechas, un gerente de proyecto presionará por obtener minutas firmadas con los apuntes que lo ayuden a presentar confirmaciones de parte de los lideres usuarios al cumplimiento de estos hitos (termino de fases, etc.), los lideres usuarios presentarán sus requerimientos al analista correspondiente con la idea preconcebida de que existen obviedades que no es relevante detallar en mayor medida (considerando el tiempo que requeriría dicha especificación que limita su disponibilidad para labores del negocio) y así continua la cadena con pretensiones enfocadas en terminar las etapas y cumplir obligaciones particulares sin un correcto “aseguramiento de la calidad” del software que debería ser el eje principal durante todas las etapas del proyecto.
No digo que las razones expuestas en párrafo anterior no sean validas, pero falta elevar la calidad del software al mismo nivel de estas, ¿cómo se logra? como varios son los factores, la solución pasa también por varias alternativas, pero creo que poner sobre la mesa la importancia de priorizar la calidad a todos los actores de un proyecto software es un buen comienzo (aterrizando esta priorización en productos esperados que sean «medibles» ante todos los actores).
Qué opinas al respecto Mario?
saludos
Claudio Vásquez