INTERFAZ UNIVERSAL ENTRE UN SISTEMA DE GESTIÓN DE ACTIVOS Y UN SISTEMA DE GESTIÓN DE COMPRAS

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO SUPERIOR EN INFORMÁTICA PROYECTO FIN DE CARRERA INTERFAZ UNIVERSAL ENTRE UN SISTEMA DE GESTIÓN DE ACTIVOS Y UN SISTEMA DE GESTIÓN DE COMPRAS AUTOR: JAVIER SÁNCHEZ JIMÉNEZ MADRID, JUNIO DE 2009

2 II

3 Resumen III

4 La distribución de un producto informático para la gestión de activos, como es Datastream, implica la integración con otros productos informáticos del cliente. Dicha integración es especialmente importante en el caso de la gestión de compras, ya que los activos que se gestionan con Datastream son los mismos cuya compra se gestiona con otros productos informáticos de diferentes suministradores. Para evitar tener que desarrollar aplicaciones específicas para cada cliente, de forma que se integre Datastream con el software que dicho cliente tenga para realizar la gestión de compras, se ha desarrollado en el presente Proyecto Fin de Carrera, una herramienta, denominada UNIGUI, que permite definir dos modelos de datos (el de Datastream y el de la otra aplicación) así como un sencillo lenguaje para editar Jobs de intercambio de información entre ambos paquetes de software. El objetivo de la herramienta será, por lo tanto, permitir el intercambio de toda la información asociada a cualquier herramienta del mercado dedicada a la gestión de compras con una herramienta específica de gestión de activos empresariales (Datastream), usada actualmente por nuestra empresa. La herramienta también ofrecerá la posibilidad de gestionar el mantenimiento de todos los activos almacenados, centralizando por tanto este proceso en un solo sistema. Las empresas participantes, por tanto, dejarán de realizar esta tarea. IV

5 Existen dos tipos de usuarios que tendrán distintas funciones dentro del proceso de gestión. Estos usuarios son los clientes de cada empresa participante y el administrador. Cada uno de ellos contará con unas funciones específicas dentro del sistema. El ciclo de vida del proyecto se basa en un modelo lineal o en cascada. Cada etapa del proyecto no comienza hasta que la anterior etapa se haya finalizado por completo, lo cual es idóneo para un proyecto de estas características. En resumen, el sistema permitirá la posible comunicación y operabilidad entre diferentes herramientas de gestión de activos y de compras de forma totalmente transparente para las empresas participantes, y usando toda la información implicada en este proceso proporcionará información de valor derivada de ésta. V

6 Abstract VI

7 The distribution of a computer science product for the management of assets, as it is Datastream, implies the total integration with other computer science products of the client. This integration is specially important in the case of the management of purchases, since the assets that are managed with Datastream are such whose purchase is managed with other computer science products of different suppliers. In order to avoid to have to develop specific applications for each client, making possible that Datastream could be integrated with the software that this client possesses to carry out the management of purchases, in the present Project has been developed a tool, denominated UNIGUI, that allows to define two data models (the one of Datastream and the one of the other application) as well as a simple language to publish Jobs of exchange of information between both software packages. The objective of the tool will be, therefore, to allow the interchange of all the information associated to any tool of the market dedicated to the management of purchases with a specific tool of management of enterprise assets (Datastream), used at the moment by our company. The tool also will offer the possibility of managing the maintenance of all the stored assets, centralizing therefore this process in a single system. The participant companies, therefore, will let make this task. VII

8 Two types of users exist who will have different functions within the management process. These users are clients of each participant company and administrator. Each one of them will count on specific functions within the system. The cycle of life of the project is based on a linear model, also known as cascade. Each stage of the project does not begin until the previous stage has been finalized completely, which is suitable for a project of these characteristics. In summary, the system will allow the possible communication and operation between different tools from management of assets and purchases with total transparency for the participant companies, and using all the information implied in this process, it will provide information of value derived from this one. VIII

9 ÍNDICE PARTE I. MEMORIA INTRODUCCIÓN PLANTEAMIENTO DEL PROYECTO ESTADO DEL ARTE SISTEMAS DE GESTIÓN DE ACTIVOS SISTEMAS DE GESTIÓN DE COMPRAS METODOLOGÍA ETAPAS DE DESARROLLO IDENTIFICACIÓN DE NECESIDADES (IDN) ANÁLISIS DE REQUISITOS (ARQ) ESTUDIO DE LA ARQUITECTURA (EAQ) DISEÑO EXTERNO (DEX) DISEÑO INTERNO (DIN) PROGRAMACIÓN (PRO) PRUEBAS DEL SISTEMA (PRU) IMPLANTACIÓN (IMP) MANTENIMIENTO (MAN) ESTRUCTURA DE DIVISIÓN DEL TRABAJO IDENTIFICACIÓN DE NECESIDADES INTRODUCCIÓN OBJETIVOS DEL SISTEMA ALCANCE DEL SISTEMA. 80 IX

10 3.4. TIPOLOGÍA DE USUARIOS RESTRICCIONES ORGANIZACIÓN DEL PROYECTO ANTECEDENTES DEL SISTEMA PLANIFICACIÓN ANÁLISIS DE REQUISITOS INTRODUCCIÓN DESCRIPCIÓN DE UN PROCESO DE ORDEN DE COMPRA LISTA DE REQUISITOS CARACTERÍSTICAS DE CADA REQUISITO DIAGRAMA DE CONTEXTO DIAGRAMA DE PRIMER NIVEL DIAGRAMAS DE SEGUNDO NIVEL MODELO CONCEPTUAL DE DATOS ESTUDIO DE LA ARQUITECTURA INTRODUCCIÓN ARQUITECTURA SOFTWARE ARQUITECTURA HARDWARE DISEÑO INTRODUCCIÓN MODELO FÍSICO DE PROCESOS PSEUDOCÓDIGO proceso GESTIÓN ENTIDADES DS (PFC_PRO_01) PSEUDOCÓDIGO proceso GESTIÓN ATRIBUTOS DS (PFC_PRO_02) X

11 PSEUDOCÓDIGO proceso GESTIÓN ENTIDADES SGC (PFC_PRO_03) PSEUDOCÓDIGO proceso GESTIÓN ATRIBUTOS SGC (PFC_PRO_04) PSEUDOCÓDIGO proceso GESTIÓN CASOS (PFC_PRO_05) PSEUDOCÓDIGO proceso GESTIÓN JOBS (PFC_PRO_06) PSEUDOCÓDIGO proceso GESTIÓN TAREAS (PFC_PRO_07) PSEUDOCÓDIGO proceso GESTIÓN FRECUENCIAS (PFC_PRO_08) PSEUDOCÓDIGO proceso GESTIÓN TIPOS DE TAREAS (PFC_PRO_09) PSEUDOCÓDIGO proceso GESTIÓN EMPRESAS - SISTEMAS (PFC_PRO_10) PSEUDOCÓDIGO GESTIÓN DE USUARIOS (PFC_PRO_11) MODELO FÍSICO DE LA BASE DE DATOS PROGRAMACIÓN INTRODUCCIÓN DISEÑO DEL INTERFAZ DE USUARIO CRITERIOS DISEÑO DE FORMULARIOS MANUAL DE USUARIO. 147 XI

12 8. PRUEBAS INTRODUCCIÓN PRUEBAS UNITARIAS PRUEBAS FUNCIONALES PRUEBAS DE SEGURIDAD PRUEBAS DE ACEPTACIÓN DEL USUARIO PRUEBAS DE REGRESIÓN IMPLANTACIÓN PRESUPUESTO INTRODUCCIÓN DIVISIÓN DE COSTES CONCLUSIONES BIBLIOGRAFÍA PARTE II. ANEXOS. 164 ANEXO A. MANUAL DE USUARIO. 164 ANEXO B. MANUAL DE IMPRESIÓN Y CREACIÓN DE FICHEROS XII

13 PARTE I: MEMORIA 1. Introducción

14 1. INTRODUCCIÓN 1.1. PLANTEAMIENTO DEL PROYECTO El proyecto presente consiste en el desarrollo de un interfaz universal, denominada UNIGUI, que permita capturar información en tiempo real entre un sistema de Gestión de Activos (DATASTREAM en nuestro caso) y un sistema de Gestión de Compras cualquiera. El objetivo principal es construir una herramienta que permita total comunicación y operabilidad entre ambos sistemas de forma totalmente transparente. Nuestra empresa (EMPRESARIOS AGRUPADOS) cuenta actualmente con la herramienta DATASTREAM para realizar la gestión de todos sus activos, siendo uno de los principales proveedores de esta herramienta tanto en España como en todos los países en los que lleva a cabo proyectos. Por ello, se tiene mucho interés en el desarrollo del proyecto ya que supondría el origen de la compatibilidad de sistemas con clientes que cuentan con gestores de compras propios. Se implementarán un conjunto de protocolos y estándares para permitir el intercambio de datos entre ambos sistemas usando un estándar universal para almacenamiento de datos, en principio basado en MS Access para garantizar la viabilidad de intercambio de información entre ambos sistemas. El proyecto incluye tanto el análisis, como el diseño, la implementación y la documentación del interfaz. 2

15 1.2. ESTADO DEL ARTE SISTEMAS DE GESTIÓN DE ACTIVOS Un Sistema de Gestión de Activos ( SGA en adelante) se define como un conjunto de herramientas informáticas que debidamente aplicadas permiten la optimización del desempeño de una empresa o planta industrial. Este sistema actúa sobre los activos de la empresa que están involucrados directamente en la producción industrial (activos industriales) y su uso permite monitorear los costos que genera un activo durante su ciclo de vida y disminuir las interrupciones imprevistas de funcionamiento. La gestión de activos se encarga, por lo tanto, de asegurar que todos los equipos y componentes en los que se ha invertido dinero realicen su trabajo de la forma más eficiente posible, y, a su vez, dar la posibilidad al usuario de estar informado de forma continua de lo que sucede a medida que transcurre el tiempo, con el fin de tomar decisiones de forma documentada. Desde el día en que se instalan los equipos de una planta, estos comienzan una paulatina degradación, de la que no se suele tener constancia hasta que algo grave ocurre, provocando que el proceso deje de ser completamente fiable. Por este motivo, se marca como objetivo interceptar el avance de la mencionada degradación para no llegar a ésta situación. Un SGA es parte activa de la Gestión de Mantenimiento moderna y permite obtener información importante del desempeño de los activos en el tiempo. En concreto, el 3

16 SGA nos entregará información de los activos de planta, alertas y alarmas de mantenimiento, monitoreo del ciclo de vida del activo, indicadores de gestión para la medición de estrategias de la compañía y mejoras en la seguridad industrial. La gerencia de Mantenimiento debe decidir la implementación de todas aquellas actividades, prácticas sistemáticas y herramientas que ayuden a lograr el mejor desempeño posible para los activos industriales. Su principal utilidad consiste en el descubrimiento de actividades de mantenimiento que no estén dando el resultado esperado, que estén consumiendo más recursos de lo debido o bien procesos de trabajo que deban ser modificados. Qué nos aportan estas tecnologías? Dependiendo del proveedor con el que decidamos implementar estas soluciones, un SGA de una empresa incorpora en una base de datos digital toda la información de funcionamiento, especificaciones y descripción de los equipos. Esto permite realizar las labores de mantenimiento en menor tiempo, aumentando la eficiencia y finalmente reduciendo los costos. Está demostrado que un SGA también puede ser un excelente aliado de los ingenieros que están incorporando la filosofía del mantenimiento predictivo, gracias a la capacidad que estos sistemas tienen para comunicarse con los equipos de campo. 4

17 COMPONENTES DE UN SISTEMA DE GESTIÓN DE ACTIVOS Un SGA debe incluir, entre otros, los siguientes módulos: Inventario de activos y componentes. Costos asociados. Almacenes y repuestos. Personal. Compras. Mantenimiento Preventivo. Mantenimiento Correctivo. Mantenimiento Modificativo. Inventario de activos y componentes. Su propósito consiste en la recopilación de información relevante que describa de manera completa los activos de tal forma que al realizar una consulta sobre cualquiera de ellos, esta refleje la condición real del bien en cuestión. No todos los activos son iguales. Se debe de considerar el contar con el soporte necesario especializado al momento de realizar un inventario. No es lo mismo tomar datos físicos de los activos de una Universidad, que básicamente lo que encontraríamos sería mobiliario y equipo de oficina, que realizar el inventario de una planta química, por ejemplo; las características físicas que describen a uno y otro activo son totalmente de naturaleza distinta. 5

18 El inventario tendrá mejor calidad de información si lo realiza conforme al criterio de la Unidad Mínima Indivisible (UMI). Se entiende como UMI aquella unidad de maquinaria integrada por el equipo propiamente dicho, accionado por un determinado mecanismo o transmisión, seguido, en su caso, de equipos o instalaciones menores, así como su ingeniería, directamente relacionados con este equipo, como son: instalaciones de ingeniería civil, mecánica, eléctrica, bombas, válvulas, tuberías, instrumentos, etc., y que por lo tanto definan una capacidad productiva. La información relativa a activos se resume a continuación: Identificación del activo: código, descripción, estado (Instalado, en reparación, etc.) y organización. Detalles del equipo: clase, categoría, costo, fecha inicio, valor y criticidad. Detalles de la instalación: costo de reparaciones necesarias y valor de reemplazo. Detalles de rastreo: fabricante, nº de serie y modelo. Asociación de piezas: pieza, almacén, estante y lote. Jerarquía: activo padre, dependencia, ubicación y posición. 6

19 Costos asociados Su propósito consiste en la recopilación de información relativa a operaciones o tareas en las que interviene un activo, lo cual se consigue asociando a cada orden de trabajo todos los activos que intervienen en ella. La información relativa a costos asociados se resume a continuación: Costos: código de orden de trabajo, tipo, organización, moneda, costo de materiales, costo de mano de obra, costo de herramientas, costo total, horas trabajadas, estado, fecha inicial y descripción. Almacenes y repuestos. El módulo de gestión de almacén nos permite llevar a cabo las distintas tareas relacionadas con el mantenimiento de los stocks de repuestos y herramientas, es decir, que no están funcionando actualmente en la empresa, así como la gestión de las órdenes de compra (OC s). A parte, se debe contar con la correspondiente Gestión de Control especificando para cada equipo o repuesto sus datos de interés: identificador único, cantidad de stock, control stock (quién, cuando, salida/entrada), pedidos, etc. Las tareas que podemos llevar a cabo con este módulo son: Mantenimientos de fichas de repuestos y herramientas. Mantenimiento de fichas de proveedores. 7

20 Entradas y salidas de almacén. Control de stocks mínimos. Gestión de órdenes de compra. La información relativa a almacenes se resume a continuación: Identificación: código almacén, descripción, clase y organización. Detalles del almacén: Ubicación, grupo, almacén padre, plazo de entrega (días), impresora de etiquetas y plantillas para etiquetas (despacho, recibo OC, recibo entre almacenes, etc.). La información relativa a repuestos, es decir, stock almacenado, se resume a continuación: Piezas: código, descripción, organización, estante, lote, cantidad almacenada y cantidad para reparación. Personal. Su propósito consiste en la recopilación de información concerniente a los trabajadores de la empresa, los cuales son los encargados de realizar tareas y servicios (almacenados a su vez en forma de OT s, revisiones, etc.). La información relativa a personal se resume a continuación: 8

21 Identificación: código de trabajador, descripción y organización. Detalles del empleado: taller, clase, ocupación, teléfono, usuario asociado y dirección de correo. Compras. En el módulo de compras se gestiona todo el proceso de adquisición de materiales y servicios, desde la solicitud de compra que expresa la necesidad, pasando por el circuito de autorizaciones, hasta la emisión del pedido generada por la OC. Asimismo, se controla la recepción de materiales mediante la entrada de los correspondientes albaranes, y el proceso finaliza con la aceptación de facturas. Un esquema básico de gestión de compras se muestra en el siguiente gráfico: Esquema Básico de Gestión de Compras. 9

22 La información relativa a compras (OC s) se resume a continuación: Identificación: código OC, descripción, organización, fecha de la orden, autorizador y fecha de autorización. Detalles de OC: estado, almacén, creador, fecha vencimiento, comprador, clase y dirección de entrega alternativa. Detalles de proveedores: código, moneda, tasa de cambio y plazo de entrega (días). Totales de orden de compra: impuesto total, descuento total, valor total de las piezas, valor total del servicio, valor total de la OC. Términos de OC: método de envío, condiciones de pago, condiciones de flete, método de pago y tarjeta de crédito. Mantenimiento Preventivo. El mantenimiento de los equipos es esencial para asegurar una operación adecuada de los mismos. La finalidad del mantenimiento preventivo es encontrar y corregir los problemas en maquinaria antes de que estos provoquen fallos. El mantenimiento preventivo puede ser definido como una lista completa de actividades, todas ellas realizadas por usuarios, operadores, y mantenimiento para asegurar el correcto funcionamiento de la planta, edificios, máquinas, equipos, vehículos, etc. Realizar mantenimiento preventivo en los activos de una empresa de manera organizada y proactiva genera muchos beneficios, como por ejemplo: 10

