|
|
La tecnolog�a de objetos es un enfoque dirigido a crear Sistemas de Informaci�n en base a componentes que pueden ser canibalizados o extra�dos de sistemas existentes, y reagrupados para producir nuevos Sistemas. Estos componentes se conocen como objetos. Resulta interesante que este nuevo enfoque respecto a las Tecnolog�as de la Informaci�n va en apoyo de muchas de las ideas que est�n detr�s de la reingenier�a BPR. En lugar de examinar los beneficios de un enfoque de tecnolog�a de objetos en relaci�n con el software, en este art�culo se analizan los beneficios y las sinergias resultantes de utilizar la tecnolog�a de objetos en el contexto de programas BPR y BRE.
Una de las caracter�sticas b�sicas de la reingenier�a BPR es que observa o analiza la empresa en t�rminos de procesos que cortan las funciones tradicionales de los departamentos. Esto se consigue observando internamente los departamentos funcionales monol�ticos y encadenando esas actividades entre los diversos departamentos, para culminar con el suministro de valor a los clientes o con la obtenci�n de valor de los proveedores.
Los sistemas de Informaci�n tradicionales se han inclinado sobre todo por unidades funcionales monol�ticas, dando lugar a aplicaciones que son ellas mismas monol�ticas. En contraste, los sistemas orientados a objetos contienen conjuntos de objetos en copperaci�n, que pueden ser empaquetados en aplicaciones y ser compartidos por �stas. Estos objetos pueden ser grandes o peque�os, y tan sencillos o complejos como la actividades que automatizan o soportan.
En �ltima instancia, los sistemas orientados a objetos desechar�n el bagaje funcional de las aplicaciones y se concentrar�n en suministrar objetos con los que los usuarios deber�n interactuar en alg�n momento durante un proceso comercial, bien para realizar alg�n c�mputo o para extraer/manipular alguna informaci�n. El fraccionamiento de la estructura monol�tica de las aplicaciones tendr� efectos profundos en la forma en que se definan los Sistemas de Informaci�n, en c�mo se realice su reingenier�a, y en c�mo sean construidos. A continuaci�n se analiza con m�s detalle cada una de estas �reas.
El cambio desde una visi�n funcional a una visi�n de proceso plantea nuevos requerimientos respecto a la forma en que se especifican y dise�an Sistemas. Ya no ser� suficiente con descomponer funcionalmente la l�gica de una aplicaci�n, manteni�ndola separada de los datos sobre los que act�a. Lo que se necesita es un enfoque en la creaci�n de modelos que pueda ser utilizado tanto para la conversi�n o mapping de procesos comerciales como para modelizar los objetos necesarios para el soporte de esos procesos. La tarea cambiar�, desde el soporte de una funci�n comercial a soportar un flujo de trabajo o workflow a lo largo de un proceso comercial. Los sistemas workflow convencionales, que intentan orquestar el trabajo entre aplicaciones monol�ticas y tareas manuales, no podr�n en �ltima instancia ofrecer la flexibilidad que requieren las iniciativas BPR. En contraste, los Sistemas creados utilizando objetos est�n fundados inherentemente en un modelo workflow expl�cito que anima a los dise�adores de Sistemas a distribuir el trabajo entre m�ltiples objetos que act�an en copperaci�n.
La tecnolog�a de orientaci�n a objetos ofrece t�cnicas de modelizaci�n que permiten definir objetos y relacionarlos de manera que puedan desarrollarse tanto procesos comerciales como Sistemas de informaci�n. Como existe un lenguaje uniforme para expresar procesos comerciales y procesos de Informaci�n es posible establecer una relaci�n entre ambos.
As�, los procesos comerciales pueden actuar interactivamente con objetos software, y el modelo de workflow puede establecerse expl�citamente de manera que muestre los cambios entre tareas manuales y autom�ticas.
La utilizaci�n de t�cnicas de modelizaci�n para describir empresas y actividades comerciales no es nueva, y ya se han utilizado t�cnicas de modelizaci�n de datos tradicionales para crear modelos de empresa. Sin embargo, a diferencia de los enfoques tradicionales, las t�cnicas orientadas a objetos no obligan a quienes crean los modelos de procesos comerciales a dividir sus modelos artificialmente en datos y procesos, sino que los objetos contienen todos los aspectos de los datos y de su comportamiento, y pueden utilizarse para representar entidades comerciales est�ticas, como departamentos, tareas comerciales como aprobaciones de cr�ditos, y subprocesos como tramitaci�n de pedidos. Una consecuencia importante de esta aproximaci�n de modelado uniforme es que, con le tiempo, el ajuste entre el funcionamiento comercial y los Sistemas de Informaci�n se mejorar�. Es este aspecto de reconfigurabilidad el que est� posicionando a los proyectos BPR como una ventaja comercial progresiva, en lugar de como los puntos de revoluci�n aislados que eran percibidos hasta ahora.
Los cambios incrementales en los procesos comerciales quedar�n reflejados en cambios en el modelo de objeto comercial y pueden dar lugar a cambios en el modelo de objeto de software. Los cambios radicales en los procesos comerciales pueden dar lugar a la creaci�n de modelos de objetos comerciales y de software radicalmente diferentes. Tambi�n aqu�, es posible reconstituir los modelos reutilizando objetos que hayan sido previamente definidos y reorquestando la forma en que act�an interactivamente entre s�. Adem�s, pueden introducirse nuevos objetos que representen nuevas pr�cticas comerciales, y relacionarlos con objetos antiguos.
Para este proceso de reutilizaci�n de modelos de objetos existentes es de importancia cr�tica la estructuraci�n o empaquetamiento y la gesti�n de toda la variedad y n�mero de objetos. Por ejemplo, resultar�a inmanejable considerar a cada objeto comercial como un tarea elemental dentro de un proceso comercial. Las t�cnicas de modelizaci�n de objetos permiten estructurar los objetos como componentes de otros objetos (acumulaciones) y tambi�n permiten que los objetos sean refinamientos u optimizaciones de otros objetos. Estos dos mecanismos de estructuraci�n hacen posible crear y desarrollar modelos de objetos en formas que resulten m�s �tiles y significativas.
La acumulaci�n o suma de objetos permite agruparlos para formar objetos mayores, mientras que el refinamiento de los objetos hace posible la portabilidad de modelos de objetos, bien entre empresas y organizaciones de un mismo sector, o entre organizaciones de diferentes sectores. As�, un modelo de objeto que representase la atenci�n a clientes en el sector hotelero, si fuera lo suficientemente general podr�a ser refinado por dos cadenas de hoteles para introducir pr�cticas y conceptos comerciales espec�ficos, o podr�a ser utilizado por una organizaci�n (tambi�n con los refinamientos apropiados) en el sector de los viajes de empresa.
En t�rminos de reingenier�a comparar procesos comerciales dentro de sectores y entre sectores es un medio importante de mejoras en reingenier�a. La entrega de modelos de objetos comerciales gen�ricos con sus correspondientes modelos software permitir� a las empresas una r�pida reingenier�a de los sistemas de Informaci�n que soportan los procesos comerciales. En el caso de la reingenier�a BRE, es decir, los programas de reingenier�a comercial (en los que las empresas consideran la posibilidad de pasar a nuevas actividades), resulta a�n m�s atractiva la utilidad de los modelos de objetos comerciales est�ndar para el desarrollo de nuevos Sistemas.
Para el �xito de la reingenier�a es de importancia crucial el proceso de ingenier�a. Muchos procesos comerciales son el resultado de una simple evoluci�n en el tiempo, y no han sido objeto de ingenier�a alguna, por lo que con frecuencia surge la confusi�n entre qu� pasos de proceso existen y c�mo se ejecutan esos pasos. En la mayor�a de los enfoques BPR existe una primera etapa en la que se separa el qu� del c�mo de los procesos comerciales.
La utilizaci�n de t�cnicas de modelizaci�n de objetos en este proceso resulta �til, ya que la separaci�n entre lo que hace un objeto y c�mo lo hace es fundamental en la definici�n de todas las descripciones de objetos. As�, tanto los modelos de objetos comerciales como los modelos de objetos de software heredan esta separaci�n. Por otra parte, esta separaci�n permite adoptar un enfoque elegante para una mejora permanente de la eficiencia de los Sistemas de Informaci�n que soportan los procesos comerciales. Seg�n van apareciendo formas de implementar software, pueden introducirse una a una sin necesidad de producir alteraciones en todo el sistema.
En el caso de los objetos de software, la separaci�n entre lo que hace un objeto y c�mo lo hace ofrece tambi�n otros beneficios dentro del contexto de la creaci�n de Sistemas. La organizaci�n OMG ha especificado mecanismos tecnol�gicos (conocidos como CORBA, Common Object Request Broking Architecture) que permiten a los objetos de software interactuar unos con otros en base a un m�todo est�ndar (conocido como IDL, Inteface Definition Language) capaz de describir lo que hace un objeto independientemente de c�mo lo hace. Esto significa que pueden adquirirse objetos de software procedentes de m�ltiples fuentes sin preocuparse por la incompatibilidad en la implantaci�n, y que en las implantaciones de objetos de software no es necesario utilizar lenguajes orientados a objetos, lo que significa a su vez que el software antiguo tiene el potencial de ser reutilizado si puede ser descrito utilizando el lenguaje IDL. Esto permitir� a las empresas concentrarse en desarrollar software para obtener una ventaja competitiva e integrarlo con software corriente adquirido y adaptable a medida de las propias necesidades o con sistemas antiguos ya existentes.
Al alcanzarse una masa cr�tica en el n�mero de empresas y organizaciones que desarrollan Sistemas de Informaci�n utilizando objetos de software, tambi�n ser� posible la interfuncionalidad o interoperabilidad con Sistemas de proveedores y clientes. Este nivel de interfuncionalidad permitir� la reingenier�a de Sistemas de cara a un redise�o de la red comercial, en que las empresas deciden colaborar con los proveedores o con los clientes con el fin de modificar los l�mites y fronteras de sus procesos comerciales internos.
Esto podr� requerir una ampliaci�n de los procesos comerciales con el fin de comprar directamente a los proveedores, por ejemplo bajo un m�todo JIT Just In Time). Alternativamente, puede requerir tambi�n la contrataci�n de procesos comerciales permitiendo a los clientes pedir productos o utilizar servicios directamente, como en el caso de las operaciones bancarias desde el hogar. Se conocen casos de fusiones y adquisiciones de empresas que han fracasado por la incompatibilidad de sus Sistemas de Informaci�n.
Eliminar procesos comerciales y someterlos a reingenier�a con el fin de obtener una ventaja competitiva conducir� a la necesidad de una reingenier�a de los Sistemas de soporte. La tecnolog�a de objetos reduce al m�nimo el esfuerzo de desarrollo para nuevos sistemas al permitir la reutilizaci�n de componentes de sistemas antiguos mientras se permite la inclusi�n de nuevos componentes.
Si se est� considerando acometer la reingenier�a BPR, deber�n analizarse los beneficios de la tecnolog�a de orientaci�n a objetos o correr el riesgo de que los Sistemas de Informaci�n se conviertan en una carga para la efectividad en la implantaci�n de procesos comerciales que hayan sido objeto de reingenier�a.
Finalmente, preg�ntese qu� pasar� despu�s del proyecto BPR inicial y c�mo mantendr� la coordinaci�n entre las mejoras continuas del proceso comercial y los Sistemas de Informaci�n existentes.
