etapa 5 - transformacion

Etapa 5: Transformación

U n i v e r s i d a d N a c i o n a l d e l

S a n t a

F a c u l t a d d e I n g e n i e r í a

E . A . P . d e I n g . D e S i s t e m a s

R e i n g e n i e r í a

0 2 / 0 1 / 2 0 1 1

Chávez Zapata Deybee

Muñoz Aleman Jonathan

Quispe Laveriano Luis

Ramos Ramírez Yaser

Salirrosas Moreno Patricia

El propósito de esta etapa es realizar la visión del proceso

implementando el diseño producido en la etapa 4.

Universidad Nacional del Santa Etapa 5: Transformación

1

2

de

e

ne

ro

d

e

20

11

CONTENIDO 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

ILUSTRACIONES Ilustración 1. Mapa conceptual de la introduccion. ............................................................................................................... 4

Ilustración 2. Mapa conceptual de la tarea 5.1. ....................................................................................................................... 7






Ilustración 8. Mapas conceptuales de las tareas 5.7 y 5.8. ..................................................................................................... 3


TABLAS Tabla 1. Despachar Pedidos: evaluacion personal para la posicion de RSC. ..................................................................... 0


2

2

de

e

ne

ro

d

e

20

11

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

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


3

2

de

e

ne

ro

d

e

20

11

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.

TAREA 5.1. COMPLETAR EL DISEÑO DEL SISTEMA 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.

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


4

2

de

e

ne

ro

d

e

20

11

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.

ILUSTRACIÓN 1. MAPA 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

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.


5

2

de

e

ne

ro

d

e

20

11

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.

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.


6

2

de

e

ne

ro

d

e

20

11

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.

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.


7

2

de

e

ne

ro

d

e

20

11

ILUSTRACIÓN 2. MAPA CONCEPTUAL DE LA TAREA 5.1.

TAREA 5.2. EJECUTAR DISEÑ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

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


8

2

de

e

ne

ro

d

e

20

11

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.


TAREA 5.3. DESARROLLAR PLANES DE PRUEBAS Y DE

INTRODUCCIÓ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

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.


9

2

de

e

ne

ro

d

e

20

11

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.



10

2

de

e

ne

ro

d

e

20

11

TAREA 5.4. EVALUAR AL PERSONAL 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

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


11

2

de

e

ne

ro

d

e

20

11

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.

Tecleo intermedio.

Prevención y solución de problemas. Comprende métodos analíticos y controles.

Trabajo en equipo.

TABLA 1. DESPACHAR PEDIDOS: EVALUACION PERSONAL PARA LA POSICION DE RSC.

CLAVE A = Alto P = Pobre M = Moderado Bu = Bueno B = Bajo Pr = Promedio

DESTREZAS CONOCIMIENTOS ORIENTACIÓN

EVALUACIÓN

Rel

acio

nes

in

terp

erso

nal

es

Man

ejo

d

e t

ecla

do

s

Ate

nci

ón

te

lefó

nic

a

De

neg

oci

ació

n

An

alít

icas

Car

reti

lla e

levad

ora

Lín

ea d

e p

rod

uct

os

Op

erac

ión

de

bo

deg

as

Ger

enci

a d

e cr

iter

ios

Clie

nte

s

Mét

od

os

de

emb

arque

Per

son

as

Pro

ducc

ión

Co

ntr

ol

Fac

ilita

ció

n

Act

ivid

ad/

Pro

yect

o

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

M. Smith

Actual M B B B M M M A Pr

Aptitud Pr Pr Pr Pr Bu Bu Bu Bu Pr Bu Pr Capacitar

I. Jones

Actual A B M B M M B A B B B Pr

Aptitud Bu Bu Bu Pr Pr Pr Pr Bu Capacitar

L. Brown

Actual B M A B B B B A A Pr

Aptitud P Pr P P Pr Bu P P Reasignar o colocar por fuera

W. Williams

Actual A A B B M B B M B A A Pr

Aptitud Bu Bu Pr Pr Capacitar

S. Henderson

Actual M B M M A M B B M B B M Pr

Aptitud Pr Bu Pr Pr Bu Bu Pr Bu Bu Pr Capacitar

w. Clinton

Actual A B A M B M B B Pr

Aptitud Pr Pr Pr Bu Pr Pr P Capacitar y volver a evaluar


TAREA 5.5. CONSTRUIR SISTEMA 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.

TAREA 5.6. CAPACITAR AL PERSONAL 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


1

2

de

e

ne

ro

d

e

20

11

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.


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.

TAREA 5.7. HACER PRUEBA PILOTO DEL NUEVO PROCESO 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.

TAREA 5.8. REFINAMIENTO Y TRANSICIÓ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.


2

2

de

e

ne

ro

d

e

20

11


TAREA 5.9. MEJORA CONTINUA 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

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


3

2

de

e

ne

ro

d

e

20

11

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:

ILUSTRACIÓN 8. MAPAS CONCEPTUALES DE LAS TAREAS 5.7 Y 5.8.

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


4

2

de

e

ne

ro

d

e

20

11

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

para aeroespacial y defensa, pero las demás organizaciones, por lo general, carecen de ellas.


5

2

de

e

ne

ro

d

e

20

11


etapa 5 - transformacion

Documents