23 Aumento de la disponibilidad: a través del aumento del tiempo entre incidencias (fallos) y la disminución del tiempo medio de reparaciones. Aumento de la productividad: por medio de una mejor planificación y organización. Reducción de costes derivados: debido a una mejor planificación, un menor número de solicitudes de servicios de emergencia y una menor cantidad de picos de servicio. Reducción de inventarios: a través del establecimiento de planes de trabajo que identifican con exactitud cuales son los materiales requeridos y cuando serán necesarios para su aplicación en órdenes de trabajo. Reducción de compra de materiales: debido a las mejores prácticas y decisiones de compra y a un menor número de compras de emergencia. Reducción de consumo de energía eléctrica: a través de la implementación de rutas de inspección de puntos donde hay mayores pérdidas de energía. 11

24 Mantenimiento Correctivo. También denominado mantenimiento reactivo, es aquel trabajo que involucra una cantidad determinada de tareas de reparación no programadas con el objetivo de restaurar la función de un activo una vez producido un paro imprevisto. Las causas que pueden originar un paro imprevisto se deben a desperfectos no detectados durante las inspecciones predictivas, a errores operacionales, a la ausencia de tareas de mantenimiento y, a requerimientos de producción que generan políticas como la de "repara cuando falle". Existen desventajas cuando dejamos trabajar una máquina hasta la condición de reparar cuando falle, ya que generalmente los costos por impacto total son mayores que si se hubiera inspeccionado y realizado las tareas de mantenimiento adecuadas que mitigaran o eliminaran la situación de fallo en la máquina. Diferencia costo / desempeño de una estrategia de mantenimiento preventivo y un mantenimiento correctivo. 12

25 Mantenimiento Modificativo. Tiene por objeto cambiar, variar o modificar las características propias del equipo, para realizar un mejor mantenimiento, incrementar la producción o cualquier tipo de mejora que aumente su calidad. Las causas que motivan estos cambios pueden ser de cualquier tipo, tales como obras, cambio de usos o de ubicación, políticas, nuevas normativas, etc. El tamaño de una instalación y el número de usuarios son directamente proporcionales a las necesidades de este mantenimiento. 13

26 RELACIÓN ENTRE LOS DIFERENTES MÓDULOS DE UN SISTEMA DE GESTIÓN DE ACTIVOS Una vez definidos los módulos que deben componer un SGA, el siguiente paso es definir cómo se relacionan entre sí. Antes de nada, se van a definir las características más importantes a cumplir por todos los módulos. La principal característica que cumplen todos los módulos es que forman un sistema integrado. En general, podemos definir un sistema integrado como un sistema de propósito especial diseñado para llevar a cabo una función específica. Un sistema integrado lleva a cabo una o unas pocas tareas predefinidas, generalmente con requerimientos muy específicos, y a menudo incluye hardware específico para cada tarea, y partes mecánicas que no se encuentran en sistemas de propósito general. Como el sistema está dedicado a una tarea específica, los ingenieros de diseño pueden optimizarlo, reduciendo su tamaño y costes. En la figura siguiente se muestra un ejemplo de sistema integrado: 14

27 Otra característica importante de los SGA es su interfaz, es decir, la forma en la que se accede a los datos. El interfaz de un SGA suele estar basado en estándares que permiten cierta homogeneización del uso por parte de los usuarios. En el caso de los SGA, ésta estandarización se pone de manifiesto en aspectos relacionados con la propia funcionalidad de la herramienta, tales como: La gestión de los datos en la pantalla (Creación de registros, borrado, modificación, duplicado, etc.). Desplazamiento en los registros del panel (Botones Siguiente y Anterior, etc.). Realización de consultas (por cualquier columna, ordenación, agrupadas, etc.). Acceso a otras pantallas relacionadas (arrastrando datos). Acceso a otras pantallas no relacionadas (sin arrastrar datos). Teniendo en cuenta la propiedad de Integración del Sistema, se debe poder llegar de cualquier pantalla a cualquier otra. Ayuda en línea. Opciones de navegación ( Aceptar, Cancelar y Salir ). Las opciones Aceptar y Salir implican la gestión correspondiente con la Base de Datos. 15

28 Es muy importante que los SGA integren el control de los flujos de trabajo. Estas aplicaciones automatizan la secuencia de acciones en la ejecución de cada proceso, permiten realizar un seguimiento de cada etapa del mismo y aportan las herramientas necesarias para su control o gestión del flujo de trabajo. Esta integración, en el caso de los SGA, es posible mediante la estructura de la propia aplicación, es decir, la forma en que se distribuyen y se recorren los paneles y, con ello, la forma en la que se permite a los usuarios realizar las diferentes operaciones posibles. Todos los módulos que componen el sistema están relacionados entre sí. El módulo más importante, como es lógico, será el formado por todos los activos o elementos que forman parte de la empresa; el resto de módulos derivan a partir de éste, por lo que la relación entre todos los módulos está asegurada. Veamos un ejemplo perfectamente válido de un esquema de división de un SGA: 16

29 Subsistema Activos (Rojo): Activos. Los recursos son uno de los activos más valiosos de una empresa. La planificación de la capacidad de recursos, el control de la disponibilidad de los recursos y el seguimiento de los costes sólo son algunas de las necesidades de gestión que pueden demandar atención constante. Una supervisión precisa del coste y el uso de los recursos permite mejorar la gestión de recursos y tener un mejor conocimiento de la capacidad global de recursos de la empresa. Éste área permite, a su vez, utilizar modelos de fijación de precios flexibles, lo que facilita la facturación a través del área de la aplicación ventas y cobros o el registro de los costes en proyectos. Las relaciones del módulo de activos se muestran en el siguiente gráfico: 17

30 Mantenimiento. Para ser competitivos existen algunos factores claves como es la Calidad, por la que se debe brindar a nuestros clientes los productos y servicios que satisfagan sus necesidades, pero también debemos entre estas necesidades, satisfacer el precio que los clientes están dispuestos a pagar por el producto o servicio que le brindamos así como el tiempo que tardamos en ofrecérselo. Estos factores debemos cumplirlos sin descuidar las exigencias en temas de Seguridad y Medio Ambiente que hoy día son tan claves para la competitividad como los primeros, dada la toma de conciencia que ha habido en estos temas. Pero la calidad y la productividad, el respeto a la seguridad y al medio ambiente, no son cosas que sea suficiente hacerlas durante un día o dos, ni durante un mes o dos, debemos lograrlas siempre y para ello necesitamos el aporte del factor clave de la competitividad: la confiabilidad. La confiabilidad es lo que me permite asegurar los cuatro primeros factores claves a lo largo del tiempo y por lo tanto asegurar la competitividad. Obtener Confiabilidad solo es posible con el correcto Mantenimiento. Es entonces por la incidencia que el mantenimiento tiene en los factores claves, confiabilidad, seguridad, medio ambiente, calidad y productividad, así 18

31 como en otros no menos importantes como la disponibilidad, el costo-eficacia y el uso racional de la energía, que se lo ubica actualmente en los primeros planos de la dirección empresarial. Hoy en día existen muchas técnicas o Herramientas a aplicar en lo referente al mantenimiento, entre las cuales destacan: OIM Optimización Integral de Mantenimiento. TQM Gestión Total de la Calidad. TPM Mantenimiento Productivo Total. LCC Costo del Ciclo de Vida. Gestión y Evaluación de Riesgos. Monitoreo de la Condición y Análisis Predictivo. Gestión por Indicadores. Sistemas Expertos. 19

32 Los procesos de mantenimiento se asocian de manera unívoca a cada activo, por lo que, a su vez, estarán asociados a las distintas piezas que lo forman. Esta relación quedará reflejada perfectamente en la base de datos, con las correspondientes relaciones entre las tablas de Tipos de Mantenimientos- Piezas-Activos. Almacenes. La gestión de almacenes implica una serie de decisiones básicas: Decidir el número de almacenes y su tamaño. Elegir las localizaciones para los almacenes. El tipo y nivel de mecanización. La primera decisión es si utilizar almacenes en propiedad, alquilados o almacenes ajenos. Algunos productos requieren almacenes especializados como, por ejemplo, los productos congelados. Otra decisión fundamental es el nivel de automatización de los almacenes. Actualmente podemos disponer de almacenes totalmente automatizados, aunque en ocasiones resulta más rentable un nivel intermedio de automatización. Establecer la organización y los procedimientos concretos de gestión. El número de almacenes depende de varios factores. Un factor fundamental es el coste y la duración de los transportes. Otros factores 20

33 fundamentales se relacionan con las características del producto y del mercado. La localización de los almacenes se decide analizando los costes de los diversos emplazamientos alternativos. Y teniendo como restricción fundamental el tiempo máximo de respuesta a los pedidos de los clientes. Establecer el sistema de organización. Se hace preciso decidir el número de empleados de los almacenes, seleccionarlos, formarlos y asignarles responsabilidades. Un aspecto importante en los almacenes es la distribución en planta. Es decir, como se reparten por la superficie del almacén los distintos productos. Dentro de los almacenes será preciso determinar como se moverán los productos, la información y las personas o medios mecánicos. Las distintas etapas o tareas que se desarrollarán desde la recepción de los productos en el almacén hasta su salida. Se deben definir de forma precisa los procedimientos a seguir, es decir, cómo se realizará el trabajo, establecer las distintas tareas de cada proceso y cómo se realizarán. Las relaciones de la tabla almacenes se muestran en el siguiente gráfico: 21

34 Operación. Comprende todas las acciones que pueden ser llevadas a cabo por la empresa tales como adquisición de herramientas, realización de técnicas de análisis y control para gestión con eficiencia de todos los recursos, planificación y optimización estratégica de todos los procesos operativos (productivos y logísticos), análisis del impacto de los conceptos de calidad, medioambiente y seguridad laboral en la gestión de operaciones, etc. En nuestro caso, las acciones posibles tienen relación con: Recepciones de reparaciones internas. Despacho/Devolución de piezas. Recibo sin OC. 22

35 Recibo con OC. Inspecciones. Inventario físico. Envíos entre almacenes. Recepción entre almacenes. Devoluciones al proveedor. Gestión de Diseño. Ante una oferta amplia de productos, el diseño permite la diferenciación del producto y la introducción de valores simbólicos, funcionales y estéticos que justifican frente al usuario los mayores precios. La competitividad de una empresa está definida por la naturaleza de su relación con el mercado a través del producto. Esta relación permite la identificación de tres elementos clave: empresa, producto y mercado, que en su intercalación mutua determinan la competitividad de la empresa. Desde el punto de vista de la empresa podemos considerar al diseño como un instrumento de gestión dirigido a incrementar su competitividad mediante la concepción de nuevos productos. El diseño actúa sobre el producto aportándole las propiedades que le permiten satisfacer las necesidades que el mercado demanda. A su vez, permite diferenciar el producto dotándole de una imagen adaptada a los deseos del mercado. 23

36 Podemos definir la gestión del diseño como el conjunto de técnicas de gestión empresarial dirigidas a maximizar, al menor coste posible, la competitividad que obtiene la empresa por la incorporación y utilización del diseño industrial. El diseño innova en las siguientes áreas fundamentales que afectan a la competitividad de los productos y de las empresas: Introduce calidad y estética en el producto contribuyendo a su diferenciación. Racionaliza los procesos productivos reduciendo los costes y colaborando en la búsqueda del liderazgo de costes. Mejora las prestaciones del producto aumentando su valor de uso. Mejora la comunicación e imagen de la empresa al actuar sobre sus comunicaciones externas e internas. Las relaciones de la Gestión de Diseño se muestran en el siguiente gráfico: 24

37 Repuestos. El objetivo fundamental de los almacenes de repuestos es dar soporte a las tareas de mantenimiento, tanto a aquellas tareas planeadas como aquellas no planeadas. Por ello, cobra sentido una política de inventario cuya demanda de repuestos tenga su origen en: mantenimiento y operaciones. Muchas técnicas tradicionalmente utilizadas para optimizar las tenencias de inventarios de repuestos fracasan justamente por olvidar al mantenimiento y las operaciones, origen de la demanda de repuestos. Esto no es extraño dado que justamente muchas de estas técnicas tradicionales se desarrollaron no para el manejo de inventarios de repuestos de ingeniería, sino para el manejo de stocks de producción. El aumento de la automatización industrial y el incremento de la complejidad de los activos físicos hace que el número y la variedad de fallos posibles haya 25

38 aumentado aceleradamente en los últimos años, por lo que a la par ha aumentado el número de repuestos necesarios para reparar esos fallos. A su vez, como la producción depende cada vez más del correcto funcionamiento de activos físicos, las consecuencias de la indisponibilidad de estos activos son cada vez peores, por lo que la indisponibilidad de planta por espera de repuestos se considera inadmisible. Esto genera una fuerte presión por aumentar los niveles de inventario de repuestos. La combinación de estos dos factores ha generado un aumento alarmante en el valor del stock de repuestos. De representar un costo inmovilizado prácticamente insignificante se ha transformado en una importantísima inversión de capital, muchas veces de varios millones de euros. Esto ha despertado el interés de la gerencia por reducir este capital inmovilizado, adoptando en muchos casos políticas irracionales ("todo repuesto no utilizado durante 2 años o más es retirado de stock"), acarreando en muchos casos grandes pérdidas económicas por no tener los repuestos disponibles cuando son requeridos. Como si esto fuera poco, la tendencia de la industria a adoptar métodos de producción just in time, y la tendencia a abandonar el mantenimiento preventivo para adoptar estrategias de mantenimiento predictivo, han dificultado aún más la determinación de políticas de repuesto adecuadas. 26

39 Subsistema Trabajo (Azul): Gestión documental. La gestión documental consiste en el uso de tecnología y procedimientos que permiten la gestión y el acceso unificado a información generada en la organización: Al personal de la empresa. A clientes y proveedores. Los beneficios clave de estas prácticas son: Establecer un nuevo espacio de trabajo compartido empresa / cliente. Aumentar el valor de la información de la empresa. Evitar la duplicación de tareas así como los tiempos de búsqueda de información interna. Incrementar la calidad de servicio y la productividad. Puntos clave de la implantación de una solución de Gestión Documental: Grupos y Roles. Acceso selectivo a la información. Workflow. Procesos online. Acceso descentralizado a la información. Punto único de Acceso. Múltiples fuentes de información. Detección de patrones de comportamiento. Calidad del servicio. La oficina sin papel. Compartición de Información. Empresa - Departamentos Clientes. 27

40 Gestión del Trabajo (Workflow). Workflow se refiere al flujo de trabajo a seguir para la consecución de una tarea o trabajo predeterminado. Se define como un sistema de secuencia de tareas de un proceso de negocio. Organiza y controla tareas, recursos y reglas necesarias para completar el proceso de negocio. Las nuevas tendencias, a la hora de regular las organizaciones, hacen del Workflow una herramienta clave para lograr mayor agilidad y aumentar la descentralización de las actividades administrativas y comerciales. La evolución de Workflow consiste en buscar la máxima automatización de los procesos de trabajo y el control total de las diferentes etapas, durante las cuales los documentos, la información o las tareas pasan de un participante a otro, según unas normas o procedimientos previamente definidos. Un sistema Workflow se caracteriza, principalmente, por una adecuada integración con sistemas de información actuales: bases de datos, gestión documental, mensajería, ERP, etc., permitiendo la ampliación de un Workflow, de un simple proceso a la integración de varios procesos de negocio interrelacionados. Las funciones más importantes de este módulo tienen que ver con: Inspecciones. Controles de revisión. 28

41 Solicitudes de servicio. Registro de mano de obra de los empleados. Resultados de calibración. Solicitudes de planificación de capital. Órdenes de Trabajo. Solicitudes de trabajo. Proyectos. Personal (Empleados). Hay algunas habilidades que son necesarias para tener éxito en la gestión de los empleados de una empresa: Conocer y dominar las normas reguladoras en materia laboral para poder tener la capacidad de actuación en función de la situación que se tenga que afrontar. Proporcionar las capacidades y habilidades necesarias para aplicarlas en la gestión de personal y las relaciones laborales de la organización. Dotar a los participantes de una formación sólida y especializada en la Gestión de Personal y Relaciones Laborales para poder actuar correctamente y afrontar los problemas que se puedan plantear en el día a día de la realidad empresarial de manera que puedan responsabilizarse, tanto dentro de una empresa como en calidad de asesores. 29

42 Las principales relaciones del módulo de trabajadores se muestran en el siguiente gráfico: Seguridad. Este módulo es uno de los más delicados dentro de un SGA. La razón es que es el encargado de gestionar, a parte de los propios parámetros de configuración e instalación de todo el sistema, elementos tan importantes como períodos de cierre, seguridad de las organizaciones, configuración de las propias organizaciones y su definición, definición de grupos de usuarios de la aplicación así como su configuración, gestión de permisos, etc. 30

43 Formación. El desarrollo de políticas de formación en el seno de las empresas, es una actividad que se ha convertido en estos últimos años en uno de los pilares sobre el que se asienta la competitividad de las mismas. Este hecho viene motivado por la importancia que se concede en las organizaciones a los activos intangibles, buena parte de los cuales están conformados por el capital humano. La necesidad de buscar soluciones, por una parte a la falta de cualificaciones que el mercado laboral proporciona al entorno empresarial, así como por la insuficiencia o desorientación de los esfuerzos que en esta materia se están realizando por parte de las instituciones públicas, conducen a que las empresas se vean embarcadas en la tarea de prestar especial atención al reciclaje profesional de sus trabajadores para atender tanto a la introducción de nuevas tecnologías, como a la reestructuración organizativa que se lleva a cabo en estas. La gestión de las actividades formativas en las empresas es un elemento prioritario a considerar, sobre todo en aquellos sectores que se encuentran en un momento de transformación estructural en sus procesos productivos. Subsistema Finanzas (Verde): Archivo. La implantación de un sistema de gestión documental (SGD) es un elemento clave en la actividad de la empresa, tanto en grandes organizaciones como en la pequeña y mediana empresa. Las empresas deben contemplar los sistemas de gestión documental como una tecnología que contribuye a 31

