Semántica, Ontología y BPM 16/11/09
Posted by msaffirio in BPM, Informática, Management, Proceso.Tags: BPM, Business Process, Modelo, Proceso
add a comment
En este artículo trataré las definiciones básicas de la Semántica y de la Ontología desde el punto de vista de Sistemas Informáticos y en particular en cuanto al impacto que implican para la disciplina BPM.
Hasta el día de hoy no existe un procesos definido, claro y continuo para la producción de software. En el caso de los procesos de negocios estriba en cómo obtener información fidedigna y completa que los describa y, cómo transformar ésta –sin pérdida de información- en una especificación semántica, a partir de la cual se puedan generar distintos artefactos de software. Visto desde una perspectiva organizacional, el asunto es como hacer que los expertos en un determinado proceso de negocio, que no son especialistas en TI, y los especialistas en TI se puedan entender entre sí, usando un mismo lenguaje.
Técnicamente se tiene, por otra parte, una falta de integración entre las aplicaciones –que registran las transacciones- y lo Workflows – que establecen el flujo de control o procedimiento. En la práctica ambos componentes de software se diseñan y programan por separado. Esta falta de integración entre las funciones y los procedimientos genera una pérdida de productividad que supuestamente la disciplina BPM pretende resolver, por la vía de contar con mecanismos que permitan mejor especificar un proceso de negocios; es así que hoy disponemos de medios gráficos para representarlos.
No obstante tener un buen diseño de un proceso de negocios junto con una adecuada representación gráfica del mismo, no nos exime del desarrollo de software, o en el mejor caso de una parametrización, tanto para las transacciones como para los Workflows.
Hoy existen desarrollos cuyo objetivo es generar un ambiente de diseño y ejecución de procesos de negocios tal que elimine o minimice las necesidades de programación y que integre el ambiente transaccional con los Workflows. La figura siguiente muestra la relación entre modelo de negocios y modelo computacional [1].
Proceso - Transacción
Estos nuevos ambientes para el diseño de procesos de negocios tiene su fundamento en las tecnologías de WEB Services, WEB Semántica, Ontologías, Programación Gráfica, BPM, etc.
Semántica
El término semántica [2], que se origina en la Lingüística, se refiere a los aspectos del significado, sentido o interpretación del significado de un determinado elemento, símbolo, palabra, expresión o representación formal. En principio cualquier medio de expresión (lenguaje formal o natural) admite una correspondencia entre expresiones de símbolos o palabras y situaciones o conjuntos de cosas que se encuentran en el mundo físico o abstracto que puede ser descrito por dicho medio de expresión. Por extensión este término se usa en el ámbito de la computación para referirse al significado de programas o funciones, permitiendo que los programas se dividan en su parte sintáctica (estructura gramatical) y a su parte semántica (significado).
Ontología
La Ontología, es la parte de la Filosofía, que se ocupa de la definición del ser y de establecer las categorías fundamentales o modos generales de ser de las cosas a partir del estudio de sus propiedades, estructuras y sistemas.
Nuevamente por extensión las Ciencias de la Computación utilizan esta palabra para definir los términos y conceptos (significados) que se usan para describir y representar una determinada área de conocimiento, como asimismo las relaciones que existen entre ellos, de modo que una Ontología –Computacional- incluye [3]:
- Cosas (conceptos) pertenecientes a un determinado dominio de interés.
- Relaciones entre estas cosas.
- Propiedades (y valores de estas propiedades) de estas cosas.
- Las funciones y procesos involucrados con estas cosas.
- Restricciones y reglas relativas a estas cosas.
Entonces una ontología bien definida es una que esta expresada en una sintaxis bien definida y que tiene, además, un mecanismo computacional bien definido para su interpretación. De manera que a partir de la interpretación “mecánica” es posible generar salidas específicas, como ser: modelos de clases, definiciones de procesos de negocios, listas de datos pertinentes a WEB Services, etc.
Es conveniente tener en consideración que La Ontología no trata sobre entidades de modelos y sus relaciones y, la optimización de estas. Sino que es un elemento que permite entender de mejor forma las cosas y sus interrelaciones en un lenguaje cercano al lenguaje natural.
A continuación incluyo un ejemplo de Ontología referido a la clase Empresas [4]
- Empresa
- Empresa productiva
- Producción para stock
- Producción continua
- Producción lotes
- Producción a pedido
- Empresa productiva
- Empresa de servicios
- Servicios financieros
- Bancos
- AFP
- Seguros
- Otros
- Servicios de salud
- Servicios del gobierno
- Servicios de transporte
- Otros servicios
- Servicios financieros
Uso o Posibilidad de Uso
Tal como muestra la investigación a la fecha las Ontologías de Procesos de Negocios serán repositorios de procesos completamente operativos (transacciones, workflows, WEB Services) que estarán a disposición del Business Process Expert (BPX), su utilización podrá ser completa o parcial y se posibilitará la detección automática de los componentes deseados. La figura siguiente muestra un ambiente de ejecución de éstas:
Conclusión
La idea de las Ontologías es magnífica, ya significa tener una “librería” de procesos de negocios lista para ser usada. Pero la realidad nos obliga a actuar ahora con las herramientas disponibles comercialmente. Y, éstas no son pocas: Best Practices, generación gráfica de procesos (ie: BPMN), generación gráfica de interfaces humanas (SAP Visual Composer), administradores de Reglas de Negocios, etc. De modo que, existe hoy una tecnología BPM, comercialmente disponible, que permite realizar el cambio de una organización con estructura funcional (Taylor) a un organizada por Procesos de Negocios (Matricial).
Referencias
[2] http://es.wikipedia.org/wiki/Sem%C3%A1ntica
[3] Business Process Ontologies: Speeding up Business Process Implementation
El Anteproyecto de una Implementación BPM 29/08/09
Posted by msaffirio in Administración, BPM, Informática, Proyectos.Tags: BPM, Gestión, Proceso, Proyectos
7 comments
Si Ud. encarga la construcción de su casa, ¿La iniciaría sin tener los planos de un arquitecto y el presupuesto de la empresa constructora? Y, ¿Por qué está dispuesto a permitir el inicio de la implementación de un proceso de negocios sin tener una definición precisa de lo que se necesita?. Hace pocos días, me preguntaron qué hacer para que los usuarios o la organización acepten realizar el Anteproyecto, y pretendo dar algunos argumentos a continuación.
La experiencia nos demuestra una y otra vez que cada vez que iniciamos un proyecto informático o de cualquier índole sin una definición formal de los objetivos, plazos y presupuestos la probabilidad de tener problemas graves e incluso fracasar es cercana a uno. Entonces, a contrario sensu es indispensable tener una definición precisa y documentada de los objetivos, plazos y presupuestos que significan la ejecución del proyecto. Este es nuestro primer argumento.
Etapas de un Proyecto
La literatura técnica [1, 2] nos dice que un proyecto tiene de cuatro a cinco etapas más un sistema de control. Esto independientemente de la metodología usada, la ejecución del proyecto tiene las etapas siguientes:
- Anteproyecto (Initiation)
- Planificación o desarrollo
- Producción o Ejecución o Realización
- Supervisión y Control
- Cierre
Y, gráficamente se tiene:
Diagrama de las Fases de un Proyectos
Entonces aquí tenemos el segundo argumento: la disciplina de Project Management [3], que nos señala la necesidad de ejecutar como primera etapa de un proyecto el Anteproyecto.
El Anteproyecto es la etapa que determina la naturaleza y el alcance de lo que se pretende desarrollar. Si esta etapa no se ejecuta bien, es improbable que proyecto sea exitoso en cuanto satisfacer las necesidades del negocio. Los controles claves que aquí se necesitan son un entendimiento del ambiente del negocio y la realización de todo lo necesario para asegurar que todos los controles están incorporados al proyecto. Cualquier falencia que se detecte debe ser abordada y resuelta.
El Anteproyecto es la primera fase del Ciclo de Vida de un Proyecto –Project Management Life Cycle- y por consiguiente establece la partida de la ejecución de un proyecto, aún cuando el proyecto en sí no se ejecute por razones de factibilidad técnica o económica.
Las tareas principales de la etapa Anteproyecto para un proyecto Informático son:
- Levantamiento del requerimiento o de la necesidad del negocio.
- Revisión de la operación actual.
- Solución Conceptual
- Dimensionamiento
- Presupuesto
- Planificación
- Análisis de factibilidad y decisión de ejecutar
Para un proyecto de implementación de proceso de negocio, las tareas anteriores es necesario ajustarlas tal que reflejen los principios básicos de BPM, por ejemplo el alineamiento estratégico, el modelamiento, el enfoque holístico, la medición de performance –KPI-, etc. También es indispensable definir para cada tarea un entregable, a objeto de contar con documentos oficiales, que de alguna manera constituirán lo que los auditores llaman la evidencia.
Levantamiento del Requerimiento o de la Necesidad del Negocio.
Antes de hacer el Levantamiento es necesario verificar si existe una verdadera necesidad de implementar procesos de negocios, es decir si la empresa ya tiene internalizado que debe ir a procesos del tipo end-to-end, porque son indispensables para la viabilidad del negocios. Además está posición es respaldada por el Gerente General e idealmente, también por el Directorio. Si estos requisitos no se dan, entonces se debe suspender el Anteproyecto hasta cuando las condiciones indicadas se den.
Establecido que existen las condiciones de patrocinio e interés, el Levantamiento debe considerar:
- Descripción detallada del requerimiento del usuario e identificación de objetivos cuantificables, por lo general KPI. En particular, es muy necesario establecer expec-tativas realistas.
- Determinar cómo este requerimiento se alinea con la estrategia de la empresa.
- Generar documento que describa el requerimiento.
Revisión de la Operación Actual.
La revisión de la situación actual significa documentar el proceso que actualmente tiene en operación la empresa, esta documentación es conocida como Modelos As-Is. Para esta operación es muy conveniente medir los KPI identificados durante el Levantamiento, pues ayudaran a establecer cuanto mejora la operación desde la situación actual, a la con el proceso rediseñado.
Generar el modelo As-Is requiere la participación de los usuarios operativos y, posteriormente la validación de los jefes, ésta a veces es difícil de obtener porque se generan discrepancias entre el proceso reportado por los usuarios y el de los Jefes. En todo caso, es necesario establecer una Verdad Oficial.
Solución Conceptual
Para establecerla es necesario desarrollar el Modelo To-Be, el cual debe satisfacer las necesidades establecidas en el Levantamiento. Para esta etapa es fundamental la participación de un Business Process Expert –BPX- a objeto que ayude a generar modelos adecuados.
En caso de no ser posible de generar el modelo To-Be una alternativa simple y económica es utilizar las Mejores Prácticas [4] provistas por fabricantes de software u otros.
Adicionalmente la Solución Conceptual debe incluir la plataforma tecnológica que soportará el software, las interfaces entre sistemas, la necesidades LLL (Legal, Localization, Language) y la definición de los roles necesarios para el nuevo proceso.
Es muy conveniente hacer una Análisis de Gap, éste consiste en establecer la brecha que media entre el modelo As-Is y el To-Be. La brecha es lo que en estricto rigor se necesita implementar.
También, es recomendable hacer un Análisis de Riesgo respecto a la implementación de esta Solución Conceptual, me refiero a un análisis de tipo cualitativo [5].
Dimensionamiento
Una vez establecida la Solución Conceptual se puede determinar cuáles son los elementos de infraestructura que la implementación requerirá, como ser: licencias, hardware, habilitación de componentes de software, comunicaciones, elementos de seguridad, etc.
El entregable de esta tarea es la lista de elementos de infraestructura requerida, la identificación de los elementos existentes y los que se necesitan adquirir, la lista de proveedores, etc.
También el dimensionamiento debe incluir una evaluación de los recursos de consultoría y programación, a objeto de determinar si estos pueden ser provistos por la propia área de Informática o se necesitará la contratación de servicios externos.
En caso de requerirse servicios externos se tendrá que hacer un llamado a propuesta –RFP- si el tema es complejo o, simplemente pedir cotizaciones. Por lo general, esta es una actividad que toma un par de semanas y, por esto es necesario tenerla muy presente.
Presupuesto
Esta actividad junto con el Dimensionamiento y la Planificación se realimentan entre sí y por tanto su ejecución tiene un cierto grado de paralelismo.
La determinación del costo del proyecto es necesario establecerla para aquellos ítems que corresponden a compras o a contratación de servicios de terceros. Es común que los costos de los recursos internos no sean considerados.
Los ítems más comunes son: Licencias de Software, Hardware, Gastos de Viajes y Servicios Externos (Consultoría, Desarrollo, Capacitación, etc.). La herramienta más usada para generar los presupuestos es MS Excel, y a veces se ocupan modelos matemáticos, como por ejemplo los Puntos de Función (para determinar el esfuerzo de los desarrollos).
Planificación
Con respecto a esta actividad, que normalmente es considerada un requisito burocrático, es necesario comentar:
- El gran entregable de la planificación es la Gantt o más precisamente la lista de tareas con su secuencia de ejecución, con la identificación precisa de cada tarea, fechas, dependencias y recursos asignados.
- La generación de la Gantt es un proceso de simulación de la ejecución del proyecto, por tanto ayuda a detectar puntos críticos, riesgos, disponibilidad de los recursos. Por lo mismo genera realimentación a las etapas de Dimensionamiento y Presupuesto.
- Con la planificación se pueden negociar los compromisos de participación y apoyo tanto de los usuarios, recursos propios y recursos externos.
- En definitiva, la Gantt debe ser formalmente aprobada por el Usuario –Cliente- a objeto que se transforme en el mecanismo oficial del control y supervisión del proyecto.
Análisis de Factibilidad y Decisión de Ejecutar
Establecidos los plazos, costos y riesgos es necesario hacer un balance entre el esfuerzo económico de realizar el proyecto versus los beneficios económicos que su ejecución conlleva. Por lo general la decisión de ejecutar se toma basada en la disponibilidad de presupuesto más un análisis cualitativo de los beneficios.
Si la organización es más sofisticada se incluye una valorización económica, para determinar que significa la ejecución del proyecto, este valor es asignado al proyecto para que compita con otros ya definidos y evaluados en el portafolio.
Un caso particular en la decisión de ejecutar son todos aquellos proyectos que obligatoriamente se deben ejecutar por razones de tipo legal o de alguna normativa (SoX, Basilea, IFRS, etc.)
Referencias
[1] http://en.wikipedia.org/wiki/Project_management
[2] New York State Proyect Management Guidebook
[3] http://www.pmi.org/Pages/default.aspx
[5] http://msaffirio.wordpress.com/2009/01/28/analisis-de-gestion-de-riesgos-en-proyectos-bpm/
As-is; To-Be; Gap 4/07/09
Posted by msaffirio in BPM, Gestión, Informática, Proceso, SAP.Tags: BPM, Business Process, Modelo, Proceso
4 comments
Este artículo corresponde en parte a discusiones técnicas con mis colegas de Embotelladora Andina y refleja mi opinión respecto a los modelos As-Is y To-Be más el análisis de GAP.
Primero es necesario tener en consideración que estas discusiones se originan por causa del transcurso del tiempo, al igual que uno los sistemas envejecen y requieren ser actualizados funcionalmente. Luego la pregunta es ¿Cómo actualizo funcionalmente mis sistemas? Asunto que intentaré responder a continuación[1].
La necesidad de la actualización funcional se presenta cuando se está trabajando varios años con un mismo sistema, que se ha actualizado técnicamente, se han instalado las nuevas versiones del software. Pero, no se usan extensivamente las nuevas funciones que incluye este nuevo software y, por otra parte el portafolio de proyectos se comienza a llenar de muchas iniciativas de “mejoramientos”. La conclusión es: los sistemas requieren un mejoramiento de mayor alcance o profundidad.
El plantearse este mejoramiento o puesta al día tiene varias implicancias:
- Los sistemas en uso se implementaron con una tecnología distinta a la hoy en boga, entiéndase BPM. Es decir se diseñaron a partir del concepto funcional: Área Organizativa / Módulo de Software.
- No existe mucha seguridad que la documentación del sistema refleje la realidad actual.
- La actualización, con toda seguridad, ocupará la disciplina BPM y el concepto Proceso de Negocios.
- Lo más probable es que la organización no esté dispuesta a ejecutar un proyecto con una estrategia Big Band, básicamente por una cuestión de costos. Esto obliga a una estrategia de implementación que denomino “Cambiar la Rueda en Marcha”[2], es decir implementar los nuevos procesos de negocios mientras los sistema originales –antiguos- siguen funcionando y, todo esto en un mismo landscape.
- Dado que los sistemas antiguos tienen un diseño funcional, se mapean directamente uno es a uno con las área organizacionales. Cuestión que no ocurre con los procesos de negocios, que generan una estructura organizacional matricial, y esto provoca, sin lugar a dudas, un conflicto de poderes –político- no menor.
- Si la empresa tiene filiales, plantas u operaciones en distintos lugares o países lo más típico es que teniendo el mismo software, se tienen implementaciones distintas de acuerdo con los criterios de los gerentes.
Estrategia Cambio de Rueda en Marcha
Esta estrategia es válida para una empresa que opera un ERP con sistemas adicionales como CRM, SCM y sistemas legados, todos estos sistemas con algún grado importante de interconexiones. Es decir es para una empresa de tamaño grande con una infraestructura informática compleja que justifica una estrategia como la que describiré a continuación.
Características
Esta estrategia corresponde a las de tipo Evolutivo por Proceso[1], cuyas características principales son:
Fortalezas
- Permite un enfoque en profundidad y sistemático.
- Cambio Organizacional suave.
Debilidades
- Realización lenta de los beneficios.
- Se generan cambios en los procesos debido al paso del tiempo.
Básicamente esta estrategia se aplica a un proceso de negocios End-To-End, por ejemplo: Order-to-Cash, Procure-to-Pay, etc.
Pre-Requisitos
Para que esta estrategia efectivamente pueda aplicarse exitosamente es necesario contar con:
- Una directriz del Directorio y la Gerencia General que señale que la empresa re-implementará sus sistemas informáticos utilizando la disciplina BPM.
- Un Mapa de los Procesos de Negocios oficial.
- Un área Informática con personal capacitado en BPM y que conozca los procesos de negocios de su empresa en profundidad (detalles operativos).
- Una estructura metodológica que incluya: la Enterprise Architecture, La estrategia BPM (la que presento en este artículo), Gestión de Portafolio y Metodología para la Implementación de Procesos de Negocios.
- Un plan de Gestión de Cambio.
A mi juicio, lo que importa es contar con estos elementos independientemente del área organizativa que los provee.
Modelo
Este modelo se aplica a un proceso de negocios End-To-End y su estructura general es:
Estrategia Cambio Rueda en Marcha
Etapa AS-IS
Este es uno de los aspectos que siempre está en discusión[2], ya que existen opiniones a favor y en contra respecto a si es necesario generar los modelos As-is, mi opinión es que es indispensable generar estos modelos debido a que:
- Ayuda a generar un alineamiento y entendimiento entre las distintas áreas y locaciones de la empresa en cuanto a cómo efectivamente se ejecuta el proceso de negocios. A menudo en las organizaciones grandes muchos ejecutivos y usuarios claves no tienen la visión completa de cada uno de los pasos y detalles de la operación del proceso de negocios. La documentación del As-Is ayuda a generar claridad respecto a cómo se ejecutan las cosas y cuáles son los desalineamientos.
- Ayuda a introducir los conceptos de BPM a los ejecutivos y a los usuarios claves, en particular en el uso de los diagramas de procesos de negocios (VAC, EPC, etc.)
- Permite establecer los puntos críticos y de mejoramiento del proceso.
- Afiata el equipo de trabajo del proyecto: Consultores, Usuarios Claves y Ejecutivos Claves.
Para el levantamiento del proceso As-Is es importante considerar:
- Que a fin de generar la documentación del As-Is en un tiempo razonable es necesario tener un método preestablecido de trabajo y un estándar para modelar.
- Se necesita de herramienta de software para modelar, ojalá una que maneje objetos como ARIS.
- Es indispensable, una vez generado el modelo As-Is, los gerentes involucrados en el proceso validen formalmente el modelo. Esta acción tiene más de una complicación debido a que a menudo el modelo levantado no corresponde a la imagen que tienen del mismo los ejecutivos.
- Por último, si su empresa necesita cumplir con alguna regulación (SoX, Basilea II) o alguna certificación el disponer de la documentación de los procesos de negocios actualizados es una obligación.
- La responsabilidad de generar y mantener actualizados los modelos As-Is de los procesos de negocios debe estar formalmente asignada a alguna unidad de la organización.
To-Be
La generación de los modelos To-Be es indispensable para establecer que se quiere de la nueva implementación, y ayuda a:
- Definir el nuevo modelo del proceso de negocios independientemente del software a utilizar. Esto permite pensar sin restricciones dadas por el software, por la costumbre, por el personal, etc. cuestión que posibilita descubrir oportunidades de mejoramiento.
- Al tener los modelos To-Be y los As-Is es factible realizar un análisis de GAP, que es fundamental para esta estrategia.
- El desarrollo del modelo To-Be permite establecer Indicadores de Performance –KPI que apoyaran el mejoramiento del negocio y el accountability.
- Posibilita realizar un efectivo alineamiento de los procesos de negocios con la estrategia corporativa.
Para la generación del modelo To-Be se pueden trabajar con los siguientes enfoques:
- Utilizar Mejores Prácticas, que son modelos provistos, en general, por los fabricantes del software o por alguna otra organización. La ventaja de su uso es tiempo, costo y que son modelos probados en la práctica[3]
- Variantes LLL (Legal, Language, Localization), modificaciones a una Mejor Práctica originadas por un imperativo legal, una necesidad impuesta por el idioma o por elementos físicos –no de idiosincrasia- de una locación, por ejemplo la disponibilidad de un determinado elemento.
- Prácticas Propias, son modelos generados por la propia organización y que se justifican, dado su alto costo de generación, cuando el proceso o parte de el –subproceso- no está presente en una Mejor Práctica y/o cuando su implementación genera una ventaja competitiva muy significativa.
Análisis de GAP
En simple es establecer cuáles son los cambios necesarios de realizar al proceso actual para actualizarlo al Nuevo modelo.
En esta estrategia es necesario volver a tener en cuenta que el “Cambio de Rueda es en Mrcha”, esto significa que los ajustes, modificaciones y adiciones se hacen en el landscape que está operando. Hecho que significa establecer con mucha precisión cuales serán los cambios a realizar, cómo y dónde se harán y, muy principalmente, cuál será el impacto que tendrán
Resumiendo el Análisis de GAP, debe establecer las brechas en:
- Procesos y Subprocesos
- Parametrizaciones
- Desarrollos propios (existente y nuevos)
- Datos
- Roles
- Responsabilidades
- Documentación
- Performance
- Gobernabilidad
Cada uno de los tópicos anteriores debe ser documentado y en conjunto constituirán en Business Blue Print que define el GAP a implementar.
Referencias
[1] SAP Roadmap for BPM
[2] http://it.toolbox.com/blogs/erp-roi/erp-business-process-improvement-asis-or-tobe-13208
[1] Todo este artículo tiene un trasfondo de tecnología SAP, pues es la que ocupa mi empleador: Embotelladora Andina.
[2] Expresión que la escuché a menudo de mi ex jefe Ricardo Majluf.
Mejores Prácticas – Best Prectices / Prácticas Propias Own Practices 6/06/09
Posted by msaffirio in Gestión, Proceso, SAP.Tags: Best Practice, BPM, Proceso
1 comment so far
Durante el Sapphire 09 (Orlando, Mayo 2009) asistí a la presentación Clear Business Value realizada por los ejecutivos Bill McDermott y Jim Hagemann Snabe [1], ellos responden a la pregunta: ¿Cómo se genera ventaja competitiva con los procesos de negocios? Plantearon que para generar Valor para el Cliente es necesario tener: Visión del Negocio, Mejores Prácticas y Prácticas Propias. La aplicación de estos tres elementos lleva a la Excelencia Operativa, y ésta es la que genera Valor para el Cliente y permite obtener ventaja sobre la competencia. En los párrafos siguientes expondré estos conceptos con algunas explicaciones mías.
Visión del Negocio
Con cualquier ejecutivo que uno converse le dirá que tiene una visión y un conocimiento profundo de su negocio, sin embargo McDermott y Hagemann definen que la visión se da cuando se dispone de:
- Información Unificada, toda la información de los procesos de negocios está estandarizada para toda la compañía, es decir un parámetro, un campo, una clasificación, un KPI, etc. significan lo mismo para cualquier empleado, independiente del cargo, de la gerencia o filial a la que pertenezca.
- Acceso Instantáneo, los empleados tienen acceso a la información que precisan en cualquier momento, no están sujetos a la necesidad de pedir a un tercero la información deseada.
- Ciclo cerrado entre estrategia y ejecución. Los procesos de negocios, que soportan la ejecución y el control, están alineados con la estrategia corporativa; es decir, en cada proceso se tienen mecanismos que permiten medir cuantitativamente la estrategia (presupuestos, planes, KPI, etc.)
El diagrama siguiente muestra como se insertan estos conceptos en un modelo de operación más general.
Modelo presentando por Bill McDermott y Jim Hagemann Snabe en Sapphire 09
Mejores Prácticas – Best Practices
Originalmente el término o concepto Mejores Prácticas -Best Practices- fue acuñado en 1993 por Hammer and Champy [2] para identificar siete reglas o indicaciones para modelar procesos de negocios.
Hoy la Mejor Práctica corresponde a un modelo completamente definido, cuyos buenos resultados operacionales están comprobados y que está disponible para ser utilizada. Por ejemplo: SAP por medio de su aplicación Solution Manager[3] permite “bajar” Mejores Prácticas prácticamente para cualquier proceso.
El usar Mejores Prácticas significa un gran ahorro de dinero, debido a que los modelos ya están establecidos y han sido refinados por el uso en muchas empresas. Las ventajas de utilizarlas son básicamente el menor costo y el menor plazo de implementación. Sin embargo, utilizar las Mejores Prácticas, a pesar que su habilitación no es un mero copiar / pegar, es simplemente una replicación de un modelo de proceso de negocios que muchas empresas ya tienen en uso, con la salvedad que quien la está implementando no será ni el primero ni el último. De modo que podemos decir que al usar una compañía Mejores Prácticas sólo está “empatando” con las otras compañías que también ocupan la referida Mejor Práctica.
Prácticas Propias – Own Practices
Son modelos de procesos de negocios propios que corresponden a aspectos específicos de la operación de una compañía, que se refieren a aspecto particulares de su operación y que al llevarlos a nivel de excelencia permiten generar más Valor para los Clientes. Por ejemplo en una empresa distribuidora puede ser algún aspecto de la logística, en otra será un forma diferencial en la generación de demanda, en el tratamiento de las órdenes de producción.
Las localizaciones del tipo LLL (Legal, Localization & Language) no corresponden a una Práctica Propia, pues dan satisfacción a una necesidad que es común para varias empresas en un país determinado.
Las Prácticas Propias se construyen por medio de:
- Identificación de las áreas de diferenciación.
- Expandiendo las Mejores Prácticas en uso.
- Construyendo Mejores Prácticas.
- Apalancándose en SOA para aumentar la velocidad de implementación.
Conclusión
La vía propuesta por McDermott y Hagemann consiste en desarrollar en paralelo la implementación de las Mejores Prácticas y la habilitación de una plataforma de Business Intelligence para proveer a los usuarios el acceso instantáneo a la información que necesitan. Una vez resueltos estos dos aspectos se procede con la generación de las Prácticas Propias, se estima que éstas debieran corresponder al 20% de las Prácticas de una empresa.
Luego, las Prácticas Propias serán las implementaciones de los modelos de procesos de negocios que en definitiva permitan generar Valor para Cliente y, establecer una diferencia competitiva por la vía de la Excelencia Operativa, que como se sabe es mucho más difícil de copiar que los productos y los servicios.
Referencias:
[1] McDermott y Hagemann, http://www.sap.com/community/events/sapphire_online_2009/index.epx
[2]Hammer, M (1990) “Reengineering work: don’t automate, obliterate”, Harvard
Business Review, Vol. 68, No. 4, pp 104-112.
El Factor Clave para un Proyecto BPM 3/05/09
Posted by msaffirio in BPM, Informática, Opinión, Proceso, Proyectos.Tags: BPM, Business Process, Proyectos
2 comments
A estas alturas del desarrollo informático cabe preguntarse donde está el mayor riesgo de un proyecto BPM y, en mi opinión, se pueden identificar tres áreas de riesgo: La Tecnología Informática, La Organización y los Informáticos. Para todo este análisis estoy suponiendo que el Proyecto BPM ya fue evaluado en su mérito y que la empresa tiene los recursos económicos para realizarlo. Y, que además el Área de Informática ya está preparada para abordar un proyecto de esta naturaleza [1]
La Tecnología Informática (TI), podemos decir que está compuesta por los tradicionales elementos de Hardware y Software. Y hoy, a diferencia de hace 25 años, la TI no es un riesgo, ahora difícilmente se frustrará un proyecto porque no tiene capacidad de discos suficiente y más raro aún es que un programa no funciones por memory exceded. Esto no quiere decir que la TI este totalmente libre de problemas, lo que sí es claro que con recursos técnicos competentes y el presupuesto correspondiente los problemas son solubles. Por consiguiente concluyo que las TI no son el factor clave para el éxito de un Proyecto BPM y sí son una condición necesaria pero no suficiente.
Los Informáticos, a la fecha el conjunto de profesionales de TI ya paso hace mucho tiempo la época de los Analistas de Sistemas, Programadores y Operadores. Hoy vemos que siguen existiendo los Operadores y los Programadores, que también se llaman Consultores Técnicos. Pero, tenemos Consultores Funcionales, Arquitectos de distintos sabores, Business Process Experts, Jefes de Proyectos, Control de Calidad, etc. Con esto quiero decir que está disponible una oferta completa de profesionales Informáticos que cubren todas las áreas de especialidad de las TI. Luego en caso que en un proyecto se presente una complicación técnica grave, teniendo presupuesto, se puede recurrir al especialista pertinente sea de Chile o de otro país, dada la globalización de la oferta técnica. De modo que también podemos decir que los Informáticos no son el factor clave de éxito de un Proyecto BPM y sí son una condición necesaria pero no suficiente[1].
La Organización, para este análisis consideraré a los Gerentes y a los Usuarios, donde los primeros son los que detentan el poder formal y los segundos son quienes usan las TI para ejecutar sus funciones. Es aquí donde encontramos el factor crítico de éxito para el Proyecto BPM. A continuación presentaré algunos elementos que refuerzan esta idea.
En una empresa típicamente los sistemas estas implementados por funciones –ventas, logísticas, producción, contabilidad, etc.- que se corresponden con la estructura organizacional –Gerencia Comercial, Gerencia Operaciones, Gerencia Producción, Gerencia de Administración y Finanzas, etc. es más estas funciones corresponden a módulos del software, por ejemplo en SAP ECC se tiene los módulos SD, MM, PP, FI, CO, etc . y a mayor abundamiento tenemos los Consultores Funcionales por módulo. De manera que estamos en presencia de un orden claramente establecido configurado en lo que se ha dado en llamar silos de información.
El proceso de negocios rompe totalmente con este orden, dado que al tener la visión holística de una actividad hace un análisis independiente de la estructura organizacional y de los componentes de software. El gráfico publicado en [2] muestra esta realidad.
Modelo Operacional Matricial
Luego, aquí detectamos el primer escollo del Proyecto BPM: los procesos de negocios rompen el orden establecido.
Para la implementación de un Proceso de Negocios se necesitan Business Process Expert (BPX) [3], este tipo de profesional tiene un dominio del negocio y de TI, y por tanto para la implementación de un Proceso de Negocios tendrá que interactuar con los Gerentes cuyas áreas participan en el nuevo modelo. Aquí se presenta otro riesgo potencial, al definirse procesos de negocios cada Gerente verá que ya no tiene un control total sobre cómo se implementan las funciones de su área, esto porque él es uno más de los que participan en la definición del modelo del proceso. Es decir, al eliminar los silos funcionales el Gerente de un área ya no puede definir de manera omnímoda la forma de operación de su área, y tiene que hacerlo en conjunto con otros Gerentes, con BPX y los Dueños de Procesos.
El otro fenómeno que afecta a los Gerentes es que el proyecto BPM implica una administración con un aspecto matricial que es dado por los Dueños de Procesos [4], que al responsabilizarce de un proceso –accountability- tienen autoridad sobre quienes operan el proceso independiente de la gerencia a la que pertenezcan. Este simple hecho generará tensión en los ejecutivos y el los usuarios.
Luego, tenemos que considerar que por causa de un proyecto BPM, independientemente de los beneficios racionales que éste pueda significar para cada Gerente, tenemos que tener en consideración las fuerzas que, de alguna manera, afectaran al Proyecto BPM y que se muestran en el diagrama siguiente:
Fuerzas que Afectan el Proyecto BPM
Por otra parte tenemos a los Usuarios que participan en el proyecto sea para validación del modelo, para entregar información de detalles operativos y legales o para el testing de la implementación. En mi opinión ellos son afectados, al igual que en cualquier proyecto de implementación de sistemas, porque son sacados de su zona de confort.
En consecuencia, el factor crítico de éxito para un proyecto BPM son las personas [5], en este análisis las he identificado como los Gerentes y los Usuarios, y ellos tendrán especial participación en:
- Tomar las decisiones de negocios.
- Diseñar los procesos de negocios.
- Monitorear la ejecución de los procesos de negocios.
Conclusión. En un área Informática, de una empresa grande, nos encontramos con recursos profesionalizados, centralizados y estandarizados. Estos recursos deberán actualizarse y agilizarse para poder incluir tópicos tan importantes como la Gestión del Cambio, entre otros, para poder abordar con éxito los Proyectos BPM. Como asimismo el CIO deberá aplicar su capacidad política y de negociación para facilitar el patrocinio de los ejecutivos superiores. Sin el patrocinio de los ejecutivos superiores es muy difícil que el Área Informática logre alinear a los Gerentes con el Proyecto BPM.
Referencias
[1] http://msaffirio.wordpress.com/2008/11/08/algunas-dudas-respecto-a-un-proyecto-bpm/
[3] http://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/
[5] Business Process Management The SAP Roadmap – Snabe, Rosenberg, Moller, Scavillo – Galileo Press 2009
[1] Se entiende que el Área Informática ya se ha preparado para abordar el Proyecto BPM.
