Vous êtes sur la page 1sur 19

Etapa 5:

Transformación
Chávez Zapata Deybee
Muñoz Aleman Jonathan
Quispe Laveriano Luis
Ramos Ramírez Yaser
Universidad Nacional del Salirrosas Moreno Patricia
Santa
El propósito de esta etapa es realizar la visión del proceso
Facultad de Ingeniería implementando el diseño producido en la etapa 4.
E.A.P. de Ing. De Sistemas

Reingeniería

02/01/2011
Universidad Nacional del Santa 1
Etapa 5: Transformación

C ONTENIDO
Tarea 5.1. Completar el Diseño del Sistema ............................................................................................................................ 3
Tarea 5.2. Ejecutar Diseño Técnico .......................................................................................................................................... 7
Tarea 5.3. Desarrollar Planes de Pruebas y de Introducción ................................................................................................ 8
Tarea 5.4. Evaluar al Personal .................................................................................................................................................. 10
Tarea 5.5. Construir Sistema ...................................................................................................................................................... 0
Tarea 5.6. Capacitar al Personal ................................................................................................................................................. 0
Tarea 5.7. Hacer Prueba Piloto del Nuevo Proceso .............................................................................................................. 1
Tarea 5.8. Refinamiento y Transición ....................................................................................................................................... 1
Tarea 5.9. Mejora Continua ........................................................................................................................................................ 2

I LUSTRACIONES
Ilustración 1. Mapa conceptual de la introduccion. ............................................................................................................... 4
Ilustración 2. Mapa conceptual de la tarea 5.1. ....................................................................................................................... 7
Ilustración 3. Mapa conceptual de la tarea 5.2. ....................................................................................................................... 8
Ilustración 4. Mapa conceptual de la tarea 5.3. ....................................................................................................................... 9
Ilustración 5. Mapa conceptual de la tarea 5.4. ....................................................................................................................... 0
Ilustración 6. Mapa conceptual de la tarea 5.5. ....................................................................................................................... 1
Ilustración 7. Mapa conceptual de la tarea 5.6. ....................................................................................................................... 2
Ilustración 8. Mapas conceptuales de las tareas 5.7 y 5.8. ..................................................................................................... 3
Ilustración 9. Mapa conceptual de la tarea 5.9. ....................................................................................................................... 5

T ABLAS
Tabla 1. Despachar Pedidos: evaluacion personal para la posicion de RSC. ..................................................................... 0
2 de enero de 2011
Universidad Nacional del Santa 2
Etapa 5: Transformación

ETAPA 5: TRANSFORMACIÓN
METODOLOGÍA RE – REINGENIERÍA

El propósito de esta etapa es realizar la visión del proceso implementando el diseño producido en la etapa 4. La
etapa de transformación produce una versión piloto y una versión de plena producción para el proceso rediseñado
y mecanismos de cambio continuo durante la vida de la versión de producción.

Las preguntas claves que contesta esta etapa son:

 ¿Cuándo debemos empezar a controlar el progreso? ¿Cómo sabemos si vamos por buen camino?
 ¿Qué mecanismos debemos desarrollar para resolver problemas imprevistos?
 ¿Cómo podemos asegurarnos de que en el periodo de transición no haya tropiezos?
 ¿Cómo seguimos creando impulso para cambio continuo?
 ¿Qué técnicas debemos utilizar para reajustar la organización?

Si hasta aquí el proyecto de reingeniería ha tenido éxito, los diseños y los planes producidos en etapas anteriores
especificarán casi totalmente el trabajo de la etapa de transformación. Decimos “casi” porque la implementación
nunca resulta exactamente como se había programado. Como lo sabe todo el que haya manejado un proyecto, son
los detalles de la implementación y como se manejen lo que decide entre éxito y fracaso. Repetidamente se ha
demostrado que los excesos y los fracasos de un proyecto provienen con menor frecuencia de haber juzgado mal
las actividades que hemos planificado. Que de actividades que no habíamos planificado. Por eso insistimos en la
planificación del proceso de reingeniería desde el principio. Sin un plan, no podemos estar seguros de adónde va
el proyecto, si está progresando satisfactoriamente, si realmente ya llego a su destino.

La etapa de transformación consta de nueve tareas.

1. Completar el diseño del sistema.


2. Ejecutar diseño técnico.
3. Desarrollar planes de prueba y de introducción.
4. Evaluar al personal.
5. Construir sistema.
6. Capacitar al personal.
7. Hacer prueba piloto de nuevo proceso.
8. Refinamiento y transición.
9. Mejora continua.

Las tareas 5.1 y 5.2 se dedican a completar el diseño del sistema. La tarea 5.3 tiene por objetivo planificar la
2 de enero de 2011

prueba y la introducción del nuevo proceso. La evaluación y la selección del personal que trabajará en el nuevo
proceso es la finalidad de las tareas 5.4. La tarea 5.5 se dedica a construir el nuevo sistema. La tarea 5.6 le
proporciona capacitación al personal del proceso ya otros que puedan necesitarlo. Las tareas 5.7 y 5.8 someten a
prueba piloto el nuevo proceso, hacen los ajustes que indique la experiencia de esa prueba, y, finalmente,
implantan el proceso rediseñado en toda la organización. La tarea 5.9 se dedica a la mejora continua del proceso
una vez implantado.

Recuérdese que, lo mismo que en las demás etapas de la reingeniería, estas tareas no se han diseñado para ser
ejecutadas estrictamente en serie. Las tareas 5.1, 5.2, 5.3 y 5.5 forman un conjunto parcialmente ordenado de
Universidad Nacional del Santa 3
Etapa 5: Transformación

