El proceso a seguir.

El proceso a seguir. Problemas en la definición de procesos.

por Luis R. Cuellar el 25 de septiembre de 2007

Visitas: 61

Calificación promedio: (0 voto)

En nuestra charla anterior hablamos sobre el significado de crear una organización orientada a procesos con el objetivo de generar resultados repetibles en forma eficaz y eficiente, facilitar la comunicación y generar un “framework” para administrar el conocimiento. Esto suena muy bien, pero si es tan buena idea, ¿por qué no se hace en todas las compañías? Esto se debe a problemas tanto de definición como de implantación. En esta ocasión hablaremos de los problemas de definición y en nuestra siguiente charla hablaremos de problemas de implantación.

El Proceso Perfecto

Un elemento que he encontrado en forma consistente en el área de sistemas, es lo mucho que nos maravilla definir procesos, y a su vez la gran falta de entusiasmo para operar los mismos. El mercado está lleno de consultores, libros, maestros y “jefes” de corazón, vendiendo la solución a todos nuestros problemas. Esto sugiere la idea de que existe un conocimiento mágico, un proceso perfecto o una única solución al problema de desarrollo de software. Creo que esta por demás decir que este proceso, ¡NO EXISTE!

En los últimos años he apoyado a varias organizaciones a alcanzar niveles de CMM y Seis Sigma. Una estrategia que he visto comúnmente es la de juntar a los grandes expertos de la organización para definir la metodología perfecta que servirá de guía sobre lo que tienen que hacer todos los demás. Esta estrategia tiene tres riesgos importantes:

1. Existen pocos incentivos a escuchar lo que actualmente sucede en los proyectos. La premisa de estos grupos acostumbra ser: “Todo lo que hacemos actualmente está mal y tenemos que definir algo nuevo para arreglar todos nuestros problemas”. Lo ideal es iniciar con aquello que actualmente funciona, asegurar que entrenamos a toda la organización para hacer el trabajo de la misma manera, y sólo cuando no estamos haciendo algo para controlar una práctica clave debemos definir algo nuevo. En la práctica, el problema de definir un proceso es diez por ciento del problema de implantarlo, por lo que si ya existe y se conoce es mejor sólo documentarlo.

2. Los nuevos procesos ya no se mejoran posteriormente. Después de todo, ¿quién puede mejorar el proceso si los mejores ya lo definieron? Desafortunadamente el proceso perfecto no existe, una de los características básicas de la definición debe de ser su facilidad de modificarse. Desde la definición se debe de estar consciente de la importancia de definir algo flexible y fácil de modificar, que se adecue a la problemática actual y futura.

3. La definición se tarda meses y después ya nadie tiene tiempo de implantar los procesos en la organización. El que define debe continuar con la implantación. Si la dirección define, es porque ellos van a implantar. Sino, entonces no deberían estar definiendo.

Otra estrategia es la de comprar un proceso en el mercado e implantarlo en la organización. En este caso es vital contemplar cómo se capacitará o modificará el proceso una vez que el consultor termine su trabajo.

En este punto permítanme ser lo más claro posible: NO EXISTE EL PROCESO PERFECTO. Muchas veces es mejor implantar un proceso que toda la organización esté dispuesta a seguir, en lugar de uno que un consultor diga que es el mejor proceso jamás generado. En el momento en que estamos cambiando a una organización orientada a procesos, estamos trabajando con la idea de que estos procesos son dinámicos, por lo que se requiere gente encargada de mantenerlos actualizados constantemente y entrenando a los equipos de trabajo en forma constante.

BestPractices

Personalmente siento que el término “BestPractice”, es uno de los grandes frenos de la industria de software. Creado con finalidad de mercadeo, el término lleva consigo la idea de una “solución mágica” que resuelve tus problemas; que de todas las soluciones que existen en el mundo, es la mejor. Sin embargo, todas las prácticas tienen un valor con respecto a su contexto. Una práctica que fue exitosa en un ambiente abierto y con pocas restricciones puede ser inoperable en una organización con fuertes niveles de control. Desafortunadamente, cuando queremos definir nuestros procesos, todas estas grandes prácticas se atraviesan en nuestro camino generando dudas, ya que queremos que lo que definamos suene impactante cuando lo presentemos a nuestros clientes y empleados.

Conclusión

