Capítulo 5

planificación para obtener ganancias

Bryan Ward

1 INTRODUCCIÓN

1.1Buenas y malas noticias

En muchas organizaciones, especialmente en los niveles más altos de administración,
el rol y el uso de TI se considera con sentimientos encontrados.

En el lado positivo, se reconoce que las aplicaciones y servicios de TI apropiados

pueden cambiar la forma en que operan las empresas. Por ejemplo, un Director de
Finanzas de una compañía multinacional comentó recientemente. "Con sistemas
administrativos y de oficina más sofisticados basados en tecnología conectados por
redes de comunicación globales, estamos experimentando una aceleración
significativa de la actividad comercial, como resultado de una capacidad de
comunicación de la más alta calidad, tanto dentro de la organización como con clientes
y proveedores. Mejoramos significativamente nuestro nivel de servicio al cliente. Estos
sistemas basados en la tecnología también están cambiando la forma en que hacemos
nuestro trabajo ".

Otros reconocen que, con una planificación adecuada, TI puede ofrecer una ventaja
competitiva, reducir costos, evitar gastos y mejorar la calidad de la toma de decisiones.
Además, TI también puede representar una gran contribución a los beneficios de la
organización, por ejemplo, facilitando el lanzamiento más temprano de nuevos
productos.

Sin embargo, siguen existiendo dudas importantes sobre la eficacia real y la gestión de
TI, como lo ilustran las siguientes citas:

 gastamos una fortuna en el procesamiento de datos. Me resulta difícil ver las

grandes mejoras que el procesamiento de datos ha contribuido a esta
organización en los últimos 5 años. Gerente General, Seguros
 los sistemas de elaboración de presupuestos desarrollados por el
departamento de informática son demasiado ingeniosos y complicados para
que las personas de mi departamento los utilicen. Director Financiero,
Gobierno Local
 ellos (Procesamiento de datos) cobran una fortuna y tenemos poca opción más
que usar lo que proporcionan. Director de la industria minorista
 Estoy convencido de que la tecnología de la información puede ayudarnos a
abrir nuevos caminos. pero lleva tanto tiempo para que una buena idea se
desarrolle en un proyecto definible. Además, a mis directores les resulta muy
 difícil cuantificar los beneficios potenciales que se pueden obtener. Presidente,
Líder Multinacional

1.2Preocupaciones actuales sobre TI

Las citas anteriores son síntomas de que algo está significativamente mal en la forma
en que se planifica y controla la TI. Los estudios detallados han centrado la atención en
los siguientes temas principales de preocupación:
(a) Gasto
- ¿Cuál es su gasto total de TI?
- ¿Qué tan efectivo es nuestro gasto de TI?
- ¿Está nuestro gasto en línea con nuestros competidores?
- ¿Qué aumento en el gasto de TI deberíamos anticipar?
(b) Beneficios / valor
- ¿Nuestras aplicaciones de TI se ajustan a nuestras necesidades comerciales?
- ¿Estamos obteniendo un retorno de la inversión satisfactorio?
- ¿Podemos juzgar las TI de la misma manera que otros proyectos?
(c) Planes / controles comerciales
- ¿Pueden los principales proyectos ser propiedad, administrados y controlados
por altos ejecutivos?
- ¿Cómo podemos vincular nuestra estrategia de TI con nuestra estrategia
comercial?
- ¿Puede IT realmente usarse como arma competitiva?
La consecuencia de estas preocupaciones planteadas por los altos ejecutivos es que
son cada vez más reacios a invertir más en TI hasta que se proporcionen respuestas
acertadas.

1.3Administrando TI como un recurso estratégico

En muchas situaciones, TI ha adquirido un estado estratégico de forma gradual e
invisible. La alta dirección ha aprobado proyectos de TI en el pasado, como la entrada
de pedidos en línea, la administración de materiales, los principales sistemas de
procesamiento de transacciones, etc., sin darse cuenta del impacto en el negocio. Por
lo tanto, TI ha evolucionado de un rol de apoyo a uno que es vital para la existencia
misma de la empresa. Con demasiada frecuencia, esto solo se hace aparente cuando el
presupuesto del PD del próximo año llega con promesas como '... y este dinero debe
ser aprobado, o bien ...'.
En contraste, algunas compañías han logrado la introducción de TI como un recurso
estratégico. Han dicho: 'Aquí está nuestra estrategia comercial. Aquí está nuestra
estrategia competitiva '. Luego, trabajaron con su gestión funcional de TI y dijeron:
'¿Hay un rol para que las TI apoyen nuestras principales estrategias?' Si lo hay, la TI se
convierte en un componente necesario de una inversión estratégica mucho más
grande.

La diferencia entre estos "estilos" de gestión de TI a menudo se puede ver al preguntar

a los directores ejecutivos (CEO) cómo ven sus gastos de TI. Las respuestas varían
entre:
(a) Un 'águila' que materialmente ayuda al negocio a 'volar' hacia el archivo de metas y
objetivos comerciales a corto y largo plazo.

(b) Un 'albatros' que pesa sobre la empresa al contribuir poco a las necesidades reales
del negocio y hacer una 'contribución' importante a los gastos generales.

1.4Selección de aplicaciones rentables

Para que una empresa perciba a TI como un 'águila', la Junta debe tener roles,
responsabilidades y propiedad claramente definidos en relación con la administración
estratégica y el uso de TI. Para pasar al estado de 'águila' y mantenerlo, es necesario
que la Junta lo revise regularmente:

(a) Los objetivos de negocio fundamentales y los objetivos que TI debe apoyar (de
Gues, 1988)

(b) Las aplicaciones y servicios basados en TI que probablemente generen los mejores
rendimientos (ganancias) en apoyo de las metas y objetivos del negocio.

(c) Los recursos (personas, dinero, etc.) que deben asignarse al desarrollo,
implementación y uso sostenido de las aplicaciones y servicios basados en TI.

Pero la asignación estratégica de recursos a menudo está llena de ansiedades.

Naturalmente, existe una disputa entre el equipo de gestión por los recursos a
menudo limitados disponibles. En última instancia, el CEO debe arbitrar y decidir, pero
¿cómo puede el CEO aumentar la probabilidad de hacerlo bien? ¿Cómo se puede
lograr el consenso dentro del equipo?
En IBM se ha desarrollado un enfoque estructurado para abordar estos problemas en
los últimos ocho años (Hardaker y Ward, 1987). Este enfoque, conocido como 'Gestión
de Calidad de Procesos' (PQM), está diseñado para ayudar al equipo de gestión a llegar
a un consenso sobre las actividades del negocio más críticas; es decir, aquellos cuyo
desempeño tendrá el mayor impacto en el éxito o el fracaso de la empresa. Se ha
encontrado que el acuerdo sobre estas actividades establece una base sólida para la
determinación de las prioridades de TI. Por lo tanto, las preocupaciones expresadas en
la Sección 1.2 anterior pueden abordarse de una manera más estructurada y se puede
formular un enfoque planificado para la maximización de los beneficios de las
aplicaciones basadas en TI.

Este capítulo describe PQM, resume las experiencias adquiridas al usarlo en una amplia
variedad de situaciones y proporciona pautas prácticas para aquellos que deseen
utilizar la Metodología.

2 LA METODOLOGÍA DE 'GESTIÓN DE LA CALIDAD DEL PROCESO' (PQM):

VISIÓN GENERAL
2.1 Objetivos
La filosofía fundamental de PQM es que las aplicaciones y servicios basados en TI son
una parte integral de las opciones estratégicas de la empresa como un todo. PQM es
esencialmente un enfoque de arriba hacia abajo, orientado a los negocios.
Los objetivos de PQM son permitir que el equipo de gestión:

(a) Identifique los requisitos clave para mejorar el rendimiento de los negocios
generales de la empresa
(b) Llevar a cabo una auditoría sobre la inversión actual en aplicaciones y servicios
basados en TI
(c) Identifique las principales oportunidades y prioridades para futuras inversiones en
aplicaciones y servicios basados en TI
(d) Revise la relevancia de los Proyectos actuales de mejora de la calidad (si sale un
Programa de calidad)
Para respaldar los objetivos de la Metodología es necesario que el equipo de gestión
acuerde conjuntamente sus necesidades de negocio antes de discutir las prioridades
de TI y el financiamiento futuro.

2.2 La base de la metodología PQM

Las raíces de PQM se encuentran en la Metodología de planificación de sistemas de
negocio de IBM, que proporciona un análisis de arriba hacia abajo de los requisitos de
información del negocio. Además, PQM utiliza el concepto de Factores de Éxito Críticos
para alentar a los equipos de gestión a centrar su atención en los problemas críticos
del negocio, y luego basar la estrategia de TI en estos.
Inicialmente, el enfoque de PQM se orientó hacia la identificación de oportunidades
estratégicas de TI para respaldar los requisitos de negocio. El uso de la Metodología
involucró a todo el 'equipo superior' de una empresa y requirió dos días de su tiempo.
Posteriormente, la Metodología PQM fue desarrollada para analizar la calidad de los
procesos de negocio como parte de una unidad de calidad importante dentro de IBM.
A partir de 1983, PQM también se ha utilizado para sesiones de planificación centradas
en los negocios y las TI con los equipos de alta dirección y, además, se ha utilizado con
la alta dirección para analizar los principales proyectos de "cambio cultural".
Finalmente, PQM se ha mejorado recientemente para abarcar un amplio espectro de
actividades adicionales.

2.3 La Metodología PQM: ¿qué es diferente?

Hay una serie de enfoques ofrecidos por las casas de consultoría en todo el mundo,
que permiten a los equipos de gestión identificar sus prioridades de negocio. Estos
enfoques, aunque tienen objetivos generales similares, tienden a enfatizar diferentes
aspectos. PQM pone especial énfasis en lo siguiente:
(a) Se centra en el consenso y el acuerdo del equipo, destaca los principales problemas
y luego proporciona la motivación y el marco para que el equipo tome medidas.
(b) El tiempo requerido para la sesión de planificación es corto, dos días. Pero, por
supuesto, hay una gran cantidad de trabajo de seguimiento que hacer.
(c) El resultado de la sesión de planificación es muy conciso y orientado a la acción.
Un taller de PQM primero definirá la razón de existencia de un equipo: la Misión (en el
caso de la Junta esto definirá la razón de la existencia de la empresa misma). Luego, el
equipo desarrollará la cantidad limitada de elementos que se deben abordar si se
quiere lograr la Misión. Estos son los factores críticos de éxito (CSF). A continuación,
establecen los Procesos de Negocio clave necesarios para gestionar cada uno de los
CSF e identificar posteriormente cuáles son los Procesos Más Críticos (MCP), es decir,
aquellos que necesitan atención de gestión urgente. A continuación, se realiza una
revisión de cómo TI es compatible actualmente con estos procesos.

2.4 El Proceso PQM

Una visión general del proceso PQM se muestra en la figura 1.