tareas relativas a implementación del diseño técnico. Las tareas 5.4 y 5.6 constituyen otro conjunto parcialmente
ordenado de tareas relativas a la implementación del diseño social. Luego las tareas 5.7 y 5.8 forman otro conjunto
parcialmente ordenado que tiene que seguir a los otros dos conjuntos anteriores; pero en cambio, la tarea 5.8
(refinamiento y transición) bien pude implicar repetición de partes de cualquiera de las tareas precedentes.

En la discusión que sigue se da por sentado que la tecnología principal que se emplea en el diseño del proceso es
tecnología informática y en la mayoría de los procesos, particularmente en los que se ejecutan en oficinas, ése será
el caso. Pero en otros procesos, como los que se llevan a cabo en ambientes industriales, el diseño técnico del
proceso bien puede emplear tecnologías físicas, tales como manejo de materiales, minería y terminado a máquina,
y control de procesos. Si éste es el caso, es preciso hacer las traslaciones pertinentes. Por ejemplo, cuando
hablamos de elegir entre una aplicación individualizada y un paquete de aplicación genérica, tradúzcase esto a
elegir entre un sistema físico diseñado especialmente para el cliente, y uno que se compra ya listo. Aún en los
procesos que se ejecutan en las oficinas habrá con mucha frecuencia cambios materiales. Éstos son generalmente
los cambios de instalaciones que hace necesario la nueva tecnología informática (v.gr., la instalación de
computadores y redes) y los cambios materiales que se necesitan para el nuevo cargo, el equipo y las relaciones
organizacionales (p. ej., traslados o reacomodamiento del espacio de trabajo).

Entre los participantes en la etapa de transformación se incluyen el equipo de reingeniería (que fue seleccionado
en la tarea 4B.12) y las organizaciones de apoyo, tales como servicios de información, recursos humanos,
administración de oficinas, instalaciones, ingeniería industrial, interesados en el proceso, el dueño del proceso, el
patrocinador y los otros miembros de la alta administración. Lo mismo que en etapas anteriores, también puede
participar un facilitador. Pero a diferencia de las etapas anteriores, en que los papeles y las responsabilidades del
equipo de reingeniería son relativamente claros, la posición de dicho equipo en la etapa de transformación será
determinada por el papel que se le asigne en el plan de implementación (tarea 4A.10 y 4B.12).

En algunos proyectos de reingeniería el equipo del proyecto actúa como comité directivo, y la principal
responsabilidad de la implementación recae sobre las organizaciones funcionales. En otros proyectos, el equipo de
reingeniería actúa como contratista general, y hace por sí mismo las cosas que puede hacer y subcontrata las que
no pueda hacer con las organizaciones funcionales o con abastecedores externos. En otros proyectos, en fin, el
equipo de reingeniería actúa como asesor del dueño del proceso, quien tiene la responsabilidad principal de la
implementación. Este papel es el más común cuando la mayor parte del trabajo de desarrollo se delega en un
abastecedor externo.

T AREA 5.1. C OMPLETAR EL D ISEÑO DEL S ISTEMA


En esta tarea, lo mismo que en las subsiguientes, la metodología Rápida Re se vale de la nomenclatura de
ingeniería informática. Sin embargo, cualquier método probado de desarrollo de sistemas es igualmente válido.

La tarea tiene que ver con el diseño “externo” de un sistema nuevo o revisado de apoyo del proceso rediseñado.
2 de enero de 2011

Incluye modelar subprocesos, modelar datos, definir aplicaciones y diseñar diálogos o menús e informes en
pantalla. Alternativamente, esta tarea podría incluir la selección de un paquete de aplicaciones disponible en el
comercio y diseño externo de cualquier modificación.

El diseño y el desarrollo de sistemas automatizados de aplicación es una empresa llena de riesgos y dificultades.
Pese a que las organizaciones grandes han venido creando tales sistemas desde hace por lo menos 30 años, el
índice de éxitos es considerablemente más bajo que el de otros esfuerzos organizacionales similares. Los estudios
han mostrado que más o menos el 30 % de los proyectos de desarrollo de aplicaciones se abandonan antes de
Universidad Nacional del Santa 4
Etapa 5: Transformación

completarlos y que de los que se terminan, el proyecto promedio excede al ciento por ciento en tiempo y al ciento
por ciento en presupuesto.

I LUSTRACIÓN 1. M APA CONCEPTUAL DE LA INTRODUCCION .

La causa primaria de estos resultados insatisfactorios es que la mayoría de las organizaciones no han rediseñado su
proceso de desarrollo de sistemas. Éste es un tema que merece su propio libro y muchos libros se han escrito
sobre ingeniería de software, metodologías de desarrollo de sistemas y administración de proyectos. Sin embargo,
no nos proponemos reproducir aquí ese trabajo sino más bien recalcar que el desarrollo de sistemas
individualizados de aplicación para implementar el diseño técnico de un proceso rediseñado se debe evitar en
cuanto sea posible. Tal desarrollo no sólo aumenta el riesgo de fracaso sino que, invariablemente, alarga el tiempo
de la implementación.

Por fortuna, ya existen en el comercio paquetes genéricos de aplicaciones para casi todas las necesidades de los
negocios. Y muchos paquetes contienen opciones incorporadas que permiten a diferentes organizaciones adaptar
la aplicación a sus propias necesidades. Aun en el caso de que un solo paquete de aplicación no contenga todas las
características y funciones requeridas, una organización tiene todavía varias opciones para usar el paquete. Una de
ellas es modificarlo, es decir, cambiar algo del código del vendedor del paquete. Esta opción en la menos deseable
porque aumenta tanto el riesgo como la dificultad de mantener el sistema. Una segunda opción es extender el
2 de enero de 2011

