Modelo de Dashboard para Supervisores

En general en las organizaciones se prioriza la generación de información de gestión para los Ejecutivos y la captura de datos para los Supervisores, en este artículo pretendo mostrar un modelo general de Dashboard para Supervisores, entendiendo que el disponer de éstos incrementa significativamente la generación de valor del negocio.

En efecto, la encuesta Is performance management performing [1], realizada por Accenture el año 2016, señala:

El 29% de los Colaboradores encuestados creen que el enfoque actual de la gestión del desempeño apoya el logro de los objetivos empresariales.

El 89% de los Colaboradores creen que su desempeño mejoraría significativamente si se cambia la gestión del desempeño

Luego, parece razonable considerar prácticas, procedimientos o métodos para mejorar la Gestión de Desempeño de acuerdo con los datos de la encuesta.

Por consiguiente, considerando que los Supervisores están en relación directa con los Colaboradores la forma de medir el rendimiento o performance debe contar con la información pertinente, al día, transparente y confiable sobre el quién, qué y cómo se hace. Para este efecto se sugiere utilizar un dashboard para disponer de la información concerniente a la metas y objetivos del equipo del Supervisor y de cada uno de sus Colaboradores, así como también de los resultados logrados.

Rol de los Supervisores

Esta sección es una traducción de parte del capítulo 1 del libro de Supervision: Managing for Results / Edition 10John Newstrom [2] y el objetivo es establecer formalmente cual es el rol de un Supervisor y que se espera de él. Para así identificar cuáles son sus necesidades de información para mejorar su performance.

¿Dónde participan los Supervisores en el proceso de gestión?

Son una parte esencial de ella. Los supervisores desempeñan exactamente las mismas funciones, en mayor o menor grado, como todos los demás gerentes en su organización, hasta el gerente general incluido. Cada tarea específica, cada responsabilidad, todas las funciones que los Supervisores están llamados a realizar son llevadas a cabo por el proceso de gestión (Figura 1). Este proceso se repite una y otra vez, diaria, semanal y anualmente, y consta de cinco amplias funciones. Desde el punto de vista de un Supervisor, cada función tiene un significado particular:

Planificar. Esta es la función de establecer metas y objetivos y convertirlos en planes específicos. Para un Supervisor, los resultados de la planificación incluyen horarios operativos, especificaciones de calidad, presupuestos de gastos, horarios y plazos. El proceso de planificación también establece políticas, procedimientos operativos estándar, regulaciones y reglas.

Organizar. En el desempeño de esta función, un Supervisor alinea todos los recursos disponibles, incluyendo herramientas departamentales, equipos, materiales y, especialmente, la mano de obra. Es en esta función que se diseña la estructura organizativa de un departamento y su trabajo se divide en puestos de trabajo.

Personal. Esta es la función por la cual los Supervisores hacen su aporte para generar una estructura organizativa efectiva para las tareas del día-a-día. Los Supervisores primero averiguan exactamente cuántos y qué tipos de empleados un departamento necesitará para llevar a cabo su trabajo. A continuación, entrevistan, seleccionan y capacitan a aquellas personas que parecen ser las más adecuadas para llenar los puestos vacantes.

Liderar. Esta función hace que la sangre fluya en una organización. Los Supervisores energizan los recursos humanos vitales de su departamento proporcionando motivación, comunicación y liderazgo.

Controlar. Una vez que los planes departamentales se ponen en marcha, los Supervisores deben mantener un monitoreo periódico sobre lo bien que están funcionando los planes. Para ello, los supervisores miden los resultados, los comparan con lo que se esperaba, juzgan la importancia de las diferencias, y luego toman cualquier acción que sea necesaria para alinear los resultados. El control está estrechamente vinculado a la planificación (como muestra la figura 1), porque las acciones de control se guían por las metas establecidas durante el proceso de planificación.

En teoría, los Supervisores realizan las cinco funciones del proceso de gestión en el orden indicado anteriormente. En la práctica, sin embargo, los supervisores realizan todas las funciones de gestión de una manera u otra cada vez que se actúa. Pueden encontrarse acortando la secuencia del proceso de gestión o retroceder en ella, en la medida en que cada situación problemática es única y requiere su propia solución.

Dashboard Supervisor 1

Fig. 1

¿Todos los gerentes son iguales?

No. Los gerentes y el trabajo que realizan difieren un poco según la organización en la que se encuentran (por ejemplo, organizaciones con fines de lucro y sin fines de lucro), el tamaño de la empresa, su industria, las normas culturales de su país, sus valores y experiencias personales, Y especialmente su nivel en la jerarquía de la organización. Esta última diferencia se ilustra en la Figura 2. En la parte superior de una organización están sus ejecutivos (a menudo un director ejecutivo -el Gerente General o CEO- y algunos vicepresidentes).

Los Gerentes de 1ª Línea o Ejecutivos están a cargo y son responsables de un grupo de otros gerentes. Los ejecutivos establecen una visión para la organización, definen su misión, desarrollan estrategias amplias, establecen objetivos y planes e implementan pautas generales de política. Luego motivan, dirigen y supervisan el trabajo de los gerentes que se reportan a ellos.

Los Gerentes de 2ª Línea o Administradores Intermedios planifican, inician y ponen en práctica programas destinados a cumplir los objetivos más amplios establecidos por los ejecutivos. Los gerentes intermedios motivan, dirigen y supervisan el trabajo de los supervisores (y de otros gerentes y empleados) que se reportan a ellos.

Los Supervisores se reportan a Gerentes de 2ª Línea. Los Supervisores son responsables de conseguir que los empleados de línea lleven a cabo los planes y las políticas establecidos por los Gerentes de 1ª y 2ª Línea. Los Supervisores planifican, dirigen, motivan y monitorean el trabajo de los Empleados a nivel operativo de la organización. Ejemplos de empleados de línea incluyen trabajadores de producción, cajeros de banco, asistentes, técnicos de laboratorio, programadores, enfermeras y miles de otros trabajadores “prácticos” y de “conocimiento” (por ejemplo, profesionales).

Dashboard Supervisor 2

Fig. 2

¿Cómo se juzga el desempeño de la supervisión por parte de la alta gerencia?

Se juzga por dos medidas generales: (1) qué tan bien maneja los diversos recursos disponibles para cumplir sus tareas y (2) cuán buenos son los resultados en términos de determinados criterios.