44 mejorar los procesos administrativos en los que la información se encuentra en soporte documental, o bien es información estructurada. El concepto clave para el análisis de los SGD es el de documento o archivo: Un documento de archivo es el testimonio material de un hecho o acto realizado en el ejercicio de sus funciones por personas físicas o jurídicas, públicas o privadas, de acuerdo con unas características de tipo material y formal. Documento es toda información fijada materialmente sobre un soporte. Los SGD son los sistemas encargados de gestionar y tratar en todos sus aspectos la información fijada en un soporte. En un SGA podemos hacer uso de esta gestión para los siguientes documentos: Trabajo (OT s). Compras (OC s). Transacciones de Stock. Pistas de Auditorias. Registros electrónicos. 32

45 Presupuestos. Un presupuesto es un plan integrador y coordinador que expresa en términos financieros con respecto a las operaciones y recursos que forman parte de una empresa para un período determinado y bajo ciertas condiciones, con el fin de lograr los objetivos fijados por la alta gerencia aplicados a cada centro de responsabilidad de la organización. El presupuesto tradicional se ha basado en los inputs. En este caso, las normas y la estandarización de los procesos son el principal foco de atención. En general se valora el cumplimiento del principio de economía (relación entre los inputs previstos y los reales). La restricción está en los inputs y, por tanto, el objeto del control se fija en el cumplimiento de los mismos. El presupuesto orientado a la producción de bienes y servicios centra la atención en los productos (outputs). Es importante la relación entre los inputs y los outputs. En este modelo de presupuestación es importante la consecución de la máxima eficiencia (relación inputs con outputs, en el sentido de obtener el máximo output dado un input, o de minimizar los inputs necesarios para obtener un determinado output). 33

46 El presupuesto orientado a resultados se basa en aquello que se quiere obtener y centra la atención en los resultados y en los impactos. Adicionalmente a los objetivos de economía y de eficiencia, también se persigue la eficacia (obtención de los objetivos deseados). En un SGA, las posibilidades de gestión de un presupuesto son las siguientes: Información del presupuesto: estructura, descripción, plazo, organización, padre, tipo de calendario, fecha creación, estado (aprobado/congelado), valor actual, fecha aprobación y persona responsable. Tipos de calendario del presupuesto (anual, mensual, semestral). Grupos de presupuesto. Estructuras de presupuesto. Plazos de presupuesto. Compras. Las empresas comerciales compran productos para venderlos. Por tanto la partida más importante de sus gastos son las compras. Un departamento de compras eficiente es esencial para el éxito de cualquier intermediario. Las tendencias actuales en la gestión de compras son: Investigar a los proveedores y buscarlos de forma activa: conseguir los mejores proveedores ampliando el ámbito de búsqueda. Las grandes cadenas están localizando proveedores en todo el mundo. Por tanto, no 34

47 hay que esperar a los proveedores sino desarrollar una activa labor de búsqueda con criterios amplios. Aumentar la información: sobre los productos, costes y proveedores que maneja el departamento de compras. Disminuir el número de proveedores: para reducir costes de compra y de gestión Por ejemplo, los fabricantes de automóviles han reducido de forma drástica el número de proveedores. Aumentar las compras a cada proveedor: para tener mayor poder de negociación para ser un comprador importante. Cooperar y coordinarse con el proveedor: para disminuir costes. La coordinación con los suministradores es fundamental para conseguir los productos en el momento del tiempo oportuno al mínimo coste. Esto supone una importante reducción de costes que se reparten entre la cadena y el suministrador. Los distintos sistemas que permiten realizar los pedidos de productos por ordenador son otra forma de cooperar que disminuye los costes. Un SGA, por lo tanto, deberá ofrecer una relación directa del área de compras con los siguientes módulos: 35

48 Contabilidad. La contabilidad es una técnica que se ocupa de registrar, clasificar y resumir las operaciones mercantiles de un negocio con el fin de interpretar sus resultados. Por consiguiente, los gerentes o directores a través de la contabilidad podrán orientarse sobre el curso que siguen sus negocios mediante datos contables y estadísticos. Estos datos permiten conocer la estabilidad y solvencia de la compañía, la corriente de cobros y pagos, las tendencias de las ventas, costos y gastos generales, entre otros. De manera que se pueda conocer la capacidad financiera de la empresa. Los objetivos de la contabilidad son: proporcionar información a dueños, accionistas, bancos y gerentes, con relación a la naturaleza del valor de las cosas que el negocio deba a terceros. Sin embargo, su primordial objetivo es 36

49 suministrar información razonada, con base en registros técnicos, de las operaciones realizadas por un ente privado o público. Para ello deberá realizar: Registros con bases en sistemas y procedimientos técnicos adaptados a la diversidad de operaciones que pueda realizar un determinado ente. Clasificar operaciones registradas como medio para obtener objetivos propuestos. Interpretar los resultados con el fin de dar información detallada y razonada. Con relación a la información suministrada, esta deberá cumplir con un objetivo administrativo y uno financiero: Administrativo: ofrecer información a los usuarios internos para suministrar y facilitar a la administración intrínseca la planificación, toma de decisiones y control de operaciones. Para ello, comprende información histórica presente y futura de cada departamento en que se subdivida la organización de la empresa. Financiero: proporcionar información a usuarios externos de las operaciones realizadas por un ente, fundamentalmente en el pasado por lo que también se le denomina contabilidad histórica. La 37

50 contabilidad es de gran importancia porque todas las empresas tienen la necesidad de llevar un control de sus negociaciones mercantiles y financieras. Así obtendrá mayor productividad y aprovechamiento de su patrimonio. Por otra parte, los servicios aportados por la contabilidad son imprescindibles para obtener información de carácter legal. Una aplicación de SGA puede ser perfectamente utilizada para llevar la contabilidad de la empresa. El motivo es que la herramienta almacena, como se ha descrito hasta el momento, todos los recursos o activos así como las operaciones y servicios en los que intervienen éstos, es decir, el archivo histórico; por ello, se tiene almacenada toda la información valiosa referente a la contabilidad, la cual puede ser tratada para la elaboración de informes de distinta índole, perfectamente definibles por la alta gerencia de la empresa. La elaboración de informes es otra de las funciones vitales de un SGA. 38

51 SISTEMAS DE GESTIÓN DE COMPRAS Como se ha visto en el anterior punto, un gestor de activos puede contener un módulo integrado para Compras ( SGC en adelante); sin embargo, es muy frecuente que cada empresa tenga un sistema gestor de compras diferente, dedicado a esta tarea de forma autónoma. Existen multitud de herramientas de este tipo, tales como Oracle, SAP o NAVISION, por ejemplo. En este punto vamos a realizar un análisis de la estructura y funcionamiento de un gestor de compras estándar en el que se puedan englobar todos los sistemas de esta índole. La gestión de las compras es una tarea asignada al servicio de suministros, cuya función se asemeja a la de un gran almacén mayorista. La tarea del servicio de suministros no es solo la de intervenir en la gestión de las compras, sino que también interviene en la gestión de las existencias de sus almacenes. La gestión de las compras lleva asociadas las siguientes tareas: Prever y planificar las necesidades. Control de emisión de OCs. Identificar y elegir a los posibles proveedores. Seleccionar los productos a comprar con criterios de calidad, servicio y precio. Confirmar las entregas de material. Realizar los pagos de los productos recibidos. 39

52 Enviar los productos al área o departamento que los solicitó. Coordinar con el resto de las áreas para identificar las necesidades. El área de Compras tiene una importancia sustantiva en las empresas, porque es el área que articula las necesidades de producción de la empresa al proveerla de los materiales que necesita para cumplir su tarea y porque es el área en la que se genera el proceso de pagos. Es el área que gestiona la salida del dinero de la empresa, para lo cual se debe garantizar comprar la mejor calidad al menor costo posible. Existen 2 factores que hacen que el departamento de compras se sitúe en un determinado nivel jerárquico en la estructura de la empresa: la naturaleza o el tipo del negocio al que se dedica la empresa y la especialización. La compra, en general, se inicia a partir de los requerimientos de los distintos sectores de la empresa y se formaliza con un documento escrito; éste es el momento en el que el área de Compras inicia su gestión. El responsable realiza comparativas de los precios y selecciona al proveedor. Luego genera la orden de compra para notificar al proveedor que se le ha adjudicado la compra y además para notificar a las demás áreas de la empresa. El proceso continúa con la recepción del pedido y de la factura para emitir el pago. Se denomina política de compras a los criterios generados desde la dirección de una empresa con respecto a las condiciones, plazos de pago, tipos de proveedores, etc., que se aplican para realizar todas las adquisiciones. Comprar es una ciencia y 40

53 comprar bien es vender bien. Cada euro ahorrado tiene efecto directo sobre las utilidades de la empresa. En la actualidad, la dirección requiere del profesional de compras: Capacidad para negociar. Capacidad de liderar. Mantenerse actualizado sobre el mercado. Seleccionar adecuadamente a los proveedores. Reducir la gestión administrativa de compras. Contar con conocimiento técnico. El planeamiento de compras es el conjunto de planes sistematizados y encaminados a dirigir las compras dentro de la empresa, el cual responde a las siguientes preguntas: qué comprar?, cuánto?, cómo?, cuándo?, a quién? Del análisis del presupuesto de producción surgen las necesidades de materiales a comprar, por lo que debe efectuarse el presupuesto de compras. Al comienzo de cada período se calculan los requerimientos que serán indispensables, a fin de cubrir las necesidades de fabricación y mantener las existencias en los niveles de stock de seguridad. 41

54 OBJETO Garantizar la adquisición de recursos y/o contratación de servicios a través de la definición de directrices encaminadas al cumplimiento y mejoramiento de las condiciones de calidad, precio y tiempos de entrega. Las actividades más importantes de este proceso se enumeran a continuación: Reconocimiento de la necesidad. El proceso de compra comienza cuando el comprador reconoce la necesidad de adquirir un producto o servicio a partir de reconocer una diferencia entre el estado deseado y el estado real existente. Esta necesidad puede surgir por impulsos externos o internos. Búsqueda de información. En esta etapa el comprador debe recopilar toda la información que considera necesaria para fundamentar sus análisis y la toma de decisiones. Esta información está relacionada con la definición de los proveedores posibles, información sobre los parámetros de las ofertas de cada proveedor, las características y exigencias de los consumidores de la empresa, características del objeto de aprovisionamiento y otras informaciones relacionadas con el mercado y la empresa. 42

55 Formación de alternativas. A partir de la información recopilada el comprador determinará las alternativas de compra ante las que se enfrenta, caracterizando a cada una de las alternativas con aquellos parámetros relevantes. Evaluación de alternativas. El comprador en cada compra determina cuáles son los principales criterios de selección. A partir de esta definición se evalúa de acuerdo a dichos criterios cada alternativa y sobre la base de la ponderación de los distintos criterios se llega a una evaluación integral de cada alternativa para llegar a seleccionar la que es más conveniente para la empresa. Decisión de compra. Considerando la evaluación anterior y el esquema de fuerzas de los actores de la compra se llega a la decisión de compra que contempla un conjunto de parámetros tales como: el proveedor, la cantidad a comprar, el valor de la compra, forma de pago, sujeto de la transportación, lugar de entrega, fecha de entrega, características del producto, envase y embalaje a utilizar y otros elementos. 43

56 Ejecución de la compra. Esta etapa comprende el conjunto de acciones para ejecutar la decisión de compra tomada anteriormente. Esta etapa tiene una gran importancia ya que en la misma es que se logra la materialización de la compra y requiere de una atención esmerada para ejecutar la compra ajustándose a los parámetros que conforman la decisión de compra. Monitoreo post compra. Una vez ejecutada la compra debe mantenerse un monitoreo del producto o servicio durante todo el ciclo de consumo o uso con vista a detectar posibles fallos que puedan ser objeto de reclamación, así como aumentar la información sobre la marca correspondiente, lo cual es de mucha utilidad en próximas compras IMPORTANCIA DE LA FUNCIÓN DE COMPRAS Medir la competitividad de una empresa es medir su participación en el mercado. Uno de los medios para mejorar la competitividad es producir a bajos costos y con alta calidad. Esta afirmación implica que el sistema de producción debe ser abastecido de recursos que cumplan con las condiciones más ventajosas posibles, las cuales son: El precio de compra. El plazo de pago. 44

57 El plazo de entrega el servicio de posventa. La calidad. La estabilidad del proveedor. Una de las responsabilidades de los que conducen empresas es dirigir y coordinar el proceso de compras para cumplir con la producción y las ventas. La planificación de este proceso se relaciona directamente con las funciones de stock. La gestión exitosa en las compras y en el manejo de inventarios permite: asegurar el normal flujo de materiales para las áreas que los transforman en los productos que la empresa comercializa; y la distribución y entrega del producto terminado a los clientes. La eficacia en la gestión de compras se medirá en función de: El control de gastos y costos que permita ahorrar recursos financieros. El manejo de stocks mínimos que aseguren el cumplimiento de las ventas esperadas. La habilidad para encontrar fuentes de abastecimiento. La posibilidad de investigar y conocer nuevos materiales disponibles en el mercado. 45

58 TIPOS En cualquier empresa, no todas las compras se llevan a cabo siguiendo idénticos procesos. Son factores determinantes de la forma de realizar la adquisición de bienes: la actividad habitual desarrollada por la empresa, la importancia de la empresa dentro del contexto del mercado (poder de compra), el tipo de artículo a adquirir, la importancia de la compra, la situación geográfica del proveedor, las características del vendedor, etc. Se puede considerar que, se podrá actuar más coherentemente, si se tienen definidas de forma independiente: Las compras normales. La adquisición de elementos denominados menores. Los bienes importados. Las incorporaciones de bienes del activo fijo. No obstante, es razonable pensar que se debe efectuar en ciertos casos, por ejemplo, la adquisición de un elemento que se puede encasillar dentro de lo que se denomina compra normal, pero que se toman pautas particulares de algunas de la tres restantes formas de comprar mencionadas. 46

59 Las Compras normales. Se ubican dentro de esta forma de comprar, las materia primas a incorporase en un proceso productivo y en otros bienes o elementos representativos de una erogación de carácter general identificada con el área de producción, comercialización o administración. Habitualmente, se trata de elementos sobre los cuales se posee información relativa a la cantidad máxima, mínima y al punto de pedido. Resumiendo, se puede decir que abarca aquellos elementos de consumo repetitivo para el desarrollo habitual de la empresa. Adquisición de elementos menores. Los elementos menores son aquellos que son necesarios para el desarrollo de la empresa pero se precisan solo en un momento determinado, como por ejemplo una pieza de repuesto, un libro contable, etc. La compra de estos elementos se realiza generalmente empleando un fondo fijo. Incluso, esas operaciones de compra se hacen por una cantidad limitada. No es conveniente centralizar este tipo de compras a un solo departamento. Lo más conveniente es que el responsable del sector que necesite un bien de este tipo realice la compra. 47

60 Compras en el exterior. Existe una marcada diferencia en la forma de actuar entre una compra local y aquella efectuada en el exterior. Cuando se importan bienes deben contemplarse particularidades vinculadas con el vendedor, el flete, impuestos, los seguros de cambio y transporte, entre otros. Se debe prestar especial atención a la calidad de los bienes a comprar. También es de tener en cuenta lo relativo a lo de la moneda empleada en la operación, haciendo hincapié en el riesgo que surge desde que el producto se embarca o sale del depósito del proveedor hasta la llegada al país del comprador. Las compras efectuadas en el exterior se realizan frecuentemente en un volumen más considerable que para las compras locales, para abaratar los costes de mercadería, fletes, etc. También, suele tratarse de bienes de elevado precio y por tal motivo las precauciones a tomar deben ser más estrictas. Compras de bienes del activo fijo. Se caracteriza por tratarse de elementos que no requieren de una reposición permanente. Incluye maquinarias, motores, herramientas, instalaciones, inmuebles, etc. En virtud de que el desembolso en estas operaciones es, en general, de importancia, se solicita para la autorización de la misma la conformidad de un alto representante de la empresa, como la del gerente general o la persona que lo sustituye en caso de ausencia o imposibilidad de aquel, o en ultima instancia, del directorio si se trata de una adquisición de gran envergadura. 48

61 RELACIONES CON OTRAS ÁREAS DE LA EMPRESA El área de compras se relaciona estrechamente con varios módulos importantes del negocio, entre los que destacan: Dirección General: fijación de políticas generales, procedimientos y análisis de los cambios del entorno. Producción: información sobre plazos de entrega, costo de los insumos, calidad disponible. Finanzas: fijación de las políticas financieras, requerimientos de fondo y presupuestos. Recepción y almacenes: administración en la logística de movimientos y coordinación de necesidades de espacio. Contabilidad: control de inventarios, costeo de materiales, y valoraciones y provisiones de las compras CONTROL DE LA FUNCIÓN DE COMPRAS Índice de compras: Significación de las compras respecto a las ventas en términos porcentuales. 49

62 Índice de coste del departamento de compras: Significado del coste del departamento de compras (coste de gestión) en relación al valor de las compras. Coste de un pedido de compras: Se determinará por el cociente entre el coste del departamento de compras y el número de pedidos emitidos. Índice de concentración de compras: Revela el importe medio de compra por pedido. Índice de carga de trabajo: Cantidad media de compras por empleado. Se determina por el cociente entre el valor de las compras y el número de empleados del departamento de compras. Índice de concentración de proveedores: Recoge el número medio de pedidos que se adjudica a cada proveedor. Se obtiene dividiendo el número de pedidos entre el número de proveedores. 50