paquete, es decir, dejar sin cambio el código del vendedor, pero redactar un código adicional que funcione con el
paquete. A veces el vendedor suministra interfaces de programación de aplicaciones [Application Programming
Interfaces, API] de apoyo para facilitar extender el paquete. Otras veces la organización redacta un código que
“rodea” el paquete del vendedor. En todo caso, esta opción de extender el paquete es menos arriesgada que la
primera. Una tercera opción es integrar el paquete, es decir, hacer funcionar el paquete con otro paquete o
programa individualizado usando las características de integración del ambiente operativo. Especialmente en
ambientes que operan con microcomputadores, tales como UNIX o Microsoft Windows, las capacidades de
integración son extensas. Esta opción es la menos arriesgada de las tres.
Universidad Nacional del Santa 5
Etapa 5: Transformación

Desde luego, estas decisiones no son sencillas; incluye en consideraciones como las siguientes:

 ¿En qué plataformas técnicas está disponible el paquete y cuáles apoya mi organización?
 ¿Qué estructuras de datos usa el paquete? ¿Éstas son estructuras con las cuales nosotros podemos
trabajar?
 ¿Hay necesidad de integrar esta aplicación con aplicaciones preexistentes, y si es así, como se puede
lograr esto?
 ¿Cuál es nuestro nivel de confianza en que el paquete funcionará tal como se anuncia?
 ¿Cuál es nuestro nivel de confianza en que el vendedor del paquete permanecerá viable y dará apoyo
adecuado?

La discusión de estas cuestiones estar fuera del propósito de este libro. Se mencionan únicamente para ilustrar
que, si bien el uso de paquetes de aplicaciones disponibles en el comercio es una opción atractiva que debe
considerar seriamente todo equipo de reingeniería, es una decisión compleja que requiere cuidadoso análisis.

Esta tarea empieza, pues, modelando subprocesos, es decir, extendiendo el nivel de detalle del diseño técnico del
proceso.

Viene enseguida la modelación de datos. Ésta es también una expansión del nivel de detalle del diseño técnico.
Específicamente, define los atributos de cada entidad moderada en la tarea 4A.1 y los valores permitidos para cada
atributo. Por ejemplo, un atributo de la entidad “empleado” es “fecha de nacimiento”, que consta de los atributos
“mes de nacimiento”, “día de nacimiento” y “año de nacimiento”. Los valores permitidos para “mes de
nacimiento” son 1 a 12, etc.

Una vez que se han modelado los subprocesos y los datos, el paso siguiente es definir la aplicación. Esto consiste
en especificar las reglas relacionadas con cada actividad y paso del diseño del proceso.

En el proceso Despachar Pedidos de ABC Toy Company, la actividad Entrar Pedido tiene un paso llamado Identificar
Cliente. Las reglas para este paso podrían ser:

1. Aceptar nombre del cliente que aparece en el computador.


2. Examinar archivo del cliente en busca de casos en que aparezca un nombre del cliente parecido al aceptado del
computador.
3. Si en el archivo se encuentre exactamente el mismo nombre, tomar la información relativa al cliente y salir de este
paso.
4. Si en el archivo no se encuentre exactamente el mismo nombre, poner los nombres tomados del archivo en orden
descendente de semejanza con el nombre entrado. Exponer también un mensaje en la pantalla para dar al operario
la opción de seleccionar uno de los nombres expuestos, de volver a entrar el nombre del cliente, o de indicar que éste
es un cliente nuevo. Si el operario elige volver a entrar el nombre, pasar a 1.
5. Si el operario escoge uno de los nombres expuestos, tomar la información relativa al cliente y salir de este paso.
6. De lo contrario, pasar al paso Entrar Nuevo Cliente.
2 de enero de 2011

Hay muchas maneras de representar las reglas. La metodología específica de desarrollo de sistemas que adopte el
equipo de reingeniería incluirá generalmente una norma. Algunas de las normas comunes incluyen insumo-
proceso-salida (IPO), insumo-proceso-salida jerárquica (HIPO), e inglés estructurado (seudocódigo). Una vez
definida la aplicación, el equipo de proyecto puede investigar la disponibilidad en el comercio de paquetes para esa
aplicación. Sí parece factible la solución de un paquete, entonces el trabajo restante de esta tarea es evaluar el
paquete elegido, demostrarlo, y decidir qué modificaciones o extensión se deben hacer o cómo se debe integrar
con otro software.
Universidad Nacional del Santa 6
Etapa 5: Transformación

Si la solución de paquete no es factible, entonces el trabajo restante de esta tarea consiste en diseñar la interfaz
humana y un prototipo del sistema.

La interfaz humana consiste en los diálogos entre el sistema y los usuarios humanos y los despliegues individuales
en pantalla que comprenden esos diálogos. Cuando se trata de un paquete, el vendedor de éste ha diseñado ya la
interfaz humana, ojalá con una buena comprensión de los factores humanos. En efecto, la calidad de la interfaz
humana y su congruencia con el diseño social del proceso será uno de los criterios más importantes de evaluación
del paquete.

Las organizaciones que diseñan sus propias aplicaciones deben usar consideraciones similares para diseñar la
interfaz humana. La expresión “para comodidad del usuario” se ha usado mal y se ha abusado de ella, pero capta
la esencia del diseño de interfaz. Queremos que la interacción entre la tecnología y sus usuarios sea intuitivamente
fácil para cualquiera que entienda la aplicación. Esto ciertamente no quiere decir que la interfaz humana deba
remendar la interfaz del sistema que reemplaza, porque la mayoría de las interfaces humanas de los sistemas
heredados son espantosas. Lo mejor sería que la interfaz humana rediseñada debe facilitar aprender el sistema y
usarlo. Lo ideal es que incorpore características gráficas más que misteriosos códigos y mandos y debe prestar
ayuda al novato y ofrecer atajos al usuario experimentado.

