Professional Documents
Culture Documents
1. INTRODUCCIN
Ha llegado el momento de cambiar estructura, administracin y desempeo de los negocios: entramos en el siglo XXI con empresas creadas en el siglo XX con las ideas del
siglo XIX. Estos cambios estn motivados, entre otras razones, por la fuerte variacin que
se ha producido en los clientes, en la competencia y en el propio proceso de cambio.
Los clientes exigen productos y servicios diseados a medida. Ya no se trata con un
mercado masivo que est dispuesto a absorber cualquier producto, si no que saben lo que
quieren, cundo lo quieren, bajo qu condiciones y cunto estn dispuestos a pagar por
ello. Otro aspecto importante es la naturaleza del cambio, que se ha convertido en algo
general y permanente. Este cambio continuo ha reducido el ciclo de vida de los producESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
106
498/00
tos, as como el tiempo disponible para disear e introducir otros nuevos [KOTLER, 95]
[SERRANO, 94].
El problema actual es que muchas empresas parecen estar en decadencia. Los motivos a los que se achaca son muy diversos. Unos piensan que se debe a factores externos,
sobre los que no se tiene control. Otros, a que no se da con el producto adecuado. Hay
quienes deciden plantear nuevas estrategias corporativas para salir de la crisis, como
cambios de mercado, pasarse a otro negocio o incluso manipular los activos. Tambin
estn los que lo atribuyen a deficiencias en la administracin y piensan que la solucin es
hacer cambios en la gestin de la empresa, variando su estructura departamental o el estilo de direccin. Muchos ven en la automatizacin el remedio a sus problemas.
Para determinar qu ocurre realmente y cmo solucionar estos problemas hay que fijarse en las empresas que tienen xito: son las que hacen mejor su trabajo. Lo que se
debe mejorar es, entonces, la forma en la que se realizan las distintas tareas que se llevan
a cabo en la empresa.
2. REINGENIERA DE LA EMPRESA
2.1. Concepto de reingeniera
La reingeniera propone obtener una visin de la empresa a partir de sus procesos.
Es la revisin fundamental y el rediseo radical de procesos para alcanzar mejoras es pectaculares en medidas crticas y contemporneas de rendimiento, tales como costes,
calidad, servicio o rapidez [HAMMER, 94], [P REZ, 96]. Esta definicin se basa en el
concepto de proceso. Un proceso es un conjunto de actividades que recibe una o ms entradas y crea un producto de valor para el cliente [FERNANDEZ, 96], [KUBECK, 95] [OULD,
94]. Esta definicin es muy til sobre todo a la hora de redisear los procesos: todo aquello que no aporte algo de valor al producto, o al menos no sea considerado como algo
imprescindible, no debera formar parte del proceso rediseado. Esto conlleva implcitamente una reduccin en las tareas de control. Otra implicacin de la visin de la empresa
a travs de sus procesos es la abolicin de la divisin de stos en tareas ms sencillas
(ALAN SMITH, 1776), que tiende a perder de vista el objetivo global. Las empresas rediseadas suelen necesitar GENERALISTAS, no ESPECIALISTAS.
La reingeniera consiste en empezar de cero, abandonando reglas anticuadas y supuestos fundamentales heredados. Este sistema para reformar la empresa tiene una serie
de caractersticas comunes aadidas: ambicin (no busca mejoras pequeas), quebrantamiento de reglas y uso creativo de la informtica.
Dentro de esta revolucin de las empresas, la Informtica tiene un papel fundamental
[WILEY, 94], [HAMMER, 94]. En primer lugar, no se debe confundir los cambios tecnolESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
499/00
107
gicos con la automatizacin. Usar nuevas tecnologas debe suponer un cambio en la forma de trabajar y en los mtodos empleados. La introduccin de las tecnologas de la informacin ha favorecido la ruptura de una serie de reglas que hasta hace algunos aos se
consideraban inamovibles:
La informacin slo puede estar en un sitio. Ahora, Las bases de datos distribuidas permiten disponer de la informacin all donde es necesaria, sin duplicidad en los datos, manteniendo la informacin dispersa en diversas localizaciones.
Slo los expertos hacen el trabajo complejo. Los sistemas expertos, como
aplicacin de las tcnicas ms novedosas de la Inteligencia Artificial, permiten a
los usuarios consultar a los ordenadores como si de expertos en materias concretas se tratara.
Escoger entre centralizar y descentralizar. La proliferacin de las redes de telecomunicaciones y el gran desarrollo de Internet permite mantener centralizado
slo lo imprescindible y repartir localmente la informacin necesaria, sin perder
las ventajas de cada uno de estos mtodos.
Todo esto conlleva una serie de implicaciones que se deben traducir en un cambio en
el comportamiento y la filosofa de una empresa. Estas implicaciones pueden resumirse
en una: las compaas deben ser flexibles y rpidas en sus reacciones, tal y como exigen
los clientes, la competencia y el mismo proceso de cambio.
2.2. Ingredientes para un proceso de reingeniera formal
Un proceso formal de reingeniera incluye [JACOBSON, 94]:
un proceso para el desarrollo de un sistema de informacin que est realmente integrado en la empresa rediseada. Un sistema as debe construirse en paralelo con
los nuevos procesos de los negocios.
108
500/00
Los procesos son rediseados por un equipo de reingeniera, habitualmente compuesto por gente que procede de distintos mbitos de la empresa. Para que este equipo pueda
realizar su trabajo adecuadamente necesita:
modelos expresivos para la compaa rediseada, que tambin son utilizados por
el personal que construye los sistemas de informacin.
Casos de uso (1). Constituyen una forma natural de identificar los procesos de la
empresa. Los usuarios de la empresa hacen uso de sta a travs de procesos. Cada
va para utilizar la empresa es un caso de uso.
La metodologa orientada a objetos (OO), que se expondr en el siguiente apartado, es excelente para clasificar el trabajo interno de una empresa sus procesos,
productos, servicios, recursos, y cmo estos elementos dependen los unos
de los otros.
El modelo de una empresa rediseada se construye mediante la unin de la reingeniera de la empresa y una metodologa de anlisis y diseo orientado a objetos.
501/00
109
papeles o roles que desempean las personas que interactan con el sistema;
unidades organizativas: estructuras que aglutinan los objetos en entidades de nivel superior;
110
502/00
503/00
111
Un caso de uso es una entidad funcional que representa un proceso en el modelo, visto como la secuencia de mensajes que intercambian el sistema y las entidades que interactan con l (actores), junto con las acciones que realiza el sistema como respuesta a
los estmulos externos. Un actor representa el papel que desempea un elemento externo
al sistema.
Venta por telfono
Comprobar estado
vendedor
Realizar pedido
cliente
Despachar pedido
dependiente
Proporcionar
crdito
supervisor
CLIENTE
Nif: String
Nombre: String
Cuenta corriente: Integer
Realizar Compra ()
Solicitar Crdito (importe: Integer)
Pedir Informacin (tema:String)
Una clase se representa como un rectngulo dividido entres partes. En la primera de ellas
se indica el nombre de la clase, en la segunda sus atributos (indicando su nombre y el tipo de
datos que almacena) y en la tercera los mtodos (su nombre y los argumentos que necesita).
Las clases pueden relacionarse entre s mediante generalizacin o mediante asociacin. La generalizacin permite realizar una clasificacin taxonmica entre clases ms
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
112
504/00
generales y otras ms especficas, consistentes con las primeras y que aaden ms informacin. A la clase general se le denomina superclase y a la especfica subclase. Se representa mediante una flecha que parte de la subclase y termina en la superclase. La aso ciacin es la relacin ms frecuente. Se utiliza para representar cualquier otro tipo de relacin existente entre las clases (es-parte-de, es-un, ). Se representa con una lnea que
une las dos clases relacionadas. A estas lneas se le pueden aadir distintos smbolos que
indican sus propiedades y caractersticas.
3.3.3. Diagrama de secuencia
Muestra cmo interactan entre s los objetos definidos en el modelo, as como los
mensajes que intercambian. Normalmente, cada caso de uso tiene asociado un diagrama
de secuencia que especifica cmo se desarrolla el proceso a lo largo del tiempo.
emisor
centralita
receptor
descolgar
dar tono
marcar n.
encaminar
dar tono
sonar
descolgar
parar tonos
parar timbre
505/00
113
Ntese que tanto el diagrama de secuencia como el de colaboracin expresan informacin similar. Por eso, normalmente, es suficiente construir slo uno de ellos para modelar el sistema. Los diagramas de secuencia muestran de forma explcita el flujo de
mensajes en el sistema, siendo ms adecuados para modelos de tiempo real o escenarios
complejos. Los diagramas de colaboracin muestran relaciones entre los objetos y son
mejores para comprender todos lo efectos que produce un objeto.
3.3.5. Diagrama de transicin de estados
Expresa la secuencia de estados en los que se puede encontrar un objeto durante su
vida en el sistema, desde que se crea hasta que se destruye. Un objeto cambia de estado
como respuesta a un cierto mensaje. Adems, en funcin de su estado actual, el objeto
responder a un tipo de mensaje o a otro. Se representa mediante una mquina de esta dos [HOPCROF, 79], donde los smbolos de estado representan los posibles estados del objeto y las flechas corresponden a las transiciones entre estados.
activo
invlido
15 seg.
marcar
dgito
15 seg.
levantar
auricular
tono de
preparado
marcar dgito
marcando
terminar
marcar
conectando
ocioso
tono de
ocupado
colgar auricular
hablan-
ocupado
receptor
contesta
conectado
sonando
114
506/00
Calcular coste
enviar
[coste 50$]
recibir
507/00
115
mismo, todos los mensajes tienen que estar definidos como mtodos de las clases
que les dan soporte.
4. Un diagrama de transicin de estados por cada clase, aunque en ocasiones puede utilizarse para una jerarqua de generalizacin completa. Muestra tambin los
mensajes que provocan los cambios de estado, definidos en el diagrama de clases.
5. El ltimo es el diagrama de actividad, que muestra con detalle la secuencia de
acciones que se debe seguir para ejecutar un proceso o un mtodo de una clase y
los puntos de sincronismo con las dems tareas (envo/recepcin de mensajes).
Todos estos diagramas constituyen un modelo de la empresa rediseada. Si es necesario, se puede incluso construir un prototipo de sistema de informacin que proporcione
un soporte informtico bsico al modelo inicial. Este modelo es el primer resultado del
equipo de reingeniera, pero no necesariamente el definitivo. Los diagramas se deben revisar, refinndolos ms o corrigiendo y modificando algn componente. El modelo revisado constituye un segundo prototipo de la empresa. Este proceso continua hasta que se
considere que el modelo refleja exactamente la empresa rediseada.
5. EJEMPLO DE APLICACIN
ARIMEZ S.A. es una empresa constructora cuya actividad se centra principalmente
en realizar grandes obras para el sector pblico. Una entidad saca a concurso pblico la
adjudicacin de una obra, publicndolo en el B.O.E. y en el de la provincia, as como en
dos peridicos de tirada nacional. ARIMEZ acude a la administracin correspondiente
para obtener una copia del proyecto para su evaluacin. La oficina tcnica, con el apoyo
del departamento de administracin, lo estudia y confecciona una propuesta, especificando (si procede) una baja en el importe del presupuesto o en tiempo de ejecucin sobre el
proyecto inicial. Esta propuesta se enva en la entidad.
Cuando finaliza el plazo de presentacin de ofertas, la entidad resuelve el concurso
pblico y adjudica la obra a una empresa determinada. En el plazo de 7 das se firma el
contrato, asumiendo la cuanta y duracin especificadas en la propuesta y fijando un calendario para la ejecucin de la obra.
Peridicamente, la entidad supervisa el estado de la obra, realizando una serie de mediciones sobre el volumen de trabajo realizado. Con los resultados de estas mediciones,
se elabora una valoracin y la entidad emite una certificacin y abona a ARIMEZ la cantidad correspondiente. Cuando ARIMEZ concluye la obra, la entidad emite una ltima
certificacin y, en el caso de que se haya ejecutado un volumen distinto al presupuestado, realiza una liquidacin por la diferencia, tras la cual el proyecto se da por concluido.
En ese momento, comienza un periodo de garanta, pasado el cual se archiva el proyecto.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
116
508/00
Confeccionar
propuesta
Entidad
Oficina tcnica
Adjudicar
Certificar
Dpto.
Administracin
Los actores, elementos activos de estos procesos, son: la entidad pblica (externo) y
la oficina tcnica y el departamento de administracin (internos).
5.2. Diagrama de clases
El diagrama de clases muestra todos los objetos, activos o pasivos, que intervienen
en los procesos de ARIMEZ (2). Las clases principales del modelo aparecen agrupadas
en una jerarqua de generalizaciones que tiene el proyecto como superclase. La propuesta es una subclase del proyecto, al que se le aade la baja que oferta la empresa (frecuentemente, expresada en porcentaje). Las propuestas, tras la resolucin del concurso, se
clasifican en acaptadas o rechazadas. Esta clasificacin de las propuestas aparece en el
diagrama como una nueva generalizacin. Tras la firma del contrato, la propuesta adjudicada recibe ms informacin (como la fecha de inicio y la de finalizacin), pasando a ser
una obra en ejecucin. Cuando termina, se le aaden los datos reales de ejecucin y se
archiva. Una obra archivada es a su vez una subclase de la obra en ejecucin.
Los documentos que se generan en el proceso tambin se modelan como clases.
En el caso de ARIMEZ, los nicos documentos que se especifican son las certificaciones y la liquidacin final. Deben asociarse a la clase que los genera (la entidad) y a la
(2) Por motivos de espacio y de complejidad del diagrama, slo aparece el nombre de las
clases y las relaciones que existen entre ellas. Para que el diagrama sea completo, se debe indicar,
para cada clase, todos sus atributos y todos sus mtodos.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
509/00
117
proyecto
1..n.
1..n.
estudia
1..n.
1..n.
elabora
1..n.
elabora
propone
propuesta
evala
1
1 oficina tcnica
1
1
1
rechazada
entidad
1
1
adjudicada
emite
dpto. administracin
cobra
1..n.
certificacin
abona
1..n. 1
1..n.
ejecucin
1
realiza
liquida
1..n.
liquidacin
archivada
clase que los recibe (una obra en ejecucin). Se unen a travs de asociaciones, que se etiquetan con un nombre y una cardinalidad (el nmero de instancias con las que se relaciona).As, una entidad emite una o varias certificaciones (marcado como 1..n), y cada
certificacin slo es emitida por una entidad (marcada como 1).
Por ltimo, deben aparecer los actores del diagrama de casos de uso (3), relacionados
mediante asociaciones con las clases sobre las que interactan directamente.
5.3. Diagrama de secuencia
Cada proceso de ARIMEZ debe tener un diagrama de secuencia o de colaboracin
asociado. La figura muestra el diagrama de secuencia asociado al proceso de certificacin de la obra (ver enunciado). Los menajes muestran el flujo de informacin a lo largo
de este proceso.
En el modelo inicial, la certificacin est unida a la finalizacin de la obra. En un futuro refinamiento, se puede considerar la posibilidad de separar este proceso en dos, uno
dedicado exclusivamente a la certificacin y otro que modela las acciones que se realizan
al finalizar la obra (ltima certificacin, liquidacin y periodo de garanta).
(3) Algunos actores pueden corresponder a entidades externas sobre las que no se desea almacenar ningn tipo de informacin. En ese caso, no aparecen en el diagrama de clases.
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
118
dpto. admn.
ejecucin
certificacin
510/00
entidad
archivada
supervisar
resultado
emitir
abonar
cobrar
liquidar
finalizar
certificar
realizar propuesta
ofertada
adjudicada
adjudicar
en ejecucin
firmar
en garanta
liquidar
rechazar
finalizar
plazo
rechazada
archivada
Una obra arranca en estado proyectada y a medida que le llegan distintos eventos
(realizar propuesta, aceptar/rechazar,) va cambiando de estado. Algunas clases estn
representadas por un nico estado (como la clase adjudicada), pues un evento de cambio de estado hace que tambin cambie de clase (al firmarla, pasa a ser una obra en
ejecucin).
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
511/00
119
rechazada
aceptada
firmar contrato
fin
6. CONCLUSIONES
En el presente artculo se ha descrito cmo aplicar la metodologa orientada a objetos
en el entorno empresarial. El empleo de este tipo de tcnicas permite modelar sistemas
de forma sencilla, sin tener que utilizar artificios y abstracciones complejas. As, no es
necesario disponer de conocimientos informticos profundos para elaborar los diagramas
y construir un sistema de informacin acorde con la realidad de la empresa que se est
modelando. Incluso existen herramientas CASE (4) que traducen los esquemas a cdigo
directamente implementable en un ordenador, generando el software que da soporte al
sistema de informacin.
Las ventajas de emplear los objetos son claras. La ms importante es que se trata de
un modelo formal, es decir, la especificacin del sistema se describe mediante una sintaxis y una semntica formales, basadas en conceptos matemticos, que permite eliminar
ambigedades e inconsistencias en el modelo y que dan rigor y robustez a los sistemas.
Los conceptos que utiliza estn prximos al mecanismo cognitivo humano. Desde el
(4) Computer Aided Sowftare Engineering (Ingeniera del Software Asistida por Computador). Son herramientas que proporcionan un soporte automtico o semiautomtico para las fases
de anlisis y diseo de sistemas informticos, apoyado por controles de coherencia internos, anlisis de los modelos, facilidades de documentacin, etc
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
120
512/00
punto de vista del diseador, ofrecen una visin conjunta de la esttica y la dinmica del
sistema, aportando grandes ventajas sobre los mtodos centrados slo en los datos (modelo entidad-relacin [CHEN, 76]) o en los procesos (anlisis y diseo estructurado
[GANE, 81]). Los modelos que resultan son escalables, simplificando las ampliaciones
sobre el modelo, lo que favorece el ciclo de vida en espiral.
UML proporciona una metodologa que rene los conceptos asumidos por la comunidad orientada a objetos. El resultado es un lenguaje de propsito general, til para redisear los procesos de la empresa y que favorece la comunicacin entre distintos equipos
al facilitar diagramas claros, sencillos, expresivos, flexibles y formales.
7. BIBLIOGRAFA
[BOOCH, 91] BOOCH, G. Object Oriented Design with Applications, Benjamin Cummings Publishing Company (1991).
[BOOCH, 97] BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. Unified Modeling Language
Users Guide, Addison-Wesley (1997).
[CHEN, 76] CHEN, P. The Entity-Relationship Model. Towward a Unified View of
Data, ACM Transactions on Database Systems 1, 1 (Mar. 1976).
[FERNANDEZ, 96] FERNANDEZ, M. A. El Control, Fundamento de la Gestin por Proce sos, ESIC Editorial (1996).
[GANE, 81] GANE C.; S ARSON T. Anlisis Estructurado de Sistemas, Ed. Librera El
Ateneo, (1981).
[HAMMER, 94] HAMMER, M.; CHAMPY, J. Reingeniera de la empresa, Paramn
(1994).
[HOPCROF, 79] H OPCROF, J. Z.; ULLMAN, J. D. Introduction to Automata Theory. Lan guages and Computation, Addison-Wesley (1979).
[JACOBSON, 92] JACOBSON, I. Object-Oriented Software Engineering: An Use Case Dri ven Approach, Addison-Wesley (1992)
[JACOBSON, 94] JACOBSON, I. The Object Advantage, Addison-Wesley (1994)
[JACOBSON, 97] J ACOBSON I.; BOOCH, G.; R UMBAUGH, J. The Objectory Software Deve lopment Process, Addison-Wesley (1997).
[KOTLER, 94] KOTLER, P. Direccin de Marketing, Prentice-Hall (1994).
[KUBECK, 95] KUBECK, L. C. Techniques for Business Process Redesign, JOHN WILEY
& S ONS (1995).
[OULD, 94] OULD, M. A. Business Processes, John Wiley & Sons (1994).
[PASTOR, 93] P ASTOR, O.; SICOL, J. J.; HERRERO, M. Modelos Semnticos y Modelos
Orientados a Objetos, Universidad Politcnica de Valencia (1993).
[PASTOR, 96] PASTOR, O. Anlisis Orientado a Objetos. Conceptos y Metodologas,
Internal Report, Dpto. de Sistemas Informticos y Computacin, Universidad Politcnica de Valencia (1996).
ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
513/00
121