63 Cifra de negocios por proveedor: Indica el volumen de compras por proveedor. Se obtiene dividiendo el valor de las compras realizadas entre el número de proveedores. Índice de rotación de stocks de materias primas: Indica el número de veces que rota el stock medio respecto a la cantidad de materias primas (materiales) comprados. Se determina dividiendo el valor de las compras anuales entre el stock medio anual. Índice de rechazos: Relación entre el valor de las devoluciones y el valor de las compras, expresado en términos porcentuales. Se obtiene dividiendo el Valor de las Devoluciones entre el valor de las Compras y multiplicado por 100. Índice de financiación de las compras por proveedores: Indica el porcentaje del valor de las compras que es financiado por los proveedores. Se obtiene dividiendo el saldo medio de proveedores entre el valor de las compras y multiplicado por

64 Días de crédito por parte de los proveedores: Si el período de análisis es el año, se puede determinar por la relación entre el valor financiado por los proveedores y el de las compras anuales y multiplicado por los 360 días del año PROCEDIMIENTO A. Planificación. Selección de proveedores y contratistas. Esta actividad se realiza a través de la auditoría que se realiza a los Proveedores y Contratistas de la empresa, para aquellos proveedores que conforman el pareto de compras, y aquellos seleccionados por los Directores de área considerados como proveedores o contratistas críticos o que inciden sobre el desempeño de los procesos y en el servicio prestado. El resultado de esta etapa es un listado de Proveedores y Contratistas aprobados así como los registros de evaluación de los mismos. Elaborar el presupuesto anual de compras. Tarea que será llevaba a cabo por la dirección de la empresa y dará como resultado el presupuesto para compras. 52

65 B. Realizar la Compra. Detección de la necesidad de compra. Cada área de la empresa genera sus necesidades de compra mensuales según el giro ordinario de la compañía. Para ello no se deben olvidar del ya fijado presupuesto anual para el total de las compras de la empresa, por lo que habrá que realizar una planificación por áreas asignando los máximos permitidos, cantidad a la que cada área deberá ajustar sus gastos. Cotización. Se contacta a los proveedores y contratistas seleccionados para solicitarles cotización de acuerdo al tipo de bien o servicio a adquirir. Para el caso de proyectos especiales, se elaborarán los términos de referencia de la compra y se publicarán para que los proveedores puedan entregar sus propuestas. Cuando el artículo o servicio requerido es objeto de un acuerdo comercial previo, una vez que los requisitos están fijados, el solicitante de la compra procede a generar la orden de compra respectiva sin que haya lugar a cotizaciones adicionales. Fijación de los requisitos. Los requisitos son definidos según las necesidades detectadas y presupuestadas. El área solicitante debe rellenar completamente la solicitud de Adquisiciones y/o 53

66 Contrataciones fijado en la empresa que contiene las especificaciones del producto o servicio. Debe estar firmado por el Director del área. La Solicitud de Adquisiciones y/o Contrataciones es entregada al Auxiliar de Compras, quien se encargará de asignar la cuenta contable y el centro de costo a afectar y revisar que la solicitud cumpla con los requisitos pertinentes, como: Firma Solicitante. Asignación de Cuenta. Descripción clara y especifica del producto o servicio solicitado. Anexo de cotizaciones y cuadro comparativo de propuestas Si la compra es un Activo Fijo, la solicitud será enviada a la Dirección para su aprobación. Se utilizan 2 copias: una para el folder consecutivo del Auxiliar de Compras, que se anexa a la copia de orden de compra, o contrato y una para el solicitante. Aprobación de Compras. Se procede a elaborar el contrato según aplique. También se solicita una vez sea aprobada la compra, una póliza de cumplimiento como garantía y respaldo según los requisitos exigidos. 54

67 Seguimiento a la Compra. Se hace seguimiento a las condiciones de entrega, garantías, calidad, etc., pactadas con el proveedor. Verificación del producto o servicio comprado. Se validan las características del producto comprado, para constatar que cumple con los requisitos según lo especificado en la Orden de Compra/Servicio/Contrato. Si existe alguna inconsistencia se hace la devolución o reclamo al proveedor y se solicita cambio o mejora del servicio. Control de Inventarios. Se hace un ingreso en el almacén, con un listado de inventario previo elaborado por la Asistente de Dirección. Anualmente se realiza inventario físico por parte de cada Director con el apoyo de la Asistente de Dirección. C. Verificación/Evaluación. Seguimiento al proveedor y Contratista. De acuerdo al desempeño mostrado por el proveedor el interesado en la compra le hace un seguimiento según los criterios de evaluación, los cuales son tenidos 55

68 en cuenta al momento de su re-evaluación anual o según los reclamos presentados en el período seleccionado. El resultado de esta etapa, por lo tanto, dará como resultado un registro de evaluación de Proveedores y Contratistas. D. Post-análisis y optimización. Retroalimentación con proveedores. Se efectúan reuniones para la mejora de aspectos claves de desempeño por proveedor. Se analiza todo el proceso y se definen actuaciones o normas para operaciones posteriores lo cual irá provocando un proceso de optimización de todo el proceso POLÍTICAS GENERALES DE COMPRAS Se exige a los proveedores certificados de la Cámara de Comercio de la ciudad donde esté radicada la empresa. En este certificado debe constar que su matrícula mercantil se encuentra al día. En caso de que sea una compra en el extranjero, se exigirá el certificado siempre y cuando la compra supere un salario mínimo legal vigente. La Entidad efectuará sus compras en condiciones de pago y precios justos acordes con las leyes de oferta y demanda imperantes en el mercado. 56

69 Las compras se realizan a proveedores que aseguren el mantenimiento, soporte y garantías del producto. Se buscará que la adquisición de los bienes, insumos, suministros y servicios sea oportuna, evitando riesgos por escasez o sobre-costos de inventario. Regulación de los conflictos de interés entre la respectiva entidad y funcionarios o terceros, así como de la obligación de manifestar oportunamente tales conflictos en todos los eventos que se presenten. La transparencia en la adquisición de bienes o servicios estará garantizada con el cumplimiento de lo dispuesto en la Declaración de Principios Éticos de la Fundación Carnaval de Barranquilla. Regulación respecto de la prevención y prohibición del uso indebido de información conocida en razón de la labor o de las funciones, que pueda ser utilizada en provecho de funcionarios, agentes o terceros (confidencialidad de la información). Se dará preferencia a aquellos proveedores que son fabricantes o representantes directos de los mismos productos y mantener la uniformidad en líneas y marcas. 57

70 En caso de realizar compras con proveedores exclusivos, éstas deberán ser revisadas periódicamente con el fin de evitar que la empresa quede desprotegida ante eventuales problemas de los mismos. Todas las empresas cumplirán invariablemente los procesos de cotización, autorización y adjudicación. En caso de que este proceso no se cumpla, siempre habrá una constancia escrita. Excluir el trámite de pólizas cuando el producto o el servicio sea entregado en forma anticipada, o la naturaleza del servicio no lo requiera. Procurar la participación del mayor número de oferentes y de demandantes idóneos para garantizar una efectiva exposición al mercado. Se seleccionaran las mejores propuestas para la Entidad, atendiendo factores objetivos previamente establecidos. 58

71 2. Metodología 59

72 2. METODOLOGÍA En este apartado se va a describir de forma general la metodología elegida para la elaboración del proyecto. Existe un gran número de metodologías a la hora de afrontar el desarrollo de un proyecto de software. Por lo general, se determina cuál de ellas es la más beneficiosa a la hora de aplicarla en la elaboración de un proyecto en función de la naturaleza del mismo, aunque en algunos casos se utilizan varias de manera simultánea, extrayendo lo mejor de cada una de ellas Para la elaboración de este proyecto, se ha determinado que la metodología idónea dada su naturaleza es el modelo lineal o en cascada. La metodología de desarrollo en cascada se caracteriza por tener un conjunto de etapas o fases bien definidas, en la que cada etapa del ciclo de vida no comienza su desarrollo hasta que la etapa anterior no ha sido finalizada por completo. Además, con la finalización de cada etapa, se obtiene un documento o producto final, que es revisado, validado y aprobado. En la gran mayoría de los casos, este documento constituye el punto de partida de la siguiente etapa. 60

73 En el caso de este proyecto, se considera de vital importancia no finalizar una etapa hasta que se esté completamente seguro de que los resultados obtenidos en la misma son correctos y hayan sido supervisados y aprobados por el cliente, ya que de la corrección de los resultados extraídos en cada una de ellas depende la corrección del resto del proyecto. La siguiente figura representa un ejemplo de la división en etapas en las que se puede subdividir la metodología lineal o en cascada. Ciclo de vida lineal o en cascada. 61

74 2.1. ETAPAS DE DESAROLLO En los siguientes apartados se va a definir el conjunto de etapas que componen el desarrollo de un proyecto informático mediante el uso de la Metodología en Cascada. Para cada uno de ellos se detallará su objetivo, tareas a realizar así como los entregables obtenidos IDENTIFICACIÓN DE NECESIDADES En esta etapa, se debe conseguir identificar cuales son los objetivos y necesidades que el cliente quiere satisfacer a través del proyecto a desarrollar. Para ello, se deberá llevar a cabo un dialogo con un interlocutor en el cliente que tenga un conocimiento profundo sobre la temática del sistema a desarrollar. En esta etapa se definirán, al menos, los siguientes conceptos: Objetivos del sistema. Se trata de objetivos de tipo empresarial y no de tipo informático. Alcance del sistema. Funciones de negocio a considerar dentro del alcance. Tipología de usuarios finales. Se debe tener una ligera idea sobre a que perfil de personas va dirigido el producto final a obtener. 62

75 Restricciones. Se deben identificar y considerar aquellas restricciones que pueden afectar al plan de proyecto y a su desarrollo. Organización y funciones empresariales. Conocer la organización del cliente para determinar en que usuarios influirá el desarrollo del proyecto. Antecedentes. Recopilar información sobre cualquier sistema existente que realizará una labor similar al que se va a implantar, así como los motivos que han llevado a la organización del cliente a realizar este proyecto. Toda esta información es recopilada básicamente a través de entrevistas con el cliente. Como resultado de esta etapa, la información que se ha ido recogiendo a lo largo de la misma se especifica en el denominado Documento de Conceptos del sistema ANÁLISIS DE REQUISITOS (ARQ) Los objetivos a alcanzar en esta fase son los siguientes: Alcanzar un conocimiento suficiente del sistema y del negocio para proponer en marcha la solución propuesta. Expresar el conocimiento adquirido mediante dos modelos: Modelo de procesos, tanto físicos como lógicos. Modelo de datos Obtener la aprobación del cliente, para avanzar en el nuevo sistema. 63

76 En el caso de existir algún tipo de sistema similar al que deseamos implantar o alguna versión anterior del mismo en el momento de la realización del proyecto, se procederá a obtener el modelo de procesos, tanto físicos como lógicos, de dicho sistema. En el caso de nuestro proyecto, al ser un sistema de nueva implantación, no será necesaria la realización del proceso anterior al no existir ningún sistema similar ya implantado en cliente. Se elaborará la denominada Lista de Requisitos, que contiene una relación lo más detallada posible de los requisitos solicitados al sistema por el cliente, a partir de los objetivos marcados en el Documento de Conceptos del sistema. En cada uno de los objetivos, se establecen los requisitos que se solicitan al sistema para cumplir con cada uno. Se procederá a la elaboración, usando para ello la Lista de Requisitos citada en el párrafo anterior, del modelo de procesos lógico del sistema a implantar, que recogerá aquellas informaciones esenciales para el negocio, eliminándose aquellas que no resulten esenciales. Este modelo deberá representar qué hace el sistema, sin importar cómo lo hace. Este modelo ha de incorporar los requisitos del usuario para el sistema a implantar. 64

77 La siguiente actividad a realizar en esta etapa es la elaboración del modelo conceptual de datos. Dicho modelo representa la familia de datos o entidades de negocio utilizadas por el sistema, así como las posibles interrelaciones existentes entre ellos. Una vez que haya sido definida la plataforma tecnológica a utilizar, se podrán conocer los componentes físicos que formarán parte de nuestro sistema y, por lo tanto, estaremos en disposición de elaborar el estudio del modelo de procesos físicos. En cuanto a los datos se refiere, el modelo físico que construye la base de datos y ficheros del sistema debe estar completado antes de iniciar la etapa de programación ESTUDIO DE LA ARQUITECTURA (EAQ) En esta fase, se deben alcanzar los siguientes objetivos: Definir el conjunto de posibles soluciones que se adapten, tanto a nivel software, hardware como de comunicaciones, a los requisitos y restricciones del sistema. Elegir una de las soluciones anteriores como la alternativa a implantar. Obtener la aprobación del cliente para la solución seleccionada. 65

78 Para alcanzar el conjunto de objetivos citados en los puntos anteriores, se procederá a la realización de un estudio de la tecnología hardware, software y de comunicaciones de cada una de las soluciones o prototipos propuestos. Se evaluará cada una de las alternativas atendiendo a diferentes aspectos tales como: estratégicos, organizativos, operativos, técnicos y económicos. Una vez que se dispongan de los criterios suficientes, se procederá a la elección que de la arquitectura que será implantada con la realización del proyecto y se procederá a la elaboración de la planificación general del proyecto. El plan general de proyecto es un documento en el que se definen el conjunto de etapas, actividades, hitos importantes, recursos y calendarios por los que se regirá el desarrollo del proyecto. Como resultados de esta etapa, además del citado plan general del proyecto, se obtienen los diferentes esquemas gráficos de funcionamiento de cada una de las alternativas propuestas, así como sus especificaciones hardware, software y de comunicaciones. Además, se dispondrá de la matriz de evaluación de las distintas alternativas que justificará la elección final de una de las mismas. 66

79 DISEÑO EXTERNO (DEX) A lo largo de esta etapa, han de completarse los siguientes objetivos: Completar el modelo de procesos, tanto lógicos como físicos, establecidos en la etapa de Análisis de Requisitos de acuerdo a las plataformas hardware y software elegidos en la etapa anterior. Definir la estrategia de los planes de pruebas, implantación, formación y conversión. En primer lugar, se introducirá en el modelo lógico, ya generado en la etapa de Análisis de Requisitos, para dar una visión física no sólo de qué hace el sistema sino de cómo lo hace. Se diseñarán las entradas y salidas del sistema, entendiéndose como entrada y salida el conjunto de ventanas, informes, ficheros y formularios que se necesiten para el correcto funcionamiento del mismo. Se especificarán los procesos con un mayor nivel de detalle, indicando características tales como en que servidor o estación se ejecutaran, frecuencias de ejecución o el tipo de arquitectura del proceso: Bach, online, cliente, servicio, clase, etc. 67

80 En esta etapa se deberán estimar los volúmenes de ficheros y transacciones críticas para servir de guía al modelo lógico de datos. Se establecen los procesos de control, seguridad y auditabilidad que sean necesarios para la gestión y operación del proceso de explotación. Son procesos de control los registros que podamos incorporar para verificar el funcionamiento correcto del sistema. Los procesos de seguridad se refieren a la protección de los componentes del sistema, tanto en su acceso como en su destrucción o pérdida. Los procesos de auditabilidad están destinados a registrar las operaciones que se realizan, con sus características organizativas. Si el proyecto no requiere de este tipo de procesos, no deberán ser incorporados. Se prepara la estrategia de instalación, mediante los planes de pruebas, implantación, formación y conversión. En esta etapa no se define ninguno de estos planes, pero si se describe la estrategia a seguir en ellos DISEÑO INTERNO (DIN) A lo largo de esta etapa se identifican y diseñan los diversos componentes software del sistema, describiendo detalladamente sus especificaciones físicas. Dependiendo de la arquitectura elegida para el desarrollo, estos componentes podrán ser muy diversos. Gracias a ello, podremos dividir el sistema en subsistemas atendiendo a la tipología de los procesos, y así especificar y diseñar sus componentes. 68

81 Los objetivos a alcanzar a lo largo de esta etapa son los siguientes: Identificar y diseñar los componentes software de cada subsistema. Especificar cada uno de los programas a desarrollar. Obtener el modelo físico de la base de datos. Completar los planes de pruebas, implantación formación y conversión. Para alcanzar los objetivos anteriores comenzaremos por la división del sistema o subsistema, diseñando cada componente según su arquitectura. Se definen y completan la estructura de los ficheros intermedios o de trabajo a utilizar en cada función de negocio: archivos temporales o intermedios, archivos de movimiento, históricos, de seguridad, etc. En la etapa anterior se diseñaron todas las entradas y salidas considerando los ficheros que se utilizarán para introducir o generar información al/del sistema. Ahora deben diseñarse aquellos ficheros intermedios utilizados en cada función. A partir del modelo lógico de datos, se obtiene el modelo físico que se constituye con las sentencias de definición y creación de la base de datos. Se desarrollan las especificaciones de los programas, o Cuadernos de Carga. Cada programa, rutina, módulo o subprograma requiere de una especificación que irá 69