2.5 Participantes PQM Estudios

2.5.1 El patrocinador

El patrocinador del estudio (con frecuencia denominado el "administrador de

clasificación") debe ser la persona que desempeña la misión, el líder del equipo de
gestión en particular. El patrocinador debe tener claro los pasos a seguir durante la
sesión de planificación, el momento aproximado de cada fase y su rol durante la
reunión. El patrocinador preside la sesión de planificación, en la que debe estar
presente todo su equipo de gestión.
En ciertas circunstancias, no hay consenso universal al comienzo de un estudio de
que el propietario de la misión es el "gerente de clasificación". Esto puede ocurrir
con equipos provenientes de muchos mercados de una empresa para administrar
un proyecto, constituir un grupo de trabajo o ser responsable de uno o más
procesos comerciales (multifuncionales). En la mayoría de los casos, el uso de PQM
ha creado un consenso sobre el liderazgo, pero el facilitador requiere mayor
vigilancia al comienzo de la sesión de planificación donde existe esta situación.
El patrocinador debería considerar cuidadosamente si los desafíos al status quo
serán personalmente aceptables. PQM descansa en la partición y el debate vigoroso
que puede no ser consistente con el estilo del patrocinador, la cultura corporativa o
las características nacionales.
 Definir Mision Declara la razón fundamental de la existencia.

Identificar Necesidades claves necesarias y suficientes para cumplir la

Factores Críticos misión.
de éxito

Establecer los
FIGURA 1

Actividades empresariales que más necesitan atención y

procesos más recursos de gestión
críticos

Acordar / definir los proyectos para mejorar los MCP

Revisar las
implicaciones de
gestión
Basado en los MCP:
(*) Implementar proyectos de mejora para la cartera
existente de aplicaciones y servicios de IT.
Revisar IT (*) Identificar nuevas áreas para aplicaciones y servicios IR
de alto rendimiento.

2.5.2 El facilitador

Se requiere que un facilitador ayude al patrocinador y a su equipo a usar PQM. En el

caso de equipos de gestión de más de seis, se recomienda que estén presentes dos
Facilitadores. El papel del Facilitador abarca la configuración de las sesiones de
planificación con el patrocinador, la ejecución de la metodología durante la reunión
de planificación y la garantía de que se realice el seguimiento.
Si bien los Facilitadores son normalmente externos a la Empresa, el personal interno
capacitado (con frecuencia extraído de los grupos de capacitación y desarrollo) ha
llevado a cabo con éxito sesiones internas. La experiencia muestra que los
Facilitadores internos no deben truncar la Metodología PQM para el (los) equipo (s)
al que informan

2.5.3 El equipo
PQM es frecuentemente utilizado por el "equipo superior" (la junta directiva, el
ejecutivo, el Comité de Gestión, etc.) para establecer sus necesidades comerciales
vitales y evaluar las implicaciones para IT. Dentro de las grandes empresas, el
"equipo superior" puede ser el responsable de dirigiendo y gestionando toda la
organización o el responsable de una unidad operativa principal.
Otros equipos pueden beneficiarse del uso de PQM; por ejemplo, equipos
responsables de la implementación de grandes proyectos, formulación de políticas y
gestión de procesos comerciales.
Si bien el enfoque óptimo es utilizar la metodología con el "equipo superior" y luego
utilizar su uso en cascada dentro de la organización, los principales beneficios
pueden, y lo hacen, acumularse para los equipos individuales que usan PQM para
enfocarse en sus requisitos y prioridades fundamentales.
La experiencia ha demostrado que la metodología puede utilizarse en un amplio
espectro de industrias y ayuda a los equipos de gestión cuyas competencias cubren
una amplia variedad de tareas. Los detalles sobre el alcance y el uso de la
Metodología PQM se proporcionan en las Notas 1 a 4.

2.6 Seguimiento

En la conclusión de una sesión de planificación de PQM, el líder del equipo pregunta

con frecuencia: "¿cómo cree que lo hemos hecho?", La respuesta siempre está
calificada por el hecho de que el juicio real sobre cómo el equipo ha "hecho" solo
puede comenzar. Se evaluará dentro de unos seis meses. Entonces, aunque la
sesión de planificación puede haber sido exitosa, la realidad de la situación se
parece más a la "larga marcha" de los comunistas en China cuando Mao Tse Tung
observó más tarde que "el viaje más largo comienza con un solo paso".
La aplicación rigurosa de PQM permite a los equipos de negocios identificar sus
problemas más críticos y las formas en que IR puede contribuir a su solución. El
seguimiento apropiado es esencial. En los mejores ejemplos, un "cambio radical"
bien pudo haber tenido lugar. El equipo de gestión ha decidido asumir tanto su
negocio como las prioridades de IT y las áreas de enfoque asociadas. El equipo ha
determinado colectivamente sus aplicaciones más rentables y se asegurará de que
se implementen. Tienen una voluntad colectiva de entregar el 'plan de ganancias'.
La sección 3 contiene una descripción detallada de la forma en que se aplica la
metodología "clásica" de PQM, junto con sugerencias, consejos y ejemplos para
maximizar el beneficio de su uso para los equipos de gestión y sus facilitadores. La
Sección 4 continúa para ilustrar formas alternativas en que se puede implementar
PQM.

3 planificación para una inversión de IT beneficiosa

Esta sección describe el uso clásico de la Metodología PQM que permite a un

equipo de gestión:

(a) Determine sus prioridades comerciales

(b) Establezca la aplicación y los servicios basados en IT necesarios para respaldar
las prioridades comerciales
(c) Planificar la implementación de los proyectos de mejora requeridos
Las razones por las que los equipos de gestión desean lograr estos objetivos son
muchas y variadas. La naturaleza del negocio puede cambiar a medida que se
realizan adquisiciones o se lanzan nuevos productos importantes. Se puede volver a
enviar a una subsidiaria para que abarque nuevas responsabilidades. Los cambios
importantes en el mercado pueden presentar nuevas oportunidades o amenazas.
Se puede establecer una empresa conjunta y se requiere "actuar juntos". Un nuevo
líder puede desear formar su equipo y comunicar sus esperanzas, deseos y
aspiraciones.
En muchas sesiones de planificación, PQM se utiliza con la intención principal de
establecer las prioridades para el uso de IT. En otras circunstancias, PQM se usa
cuando hay una sensación general de inquietud en relación con, por ejemplo, el
progreso, o la falta de éste, con un proyecto importante. Cualquiera que sea la
razón para usar la metodología, el resultado final será el compromiso del equipo y
el consenso sobre dónde deben implementarse los recursos para cumplir con las
prioridades comerciales, para los estudios que abarcan los requisitos de IT, la
atención se centrará en mejorar la cartera o aplicaciones, servicios y servicios
existentes. y desarrollar e implementar nuevos para apoyar los planes de negocios.

La Figura 2 muestra los pasos detallados que son la base del uso "clásico" de PQM
que primero define las criticidades del negocio del equipo y luego utiliza esta
información como el básico para el desarrollo de la Estrategia de IT. Esta sección
contiene detalles de los ítems principales que se abordarán en cada paso. El número
que se le da a cada uno de los pasos en la Figura 2 corresponde a su número de
subsección en esta sección.

3.1 Llevar a cabo la reunión informativa

Regla 1: No se embarque en una sesión de planificación de PQM sin que el
Facilitador complete una sesión informativa adecuada con el Patrocinador.

3.1.1 Preámbulo
Antes de embarcarse en el trabajo de configuración deshabilitado para la sesión de
planificación, es vital que el Facilitador informe al Patrocinador sobre los objetivos y
objetivos de PQM. El patrocinador puede entonces decidir si es un mecanismo
apropiado para enfocarse en los problemas percibidos del equipo. Si lo es, entonces
el trabajo de preparación para la sesión de planificación debería continuar.
 3.1.2 Configuración de la reunión

Normalmente se requieren 2 horas para la reunión informativa. La principal tarea

que deben emprender el patrocinador y el facilitador son:

Informe de conducta Tiempo Aproximado

3.1

2 Horas

3.2 Elegir el Equipo

3.3 Definir la Mision 3 Horas

FIGURA 2

3.4 Listar influencias Dominantes 1/2 Hora

Identificar Factores 2 Horas y

3.5 media
Críticos de Éxito (CSFs)

3.6 3.7

Definir proceso de negocio Relacionar CSFs con procesos de negocios

2 Horas 2 Horas

3.8 Establecer el proceso más crítico (MCPs)

2 Horas

3.9 3.10

Revisar las implicaciones de gestión Revisar las Implicaciones de IT

1 hora y media

Figura 2: La metodología PQM. NOTA: Los pasos 3.3 a 3.6 están completos en el
 primer día de la reunión. Los pasos 3.7 a 3.9 están completos en el segundo día de
la reunión. El paso 3.10 se aborda después de la reunión, ya que se requiere
información del grupo de IT para su finalización.

(a) Elabore la Declaración de la misión que el Patrocinador "posee" (a menos que ya

exista una Declaración de Misión).
(b) Producir un conjunto de procesos de negocios que sea apropiado para el
borrador de la Misión.
(c) Reserve un lugar fuera del sitio para la reunión. Esta ubicación puede estar en un
sitio geográficamente remoto dentro de la Empresa.
(d) Preparar y emitir una nota informativa para todos los participantes (ver
apéndice 1)

3.1.3 Análisis previo

La experiencia muestra que es esencial hacer lo siguiente en la etapa de

información:
(a) Desarrollar un esquema de los principales grupos con los que el patrocinador y
su equipo se relacionan o interactúan, tanto dentro como fuera de la empresa, es
decir, las "relaciones clave".
(b) Decida si es apropiado informar a todos los directores que asistirán a la reunión.
(c) Evalúe cualquier trabajo de planificación previo que haya sido llevado a cabo por
el equipo con consultores, planificadores, etc., que podría proporcionar información
útil para el PQM. Donde sea relevante, esta materia debe ser incorporada en la
documentación de la sesión de planificación para una posible duplicación de trabajo
y confusión potencial.
(d) Asegúrese de que el patrocinador sepa que la sesión de planificación es solo el
primer paso. El trabajo realmente duro radica en los meses (a veces años) que se
avecinan cuando los proyectos de mejora se identifican, desarrollan e implementan.

3.2 Elegir el equipo

Regla 2: Todos los gerentes relevantes deben estar presentes en la sesión de
planificación. No lo ejecute si falta un jugador clave en el equipo.

La experiencia sugiere fuertemente que todos los miembros del equipo directivo
inmediato del Patrocinador deben participar: nadie falta. sin pasajeros La mayoría
de los equipos de administración tienen aproximadamente diez personas y ese
número es 'controlable' en una sesión de planificación estándar. A medida que
aumenta el número de participantes, también aumentan los problemas de
 mantener el "control". La sesión más grande de PQM hasta la fecha ha sido con
diecinueve personas.
Si ni siquiera un miembro del equipo puede asistir, posponga el estudio hasta que
todos puedan asistir. PQM requiere un "buy-in"(¿compra interna?) por parte de
todos, no solo para crear el producto acordado sino también para lograr el
compromiso del equipo con él. Con demasiada frecuencia, si falta un jugador clave,
hay disrupción y confusión durante las sesiones de seguimiento. Evita esta situación
a toda costa.
Igualmente, excluya a todos los autostopistas. Este es un trabajo duro y
concentrado para el equipo de administración en sí. Deje a los ayudantes y
asistentes personales, etc. para cuidar la tienda.
Todos en el 'equipo' deben tener un interés directo en progresar en la Misión. Esto
ha llevado. En varias ocasiones, a los gerentes de las "funciones de servicio" (por
ejemplo, TI o Personal) que participan en la sesión de planificación.
El tipo y la naturaleza de los equipos que participaron en las sesiones de
planificación de PQM se analizan en las Notas 2 y 3.

3.3 Definir la Misión

Regla 3: La misión debe ser definida y acordada por el equipo antes de pasar a la
siguiente etapa del estudio; de lo contrario, todo lo que sigue será un esfuerzo
desperdiciado.

3.3.1 ¿Que es una misión?

El idioma inglés es rico en palabras como misión, metas, objetivos. objetivos. etc., y
su uso y significado están lejos de ser estandarizados. La palabra "Misión" se usa en
PQM de manera muy sencilla para indicar la razón por la cual existe un equipo de
gestión particular; para lo que colectivamente se les paga por hacer.
La Declaración de la Misión es la visión y guía para el equipo. y todos aquellos
manejados / influenciados por ellos. En consecuencia, la Misión suele comunicarse
a todos los grupos internos pertinentes y, en su caso, a los clientes. proveedores y
socios comerciales (y ver Dernb en 1989).

3.3.2 Definiendo la misión.

La Declaración de la Misión no requerirá más trabajos de definición si ya existe uno
apropiado para la empresa. o si, en el caso de grandes empresas nacionales /
internacionales / multinacionales, existen declaraciones de misión estándar para los
territorios. unidades de negocios, etc.
La definición de la Misión comienza con la presentación por parte del Patrocinador
para el debate del proyecto de Declaración de la Misión distribuido con la nota
informativa. Luego, el equipo debe analizar esto y, a través del debate, desarrollar una
Declaración de misión con la que todos estén de acuerdo.
Deben observarse los siguientes principios al desarrollar la Declaración de la Misión.
a) Debe ser breve, no más de 3 o 4 breves. declaraciones escuetas.
b) Debe ser capaz de una interpretación consistente.
c) Debe ser claro, visible y no ambiguo
d) Debe contener los siguientes elementos:

• Hacer algo
• Para…
• Tal que… se logran los fines. (aunque la secuencia es variable)
También puede haber elementos fundamentales que se encuentran detrás de todas
las declaraciones de misión de una empresa. Estos se detallan por separado como
'valores fundamentales' o 'creencias básicas'. Estos forman el trasfondo sobre el cual
se realizan todas las funciones de la Misión e incluyen elementos tales como:
a)"La calidad y la seguridad son principios dominantes en todo lo que hacemos"
b) ‘Las personas son nuestro activo más importante’.
c) ‘Servicio al cliente’.

d) ‘Respeto por el individuo’.

En algunos casos, los equipos también desarrollan un breve "Glosario de términos".
para aclarar aún más el significado más profundo de unas pocas palabras clave en la
Declaración de la Misión (y ver David, 1989).

3.3.3 ¿A quién pertenece la Misión?

PQM considera que la Misión pertenece efectivamente a una persona, el "gerente de
clasificación" o supremo del equipo que participa en el estudio. Puede ser el CEO de
una compañía multinacional, un vicepresidente de división, un gerente de planta, un
gerente de proyecto, un gerente de una sucursal de ventas, etc. Pero el dinero se
detiene en el escritorio de esa persona. Él o ella es dueño de la Misión. El equipo está
creado para lograrlo.

3.3.4 ¿Se entiende la misión?

Es increíble cuántos equipos de administración realmente no saben cuál es su misión.
A veces esto se debe a una rápida rotación de los miembros del equipo. A veces se
debe a que el entorno ha cambiado lo suficiente como para hacer que la antigua
Misión sea irrelevante y, a veces, se debe a que nunca se ha preparado una
Declaración de la Misión.
Las compañías internacionales / multinacionales pueden presentar problemas
particulares. Aquí la declaración de la misión debe ser en inglés muy explícito o ser
capaz de una traducción "ajustada" a otros idiomas si se va a promulgar a nivel
mundial.

3.3.5 Ejemplos de declaraciones de misión.

a) Una empresa internacional: la Junta "Cumpla con los requisitos de rendimiento de
los clientes en todo el mundo como proveedor de materiales y sistemas seleccionados
en función de las aplicaciones específicas de la ciencia de los materiales".
b) director de planta de fabricación y gerentes de informes
‘Para el suministro de productos y servicios que sean competitivos en términos de
función, costo, calidad y entrega y garantizar la satisfacción del cliente.'
c) Función personal - director y gerentes de informes
"Apoyar a la administración de la organización en sus responsabilidades que involucran
a las personas y, cuando se le asigna, a la comunidad al proporcionar un entorno que
permite a nuestra empresa en el Reino Unido atraer, motivar, educar, desarrollar y
retener a las personas para:
• Cumplir objetivos de negocios.
• Cumplir con nuestras creencias básicas.
Se puede obtener información adicional sobre el uso de la Metodología PQM
consultando el Apéndice 2, ‘Ejecutando un estudio de planificación de PQM’.

3.4 Enumerar las influencias dominantes.

Regla 4: Asegúrese de que cada miembro del equipo haga su contribución o Influencias
dominantes para que los problemas reales que impactan a los Desaparecidos sean
presentados.
El acuerdo de la Misión significa que el equipo ahora sabe por qué 'existen' y ahora
deben considerar las Influencias dominantes en la Misión. El propósito aquí es
enumerar todo y cualquier cosa que el equipo crea que podría afectar el logro de la
Misión. Estos incluirán aquellos elementos que pueden afectar adversamente la
capacidad del equipo para lograr su Misión y aquellos elementos de fuerza que pueden
ser explotados aún más. Este es el momento para comentarios completos y francos, y
el establecimiento de la 'política de la realidad' dentro de las operaciones de los
equipos. 'Lluvia de ideas' se usa para desarrollar las Influencias dominantes (ver
Apéndice 2).
Al desarrollar las Influencias Dominantes, el equipo se referirá a la Misión, el diagrama
de "Relaciones Clave" (si fue desarrollado en la sesión de información -ver Sección 3.1)
y un diagrama de "Relaciones de Misión", como se muestra en la Figura 3. El equipo
debería considerar el entorno futuro en el que se realizará la Misión, así como registrar
las "lecciones de la historia" pasadas. Una lista típica de Influencias dominantes
contendrá de treinta a sesenta elementos.

Los ejemplos de influencias dominantes son:

➢ Rentabilidad del cliente

➢ Legislación

➢ Demanda futura

➢ Cuestiones ambientales

➢ Reducción de costos

➢ Comunicación dentro de la compañía

➢ Estilo de gestión

➢ Servicio al cliente

➢ Tiempo

➢ Cultura presente

➢ Barreras comerciales

➢ Capacidad de producción

➢ Comunidad Económica Europea- 1992

➢ Confianza del empleado

➢ Equipos de negocios

➢ Costos de distribución

➢ Información de gestión

➢ Formación

➢ Competidores
La identificación de las influencias dominantes es un paso esencial antes de identificar
Factores Críticos de Éxito. Si bien muchas de las influencias dominantes eventualmente
contribuirán a la formulación de CSFs, no todas los harán, ya que algunas serán
típicamente preocupaciones de fondo y no críticas.

3.5 Identificar factores críticos del éxito(CSFs).

Regla 5: Un número limitado de CSFs debe ser acordado en el equipo siendo
individualmente necesario, y a su vez suficiente, listando los elementos necesarios que
deben ser archivados si la misión está cumplida.

3.5.1 ¿Cuáles son los CSFs?

Los factores críticos del éxito son, para algunos business, el número limitado de áreas
en el cual los resultados, si son éxitos, asegurara un funcionamiento competitivo exitoso
para la organización. Ellos están en algunas áreas claves donde “Las cosas deben ir bien”
para que los negocios prosperen. Si los resultados en estas áreas no son adecuados, los
esfuerzos de la organización no serán los deseados.
Las influencias dominantes, escuchadas durante la sesión “brainstorming” (Tormentas
de ideas), y otros ítems notados durante los debates de equipo, Son una rica fuente de
materiales para acordar los CSFs. Muchas veces ellos son agrupados en un numero de
“Clusters” desde el cual son desarrollados.

3.5.2 ¿Cuantos CSFs puede administrar un equipo?

Las experiencias de muchos estudios han establecido que el número ideal de CSFs es 5
o 6 y que no deberían ser más que 8. Estos números estas basados en el número de
tareas de gestión que un equipo puede enfocarse en paralelo. Frecuentemente en una
situación de crisis tendrán un máximo de solamente 4 CSFs.

3.5.3 La naturaleza esencial del CSFs.

La descripción de cada CSFs debería ser dedicado a un solo problema. En Este medio la
palabra “AND” está realmente prohibido si se abordan 2 temas totalmente distintos. Los
equipos con frecuencia están tentados a combinar CSFs como una manera de bajar el
número total. Esto debería evitarse.
Normalmente habrá una mezcla de CSFs tácticos y estratégicos. Si ellos son todos
estratégicos. Los negocios podrían fundirse a corto plazo mientras todos están
concentrados “en el cielo azul de sus cabezas”. Igualmente, si todos los CSFs son tácticos,
Los negocios podrían consumirse como una supernova. La relación de Táctica a
estratégica depende del número de factores incluyendo la naturaleza del equipo usando
PQM. El predominio de los CSFs tácticos desde el equipo de gestión de las oficinas de
ventas regionales seria esperado. Mientras la sede del corporativo normalmente tendrá
casi totalmente listas estratégicas.
Los CSFs tiene que ser acordados para el equipo entero. Cordialmente es apropiado que
ellos empiezan con palabras como “Nosotros deberíamos” “Nosotros necesitamos”.

3.5.4 Ejemplos de CSFs.

Algunos ejemplos generales de CSFs son extraídos de una variedad de sesiones de
planificación y se presentan a continuación:
(a) Nosotros debemos tener una asociación efectiva con todos nuestros clientes claves.
(b) Nosotros necesitamos incrementar nuestra visión externa.
(c) Nosotros deberíamos entender lo básico de como juzgan nuestros clientes nuestro
rendimiento.
(d) Nosotros debemos asegurar el implante exitoso del proyecto "cambio de cultura" en
una importante subsidiaria europea para fines de 1988. (e) Nosotros debemos asegurar
un suministro adecuado de piezas que cumplan con nuestros estrictos Estándares de
calidad.