Las organizaciones que diseñan sus propias aplicaciones deben desarrollar un prototipo porque se ha visto que
esto es más eficaz como medio de comunicación que un diseño en papel. Recuérdese que el tiempo y el costo de
corregir un sistema aumentan en una forma exponencial a medida que el error se multiplica pasando por
requisitos, diseño, desarrollo e implementación. El propósito del prototipo es que quienes lo desarrollan y sus
clientes comprendan las características esenciales del nuevo sistema que experimenten con las modificaciones
antes de hacer una inversión cuantiosa en la construcción del sistema. Algunos ambientes de desarrollo de
sistemas permiten la expansión del prototipo al sistema de producción, pero la mayoría no. Aun así, el desarrollo
de un prototipo bien vale el esfuerzo.

Ésta es, pues, la tarea en que las organizaciones que diseñan sus propias aplicaciones diseñan un prototipo. En la
tarea siguiente es donde lo desarrollan.

En ABC Toy Company, el equipo de reingeniería del proceso Despachar Pedidos resolvió que no le quedaba más remedio que
escoger un paquete para la aplicación de tramitar pedidos. Hasta entonces, la compañía no tenía ninguna organización de
servicios de información. Acababa de contratar a un gerente de servicios informáticos, y el equipo de reingeniería fue su primer
destino. El equipo encontró varios paquetes de tramitación de pedidos que parecían cumplir todos los requisitos. Uno de los
requisitos era que el paquete pudiera suministrar datos al paquete de contabilidad Peachtree que ya tenían para computador
personal, porque no se tenía la intención de reemplazarlo. Otro requisito era que el paquete pudiera aceptar insumos de
tandas de pedidos ajustados a formatos industriales estándar de intercambio electrónico de datos (IED).

También pudo el equipo encontrar un sistema experto ya hecho para optimización de bodega y señalamiento de rutas de
despachos, aun cuando su implementación necesitaría considerable ayuda del vendedor.

Para el sistema experto de crédito, el equipo resolvió crear su propia aplicación, usando una “caja de herramientas” comercial.
2 de enero de 2011

Reconoció que la compañía tendría que contratar los servicios de un ingeniero de conocimientos que trabajaría con el gerente de
crédito para extractar tal experiencia y representarla como un conjunto de reglas para la base de conocimiento del sistema
experto. El equipo reconoció igualmente que necesitaría crear un interfaz entre sistema de cuentas por cobrar y el sistema
experto de modo que éste tuviera acceso a la historia de crédito del cliente.
Universidad Nacional del Santa 7
Etapa 5: Transformación

I LUSTRACIÓN 2. M APA CONCEPTUAL DE LA TAREA 5.1.

T AREA 5.2. E JECUTAR D ISEÑO T ÉCNICO


Esta tarea tiene que ver con el diseño “interno” del sistema nuevo o revisado que apoya el proceso rediseñado.
Para paquetes, esta tarea ya la realizaba el vendedor.

Esta tarea escoge la plataforma o plataformas sobre las cuales se va a montar el sistema de aplicación. Tanto para
sistemas de información como para sistemas físicos, la plataforma consiste en aparatos y software. La diferencia
principal está en los dispositivos terminales. Los terminales de los sistemas de información proporcionan interfaz
humana. Los de los sistemas físicos proporcionan interfaces tanto con seres humanos como con cosas.

Las decisiones sobre selección de plataforma deben ser impulsadas por las necesidades y por la disponibilidad de
software de aplicación. En igual de circunstancias, un equipo de reingeniería debe escoger primero el paquete de
aplicación más apropiado y luego la plataforma en la cual funcionara mejor. Esa es la razón por la cual pusimos la
selección de paquete en la tarea precedente. Pero a menudo un equipo de proyecto no tiene completa libertad
para elegir plataforma. A veces este se debe al que el sistema tiene que interactuar con otros sistemas, y la mejor
manera de lograrlo es montar el nuevo sistema en la misma plataforma del viejo. Otras veces se debe a que la
2 de enero de 2011

organización tomo la decisión estratégica de montar todo nuevo desarrollo en la misma plataforma.

Una vez que se ha seleccionado plataforma, el trabajo restante de la tarea depende de que si la aplicación se va a
basar en un paquete o se va a desarrollar individualizada. Si se basa en un paquete, el paso siguiente implica la
selección de las opciones del paquete que se van a usar o el diseño de extensiones o modificaciones que se van a
hacer al paquete o a las interfaces entre dicho paquete y otro sistema. Si la aplicación se desarrolla individualizada,
el paso siguiente en diseñar la estructura física de datos. Esto significa correlacionar los atributos de una entrada
en los campos de datos, decidiendo cuales campos de datos debe residir en determinado registro o tablas, y
especificando como se deben representar las relaciones entre entidades. Significa igualmente especificar los
Universidad Nacional del Santa 8
Etapa 5: Transformación

medios sobre los cuales residirán los datos y los métodos de evaluar dichos datos. Las opciones están aquí
limitadas por la capacidad del subsistema de manejo de datos de la plataforma elegida.

Otra parte de esta tarea es el diseño detallado del sistema, incluso mayor refinamiento de las reglas desarrolladas
en la tarea 5.1, segregación de las reglas en componentes del sistema o módulos, y extensión de dichas reglas para
incluir interacciones entre los módulos y con los usuarios del sistema.

Al terminar estas actividades, la estructura del sistema quedara completamente especificada. El trabajo restante de
esta tarea es finalizar definiciones y planes para la implementación del plan piloto y para las entregas del proyecto.

