CASO DE EJEMPLO EMPRESARIAL

APLICACIÓN ADECUADA DE LA ADMINISTRACIÓN

La empresa
Fina Cola es una empresa de tamaño medio que produce y distribuye bebidas
refrescantes a distribuidores de todo el país. Tiene una planta de producción y varios
centros de distribución ubicados estratégicamente. El tipo de cliente de Fina Cola
va desde cadenas de supermercados a nivel nacional a pequeñas tiendas de barrio.
Por norma, las cadenas de supermercados realizan pedidos de forma periódica y
fija, aunque pueden realizar cambios en el momento de entrega. Las tiendas
pequeñas de barrio suelen proveerse directamente del camión de reparto sin
realizar pedidos con antelación. El volumen de los pedidos varía, alcanzando el
máximo en la estación más calurosa y durante las vacaciones.
El proceso que va desde el pedido de la materia prima a la entrega del producto
acabado y la devolución de los envases vacíos comporta un número de
subprocesos: inventario, pedido de compra de materia prima, producción,
suministro a los centros de distribución y entrega. Todos estos subprocesos son
interdependientes y las actividades de un subproceso suelen iniciarse gracias a un
suceso en otro. Por ejemplo, el pedido de materia prima se inicia automáticamente
cuando inventario descubre que el volumen actual de materia prima del almacén ha
alcanzado el nivel de reaprovisionamiento.

El reto
Fina Cola utiliza Tivoli Workload Scheduler para gestionar la temporización y las
interdependencias de su proceso de producción y suministro. No obstante, en
algunas zonas se están produciendo problemas con la asignación de recursos en el
sistema:
• Algunos trabajos planificados tienen un plazo de espera muy largo hasta conseguir
que los recursos estén disponibles.
• Algunos recursos se sobrecargan, con lo que se producen problemas de
rendimiento.
• Cuando un recurso con sobrecarga se elimina temporal o permanentemente, las
definiciones de trabajo deben cambiarse manualmente para utilizar un recurso
nuevo.
Tivoli Workload Scheduler utiliza asignación fija de recursos. De este modo, Fina
Cola puede adquirir más recursos o bien arriesgarse a que los trabajos no se
completen a tiempo.
Los problemas son especialmente evidentes durante el proceso de reconciliación al
final del día. Este proceso se inicia cuando regresa el último camión de reparto y
debe completarse para que pueda iniciarse la planificación de la ruta de reparto del
día siguiente. La parte principal del proceso de final del día es la base de datos de
las transacciones diarias. Esta base de datos contiene una gran variedad de
transacciones: transacciones de envío de cada artículo en un pedido de cliente,
transacciones de envío para cada carga de entrega, transacciones de recepción de
 los artículos devueltos, transacciones de recepción de los envases vacíos,
transacciones de ajustes en la facturación del cliente si el volumen del pedido se ha
modificado en la entrega. Estas transacciones se utilizan para actualizar las bases
de datos siguientes: pedidos de clientes y facturación, inventario y contabilidad
general.
En un margen de tiempo pequeño deben completarse las tareas siguientes:
• Actualizar la base de datos de inventario con los artículos devueltos.
• Actualizar la base de datos de inventario con los envases vacíos devueltos.
• Actualizar la base de datos de pedidos de clientes y facturación para que se tengan
en cuenta los cambios realizados en los pedidos y se creen pedidos y facturas para
los clientes que se han provisto de artículos desde el camión directamente.
• Actualizar la base de datos de contabilidad general.
• Realizar extracciones de minería de datos en la base de datos de transacciones y
guardar la información extraída en la base de datos de informes de gestión para
realizar posteriormente un análisis de tendencias de compra que se utilizará en las
campañas promocionales del futuro.
• Generar diversos informes con distintos niveles de detalle de las transacciones por
artículo, por cliente y por ruta de reparto con el fin de analizar la rentabilidad de las
líneas de productos y las rutas. Guardar estos informes en la base de datos de
informes de gestión.

La solución
Fina Cola decide que en su solución de TI falta un elemento importante: la
posibilidad de mantener un conjunto de recursos del sistema, identificar aquellos
recursos que se corresponden con los requisitos de un trabajo y asignar
dinámicamente el trabajo a un recurso coincidente que esté disponible en el
momento del envío.
Fina Cola decide aprovechar la característica Dynamic Workload Broker de Tivoli
Workload Scheduler, ya que parece que cumple los requisitos de planificación de
trabajos, resolución de dependencia y asignación eficaz de los recursos. El
administrador de la infraestructura de TI migra a esta versión de Tivoli Workload
Scheduler e implementa los agentes de Tivoli Workload Scheduler en los sistemas
que se utilizan normalmente para realizar las tareas asociadas con la base de datos
de transacciones en el proceso de reconciliación de final del día. De esta manera,
podrá comprobar si con la asignación dinámica se logra un uso más eficaz de los
recursos.
La exploración del hardware que realiza el agente proporciona un conjunto de
información detallada sobre los sistemas informáticos, los sistemas operativos, los
sistema de archivos y las conexiones de red. Además de ver los recursos que están
disponibles, el administrador, para asignar de forma precisa los recursos a los
requisitos de trabajos, debe identificar los sistemas informáticos que tienen acceso
a las distintas bases de datos. Para ello, utiliza Dynamic Workload Console para
crear un recurso lógico para cada base de datos y lo enlaza a los sistemas
informáticos desde los que se accede a la base de datos.
A continuación, el administrador puede crear las definiciones de trabajos y
proporcionar así una fotografía precisa de los recursos lógicos y físicos necesarios
para el trabajo. Instala la Consola de Job Brokering Definition en su estación de
trabajo local. Esta herramienta ofrece una interfaz gráfica fácil de utilizar para crear
definiciones de trabajo JSDL.