3.5.5 La regla Necesario y suficiente.

Cada CSF en discusión debería someterse constantemente a pruebas de "necesidad" y
"suficiencia" en contra de la misión. Si el equipo esta de acuerdo, “si tenemos eso, eso,
eso, eso y eso bien, nosotros lo hacemos”. La lista de CSF esta “Completa”. Una prueba
útil de integridad es comprobar si el equipo está de acuerdo en que, si sus CSF no se
gestionan hacia adelante, seguramente fracasarán con su misión. También es
conveniente probar la redacción de los CSFs contra la Misión. Si la misión de un equipo
incluye "convertirse en el proveedor mundial de elección", tiene poco valor registrar
como CSF, "debemos convertirnos en el proveedor mundial de elección". Lo que
debemos saber es si hay alguna dificultad para convertirse en "el proveedor mundial de
cambio". En otras palabras, los miembros del equipo no deben "rebobinar" la Misión
como una serie de CSFs.

3.5.6 CSFs Chequeo final

Una vez que se ha alcanzado el "consenso" sobre los CSFs, la experiencia muestra que
se debe recordar al equipo de gestión que
a) Todos los CSF son 'iguales'. Pueden ser completados en diferentes escalas de
tiempo, pero a menos que todos sean tratados, si no la Misión fracasará.
b) Los CSF son los que el equipo ha desarrollado para la misión, en el entorno actual.
Un cambio importante en el alcance de la Misión o en el entorno en el que se
está llevando a cabo debería desencadenar una revisión de los CSFs.
c) Los CSF deben ser revisados por el equipo, al menos cada año. En esta etapa, el
equipo sabe lo que tienen que hacer (la Misión) y acordaron los elementos
necesarios y suficientes que deben lograrse para lograrlo (los Factores Críticos
de Éxito). Sin embargo, los CSF, tal como se definen habitualmente, no son
directamente manejables y, por lo tanto, el análisis debe avanzar hacia los
Procesos Comerciales que proporcionan el marco para la gestión.

3.6 Definir Proceso de Negocio.

Regla 6: Cada proceso de negocio debería tener un dueño, y los dueños deberían ser un
miembro del equipo de gestión que está en acuerdo con CSFs.

3.6.1 ¿Qué son los procesos de negocios?

Los procesos de negocio se pueden ver como actividades de una serie vinculada, que
trasciende los límites de la organización funcional, que son necesarios para que la
empresa funcione de manera eficiente. Los ejemplos pueden ser aquellas actividades
requeridas para llevar un producto al mercado, administrar el inventario de demanda y
suministro o administrar la facturación y las cuentas por cobrar. Existe una clara
diferencia entre los Procesos de Negocios y los CSF. Los Procesos de negocios están
relacionados con las actividades y los flujos de información, mientras que los CSF son
áreas clave para el enfoque de gestión. Inicialmente, los equipos generalmente definen
los procesos de una manera bastante insulsa y poco exigente. “Facturación “, por
ejemplo, o “Mantenimiento “, o “Ventas”, o “Servicio al cliente” Estas no son
descripciones útiles y PQM recomienda un enfoque riguroso a la definición de Procesos
de negocio que especifica que:
a) La estructura del lenguaje de cada descripción de procesos de Negocio debe
seguir una secuencia verbo más sustantivo.
b) Cada proceso de negocio debe tener un propietario, un propietario, la persona
responsable de llevar a cabo el proceso.
c) El propietario debe ser un miembro del equipo administrativo que acordó la
CSFs.
d) los NO Propietarios (no Dueños) deberían tener no más de 3 o 4 procesos de
negocios para administrar.
Por ejemplo, "Introducir nuevas ofertas" describe un proceso. Tiene el verbo de acción
"Introducir" para que algo se deba hacer, y tiene la porción de sustantivo: Nuevas
ofertas. Puede tener un propietario y se puede medir su calidad o rendimiento. También
es multifuncional, fundamental para el negocio, y cada colega en el equipo de gestión
debería estar profundamente preocupado por su éxito.

3.6.2 Proceso de Descripción

Es vital comprender que verbos como 'control', 'reducir' optimizar ', no describen
Procesos de Negocio. Más bien, describen los resultados deseados de la Gestión de
Procesos. Por ejemplo, “Optimize Stocks 'describe un deseo en lugar de un Proceso y el
equipo debe buscar los principales procesos mediante los cuales logran "Optimizar
Stocks”, por ejemplo, establecer y revisar niveles de existencias, establecer políticas
para acciones obsoletas. La prueba consiste en preguntar qué miembro del equipo
desea ser el propietario del Proceso en discusión. Con procesos como "Reducir
personal", "Optimizar costos de administración", "Mejorar la moral", suelen existir
pocos voluntarios serios. En la misma línea, PQM recomienda no utilizar adjetivos o
adverbios en las descripciones de los procesos. Terminología como:
Hacer encuestas integrales de satisfacción del cliente
Definir requisitos de habilidades EFECTIVAMENTE
Negociar ALTO NIVELES DE SERVICIO
Ingresar PRECISAMENTE órdenes del cliente
Educar a los vendedores EFICACES
están describiendo los resultados deseados y son CSF en lugar de procesos.

3.6.3 Propiedad
El equipo se enfoca en los procesos comerciales requeridos para cumplir su misión.
Algunos de estos serán propiedad y administrados por el equipo directamente; otros
serán propiedad de otros equipos. Si un equipo confía en un Proceso de Negocio poseído
en otra parte, típicamente instituirá un proceso de control o negociación descrito por
tales acciones como 'negociar escalar', etc., y asignar la propiedad de estos dentro del
equipo.

3.6.4 Desarrollando procesos de negocios

Se pueden usar varias técnicas para derivar la lista de procesos principales. Cuando el
Informe (Sección 3.1) ha sido exhaustivo, se puede presentar y discutir una lista sugerida
de Procesos de negocios, circulada por el Patrocinador en la nota informativa.
Cuando esto no se ha hecho, el Facilitador proporciona cuatro o cinco ejemplos de
procesos para que el grupo los utilice como punto de partida. El Apéndice 3 proporciona
ejemplos de Procesos de IT y el Apéndice 4 ilustra un conjunto general de Procesos de
negocio. El equipo debe tener copias de la Declaración de la misión, las Influencias
dominantes y los CSF disponibles como referencia en todo momento. Todos estos
pueden ayudar a resumir el acuerdo sobre los Procesos de negocios. En algunos casos,
la empresa ya implementó las técnicas de Business Process Management. En estos
casos, existe un Directorio de Procesos de Negocio para toda la empresa, y aquellos
procesos de los cuales el propio equipo puede extraerse. En estas circunstancias, los
procesos aplicables al Patrocinador y su equipo se distribuirán como parte de la Nota
informativa (Sección 3.1). Si bien una revisión de la Misión / CSF / Influencias
Dominantes puede crear algunos procesos adicionales, o procesos de Sul, que serán
administrados por el equipo, la mayor parte del trabajo está hecho. La experiencia
demuestra que un equipo normalmente tiene entre 30 y 40 procesos de negocios
exclusivos que posee ". Es importante confirmar que la propiedad de todos los Procesos
ha sido asignada al equipo. Una vez definidos los Procesos Comerciales que posee el
equipo, ahora es importante comenzar a enfocarse en los procesos clave. Esto comienza
relacionando los CSF con los Procesos de negocios.

3.7 Relacionar los CSF con los procesos de Negocios.

Regla 7: tome cada CSF por turno y considere qué Procesos de Negocio se requieren
para administrarlo, agregando nuevos si es necesario.

3.7.1 Relacionar los CSF con los procesos

Para cumplir con la Misión, la "gestión" de los CSF es vital, pero, como se ha discutido
en la Sección 3.5, los CSF no son, en sí mismos, directamente manejables. Son los
Procesos de Negocio los que definen lo que un equipo de gestión 'HACE'. Son los
Procesos de Negocio los que pueden ser apropiados, definidos, medidos y
administrados.
Por lo tanto, es necesario "relacionar" los CSF con los Procesos de Negocio para
proporcionar una visión general de la importancia de cada uno de ellos para la gestión
de los CSF. Este Paso se realiza mejor mediante la construcción de una matriz de CSF
frente a Procesos de Negocio.

3.7.2 Construyendo la Matriz

PQM depende en gran medida en esta etapa de la sabiduría, la experiencia, el
conocimiento y las opiniones del equipo de gestión.
El equipo crea la matriz relacionando los CSF con los Procesos de Negocio agrupando la
matriz en dos secciones:
(a) Una sección 'Detalle', que relaciona los CSF individuales con los Procesos de Negocio.
(b) Una sección de 'Análisis', que indica la 'importancia' relativa al desempeño de CSF de
cada
Proceso de Negocio, y forma la base para el establecimiento de los Procesos Más
Críticos.
Los pasos detallados que el equipo se compromete a construir la matriz son los
siguientes.

3.7.3 Completando la sección 'Detalle' de la matriz

El primer paso es insertar los Procesos de Negocio y los CSF en la matriz (ver Figura 4).
El equipo de gestión se centra a su vez en cada CSF y considera la siguiente pregunta:
«¿Qué procesos de Negocio deben realizarse especialmente bien para que tengamos
confianza en lograr este CSF?». Muchos procesos influirán en el logro de un CSF, pero el
equipo juzga cuáles son los verdaderamente críticos.
Después del primer pase, se aplica una "prueba de suficiencia". Si los Procesos
identificados se realizan bien, ¿son suficientes para gestionar el CSF en cuestión? Si la
respuesta es 'no', es necesario definir procesos adicionales. Aquí es donde el equipo
comienza a ser realmente creativo, abriendo nuevos caminos, acordando lo que se debe
hacer además de lo que ya se está haciendo. Además, cada nuevo Proceso de negocio
agregado para la suficiencia debe tener un propietario asignado de entre el equipo de
administración.
Este análisis se repite para todos los CSF, cada uno de los cuales tendrá un conjunto
diferente de Procesos vitales. De nuevo, la prueba de "suficiencia" debe aplicarse
rigurosamente. La figura 5 muestra una matriz en la que todos los CSF se han relacionado
con procesos empresariales. Tenga en cuenta que los Procesos número 20 a 24 se han
agregado en nuestro ejemplo como resultado de la prueba de "suficiencia".

3.7.4 Completando la sección 'Análisis' de la matriz

La matriz ahora contiene muchos "datos brutos" valiosos. Para que esto sea realmente
útil, se debe llevar a cabo un análisis de las prioridades, y esto se hace usando tres
indicadores.
(a) El conteo. Los procesos de negocio más importantes son potencialmente los que
afectan a la mayoría de los CSF y se proporciona un recuento simple en la
columna (A) en la sección Análisis de la matriz.
(b) Asignación de una calificación de "calidad" Se proporciona una calificación de
"calidad" para cada proceso en la columna (B) de la sección de análisis. Esta
calificación es normalmente objeto de considerable debate entre el equipo. La
clasificación "básica" que PQM utiliza para evaluar la calidad actual de los
procesos comerciales es:
A = No necesita mejora
B = Funciona bien, espacio para mejoras menores
C = Funciones, varias áreas para mejorar
D = Proceso en el lugar pero no funciona
E = Embrionario