I LUSTRACIÓN 3. M APA CONCEPTUAL DE LA TAREA 5.2.

T AREA 5.3. D ESARROLLAR P LANES DE P RUEBAS Y DE


I NTRODUCCIÓN
Esta tarea determina los métodos que se van a emplear para validar el sistema; es decir, determina como verificar
la corrección y la calidad de las entregas del proyecto. Las dos herramientas principales de verificación son
revisión estándar y revisión independiente. La primera es importante por varias razones: Primero, da dirección a
quienes están desarrollando el proyecto; segundo, da un punto de referencia a los revisores; y tercero, ayuda a
condicionar las expectativas de los clientes. Revisión independiente significa que personas distintas de los que lo
están desarrollando revisan las entregas. La “revisión” puede incluir sistemas tensión, pruebas paralelas o piloto,
inspección u observación, visitas, demostraciones, etc.

La tarea determina también los métodos que se van a usar para conversión y transición y desarrolla un plan de
2 de enero de 2011

implantación por fases. La conversión entraña varias cuestiones. En primer lugar el nuevo sistema puede
reemplazar en todo o en parte a un sistema existente, llamado a menudo el sistema legado. El plan debe identificar
papeles del sistema legado e interfaces en el proceso y determinar cómo cambiarán éstos. Debe también resolver
cómo disponer de los datos del legado: ¿Serán convertidos, se les permitirá “escapar”, o se hará caso omiso de
ellos? ¿Cómo se reconciliaran los resultados del nuevo sistema con los del sistema legado? El equipo de
reingeniería tiene que evaluar y documentar los requisitos de la conversión. El tiempo y los recursos que se
dedican a la conversión pueden ser considerables, y a menudo se subestiman.
Universidad Nacional del Santa 9
Etapa 5: Transformación

También hay varias cuestiones implicadas en implantar o llevar al terreno el sistema, particularmente en una
organización geográficamente dispersa. El personal que va a estar encargado de llevar el sistema al terreno “en el
sitio” debe también intervenir en la planificación. El plan de implantación debe atender a cuestiones tales como:
¿Qué entrenamiento se necesitara en cada sitio? ¿Qué documentación? ¿Cómo obtendrá cada sitio ayuda con sus
problemas? ¿Cómo puede el impacto del nuevo sistema en cada sitio coordinarse en el ciclo de negocios de este
sitio?

Finalmente, la tarea evalúa los impactos del nuevo sistema y define los planes de retirada y contingencia. Estos
son especialmente importantes en vista de la ley de Murphy: Si algo puede salir mal, saldrá mal. Lo que menos
queremos que ocurra es descubrir que el nuevo sistema no funciona y que no tenemos manera de retornar al
viejo.

Había una pequeña distribuidora de partes eléctricas que estaba cambiando su sistema de despacho de pedidos. La
innovación tecnológica clave era reemplazar un sistema manual de tramitación de pedidos de uso intensivo de
mano de obra por un sofisticado servicio en línea. Después de hacer algunas modificaciones al sistema y de una
razonable cantidad de pruebas y entrenamiento de los operarios del nuevo sistema, se programó el cambio para
un lunes por la mañana. El viernes anterior por la tarde el presidente de la compañía despidió sin previo aviso a
todos los tramitadores de pedidos que no habían sido entrenados para operar el nuevo sistema (el 75% del total),
y el lunes por la mañana el nuevo sistema ¡no funciono! El vendedor del servicio en línea tardo casi un mes en
arreglar el problema. Mientras tanto, los tramitadores de pedidos que habían quedado y otras personas de quienes
se echó mano para que ayudaran no pudieron mantenerse al día con el flujo de pedidos. La bodega fue
subutilizada. Los clientes quedaron descontentos. Y los ingresos de caja bajaron. La compañía tardo varios meses
en recuperarse de este percance, y todo porque no preparo un plan de contingencia y retirada. Al crear sistemas,
siempre se debe esperar lo mejor, pero planificar para lo peor.
2 de enero de 2011

I LUSTRACIÓN 4. M APA CONCEPTUAL DE LA TAREA 5.3.


Universidad Nacional del Santa 10
Etapa 5: Transformación

T AREA 5.4. E VALUAR AL P ERSONAL


Esta tarea evalúa al personal actual en función de sus destrezas, conocimientos, orientación, el grado de
conformismo con el cambio y su aptitud. La evaluación de la actitud es muy importante porque la determinación
de la disposición de cada persona debe basarse en ella misma, no en el cargo que desempeña algunas personas no
están suficiente mente calificadas para su cargo, y otras les sobran calificaciones. Algunas tienen destrezas,
conocimientos y orientación no relacionados con su cargo actual pero muy deseable en otros cargos. La
evaluación de cada persona luego se coteja con los requisitos del cargo y los niveles de rotación de personal
desarrollados en la tarea 4B.4, a fin de identificar las escaseces o excesos de personal y las necesidades de
capacitación.

Puesto que la reingeniería de procesos (RP) habitualmente mejora la eficiencia y eficacia de un proceso y la
productividad de las personas que toman parte en él, en un proceso rediseñado es cierto, en general, que menos
personas puedan manejar la misma cantidad de trabajo. La cuestión entonces viene a ser qué hacer en las que
sobran.

Una de las dificultades de la reingeniería de una organización, proceso por proceso, es que no tenemos un cuadro
general de las necesidades de personal de toda la organización. Podemos encontrarnos que hemos despedido de
un proceso a empleados competentes y tenemos que contratar fuera de la organización para dotar otro proceso.
También, como la reingeniería mejora la eficiencia de operativa de una empresa, con frecuencia encontramos que
la cantidad de trabajo aumenta en lugar de disminuir a medida que la organización tiene más éxito en el mercado.
En estos casos, es posible que nos encontremos con que hemos despedido empleados y luego tenemos que
contratar a otros para el mismo proceso.