82 dirigida a tres áreas diferentes. En primer lugar, este documento será utilizado por el programador a la hora de realizar su trabajo de codificación y pruebas del programa a desarrollar. En segundo lugar, estas especificaciones serán empleadas por los diseñadores de pruebas a la hora de preparar sus juegos de ensayos para comprobar la robustez del sistema. Por último, esta documentación constituye la base necesaria para poder mantener los programas desarrollados, evitándose tener que analizar el código fuente de la aplicación para averiguar cual es su función. En esta etapa, por último, se completaran los planes de pruebas, implantación, formación y conversión, cuya descripción comenzó en la etapa anterior. En esta etapa se establecerán los planes especificando las actividades, recursos humanos y materiales y el calendario de fechas de realización. Como resumen, el Output de esta etapa deberá estar formado por: el modelo físico de datos y diseño de ficheros, las especificaciones de los programas o Cuadernos de Carga y los planes de pruebas, implantación, formación y conversión PROGRAMACIÓN (PRO) A lo largo de esta etapa debemos de conseguir la transformación del sistema en un conjunto de programas que puedan ser ejecutados correctamente, bajo criterios de calidad. Los objetivos de esta etapa son los siguientes: 70

83 Codificar los programas y componentes que forman el software del sistema. Realizar la prueba unitaria de cada uno de los programas y componentes desarrollados Documentar la operación del sistema, elaborando el manual de usuario y la guía de explotación del sistema. Para ello, se comenzará por la codificación de los programas en los lenguajes establecidos según las especificaciones del Cuaderno de Cargas. Una vez finalizada la codificación de los programas, se procederá a la realización de las pruebas de los programas y componentes software del sistema. Se elaborará el manual de usuario y la guía de explotación. El manual de usuario esta compuesto por el conjunto de las instrucciones de operación del sistema y va dirigido, sobre todo, a los futuros usuarios del sistema. La guía de explotación, sin embargo, va dirigida a la las personas que en su día serán las encargadas de la explotación del sistema, debiendo establecerse en ella la planificación de tareas tanto programadas como aperiódicas, los soportes de entrada y salida que se manipulan, las operaciones de seguridad o de backup, la obtención de históricos, la parada y mantenimiento del sistema, etc. 71

84 PRUEBAS DEL SISTEMA (PRU) Una vez desarrolladas en la etapa anterior las pruebas de los componentes a nivel individual, en esta etapa deben realizarse una serie de pruebas para conseguir integrar todo el sistema, de acuerdo al Plan de Pruebas elaborado durante la etapa de Diseño Interno. Por lo tanto, el objetivo de esta etapa es someter al sistema desarrollado y a sus componentes, a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable. Esta fase es crítica y debe por lo tanto ser planificada, diseñada y realizada con el mismo rigor y control con el que se realiza el desarrollo del sistema. Para ello, comenzaremos por ejecutar el ciclo de pruebas necesarias. Este ciclo recoge las distintas pruebas alas que puede someterse el software, desde las pruebas de encadenamiento entre programas, hasta las pruebas de estrés para diagnosticar el rendimiento del sistema ante condiciones extremas de operación y concurrencia de usuarios. Se conseguirá la aprobación, por parte del cliente, de las pruebas del sistema. Una de las pruebas a realizar en el ciclo es la aceptación del usuario, donde este verifica el funcionamiento del sistema y su usabilidad ajustada a las necesidades especificadas en los requisitos. Se procederá al proceso de formación del personal que utilizará el nuevo sistema. 72

85 IMPLANTACIÓN (IMP) Una vez probada la integridad del software del sistema, llega el momento en que se debe transferir el software producido del Centro de Desarrollo o Pruebas al Centro de Producción, para llevarse a cabo la explotación del sistema. El conjunto de las actividades a desarrollar en esta fase ha sido previamente definido en las planificaciones realizadas en fases anteriores (plan de conversión y plan de implantación), siendo en esta fase donde se lleva a cabo la materialización de los mismos. Para ello, se debe preveer la migración necesaria del software configurado a cada uno de los equipos y estaciones de trabajo. Así mismo, se deberán realizar pruebas de carga y rendimiento en los equipos donde se vaya a instalar el software, garantizándose así la correcta instalación y configuración del software. Dichas pruebas deberán ser aprobadas por el cliente. Por último se cumplimentarán todas las tareas descritas en los planes de implantación, instalación y configuración MANTENIMIENTO (MAN) El ciclo de desarrollo queda finalizado con la implantación y entrega del sistema al cliente pero, generalmente, con la entrega del software suele acompañarse un período 73

86 de mantenimiento posterior en estos equipos, que ofrece al cliente una garantía de un servicio técnico para subsanar cualquier incidencia o mejora dentro del sistema. Es importante diferenciar entre dos tipos de mantenimiento: Mantenimiento correctivo. Consiste en la atención de las incidencias y errores detectados durante la operación del sistema, debiéndose diagnosticar, subsanar y actualizar rápidamente para mantener el nivel de servicio esperado por él. Mantenimiento adaptativo. Atiende a las mejoras y versiones del software o del sistema, debido a cambios en el negocio o incorporación de nueva tecnología. En este punto, deberá pactarse con el cliente el tipo de mantenimiento, en caso de darse, que se le ofrecerá, así como el periodo de tiempo durante el cual se dará ESTRUCTURA DE DIVISIÓN DEL TRABAJO (EDT) En la siguiente figura se muestra el Esquema de división de Tareas, también conocido como EDT, donde se pueden observar el conjunto de paquetes de trabajo, o Work Packages (WP), en los que se va a dividir el desarrollo del proyecto, así como el conjunto de actividades que los componen. El propósito de cada uno de los paquetes de trabajo y sus actividades ha sido proporcionada en anteriores puntos dentro de este capitulo dedicado a la Metodología del proyecto. 74

87

88 3. Identificación de Necesidades

89 3. IDENTIFICACIÓN DE NECESIDADES 3.1. INTRODUCCIÓN En esta fase se deben definir las relaciones entre los participantes en el desarrollo del proyecto. Para ello, se realizan una serie de reuniones en las que se debe dejar definidos ciertos aspectos de la herramienta, tales como: los objetivos que se pretende alcanzar con su desarrollo y el alcance, la tipología de usuarios y sus requerimientos, restricciones de todo tipo que afecten de manera directa al desarrollo del proyecto, la estructura organizativa del equipo (empresa) y los antecedentes del sistema en el caso de que los hubiese. Dada la naturaleza del proyecto, se necesitará información de los elementos manejados por un SGA, así como los elementos específicos involucrados en una Orden de Compra. Una vez obtenidos los datos por separado, a través de la realización de varias entrevistas con usuarios de las herramientas, nuestra tarea consistirá en la definición de un estándar que recopile toda la información coincidente en ambos sistemas, lo que a su vez ayudará en la definición de objetivos y alcance del propio proyecto. Por último, en esta fase se analizan los antecedentes del sistema, lo cual, en el caso de que los hubiese, ayudará a la mejor comprensión de la herramienta, ya que agilizará la inducción de conocimiento en las entrevistas mediante la preparación de éstas por parte del entrevistador, es decir, nosotros mismos. 77

90 3.2. OBJETIVOS DEL SISTEMA El principal objetivo del sistema consiste en la creación de un sistema que actúe como intermediario entre el sistema de gestión de activos de nuestra empresa (DATASTREAM) y los sistemas gestores de compras de nuestras empresas cliente, que pueden ser de cualquier tipo (ORACLE, SAP, NAVISION, etc.). Es justo por este motivo, el que las empresas cliente puedan tener instalados gestores de compras propios y no deseen cambiarlo, que se hace necesario el desarrollo de una aplicación que haga de intermediaria entre estos sistemas y, por lo tanto, se justifica el desarrollo de nuestro proyecto. A continuación se muestra un gráfico esquemático resumen de esta situación: 78

91 El objetivo final del sistema consiste en la definición de todos los activos de valor para poder realizar su gestión sea cual sea el SGA utilizado. De esta manera, tras construir nuestro sistema conseguiremos un estándar de comunicación universal entre sistemas gestores de activos y de compras usando la herramienta más extendida de almacenamiento de bases de datos (Access), abarcando por tanto la mayor amplitud de usuarios posible. La herramienta debe permitir, por tanto, comunicación entre ambas partes, facilitando el proceso de transmisión y conversión de los datos de forma totalmente transparente al usuario. Se pretende abordar el proyecto ya que resulta una propuesta interesante en el mercado de la gestión de activos, teniendo en cuenta la ausencia actual de una herramienta que permita la función del sistema que se pretende desarrollar. Por tanto, el desarrollo se ve altamente justificado para empresas que haciendo uso de una herramienta de gestión de activos, necesiten comunicarse o intercambiar parte o el total de su información con otra u otras empresas, o, por ejemplo, si una misma empresa hace uso de distintas herramientas de este tipo en diferentes departamentos o sedes y necesita tener centralizada o unificada toda la información. 79

92 3.3. ALCANCE DEL SISTEMA El alcance del proyecto está limitado inicialmente, ya que en lo referente al almacenamiento de datos se pretende realizar el desarrollo para Access, siendo ampliable a medida que se vaya desarrollando la herramienta o en el futuro (Toad de Oracle, DB2, MySql, etc.). El alcance real es la definición y creación de una base de datos universal donde se centralicen todos los datos para la gestión de activos, así como el desarrollo de una herramienta capaz de realizar el proceso de conversión y traducción de los datos entre este tipo de sistemas. Las funciones más importantes en el desarrollo del sistema se especifican a continuación: Definición de los datos de valor. En esta fase se pretende hacer una recopilación de todos los datos necesarios que intervengan habitualmente en una operación de compras. Para ello, analizaremos por separado los datos requeridos en un SGA elegido por nosotros (DS en nuestro caso), así como los datos usados generalmente en la gestión de compras. Creación de la base de datos. Una vez tengamos definidos los datos de valor a gestionar en nuestro sistema, procederemos a la creación de una base de datos en Access basándonos en estos datos. 80

93 Creación de la Interfaz. A partir de este momento, la tarea se centrará en la construcción de la aplicación, centrándonos en las tareas de conversión de los datos entre sistemas así como de que esto se realice de la forma más transparente posible a los usuarios TIPOLOGÍA DE USUARIOS La tipología de los usuarios finales de este proyecto será cualquier persona que intervenga en el proceso de compras de la empresa así como cualquiera que tenga relación con la gestión y control de activos de la misma (áreas de Finanzas, Mercado, Producción, Personal, etc.). La gestión de los usuarios de la aplicación será llevada a cabo por el administrador de la herramienta, el cual posee privilegios totales sobre ésta. Los usuarios no administradores, sin embargo, tendrán un acceso restringido a la herramienta por lo que sólo podrán acceder a las partes específicas diseñadas para los usuarios de nuestras empresas cliente. 81

94 3.5. RESTRICCIONES El proyecto está sujeto básicamente a dos tipos de restricciones: De tipo temporal: la falta de tiempo es la principal restricción del proyecto. El plazo para que la herramienta esté totalmente operativa está fijada para mediados del mes de Mayo de Al tipo de herramientas: hay que tener en cuenta que para la realización de nuestro proyecto, hemos elegido un SGA específico, en concreto DATASTREAM 3.6. ORGANIZACIÓN DEL PROYECTO En este módulo se va a mostrar un organigrama que representa un esquema de las partes implicadas en el proyecto. Este quedará dividido de la siguiente manera: 82

95 3.7. ANTECEDENTES DEL SISTEMA La empresa, actualmente, no dispone de una herramienta que cuente con las características del sistema que se pretende construir. Fuera de la empresa, tampoco se conoce ninguna herramienta que ofrezca este servicio, por lo que se considera una buena oportunidad de negocio, a parte, obviamente, de aprovecharla para la propia explotación dentro de la empresa, lo cual les permitiría unificar todos los sistemas de gestión de activos en un único sistema; el principal beneficio que puede obtener la empresa será la optimización de los servicios que ofrecen los SGA en términos totales. Como ya se ha comentado anteriormente, la herramienta será totalmente escalable por lo que en el futuro se podrán añadir todas las nuevas funcionalidades asociadas que se deseen, así como hacer extensible el manejo de los datos a cualquier tipo de herramienta de bases de datos. Los objetivos básicos de la empresa a la hora de poner en funcionamiento la herramienta son, como casi siempre, el ahorro de tiempo y dinero. Ya se han citado las ventajas y beneficios del uso de los SGA, por lo que a cualquier empresa le beneficiaría poder realizar ésta tarea sea cual sea la cantidad que posea de sistemas de este tipo. Por otra parte, no hay que olvidar que uno de los objetivos más importantes del desarrollo del proyecto siempre ha sido el contar con un sistema de control dinámico de todos los activos con los que cuenta una empresa, sean del tipo que sean. Este control complementa a su vez los objetivos de ahorro de tiempo y dinero, ya que ese es justamente el objetivo principal de un SGA. Con todo ello, se pretende la mejora de la calidad del servicio del sistema. 83

96 3.8. PLANIFICACIÓN

97 4. Análisis de requisitos

98 4. ANÁLISIS DE REQUISITOS 4.1. INTRODUCCIÓN En esta fase del proyecto se profundiza en los requisitos necesarios para conseguir los objetivos fijados anteriormente. Este análisis consumirá un tiempo considerable ya que se necesitan definir claramente las funcionalidades de la herramienta, así como los procesos actuales mediante los cuales se realizan las operaciones de compras y de gestión de activos, y, por último, el proceso de toda esta información dando como resultado los datos necesarios para la definición de la base de datos unificada. Todo ello se realizará por medio de sucesivas entrevistas con usuarios finales de las herramientas en cuestión, lo cual se considera el método más oportuno para la comprensión de los procesos y poder realizar la herramienta de la manera más necesaria y útil para los propios usuarios de la misma. Los objetivos fijados en la etapa de identificación de necesidades así como los requisitos de la aplicación se citan a continuación: Descripción de un proceso de Orden de Compra. Lista de requisitos. Características de cada requisito. 86

99 4.2. DESCRIPCIÓN DE UN PROCESO DE ORDEN DE COMPRA A continuación se va a realizar una breve descripción de todos los elementos implicados en un proceso completo de compras. El proceso es el siguiente: Rellenar OC Registrar en el Sistema Si Correcta? Actualización en BBDD No Resolución Incidencia Notificar a usuario Al rellenarse una Orden de Compra, el sistema comprueba si los datos introducidos son correctos y, a parte, si se han introducido todos los datos requeridos obligatoriamente, ya que algunos de los campos de una OC son opcionales mientras que otros, los requeridos, son obligatorios. 87

100 Tras mostrar al usuario el motivo del fallo, si este decide solucionarlo, el sistema vuelve a procesar la OC realizando las mismas comprobaciones y, en el caso de que todo sea correcto, se registra en el sistema con el consecuente reflejo en la base de datos. A continuación se muestran los posibles errores que pueden producirse en el proceso de dado de alta de una OC: El usuario no ha introducido la organización a la que le será asignada la OC. El usuario no ha introducido el almacén al que se enviará y se asignará la OC. El usuario no ha introducido el originador de la OC, es decir, el responsable en última instancia de esta. El usuario no ha introducido la fecha de vencimiento de la OC. El usuario no ha introducido el proveedor correspondiente asociado. El usuario no ha introducido el tipo de moneda asociada al proveedor. Una vez la OC ha sido procesada de forma correcta, el siguiente paso es registrarla en el sistema. El estado con el que se puede registrar puede tomar tres valores: incompleto, aprobado y cancelado. Una vez que la OC adquiere uno de los estados aprobado o cancelado, el resto de campos quedan deshabilitados por lo que los datos se convierten en finales y no se pueden volver a modificar. 88

101 4.3. LISTA DE REQUISITOS Definición y creación de una base de datos única. Crear un listado con toda la información de la base de datos. Información detallada de una Orden de Compra. Gestión de acceso a la aplicación. Gestión de acceso a la información. Realizar un pre-diseño de las pantallas del futuro sistema. Generación de comentarios ante incidencias. Tratamiento de duplicidad en los datos. Listado de Meta-Modelos de datos e impresión en fichero. Listado de Tareas por usuario e impresión en fichero. 89

102 4.4. CARACTERÍSTICAS DE CADA REQUISITO En este punto se van a comentar las características de cada uno de los requisitos citados en el apartado anterior: Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Definición y creación de una base de datos única Fecha Versión Origen Identificación de requisito 29/09/ Jefe de Proyecto R1 Descripción del requisito Definición y creación de una base de datos unificada que contenga toda la información de nuestra empresa así como de nuestras empresas cliente. Objetivo Agilizar el trabajo relacionado con bases de datos de los clientes, aportando mayor cantidad de información sobre los datos así como facilitando su gestión. 90

103 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Crear un listado con toda la información de la base de datos. Fecha Versión Origen Identificación de requisito 13/10/ Jefe de Proyecto R2 Descripción del requisito Definición de un listado que contenga todos los meta-modelos de tablas de las bases de datos existentes actualmente, tanto para nuestra empresa como para nuestras empresas cliente. Objetivo Agilizar posteriormente la tarea de asociación de las distintas entidades y sus atributos relacionados en el proceso de definición de Meta-Modelos de datos. 91

104 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Información detallada de una Orden de Compra. Fecha Versión Origen Identificación de requisito 13/10/ Jefe de Proyecto R3 Descripción del requisito Recopilar información sobre estándares en la realización del proceso de compras, es decir, toda la posible información de valor que esté relacionada con una Orden de Compra. La realización de esta recopilación de información se debe realizar, como mínimo, en todas nuestras empresas cliente. Objetivo Agilizar el proceso posterior de definición de un estándar de Orden de Compra así como la obtención de información valiosa del propio proceso por el que atraviesa una Orden, y los elementos que intervienen en este proceso. 92