Ejm:
Acceso a unidades Sistema Acceso de base
Trabajo remotas compartidas operativo de datos
Actualizar artículo de Ninguno Linux Inventario,
inventario Transacción
Actualizar envases Ninguno Linux Inventario,
vacíos de inventario Transacción
Crear/actualizar pedidos Ninguno AIX con al menos Cliente,
de clientes 1024 MB de Transacción
memoria física
libre
Facturar pedidos de Ninguno AIX Cliente,
clientes Transacción
Actualizar consolidación Ninguno AIX Contabilidad
de transacciones y general,
contabilidad general Transacción
Minería de datos de Ninguno Linux®, AIX o Transacción,
información de artículos HP-UX Informes de
gestión
Minería de datos de Ninguno Linux, AIX o HP- Transacción,
información de rutas UX Informes de
gestión
Resumen de ventas por //shared/reports/sales Linux, AIX o HP- Transacción,
artículo UX Informes de
gestión
Resumen de ventas por //shared/reports/sales Linux, AIX o HP- Transacción,
ruta UX Informes de
gestión
Resumen de ventas por //shared/reports/sales Linux, AIX o HP- Transacción,
cliente UX Informes de
gestión
Tabla 1. Trabajos y requisitos de final del día
 Estos trabajos ya existen en Tivoli Workload Scheduler, pero utilizan la asignación
estática de recursos. El administrador utiliza laConsola de Job Brokering
Definition para importar estos trabajos y crear una definición de trabajo JSDL para
cada trabajo, incluidos los requisitos identificados para cada trabajo:
• Agregar los sistemas operativos candidatos que se han identificado para cada
trabajo.
• Agregar un requisito de sistema de archivos para el acceso remoto al
directorio //shared/reports/sales para los trabajos de informes.
• Agregar los recursos lógicos adecuados para el acceso a la base de datos que
convenga.
.
Figura 1. Requisitos de recursos para el trabajo de actualización de artículos en
Inventario

Una vez creados todos los trabajos, el administrador comprueba los recursos
coincidentes que se han encontrado para los trabajos que ha definido. El resultado
es que hay ocho sistemas que coinciden con los requisitos de trabajo para los
trabajos de creación de informes y minería de datos, que requieren acceso a las
bases de datos de transacciones e informes de gestión. Los otros trabajos, que
requieren acceso a las bases de datos de inventario, clientes y contabilidad general
respectivamente, tienen cada uno dos sistemas coincidentes. No obstante, todos
estos sistemas se incluyen en los ocho sistemas que se han encontrado para las
tareas de creación de informes y minería de datos.
Figura 2. Recursos coincidentes para los trabajos de final del día

El administrador se pregunta si se producirán problemas de equilibrio de carga entre

los ocho sistemas y decide incluir instrucciones de optimización en todas las
definiciones de trabajos.

Figura 3. Instrucciones de optimización de un trabajo

El objetivo es distribuir los trabajos entre los recursos disponibles con el fin de
mantener el uso de la CPU al mínimo. De esta manera, el administrador cree que
conseguirá una distribución más eficaz de los recursos, en lugar de tener un número
igual de trabajos en cada sistema informático disponible.
Además, como los trabajos de actualización se destinan a un subconjunto de
sistemas disponibles para los trabajos de minería de datos y creación de informes,
el administrador decide que los trabajos de actualización deben tener la prioridad
más alta, de modo que los recursos se asignan antes de los trabajos que tienen un
mayor abanico de opciones. Regresa a las definiciones de los trabajos de
actualización y establece la prioridad de planificación en 100 (el valor más alto).
Una vez completadas las definiciones de trabajo, el administrador las carga en el
repositorio de trabajos de la base de datos de Tivoli Workload Scheduler. Está
convencido de que observará una mejora en el rendimiento durante el proceso de
final del día, ya que todos los trabajos tienen más de un destino posible y ha
personalizado las definiciones para promover un uso equilibrado de los recursos
disponibles.
Mediante Tivoli Workload Scheduler, el administrador ha creado una secuencia de
trabajos para los trabajos de final del día y lo planifica de modo que se realice todos
los días laborables. La mayoría de los trabajos no tienen dependencias y pueden
ejecutarse al mismo tiempo. No obstante, la minería de datos de información de ruta
requiere como entrada datos producidos por la minería de datos de información de
artículos. Debe esperar hasta que el trabajo de minería de datos de información de
artículos se haya completado y después debe ejecutarse en el mismo sistema
informático.
Para alcanzar este objetivo sin perder las ventajas de la asignación dinámica de
recursos, el administrador decide definir una relación de afinidad entre los dos
trabajos. Mediante Tivoli Workload Scheduler, agrega información al trabajo de
minería de datos de información de ruta para identificar su relación con la tarea de
minería de datos de información de artículos. Cuando el trabajo se envía en el
entorno integrado, Dynamic Workload Broker reconoce la relación y asigna el
trabajo al recurso donde previamente se ha ejecutado la tarea de minería de datos
de información de artículos.
Una vez que los trabajos de la secuencia de trabajos se han enviado y asignado
dinámicamente a los recursos, el administrador puede realizar un seguimiento del
progreso y ver la salida del trabajo en Tivoli Workload Scheduler.

Referencias:

Recuperado de:
https://www.ibm.com/support/knowledgecenter/es/SSRULV_8.6.0/com.ibm.tivoli.itws.doc_8.
6/awsbr_topics/awsbrbuscen.htm