(c) Identificar los 'Big Burners' Además de 'Conteo' y 'Calidad ', varios equipos también
identifican los 'Big Burners', aquellos Procesos de Negocio que consumen una
proporción significativa del dinero, personas o activos para los cuales el equipo es
responsable. Los procesos a los que se aplica esta prueba están designados con un
asterisco en la columna (C). Un debate bien puede tener lugar en esta etapa si un
proceso de 'Big Burner' parece tener un impacto mínimo en cualquiera de los CSF.
La Matriz que relaciona los Procesos de Negocio con los CSF ahora está completa (ver
Figura 5). La materia prima está en su lugar y, potencialmente, la importancia relativa
de cada uno de los procesos comerciales se detalla en la sección 'Análisis'. El equipo
ahora puede avanzar para establecer sus procesos más críticos.

3.8 Establecer los procesos más críticos (MCP)

Regla 8: Aquellos Procesos de negocio designados como los "Procesos Más Críticos"
(MCP) para la mejora deben ser muy limitados en número. El equipo no debe crear una
situación de 'misión imposible' para sí mismo tratando de administrar demasiados MCP.
Los procesos más críticos son los procesos cuyo desempeño debe mejorarse si los CSF
se deben gestionar con éxito. Si no se mejoran los MCP, significará que no se
administrarán los CSF con los que están asociados y que, consecuentemente, el equipo
fallará con su misión. La Identificación de MCPs Seguirán los siguientes pasos.

3.8.1 Asignación de Prioridades

Se usa una 'Cuadrícula de resumen' (ver Figura 6) para mapear el 'Conteo de CSF' contra
'Calidad' para cada Proceso de negocio. Por lo tanto, el Proceso 1 (P1) que afecta a tres
CSF y tiene una calificación de Calidad 'C' se inserta en la casilla 3C (ver Figura 6). Cada
uno de los procesos se transfiere a su casilla correspondiente en la cuadrícula de
resumen.
El equipo puede usar este resumen para establecer sus procesos más críticos. Esto se
logra acordando 'zonas' en la Rejilla Resumen. La Figura 6 ilustra esto donde el equipo
de gestión ha decidido que la Zona 1 contiene los Procesos Más Críticos. Por supuesto,
todos los otros procesos son importantes, pero..
los procesos de mayor riesgo / mayor oportunidad son los de la Zona 1. Las zonas
sombreadas en la Figura 6 representan, por lo tanto, una Vista de la secuencia para la
mejora del rendimiento del Proceso de Negocio (Zona 3 = menos urgente). Esta es una
decisión del equipo de administración. Deben decidir dónde deberían estar los límites
de la zona en la cuadrícula. 'Zonificación'. de los Procesos Comerciales para establecer
la "criticidad" es la técnica más comúnmente utilizada por los equipos de gestión. Sin
embargo, algunos equipos prefieren asignar una ponderación numérica al rendimiento
de calidad del proceso; por ejemplo A = I, E = 5, etc. A los procesos se les puede asignar
un número de 'criticidad' igual al número de impactos (conteo) por ponderación de
calidad y ordenados numéricamente para ayudar a refinar los Procesos más críticos.

3.8.2 La influencia de los "Big Burners"

Si bien todos los CSF tienen la misma importancia, los procesos varían en su alcance y la
cantidad de recursos del equipo que se dedica a cada uno de ellos. La regla general es
que bajo ninguna circunstancia se debe permitir el deslizamiento de la calificación de
calidad de un proceso de "Big Burner"; y cuando tiene una calificación de calidad actual
de 'D' o 'C', se requiere atención inmediata en forma de proyectos de mejora. Los 'Big
Burners' se identifican haciendo un círculo en los números del Proceso en la Cuadrícula
de Resumen a la que se aplican (ver Figura 6).

3.8.3 El juicio final

Para enfocar claramente sus actividades, la mayoría de los equipos deciden restringir su
atención a los Procesos en la Zona 1. Ahora pueden avanzar para revisar las
implicaciones de las mejoras deseadas para los MCP en sus actividades de
administración general y para revisar las implicaciones para su uso de aplicaciones y
servicios basados en TI.

3.9 revisar las implicaciones de gestión

Regla 9: el equipo debería usar los sistemas de gestión de “negocios habituales” para
definir e implementar proyectos de mejora de la calidad de los procesos.

3.9.1 Compromiso de procesar la mejora de calidad

Es vital que el equipo demuestre su compromiso tangible con la mejora de la calidad del
proceso después de la sesión de planificación al implementar rápidamente un
importante proyecto de mejora apropiado, al menos, para los MCPs.
Siempre que los CSF de un equipo sigan siendo válidos, los procesos de negocios solo se
pueden mover horizontalmente (mirar figura 6). Si se dejan solos, la tendencia es
moverse hacia la izquierda (disminución de la calidad), mientras que la gerencia desea
un movimiento hacia la derecha (mejora de la calidad). Esto normalmente solo se
logrará a través del trabajo duro y la atención concentrada de la gerencia, es decir, a
través de una gestión de calidad de procesos efectiva. El uso de PQM requiere que el
equipo de gestión despliegue sus recursos para lograr mantener las mejoras deseadas y
lo hace mediante el uso de proyectos de mejora de la calidad.
3.9.2 definir e implementar los proyectos de mejora de la calidad (QIPs)
Inicialmente los propietarios de MCP y, posteriormente, todos los procesos deben:
a) Proporcionar una definición formal del proceso y los subprocesos asociados
(asignar la propiedad de los subprocesos)
b) Realizar un análisis de fortalezas y debilidades para aclarar la calificación de
calidad actual.
c) Definir y obtener la concurrencia para los Proyectos de Mejora de Calidad
apropiados, relacionándolos, si corresponde, con los QIPs establecidos
d) Definir la gestión de proyectos apropiada para cada QIP

3.9.3 Fin del juego

El progreso que esta realizando el equipo en la implementación de los Proyectos de
Mejora de la Calidad debe ser revisado como parte de los sistemas de gestión habituales.
El Sponsor tiene un papel importante que desempeñar asegurando que se mantenga el
impulso en los proyectos. Las principales revisiones de proyectos a las que asiste el
Facilitador normalmente tienen lugar 3 veces al año. Una de estas reuniones de revisión
debe realizarse lo más cerca posible del comienzo del ciclo de planificación de la
empresa. esta reunión se usará para determinar si la Misión ha cambiado, y si este
cambio se combina con cambios significativos en el ambiente (nueva competencia,
cambios en la legislación regulatoria, impactos del ciclo económico, etc.), Necesitan
enmiendas a los CSF, los MCP y el conjunto existente de Proyectos de Mejora de la
Calidad.
el equipo siempre debe concentrarse en administrar los QIP para obtener calificaciones
"A" para cada uno de sus procesos de negocio y llevar los QIP en "a tiempo y dentro del
presupuesto".

3.10 Revisión de las aplicaciones de IT

Regla 10: garantizar la consideración completa para mejorar la cartera (o portafolio o
carpeta, no se la traducción adecuada) actual de aplicaciones y servicios basados en IT
(así como a los nuevos desarrollos). Estos pueden ser la clave para mejoras importantes
en los MCPs

3.10.1 agregar valor al proceso empresarial/matriz CSF

el equipo ahora capitaliza el trabajo que ha hecho para relacionar los Procesos de
Negocio con los CSF. (mirar figura 5). El CSF/Matriz de proceso se puede usar para
realizar una auditoría del soporte de IT existente para cada uno de los Procesos del
negocio. Esta información se puede usar para detallar esas áreas para posibles
inversiones estratégicas futuras en aplicaciones y servicios basados en TI.
la figura 7 ilustra cómo un equipo agrega valor a la información contenida en la figura 5.
se agregan dos columnas adicionales bajo el título "IT": la primera para "Calidad
empresarial" y la segunda para "Calidad técnica". se le pide a cada propietario de
Procesos de negocio que califique el soporte actual de la aplicación / servicio basado en
TI para su Proceso en una escala de:
A = Excelente.

B = Bueno

C = Razonable (Justo)

D = Malo

E = Embrionario (seria la traducción, que es algo como en estado muy inicial)

y asignar esto a la columna de TI "Calidad empresarial".

La columna "Calidad técnica" la completa la administración de TI que califica la calidad técnica

de los sistemas que respaldan cada proceso empresarial, nuevamente en una escala de "A" a
"E". Se entiende por calidad técnica una combinación de: la antigüedad de los programas de
aplicación, el gasto de mantenimiento cada año, la facilidad de mejora, la tecnología de archivos
utilizada, el estándar de documentación, el lenguaje de programación utilizado, el software de
control empleado, etc.

Este es usualmente un análisis altamente revelador. la comunidad empresarial con frecuencia

se horroriza al descubrir que sus sistemas más importantes y altamente respetados solo se
mantienen a flote a un enorme costo (y riesgo).

Como ejemplo, un gran equipo de Gobierno Local en Inglaterra descubrió en este punto que sus
sistemas de soporte vital (nómina y recaudación de impuestos a la propiedad local) habían sido
escritos en lenguaje ensamblador doce años antes. la documentación se había desvanecido hace
mucho tiempo. la única habilidad restante para monitorear los programas recae en su gerente
DP de 62 años. fue conmovedor ver la atenta manera en que el Jefe Ejecutivo de repente
comenzó a cuidar el bienestar del hombre.

3.10.2 establecer las prioridades de inversión de IT

(a) la cartera actual (o carpeta o portafolio): la información "IT" contenida en la figura 7
puede resumirse para proporcionar una "Auditoría comercial / técnica del soporte de
aplicaciones de TI" (mirar figura 8) que mapea la calidad del negocio con la calidad
técnica. Este es un diagrama poderoso contra el cual el equipo puede determinar la
financiación de IT.
Figura 7: factores críticos de éxito
Procesos actualmente sin soporte de IT
P3 Anunciar productos
P4 Controlar la competencia
P6 Educar a los vendedores
P8 Educar / capacitar a los empleados
P12 Monitorear las quejas de los clientes
P13 Negociar diseños de fabricación
P16 Seleccionar y certificar proveedores
P17 Promover la compañía
P20 Monitorear el negocio del cliente /perspectiva
P22 Controlar la legislación

Figura 8: Auditoria del negocio / técnica del IT