Por estas razones, una organización que emprende la reingeniería debe pensarlo mucho antes de desprenderse de
empleados competentes. Y según nuestra experiencia, esto es lo que se está haciendo en organizaciones que
comienzan con reingeniería. Las organizaciones que comienzan con reducir su tamaño (o “rectificar el tamaño”
como dice el eufemismo de moda) a veces rediseñar a posteriori para tratar de restablecer la eficiencia perdida con
los recortes del personal; pero hay pruebas considerables que las organizaciones que recortan personal sin cambiar
antes la manera de hacer el trabajo encuentran que las dotaciones de personal vuelven a subir a los niveles
anteriores.

Pero si una organización resuelve conservar empleados más allá del nivel que se necesita para el proceso ¿qué
hace con ellos? La respuesta a esta pregunta depende en gran parte a la estrategia de la compañía. Si la estrategia
consiste en concentrarse, disminuir tamaño, ceder participación del mercado, salirse de algunos negocios,
entonces puede ser apropiado disminuir el número de empleados. Por el contrario, si la estrategia es de expansión,
de crecer, de entrar en nuevos mercados, de ampliar la partición de mercado, entonces posiblemente es
inapropiado reducir al personal. Aun cuando a corto plazo parezca más rentable prescindir de ciertos empleados y
al mismo tiempo contratar a otros, esto puede ser una anomalía de nuestros sistemas contables.

Nuestros sistemas contables tratan a las personas como si fueran gastos, cuando en realidad son activos. La
experiencia en el oficio, el entrenamiento y la educación que damos a nuestros empleados son en verdad
2 de enero de 2011

inversiones, no gastos. Por eso los empleados se hacen más productivos a medida que envejecen, y esa es la razón
por la cual pagamos más por antigüedad. Si tuviéramos que tratar a los empleados como activos en los libros de la
organización, estaríamos mucho menos dispuestos a despedirlos. Pero ¿qué hacemos con ellos mientras
esperamos que el nivel de negocios aumente? No hay una respuesta única pero damos a continuación unas
sugerencias:

 TRANSICIÓN. A menudo, cuando se rediseña un proceso al principio las medidas de rendimiento se


mueven en dirección contraria a lo que se esperaba. En otras palabras, la productividad baja, lo mismo
que la calidad, mientras los costos suben. La razón es que por lo general se solicita un periodo de
Universidad Nacional del Santa 11
Etapa 5: Transformación

transición después de efectuar cualquier cambio significativo y antes de que el nuevo proceso se
estabilice.
 PROMOCIÓN. Utilizar a los empleados libres para estimular más negocios o nuevos negocios.
 COMPARTIR OFICIOS. En lugar de reducir el número de personas, reducir el empleo equivalente a
jornada completa haciendo que las personas compartan sus oficios. Muchos empleados recibirán con
agrado el tiempo libre adicional, especialmente si no va acompañado de una reducción proporcional de
paga.
 CAPACITACIÓN CRUZADA. Capacitar a las personas para desempeñar más de un cargo.
 EMPRESARIADO INTERNO. Estimular a los empleados para que encuentren nuevas oportunidades
de negocios para la compañía.
 ACELERACIÓN DE LA REINGENIERÍA. Utilizar a los empleados libres para dotar a los equipos de
rediseño.

A pesar de todas estas tácticas, a menudo es reducir el personal, y entonces la cuestión es a quien conservar. El
primer criterio debe ser la aptitud de una persona para el empleo rediseñado. El segundo criterio debe ser la
conformidad de una persona con el cambio, si lo acoge con entusiasmo o con temor. Una vez que sepamos
quienes van a manejar el proceso rediseñado y conozcamos sus actuales destrezas, conocimientos y orientación en
comparación con los requisitos del cargo, podemos formular las necesidades de capacitación de cada persona. Las
necesidades de capacitación de esta tarea se usan luego para finalizar los componentes del plan de estudios y
entrenamiento y para asignar individuos a cursos específicos.

En ABC Toy Company, el equipo de reingeniería evaluó las destrezas y las aptitudes corrientes de cada una de las personas
afectadas frente a los requisitos del proceso Despachar Pedido. La figura muestra los resultados de esa evaluación para la
posición de representante de servicio al cliente (RSC).En la evaluación del personal, el equipo se valió de un simple sistema
triar para disponer de las personas: conservarlas, despedirlas o dudoso. El primer grupo recibirá capacitación. El segundo
grupo seria reasignarlo a otro proceso o colocarlo por fuera. Y el tercer grupo seria capacitado, evaluado de nuevo y luego
colocarlo en uno u otro de los dos grupos anteriores.

Si en el primer grupo quedaban más de las personas que las suficientes para dotar el proceso, algunas de ellas también
tendrían que ser despedidas. En este caso, el criterio primario de retención seria el grado en que cumplían con los requisitos
del cargo y su conformidad con el cambio.

Basándose en la evaluación de las necesidades de capacitación, el equipo de reingeniería formulo un plan de estudio que
contaba con los siguientes cursos:

 Introducción a ABC Toy Company. Comprende los productos. Los clientes, la historia y proporciona una visión
global de manufactura y distribución.
 Servicio al cliente. Comprende necesidades delos clientes, destrezas en relaciones interpersonales, telefónicas, de
negociación, facilitación, y una introducción a la gerencia de crédito.
 Tecleo básico.
2 de enero de 2011

 Tecleo intermedio.
 Prevención y solución de problemas. Comprende métodos analíticos y controles.
 Trabajo en equipo.
