Diseñando Sistemas II: El diseño del sistema

Como ya indicaba en el anterior artículo de este ciclo, quiero recordar que estoy escribiéndolos basándome en mi propia (y dilatada) experiencia y reflejan tan solo ideas generales y prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado.

Así pues, continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez consideramos que la toma de requerimientos ha sido hecha y documentada adecuadamente y el cliente ha dado su visto bueno, comenzaremos con el diseño del sistema de tratamiento de la información. En esta etapa debemos asegurarnos de plasmar en el diseño todos aquellos requerimientos que hayamos sido capaces de conocer, aun cuando se dé el caso frecuente de que no va a ser posible implementar todas las funciones posibles ya que el cliente ha limitado el ámbito de actuación, solicitado un sistema más sencillo y de bajo coste y en este caso hay que recortar el desarrollo hasta donde sensatamente se pueda y limitarlo a la visión del cliente.

Es aquí donde la habilidad del responsable del proyecto debe mostrarse, definiendo las funciones esenciales, las que son convenientes —pero no son esenciales— y otras funciones posibles y deseables que, en una primera versión del sistema, tal vez no podrán implementarse, pero que muy posiblemente serán objeto de posteriores peticiones del cliente para ampliar la funcionalidad del sistema y si hemos sido capaces de prevenir estas circunstancias, será más sencillo satisfacerlas. De este modo, y tal como ya dije en mi artículo anterior, el clásico “esto no me lo habías contado y no está previsto”, quedará sustituido en la mayoría de las veces por “es posible integrar lo que me pides” y la inversión para implementar estas nuevas funcionalidades será menor y más rentable para el proveedor que lo tenía previsto que para aquel que necesita replantearse el diseño del sistema. Para ello, conviene dotar al diseño inicial de ciertos elementos de ajuste y flexibilización en la forma de procesar la información, que más adelante nos van a permitir implementar funciones y controles adicionales sin gran esfuerzo, rentabilizando así la inversión inicial.

¿Cómo se puede llegar a esto? Adquiriendo conocimientos extra durante el diálogo con el cliente, intuyendo lo que no ha dicho y previniendo que suceda. Por ejemplo, identificando los elementos clave que pueden definir el modo de procesar la información y añadiéndolos al sistema como entidades gestionables individualmente. Cuando el interlocutor te dice, tenemos clientes y proveedores —por ejemplo— pero no ha definido clases dentro de ambos, debemos averiguar si hay clientes que requieren procesos específicos o funciones dedicadas a su situación o necesidad y en tal caso prevenir ya que van a haber categorías de clientes y seguramente también de proveedores, así como que clientes o proveedores tendrán ramificaciones en el interior de los procesos. Si nos dice que compran o prestan tal o cual servicio, averiguar cuantas particularidades corresponden a cada uno y cómo se aplican a los clientes y proveedores (tal vez se está haciendo manualmente y bajo la “cultura” de algún empleado experto) y así sucesivamente. Probablemente de pronto el sistema tenga definido un fichero de tipos de cliente, otro de tipos de proveedor, otro de tipos de servicio (distribución), otro de condiciones de facturación, etc., de tal modo que si surgen nuevas combinaciones no hay que tocar programas, solo combinar nuevas entradas en los ficheros. Será importante también establecer relaciones válidas entre los diferentes conceptos, que al final definan las transacciones posibles que el sistema va a ejecutar, de manera que sólo sea posible procesar aquellas combinaciones previamente definidas en tablas de control.

Por citar un ejemplo de lo que propongo, un cliente del sistema de salud no puede recibir un medicamento registrado si no es una farmacia. Por tanto un hospital ha de comprar estos medicamentos a través de su farmacia o de una farmacia externa, pero nosotros no podemos servir ni facturar estos medicamentos a un cliente que no es una farmacia. Las entradas de nuestras tablas reflejarán las relaciones válidas entre tipos de clientes (hospital, clínica, farmacia, etc.) y tipos de productos (producto hospitalario, medicamento no registrado, medicamento registrado, etc.) y de este modo el sistema dará un aviso e impedirá —si se desea— que se asigne inventario de un producto a un pedido de un cliente que legalmente no puede comprar ese producto, evitando errores en la transacción final, y lo que es más importante, riesgos legales. Crear un programa que sirva y facture cualquier producto a cualquier cliente es fácil, pero no hablamos de eso, sino de control, seguridad y valor añadido.

Del mismo modo, podremos actuar en la definición de funciones, habrá que esforzarse en que unas no dependan de otras y las puedan condicionar, sino que las condiciones estén gestionadas a través de elementos externos, de nuevo, en una tabla o veinte tablas de la base de parámetros de ajuste del sistema.

El análisis de los procesos reflejará con claridad las funciones a ejecutar y sus relaciones con las entradas de las tablas o ficheros citados, para que los técnicos puedan aplicar estos criterios y crear programas que gestionen transacciones basadas en los parámetros incluidos en las tablas de control citadas y también en los registros de datos, ya que en este último caso, por ejemplo, habrán sido añadidos al crear un cliente, definiendo su clase y validándola en la tabla de clases de clientes, el tipo de servicio que requiere, sus particularidades para facturarle, etc., tal como haya sido predefinido anteriormente por el usuario experto o el administrador del sistema.

Tal vez parezca que todo esto es obvio, pero pueden creerme si les digo que el mundo está lleno de sistemas y procesos que no entienden nada de esto y que requieren intervención —a veces intencionada— de soporte cada vez que algo nuevo afecta al proceso de la información, por no hablar aquí de las condiciones de explotación del sistema (ya lo hice en otro artículo “La Explotación de Sistemas Informáticos”). Definir nuevas transacciones de negocio debe convertirse en un problema de administración y ajuste del sistema, en lugar de una revisión y reprogramación del mismo. Como ya he indicado, habrá un usuario, o varios, expertos en la administración del sistema y en la definición y ajuste de los parámetros que componen las transacciones que ejecuta, y aunque esta tarea puede ser subcontratada externamente como parte de un servicio, es muy conveniente que quede dentro de la empresa usuaria.

Tal vez el cliente pueda sorprenderse de que se requiere hacer una definición inicial de todos los parámetros y se pierda en el concepto, pero verá sus resultados con cierta rapidez, en cuanto pueda definir sus propias funciones dentro de lo previsto y cambiar el modo en que se procesa la información en ciertas circunstancias (un cliente que inicia una nueva actividad o negocio, por ejemplo).