Los sistemas en el cuadrante 2 están en buenas condiciones y son muy apreciados por
su contribución al negocio. Sin embargo, la financiación es más importante con un
enfoque en "Mantenimiento".
Los sistemas en el cuadrante 4 necesitan un escrutinio minucioso. El soporte IS actual
para estos procesos es pobre y se deben hacer preguntas sobre la necesidad y el costo
de mejorar la situación. si se justifica la inversión, el financiamiento se centrará en
"rediseñar" y "rehacer", en comparación con el mantenimiento en el cuadrante 2, y se
requerirá una técnica de gestión de proyecto diferente.
Los sistemas en el cuadrante 1 son una amenaza para el negocio. cuanto más tiempo
una compañía ha estado usando computadoras, más probable es que tenga un grupo de
sistemas aquí; por ejemplo, sistemas antiguos de cuentas por pagar. a menudo dichos
sistemas necesitan las mejores habilidades disponibles y, a menudo, no los obtienen
hasta que haya una crisis. en esta etapa, el nuevo desarrollo de otra persona se retrasa,
la administración de decibeles se hace cargo y la imagen de la tienda de TI sufre. El
enfoque de financiamiento para estos sistemas debe estar en "Renovación" y el objetivo
debe ser moverlos al cuadrante 2.
Los sistemas ubicados en el cuadrante 3 son menos comunes que hace diez o quince
años. Posiblemente sean técnicamente fascinantes, pero claramente no son muy
valorados por su contribución al negocio. Aquí el enfoque de financiación debe ser
mejorar la "relevancia del negocio", y se requiere un alto grado de participación del
usuario para garantizar el éxito.
el análisis anterior revela cuánto dinero nuevo se requiere para administrar su cartera
(carpeta o portafolio) actual. No es un gasto popular. No es tan glamoroso ni tan
emocionante como desarrollar nuevos sistemas, pero es necesario. Este análisis muestra
a los gerentes de empresas por qué.
(b) Inversiones estratégicas futuras: pero ¿qué hay de los nuevos sistemas glamorosos y
emocionantes? Simplemente mantener las existencias actuales en el cuadrante 2 de la
figura 8 es poco probable que cree una ventaja competitiva sostenible. ¿Dónde debería
concentrarse la nueva inversión?
Deben tenerse en cuenta dos cosas: en primer lugar, aquellos procesos que actualmente
no tienen soporte informático (P3, P4, P6, P8, P13, P16, P17, P20, P22); en segundo
lugar, la calidad actual del soporte de TI para los Procesos más críticos (consulte la zona
1, figura 6), prestando especial atención a los elementos de “Big Burner” (gran
quemador o algo así)
(c) debatir las prioridades de IT: junto con la función de IT, el equipo de gestión ahora
puede llevar a cabo un debate racional sobre sus prioridades para el desarrollo de TI que
abarque tanto la cartera (o carpeta o portafolio) de IT actual como las futuras
inversiones estratégicas. El debate se centra en el uso de recursos escasos (usuarios y
personal de IT y gastos de capital e ingresos) para producir un conjunto de aplicaciones
y servicios de IT que brindan el máximo apoyo a los procesos del negocio que el equipo
ha identificado como críticos para su rendimiento del negocio. El uso de PQM tiende a
alentar una voluntad común de tener éxito, reduciendo así la probabilidad de que se
establezcan prioridades a través del debate "megáfono" o "decibeles".
Pero aún deben tomarse decisiones difíciles. La "viabilidad técnica" de los desarrollos
deseados debe evaluarse rigurosamente, al igual que la capacidad de los empleados de
todos los niveles del negocio para obtener los máximos beneficios de ellos. Deben
abordarse las cuestiones que rodean la certeza, y de hecho el alcance total, del costo de
desarrollo / renovación, ejecución y mantenimiento de las aplicaciones planificadas
debe abordarse. los factores relacionados con la cuantificación y el alcance de los
beneficios proyectados, así como la implementación de "sistemas de gestión de
beneficios" para maximizar los beneficios previstos, deben debatirse. y, por supuesto,
deben prepararse casos de análisis de riesgos que abarquen tanto los costos como los
beneficios. (Los problemas relacionados con los costos, beneficios y análisis de costos /
beneficios de IT se abordan en los capítulos 7, 10 y 11).

3.10.3 entregando las prioridades de IT

Una vez que el equipo haya resuelto sus prioridades para el desarrollo o la renovación
de aplicaciones, se formularán los proyectos requeridos y se aplicarán las técnicas de
gestión de proyectos apropiadas. del mismo modo que todo el "equipo" se centró en los
MCP para la mejora de sus actividades comerciales generales, PQM garantiza que este
enfoque empresarial se adelante para seleccionar las prioridades de IT. esto lleva la
realidad al requisito frecuentemente establecido de que "el plan de IT debe reflejar el
plan de negocios". Este uso extendido de la Metodología ha permitido que muchos
equipos de gestión logren este requisito para su beneficio y el de toda la empresa. Han
planeado obtener el máximo beneficio de su inversión en IT.

3.11 Resumen de las reglas de PQM

1. no se embarque en una sesión de planificación de PQM sin que el facilitador complete
una sesión informativa adecuada con el patrocinador
2. Todos los gerentes relevantes deben estar presentes en la sesión de planificación. No
lo ejecute si falta un jugador clave en el equipo.
3. La misión debe ser definida y acordada por el equipo antes de pasar a la siguiente
etapa del estudio; de lo contrario, todo lo que sigue será un esfuerzo desperdiciado.
4. Asegúrese de que cada miembro del equipo haga su contribución a las influencias
dominantes para que los problemas reales que impactan la misión sean tablas.
5. Un número limitado de CDF debe ser acordado por el equipo como la lista
individualmente necesaria, y en conjunto suficiente, de los elementos esenciales que se
deben alcanzar para que la misión se cumpla.
6. Cada proceso de negocio debe tener un propietario, y el propietario debe ser un
miembro del equipo de gestión que acordó los CSF.
7. Tome cada CFS por turno y considere cuáles son los procesos empresariales que se
requieren para administrarlo, agregando nuevos procesos comerciales si es necesario.
8. Aquellos procesos comerciales definidos como los "procesos más críticos" (MCP) para
la mejora deben ser muy pocos. El equipo no debe crear una situación de 'misión
imposible' para sí mismo tratando de administrar demasiados MCP.
9. El equipo debe usar el sistema de gestión 'negocios como siempre' para definir e
implementar proyectos de mejora de la calidad del proceso.
10. Asegurar que las consideraciones y servicios completos (así como a los nuevos
desarrollos).

Estos pueden contener la clave para mejoras importantes de los MCP.

Otras pautas para el uso exitoso de PQM se encuentran en el Apéndice 5.

4. Usos alternativos de la metodología PQM

la sección 3 de este capítulo discutió el uso "clásico" de PQM que permite a un equipo
de gestión identificar aquellas aplicaciones y servicios basados en TI que necesitan ser
mejorados o desarrollados. PQM se ha utilizado para ayudar al análisis de una gama más
amplia de problemas, tal como se describe en las Notas 2, 3 y 4, y entre estos dos ha
demostrado ser particularmente exitoso. estos son:
1. proyectos principales de toda la organización
2. el establecimiento de prioridades por el equipo de TI

que se describen más abajo

4.1 grandes proyectos de toda la organización

4.1.1 el problema
muchas empresas han implementado o están implementando grandes proyectos de
"cambio cultural" diseñados para cambiar fundamentalmente la forma en que funciona
la organización. Entre los ejemplos de estos se incluye la entrega de una mejor
orientación de servicio al cliente y la implementación de un sistema electrónico de
'comunicación de negocios'. Ambos ejemplos pueden dar como resultado un
rendimiento empresarial mejorado a través de una productividad interna mejorada y un
crecimiento en la cuota marcada rentable.
Los proyectos exitosos de "cambio cultural" normalmente exigen una verdadera
propiedad al más alto nivel en la empresa y la participación activa de toda la Junta. El
fracaso de estos proyectos ocurre con frecuencia cuando la alta gerencia delega la
propiedad a un gerente de proyecto de nivel más bajo. Para minimizar el riesgo de
fracaso y maximizar las posibilidades de éxito para estos proyectos de "cambio de
cultura", se ha utilizado una versión modificada de PQM con los equipos de alta
dirección para identificar las criticidades de los proyectos y los procesos consecuentes
relacionados con el proyecto que poseen.
Este uso de la metodología mejora las capacidades de la junta directiva en su rol de
equipo de proyecto y enfatiza que el desempeño de cada director es vital para el éxito
general del proyecto.

4.1.2 las sesiones de planificación

Las sesiones de planificación siguen los mismos pasos básicos que se describen en la
figura 2. Las diferencias clave son las siguientes.
1. el equipo: en este caso, el equipo es la Junta que actúa en su función de principal
grupo directivo para el proyecto y el propietario del proyecto es (normalmente) el
director general.
A menudo se designa a un director de revisión para que supervise los asuntos y las
actividades cotidianas relacionadas con el proyecto en nombre de la junta. El gerente
del proyecto normalmente informa al director de revisión.
2. la declaración de la misión: la misión del proyecto se describe en una declaración de
definición de proyecto ejecutivo (EPDS) de entre quince y veinte páginas. La producción
de la EPDS es vital para que la junta desempeñe su función requerida en los proyectos y
representa la visión consensuada del proyecto. es la 'Visión' del proyecto para toda la
organización. La EPDS se prepara antes de la revisión, y es objeto de una discusión
detallada y, si corresponde, de modificaciones durante la reunión.
Una EPDS generalmente incluirá:
- Introducción
-resumen de gestión
-CSF de la empresa (si están desarrollados), y la forma en que el proyecto aborda uno o
más de estos.
- Elementos clave y límites del proyecto
- planes de implementación
- proyecto: costo (desarrollo, usuario, entrenamiento, educación, consultoría, etc.)

beneficios (sistema de administración de beneficios, 'responsabilidad' de beneficios de

los miembros de la junta individual, área de beneficio, beneficios específicos)
- Proyecto: riesgos, suposiciones, factores críticos de éxito
- organización del proyecto y recursos
La EPDS se emitirá en varias versiones si el proyecto tiene una secuencia de pasos de
implementación discretos que están programados para tener lugar durante un período
de años, p. en Europa, luego EE. UU., luego Asia-Pacífico.

3. CSF para el proyecto, los directores luego verifican o enmiendan los CSF contenidos
en la EPDS. estas son sus responsabilidades como el principal grupo directivo.
4. los procesos más críticos: con base en los MCA, los directores luego construyen la
matriz para relacionar los MCA con los procesos de negocios y establecer los procesos
más críticos. Luego se asignará la propiedad de todos los procesos requeridos para el
proyecto y se implementarán los proyectos de mejora de calidad apropiados. Los
procesos relevantes para el proyecto serán una mezcla de procesos para la organización
como un todo, ir subprocesos específicos del proyecto.

4.1.3 revisiones de seguimiento