T ABLA 1. D ESPACHAR P EDIDOS : EVALUACION PERSONAL PARA LA POSICION DE RSC.

DESTREZAS CONOCIMIENTOS ORIENTACIÓN

CLAVE

Relaciones interpersonales
A = Alto

Operación de bodegas

Métodos de embarque
EVALUACIÓN

Gerencia de criterios
Manejo de teclados
P = Pobre

Atención telefónica

Actividad/Proyecto
Línea de productos
Carretilla elevadora
M = Moderado

De negociación
Bu = Bueno
B = Bajo

Producción

Facilitación
Analíticas

Personas
Pr = Promedio

Clientes

Control
Requisitos A A A M B M B B M B A M M A Pr

Actual M B B B M M M A Pr
M. Smith
Aptitud Pr Pr Pr Pr Bu Bu Bu Bu Pr Bu Pr Capacitar
Actual A B M B M M B A B B B Pr
I. Jones
Aptitud Bu Bu Bu Pr Pr Pr Pr Bu Capacitar
Actual B M A B B B B A A Pr
L. Brown
Aptitud P Pr P P Pr Bu P P Reasignar o colocar por fuera
Actual A A B B M B B M B A A Pr
W. Williams
Aptitud Bu Bu Pr Pr Capacitar
Actual M B M M A M B B M B B M Pr
S. Henderson
Aptitud Pr Bu Pr Pr Bu Bu Pr Bu Bu Pr Capacitar
Actual A B A M B M B B Pr
w. Clinton
Aptitud Pr Pr Pr Bu Pr Pr P Capacitar y volver a evaluar
I LUSTRACIÓN 5. M APA CONCEPTUAL DE LA TAREA 5.4.

T AREA 5.5. C ONSTRUIR S ISTEMA


Esta tarea produce una versión del nuevo proceso lista para operaciones. Cuando el proceso se basa en un sistema
individualizado, esta tarea incluye desarrollo y prueba de base de datos, desarrollo y prueba de sistemas y
procedimientos, y documentación. Cuando el proceso se basa en un paquete, esta tarea incluye instalación y
modificación o extensión del paquete, y su prueba. En ambos casos, la tarea comprende también conversión de
datos.

La prueba es generalmente un procedimiento de múltiples pasos y niveles, en que se pasa a ensayar las unidades
más pequeñas del sistema a ensayar unidades cada vez más grandes hasta que todo el sistema se pone a prueba
como una unidad. Aún entonces, lo común es llevar a cabo nuevas pruebas a fin de determinar el
comportamiento del sistema bajo tensión, comparar los resultados del nuevo sistema con los del anterior, y
desarrollar confianza del cliente con el sistema.

Todas las actividades incluidas en esta tarea deben haber sido planificadas en tareas anteriores.

T AREA 5.6. C APACITAR AL P ERSONAL


Esta tarea da capacitación en la operación, la administración y el mantenimiento del nuevo proceso, justo a
tiempo para que el personal asuma sus nuevas responsabilidades. Incluye igualmente instrucción particular cuando
los empleados asumen dichas responsabilidades por primera vez. Queremos capacitar a los empleados justo a
Universidad Nacional del Santa 1
Etapa 5: Transformación

tiempo porque demasiado temprano significa que se les olvidará lo que se les enseño, y demasiado tarde significa
que no estarán preparados para hacer frente a sus responsabilidades.

I LUSTRACIÓN 6. M APA CONCEPTUAL DE LA TAREA 5.5.

A veces instruimos a las personas para trabajar con el nuevo sistema mientras éste está todavía siendo sometido a
pruebas. Esto les da a los empleados tiempo adicional para familiarizarse y aprender a manejarlo antes que tener
que emplearlo “en vivo”, y a quienes lo desarrollan les ofrece casos adicionales de prueba y no planificados para
evaluar. Pero el sistema debe estar en un estado razonablemente bueno antes de permitir a los empleados trabajar
con él, pues de otra manera se corre el riesgo de que se desanimen.

T AREA 5.7. H ACER P RUEBA P ILOTO DEL N UEVO P ROCESO


Esta tarea pone en operación el nuevo proceso en un área limitada a fin de identificar mejoras o correcciones
necesarias, sin correr el riesgo de una implantación total.
2 de enero de 2011

T AREA 5.8. R EFINAMIENTO Y T RANSICIÓN


Esta tarea corrige las fallas que se descubran en la operación piloto e implanta el nuevo proceso en una forma
controlada, de acuerdo con el plan de lanzamiento desarrollado en la tarea 5.3.
Universidad Nacional del Santa 2
Etapa 5: Transformación

I LUSTRACIÓN 7. M APA CONCEPTUAL DE LA TAREA 5.6.

T AREA 5.9. M EJORA C ONTINUA


La mejora de un proceso es continua, no porque se haga en todos los instantes sino porque se hacen mejoras en
todo intervalo de tiempo; pero “mejora continua” es el término que se emplea en la literatura sobre la materia y es
el que nosotros usaremos.

Con frecuencia se pregunta si la reingeniería es un programa permanente para las organizaciones. Ciertamente,
algunos autores quisieran hacernos creer que lo es; pero nosotros no estamos de acuerdo. Creemos que la
reingeniería es un proceso demasiado difícil y penoso para emprenderlo si no existen muy buenas razones para
ello. Si una organización identifica correctamente sus objetivos y sus procesos, evalúa correctamente el impacto de
cada proceso en sus objetivos y la consiguiente oportunidad de contribuir al negocio rediseñando los procesos
estratégicos de valor agregado, y luego desarrolla y realiza una visión para el rendimiento trascendental del
proceso, lo único que le queda por hacer es incorporar mejora continua en el proceso. Entonces la organización
no debe tener que rediseñar, a menos que nuevamente encuentre un cambio en su estrategia de negocios o en el
ambiente.

