FASE DE ARQUITECTURA DE PROCESOS, DESARROLLO E IMPLEMENTACION.

FASE DE ARQUITECTURA DE PROCESOS
La fase de arquitectura de procesos es un prerrequisito para cualquier organización que desee sobrellevar actividades relacionadas con el manejo de procesos de manera exitosa de manera ágil y sostenible.

La arquitectura de procesos nos asegura que:
• Los procesos a rediseñar o desarrollar desde cero cumplen con los objetivos de la organización.
• Los procesos están alineados con la manera de hacer negocios y son capaces de proveer productos o servicios a los clientes.
• Los procesos están alienados con la arquitectura y aplicaciones TI.
• Los procesos están alineados con procesos relacionados.
• Toda información relevante y decisiones acerca de los procesos están en un mismo grupo.
• Las decisiones relevantes y los procesos de alto nivel están presentados en una manera fácilmente entendible.

La PAP se desarrolla en una serie de fases como son:
BPM scenario: la criticalidad e intensidad de esta fase será influenciada por el escenario BPM de la organización, como son:
• Administración de procesos “negocios como siempre”.
• El escenario “en la silla del conductor”.
• El escenario proyecto “piloto”.
• El escenario “por debajo del radar”.
La madurez de la organización en arquitectura: la madurez de la organización no solo está relacionada con el nivel de pensamiento de arquitectura y la implementación, sino también a la arquitectura del hacer y la disciplina de ser capaz de obedecer las disciplinas relacionadas.

Aislamiento: situaciones donde los arquitectos desarrollan una arquitectura perfecta y muy pocas personas están al tanto de ella ni saben usarla. Aquí los arquitectos deben encontrar más cohesión y compromiso del resto de la organización.

Barreras: situaciones donde los arquitectos requieren cierta cohesión con el resto de la organización pero no están muy adelantados con la arquitectura. La arquitectura va a ser muy predominante a nivel operacional pero no añade ningún valor estratégico.

Perder: la organización tiene conocimiento limitado de arquitectura y tiene integración parcial en la organización. Ocurre mucho en organizaciones donde se apagan muchos incendios por tanto no hay tiempo ni recursos para centrarse en otras opciones más estratégicas.

Permitir: la organización adopta una arquitectura como una opción permisiva clave. El problema (reto) está en que la arquitectura siga siendo una clave permisiva y no un problema.

El objetivo y el foco de la arquitectura. Antes de embarcarse en formular una arquitectura, es importante decidir el nivel del objetivo y el enfoque de la arquitectura.

La arquitectura de procesos no se logra con una serie de lineamientos preestablecidos sino con una serie de pasos:
Paso 1: obtener la estrategia e información del negocio.
Se debe obtener la siguiente información:
• Objetivos globales y principios generales además de una estrategia organizacional completada o actualizada según sea apropiado.
• Lineamientos y modelos de negocios relevantes.
• Lineamientos y modelos organizacionales relevantes.
Es importante entender lo fundamental del negocio para que la arquitectura de procesos sirva al negocio.

Adicionalmente, es necesario capturar información relevante, mayoritariamente de alto nivel como:
• Productos y servicios que están por debajo de la lógica y los principios.
• Clientes y los principios y la lógica que están por debajo.
• Política de precios y descuentos.
• Socios (incluyendo proveedores) y canales de distribución.

Obtener esta información puede ser un gran reto, más que todo el obtener la información de los principios y la lógica que hay por debajo de todo lo anterior, por que habitualmente estos principios y lógicas son considerados implícitamente.

Paso 2: obtener procesos de lineamientos y modelos.
Se debe determinar quién es el dueño del proceso, objetivo del mismo, la selección de un método de modelado y de una herramienta de administración, método de gobierno de dicho proceso, outsourcing del proceso modelos de referencia del proceso.

Adicionalmente, la arquitectura debe contener una representación grafica de alto nivel de los procesos. Este diagrama tiene varios propósitos, sin embargo esto solo funciona cuando una vista de alto nivel tiene información relevante de lo que pasa por debajo y es adoptada y usada por toda la organización.

Esto trae el beneficio de enganchar a los de administración en el modelado de los procesos.

Paso 3: obtener información relevante y modelos y principios de tecnología.
En este paso se deben obtener detalles concernientes a los aspectos relevantes de la información así como la tecnología que lo soporta.

El departamento de IT puede tener muchas herramientas y aplicaciones pero el reto está en centrarse en los principios y las opciones principales. Además es muy importante que el departamento do IT apoye los objetivos estrategias y el negocio.

Paso 4: consolidar y validar.
Toda la información es consolidada y validad para comprobar consistencia. Suele ser el paso más complicado.

Una manera de consolidar la información recolectada es el relaciona los distintos modelos de arquitectura unos con otros.

Paso 5: Comunicaciones.
Se debe socializar la arquitectura y sus beneficios con gente de peso dentro de la organización, tanto como sea posible.