Dashboard Supervisor 3

 Fig. 3

Gestión de Recursos. La utilización de los recursos son las cosas que, de hecho, preparan a una persona para se supervisor. Incluyen lo siguiente:

  • Instalaciones y Equipos. Ejemplos son una cierta cantidad de espacio, escritorios, bancos, herramientas, maquinaria de producción y terminales de computadora. Su trabajo es mantener estos recursos funcionando de manera productiva y evitar su uso indebido.
  • Energía, Combustibles y Servicios Públicos. Entre estos recursos se encuentran el calor, la luz, el aire acondicionado, la electricidad, el gas, el agua y el aire comprimido. La conservación es la principal medida de eficacia aquí.
  • Materiales y Suministros. Se incluyen materias primas, piezas y ensamblajes utilizados para fabricar un producto y suministros operativos tales como lubricantes, artículos de papelería, discos de computadora, clips de papel y cinta adhesiva. Obtener el máximo de todos sus materiales y la generación de un mínimo de residuos son las medidas principales aquí.
  • Recursos Humanos. Esto se refiere a la fuerza de trabajo en general y a sus empleados en particular. El trabajo principal es ver que estas personas están presentes, entrenadas, productivamente comprometidas y motivadas en todo momento.
  • Información y Sistemas. Ejemplos de ello son la información facilitada por los departamentos de personal y que se encuentra en los manuales de funcionamiento, en las hojas de especificaciones y en las pantallas de los computadores. Su éxito a menudo depende de lo bien que pueda utilizar los datos y conocimientos disponibles a través de estas fuentes.

Todos estos recursos pueden medirse por medio de su Costo, aunque el dinero, efectivo real, raramente fluirá a través de las manos de un Supervisor. No obstante, se espera que los Supervisores sean prudentes en las decisiones que afectan los gastos y, a menudo, tienen que justificar esas decisiones en términos de ahorro u otros beneficios.

Gestión de Resultados. De ello se deduce que, si el Supervisor gestiona bien cada uno de sus recursos, debe obtener los resultados deseados. Cualquiera que sea su área de responsabilidad y cualquiera que sea su organización el Supervisor, puede estar seguro de que será juzgado a la larga por lo bien que cumple estos cuatro objetivos:

  • Cantidad. Específicamente, su departamento o unidad se espera que realice una cierta cantidad de trabajo por día, por semana, y por mes. Se espera que esto se haga a tiempo, según las especificaciones y dentro del presupuesto.
  • Calidad y Mano de Obra. El volumen de salida por sí solo no es suficiente. También se juzgará por la calidad del trabajo que realizan los empleados, ya sea que se mida en términos del número de defectos del producto, errores de servicio o quejas de los clientes.
  • Costos y Control Presupuestario. Sus esfuerzos de operación, producción y calidad siempre estarán restringidos por la cantidad de dinero que puede gastar para llevarlos a cabo. Universalmente, se pide a los Supervisores que busquen formas de reducir aún más los costos.
  • Gestión de Recursos Humanos. El Supervisor enfrenta muchos problemas potenciales en aspectos como: rotación de empleados, robo, impuntualidad, ausentismo, disciplina y moral. La gestión de estas dimensiones de la satisfacción y el comportamiento de los empleados será un elemento clave para el éxito.

Necesidad

A partir de los requerimientos de Gestión de Recursos y Gestión de Resultados se puede establecer que las necesidades de información de los Supervisores, es posible agruparlas en cuatro categorías, como se muestra en la figura 4.

Dashboard Supervisor 4

Fig. 4

Evidentemente la información requerida dependerá del trabajo específico que el Supervisor ejecuta, así se tienen actividades como las siguientes:

  • Call Centers
  • Servicios al Cliente
  • Servicios TI
  • Recurso Humanos
  • Cuentas por Pagar
  • Cuentas por Cobrar
  • Mantenimiento de Instalaciones y Edificios
  • Mantenimiento de Maquinaria
  • Producción
  • Logística
  • Compras
  • Ventas
  • Inventario
  • Control de Calidad
  • Inventario
  • Flota
  • Seguridad

Definición de Alcance

Establecido el tipo de trabajo que hacen los Supervisores para los cuales se necesita mejorar su disponibilidad de información el análisis debe enfocarse a:

  • Inventario de la Información que necesitan.
  • Identificar las fuentes donde la Información está disponible.
  • Formalizar los Resultados que deben generar y cómo serán o están siendo medidos.
  • Conocer el modus-operandi de los Supervisores por medio de entrevistas y observación de la operación del día-a-día.
  • Identificar como atiende las interrupciones y los imprevistos.
  • Generar el modelo as-is del proceso de Supervisión en estudio.

Toda la información recopilada deberá volcarse en un documento, por ejemplo: Definición de Alcance, Business Blue Print, ppt  o el formato que su organización utilice. Éste es conveniente que lo revisen los Supervisores y los Gerentes pertinentes.

Una vez que la Definición de Alcance está aprobada por quienes correspondan se seguirán los pasos de Autorización y Ejecución del Proyecto Dashboard, de acuerdo a las prácticas de su Organización.

Arquitectura del Dashboard

Versión 1. Es un programa que tiene link u otro mecanismo para activar las aplicaciones que proveen el ítem de información requerido, que se muestra según la interfaz de usuario de la aplicación en cuestión. En principio la comunicación es unidireccional y eventualmente tiene retorno al Dashboard (Fig. 5).

Es un simple menú que activa cada una de las aplicaciones que necesita el Supervisor, como mejora se le puede agregar la función Single Sign On, para activar la aplicación sin necesidad de ingresar password.

Dashboard Supervisor 5
Fig. 5

Versión 2. Una de las aplicaciones consideradas en la Versión 1 se asocia con una Aplicación de Presentación (Fig. 6), las características de estas son:

  • Está integrada al Dashboard y utiliza su estándar de interfaz de usuario.
  • Puede operar con las transacciones de la Aplicación n mediante WEB Services.
  • Puede presentar datos extraídos desde la Base de Datos “Dashboard”.
  • La Base de Datos “Dashboard” se carga y actualiza en tiempo real mediante un programa o servicio ETL —Extract, Transforn & Load– que se conecta con la Aplicación n.

Dashboard Supervisor 6

