Vínculo para visualizar la solución: Presentación
Presentación en PDF
lunes, 19 de septiembre de 2011
Diagrama de la Estructura Organizacional.
El siguiente, es el diagrama de la estructura organizacional de vehialpes, en el cual detallamos la situacion actual, mezclado con las opciones de mejora que ofrecemos al esquema actual.
Diagrama
Diagrama
domingo, 18 de septiembre de 2011
Entrega 1 Artículo
A continuación, proporcionamos el vínculo de descarga de la primera entrega del artículo, el cual estaremos desarrollando a lo largo del curso.
Entrega I Articulo
Entrega I Articulo
martes, 13 de septiembre de 2011
Version actualizada del Canvas.
Con el pasar del tiempo, hemos hecho modificaciones al canvas inicial, y ahora estamos trabajando con las ideas iniciales del mismo, transformandolas a BPMN.
Aqui publico entonces la version mas reciente de dicho canvas.
DESCARGAR EN PDF
DOCUMENTO EN GDOCS
Aqui publico entonces la version mas reciente de dicho canvas.
DESCARGAR EN PDF
DOCUMENTO EN GDOCS
lunes, 12 de septiembre de 2011
Este diagrama BPMN describe el proceso de recolección de información, el cual queremos optimizar con nuestra propuesta de cambio. Para ver el diagrama en su tamaño original, haga clic sobre él. Posteriormente, estaremos publicando el detalle de los subprocesos de Validar Información y Analizar Información.
lunes, 5 de septiembre de 2011
Patrón Top-Down para modelaje de procesos en BPMN
Este patrón pretende simplificar, a través de una serie de pasos, plasmar un proceso de negocio en la notación BPMN 2.0.
Los pasos son:
1. Definir el alcance del proceso: Se debe entender lo siguiente:
a. ¿Como empieza el proceso?.
b. ¿Que es lo que representa una instancia del proceso, quienes son los participantes del proceso?.
c. ¿Que significa el final del proceso?.
2. Definir el diagrama BPMN de nivel mas alto para el camino ideal: Normalmente los procesos siguen un flujo que va variando conforme las decisiones o los eventos que van ocurriendo, por lo que se piensa inicialmente en dibujar el curso de eventos ideal para el proceso. Se realiza mediante los siguientes pasos:
a. Adicionando los “Pools”: Los pools encierran las sucesiones de eventos y actividades que ocurren en un proceso. Cuando hay procesos externos de los que no se tiene conocimiento pleno pero que actuan de alguna forma en el proceso a modelar, se pueden dibujar en el diagrama como un pool solitario. Tambien se dibujan en pools solitarios los participantes del proceso no pertenecientes a la organización.
b. Adicionando los "lanes" a los “Pools”: Los lanes encierran las actividades y eventos cubiertos por un rol de negocio (el cual es asumido por una persona).
c. Adicionar el evento de inicio y de final del proceso: El evento de inicio puede describirse como la llegada de un mensaje (puede ser para descubrir una solicitud, la llegada de un documento) o la llegada de un evento de tiempo (como por ejemplo, cuando un proceso debe ejecutarse regularmente cada cierto tiempo). Si lo inicia un participante directamente, se define un evento de inicio básico.
d. Se identifican los pasos principales (o actividades globales) del proceso y se dibujan. Se aclara que estos pasos principales van a contener una serie de sub-pasos, por los se dibujan con la notación de las actividades de tipo subproceso.
e. Se conectan los pasos a través de flujos de secuencia (normalmente son flechas que indican el paso de una actividad a otra. Hay flujos en los que se toman decisiones para ir a una actividad un otra, o que se inician actividades en paralelo, o que esperan a que un conjunto de actividades finalice para avanzar a la siguiente. Para definir los dos ultimos flujos, se utilizan las compuertas lógicas (o gateways).
Paso 3. Se adicionan los caminos de excepción del nivel superior. Para esto, se pueden seguir estos pasos:
a. Identificar los estados de finalización no exitosa del proceso.
b. Ingresar eventos de finalización para cada estado final no exitoso del proceso.
c. Se insertan los gateways, que son compuertas para especificar condiciones que van a dirigir las actividades tanto en caso de éxito como en caso que el proceso tenga que finalizar de manera no exitosa.
Paso 4. Para cada actividad de subproceso definida, se tiene que detallar toda la secuencia de pasos que deben ocurrir para que se cumpla, y describir los pasos a los eventos de finalización no exitosa de la actividad de tipo subproceso.
Paso 5. Si se tienen Pools externos, se trazan los flujos de mensajes que van desde y hacia estos Pools por parte del proceso encerrado en un Pool.
Paso 6. Si se quiere describir flujo de datos, se pueden utilizar las figuras mensaje (tiene apariencia de carta), objeto de datos (para describir variables que cambian en el proceso, tiene apariencia de una hoja de papel) o un almacén de datos (para descubrir fuentes externas de datos que se usan de cierta forma en el proceso).
Los pasos son:
1. Definir el alcance del proceso: Se debe entender lo siguiente:
a. ¿Como empieza el proceso?.
b. ¿Que es lo que representa una instancia del proceso, quienes son los participantes del proceso?.
c. ¿Que significa el final del proceso?.
2. Definir el diagrama BPMN de nivel mas alto para el camino ideal: Normalmente los procesos siguen un flujo que va variando conforme las decisiones o los eventos que van ocurriendo, por lo que se piensa inicialmente en dibujar el curso de eventos ideal para el proceso. Se realiza mediante los siguientes pasos:
a. Adicionando los “Pools”: Los pools encierran las sucesiones de eventos y actividades que ocurren en un proceso. Cuando hay procesos externos de los que no se tiene conocimiento pleno pero que actuan de alguna forma en el proceso a modelar, se pueden dibujar en el diagrama como un pool solitario. Tambien se dibujan en pools solitarios los participantes del proceso no pertenecientes a la organización.
b. Adicionando los "lanes" a los “Pools”: Los lanes encierran las actividades y eventos cubiertos por un rol de negocio (el cual es asumido por una persona).
c. Adicionar el evento de inicio y de final del proceso: El evento de inicio puede describirse como la llegada de un mensaje (puede ser para descubrir una solicitud, la llegada de un documento) o la llegada de un evento de tiempo (como por ejemplo, cuando un proceso debe ejecutarse regularmente cada cierto tiempo). Si lo inicia un participante directamente, se define un evento de inicio básico.
d. Se identifican los pasos principales (o actividades globales) del proceso y se dibujan. Se aclara que estos pasos principales van a contener una serie de sub-pasos, por los se dibujan con la notación de las actividades de tipo subproceso.
e. Se conectan los pasos a través de flujos de secuencia (normalmente son flechas que indican el paso de una actividad a otra. Hay flujos en los que se toman decisiones para ir a una actividad un otra, o que se inician actividades en paralelo, o que esperan a que un conjunto de actividades finalice para avanzar a la siguiente. Para definir los dos ultimos flujos, se utilizan las compuertas lógicas (o gateways).
Paso 3. Se adicionan los caminos de excepción del nivel superior. Para esto, se pueden seguir estos pasos:
a. Identificar los estados de finalización no exitosa del proceso.
b. Ingresar eventos de finalización para cada estado final no exitoso del proceso.
c. Se insertan los gateways, que son compuertas para especificar condiciones que van a dirigir las actividades tanto en caso de éxito como en caso que el proceso tenga que finalizar de manera no exitosa.
Paso 4. Para cada actividad de subproceso definida, se tiene que detallar toda la secuencia de pasos que deben ocurrir para que se cumpla, y describir los pasos a los eventos de finalización no exitosa de la actividad de tipo subproceso.
Paso 5. Si se tienen Pools externos, se trazan los flujos de mensajes que van desde y hacia estos Pools por parte del proceso encerrado en un Pool.
Paso 6. Si se quiere describir flujo de datos, se pueden utilizar las figuras mensaje (tiene apariencia de carta), objeto de datos (para describir variables que cambian en el proceso, tiene apariencia de una hoja de papel) o un almacén de datos (para descubrir fuentes externas de datos que se usan de cierta forma en el proceso).
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.
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.
Administración de procesos de negocio
BPM no es una herramienta de tecnología, o una iniciativa para procesos de negocio. Es la administración que permite el logro de los objetivos de la organización a través de la mejora, gestión y control de los procesos esenciales de negocio. Es de gran importancia mejorar los procesos de negocio, antes de automatizarlos.
La administración del nivel operacional tiene como objetivo principal el logro y control de los procesos esenciales de negocio para mejorar los objetivos de la organización. Establecer la dirección y mejoramiento de procesos de negocio es un paso definitivo que debe ser abordado por la alta dirección.
Otro aspecto importante a tener en cuenta, antes de considerar la implementación de la tecnología, como herramienta para el mejoramiento de los procesos de negocio, es que, si bien la introducción de tecnología, puede ser de gran contribución, no siempre es requerida para que el mejoramiento de los procesos sea exitoso.
Es responsabilidad de la dirección ejecutiva asegurarse de que existe un vínculo claro entre los proyectos de mejora de procesos realizados por la empresa, y la estrategia de la organización y sus objetivos. Si no es posible evidenciar la forma en que el proyecto de mejora de los procesos, contribuye y aporta un valor significativo a los objetivos de la organización, el proyecto no debería llevarse a cabo.
Para efectuar un diagnóstico adecuado en relación con la efectividad de los procesos de negocio, es necesario evaluar cómo los componentes críticos de la organización, son sincronizados:
· Intención Estratégica
· Visión estratégica
· Ejecución
· Valores, cultura y comportamiento
· Las personas
Una vez evaluada la efectividad y viabilidad de implementar la tecnología al proyecto de mejoramiento de los procesos, se plantean alternativas como frameworks que permiten modelar los procesos a partir de las bases y las reglas de negocio que soportan la operación de la organización, alineándolas con BPM, de acuerdo con la estrategia general de negocio. A través de las distintas fases del framework:
· Estrategia de la organización
· Proceso de arquitectura
· Plataforma de ejecución
· Entendimiento
· Innovación
· Desarrollo
· Las personas
· Implementación
· Evidenciar el valor.
· Rendimiento sostenible
Suscribirse a:
Entradas (Atom)