1. Estructura Organizacional para la Operación con BPM 24/07/10
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í.

2. 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:
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

3. 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.
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:

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

5. 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:

6. • 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] http://msaffirio.wordpress.com/2006/07/09/gobernabilidad-ti-it-governance/
[3] http://msaffirio.wordpress.com/2008/01/20/dueno-de-proceso-de-negocio-%E2%80%93-business-
process-owner/
[4] http://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/
[5] http://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.
Algunos Puntos Sobre la Aplicación de BPM 29/04/10
Posted by msaffirio in BPM, Informática, Management, Opinión, Proyectos.
Tags: BPM, Business Process, Proceso, Proyectos, SAP
2 comments
Partiendo de la base que BPM [1] es una disciplina del Management y que al área Informática se le asigna la
responsabilidad de la actualización de procesos de negocios: “pasar de silos a procesos E2E”. Quiero
comentar algunos aspectos que me han llamado la atención en los proyectos de implementación de
procesos de negocios que estoy supervisando.
La Limitación del Ámbito Tradicional de la Consultoría Funcional[1].
Un Consultor SAP tiene el entrenamiento y práctica para implementar procesos de negocios desde la
perspectiva de un módulo SAP, por ejemplo Fi-CO, HR, SD, etc. Y, la forma estándar que tiene para hacer
su proyecto de implementación es la metodología ASAP o alguna de sus múltiples variantes.
Por otra parte, el Consultor SAP con heridas de combate, partirá de alguna Best Practices provista por SAP,
la cual podrá bajar a SolMan y eventualmente traspasarla a ARIS [2].
Ahora, si queremos que este Consultor Funcional efectivamente diseñe e implemente procesos de negocios
E2E nos encontramos que tenemos que potenciarlo en:
• Capacidad para modelar procesos de negocios con una herramienta ad-hoc, por ejemplo ARIS.
• Conocimiento del proceso de negocios E2E en uso en la empresa (as-is).
• Capacidad de uso efectivo de Best Practices como modelo to-be.
• Capacidad para hacer análisis de brecha –gap- [3].
• Capacidad de trabajo en un equipo multidisciplinario.
En mi experiencia, un Consultor Funcional tiene la capacidad y el potencial para incorporar a su bagaje
profesional los puntos anteriores, sea con capacitaciones formales o mediante auto-aprendizaje.
Aplicando todas las capacidades antes mencionadas el Consultor Funcional es capaz de generar los modelos,
por ejemplo VAC y EPC, que representan un determinado proceso de negocios. Y, es al revisar en
profundidad los modelos en cuestión cuando aparecen las limitaciones del ámbito de acción del Consultor
Funcional y del Área Informática.
La revisión del modelo EPC nos lleva a visualizar claramente, al menos 3 dimensiones del proceso de
negocios:
• Organizacional, referida a los roles o estructuras organizativas. Se verifican mediante los símbolos:
• Procedimental, referida a los procedimientos y reglas de negocios, se verifican con los símbolos:

7. • Transaccional, referida a componentes de software y a transacciones, se verifican con los
símbolos:
Para cada una de estas dimensiones es necesario hacer el análisis de GAP respectivo, así para la dimensión
Organizacional se verificará como se corresponde la organización que hoy soporta al proceso versus la
necesaria para el proceso a implementar. Y, aquí el Área Informática puede señalar las diferencias
detectadas pero, no puede generar los cambios organizacionales pertinentes.
En el caso de los Procedimientos y Reglas de Negocios el análisis de brecha establecerá, en términos
generales, las diferencias entre el as-is y el to-be. Quedando pendiente la definición detallada tanto de los
procedimientos como de las Reglas del Negocios, esto porque estás definiciones tienen que establecerlas las
áreas de Procedimientos, o controles Internos o, la que antiguamente llamábamos Organización y Métodos.
Finalmente, solo la dimensión Transaccional es de total responsabilidad del Área Informática y aquí
podemos darnos cuenta que lo que hemos llamado Implementación de Proceso de Negocios, antes de la
introducción de BPM, no es más que la habilitación del software y sus correspondientes transacciones.
Cuestión que técnicamente consiste en la instalación y parametrización del software.
Como reflexión queda una explicación de la razón porque muchos proyectos de implementación son exitosos
pero, que no se usan debido a que no se trataron las dimensiones Organizacional y Procedimental, que
típicamente no son consideradas por el Área Informática.
La Necesidad de Contar con una Herramienta Adecuada para el Modelamiento.
Es evidente que para hacer un buen trabajo se necesitan las herramientas adecuadas, el modelamiento no
es la excepción. A mi juicio una herramienta es adecuada para el modelamiento cuando permite trabajar en
todos los aspectos del cometido.
Tiene que permitir tratar con todas las dimensiones del proceso de negocios que la empresa. Necesita
abarcar las tres dimensiones mencionadas en el párrafo anterior más Datos, KPI, Riesgos, Perfiles de
Usuario, etc.
Y, además de incluir los diagramas típicos: VAC, EPC, BPMN, etc. Debe tener un generador de reportes que
permita producir informes y matrices, como ser: Manuales de Procedimientos, Especificaciones de Cargos,
Matrices de Controles, etc. con los formatos ajustados a las necesidades de la organización.
También resulta conveniente que la herramienta facilite el trabajo concurrente en un mismo modelo, de
modo que simultáneamente puedan trabajar distintas personas cada una en una dimensión. Y, aunque no es
crítico, es muy útil contar con un mecanismo que automatice la publicación en la WEB de los modelos, para
que queden a disposición de los usuarios.
El Trabajo Multidisciplinario
La implementación de un Proceso de Negocios requiere un equipo multidisciplinario tanto de la perspectiva
de los especialistas como de los usuarios. Así se tiene que se necesitan especialistas para abordar cada una
de las dimensiones principales, esto implica profesionales expertos en diseño y especificación de
procedimientos, expertos en el tema de descripción de cargos, roles y perfiles más lo consabidos consultores
informáticos.
Para el caso de los consultores informáticos, en mi experiencia con SAP, resulta que se necesita uno por
cada módulo involucrado, ya que por lo general los consultores funcionales SAP conocen en profundidad uno
o dos módulos.
El equipo técnico por consiguiente estará conformado por varias personas que dependen de áreas distintas
de la Informática y, esto impacta en la programación de actividades y en el liderazgo del proyecto.
En cuanto a los usuarios, se necesitará al Dueño del Proceso, que en nuestras organizaciones es
prácticamente inexistente, más usuarios conocedores de los sub-procesos del proceso en uso en la empresa,
el as-is. Aquí la dificultad está en que es difícil encontrar un usuario que tenga la visión completa u holística
del proceso E2E.

8. De modo que, la conformación del equipo de trabajo para el proyecto de implementación del Proceso de
Negocio es una tarea prioritaria y que requiere arduas negociaciones para comprometer los recursos
requeridos. Y, su gestión como equipo precisa establecer un plan de apoyo y supervisión en el tema “trabajo
en equipo”, dado lo variopinto de sus integrantes.
Temas pendientes
Del análisis de los proyectos realizados me quedan pendientes los siguientes tópicos:
• El análisis de los tiempos requeridos por un proyecto de implementación tradicional versus una
implementación de proceso de negocios BPM.
• La incorporación formal de las actividades relacionadas con la dimensión Organización y con la de
Procedimientos, sea que la realice el área de Informática u otra.
• La generación de la implementación simultánea de las transacciones y los workflows representados
en los modelos EPC.
• El medio más adecuado para capacitar en los principios del BPM a la organización.
Referencias
[1] http://msaffirio.wordpress.com/2006/05/07/bpm-business-process-management/
[2] http://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-
practices/
[3] http://msaffirio.wordpress.com/2009/07/04/as-is-to-be-gap/
[1] Me refiero a Consultores Funcional SAP, es decir especialistas en la implementación y uso de uno o más
módulos SAP. Y, que además tiene certificación SAP.
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.