Fig. 6

Versión 3. Se repite el procedimiento de la versión 2 para cada una de las aplicaciones conectadas por link al Dashboard que se requieren integrar a éste a objeto de tener una interfaz estandarizada que facilite el trabajo de los Supervisores (Fig. 7).

Dashboard Supervisor 7

Fig. 7

Colofón

Todos los métodos psicológicos [3] para mejorar la productividad de los empleados son excelentes, pero son inútiles sin las herramientas adecuadas. Y las herramientas adecuadas significan la tecnología adecuada. Para que un Colaborador sea eficiente y productivo en el ambiente de trabajo de hoy es imprescindible equiparlos con el equipo adecuado. Las empresas que no actualizan o ignoran la necesidad de herramientas tecnológicas como PCs, Notebook, Tablets, Smartphone, Software y otras herramientas del siglo XXI, corren el riesgo de disminuir la productividad de los empleados.

Referencias

[1] https://www.accenture.com/t20161212T072538__w__/us-en/_acnmedia/PDF-13/Accenture-Strategy-Is-Performance-Management-Performing.pdf#zoom=50

[2] http://highered.mheducation.com/sites/dl/free/0073545082/323131/Chapter_1.pdf

[3] https://www.nbrii.com/employee-survey-white-papers/5-factors-that-affect-your-employees-productivity/

Modelos de Referencia – Reference Models

Este artículo es una introducción a los Modelos de Referencia, con el propósito de explicar su alcance y las razones de uso.
Para este efecto se muestran algunos modelos como TOGAF, utilizado para diseñar y especificar arquitecturas empresariales; COBIT, modelo de gobernabilidad para áreas de informática y SCOR, modelo para la cadena de suministro.
Y, a modo de ejemplo de aplicación se presentan modelos actualmente en uso en Embotelladora Andina S.A.: arquitectura empresarial y proyecto de implementación de proceso de negocios.

Definiciones Previas
A objeto de mejor entender los Modelos de Referencia y evitar confusiones, a continuación incluyo algunas definiciones que me parecen fundamentales.

Sistema

  • “El Todo y las Partes”. u Hesíodo (siglo VIII a.C.) y Platón (siglo IV a.C.)
  • “Sistema es una colección organizada de hombres, máquinas y métodos necesaria para cumplir un objetivo específico”.  u Estándar X3.12-1970 (ANSI), Estándar 2382/V, VI (ISO) Vocabulary for Information Processing .
  • “Sistema es un todo integrado, aunque compuesto de estructuras diversas, interactuantes y especializadas. Cualquier sistema tiene un número de objetivos, y los pesos asignados a cada uno de ellos puede variar ampliamente de un sistema a otro. Un sistema ejecuta una función imposible de realizar por una cualquiera de las partes individuales. La complejidad de la combinación está implícita“. u IEEE Standard Dictionary of Electrical and Electronic Terms.

Proceso de Negocios

  • “Un Proceso de Negocios es un sistema estructurado, con un conjunto específico de actividades diseñadas para producir una salida especifica ya sea para un cliente o un mercado particular.  Implica un énfasis fuerte en cómo el trabajo se hace dentro de una organización” u Davenport 1993.

Modelo

  • Representación gráfica, matemática (simbólica) o verbal; o versión simplificada de un concepto, fenómeno, relación, estructura, sistema o algún aspecto del mundo real. [1]
  • Los Procesos se representan –especifican– por medio de Modelos.
  • Un modelo es una representación aproximada de una realidad.
  • La disciplina que originalmente comenzó a estudiarlos es la Física y después la Teoría de Sistemas.
  • Ítem original a partir del cual se hacen copias o duplicados. [1]

Framework
Según Wikipedia en español:

  • La palabra inglesa framework define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular, que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

Y, en la versión en inglés:
Framework se refiere:

  • Software framework, es un conjunto de bibliotecas –librerías- o clases reusables para un sistema de software (o subsistema).

Modelo de Referencia

Un Modelo de Referencia en ingeniería de sistemas y en ingeniería de software es un modelo de algo que contiene un objetivo o idea básica de algo, y que se puede establecer como una referencia para múltiples propósitos. [2]

Un Modelo de Referencia es un marco de referencia abstracto para entender el significado de las relaciones entre entidades de algún ambiente. Permite el desarrollo de referencias específicas o de arquitecturas por medio del uso de estándares o especificaciones que soportan el ambiente en cuestión. Un Modelo de Referencia consiste de un conjunto mínimo de conceptos, axiomas y relaciones propios de un dominio particular de problema, y es independiente de estándares específicos, tecnologías, implementaciones, o de cualquier otro detalle concreto. [3]

Características

Abstracto: Un modelo de referencia es abstracto. Los elementos descritos por él  no son las cosas en sí mismas, sino que son representaciones de ellas. Por consiguiente, cuando se describe la arquitectura de una casa –plano-, las paredes tienen dimensiones y materiales, pero el concepto pared es parte del modelo de referencia. De este modo para construir las paredes de una casa es necesario entender los planos, y esto significa entender el modelo de referencia en cuestión. [4]

Entidades y Relaciones: Un modelo de referencia contiene tanto entidades (las cosas que existen) como relaciones (como las cosas interactúan entre sí). La lista de entidades no es suficiente para describir completamente un modelo de relación.

Inserto en el ambiente: Un modelo de referencia no pretende describir “todas las cosas”. Se usa para clarificar “las cosas en un ambiente” o espacio de un determinado problema o tópico. Para que el modelo de referencia sea efectivamente útil debe incluir una descripción precisa del problema que pretende resolver, y de las preocupaciones de quienes necesitan resolver dicho problema.

Tecnológicamente agnóstico: Un modelo de referencia no es útil si incluye consideraciones tecnológicas o de alguna plataforma computacional en particular. Un modelo de referencia es un mecanismo para entender un determinado problema, no es su objetivo proveer la solución  propiamente tal. Tiene que ser independiente de la solución, de modo de entregar valor a quien usa el modelo.

Razones de Uso

La utilización de los modelos de referencia está motivada por distintas necesidades, como ser:

Estandarización: Por medio de la creación de estándares, el trabajo de los ingenieros y de los desarrolladores que tienen la tarea de crear objetos, que tengan un comportamiento adecuado al requerimiento, se facilita mediante el uso de una base común de conocimiento y de reglas sobre el “cómo hacer”, este es el estándar. En particular, la implementación de proyectos, el desarrollo de software, el mantenimiento de las aplicaciones, etc. Esta labor se facilita mucho si sus respectivas definiciones están soportadas por modelos de referencia.

Educación: Por medio de los modelos de referencia los líderes de un determinado proyecto, sea de implementación, mejoramiento o desarrollo de software pueden organizarlo por partes o fases, descomponiendo el problema en partes más simples que puedan ser realizadas por distintos equipos profesionales. Esto lleva a que un grupo de profesionales aprenda a trabajar conforme a una regla general, y esto redunda en una mayor eficiencia a la hora de integrar los distintos componentes del proyecto como asimismo en disponer de la capacidad de realizar partes de un proyecto en paralelo. Un ejemplo es el uso de modelos EPC para describir un determinado proceso de negocios.

Comunicaciones interpersonales: Un Modelo de Referencia descompone un problema en entidades, o en “cosas que existen por si mismas”. Esto es a menudo un reconocimiento declarado de conceptos que ya mucha gente comparte, pero que son expresados de una manera explícita. Un Modelo de Referencia es útil cuando permite definir cuando los conceptos difieren y/o se relacionan. Estas cualidades del Modelo de Relación facilitan la comunicación entre las personas.

Roles y responsabilidades: Por medio de la creación de un modelo de entidades con sus correspondientes relaciones, una organización puede asignar personas específicas o equipos, dándoles la responsabilidad para resolver los problemas concernientes a un determinado conjunto de entidades. Por ejemplo, si un Modelo de Referencia describe un conjunto de indicadores para medir el negocio (KPI), cada uno de ellos pude ser asignado al ejecutivo que corresponda.

Comparación: Un Modelo de Referencia sirve para comparar cosas diferentes. Por medio de la descomposición del problema en conceptos básicos, puede utilizarse para examinar dos soluciones distintas para el mismo problema.

Modelos de Uso General

Corresponden a modelos propuestos por distintas organizaciones para atender un determinado tópico o área de trabajo, éstos son posibles de ubicar en la WEB, y muchos de ellos están a disposición del público. A continuación incluyo los modelos TOGAF, SCORE y COBIT a modo de ejemplos, para mayor detalle sobre cada uno su título tiene un link a las páginas que los describren.

TOGAF [The Open Group Architecture Framework]

TOGAF es un modelo de referencia que puede ser utilizado libremente –sin costo- por cualquier organización que desee desarrollar su arquitectura de sistema de información.

TOGAF se ha desarrollado y ha evolucionado continua mente desde mediados de los 90 bajo el alero del Open Group´s Archiecture Forum, actualmente este modelo va en su versión 9. A continuación incluyo el diagrama general de este modelo:

SCOR  [Supply Chain Operations Reference]

Se compone de un conjunto de secciones específicas, y se encuentra organizado en cinco procesos de gestión primarios: Planificación, Abastecimiento, Producción, Despacho y Retorno.

El modelo SCOR provee un marco estándar que permite vincular procesos de negocios, métricas, mejores prácticas, y tecnologías.

La siguiente figura muestra como se relacionan los procesos de la cadena de abastecimiento de una empresa, y a la vez como los procesos de ésta se relacionan con su entorno.

COBIT [Control Objectives for Information and related Technology]

Es un marco de referencia para controlar la TI, que se ajusta  y sirve como soporte al Committee Of Sponsoring Organisations Of The Treadway Commission. Es el marco de referencia de control ampliamente aceptado para gobierno de la empresa y para la administración de riesgos, en lo que se refiere a las operaciones de un área informática.

La figura siguiente muestra los procesos del área informática que considera COBIT.

Modelos de Referencia en uso en Embotelladora Andina S.A.

A continuación se incluyen ejemplos de aplicación de los modelos de referencia para la arquitectura empresarial, los proyecto de implementación de proceso de negocios y el mapa de proceso de negocios que actualmente se utilizan en Embotelladora Andina.

AEA (Arquitectura Empresarial Andina)

Está basada en el modelo la Federal Enterprise Architecture (FEA). Su representanción se muestra en la figura siguiente:

La figura que sigue muestra como se aplica la arquitectura para incorporar una nueva tecnología a la operación de la empresa, en este caso se trata de la Apple iPad.

Modelo Proyectos de Implementación de Procesos de Negocios

Este modelo está diseñado para proveer la base conceptual para ejecutar proyectos de implementación desde la perspectiva de los procesos de negocios basados en la disciplina Business Proocess Management (BPM). Como se podrá observar el modelo trata, al menos, las dimensiones: Organizacional, Procedimental y Transaccional del proceso.

Otros Usos para los Modelos de Referencia

Los siguientes artículos que he publicado tratan sobre Modelos de Referencia y su aplicación en distintos ámbitos:
Mapa de Negocios

Escala de Madurez – Process Maturity Model

El Anteproyecto de una Implementación BPM

Referencias

[1] http://www.businessdictionary.com/definition/model.html

[2] http://en.wikipedia.org/wiki/Reference_model

[3] http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

[4] http://en.wikipedia.org/wiki/Reference_model

Nota: Este artículo se basa en material de la presentación que realicé el 27 de Octubre del 2010 al Club CPO, que organiza el Centro de Estudios de Tecnologías de Información, CETIUC, de la Universidad Católica de Santiago.

Estructura Organizacional para la Operación con BPM

Si en una empresa se toma la decisión de operar sobre la base de procesos de negocios end-to-end, es necesario generar una organización ad-hoc. En efecto, este tipo de operación requiere contar con una estructura que dé Gobernabilidad a los procesos de negocios: desde su diseño, implementación, operación y mejoramiento. Y, por consiguiente es necesario responder a las preguntas siguientes:

  • ¿Quién o quiénes son responsables de la Gobernabilidad de los Procesos de Negocios?
  • ¿Quiénes son los responsables de la implementación y mejoramiento de los Procesos de Negocios?
  • ¿Quiénes tiene el accountability de los Procesos de Negocios?
  • ¿Quiénes los ejecutan?

Y, finalmente cómo se organizan estos quiénes.

Este artículo está basado en el trabajo de Janne J. Korhonen [1] y en mi participación en la creación y operación del Comité Condominio que se encarga de crear las políticas y coordinaciones para la operación de los sistemas informáticos de Embotelladora Andina S.A. para sus empresas en Argentina, Brasil y Chile,