La reingeniería puede convertirse en un programa permanente para algunas organizaciones porque tienen muchos
procesos distintos que rediseñar, por ejemplo cuando una empresa se compone de muchas unidades diversas. Y
algunas organizaciones pueden verse en el caso de rediseñar repetidas veces porque están en una industria que
2 de enero de 2011

encuentra cambios frecuentes, por ejemplo en tecnología, reglamentación o competencia. Pero la mayoría de las
compañías no deben estar obligadas a rediseñar muy a menudo. Para ellas basta con mejora continua.

Robert B. Reich, Secretario del Trabajo en la administración Clinton, escribió un artículo muy interesante titulado
“Entrepreneurship Reconsidered – The Team as Hero”, en el número de Hardvard Business Review
correspondiente a mayo/junio de 1987, en que considera la cuestión de por qué tantos productos inventados por
estadounidenses ha sido aprovechados más bien por otros países. Entre esos productos se cuentan transistores,
televisión en colores, robots, videograbadoras de casete, hornos básicos de oxígeno, fundidoras continuas de
acero, hornos de microondas, maquinas estampadoras de automóviles, maquinas herramientas computarizadas y
Universidad Nacional del Santa 3
Etapa 5: Transformación

circuitos integrados. Reich atribuye esto al hecho de que los competidores extranjeros, en particular el Japón,
actuaron más rápida y eficientemente para trasformar ideas en productos incrementalmente mejores, en otras
palabras mejora continua. Y la razón, según Reich, es:

I LUSTRACIÓN 8. M APAS CONCEPTUALES DE LAS TAREAS 5.7 Y 5.8.


2 de enero de 2011

El viejo mito estadounidense todavía dominante comprende a dos factores: héroes empresariales y
zánganos industriales – los inspirados y los sudados.
 “En el mejor de los casos, ellos (los trabajadores) hacen un esfuerzo honrado para ejecutar el gran diseño
del héroe empresarial. En el peor de los casos, exigen mejores jornales y prestaciones por menos trabajo,
hacen el mínimo que se espera de ellos o funcionan como burócratas irresponsables empantanados en
los procedimientos operativos estándar”.
Universidad Nacional del Santa 4
Etapa 5: Transformación

En otros términos, las compañías estadounidenses reservan el derecho y la obligación de mejorar productos y
servicios a relativamente pocos trabajadores, mientras que sus competidoras extranjeras logran la participación de
todos los empleados. Esto quiere decir que aprovechan mejor su potencial humano.

El lector debe reconocer que el paradigma que propone Reich es el que representa el diseño social de la RP.
Desde este punto de vista, podemos ver que la razón por la cual los negocios japoneses han tenido tanto éxito es
porque ha sido bien diseñados. Bien sea por suerte, cultura o atención más cuidadosa a los proponentes
estadounidenses de calidad, como J. M. Juran y W.E Deming, los japoneses se han acercado mucho a los procesos
que las compañías de los Estados Unidos han estado buscando alcanzar por medio de la reingeniería.

En Norteamérica, la mejora continua es un acto que no es natural. Si se las deja solas, las organizaciones siguen
inconscientemente las prácticas del pasado, sin cuestionar nunca si hay una manera mejor de hacer las cosas. Por
eso la RP entraña tan ricas oportunidades. Pero con solo haber rediseñado un proceso no hemos superado
automáticamente la tendencia a dejar las cosas como están. Si queremos mejora continua, es preciso incorporara
en el proceso los medios de alcanzarla.

Para que tenga lugar la mejora continua del proceso, hay que cumplir tres requisitos:

1. Al personal del proceso hay que darle metas claras de rendimiento, medidas de realización de las metas e
información sobre los valores actuales y pasados de esas medidas.
2. Hay que dar al personal del proceso las herramientas necesarias para efectuar cambios de rendimiento.
3. Hay que dar al personal del proceso responsabilidad, autoridad e incentivos para mejorar el rendimiento.

Los dos primeros requisitos se estudiaron en la tarea 4A.3: Instrumentar e Informar. Los dos últimos requisitos se
estudiaron en la tarea 4B.1 Facultar al Personal que tiene Contacto con el Cliente. Y el tercer requisito se estudió
en la tarea 4B.11 Diseñar Incentivos.

La RP proporciona el contexto técnico y social para la mejora continua. Por el aspecto social, les da a empleados
facultados y motivados la capacidad de aportar todo lo que contiene su potencial humano. Por el aspecto técnico,
suministra la información y las herramientas para evaluar el rendimiento actual y mejorarlo.

Una nota final sobre diseño técnico. Como una de las palancas del rendimiento del proceso es el uso de la
tecnología, mejora continua significa la implementación de sistemas sucesivamente mejores. Un requisito previo
para esto es un ambiente de prueba de sistemas que suministre un vehículo para mejora progresiva. Tal vehículo
debe comprender:

 La capacidad de acumular casos de prueba y situaciones interesantes para ejercitar el sistema.


 Pruebas regresivas para asegurar que problemas corregidos anteriormente no se repitan.
 Establecimiento de índices básicos de defectos y vigilancia de cambios.
 Aplicación automática de casos de prueba y comparación de los resultados de las pruebas.

Estas capacidades se encuentran comúnmente en las compañías de desarrollo de software y las de contratistas
2 de enero de 2011

para aeroespacial y defensa, pero las demás organizaciones, por lo general, carecen de ellas.
Universidad Nacional del Santa 5
Etapa 5: Transformación

I LUSTRACIÓN 9. M APA CONCEPTUAL DE LA TAREA 5.9.


2 de enero de 2011