En intervalos apropiados después de la sesión de planificación la sesión de planificación
el director de revisión del proyecto, junto con el consultor, consultor de PQM, realiza
una reunión de revisión con el propietario del proyecto y cada uno de los directores para
discutir sus opiniones actuales del proyecto, basado en la EPDS y el impacto que está
teniendo en sus actividades funcionales.
Se confirman las responsabilidades individuales actuales dentro del proyecto y se
modifican los CSF si corresponde. Con el tiempo, el riesgo de cambio se identifica y
legitima el establecimiento de cuestiones importantes para una mayor consideración.
También se revisan los procesos para administrar los CSF apropiados para el propietario
y los directores individuales. este procedimiento proporciona el mecanismo para
implementar y sostener el proyecto en toda la empresa.

4.1.4 Prueba de 'cambio cultural'

de vez en cuando es apropiado probar si el proyecto está logrando o no el "cambio de
cultura" deseado. Esto se hace mediante entrevistas, dirigidas por el director de revisión
y el consultor de PQM, con niveles seleccionados en la jerarquía de gestión y, si
corresponde, con clientes, proveedores y otras partes externas. estas entrevistas
proporcionaron información detallada sobre el grado en que se está produciendo el
"cambio cultural" y apuntan a acciones correctivas, especialmente a nivel de gestión
intermedia, que pueden ser necesarias. también proporcionan un excelente juicio sobre
la efectividad de la junta para mantener viva la 'Visión' del proyecto

4.2 El establecimiento de prioridades por parte del equipo de TI

PQM se ha utilizado ampliamente para centrarse en la función de TI en las empresas, y
una ilustración de este enfoque es proporcionada por el "taller de evaluación de la salud
del sistema de información" de dos días, dirigido por el equipo de gestión de TI. El
objetivo de este taller es mejorar la efectividad de la función de TI mediante un equipo
que identifique de forma conjunta los procesos empresariales de TI más importantes y
luego se comprometa con los proyectos de mejora de calidad relevantes.
Este trabajo ha llevado al desarrollo de una declaración de misión de TI estándar, CSF
relacionados y procesos de negocio como se muestra a continuación. Los equipos
pueden optar por adoptar estos elementos "estándar" o personalizarlos, pero de
cualquier forma proporcionan valiosos aportes para el taller o para la exposición y el uso
posterior de la metodología PQM asociada con una variedad de equipos en la función
de TI.

4.2.1 Declaración de misión de TI

"El objetivo fundamental de un departamento de TI debería ser explotar la tecnología
de la información para beneficiar a la empresa y producir productos y servicios de 'valor
por dinero' que cumplan exactamente los requisitos justificados del usuario, estén libres
de defectos, estén disponibles cuando sea necesario y sean producidos / mantenidos al
costo mínimo '

4.2.2 CSF para la función de TI

Los CSF típicos para esta misión son:
"debemos asegurarnos ..."
1. Prioridades de TI en línea con los requisitos estratégicos del negocio.
2. Maximizar la participación del usuario con roles de usuario claramente definidos.
3. Una organización de información sistemática que está estructurada para promover la
responsabilidad individual.
4. El uso de procesos efectivos de gestión de proyectos.
5. Entrega eficiente / efectiva de la función del usuario.
6. La orientación de servicio al cliente respaldado por acuerdos de nivel de servicio.
7. Número suficiente de personas debidamente capacitadas para cumplir con todos los
compromisos con los clientes.
8. Un sistema de comunicación efectivo con otros usuarios.

4.2.3 Procesos empresariales de TI

Esos procesos comerciales de TI presentados para su uso en los talleres de evaluación
de salud se enumeran en el apéndice 3. Estos se utilizan como pautas y pueden tener
procesos comerciales agregados o eliminados para reflejar el mandato acordado de una
función de TI en una empresa.
El desarrollo de material estándar para la función de TI ha contribuido en gran medida
a la velocidad con la que el equipo de gestión de TI puede progresar a través de los pasos
de la metodología PQM en el "Taller de evaluación de la salud".

Sumario
"Houston, tenemos un problema", dijo James Lovell, comandante de la misión Apolo 13,
cuando en abril de 1970 ocurrió un mal funcionamiento, conectado con el módulo de
oxígeno líquido de la nave espacial (afortunadamente Lovell y su tripulación regresaron
sanos y salvos a tierra).
Mientras que su "problema" puede manifestarse de una manera menos dramática,
muchos equipos de gestión (especialmente la Junta) encuentran que la identificación de
aquellos a las aplicaciones y servicios IT, que potencialmente aportará la máxima
contribución a la rentabilidad de la empresa, está plagada de dificultades . reconocen
fácilmente que la IT puede traer considerable "ventaja competitiva", y que las
aplicaciones y servicios de IT deberían ser un componente principal para respaldar el
plan de negocios. Pero, ¿cómo puede el equipo de gestión romper el estancamiento e
identificar positivamente esas aplicaciones y servicios de TI fundamentales que
aportarán la máxima ventaja competitiva y rentabilidad a la empresa?
En este capítulo , el enfoque para resolver este "problema" se ha descrito. En base a las
experiencias del autor y de muchos otros consultores, se ha demostrado que el uso de
la Metodología de Gestión de la Calidad del Proceso ha permitido a los equipos de
gestión lo siguiente:
(a) Identificar los requisitos clave para mejorar el rendimiento general de los negocios
de la empresa
(b) Llevar a cabo una auditoría sobre la inversión actual en aplicaciones y servicios
basados en TI.

(c) Identifique las principales oportunidades y prioridades para futuras inversiones en

aplicaciones y servicios basados en IT.
(d) Revise la relevancia comercial de los Proyectos de Mejoras de Calidad actuales (si
existe un Programa de Calidad).
PQM se ha utilizado para mejorar el rendimiento comercial de muchos tipos de equipos
de gestión, con una multiplicidad de funciones, en una amplia gama de industrias.
La formulación e implementación de proyectos para mejorar la calidad de los Procesos
de Negocio proporciona un excelente marco para que el equipo realice un seguimiento
(durante varios meses o años) de aquellos elementos que se identificaron como críticos
para el éxito de su negocio. El marco de gestión de proyectos para la implementación
de nuevas aplicaciones de IT o la "renovación" de la cartera actual nuevamente
proporciona un excelente método para el seguimiento. La experiencia sugiere que
tanto el Patrocinador como el Facilitador juegan un papel importante para mantener al
equipo enfocado en los proyectos de seguimiento.
Aunque la mayor parte de este capítulo se ha dedicado al uso "clásico" de PQM (que
permite a un equipo establecer sus prioridades comerciales, y luego sus prioridades de
IT), su uso en la implementación de grandes proyectos de toda la organización y en la
asistencia el equipo de IT para establecer sus prioridades comerciales también ha sido
revisado.
Finalmente, una fábula ilustra las duras realidades del mundo empresarial de hoy :
Todas las mañanas en África, una gacela se despierta. Sabe que debe correr más rápido
que el león más rápido o será asesinado. Cada mañana un león se despierta. Sabe que
debe correr más rápido que la gacela más lenta o morirá de hambre. no importa si eres
un león o una gacela: cuando salga el sol, será mejor que corras.
Se espera que el lector y su equipo de gestión estén suficientemente entusiasmados con
el contenido de este capítulo para usar PQM para ayudarlos a funcionar tan rápido como
lo necesiten.

Expresiones de gratitud
El autor desea agradecer la importante contribución hecha a su uso de la metodología
PQM a través del trabajo de investigación conjunta y las discusiones con:
* Maurice Hardaker, IBM international Education Centre, Belgium
* Alex Mayall, Gerente de servicios de aplicaciones estratégicas, Servicios de gestión
corporativa de ICI
* Alan Spall, Director de Finanzas, ICI Colors and Fine Chemicals

Notas:
Nota 1: Tipo de industria.
Cuando el equipo que utiliza la metodología tiene un enfoque común y un deseo real -
de hecho, la necesidad- de tener éxito, entonces el tipo de industria no ha sido un factor
inhibidor del uso de PQM. Las industrias donde PQM se ha utilizado incluyen:
• Seguro - vida y general
• Bolsa de seguros internacional
• Sociedades de construcción (asociaciones de ahorro y préstamo)
• Instituciones de servicios finales
• Banca nacional del Reino Unido
• Banca internacional
• Productos químicos / farmacéuticos
• Petróleo
• Gas
• Electrónica / informática / equipos de oficina / servicios de red
• Líneas aéreas / servicios aéreos
• Manufactura de alimentos, equipo agrícola
• Elaboración de cerveza / distribución de cerveza
• Venta al por menor - muebles, ropa, comida
• Asistencia médica privada
• Ministerios del gobierno central
• Autoridades del gobierno local
• Universidades
• Ingeniero civil
• Distribución- revistas
• Conglomerado internacional
• Industria pesada - acero
• Comunicaciones
• Festivales de cultura
• Agencias ambientales
Nota 2: Tipos de equipos de gestión
Mientras que el uso "óptimo" de la metodología se obtiene de un proceso de "arriba
hacia abajo", los equipos de gestión en una variedad de niveles en la gestión jerárquica
funcional han descubierto que su uso ha sido de considerable beneficio para ellos.
Habiendo articulado cuidadosamente su Misión, CSF y MCP, el equipo se encuentra en
una posición sólida cuando comienza el proceso de negociación de recursos.

Además de utilizar la metodología con grupos de gestión funcional, la metodología

también ha sido útil para equipos de gestión interfuncionales responsables de la
implementación de grandes proyectos, gestión de procesos de negocios, iniciativas de
"calidad", etc.
Los tipos de equipos de gestión que utilizan PQM para ayudar a su planificación incluyen:
• El consejo de administración.
• directores funcionales de línea y personal, y sus gerentes de informes.
• equipos funcionales debajo del nivel del director.
• Agrupaciones de gestión territorial.
• Juntas para empresas conjuntas.
• Equipos de proyecto.
 La junta como principal grupo directivo.
 Los grupos de dirección del usuario.
 El equipo de gestión del proyecto.
• Equipos de gestión de procesos comerciales.
• Equipos de trabajo.
• Grupos de empleados multifuncionales.
• Consejos de calidad.
• Equipos de marketing de la industria (en empresas "dirigidas por productos").
Nota 3: Funciones / actividades dirigidas
Para los tipos de actividades la cual metodología se ha utilizado para abordar incluyen:
• formulación de estrategias comerciales
 para la empresa.
 para unidades de negocio estratégicas.
 para las principales empresas / divisiones / territorios.
• Implementando proyectos importantes
 Para cambiar las estructuras del mercado.
 Para cambiar las "culturas corporativas".
• Mejora del rendimiento de los siguientes equipos funcionales:
 Investigación y desarrollo.
 Fabricación.
 Finanzas.
 Comunicaciones.
 Personal.
 Ventas y marketing.
 Distribución.
 Ingeniería (soporte de servicio al cliente).
 Propiedad administrativa.
 Servicios corporativos.
 Planificación.