Gobernabilidad de los Procesos de Negocios

La Gobernabilidad de los Procesos de Negocios es un subconjunto de la Gobernabilidad Corporativa y está estrechamente relacionada con la Gobernabilidad de las Tecnologías de Información [2].

Con Gobernabilidad de los Procesos de Negocios nos referimos al conjunto de normas, prácticas y estructuras organizacionales que hacen que los Procesos de Negocios se diseñen, implementen, operen, midan y perfeccionen.

Por tanto de éste concepto de Gobernabilidad derivamos que es necesario establecer una estructura normada y operativa, que permita el progreso y operación eficiente de los procesos de negocios. Para estos efectos ya existen actores definidos:

  • Dueño de Proceso de Negocios o Business Process Owner, responsable de un proceso de negocios y con accountability del mismo [3].
  • Consultor Experto en Proceso de Negocios o Business Process Expert (BPX), experto en un determinado proceso de negocios y en Tecnologías de Información, en particular con conocimientos amplios en algún software (ERP, CRM, SCM, etc.) [4].
  • Mapa de Procesos de Negocios, diagrama con la identificación de los procesos de negocios end-to-end de una empresa [5].

Luego, el tema pendiente por definir es como operan los Dueños de Procesos y los BPX con los procesos identificados en el Mapa de Procesos y las respectivas gerencias que los operan. Sabemos que los procesos por ser del tipo end-to-end “cruzan” la organización; es decir, requieren de la participación de varias unidades pertenecientes a gerencias distintas y, esto implica una estructura matricial en la organización. Establecer este tipo de estructura en una organización con tradición jerárquica es complejo por los costos políticos que significa. Por eso mí propuesta, basada en el trabajo de Janne J. Korhonen [1] y en mi experiencia en el Comité Condominio de Embotelladora Andina S.A., que opera de hecho como una sociocracia,  es generar una estructura basada en cuatro componentes:

  • El Comité Corporativo de Procesos de Negocios,
  • El Área de Consultores Expertos de Negocios,
  • Las Iniciativas de Procesos, y
  • La Ejecución de Proyectos de Implementación de Procesos de Negocios.

Definiciones Previas

De acuerdo con Maturana y Varela [6] un sistema consiste en una organización y una estructura. La organización define la identidad del sistema y corresponde a su configuración general. Mientras que su estructura muestra la forma de la interconexión –interacción- de las partes. Una empresa pueda ser vista como un sistema consistente en una organización y una estructura: las relaciones entre los agentes y las realizaciones específicas de los agentes. El sistema continuamente produce interacciones entre sus componentes, pero raramente en los componentes en sí.

Modelo Sistema

Independientemente de la organización existen cuatro niveles para la toma de decisiones en una empresa: estratégico, táctico, operacional y tiempo-real. Los ejecutivos superiores están involucrados en la toma de decisiones estratégicas, que son esencialmente formulaciones conceptuales de los objetivos de largo plazo. En el nivel táctico, los ejecutivos medios implementan y soportan la ejecución de las estrategias de largo plazo, monitoreando la utilización de los recursos y del rendimiento de las unidades a su cargo, y realizan la planificación táctica. En el nivel operacional, las decisiones se refieren a asignar y ejecutar tareas específicas más la asignación de los recursos que requieren. Y, finalmente en el nivel tiempo-real se hacen, realizan o ejecutan las tareas. Son realizadas como parte de la operación, en línea con los planes operacionales, por medio de la automatización o por personas. Estos niveles se representan en la figura siguiente:

Niveles de la Organización

Para cada nivel existe un mecanismo de control:

  • Estratégico <- Contrato, el Plan Estratégico es un contrato que especifica como la empresa se organiza para el logro de sus objetivos: identifica las unidades de trabajo para el negocio –core business-, asigna las responsabilidades para los distintos componentes de la organización –gerencias- que ejecutan los trabajos pertinentes, y especifica una visión global de los procesos de negocios que la organización debe ejecutar. Es en este nivel donde se generan los cambios organizacionales.
  • Táctico <- Coordinación, el Plan Estratégico o Contrato es transformado en coordinaciones entre los distintos componentes de la organización. Las decisiones a nivel táctico corresponden a adaptaciones de la estructura a los cambios del negocio. Requiere de metas específicas, mecanismos para medir la performance, políticas y accountability para cada una de las estructuras existentes o para las nuevas.
  • Operacional <- Control, las decisiones operacionales son realizadas por la estructura. Una unidad operacional tiene el control de los recursos en su estructura. La empresa puede cambiar su estructura por motivos operacionales, pero su organización se mantiene constante. El trabajo en este nivel es relativo al plan, trata con la asignación y control de las tareas de las personas.
  • Tiempo-real <- Modelo, las decisiones en tiempo-real son parte integral del modus operandi de la empresa. Ellas no impactan a su estructura ni a su organización. El trabajo a este nivel consiste en tareas y actividades discretas que son ejecutadas tanto por las personas como por las máquinas. La manera de hacer las cosas puede representarse o especificarse por medio de un Modelo.

A partir de la apreciación que la utilización de la disciplina Business Process Management (BPM) implica generar estructuras matriciales y, estas son muy difíciles de establecer en organizaciones con una fuerte tradición jerárquica, es que la distinción entre Organización y Estructura permite postular a Korhonen [1] que se puede crear la estructura matricial, requerida por BPM, sin alterar la organización mediante la implementación de Círculos Organizacionales o Comités del tipo sociocrático, que es a fin de cuentas una nueva forma de interacción entre las distintas gerencias o áreas de la empresa.

Por otra parte, los distintos tipos de control permiten establecer los niveles en los cuales deberán operar los Comités y a la vez clarifica que el control a los “que hacen las cosas” es mediante Modelos.

Sociocracia – Superimposición de un Círculo Organizacional sobre la Jerarquía.

Es una estructura (forma de relacionarse) que se puede aplicar a todos los niveles de organización incluyendo a todos sus miembros. La gobernabilidad de esta estructura está basada en el Círculo Organizacional, que se establece superimponiéndolo a la jerarquía administrativa existente (organización). Un Círculo es una agrupación de personas con un objetivo de trabajo común y que se ocupa de generar las políticas –policies. En las reuniones del Círculo se formulan y actualizan los objetivos, se realizan las funciones relativas a la operación, medición de performance y direccionamiento (directrices). También mantiene la calidad de sus recursos por medio de una capacitación integral.