105 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Gestión de acceso a la aplicación. Fecha Versión Origen Identificación de requisito 14/10/ Jefe de Proyecto R4 Descripción del requisito Definición de las políticas de seguridad para usuarios según sus privilegios. Objetivo Evitar el uso indebido de la aplicación. 93

106 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Gestión de acceso a la información. Fecha Versión Origen Identificación de requisito 14/10/ Jefe de Proyecto R5 Descripción del requisito Definición del alcance sobre la información de cada tipo de usuario. Cada usuario deberá poder acceder a los datos relacionados a la empresa (y, por tanto, sistema) a la que pertenece y en ningún caso a datos de otras empresas. Objetivo Asegurar a nuestros clientes unos niveles de seguridad y fiabilidad adecuados. 94

107 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Realizar un pre-diseño de las pantallas del futuro sistema. Fecha Versión Origen Identificación de requisito 15/10/ Jefe de Proyecto, Cliente R6 Descripción del requisito Realizar un pre-diseño en papel de las pantallas a las que va a acceder un usuario de la herramienta dependiendo del tipo que sea, definiendo, por tanto, tanto la navegación como los elementos intervinientes en cada pantalla. Objetivo Realizar una estimación del alcance y de las dimensiones de la herramienta, así como la agilización del proceso posterior de diseño y desarrollo. 95

108 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Generación de comentarios ante incidencias. Fecha Versión Origen Identificación de requisito 16/10/ Jefe de Proyecto R7 Descripción del requisito Definición de unos estándares así como la elaboración de un listado de comentarios que mostrará la herramienta ante posibles incidencias o errores, definiendo el origen del problema así como los pasos para su resolución. Objetivo Tener una base de documentación sobre el uso de la herramienta. Ello nos agilizará posteriormente la batería de pruebas de la herramienta así como la elaboración del manual de usuario final. 96

109 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Tratamiento de duplicidad en los datos. Fecha Versión Origen Identificación de requisito 16/10/ Jefe de Proyecto R8 Descripción del requisito Definición de unos protocolos de actuación ante posibles duplicados en el sistema así como el control y validación de los datos de entrada y, por lo tanto, su formato. Objetivo Asegurar coherencia en los datos y, como consecuencia, fiabilidad del sistema. 97

110 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Listado de Meta-Modelos de datos e impresión en fichero. Fecha Versión Origen Identificación de requisito 16/10/ Jefe de Proyecto, Cliente R9 Descripción del requisito Definición de la pantalla en la que se van a mostrar los datos relacionados con los metamodelos definidos, del contenido así como del formato de estos datos. Se debe definir, por otra parte, el formato del fichero en el que se van a mostrar los datos. Objetivo Agilizar el proceso posterior de diseño y codificación de la pantalla. 98

111 Identificación HOJA DE REQUISITOS Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de Compras. Jefe de proyecto: Javier Sánchez Jiménez Requisito Listado de Tareas por usuario e impresión en fichero. Fecha Versión Origen Identificación de requisito 13/10/ Jefe de Proyecto, Cliente R10 Descripción del requisito Definición de la pantalla en la que se van a mostrar los datos relacionados con las Tareas definidas, del contenido así como del formato de estos datos. Se debe definir, por otra parte, el formato del fichero en el que se van a mostrar los datos. Objetivo Agilizar el proceso posterior de diseño y codificación de la pantalla. 99

112 4.5. DIAGRAMA DE CONTEXTO Como se puede observar en el diagrama, existen 2 entidades externas claramente diferenciadas: nuestra empresa, en la que contamos con una base de datos propia de nuestro sistema de gestión de activos (DataStream), y las empresas cliente, que siendo cual sea su número, cada una de ellas contará a su vez con una base de datos propia del sistema de gestión de compras que tengan instalado. Dos empresas cliente pueden contar con el mismo sistema de gestión de compras y, sin embargo, tener las bases de datos distintas (las bases de datos están particularizadas). El objetivo de la herramienta es unificar toda la información y permitir su completa gestión. 100

113 A continuación vamos a proceder a describir las bases de datos con las que va a contar nuestro sistema: Meta-Modelos de Datos. Está formada por varias tablas. Almacena todos los Meta-modelos de datos creados para los clientes. No existe limitación en el número de Meta-modelos definidos entre dos sistemas. La base de datos será de lectura y escritura. Ficheros. Almacén de los ficheros creados con información relativa a Metamodelos de datos y de Tareas de clientes. Los ficheros son creados por la herramienta a solicitud de un cliente, por lo que únicamente mostrarán datos asociados a la empresa y sistema que tenga asociados éste. La base de datos será de escritura. Como se ha citado anteriormente, nuestra empresa y los clientes son los que van a suministrar los datos requeridos a nuestro sistema, mientras que el usuario (administrador de la herramienta) va a poder hacer uso de esta información según las distintas posibilidades implementadas en la aplicación. En los diagramas de flujo de primer y segundo nivel se especificará en mayor detalle en contenido de estos flujos. 101

114 4.6. DIAGRAMA DE PRIMER NIVEL En el anterior diagrama se muestra, de forma general, los principales procesos con los que va a contar la aplicación. A continuación se va a proceder a realizar una breve descripción de cada uno de los procesos. Se procederá a realizar una mayor profundización (o explosión) de aquellos procesos que cuenten con una mayor complejidad, procurando darles una mayor especificación. 102

115 Login: al entrar en la aplicación el usuario introduce sus datos (nombre de usuario y contraseña) para que el sistema los valide. Una vez los datos han sido validados, el sistema comprueba el perfil del usuario determinando los privilegios con los que contará dentro de la aplicación. Menú general aplicación: se procede a mostrar las diferentes opciones que ofrece la aplicación según los privilegios del usuario que accede. Las opciones se enumeran a continuación: Menú administrador: el usuario que accede es de tipo administrador y, por lo tanto, tiene acceso completo a las opciones que ofrece la aplicación (operaciones de consulta, alta, baja y modificación). Sus diferentes opciones son: 1. Gestión Meta-Modelo de datos. a. Administración Modelo de datos de DATASTREAM. b. Administración Modelo de datos de Sistemas Gestores de Compras. c. Administración de Casos. 2. Gestión de Jobs. a. Gestión de Tareas. b. Gestión de Frecuencias. c. Gestión de Tipos de Tareas. d. Gestión de Jobs. 103

116 3. Administración de Empresas Sistemas. 4. Gestión de usuarios. Menú usuario: el usuario que accede es de tipo usuario y, por lo tanto, tiene acceso restringido a las opciones que ofrece la aplicación (operaciones de consulta). 1. Visualización Meta-Modelo de datos. 2. Visualización de Jobs - Tareas. Como se puede comprobar, los usuarios no administradores cuentan con un menú distinto al del administrador, quedando restringido su área de acción a consulta de información asociada a su propia empresa y sistema. Administración de usuarios: el usuario administrador es capaz de realizar una típica gestión de los usuarios de un sistema; si el usuario cuenta con privilegios suficientes, es decir, es administrador del sistema, será capaz de llevar a cabo una gestión de los usuarios ya existentes (modificación y baja) así como de realizar los pasos necesarios para dar de alta a nuevos. En cualquier caso, no se permite dar de baja al usuario Administrador. Gestión del meta-modelo de datos: esta opción ofrece la posibilidad de la gestión de los meta-modelos de datos, siempre y cuando se sea el usuario administrador, y representa el núcleo principal de la aplicación. 104

117 Editor de Jobs: el usuario de tipo administrador es capaz de realizar la gestión total de todos los procesos relacionados con Jobs y tareas, así como de todos los elementos implicados en estos dos procesos (Tipos de tareas y frecuencias). Los usuarios no administradores tienen la posibilidad de consulta de los Jobs creados con todas sus tareas asociadas. Gestión de Empresas - Sistemas: el usuario administrador es el encargado de la gestión de la información de nuestras empresas cliente así como de sus sistemas de gestión de compras asociadas. Visualización Meta-modelos de datos: esta opción ofrece a los usuarios cliente la posibilidad de visualización en formato de tabla de todos los Meta- Modelos de datos asociados a su empresa y sistema, así como la generación de un fichero de salida con toda esta información. Visualización Jobs - Tareas: esta opción ofrece a los usuarios cliente la posibilidad de visualización en formato de tabla de todas las tareas dependientes de sus Jobs, así como la generación de un fichero de salida con toda esta información. 105

118 4.7. DIAGRAMAS DE SEGUNDO NIVEL Login Validar usuario: al introducir el usuario sus credenciales, nombre y contraseña, el sistema valida estos datos en la base de datos de USUARIOS, donde se valida tanto si existe el usuario como si la contraseña es válida, dando como resultado el tipo de usuario que accede a la aplicación para ser usado en el siguiente proceso Asignar privilegios usuario: recibe el tipo de usuario que accede a la aplicación y establece los privilegios asociados a ese tipo de usuario, determinando, por tanto, las opciones que tendrá habilitadas de la aplicación (filtros de información). 106

119 Administración de usuarios Gestión de usuarios: el usuario administrador es capaz de realizar una gestión típica de los usuarios del sistema. Los cambios se darán de alta en la base de datos de USUARIOS, mientras que de la tabla EMPRESAS-SISTEMAS se leerán las distintas empresas sistemas dadas de alta para la inserción de un nuevo usuario en una de ellas. Como se ha comentado anteriormente, el Administrador puede dar de baja cualquier usuario pero no se puede dar de baja a sí mismo. Esto se decidió que fuera así debido a la intención de centralizar toda la gestión en un único usuario de nuestra empresa, y así evitar gestiones paralelas que pudiesen provocar incoherencia en los datos de las tablas. 107

120 Administración del meta-modelo de datos Menú Meta-modelo: se muestran las diferentes opciones permitidas respecto a la administración del meta-modelo de datos, siendo en total 4: Administración del modelo de datos de DATASTREAM, Administración del modelo de datos de SGC, Administración de casos y, por último, análisis del Meta-modelo Administración Modelo de datos DATASTREAM: ofrece la posibilidad de gestión de los diccionarios de datos (Entidades DS y de Atributos DS) del sistema DATASTREAM con el que cuenta nuestra empresa, lo cual afecta a los diccionarios de Entidades y Atributos generales de la aplicación dada la relación existente entre las tablas. 108

121 4.3.- Administración Modelo de datos SGC s: ofrece la posibilidad de gestión de los diccionarios de datos (Entidades SGC y de Atributos SGC) de los diferentes Sistemas de Compras con los que cuentan nuestros clientes, lo cual afecta de igual manera a los diccionarios de Entidades y Atributos generales Administración de Casos: ofrece la posibilidad de gestión de los Casos definidos entre un Atributo de una Entidad de DS y un Atributo de una Entidad de SGC. El siguiente gráfico muestra un ejemplo de éste proceso de asociación o Caso: 109

122 4.5.- Análisis de Meta-Modelos: este proceso realiza un análisis de coherencia y validado de datos que intervienen en el proceso de asociación. Su función es avisar de cualquier incidencia o problema encontrado durante el proceso. Edición de Jobs Menú Editor Jobs: se muestran las diferentes opciones permitidas respecto a la gestión de Jobs, siendo en total 4: Gestión de tareas, Gestión de frecuencias, Gestión de tipos de tareas y Gestión de Jobs. 110

123 5.2.- Gestión de Tareas: ofrece la posibilidad de gestión de las tareas almacenadas en el sistema; cada tarea tendrá asociada un Job específico. Éste proceso requiere de la lectura de tres bases de datos correspondientes a los diferentes atributos con los que cuenta una Tarea: la frecuencia con la que se va a realizar, el tipo de la Tarea y la Entidad a la que se atribuye la ejecución de la propia Tarea Gestión de frecuencias: ofrece la posibilidad de gestión de las frecuencias que luego serán asignadas a las tareas que se den de alta en el sistema. Cada tarea tendrá asociada una frecuencia específica Gestión de tipos de tareas: ofrece la posibilidad de gestión de los diferentes tipos de tareas que se pueden llevar a cabo en las entidades de nuestro sistema. Cada tarea tiene asociada un tipo de tarea específica. 111

124 Visualización de Meta-Modelos de datos Seleccionar Entidad: una vez el usuario accede a esta pantalla, se le ofrece la posibilidad de seleccionar entre las distintas Entidades definidas en su empresa sistema para mostrar únicamente los meta-modelos asociados a estas Entidades Visualización de Meta-Modelos: una vez el usuario ha seleccionado una Entidad específica, se le muestran todos los meta-modelos asociados a esta Entidad en formato de tabla. 112

125 7.3.- Imprimir Listado: se ofrece la posibilidad al usuario de realizar una impresión en papel de la tabla resultado según el filtrado realizado previamente por éste Generar documento: se ofrece la posibilidad al usuario de crear un fichero con la información específica que haya seleccionado previamente. Visualización de Jobs-Tareas Seleccionar Job: una vez el usuario accede a esta pantalla, se le ofrece la posibilidad de seleccionar entre los distintos Jobs que tiene asociados Visualización de Tareas: una vez el usuario ha seleccionado un Job específico, se le muestran todos los datos asociados a la Tarea específica en formato de tabla. 113

126 8.3.- Imprimir Listado: se ofrece la posibilidad al usuario de realizar una impresión en papel de la tabla resultado según el filtrado realizado previamente por éste Generar documento: se ofrece la posibilidad al usuario de crear un fichero con la información específica que haya seleccionado previamente MODELO CONCEPTUAL DE DATOS El Modelo de Datos describe las características principales de los datos del sistema, es decir, determina cuáles son las familias o entidades de datos de negocio, sus relaciones y sus atributos más importantes. Se utiliza la información de los flujos de datos, almacenes, registros y atributos del modelo lógico para identificar las entidades de datos del sistema. Los datos están normalizados, ya que están identificados los grupos diferentes de información y sus dependencias consiguiendo una arquitectura coherente con el sistema mecanizado. Todas las tablas cumplen con las tres formas normales de la normalización: 114

127 Primera Forma Normal (1FN): Una entidad está en 1FN si cada atributo que la constituye, y que no participa como identificador de ella, es pendiente funcional de dicho identificador. Segunda Forma Normal (2FN): Una entidad está en 2FN si está en 1FN, y si todos los atributos que la constituyen y que no participan como identificador son dependientes funcionales de la totalidad del identificador y no de una sola parte de éste. Tercera Forma Normal (3FN): Una entidad está en 3FN si todos los atributos que la componen, y que no constituyen el identificador de ella, son independientes funcionales entre sí. Normalizando el Modelo de Datos se consigue evitar redundancias y dar integridad a los datos. El modelo de Datos lógico final se muestra a continuación: 115

128 Las tablas que componen el sistema así como sus atributos se describen a continuación: 116

129 Tabla USUARIOS: tabla en que se almacena toda la información relativa a usuarios de la aplicación. Dicha tabla cuenta con los siguientes campos: NOMBRE_USUARIO: Nombre del usuario de la aplicación. CONTRASEÑA: Contraseña del usuario de la aplicación. PRIVILEGIOS: identificador que indica los privilegios asociados a un usuario. NOMBRE_EMPRESA_SISTEMA: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado. Tabla EMPRESAS-SISTEMAS: tabla en que se almacena toda la información relativa a las empresas cliente con sus respectivos sistemas de Gestión de compra asociado. Dicha tabla cuenta con los siguientes campos: NOMBRE_EMPRESA_SISTEMA: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado. DESCRIPCIÓN_EMPRESA_SISTEMA: Descripción de la Empresa y su SGC (opcional). Tabla ENTIDADES: tabla en que se almacena toda la información cruzada relativa a entidades. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD_TOTAL: Número de identificador único de la entidad (sea del sistema que sea). 117

130 NOMBRE_ENTIDAD: Nombre de la entidad. NOMBRE_EMPRESA_SISTEMA: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado. Tabla ATRIBUTOS: tabla en que se almacena toda la información cruzada relativa a atributos. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD: Número de identificador de la entidad. NOMBRE_ENTIDAD: Nombre de la entidad. IDENTIFICADOR_ATRIBUTO_TOTAL: Número de identificador único del atributo (sea del SGC que sea). IDENTIFICADOR_ATRIBUTO_DS: Número identificador del atributo de DS. NOMBRE_ATRIBUTO: Nombre del Atributo. NOMBRE_EMPRESA_SISTEMA: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado. Tabla ENTIDADES_DS: tabla en que se almacena toda la información relativa a entidades de la base de datos de DS. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD_DS: Número de identificador de la entidad de DS. NOMBRE_ENTIDAD_DS: Nombre de la entidad de DS. 118

131 NOMBRE_EMPRESA_SISTEMA_DS: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado nuestra empresa (AE y DS, respectivamente). Tabla ATRIBUTOS_DS: tabla en que se almacena toda la información relativa a atributos de la base de datos de DS. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD_DS: Número de identificador de la entidad de DS. NOMBRE_ENTIDAD_DS: Nombre de la entidad de DS. IDENTIFICADOR_ATRIBUTO_DS: Número identificador del atributo de DS. NOMBRE_ATRIBUTO_DS: Nombre del atributo de DS. NOMBRE_EMPRESA_SISTEMA_DS: Nombre compuesto de la empresa y del sistema de gestión que tiene integrado nuestra empresa (AE y DS, respectivamente). Tabla ENTIDADES_SGC: tabla en que se almacena toda la información relativa a entidades de un SGC. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD_SGC: Número de identificador de la entidad del SGC específico. NOMBRE_ENTIDAD_SGCX: Nombre de la entidad del SGC específico. 119