Paso 6: aplicar la arquitectura.
Se debe buscar la manera de aplicar los conceptos de la arquitectura de procesos en la organización, pero para esto se deben tener mecanismos para manejar las posibles excepciones. Uno de los métodos propuestos para esto es la DYA (DYnamic Archtecture).

Paso 7: hacerlo mejor.
En este paso se puede refinar y expandir la arquitectura. Adicionalmente en este paso es importante el asegurarse que cada vez más gente esté usando la arquitectura, puesto que le beneficio real de la arquitectura de procesos se vuelve evidente con el paso del tiempo.

FASE DE DESARROLLO.
Normalmente un proyecto se desarrolla en una de dos maneras, con el ciclo SDLC o con el RAD. El modo BPM propone una serie de pasos y aproximación al problema distinto implementando una serie de pasos:
Paso 1: comunicaciones.
Durante la fase de desarrollo es importante comunicar el objetivo y la extensión de los procesos a automatizar a los stakeholders, además de dar respuesta a cada una de las preguntas que puedan surgir en un caso de automatización.

Paso 2: determinar los componentes BPM.
Aquí hay que tomar una decisión sobre cuáles son las herramientas requeridas.

Paso 3: decidir si reusar, comprar, hacer o “Outsource”.
Cada una de estas opciones tiene sus ventajas y desventajas, por tanto es necesario hacer un balance de cada una de estas, ver cuales están disponibles, cuales son viables, entre otros factores, para poder tomar una decisión.

Paso 4: actualizar las especificaciones técnicas y funcionales.

Paso 5: desarrollo de software.
Cualquier solución BPM tendrá las capas de presentación, procesos y de integración. Es crucial entender que cada una de estas capas necesita una aproximación distinta para el proceso de desarrollo y pruebas puesto que involucra distintos grupos de personas.

Paso 6: distribución de hardware
Hay que considerar una serie de problemas que pueden surgir al distribuir hardware como la compatibilidad, escalabilidad y el mantenimiento y soporte. Adicionalmente, hay que asegurarse que el hardware distribuido es exactamente igual al que se utilizo en el proceso de desarrollo.

Paso 7: pruebas.
Esta fase es crucial y debe ser adecuadamente planeada y en detalle y debe ser ubicada dentro del proyecto de manera adecuada (intentando no aplicar las pruebas cuando el proyecto este demasiado avanzado), además que se deben considerar una serie de problemas que pueden surgir durante la fase de pruebas.

FASE DE IMPLEMENTACION.
La mejor manera de asegurar una implementación sin problemas es el iniciar a considerar los problemas de la implementación al inicio del proyecto. De esa manera cuando se llegue a la fase de implementación, los esfuerzos estarán más enfocados en actualizar la información y en realizar las tareas y no en soluciones de último minutos para que la aplicación guste al usuario.
Para llevar a cabo una buena implementación, se requiere el desarrollo de los siguientes pasos:
Paso 1: comunicación.
Hay que comentarle a la gente el proyecto, recibir feedback, sugerencias entre otros. Lo ideal es considerar el feedback recibido en vez de descartarlo.

Paso 2: actualizar la estrategia de implementación.
Es importante revisar la estrategia de implementación por que el equipo del proyecto y la organización tendrán un mejor entendimiento de los cambios propuestos y la estrategia de implementación debe tomar en cuenta la situación actual, la cual puede haber cambiado sustancialmente desde los tiempos de implementación de la estrategia.

Paso 3: prepararse para la pruebas de aceptación de los usuarios.
En esta fase se requiere que usuarios reales prueben la solución, para probar integridad en un uso rutinario, así como el observar las expectativas y asunciones.

Paso 4: entrenamiento del personal.
El entrenamiento puede tomar la forma de cursos formales o entrenamiento in-situ. Obviamente el material usado para el entrenamiento debe ser consistente y el entrenamiento no debe ser realizado demasiado pronto, para prevenir la pérdida del conocimiento adquirido.

Paso 5: completar las pruebas y pilotos de negocios.
Es que donde las pruebas de aceptación de los usuarios son ejecutadas por el negocio. Se debe involucrar a todos los agentes que sean necesarios en estos escenarios, obtener feedback de cada uno de ellos, hay que estar preparados para realizar cambios, tener un mecanismo para medir y compartir los resultados entre los usuarios, entre otros factores.

Paso 6: actualizar los entregables.
Es importante el actualizar continuamente los entregables y asegurarse que los stakeholders los acepten.

Paso 7: involucrar a los administradores.
Paso 8: desarrollar roll-out, back-out y planes de contingencia.
Paso 9: desarrollar y ejecutar programas de marketing.
Paso 10: tutorar al personal.
Paso 11: roll-out changes.
Paso 12: monitorear y ajustar.
Paso 13: proveer feedback a los usuarios y stakeholders.