Dado que en la organización pueden existir varios Círculos que operan sobre un mismo tema pero, en distintos niveles organizacionales. Se da que en un Círculo participan gente de un nivel más gente del nivel inmediatamente superior, de manera de tener doblemente enlazados ambos niveles por medio de la participación de, al menos, dos personas. Una de ellas, el Líder Funcional, representa al nivel superior y tiene el accountability de los resultados sobre el tema  asignado al Círculo y que deben generar las personas del nivel inferior, y el  otro es un representante del nivel inferior, el Delegado, elegido por consentimiento por la gente de su nivel.

Circulos Organizacionales

La mejor solución para un problema importante se genera a partir del conocimiento y sabiduría de aquellos que están más cercanos al problema, independiente de su posición jerárquica. Esto define que los participantes de un Círculo deben ser cercanos al tema.

Las decisiones en el Círculo se toman por Consentimiento, esto es cuando se da la ausencia de cualquier tipo de objeción. En el caso del Consenso la decisión se da cuando todos están de acuerdo, todos han dicho sí; en el esquema de Consentimiento la decisión se logra cuando nadie dice no. En la práctica las decisiones surgen, no se toman.

El principio del Consentimiento es también utilizado en las elecciones sociocráticas para elegir gente para que asuma determinadas funciones y responsabilidades. A diferencia de las democracias donde se vota secretamente y se gana por mayoría, en la sociocracia los votos son públicos, cada quien señala por quién vota y por qué. La gente puede cambiar su voto después de escuchar otros votantes y puede existir un facilitador para ayudar a generar el consentimiento del nominado. La elección finaliza cuando ya no hay más objeciones.

La operación de este modelo se representa en la figura siguiente:

Superimposición de los Circulos en los Niveles Organizacionales

El Comité Corporativo de Procesos de Negocios

El Comité Corporativo de Procesos de Negocios o Steering Committee representa el patrocinio del nivel gerencial superior y asegura el compromiso con los objetivos del negocio, especifica el contrato estratégico: el proceso colaborativo para establecer y desarrollar los procesos de negocios end-to-end. Los modelos establecidos son descriptivos, con especificaciones de los roles y los indicadores de performance (KPI). A este nivel los detalles no están definidos, pero el diseño está concentrado en la representación general de los procesos, siendo su objetivo principal comunicar el direccionamiento estratégico a los niveles operacionales.

De este modo el Comité de Procesos de Negocios articula la visión estratégica de la empresa en iniciativas que se alinean con las diseños de procesos de negocios (BPM) y con los objetivos del área Informática (TI). Este comité establece y prioriza las iniciativas de procesos de negocios, revisa y a prueba los portafolios de proyectos (roadmap), revisa y aprueba los proyectos presentados por el Centro de Excelencia o Área de Consultores Expertos en Procesos de Negocios, y asegura que proyectos aprobados tengan el debido patrocinio y presupuesto.

Específicamente, en este comité participa gente del Nivel Estratégico más la gente del Nivel Táctico. Por ejemplo en una corporación con divisiones nacionales o por países, el Nivel estratégico puede ser representado por el Chief Information Executive (CIO) y los niveles tácticos por los Gerentes de División.

El Área de Consultores Expertos en Procesos de Negocios o Centro de Excelencia (CdE).

El CdE coordina todos esfuerzos referidos a procesos de negocios en el nivel táctico y de acuerdo a los objetivos estratégicos. Lidera los proyectos de implementación o mejoramiento de los proceso de negocios auspiciados por el Comité de Procesos de Negocios. Entrena, capacita y facilita la ejecución de las iniciativas, construye las reglas de negocios y la arquitectura de procesos, desarrolla los estándares que facilitan la re-utilización y la interoperativilidad, favorece el uso de las best practices, documenta, implementa los requerimientos para satisfacer las exigencias legales y/o regulatorias. También apoya la generación de material de capacitación y la ejecución de la misma. El CdE tiene autoridad sobre los artefactos técnicos, tales como: modelos de arquitectura, modelos de procesos de negocios, reglas de negocios y servicios, metodologías de implementación, plataformas para diseño y desarrollo y protocolos de integración, convenciones de nombres y cualquier elemento que tenga relación con BPM.

Está área está conformada por los Expertos en Procesos de Negocios o Business Process Expert (BPX) y Consultores Funcionales. Y, en estricto rigor también puede ser un componente de la organización.

Iniciativas de Procesos de Negocios

También operan a nivel táctico. Tienen la propiedad de un proceso de negocio y coordinan los proyectos dentro de su ámbito de competencia. El dueño del proceso identifica las unidades que participan horizontalmente en el proceso end-to-end, designa las responsabilidades al nivel de ejecución de las tareas del proceso, descentraliza la ejecución del proceso al nivel operacional más pertinente. Planifica los proyectos y los prioriza de acuerdo con los criterios generales de la administración del Portafolio de Proyectos de la empresa.

Para los efectos prácticos las Iniciativas de Procesos de Negocios pueden estar a cargo de un Dueño de Procesos [2] o de un Comité del Proceso de Negocios XY, que tendrá una estructura similar al Comité Corporativo de Procesos de Negocios, pero referido al nivel Táctico y al Operacional.

La Ejecución de Proyectos de Implementación de Procesos de Negocios.

El Proyecto tiene el control sobre las implementación de una parte discreta del proceso de negocios, especificada por la Iniciativa de Proceso. Por lo general se realizan varios proyectos simultáneamente, cada proyecto estará alineado con las directivas del Portafolio de Proyectos.

La ejecución del Proyecto se podrá hacer conforme a la metodología de Implementación que la empresa tenga estandarizada, que por lo generar está organizada por fases, a modo de ejemplo se puede mencionar la ASAP de SAP.

Es una estructura temporal, se mantiene durante el período de ejecución del proyecto propiamente tal. En ella participan gente de las áreas Usuarias, del CdE y consultores externos a la empresa.

Interacciones

Las interacciones entre los entes que componen la gobernabilidad de los procesos de negocios se muestra en la figura siguiente:

Modelo de Operación de los Círculos