132 NOMBRE_EMPRESA_SISTEMA_ SGC: Nombre compuesto de la empresa y del sistema de gestión de compras que tiene integrado. Tabla ATRIBUTOS_SGC: tabla en que se almacena toda la información relativa a atributos de las bases de datos de SGC. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_ENTIDAD_SGC: Número de identificador de la entidad de SGC específica. IDENTIFICADOR_ATRIBUTO_SGC: Número identificador del atributo de SGC específico. NOMBRE_ATRIBUTO_SGC: Nombre del atributo del SGC específico. Tabla CASOS: tabla en que se almacena toda la información relativa a relaciones entre entidades entre DS y entidades de cualquier SGC s. Se podrán definir tantos casos (o metamodelos de datos) como se desee. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_CASO: Número de identificador del caso. NOMBRE_CASO: Nombre específico del caso (único). IDENTIFICADOR_ENTIDAD_DS: Número identificador de la entidad de DS. IDENTIFICADOR_ENTIDAD_SGC: Número identificador de la entidad de SGC específica. 120

133 IDENTIFICADOR_ATRIBUTO_DS: Número identificador del atributo de DS. IDENTIFICADOR_ATRIBUTO_SGC: Número identificador del atributo de SGC específico. Tabla JOBS: tabla en que se almacena toda la información relativa a JOBS. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_JOB: Número de identificador del JOB. NOMBRE_JOB: Nombre único del Job. DESCRIPCIÓN_JOB: Descripción del Job (opcional). NOMBRE_USUARIO: Nombre del usuario asignado al JOB. Tabla TAREAS: tabla en que se almacena toda la información relativa a tareas. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_JOB: Número de identificador del JOB. IDENTIFICADOR_TAREA: Número de identificador de la tarea. NOMBRE_TAREA: Nombre de la Tarea. IDENTIFICADOR_TIPO_TAREA: Número de identificador del tipo de tarea asociado a la tarea. IDENTIFICADOR_FRECUENCIA: Número de identificador de la frecuencia asociada a la Tarea. IDENTIFICADOR_ENTIDAD: Número de identificador de la entidad asociada a la tarea. 121

134 Tabla TIPOS_TAREAS: tabla en que se almacena toda la información relativa a tipos de tareas. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_TIPO_TAREA: Número de identificador del tipo de tarea. NOMBRE_TIPO_TAREA: Nombre del tipo de tarea. DESCRIPCIÓN_TIPO_TAREA: descripción del tipo de la tarea (opcional). Tabla FRECUENCIAS: tabla en que se almacena toda la información relativa a frecuencias. Dicha tabla cuenta con los siguientes campos: IDENTIFICADOR_FRECUENCIA: Número de identificador de la frecuencia. NOMBRE_FRECUENCIA: Nombre de la tarea. DESCRIPCIÓN_TIPO_TAREA: descripción de la frecuencia (opcional). 122

135 5. Estudio de la Arquitectura 123

136 5. ESTUDIO DE LA ARQUITECTURA 5.1. INTRODUCCIÓN En este apartado se describe la arquitectura seleccionada para el proyecto así como los distintos recursos Software y Hardware requeridos para el posible desarrollo y explotación de la aplicación ARQUITECTURA SOFTWARE El proyecto se ha realizado bajo el sistema operativo Windows XP Profesional. El proceso de documentación y preparación de su formato se ha realizado mediante Microsoft Office Word 2003, mientras que para la realización de los distintos diagramas y gráficos se ha utilizado Microsoft Office Power Point La tecnología que se va a utilizar para el desarrollo de la aplicación será JAVA. Para ello, vamos a hacer uso de dos entornos de desarrollo integrados: Eclipse SDK y NetBeans IDE 6.5. La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados módulos. Un módulo es un archivo Java que contiene clases de java escritas para interactuar con las API s de NetBeans y un archivo especial (manifest file) que lo identifica como módulo. Las aplicaciones construidas a partir de módulos pueden ser extendidas agregándole nuevos módulos. 124

137 Debido a la modularidad ofrecida por NetBeans, se subdividirá la codificación en dos partes: 1) Diseño exterior de las pantallas (diseño gráfico). La herramienta empleada para el desarrollo será NetBeans. 2) Diseño interno (lógica de la aplicación). La herramienta empleada en este caso será Eclipse SDK. En el desarrollo de la base de datos se va a utilizar Microsoft Office Access 2003 para garantizar la viabilidad de intercambio de información entre ambos sistemas puesto que es el sistema de gestión de bases de datos relacional más extendido en todo el mundo empresarial. Como ya se ha comentado anteriormente, se pretende que el sistema sea escalable por lo que su uso puede ser extendido en el futuro a otras aplicaciones de gestión de datos tales como MySQL o SQL Server. La Gestión de Activos se realiza actualmente en nuestra empresa mediante la herramienta de Gestión de activos empresariales Infor EAM Enterprise Asset Management, más conocido como DATASTREAM. Por último, comentar que cualquiera de las aplicaciones de Gestión de Compras usada por los clientes (SAP, ORACLE, NAVISION, etc.) tiene características similares a la herramienta Infor EAM. 125

138 5.3. ARQUITECTURA HARDWARE El proyecto se va a realizar, tanto el desarrollo de la aplicación como el de la documentación, sobre un Packard Bell modelo EasyNote, que cuenta con un procesador Intel Pentium M 1,73 GHz. La impresora utilizada para las pruebas de impresión de ficheros corresponde a un modelo HP PSC 750. La empresa en la que trabajamos y, por lo tanto, que cuenta con el Sistema de Gestión de Activos DATASTREAM instalado, cuenta con una serie de ordenadores que cuentan con las siguientes especificaciones: Hewlett-Packard Company HPCompaq dc7800 Convertible Intel Core 2 Duo CPU con 1,95 GHz de RAM Microsoft Windows XP Profesional Service Pack 2 Para la óptima visualización de la herramienta se debe establecer una resolución de pantalla de 1440x900 píxeles. 126

139 6. Diseño 127

140 6. DISEÑO 6.1. INTRODUCCIÓN En esta fase del proyecto se va a proceder a mostrar las diferentes ventanas de entrada y salida de datos del sistema. El programa empleado para la elaboración de las pantallas es NetBeans IDE MODELO FÍSICO DE PROCESOS El modelo físico de procesos representa la estructura del sistema y la organización de sus componentes: Componentes: aplicaciones, programas, módulos, procedimientos. Organización de dichos componentes. Un modelo físico puede ser interpretado con diagramas de estructura, con flujogramas, con esquemas de proceso o con una combinación de éstos. En nuestro caso, hemos optado por realizarlos en pseudocódigo de alto nivel. 128

141 PSEUDOCÓDIGO PROCESO GESTIÓN ENTIDADES DS (PFC_PRO_01) Cargar_Datos (Entidades_DS) Si (Opción = Modificar) Entonces Leer (Nombre_Entidad_DS) Actualizar_Entidad (Id_Entidad_DS, Nombre_Entidad_DS, Nombre_Empresa_Sistema_DS) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Entidad (Id_Entidad_DS) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Entidad_DS) Insertar_Entidad (Nombre_Entidad_DS, Nombre_Empresa_Sistema_DS) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE ATRIBUTOS DS (PFC_PRO_02) Cargar_Datos (Entidades_DS) Cargar_Datos (Atributos_DS) 129

142 Si (Opción = Modificar) Entonces Leer (Nombre_Atributo_DS) Actualizar_Atributo (Id_Entidad_DS, Nombre_Entidad_DS, Id_Atributo_DS, Nombre_Atributo_DS, Nombre_Empresa_Sistema_DS) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Atributo (Id_Atributo_DS) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Atributo_DS) Insertar_ Atributo (Id_Entidad_DS, Nombre_Entidad_DS, Nombre_Atributo_DS, Nombre_Empresa_Sistema_DS) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE ENTIDADES SGC (PFC_PRO_03) Cargar_Datos (Nombre_Empresa_Sistema_SGC) Cargar_Datos (Entidades_SGC) Si (Opción = Modificar) Entonces 130

143 Leer (Nombre_Entidad_SGC) Actualizar_Entidad (Id_Entidad_SGC, Nombre_Entidad_SGC, Nombre_Empresa_Sistema_SGC) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Entidad (Id_Entidad_SGC) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Entidad_SGC) Insertar_Entidad (Nombre_Entidad_SGC, Nombre_Empresa_Sistema_SGC) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE ATRIBUTOS SGC (PFC_PRO_04) Cargar_Datos (Nombre_Empresa_Sistema_SGC) Cargar_Datos (Entidades_SGC) Cargar_Datos (Atributos_SGC) Si (Opción = Modificar) Entonces Leer (Nombre_Atributo_SGC) Actualizar_Atributo (Id_Entidad_SGC, 131

144 Nombre_Entidad_SGC, Id_Atributo_SGC, Nombre_Atributo_SGC, Nombre_Empresa_Sistema_SGC) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Atributo (Id_Atributo_SGC) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Atributo_SGC) Insertar_ Atributo (Id_Entidad_SGC, Nombre_Entidad_SGC, Nombre_Atributo_SGC, Nombre_Empresa_Sistema_SGC) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE CASOS (PFC_PRO_05) Cargar_Datos (Nombre_Empresa_Sistema_SGC) Cargar_Datos (Entidades_DS) Cargar_Datos (Atributos_DS) Cargar_Datos (Entidades_SGC) Cargar_Datos (Atributos_SGC) Cargar_Datos (Casos) Si (Opción = Dar de Baja) Entonces 132

145 Borrar_Caso (Id_Caso) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Caso) Insertar_ Caso (Id_Entidad_DS, Id_Entidad_SGC, Id_Atributo_DS, Id_Atributo_SGC) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE JOBS (PFC_PRO_06) Cargar_Datos (Usuarios) Cargar_Datos (Jobs) Si (Opción = Modificar) Entonces Leer (Nombre_Job) Leer (Descripción_Job) Actualizar_Job (Id_Job, Nombre_Job, Descripción_Job, Usuario) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Job (Id_Job) Fin Si Si (Opción = Dar de Alta) Entonces 133

146 Leer (Nombre_Job) Leer (Descripción_Job) Insertar_Job (Nombre_Job, Descripción_Job, Usuario) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE TAREAS (PFC_PRO_07) Cargar_Datos (Jobs) Cargar_Datos (Tipos_de_Tareas) Cargar_Datos (Frecuencias) Cargar_Datos (Entidades) Cargar_Datos (Tareas) Si (Opción = Dar de Baja) Entonces Borrar_Tarea (Id_Tarea) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Tarea) Insertar_ Tarea (Id_Job, Nombre_Tarea, Id_Tipo_Tarea, Id_Frecuencia, Id_Entidad) Fin Si 134

147 PSEUDOCÓDIGO PROCESO GESTIÓN DE FRECUENCIAS (PFC_PRO_08) Cargar_Datos (Frecuencias) Si (Opción = Modificar) Entonces Leer (Nombre_Frecuencia) Leer (Descripción_Frecuencia) Actualizar_Frecuencia (Id_Frecuencia, Nombre_Frecuencia, Descripción_Frecuencia) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Frecuencia (Id_Frecuencia) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Frecuencia) Leer (Descripción_Frecuencia) Insertar_Frecuencia (Nombre_Frecuencia, Descripción_Frecuencia) Fin Si 135

148 PSEUDOCÓDIGO PROCESO GESTIÓN DE TIPOS DE TAREAS (PFC_PRO_09) Cargar_Datos (Tipos_de_Tareas) Si (Opción = Modificar) Entonces Leer (Nombre_Tipo_de_Tarea) Leer (Descripción_Tipo_Tarea) Actualizar_Tipo_de_Tarea (Id_Tipo_de_Tarea, Nombre_Tipo_de_Tarea, Descripción_Tipo_de_Tarea) Fin Si Si (Opción = Dar de Baja) Entonces Borrar_Tipo_de_Tarea (Id_Tipo_de_Tarea) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Tipo_de_Tarea) Leer (Descripción_Tipo_de_Tarea) Insertar_Tipo_de_Tarea (Nombre_Tipo_de_Tarea, Fin Si Descripción_Tipo_de_Tarea) 136

149 PSEUDOCÓDIGO PROCESO GESTIÓN DE EMPRESAS - SISTEMAS (PFC_PRO_10) Cargar_Datos (Empresas_Sistemas) Si (Opción = Dar de Baja) Entonces Borrar_Empresa_Sistema (Id_Empresa_Sistema) Fin Si Si (Opción = Dar de Alta) Entonces Leer (Nombre_Empresa_Sistema) Leer (Descripción_Empresa_Sistema) Insertar_Tipo_de_Tarea (Nombre_Empresa_Sistema, Descripción_Empresa_Sistema) Fin Si PSEUDOCÓDIGO PROCESO GESTIÓN DE USUARIOS (PFC_PRO_11) Cargar_Datos (Empresas_Sistemas) Cargar_Datos (Usuarios) Si (Opción = Dar de Baja) Entonces Borrar_Usuario(Id_Usuario) Fin Si Si (Opción = Dar de Alta) Entonces 137

150 Leer (Nombre_Usuario) Leer (Contraseña) Insertar_Usuario (Nombre_Usuario, Contraseña) Fin Si 6.3. MODELO FÍSICO DE LA BASE DE DATOS El modelo físico de datos representa la organización física de los datos en: Bases de datos y archivos integrados por registros que se almacenan juntos físicamente. Agrupación de registros en áreas de almacenamiento físico (áreas, table spaces, etc.), donde residirán físicamente los datos. Forma en que físicamente se almacenan las interrelaciones entre registros (índices, apuntadores, claves extranjeras, claves secundarias, etc.). A continuación se muestra una captura del modelo físico de nuestro sistema, realizado con MS Access 2003, herramienta en la que se ha construido toda la base de datos: 138

151

152 7. Programación

153 7. PROGRAMACIÓN 7.1. INTRODUCCIÓN En esta fase del proyecto se va a proceder a la construcción del sistema según los criterios establecidos dando como resultado un conjunto de programas que puedan ser ejecutados de forma correcta y cumpliendo con los diseños de funcionalidad establecidos en puntos anteriores. Para ello, se va a seguir una rutina de pasos a seguir en la elaboración de cada unidad por separado, analizando 3 puntos clave: Entradas: todos los datos de ingreso en la aplicación. Procesos: son los diferentes procedimientos en los cuales se usarán los datos proporcionados por el usuario. Salidas: resultado de estos procesos. Una buena definición del problema, junto con una descripción detallada de las especificaciones de entrada y salida, son los requisitos más importantes para llegar a una solución eficaz. Una vez se hayan desarrollado todas las unidades del programa, se procederá a la elaboración del manual de usuario y de implantación asociados que expliquen detalladamente todas las especificaciones descritas en este mismo apartado. 141

154 7.2. DISEÑO DEL INTERFAZ DE USUARIO A continuación se van a especificar los criterios empleados para la elaboración del diseño de la Interfaz del sistema. Para ello se adjuntan varias capturas que contienen imágenes de los componentes seleccionados para la resolución del problema de cada unidad del programa (descrito en el apartado anterior). Los componentes corresponden a elementos de diseño de la aplicación NetBeans IDE CRITERIOS El objetivo es construir una aplicación sencilla, lo más intuitiva posible que facilite su explotación por parte del usuario. Para ello se ha optado por utilizar el sistema de formularios proporcionado por la herramienta NetBeans IDE 6.5. Estos formularios permiten la inserción de paneles en los cuales se pueden agregar de forma intuitiva los componentes que se requieran así como la navegación entre estos diferentes paneles. El diseño incluye, de igual manera, el propio diseño de ventanas emergentes las cuales pueden tener distintas funcionalidades: Aviso de un error. 142

155 Aviso de carácter informativo. Ingresado de datos Aceptación o cancelación de una operación (validación). NetBeans ofrece una serie de componentes aptos para ser ubicados dentro de los formularios. Estos componentes se van a utilizar para la gestión de información de entrada y salida, por lo que se considera de alta importancia una buena selección de los mismos. A continuación se muestra un listado de los componentes ofrecidos para el manejo de esta información: CheckBox/RadioButton: permite al usuario la selección de una opción añadida. Su estado puede ser seleccionado o no seleccionado. ComboBox: permite al usuario la selección entre un conjunto de opciones. Estas opciones habrán sido previamente cargadas desde la base de datos. TextBox: permite tanto el ingreso de datos como el mostrado de éstos. Para mayor información se suele acompañar de un Label en el que se describe su título así como de un Tooltip con información adicional sobre el dato. 143

156 TextArea: permite al usuario la introducción de una cantidad numerosa de caracteres (para descripciones, por ejemplo). Se suele acompañar de una barra de Scroll vertical y así como de una horizontal para facilitar su visionado. Table: permite al usuario la introducción y visualización ordenada de una alta cantidad de datos en un mismo elemento. Se puede acompañar de igual manera de una barra de Scroll vertical y horizontal para facilitar su visionado. Button: permite al usuario provocar el comienzo de una acción o proceso, la cual será brevemente descrita mediante un texto contenido en el interior del propio botón así como de un Tooltip si fuera necesario la ampliación de ésta información. Menú: permite al usuario la navegación entre las Diferentes pantallas de la aplicación. 144

157 DISEÑO DE FORMULARIOS En este apartado se va a proceder a detallar, ayudándonos de imágenes realizadas con NetBeans, cómo será la disposición de los distintos componentes en el tipo de formulario final que se va a diseñar para la aplicación. Diseño del Formulario Principal de la aplicación Área de Menú Área de Pantallas 145