• Validar los "sistemas de gestión" de la empresa
• Definición de estrategia de consultoría
• Mejorando la contribución de "marketing de canales"
nota 4: Actividades especificas
PM ha sido utilizado, en todo o en parte, por consultores en estudios de planificación
individual, seminarios y talleres con equipos de gestión de TI. Estos eventos utilizaron la
metodología en su totalidad - Misión a los MCP (ver figura 1) - o utilizaron partes de la
metodología (principalmente Misión y CSF) como un elemento principal junto con otras
ofertas de planificación y evaluación de IT.
Las áreas de "tema" cubiertas incluyen:
• vincular la estrategia de TI con la estrategia empresarial.

• Desarrollo e implementación de estrategias de IT.

• Estudios de organización de departamento de IT.
• Configuración de objetivos para la administración sénior de IT.
• Formulación de la estrategia del grupo de desarrollo de aplicaciones.
• Operaciones informáticas: problemas de gestión.
• Misión de Servicios Informáticos.
• Proyectos de oficina: definición y beneficios.
• Estrategia / justificación informática del "usuario final".
• Requisitos de información ejecutiva.
• Estrategia de carga de IT.

• Estrategia de red.
• Estrategia de infraestructura de IT.
• Sanción de caso de negocios de IT.

Apéndice 1: Sesión de planificación - nota informativa

Las sesiones de planificación deben ir precedidas de una nota del patrocinador a los
participantes. Por ejemplo:
Metodología de gestión de la calidad del proceso (PQM)
Creo que es importante que como equipo de gestión revisemos la estrategia comercial
y nuestro papel en la entrega. Este será el principal objetivo de nuestra reunión. (Fechas,
horas y ubicación para insertar).
Para ayudar a nuestras actividades, dos consultores de IBM actuarán como facilitadores,
y yo presidiré la reunión.
La reunión se estructurará en torno a la metodología PQM que ha sido desarrollada por
IBM. Una descripción de la metodología PQM está contenida en un artículo de Harvard
Business Review titulado "Cómo hacer que un equipo funcione" escrito por Maurice
Hardaker y Bryan Ward . Se adjunta una copia. Por favor, asegúrese de leerlo antes de
la reunión.
La reunión tomará en su punto de partida el siguiente proyecto de declaración de
misión:
inserte "........................."
¿Podrían considerar la idoneidad de la declaración de la misión para nuestras
actividades y los problemas que surgen de ella, para permitirnos comenzar de manera
positiva la reunión de planificación?
También adjunto una lista preliminar de los procesos comerciales aplicables a nuestra
misión. No están destinados a ser exhaustivos, algunos pueden no ser relevantes e
indudablemente habrán pasado por alto a otros. De nuevo, esta lista es un comienzo
que me gustaría que revise antes de la reunión, de modo que progresaremos
rápidamente en el punto de la metodología PQM donde estamos creando y revisando
nuestros procesos comerciales.
Espero con interés la reunión más interesante, pero más importante para desarrollar un
programa de seguimiento sólido al que todos estamos comprometidos y que
buscaremos activamente.

------------------------
Director Ejecutivo
Cuando la metodología se vaya a utilizar para establecer los requisitos de IT, se deben
incorporar las siguientes declaraciones en la carta:
¿podría asegurarse de que, antes de la reunión, tenga conocimiento de:
1. Los principales requisitos de IT para respaldar sus requisitos funcionales (o
unidad, territorio, etc.) del plan comercial de la empresa.
2. el estado actual de desarrollo de las aplicaciones y servicios de IT que respaldan
sus actividades funcionales (o unidad, territorio, etc.).

Apéndice 2: Ejecutando un estudio de planificación de PQM

Los siguientes pasos proporcionan una estructura para ejecutar un estudio de
planificación de gestión de calidad de proceso que se ha encontrado que funciona bien
bajo una amplia variedad de condiciones:
1) Al comienzo de la reunión, uno de los Facilitadores realiza una presentación sobre la
estructura de la Metodología y el resultado que se desarrollará en cada etapa (ver pasos
3 a 10 en la figura 2). Una copia de este material de información se distribuye a cada
participante, junto con un calendario para la sesión de planificación.
2) El resultado para cada etapa de la Metodología se distribuye a cada miembro del
equipo a medida que se desarrolla. Para hacer esto, los equipos han utilizado una serie
de alternativas que incluye:
a) Computadoras que utilizan programas de manipulación de texto y de datos
con salida impresa.
b) Rotafolio (Consiste normalmente de un pizarrón blanco montado en un
caballete, y sobre el cual se fija un bloc de hojas A1), láminas y símbolos magnéticos. El
material desarrollado en cada etapa se fotocopia luego (después de transcribirse si
corresponde).
El facilitador hace una breve presentación al comienzo de cada paso de la Metodología
para recordarle al grupo la tarea que se debe completar y el material que se generará.
3) Las Sesiones de lluvia de ideas de 'Lluvia de ideas' han demostrado ser una forma muy
valiosa de recopilar una gran variedad de ideas en un corto período de tiempo. Se deben
observar las siguientes reglas:
a) Duración máxima de 15 minutos.
b) Todos deberían contribuir.
c) Cualquiera puede decir cualquier cosa, no importa cuán loco o escandaloso.
De hecho, fomentar el pensamiento salvaje.
d) A nadie se le permite desafiar cualquier cosa que diga alguien, hasta el final
de la lluvia de ideas.
e) Sea conciso al notar ideas.

Apéndice 3: Los procesos de negocio TI.

El material para el proceso comercial de TI que se muestra a continuación se ha extraído
de los Talleres de evaluación de la salud y del material incluido en IBM g520-3998.
'Arquitectura de gestión de sistemas de información'.
1) Realizar planificación estratégica y control.
2) Definir la arquitectura técnica.
3) Desarrollo de conducta y planificación de proyectos.
4) Monitorear los servicios y la planificación del acuerdo de nivel de servicio.
5) Llevar a cabo la planificación de la capacidad.
6) Llevar a cabo la planificación de habilidades.
7) Llevar a cabo la planificación del presupuesto.
8) Llevar a cabo la gestión del plan táctico.
9) Administrar el control de cambios.
10) Administrar el control de activos y datos.
11) Administrar servicio y control de problemas.
12) Implementar la metodología de desarrollo y mantenimiento de aplicaciones.
13) Desarrollo de aplicaciones / adquisición de software
14) Llevar a cabo el enlace de hardware / instalaciones.
15) Ajuste de la conducta / equilibrio del sistema
16) Monitorear producción
17) Sistemas de monitoreo y soporte de red.
18) Supervisar distribución.
19) Facilite el soporte y la ayuda del usuario.
20) Monitorear la medición del servicio y los informes.
21) Implementar servicios de marketing.
22) Monitorear finanzas y servicios administrativos.
23) Llevar a cabo la educación y la formación.
24) Monitorear el desempeño del personal.
25) Desarrollar la gestión de personas / procedimientos de reclutamiento.
26) Implementar la garantía de calidad.
27) Llevar a cabo relaciones públicas.
28) Implementar enlace de usuario.
29) Gestionar la gestión de proveedores.

Apéndice 4: Los procesos de negocio para la fabricación / Industrias de

proceso.
El material para los procesos de negocio generales mostradas se ha elaborado a partir
de material desarrollado por Tony Treadgold, Gerente de Capacitación, ICI Chemicals
and Polymers (Imperial Chemical Industries (ICI) fue una empresa química británica con
sede en Londres) y el autor. Estos han demostrado ser útiles como un conjunto de
patrones para simular la discusión, pero normalmente serían enmendados.
1) Identificar mercados.
2) Llevar a cabo estudios de mercado.
3) Desarrollar carpeta de productos / servicios.
4) Formular estrategias comerciales.
5) Monitorear negocios / legales / entornos políticos.
6) Preparar planes de negocios.
7) Llevar a cabo el análisis de la competencia.
8) Establecer los requisitos del cliente.
9) Fijar precio / estrategia de costos.
10) Negociar el suministro de productos.
11) Negociar el suministro de materias primas.
12) Legisladores del lobby.
13) Acordar estrategia comercial.
14) Proporcionar objetivos de investigación enfocados.
15) Llevar a cabo la investigación y el desarrollo.
16) Desarrollar canales para comercializar.
17) Desarrollar una red de distribución / comunicaciones.
18) Distribuidores de trenes.
19) Monitorar el rendimiento del distribuidor.
20) Proporcionar soporte técnico a los distribuidores.
21) Publicidad / promoción de productos.
22) Crear / implementar políticas de relaciones públicas.
23) Desarrollar un plan de inversión de capital.
24) Administrar fabricación.
25) Servicio de pedidos de clientes (factura / despacho / cuenta).
26) Llevar a cabo auditorías de satisfacción del cliente.
27) Gestionar el control de aseguramiento de la calidad.
28) Desarrollar / implementar estrategia de TI.
29) Administrar / monitorear los programas de cambio.
30) Revisión de estrategia / planes operacionales.

Apéndice 5: El uso exitoso de PQM

La experiencia ha demostrado que los estudios de PQM no siempre son fáciles de
ejecutar y algunos son más exitosos que otros. Este apéndice detalla los factores
observados durante muchos estudios que han conducido al relativo "fracaso" o "éxito"
de las sesiones de PQM.
‘Factores de fracaso’
1) No tener un propósito común en el grupo, por lo que una ‘Misión’ no podría ser
acordada.
2) El equipo de gestión estaba totalmente sobrecargado de "orientación" desde todas
las direcciones; la Metodología PQM era simplemente considerada como un intento más
de "hacer" algo.
3) Los Facilitadores no insistieron en una sesión informativa rigurosa, el tiempo
adecuado para llevar a cabo la sesión, solo en tener aquellos dedicados al éxito de la
Misión, MCPs, etc., en la sesión de planificación.
4) Cambios organizacionales intervinientes entre la sesión informativa y la sesión de
planificación.
5) El Patrocinador había creado expectativas que la Metodología no pudo cumplir
6) La cultura de la organización no fomentó la discusión libre y franca.
7) Varios conceptos de PQM sobre "criticidad", etc. se consideraron demasiado
extremos

8) El equipo había sido instruido para participar en una sesión de planificación, sin
seguimiento previsto.
9) El equipo creó una serie de proyectos de acción a corto plazo que se esfumaron, en
lugar de confiar en sus sistemas de gestión habituales para seguir adelante.
‘Factores de éxito’
1) Realizar una sesión informativa efectiva y exhaustiva.
2) La sesión de planificación se apegó a las reglas en términos de tiempo, participantes,
etc.
3) El patrocinador cumplió su rol acordado.
4) Hubo un fuerte deseo de tener éxito.
5) El resultado relevante de la sesión de planificación estuvo bien comunicado.
6) Los sistemas de gestión habituales se utilizaron eficazmente para gestionar los
proyectos de mejora de seguimiento de los procesos más críticos.
7) Un "inicio rápido" tuvo lugar después de la sesión de planificación; se identificó un
proyecto importante de mejora y se implementó rápidamente.