El Comité Corporativo de Procesos de Negocios provee al Centro de Excelencia y a la Iniciativa de Proceso con el marco necesario de directrices para que ellos puedan gobernar sus operaciones propias en sus respectivos Círculos. Basados en la visión y en la estrategia del Comité Corporativo de Procesos de Negocios, el CdE desarrolla los roadmaps y los planes de proyectos que incrementaran la productividad de la empresa y también entrega retroalimentación al Comité Corporativo. Por otra parte, cada Iniciativa de Proceso coordina con  el CdE los planes de proyectos teniendo como base los indicadores de performance requeridos por el Comité Corporativo. Tanto para el CdE como para la Iniciativa de Proceso los proyectos son gestionados mediante el Portafolio de Proyectos.

Luego, las implementaciones son realizadas mediante Proyectos, que son estructuras que se configuran en función del proceso en cuestión. La implementación se ejecuta conforme a los estándares y modelos definidos con por el CdE, quien también se hace cargo de mantener todos los artefactos técnicos generados por el proyecto.

Los miembros de cada Círculo se reúnen periódicamente para establecer políticas –policies-, responsabilidades –accountability– y roles. Los temas contingentes de los procesos no son tratados en los Círculos, sino que en la ejecución misma de los procesos (niveles Operacional y Tiempo-real). Así se tiene que el Comité Corporativo podrá reunirse mensualmente, por trimestre o según la necesidad. Las Iniciativas de Procesos podrán hacerlo quincenal o mensualmente. Y, los Proyectos semanalmente. El CdE se reúne regularmente o según demanda.

Los Círculos de la estructura de Gobernabilidad están doblemente enlazados, así se tiene:

  • Participan además en el Comité Corporativo de Procesos de Negocios el gerente del CdE, su participación es permanente y, los Dueños de Procesos de Negocios de cada Iniciativa de Proceso, éstos participación según necesidad.
  • El CdE tiene un representante en las reuniones de la Iniciativa de Procesos y viceversa.
  • El Líder de Proyecto participa en las reuniones de la Iniciativa de Proyecto cuando corresponda.

Referencias:

[1] http://jannekorhonen.fi/rcs.pdf

[2] https://msaffirio.wordpress.com/2006/07/09/gobernabilidad-ti-it-governance/

[3] https://msaffirio.wordpress.com/2008/01/20/dueno-de-proceso-de-negocio-%E2%80%93-business-process-owner/

[4] https://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/

[5] https://msaffirio.wordpress.com/2008/05/22/mapa-de-negocios/

[6] Maturana, H. & F. Varela (1980). “Autopoiesis and Cognition: The Realization of the Living”. Boston Studies in the Philosophy of Science, Vol. 42, Dordecht (Holland): D. Reidel Publishing Co.

Una Estrategia BPM para el Área Informática, Parte II

En esta segunda parte completaré las fases: Prototipo, Medir KPI por Procesos y Anteproyecto de la Estrategia BPM para el Área Informática.

Esquema General

Recordemos que la estrategia se presenta como un conjunto de fases secuenciales 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 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).
Estrategia BPM para el Área Informática

Prototipo

Con motivo de ganar en experiencia es conveniente realizar una proyecto de prueba, este es el Prototipo. Se trata de seleccionar un proceso de algún centro o filial, que sea de complejidad mediana y que represente una necesidad imperiosa para alguno de los gerentes involucrados. El objetivo es tener un “caso de negocio” que se pueda analizar y mostrar, de modo de tener un punto de referencia real al momento de planificar el proyecto BPM.

El Prototipo consta de las etapas:

Prototipo

Implementación

Es la habilitación propiamente tal de un proceso de negocios. El ideal es implementar un macro proceso (Nivel 1) de los inidentificados en el Mapa de Proceso o, en su defecto un proceso (Nivel 2). La implementación permitirá aplicar los conocimientos de BPM y de la metodología de implementación del Área Informática. Por ejemplo, si la empresa tiene productos SAP, lo típico será que aplique la metodología ASAP ajustadas a las necesidades de l a empresa.

En todo caso, es necesario disponer de herramientas para el modelamiento, que ayuden a generar los modelos as-is, los modelos to-be y el análisis de GAP. Me refiero a herramientas para modelar BPM no para hacer diagramas.

Como parte de la Implementación es necesario evaluar a la gente que participará en el proyecto, a objeto de establecer si tiene los conocimientos necesarios para abordar la ejecución de éste, en caso contrario se podrá diseñar un plan de capacitación.

Evaluación

Una vez terminado el prototipo se podrá cuantificar el impacto que generó en las áreas donde se intervino, en el Área Informática, en la plataforma tecnológica, etc. También se podrá evaluar el desempeño del equipo de proyecto y el fenómeno del cambio.

Ajustes Metodológicos

Un resultado específico de la Evaluación es medir cómo se aplicó la Metodología de Implementación con el fin de establecer si es adecuada, si incluye todos los aspectos que se necesitan y si los consultores la aplicaron bien.

De este análisis resultará una lista con los puntos de la metodología a revisar, o a eliminar o a incorporar, según corresponda. Este proceso y la Evaluación es también conocido, con el poco feliz nombre, de análisis post mortem que a pesar de su nombre es muy útil realizar para todos los proyectos.

Medir KPI por Proceso

La razón de medir KPI por Proceso es establecer de manera cuantitativa el estado de situación de un proceso de negocios antes de remodelarlo con BPM y después de implementado con BPM. Esta medición se puede realizar mediante KPI [1] y por medio de una Escala de Madurez [2], de este modo se puede:

  • Determinar el nivel actual de productividad mediante KPI, estos valores permiten establecer un punto de comparación respecto a los valores susceptibles de obtener una vez implementado el nuevo proceso de negocios con BPM. De este modo se tendrá una herramienta cuantitativa para medir el impacto real de la aplicación de BPM en la empresa.
  • El medir los procesos conforme a una Escala de Madurez provee un mecanismo básicamente cualitativo para establecer el nivel de desarrollo actual del proceso respecto a un desarrollo ideal u óptimo (los valores de la Escala de Madurez). La utilidad de esta media es establecer el real punto de partida para la nueva implementación y, de este modo fijar expectativas acordes con la capacidad organizacional de la empresa. Ejemplo: si se quiere implementar un proceso de Planificación de la Producción, deben estar operando previa y adecuadamente: La Proyección de Ventas, el MRP, el Programa de Mantenimiento Preventivo, etc.