9. 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.
[3] SAP Best Practices

10. Algunas Dudas Respecto a un Proyecto BPM 8/11/08
Posted by msaffirio in BPM, Informática, Opinión, Proyectos.
Tags: BPM, BPX, COBIT, Dueño
add a comment
Existe siempre la duda respecto a que es primero el huevo o la gallina, así que aquí surge mi primera duda
¿Cómo efectivamente nos hacemos cargo del concepto Gestión del Ciclo de Vida o Life Cycle Management
(LCM? Esta interrogante me surge, por que como en muchas otras ocasiones, los informáticos no
embarcamos con gran facilidad en la nueva sigla de moda, me estoy refiriendo a BPM.
BPM, a mi juicio, importa para el área Informática un enorme desafío y no quiero que confundan el tener
dudas con estar en contra, ya que efectivamente BPM es el primer enfoque unificado de la perspectiva del
negocio y la de las tecnologías de información [1]. Entonces mi preocupación es que no se frustre esta
disciplina en el mar de los papers, ppt, marketing y cotilleo tecnológico.
La Perspectiva de los Sistemas Informáticos
El LCM [2] nos indica que todo sistema tiene una fecha de partida y una de término, período que
típicamente es de seis años. Por simplicidad asumiré que este período se divide en el proyecto de
implementación y la operación propiamente tal [3]. De esta clasificación se tiene que el proyecto de
implementación ocupa un 1/6 del ciclo y la operación 5/6.
Por otra parte si asumimos que un proyecto de implementación tiene por objetivo habilitar, para la
organización, el uso de un nuevo sistema; queda claro que una función objetivo es optimizar el uso de dicho
sistema. En simple, si el sistema no es utilizado entonces tenemos un proyecto fracasado.
En el artículo de la referencia [3] menciono someramente que para que un sistema tenga una probabilidad
alta de ser usado, se necesita que el proyecto tenga en consideración los objetivos y entregables que se
requieren para la Gobernabilidad y para la Operación. De aquí se desprenden dos preguntas:
La Operación
Me centraré en la Operación, asumamos que estamos de acuerdo con incorporar a nuestra organización la
disciplina BPM, ¿Qué nos dice ésta? Qué se requiere tener procesos de negocios formalizados; luego,
necesitamos procesos formalizados en el área Informática, recuerden que esa área hoy es vital para el
negocio. La formalización de los procesos de un área Informática no es necesario inventarlos, ya tenemos
los modelos, a nivel general, especificados en la COBIT [4].
Mi preocupación por los procesos operacionales del área Informática se debe a, que en general, el énfasis
está en la ejecución de los proyectos, y no en el uso de los sistemas, por tanto si la empresa decide hacer
un proyecto para introducir BPM, es decir un proyecto de Actualización Funcional, me parece que lo primero
es establecer una plataforma de procesos TI que garanticen que los nuevos sistemas serán utilizados de
acuerdo a su diseño y así aumentar la probabilidad de éxito del proyecto BPM. Entonces la secuencia debe
ser:
1. Análisis de GAP de los procesos del área Informática usando como base de referencia los procesos
COBIT. Priorizar los procesos de Administración de Ordenes de Cambio (Mantenimiento), Soporte y
Capacitación.
2. Ejecución del proyecto BPM para los procesos del área Informática.
3. Establecer los mecanismos de Gobernabilidad para los procesos del área Informática.

11. 4. Definir para los proyectos de implementación cuales serán los entregables para las áreas de
Mantenimiento, Soporte y Capacitación.
El Proyecto BPM para el Área Informática
Este proyecto BPM para los procesos de Informática tiene el mérito de permitir que el área tenga un terreno
donde hacer la práctica con BPM y resolver:
• La Capacitación, una persona capacitada adecuadamente podrá usar un sistema de manera
eficiente. Las personas rotan y por tanto la capacitación es una necesidad vigente durante 5/6 del ciclo de
vida del sistema.
• El Soporte, los usuarios están centrados en su función específica y por ellos son medidos y
remunerados, ergo su preocupación fundamental es hacer su trabajo. Cualquier dificultad con los sistemas
que interrumpa la generación de los resultados esperados es crítica para el usuario, pues pone en riesgo su
idoneidad. De modo que se necesita proveerle ayuda efectiva y oportuna para que supere los problemas que
se presentan con los sistemas.
• El Mantenimiento o Administración de Cambios, sabemos que a lo largo del tiempo se
descubren errores –bugs- en los sistemas que son necesarios de corregir, por otra parte la dinámica del
mercado impone cambios en las reglas de negocios, que son necesarias de actualizar en el sistema –
parametrizaciones o funciones-. Esta actividad permite que el sistema esté efectivamente alineado con el
negocio.
• Gobernabilidad, me refiero aquí a la correspondiente a los procesos de negocios propiamente
tales y a los procesos del área TI. El cumplimiento con Sarbanes – Oxley obliga a tener los procesos del área
Financiera y de TI auditados. Al comparar la ejecución efectiva de estos procesos en relación a otros no
auditados, la balanza se inclina totalmente hacia procesos auditados, ya que obliga a que los procedimientos
se ejecuten de acuerdo a sus definiciones y que el personal este bien capacitados. Ambos conceptos hacen
que la utilización de los sistemas sea de mejor calidad.
A Tener en Cuenta
Es claro que la introducción y puesta en operación de la disciplina BPM es un camino arduo. Y que como
muchas cosas el aprendizaje se logra mediante la aplicación y uso de la herramienta. En este caso, nos
encontramos con dos desafío a superar:
Cómo hacer que nuestros Consultores Funcionales evolucionen a Business Process Expert BPX.
Cómo generar el rol de Dueño de Proceso de Negocios.
Me parece que un punto de partida, muy útil y de bajo riesgo, es la formalización de los procesos de
negocios de TI, ya que nos provee por una parte una ámbito controlado para aprender y experimentar. Y,
ala vez nos permite establecer una plataforma sólida para apoyar el buen desempeño de los procesos de
negocios que se formalizarán y rediseñarán con BPM.
Referencias
[1] http://msaffirio.wordpress.com/2006/05/07/bpm-business-process-management/
[2] http://msaffirio.wordpress.com/2006/04/08/costo-total-de-propiedad-tco-y-administracion-del-ciclo-de-
vida-lcm/
[3] http://msaffirio.wordpress.com/2008/07/26/dimensiones-de-un-proceso-de-negocio-%E2%80%93-
business-process-dimension/
[4] http://msaffirio.wordpress.com/2007/03/03/la-cobit-y-la-organizacion-del-area-informatica/
Diseño de Portales – Portal Design 16/08/08
Posted by msaffirio in Informática, Sistemas.
Tags: Diseño, Portal, Sistemas
add a comment
El motivo de este artículo es ver como en los portales de empresas se tiende a crear páginas multimediales,
llenas de abalorios; que por una parte hacen más lenta la operación y, por otra no aportan nada. En la falsa
idea que una entrada con una pagina atractiva, entendiendo por tal una llena de multimedia y botones que
bailan, generará en el usuario el deseo de retornar al portal. Este enfoque lo llamo de “publicistas”, les
plantearé un enfoque de “informáticos”.

12. Mi punto de vista es que los usuarios ocuparan el portal en la medida que éste les ofrezca información y,
herramientas útiles para la ejecución de sus respectivas labores. Si el portal no brinda utilidad a un usuario,
él no volverá a ocuparlo.
Por tanto, desarrollaré algunos aspectos del portal respecto a lo útil, es decir que es lo pertinente y
adecuado tener en él. En otras palabras intentaré describir algunos conceptos básicos de diseño [1],
partiendo por definir la utilidad del objeto que se pretende crear: un portal.
Definición
Un portal de empresa -enterprise portal-, también llamados enterprise information portal (EIP) o corporate
portal, es un mecanismo para la integración de información, personas y procesos dentro de las fronteras de
una organización. Provee un punto único y seguro de acceso a información organizada por roles, es decir
cada persona tiene acceso a la información que corresponde a su rol o cargo. Un aspecto destacado de los
portales es su capacidad para operar descentralizada mente en la creación y administración de contenidos,
cuestión que facilita el mantenimiento actualizado de la información [2].
“Los portales son básicamente para uso interno dentro de una empresa”
Funciones de un Portal
Idealmente un portal debiera ser la interfaz única para los usuarios de una empresa, a través de la cual
tienen acceso a todas las aplicaciones que ocupan y a toda la información que necesitan para la realización
de sus tarea. Este objetivo no parece simple de alcanzar y por tanto un objetivo más razonable es contar
con un portal para distribuir información y fomentar el trabajo colaborativo, desde esta perspectiva las
funciones son:
• Generación y publicación de contenidos, simplificando el portal permite la creación de
“carpetas” en las cuales se puede guardar documentos (PDF, texto, presentaciones, planillas, etc.) que
puede ser accedidos por los usuarios. Para la generación de contenidos y su publicación normalmente
existen workflows que sistematizan y ordenan esta tarea. A modo de ejemplo: puede existir una carpeta
denominada “Informes de Producción” y en ella se almacena los Informes Semanales (típicamente planillas),
esta simple operación ayuda a distribuir y a mantener las copias “oficiales” de los informes. Otro ejemplo:
tener una carpeta de “Procedimientos” en las que se guardan los documentos que los describen, para estos
documentos resulta muy útil la funcionalidad de control de versiones de un documento.
• Workflows, es la automatización de un proceso de negocio, sea parcial o totalmente, durante el
cual documentos, información o tareas son pasados desde un participante a otro para la ejecución de otra
acción, de acuerdo a un conjunto de reglas procedurales [3]. Por tanto para el portal nos interesan los
workflows que pueden operar en él. Por ejemplo un workflow para reasignar partidas presupuestarias, o
para autorizar una solicitud de compra, etc
• Aplicaciones, nos referimos a cualquier programa que resuelve una necesidad del negocio que
funciona en el portal. Por lo general son funciones para entrega de información o para transacciones de bajo
volumen. Por ejemplo una aplicación de business intelligence que entrega información de venta, o un
sistema para la administración de contratos, etc. Un caso especial de aplicación es el material para
capacitación, que si puede tener material multimedial.
• Trabajo colaborativo, se refiere al uso que un grupo de personas de un equipo de trabajo puede
darle al portal para ejecutar su actividad. Al menos esta funcionalidad incluye: salas de colaboración, que
son lugar donde los miembros del grupo pueden colocar documentos y compartirlos, mecanismos para hacer
presentaciones remotas, chat, foros, etc. Entonces para un equipo de proyecto que opera en varias
locaciones simultáneamente esta es una muy buena herramienta para intercambio de información, para
comunicación y coordinación, por ejemplo las reuniones de control de avance se pueden proyectar para todo
el equipo en sus lugares respectivos de trabajo con la herramienta de presentaciones, la carta Gantt se

13. puede dejar en la sala de colaboración y la generación y evolución de la minuta se hace con la herramienta
de generación de contenidos.
Consideraciones para el Diseño
Establecida la funcionalidad del portal, que puede ser la señalada en los párrafos anteriores u otra, la
pregunta a hacerse desde la perspectiva del diseño es ¿Cuál es la interfaz más adecuada para cada función?
Al respecto me referiré, en esta oportunidad, al home page.
Siguiendo con nuestro modus operandi, primero establecemos las características del home page que
necesitamos:
• Que tenga un diseño de acuerdo a la imagen corporativa de la empresa (logo, colores, tipografía,
etc.)
• Que muestre las últimas noticias relevantes de la compañía
• Que incluya la lista de opciones propias del usuario
• Que el scroll sea sólo hacia abajo o hacia arriba, pero no hacia los lados (izquierda – derecha).
• Que contenga avisos relevante y links hacia sitio relevantes para la empresa.
• Que los temas más importantes vayan en la parte superior y los de menor importancia más abajo.
• Que la gráfica se use con moderación, teniendo siempre presente que la función a optimizar es la
facilidad y velocidad al tópico de información que al usuario interesa.
Ejemplos
Para ilustrar estos conceptos les incluye el sitio SAP Community Network y el Washington Post que a mi
juicio cumplen a cabalidad con el objetivo de presentar y destacar los tópicos importante y de poder llegar
fácilmente al tema que importa, sin elementos distractores.
Sitio SAP Community Network
Este sitio tiene por misión entregar información a profesionales de las área de programación y desarrollo
más al área de expertos en procesos de negocios. Incluye también un foro para hacer consultas y pedir
ayuda en temas relacionados con los productos de SAP AG. Este portal es para público general, para
suscriptores (gratis), para socios de SAP y para empleados de SAP. No incluye publicidad de terceros.
Portal SAP Community Network
En esta página podemos observar 5 secciones:
1. La barra de menú u opciones, que dependerá del perfil del usuario.
2. La sección de la izquierda con fondo azul, que incluye links hacia área o aplicaciones específicas,
cuya lista de opciones también depende del perfil del usuario.

14. 3. El área central, sobre la línea azul, muestra ocupando todo el ancho en su parte superior la noticia o
aspecto más destacado. Y, debajo estructura dos columnas, en la que se incluyen dos tópicos destacados.
4. El área central, bajo la línea azul tiene muchas secciones al las que se llega con el scroll vertical, y
cada una de ellas incluye links a los temas de interés.
5. La sección izquierda, incluya en forma de columna avisos de eventos.
Sitio de Washington Post
El Washington Post es uno de los periódicos más influyentes de USA y que es un referente para estar
informado sobre la política norteamericana. Este portal es para público en general y para suscriptores.
También incluye publicidad de terceros (casualmente aparece SAP y Toyota),
Períodico Washington Post
En esta página podemos distinguir 5 secciones.
1. En la parte superior, antes de la barra de menú azul, existen links para funciones de ingreso y
suscripción, debajo esta la identificación gráfica del sitio y a la derecha existe un espacio para publicidad
estática.
2. Después viene la barra azul con las opciones de menú, que llevan a la distintas secciones de
información.
3. Columna de la izquierda, incluye foto para ilustrar la noticia más destacada.
4. Sección central, presenta los titulares o noticias destacadas.
5. Columna derecha, tiene una sección que resalta los artículos más leídos, un cuadro con aviso previo
–Advertisement- para publicidad con material multimedial y la parte inferior apunta a material de video.
Conclusiones:
La gran deferencia entre el SAP Commuty Network y el Washington Post, es que este último hace publicidad
explícita pero, lo hace de una manera no invasiva, es en lugares pre-establecidos y con un espacio que no
es mayor que la foto de la noticia destacada. Podemos ver que tienen una organización –estructura- simple
que a primera vista permite seleccionar el tema que interesa y, ambos tiene secciones con material de video
en áreas ad-hoc. Los dos sitios ocupan sólo el scroll vertical.
Referencias
[1] Principles of Design http://www.digital-web.com/articles/principles_of_design/
[2] Enterprise Portal http://en.wikipedia.org/wiki/Enterprise_portal
[3] Workflow Definition http://www.e-workflow.org/