Ya el tema BPM está permeando las organizaciones en Chile y las Área de Informática se están preguntando cómo abordar el tema, en este artículo les presentaré la primera parte de una estrategia que he diseñado para abordar sistemáticamente la introducción del BPM, desde la venta interna hasta la ejecución del Anteproyecto corporativo para planear y dimensionar la implementación de los procesos de negocios end-to-end.
La estrategia al estar basada en fases, cada una de ellas podrá evaluarse, permitiendo decidir si se ejecuta la siguiente o no (modelo Waterfall). Se esta manera los recursos a conseguir son los necesarios para una fase, y los requeridos para la fase siguiente se obtendrán una vez evaluada la anterior. Por otra parte se disminuye el riesgo al acotar funcionalmente la complejidad.
La introducción de BPM en el Área Informática debe asumirse como un cambio organizacional, por consiguiente es necesario abordar, simultáneamente, los siguientes aspectos:
- Motivación, Dar respuesta a los ¿Por qué?, atender a las emociones que están detrás de los discursos personales.
- Conocimiento, Dar respuesta a los ¿Qué?
- Habilidad, Dar respuesta a los ¿Cómo?
Esta estrategia ayuda a dar solución al Conocimiento y al desarrollo de la Habilidad, en este caso referido al BPM. Es decir, se presenta un camino que permita al Área Informática pasar del conocimiento teórico a la capacidad práctica para desarrollar proyectos BPM.
Esquema General
La estrategia se presenta como un conjunto de fases secuencial es ,que permiten ir evaluando fase a fase la decisión de continuar la ejecución de la siguiente. Este enfoque tiene las siguientes ventajas:
- Permite al Área de Informática establecer un plan para el cual puede ir pidiendo autorizaciones y presupuestos para cada fase.
- Cada fase se aborda como un proyecto en sí mismo, con su alcance, presupuesto y plazos previamente definidos.
- Cada fase puede ser ajustada a las características de cada empresa.
- Por estar cada fase claramente definida en su alcance, disminuye el riesgo y aumenta la probabilidad de éxito.
- Por ser cada fase acotada a un objetivo fundamental, el impacto del cambio será percibido en sus aspectos positivos, es un desarrollo, y no como una amenaza (ocurre con los cambios radicales).
Preparar al Área TI
Consiste en lograr que la gente del área, en particular los consultores funcionales y sus ejecutivos, tengan los conocimientos de BPM necesarios para poder argumentar adecuadamente y, para hacer un catastro de oportunidades. También incluye actividades para crear la estructura técnica que podrá dar soporte al futuro proyecto BPM.
Esta preparación también incluye considerar que el Área debe cambiar su foco: para evolucionar y generar ventajas competitivas para su empresa, se necesita el conocimiento de sus procesos de negocios. Este conocimiento es estratégico y por tanto debe estar en la empresa, en particular en Informática. En otras palabras, el Área Informática debe profundizar en el conocimiento, compresión y lenguaje del negocio de su empresa.
Las actividades a realizar son:
Capacitación BPM
El objetivo de esta tarea es lograr que la gente del Área Informática tenga un conocimiento básico de BPM y, algunos de sus integrantes un conocimiento medio, idealmente avanzado, con particular énfasis en el entendimiento de los procesos de negocios de su empresa. En esta etapa se podrán detectar las personas con interés y capacidad para evolucionar de Consultores Funcionales a Expertos en Procesos de Negocios [1].
Metodologías
Dado que la implementación de BPM es esencialmente un proyecto de estandarización de procesos de negocios: Procesos Globales y Funcionalidad Global en Todas Partes, es necesario tener en operación metodologías para la gestión del Portafolio de Proyectos y para la Implementación de Procesos de Negocios. La primera permite establecer la secuencia de ejecución de los proyectos priorizados por su mérito económico, estratégico o legal. La segunda, facilita hacer las implementaciones globales, es decir, una implementación más los roll-out que sean necesarios según la cantidad de filiales o centros de la empresa.
Arquitectura
Al menos debe existir una definición básica que establezca los criterios para la plataforma de hardware Technical Reference Model (TRM) y otra para la plataforma de software Information Systems Reference Model (ISRM). Es conveniente considerar que interesa definir la arquitectura en términos pragmáticos, vale decir tiene que ser un conjunto de definiciones que tanto la empresa como el Área Informática consideran en sus procesos de planificación e implementación de procesos de negocios.
Herramientas BPM
en esta etapa, al menos, deben evaluarse las herramientas BPM con las cuales de construirán los procesos de negocios. Debe entenderse, que como en cualquier obra de ingeniería, es indispensable contar con las herramientas apropiadas y con la gente debidamente capacitada.
Patrocinio
Dado que un proyecto BPM es en realidad un cambio organizacional más que un proyecto informático, es necesario entender que todo cambio organizacional altera el equilibrio de poder en la organización. Por ejemplo, es común que los gerentes de línea tengan autonomía para decidir cómo se hacen los sistemas y el área Informática, a lo más puede hacer sugerencia. Por el contrario, un proyecto BPM, implica la visón integral u holística de los procesos de negocios, visión que lleva a diseños que involucran a varias gerencias y que promueven una implementación estándar. Debido a esto el Gerente en cuestión tendrá que aceptar que ya no puede decidir de manera omnímoda.
Por otra parte, el abordar los procesos de negocios holísticamente aumenta el nivel de stress de la organización, por la natural incertidumbre que significa una nueva manera de hacer las cosas, por el riesgo de afectar al negocio y por la reluctancia de las personas al cambio.
Para paliar estos efectos: el cambio del poder de los gerentes con su consiguiente pérdida de autonomía; los nuevos procesos de negocios que conllevan un cambio organizacional importante, típicamente de estructura tayloriana a matricial y el cambio, propiamente tal, que afecta a la gente. Resulta imprescindible que el área Informática cuente con el apoyo, patrocinio, de la Gerencia General y, en lo posible del Directorio. Pues de otro modo, no tendrá la autoridad para hacer tan importantes cambios.
Las actividades para obtener el Patrocinio son:
Venta Interna
Se refiere a toda la actividad necesaria para “vender” el proyecto BPM al Gerente General y al Directorio. En mi concepto deberán establecerse cuáles son los pain points, es decir cuáles son los puntos de preocupación respecto al negocio. Por ejemplo: Baja rentabilidad, necesidad de ir a excelencia operativa, contar con información confiable, resolver un problema operativo importante (inventarios, distribución, etc.), obsolescencia de los sistemas informáticos, necesidades contractuales, etc. Como se puede observar de esta lista los argumentos computacionales están ausentes.
La manera específica de ejecutar esta venta dependerá de la situación de cada empresa, pero es un factor común que el área Informática tiene que conocer detalladamente el negocios de su empresa para poder buscar las oportunidades y los argumentos adecuados, que deben ser de negocios y no técnicos.
Análisis del Cambio
Sabemos que un proyecto BPM implica un cambio organizacional por consiguiente, atendiendo a la realidad de cada empresa, se necesita hacer un análisis pormenorizado de todos los impactos o implicancias que conlleva este proyecto.
Este análisis debe considerar, al menos, los efectos sobre la organización, los riesgos implícitos del proyecto, las implicancias para el área Informática, las necesidades de cambio de la plataforma tecnológica.
Por otra parte este análisis, mirado desde la venta, ayudará a identificar las objeciones al proyecto, de manera de poder buscar la mejorar forma de encararlas. También ayudará a establecer los lineamientos para el plan de Gestión de Cambio.
Where is the Money?
Esta actividad es una búsqueda sistemática de argumentos cuantitativos y cualitativos para justificar el proyecto.
Un punto de partida es hacer un levantamiento de los procesos de negocios existentes –as-is- y compararlos con un mapa de procesos deseados y/o con Best Practices, este análisis entregará información respecto a los procesos que hoy tiene soporte informático, los que tienen soporte Excel /Manual y los que simplemente no están en el radar.
Otra alternativa es establecer los Key Performance Indicators (KPI) para los procesos principales, medir cuales son los valores que arrojan con los procesos en uso hoy, verificar cual es su promedio de la industria, y establecer los valores a los que se desea operar.
Una tercera alternativa es utilizar una Escala de Madurez para determinar el nivel de desarrollo en el cual se encuentra cada proceso de negocio, establecer el valor que significa pasar del nivel actual a los superiores. Además se pueden asociar valores de KPI a cada uno de los niveles de la Escala [2].
También se puede hacer una evaluación económica del proyecto utilizando las metodologías ya conocidas.
Mapa de Procesos
Básicamente consiste en un diagrama que señala las actividades que son pertinentes realizar en una determinada organización, a objeto de lograr su misión u objetivos de negocios [3].
En un esquema de modelamiento de lo general a lo particular –top down– es la primera aproximación a un visión holística de un organización, la idea es que sucintamente en un gráfico queden reflejados todos los procesos de negocios que tiene que realizar dicha organización.
La tareas a realizar para tener el Mapa de Procesos son:
Identificación
Se trata de identificar cuáles son los procesos principales o macro procesos de la organización, al respecto debe generarse consenso en cuanto a la lista y a su especificación. Para mayor detalle ver Mapa de Negocios.
Modelos As-Is
La generación de los modelo actualmente en uso se refiere a producir en una herramienta BPM los modelos VAC, EPC, BPMN, etc. que permitan tener un acuerdo común formal sobre el estado de las cosas, tal que posteriormente posibilite hacer el análisis de GAP. Para mayor detalle ver As-is; To-be; Gap [4].
Este articulo Una Estrategia para cuenta con dos parte:
Una estrategia BPM para el Área Informática – Parte 1
Una estrategia BPM para el Área Informática – Parte 2
Referencias
[1] http://msaffirio.com/2008/09/30/business-process-expert-%E2%80%93-bpx/
[2] http://msaffirio.com/2008/06/21/escala-de-madurez-%E2%80%93-process-maturity-model/
Hola Mario,
Intersante y explicativo post. Quedé con ganas de seguir leyendo los ultimos 3 pasos de la estrategia, los vas a explicar en un siguiente post?
Saludos,
Ricardo Seguel
Ricardo:
Gracias por el comentario. La parte II la voy a publicar los primeros das de Enero. Mi inters es que le tema se trate y se genere debate al respecto.
Saludos,
M. Saffirio
Muhcas gracias por el post, pero tienes alguna experiencia de implementación de BPM´s en entidades estatales?
Mi experiencia con BPM es en la empresa privada.