Medir los KPI cuenta con las siguientes etapas:

Medir KPI por Proceso

Definición

Cada empresa deberá, conforme a su negocio y estrategia, establecer sus KPI. Que serán los mismos para toda la compañía. Es útil en la etapa de definición establecer el uso de KPI estandarizados, es decir indicadores que ya son usados por muchas empresas y sobre los cuales existen estadísticas conocidas o benchmark. Por ejemplo Coca-Cola Co. tiene un documento denominado White Book, éste contiene la definición, formula y valores de la industria para cada KPI.

Mecanismos de Medición

Se puede partir con un sistema de medición descentralizado y manual, esto es: cada KPI tiene un responsable de medirlo de alguna manera. Este mecanismos, aunque simple, ha demostrado en la práctica ser inadecuado.

Una forma más apropiada es establecer un proceso automatizado para la recolección de los datos necesarios para el cálculo de los KPI más un programa para su cálculo y presentación (dashboard, panel de control, etc.).

Es necesario ser pragmáticos en esta materia, ya que un afán de perfeccionismo puede llevar a la inoperancia. Por eso es preferible, en un comienzo, establecer operacionalmente la medición de 2 o 3 KPI por macro-proceso (Nivel 1) bien definidos y medidos, que una enorme cantidad de indicadores que dificultan establecer el mecanismo de medición y que muchas veces no son utilizados.

Benchmark

O Ranking, es una herramienta indispensable para establecer un mecanismo de medición con respecto a otros. Así por ejemplo, se pueden comparar los resultados de distintas divisiones, entre filiales o con la industria. Y, esto ayuda a determinar los puntos de mejoramiento que llevan a la excelencia operativa.

Existen empresas que venden los benchmark, esto es las definiciones y valores de los KPI, para determinadas industrias y, son herramientas muy valiosas ya que permiten establecer, en relación a la competencia, cual es el nivel efectivo de operación.

Oportunidades de mejoramiento

Establecido el Benchmark para un conjunto determinado de KPI por medio de la comparación de valores con respecto a la media de la industria se puede determinar cual proceso es que necesita una intervención.

También del ranking de KPI de la divisiones o empresas se puede derivar cuál de ellas necesita un mejoramiento. Nótese que este mejoramiento podrá ser en cuanto a Organización, Procedimientos y/o Sistemas Informáticos.

Anteproyecto

En este blog ya he tocado este tema [3], de manera que me referiré a los aspectos específicos de un anteproyecto BPM. El objetivo de este proyecto es implementar procesos de negocios basados en la disciplina BPM. Asumo que:

  • Al menos, se incluirán las dimensiones: Organización, Gobernabilidad (Procedimientos, Políticas, workflows, etc.) y Transacciones (Sistemas Informáticos) en los modelos.
  • La implementación se hará utilizando sistemas de Clase Mundial.
  • La empresa tiene, hace varios años, funcionando una plataforma informática.
  • El Mapa de Procesos de Negocios de la empresa ya está definido.

Para esta estrategia se considerarán las etapas siguientes:

Anteproyecto

Estrategia de Implementación

Esta debe indicar, en términos generales como se hará el proyecto de implementación. Si se hará una implementación gradual o una tipo big band; si se hará para toda la empresa o se hará por divisiones o filiales o países. Si se implementará por proceso o se hará para todos los procesos.

Debe incluir los criterios para la asignación de recursos tanto humanos como monetarios. También es pertinente analizar la transición del sistema antiguo al nuevo.

Es muy conveniente agregar el análisis de riesgos del proyecto, las acciones de mitigación y el plan de Gestión del Cambio.

Factiblidad Técnica

O posibilidad de implementación efectiva, consiste en determinar si la empresa está en condiciones de implementar los procesos de negocios de acuerdo a Best Practices o, en su defecto, establecer que debe realizar previamente.

Otro aspecto a evaluar es la capacidad técnica / operativa del personal para operar con los nuevos modelos de procesos y, de aquí derivar las necesidades de capacitación.

En este proyecto BPM, al igual que en cualquier proyecto de implementación de ERP, los datos a traspasar desde el sistema antiguo al que soportará los nuevos procesos de negocios es un tópico importante de evaluar: Calidad, Cantidad, Años de Historia, etc.

Este análisis de factibilidad debe incluir elementos funcionales adicionales a la operación actual. Por ejemplo. IFRS, Facturación Electrónica, Herramientas para Presupuestación, etc. De modo de aprovechar la ocasión para habilitarlos.

Factibilidad Económica

Debe entenderse que la motivación principal de ejecutar un proyecto BPM se origina en un hecho económico relevante para la empresa. De manera tal que el costo de mantener la situación actual debe ser mayor que el costo de implementación del proyecto en cuestión.

Una forma adicional de medir el valor agregado del proyecto es determinar a partir de los KPI correspondientes a los procesos as-is cuanto se incrementarán al tener operativos los nuevos procesos.

Plan de Implementación

Se refiere a generar una planificación muy detallada de las actividades necesarias para el proyecto y cuya expresión será un Carta Gantt, una lista de hitos, con sus respectivos criterios de aprobación más el plan de gastos.

Otro asunto a considerar en la planificación, es la determinación de los recursos externos necesarios, que implicarán llamados a propuestas (RFP), evaluaciones y generación de contratos.

Referencias

[1] http://es.wikipedia.org/wiki/KPI

[2] https://msaffirio.wordpress.com/2008/06/21/escala-de-madurez-%E2%80%93-process-maturity-model/

[3] https://msaffirio.wordpress.com/2009/08/29/el-anteproyecto-de-una-implementacion-bpm/

Una Estrategia BPM para el Área Informática – Parte I

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).
Estrategia BPM para el Área Informática

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:

Preparar al Área TI

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:

Patrocinio

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:

Mapa de Procesos

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].

Referencias

[1] https://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/

[2] https://msaffirio.wordpress.com/2008/06/21/escala-de-madurez-%E2%80%93-process-maturity-model/

[3] https://msaffirio.wordpress.com/2008/05/22/mapa-de-negocios/

[4] https://msaffirio.wordpress.com/2009/07/04/as-is-to-be-gap/