Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Transcripción

1 ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN OBJETIVOS GENERALES 1. Identificar, diseñar, automatizar y habilitar la mejora continua de los procesos relacionados a la necesidad o proyecto de automatización bajo el enfoque BPM (business process management) y con tecnología BPMS (business process management system). 2. Identificar y/o implementar las aplicaciones, componentes o software o servicios web (bajo principios de SOA) necesarios para respaldar a las actividades dentro del alcance de la necesidad o proyecto de automatización. 3. Integrar los procesos automatizados y las aplicaciones, servicios u otros componentes de software existentes y/o implementados. DESCRIPCIÓN DEL SERVICIO BPM (Business Process Management) es una nueva forma de gestionar los procesos de negocio de una organización, en ese sentido su alcance abarca toda la organización. La experiencia ha demostrado que no es adecuado tratar de adoptar BPM mediante un único gran proyecto, por el contrario es recomendable un enfoque incremental para la correcta adopción de BPM. El siguiente diagrama representa un enfoque incremental para adoptar BPM, de manera adecuada, en una organización. Antes de la consolidación de BPM como enfoque para la gestión (que incluye a la automatización) de procesos de negocio, la principal forma de implementar o automatizar procesos de negocio en una organización ha sido el desarrollo de software a la medida (enfoque de la Ingeniería de Software), en ese sentido se puede hablar de un antes y un

2 después en lo que respecta a la automatización de procesos de negocio como se ilustra en los siguientes gráficos. Automatización bajo el enfoque de la Ingeniería de Software Automatización con Enfoque BPM

3 Las principales diferencias de ambos enfoques son: 1. Con el enfoque de la ingeniería de software, a medida que se requiera, se van construyendo diferentes aplicaciones que automatizan diferentes aspectos de una organización o de sus unidades (aplicación contable, aplicación de recursos humanos, etc.) Cada aplicación significa una inversión para la organización. En el enfoque BPM, la tecnología BPMS proporciona una plataforma de automatización de procesos de negocio lo cual permite automatizar todos los procesos de negocio de la organización con la misma plataforma, esta característica es lo que le da a un enfoque BPM un alto retorno de la inversión. 2. Otra diferencia es que en un desarrollo a la medida (enfoque de ingeniería de software) se tienen que construir/desarrollar todos los elementos/componentes de la aplicación mientras que en un enfoque BPM, el BPMS hace de plataforma y trae muchas funcionalidades que se pueden reutilizar, asimismo una gran parte de la automatización se realiza de manera gráfica lo que conlleva a un mínimo de esfuerzo en programación, esta característica hace que las automatizaciones de procesos de negocio con un BPMS se realiza en menos tiempo que con el desarrollo de aplicaciones a la medida. En base a lo anterior podemos afirmar que la tecnología BPMS ofrece muchas ventajas comparada con la ingeniería de software en lo que respecta a la automatización de procesos de negocio, sin embargo BPM no reemplaza a la ingeniería de software, más bien redefine su rol en la automatización de actividades de una organización: 1. Hay aspectos o tareas de una organización, fuera de los procesos de negocio, que requieren automatización; por ejemplo la contabilidad de una empresa, si bien hay procesos (proceso de ventas, proceso de reclamos, etc.) cuya ejecución tiene o puede tener impacto en la contabilidad de la empresa, la contabilidad propiamente dicha requiere de una aplicación específica para dicho fin. 2. Incluso en proyectos de automatización con tecnología BPM se puede requerir trabajos de ingeniería de software (generalmente como desarrollo de servicios web o integraciones) para dar soporte a las actividades automáticas (por ejemplo registrar información en una base de datos) o integración con aplicaciones existentes (por ejemplo la aplicación de contabilidad) ya que en general la ejecución de procesos de negocio tiene impacto en uno o más registros de datos o aplicaciones existentes en la empresa. Lo anterior se puede resumir en la siguiente conclusión: El alcance de lo que se puede automatizar con el enfoque de ingeniería de software es mayor a lo que se puede automatizar con la tecnología BPMS, sin embargo la tecnología BMS está centrada en los aspectos principales y que permiten la definición y diferenciación de la organización con respecto a sus competidores, sus procesos de negocio, y en dicho alcance resulta más eficiente (reducción de tiempos y costos) que la ingeniería de software, tal y como se ilustra en la siguiente imagen.