Lo que busco decirles con todo esto es: no existe un proceso perfecto; no existe la solución mágica que sólo tengan que copiar y obligar a su gente a seguir. El mejor proceso que podemos definir es uno que sea sencillo de aprender, operar y fácil de mejorar, que controle de alguna manera el trabajo que hacen actualmente, y que las personas estén dispuestas a implantar ellos mismos en sus proyectos. La próxima ocasión platicaremos sobre la implantación de los procesos, sus problemáticas y cómo beneficiarse al máximo de la estrategia de implantación.

Acerca del autor

Luis R. Cuellar es Director de Calidad a nivel mundial de SofttekInformation Services. Luis esreconocidopor la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

BPM. Desde la Perspectiva de un Desarrollador.

por Ernesto Méndez Solís el 21 de noviembre de 2007

Visitas: 2228

Calificación promedio: (0 voto)

Como consultor en el desarrollo de software, es muy común ser asignado a proyectos en los que participan consultores de otras empresas formando de esta manera equipos de trabajo interdisciplinarios y multiempresa; unos se encargan de la administración y metodología del proyecto, otros más del análisis, diseño, modelación, desarrollo, documentación y pruebas, por mencionar solo algunas de las diferentes tareas involucradas. Fue de esta manera que fui asignado a participar en un proyecto en el que había que automatizar el flujo de un proceso administrativo de una empresa dedicada a la comercialización, industria perteneciente al sector conocido como retail.

Así que me integré al equipo, que estaba conformado por tres diferentes empresas y fui asignado a la fase de desarrollo. Solo requería tener conocimientos básicos de programación orientada a objetos y experiencia en el análisis, diseño y desarrollo de sistemas. La herramienta que se iba a utilizar para este desarrollo se llamaba Fuego. En mi vida había oído hablar de esta herramienta, por supuesto que no se requería experiencia, se dedicaría un periodo inicial para capacitar a los desarrolladores antes de iniciar formalmente el proyecto. Así fue como conocí el concepto BPM. Fuego, es mas que una herramienta de desarrollo, es un ambiente de trabajo. Este ambiente de trabajo, se puede dividir a su vez en dos: el ambiente de producción y el ambiente de desarrollo y configuración. Estos están basados en aplicaciones comunes a los ambientes de sistemas: navegadores, servidores web, servidores de bases de datos y servicios de directorio, por mencionar algunos. Algunas aplicaciones propias de Fuego complementan el ambiente de producción y desarrollo: motor de orquestación, portal de trabajo, administrador de componentes, administrador de la organización, diseñador de procesos, consola de ejecución y el analizador de procesos.

Aunque pudieran parecer una gran cantidad de aplicaciones, realmente no es tan complicado preparar el ambiente de operación y desarrollo, inclusive el de desarrollo se puede preparar en un solo equipo para poder trabajar en forma independiente y aislada para posteriormente poder desplegar el proceso en el ambiente de producción.

Recuerdo que en alguna ocasión me tocó programar aplicaciones del tipo “flujo de trabajo” utilizando lenguajes de programación convencionales. Esto representó un reto algo diferente al de cualquier otro tipo de desarrollo, pero nada que impidiera alcanzar finalmente el éxito y la automatización del proceso correspondiente. Sin embargo, los BPMS están específicamente diseñados para automatizar en forma sencilla este tipo de procesos.

La clave del éxito de este tipo de ambientes de desarrollo es el denominado “diseñador de procesos”, la herramienta central del BPMS. Al mismo tiempo, representa el mayor de los retos que los programadores de lenguajes tradicionales enfrentan al pretender automatizar un proceso. En este caso, la clave es “modelar el proceso” tal como se desarrolla en la práctica; lo que implica primero, identificar los diferentes pasos que el proceso incluye para posteriormente, apoyado en una serie de íconos para el modelado, representarlo gráficamente en el diseñador, considerando los participantes en el proceso y los conectores que comunican las actividades o pasos.

Aunque esta representación gráfica del proceso esta diseñada para que cualquier analista de negocio e inclusive ejecutivo participante del proceso lo pueda entender, la construcción o modelado del proceso requiere de un nivel de abstracción adicional al requerido simplemente para su entendimiento. Un elemento fundamental a considerar al momento de modelar es lo que se denomina una “instancia”. Las instancias son las ejecuciones individuales

...