158 Diseño del Formulario tipo de Gestión de datos ComboBox Botones Áreas de Datos 146

159 Diseño del Formulario tipo de salida de datos con componente Table Tabla de salida de datos MANUAL DE USUARIO Se adjunta como Anexo A. 147

160 8. Pruebas 148

161 8. PRUEBAS 8.1. INTRODUCCIÓN Una vez terminada la fase de programación, se va a proceder a realizar un conjunto de pruebas que van a conseguir la integración total del sistema, así como asegurar los niveles prefijados inicialmente de calidad y fiabilidad. Una vez realizadas todas las pruebas, si los resultados son satisfactorios, se procederá a la implantación del sistema en su entorno de trabajo final. Si, por el contrario, los resultados no son aceptables, se procederá a la resolución de los problemas que han causado la no aceptabilidad realizando para ello una documentación completa de éste proceso; para ello, se describirá cada uno de los problemas, sus causas y las medidas tomadas para su resolución. Una vez que se hayan subsanado todos los problemas, se repetirá la etapa de pruebas desde el principio. Las pruebas que serán llevadas a cabo son las siguientes: Pruebas unitarias. Pruebas funcionales. Pruebas de seguridad. Pruebas de explotabilidad. Pruebas de aceptación del usuario. Pruebas de regresión. 149

162 8.2. PRUEBAS UNITARIAS Consiste en la comprobación del funcionamiento de todo el sistema según las especificaciones iniciales. Para ello, las pruebas se realizarán de forma unitaria, comprobando el funcionamiento correcto de cada unidad de la aplicación. Ésta fase se incluye dentro de la fase de programación PRUEBAS FUNCIONALES Consiste en comprobar que se cumplen todas las funciones de la aplicación tal y como se habían prefijado en las etapas de análisis de requisitos y diseño físico de procesos. Algunas de estas funciones se resumen a continuación: Acceso óptimo a la base de datos. Coherencia de los datos de la base de datos. Ubicación correcta de los datos en el Interfaz de la aplicación. Contenido correcto de los datos en cada ubicación. Correcto funcionamiento de los filtros de datos. Correcto funcionamiento de los ficheros de salida de datos. Contenido correcto de los ficheros de salida. Correcto funcionamiento de la gestión de datos desde la Interfaz contra la base de datos. 150

163 8.4. PRUEBAS DE SEGURIDAD Consiste en la comprobación del cumplimiento de los mecanismos de seguridad del sistema en cuanto a accesibilidad del sistema (gestión de contraseñas así como vulnerabilidad del sistema de encriptado) y el acceso a datos según el perfil del usuario que accede a la aplicación PRUEBAS DE ACEPTACIÓN DEL USUARIO El objetivo de estas pruebas es la aceptación del sistema por parte de los usuarios finales de la aplicación; en nuestro caso, ésta labor será llevada a cabo por el administrador de la herramienta, perteneciente a nuestra propia empresa, así como por parte de los usuarios que van a interactuar con ella desde nuestras empresas cliente. Se debe verificar la facilidad de uso de la herramienta. La aceptación de todos los intervinientes en ésta prueba supone la aprobación final para la implantación del sistema en el entorno de trabajo real PRUEBAS DE REGRESIÓN Una vez realizadas todas las pruebas anteriores, y justo antes de la fase de implantación, se hará una revisión del sistema para su optimización teniendo en cuenta los resultados obtenidos en éstas. Ésta fase se realizará tantas veces como sea necesario hasta que el sistema cumpla con todos los requisitos establecidos. 151

164 9. Implantación 152

165 9. IMPLANTACIÓN Una vez hayan sido realizadas todas las pruebas dando como resultado la aceptación final del sistema, se va a proceder a la implantación de éste en el entorno real de producción en el que se va a llevar a cabo su explotación. La implantación del sistema supone la preparación de las estaciones de trabajo de los usuarios finales que van a usarla. Para empezar, se deben revisar las características Hardware de los equipos donde se va a instalar el sistema comprobando que cuentan con unos requisitos mínimos necesarios para asegurar su correcto funcionamiento; ésta tarea se realizará para todas nuestras empresas cliente. A continuación, se procederá a instalar en todos los equipos el conjunto de aplicaciones desarrolladas así como el software necesario para posibilitar su correcto acceso y uso. Dado que el sistema da opción a impresión de ficheros, se debe comprobar el correcto funcionamiento de la/s impresora/s en línea realizando las configuraciones necesarias si fuese necesario. Una vez se haya realizado la completa integración del sistema, se procederá a realizar una serie de pruebas que aseguren el correcto funcionamiento del sistema. La aceptación final del usuario significará el final de esta etapa. 153

166 10. Presupuesto 154

167 10. PRESUPUESTO INTRODUCCIÓN En este apartado se va a proceder a realizar una valoración económica de los costes asociados al desarrollo e implantación del presente proyecto. Para ello, se ha decidido dividir la valoración en dos partes: Valoración económica del personal por paquete de trabajo. Costes Hardware y Software DIVISIÓN DE COSTES En este apartado se va a realizar una subdivisión de los costes asociados del proyecto por persona implicada y paquete de trabajo en el que intervenga, así como de los costes Hardware y Software asociados al desarrollo. Para ello recordamos que los intervinientes en el proceso de desarrollo del proyecto se encuentran especificados en el apartado 3.6 (Organización del Proyecto), mientras que la subdivisión en paquetes de trabajo se puede encontrar especificado en el apartado 2.2 (Estructura de Descomposición del Proyecto). Las especificaciones Software y Hardware, se especifican en los apartados 5.2 y 5.3, respectivamente. 155

168 A continuación se muestra el gráfico de valoración económica de personal por paquete de trabajo en el que interviene: La estimación de la duración del proyecto es de 1172 horas, que, teniendo en cuenta las respectivas tarifas del personal que interviene en su desarrollo así como los costes de Software y Hardware asociados, supone un coste total de Euros. 156

169 11. Conclusiones 157

170 11. CONCLUSIONES El desarrollo de un proyecto de esta envergadura, con todo lo que ello conlleva, ha supuesto un verdadero reto personal. Para su realización, no sólo se ha requerido de los conocimientos adquiridos durante toda la carrera, sino que se ha requerido un estudio profundo especializado del sector y de las herramientas que se utilizan actualmente tanto nuestra empresa (DataStream) como en cualquier otra empresa del sector. Por otra parte, también ha servido para poder comprobar personalmente el coste y las dimensiones de la realización de un proyecto real. La ampliación de conocimientos así como la posibilidad de trabajar en una empresa de estas características viendo su funcionamiento desde dentro, ha resultado una experiencia muy enriquecedora y satisfactoria. Como añadido a todo esto, me ha sido posible aprender mucho sobre aplicaciones informáticas usadas actualmente en el sector así como la profundización en aplicaciones de gestión de activos empresariales, en mi caso, DataStream. En conclusión, el éxito del proyecto no solo se debe al desarrollo y funcionamiento satisfactorio de un sistema que permite mejorar un proceso actual de nuestra empresa, con los ahorros de recursos que ello conlleva (tiempo y, por lo tanto, dinero), sino que también se debe a la satisfacción y enriquecimiento personal por haberlo realizado con éxito. 158

171 12. Bibliografía 159

172 12. BIBLIOGRAFÍA La mayoría de las fuentes de información utilizadas para el desarrollo del proyecto están en la Web. A parte, se han utilizado varios manuales especializados en herramientas de gestión de activos y de compras. Todas ellas se listan a continuación: [MAES] Metodología del Análisis Estructurado de Sistemas, Jesús Barranco de Areba, [MDLP] Metodología de la Programación, Eduardo Alcalde, [GPI] Apuntes de la asignatura de Gestión de Proyectos Informáticos, 5º IINF, ICAI. [JAVA] Apuntes de la asignatura de programación en JAVA, 2º IINF, ICAI. [SAP] Apuntes de la asignatura de libre elección SAP/R3, ICAI. [MOA] Manual de Ingeniería del Software, Empresarios Agrupados, [DS] Manual de usuario de la herramienta Datastream 7i, Empresarios Agrupados,

173 Páginas Web: [WIKI] Wikipedia, la enciclopedia libre: [SGA] Sistemas de Gestión de Activos: [SMPC] Sistema de Mantenimiento Preventivo-Correctivo [GCCI] Gestión de Compras, comercio Internacional [SIG] Sistemas Integrados de Gestión [OM] Optimización del Mantenimiento ptimacionintegraldemantenimiento.asp 161

174 [SGC] Generalidades sobre la Gestión de Compras [IEE] Infor EAM España [JAVA2] Programación en JAVA [WDP] Foros de la Web del Programador [FDW[ Foros del Web [FJH] Foros JAVA Hispano 162

175 PARTE II: ANEXOS Anexo A: Manual de Usuario 163

176 MANUAL DE USUARIO 1. Acceso a la aplicación. 2. Menú principal Administrador Gestión de Entidades Entidades DATASTREAM Entidades de SGC Gestión de Atributos Atributos DATASTREAM Atributos de SGC Gestión de Casos Gestión de Jobs Gestión de Tareas Gestión de Frecuencias Gestión de Tipos de Tareas Gestión de Empresas Sistemas Gestión de Usuarios. 3. Menú principal Usuario Visualización de Casos Visualización de Jobs Tareas. 164

177 1. Acceso a la aplicación. El acceso a la aplicación comienza con la presentación de la ventana de bienvenida de la aplicación. Como se puede ver en la imagen, no existe interacción de datos, ya que se trata de una ventana de transición. La pulsación en cualquier parte de la ventana produce la navegación hacia la pantalla de validación de los usuarios. En esta ventana el usuario introduce sus datos de acceso a la aplicación. Se trata, por tanto, de una ventana de entrada de datos. Si los datos del usuario no son correctos, se le informa de esta situación mediante una ventana de diálogo; si, por el contrario, los datos son correctos, se produce la navegación a la pantalla de Menú de Administrador o la pantalla de Menú de Usuario, dependiendo de si se trata de un usuario de tipo administrador o de uno de tipo no administrador, respectivamente. El diseño se muestra a continuación: 165

178 2. Menú Principal Administrador. El usuario de tipo administrador tiene la posibilidad de navegar hacia todas las opciones que ofrece la aplicación tal y como muestra la imagen: 166

179 2.1. Gestión de Entidades Gestión de Entidades de DATASTREAM. Esta pantalla cuenta con varias funciones: dar de alta nuevas entidades, mostrar las entidades existentes, modificarlas y/o darlas de baja. Por tanto, se trata de una pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta una nueva Entidad de DATASTREAM es el nombre de la propia Entidad; no pueden existir dos Entidades con el mismo nombre. El diseño se muestra a continuación: 167

180 Gestión de Entidades de SGC. Esta pantalla cuenta con varias funciones: dado de alta de nuevas entidades, listado de las entidades existentes, modificaciones y/o dado de baja. Por tanto, se trata de una pantalla tanto de entrada como de salida. La diferencia lógica respecto a la pantalla de Gestión del Diccionario de entidades de DS es que en ésta pantalla se ofrece la posibilidad de selección de la empresa sistema en la que se desea realizar la gestión. El nombre de la Entidad debe ser único. El diseño se muestra a continuación: 168

181 2.3. Gestión de Atributos Gestión de Atributos de DATASTREAM. Esta pantalla cuenta con varias funciones: selección de la entidad asociada a los atributos que se desean gestionar, dado de alta de nuevos atributos, listado de los atributos existentes asociados a la entidad, modificaciones y/o dado de baja. Es una pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta un nuevo Atributo de DATASTREAM es el nombre del propio Atributo; no pueden existir dos Atributos con el mismo nombre. El diseño se muestra a continuación: 169

182 Gestión de Atributos de SGC. Esta pantalla cuenta con varias funciones: selección de la entidad asociada a los atributos que se desean gestionar, dado de alta de nuevos atributos, listado de los atributos existentes asociados a la entidad, modificaciones y/o dado de baja. Es una pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta un nuevo Atributo de DATASTREAM es el nombre del propio Atributo; no pueden existir dos Atributos con el mismo nombre. Por último, se ofrece la posibilidad de selección de la empresa sistema en la que se desea realizar la gestión. 170

183 2.4. Gestión de Casos. Esta pantalla cuenta con varias funciones: dado de alta nuevos Casos, dada de baja de estos Casos y listado de las entidades y atributos asociados de nuestra empresa y de las empresas clientes. Es una pantalla tanto de entrada como de salida. El único dato requerido para dar de alta es el nombre del Caso, el cual debe ser único. El diseño se muestra a continuación: 171

184 2.5. Gestión de Jobs. Esta pantalla cuenta con varias funciones: listado de todos los usuarios dados de alta en el sistema, dado de alta de nuevos Jobs (asociadas al usuario seleccionado previamente) y dado de baja de estos Jobs. Es una pantalla tanto de entrada como de salida. Los datos requeridos son el nombre del nuevo Job, el cual debe ser único, y su descripción, la cual es opcional. El diseño se muestra a continuación: 172

185 2.6. Gestión de Tareas Esta pantalla cuenta con varias funciones: listado de todos los Jobs dados de alta en el sistema, dado de alta de nuevas tareas (asociadas al Job seleccionado previamente) y dado de baja de estas tareas. Es una pantalla tanto de entrada como de salida. Los datos requeridos para dar de alta son el nombre de la nueva tarea, el cual debe ser único, el tipo de tarea, la frecuencia y la Entidad a la que va asociada, todos ellos obligatorios. El diseño se muestra a continuación: 173

186 2.7. Gestión de Frecuencias. Esta pantalla cuenta con varias funciones: dado de alta de nuevas Frecuencias, listado de todas las frecuencias dadas de alta previamente en el sistema, modificaciones y/o dado de baja. Es una pantalla tanto de entrada como de salida. Los datos requeridos son el nombre de la nueva frecuencia, el cual debe ser único, y su descripción, la cual es opcional. El diseño se muestra a continuación: 174

187 2.8. Gestión de Tipos de Tareas. Esta pantalla cuenta con varias funciones: dado de alta de nuevos Tipos de tareas, listado de todos los Tipos de tareas dados de alta previamente en el sistema, modificaciones y/o dado de baja. Es una pantalla tanto de entrada como de salida. Los datos requeridos son el nombre del nuevo tipo de tarea, el cual debe ser único, y su descripción, la cual es opcional. El diseño se muestra a continuación: 175

188 2.8. Gestión de Empresas - Sistemas. Esta pantalla cuenta con varias funciones: dado de alta de nuevas empresas con su SGC asociado, listado de todas las empresas y dado de baja. Es una pantalla tanto de entrada como de salida. Los datos requeridos son el nombre de la nueva Empresa - Sistema, el cual debe ser único, y su descripción, la cual es opcional. El diseño se muestra a continuación: 176

189 2.9. Gestión de Usuarios. Esta pantalla cuenta con varias funciones: dado de alta de nuevos usuarios asociados a una empresa - sistema, listado de todas las empresas dadas de alta previamente en el sistema y dado de baja de estos usuarios. Es una pantalla tanto de entrada como de salida. Los datos requeridos son el nombre del nuevo usuario, el cual debe ser único, su contraseña y la empresa a cual queda asociado. Todos ellos son obligatorios. El diseño se muestra a continuación: 177

190 3. Menú principal Usuario. La pantalla Menú Principal Usuario es similar a la pantalla de Administrador, con la diferencia obvia del acceso a las pantallas específicas para los usuarios. Como se observa en la imagen, el usuario es capaz de acceder a todas estas opciones: 178

191 3.1. Visualización de Casos. Esta pantalla pertenece al menú de usuarios y cuenta con varias funciones: listado de todas las entidades asociadas al cliente que ha ingresado en la aplicación, listado en formato de tabla de todos los casos asociadas a la entidad seleccionada, impresión de la tabla de tareas en formato papel y generación de un informe con toda esta información (una guía para estas dos últimas funciones se encuentra descrita en el Anexo B del presente Proyecto). Es una pantalla sólo de salida. El diseño se muestra a continuación: 179

192 3.2. Visualización de Jobs y Tareas. Esta pantalla pertenece al menú de usuarios y cuenta con varias funciones: listado de todos los Jobs asociados al cliente que ha ingresado en la aplicación, listado en formato de tabla de todas las tareas asociadas al Job seleccionado, impresión de la tabla de tareas en formato papel y generación de un informe con toda esta información (una guía para estas dos últimas funciones se encuentra descrita en el Anexo B del presente Proyecto). Es una pantalla sólo de salida. El diseño se muestra a continuación: 180

193 Anexo B: Manual de Impresión y creación de Ficheros 181

194 El presente Anexo pretende ofrecer una guía orientativa para la función de impresión y creado de ficheros que tienen incorporadas las pantallas de visualización de Casos y de visualización de Jobs y Tareas. Para acceder a estas opciones, el usuario debe pulsar el botón de Imprimir lo cual hace saltar el asistente de JAVA para configuración de impresiones, tal y como se puede observar en la siguiente imagen: 182

195 Configuración de Impresiones. Si la opción que desea realizar el usuario es la impresión en formato tabla de los datos, deberá seleccionar una impresora en línea de su red y a continuación realizar una configuración de la impresión tal y como la desee (pestañas Configurar página y Aspecto ). Si el tamaño de hoja de impresión deseado por el usuario es de tamaño A4, se recomienda seleccionar la propiedad Orientación Horizontal para su óptima visión. En el gráfico siguiente se indican estos pasos: 183