4 Cómo Empezar? Ante los beneficios que ofrece un enfoque BPM y la tecnología BPMS, muchas organizaciones se preguntan Cómo podemos empezar a trabajar con este enfoque y con esta tecnología? Como ya se ha comentado al principio, es recomendable un enfoque de adopción incremental. Considerando que los cambios y/o mejoras en una organización se realizan mediante proyectos y que BPM no se limitan a un proyecto o una parte de la organización sino a toda la organización, el siguiente esquema muestra cómo se puede adoptar BPM en una organización de forma incremental (proyecto a proyecto) en lugar de tratar de hacerlo mediante un único mega proyecto : Lo importante en la adopción incremental, proyecto a proyecto, es no perder el foco en el valor de incremento en la adopción de BPM. La identificación de un proyecto que aporte en la adopción/implementación de BPM en la organización (proyecto BPM) es bastante natural ya que siempre o casi siempre habrá por lo menos un proceso de negocio dentro del alcance del proyecto, lo importante es trabajar bajo el modelo conceptual de BPM y cubrir el ciclo BPM para considerarlo un Proyecto BPM. En la medida que una organización tenga claro el modelo conceptual de BPM, podrá identificar con claridad Proyectos BPM a partir de sus necesidades, sin embargo al principio

5 otros tipos de proyectos pueden aportar indirectamente a la adopción de BPM o ser fuente para identificar Proyectos BPM. Por lo anterior una de las fuentes para identificar Proyectos BPM son la necesidad o requerimiento de automatización, típicamente esta necesidad se traduciría en proyectos de ingeniería de software; sin embargo con la relación mostrada en las páginas previas entre el enfoque de la ingeniería de software y el enfoque BPM, se puede deducir que este tipo de requerimientos pueden ser fuente para identificar Proyectos BPM. DESARROLLO DEL SERVICIO Ante un requerimiento o necesidad de automatización y con el objetivo de introducir prácticas de BPM en una organización, se puede abordar en las siguientes fases: Fase de clarificación de requerimientos: Centrada en conocer el estado actual (diagnóstico) de las unidas, forma de trabajo, aplicaciones existentes y problemas dentro del alcance de lo que se pretende mejorar y automatizar; definir a alto nivel los requerimientos mediante escenarios de negocio (técnica desarrollada como parte del marco de referencia TOGAF para arquitecturas empresariales) y recomendaciones para las siguientes fases. Fase de especificación de requerimiento: Centrada en identificar los tipos de requerimientos dentro del alcance de lo que se pretende automatizar y en función de ello definir la forma adecuada de automatizarlos. No hay que confundir esta fase con la típica especificación de requerimientos de la ingeniería de software, en esta propuesta esta fase no se centra en requerimientos de software sino en requerimientos de información bajo el marco de un sistema de información organizacional.

6 Fase de implementación de requerimientos: Centrada en definir las herramientas adecuadas para la automatización de los requerimientos conforme a lo identificado y definido en la fase de especificación de requerimientos. Esta fase se diferencia de las típicas implementaciones con ingeniería de software ya que tiene en cuenta que no se tiene que trabajar todos los requerimientos de la misma forma, existen diversos tipos de requerimientos y cada tipo tiene sus propias características, por ejemplo la frecuencia de cambio, y que en la actualidad existen soluciones especializadas para ciertos tipos de requerimientos que evitan tener que construir soluciones desde cero para cada requerimiento.