UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL INDUSTRIAL

Transcripción

1 UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL INDUSTRIAL DISEÑO E IMPLEMENTACIÓN DE UN SUB-SISTEMA DE GESTIÓN DE INFORMACIÓN PARA EL ÁREA DE OPERACIONES DE LA EMPRESA COPEFRUT S.A., CON EL USO DE HERRAMIENTA BUSINESS INTELLIGENCE MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL INDUSTRIAL PROF. GUÍA: RUTH GARRIDO CARLOS TOLEDO JUAN IGNACIO PINO PIZARRO CURICÓ - CHILE 2008

2 RESUMEN EJECUTIVO Esta memoria se desarrolla en la casa matriz de la empresa Copefrut S.A. ubicada en Curicó, región del Maule. La problemática que se intenta resolver es el manejo de indicadores de gestión para el área de Gerencia de Operaciones a través de una herramienta de negocio inteligente. Los objetivos planteados para resolver la problemática apuntan a realizar un estudio del tipo de información que se maneja y la que se desearía manejar, para determinar los requerimientos actuales de información traducidos en indicadores y crear una aplicación para gestionarlos a través de QlikView. Para resolver la problemática de la empresa se realizaron cuatro grandes actividades como: formalización del problema, diagnóstico de la situación actual, desarrollo del proyecto y diseño e implementación de un prototipo. En la etapa de formalización del problema, se da a conocer el tipo de problemática a abordar y se plantean los objetivos del proyecto. La etapa de diagnóstico de la situación actual permite identificar los procesos que van a ser apoyados con información y además visualiza con qué se cuenta para desarrollar la memoria. En la etapa de desarrollo del proyecto se emplea la ingeniería de requerimientos como base para la obtención de los indicadores de gestión, su especificación y validación. Por último, en etapa de diseño e implementación se crea un prototipo para el software de negocio inteligente QlikView. Éste permite concretar el trabajo realizado satisfaciendo los requerimientos globales de información para el área de operaciones. Como resultado de la memoria, se cumplen los objetivos planteados inicialmente, los cuáles fueron suficientes para la obtención de resultados tangibles y una solución concreta a la empresa. La solución consta de los requerimientos de información para el informe operacional validado y la implementación de un prototipo, que reúne los requerimientos de información necesarios para los solicitantes y es eficaz para captar en gran medida la realidad de los procesos apoyados.

3 ÍNDICE CAPÍTULO 1: DEFINICIÓN Y FORMALIZACIÓN DEL PROBLEMA A ESTUDIAR LUGAR DE APLICACIÓN LA PROBLEMÁTICA DE LA EMPRESA ÁREA DE INVESTIGACIÓN Y ESTUDIO OTROS INTERESADOS OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS RESULTADOS TANGIBLES ESPERADOS...15 CAPÍTULO 2: MARCO TEÓRICO RELEVANTE INGENIERÍA DE REQUERIMIENTOS Clasificación de requerimientos en funcionales y no funcionales Requerimientos de usuario Requerimientos del sistema Determinación de requerimientos Requerimientos Básicos Especificación de la interfaz Documento de requerimientos del software PROCESOS DE LA INGENIERÍA DE REQUERIMIENTOS Estudios de viabilidad Obtención y análisis de requerimientos Validación de requerimientos Gestión de requerimientos...30 CAPÍTULO 3: DIAGNÓSTICO SITUACIÓN ACTUAL DESCRIPCIÓN DE LOS PROCESOS Y LOGÍSTICA DE LA EMPRESA Proceso de recepción de fruta Proceso de ducha bins Proceso de control de calidad Proceso de fruta embalada Proceso de control SAG Proceso de coordinación y despacho de fruta ANÁLISIS DE FLUJOS Y GESTIÓN DE LA INFORMACIÓN ACTUAL Proceso de recepción de fruta Proceso de fruta embalada Proceso de coordinación y despacho de fruta ESTUDIO SISTEMAS DE INFORMACIÓN CORPORATIVOS (ERP QLIKVIEW) ERP PRAGMATIC XXI Herramienta de negocio inteligente QlikView (GDSIS)... 56

4 CAPÍTULO 4: DEFINICIÓN DE REQUERIMIENTOS APLICACIÓN DE LA METODOLOGÍA DE INGENIERÍA DE REQUERIMIENTOS Estudio de viabilidad Obtención y análisis de requerimientos Especificación de requerimientos Validación de requerimientos...84 CAPÍTULO 5: DISEÑO E IMPLEMENTACIÓN CREACIÓN DEL MODELO DE DATOS Tabla Cartola Movimiento Fruta Tabla Antecedentes De Turno Tabla Trabajadores Y Horas Extras Tabla Exportación Tabla Costos Variables Tabla Costos Fijos Tabla Ingresos Tabla Reembalaje Tabla Transporte DISEÑO DE INFORME OPERACIONAL CREACIÓN DE PROTOTIPO PARA APLICACIÓN EN QLIKVIEW Conexión a través de bases de datos relacionales del ERP Conexión a través de ficheros planos Especificaciones del módulo QlikView para requerimientos Ejemplos gráficos de la aplicación CAPÍTULO 6: CONCLUSIONES ANEXOS ANEXO 1: FORMATO DE DOCUMENTO DE REQUERIMIENTOS, ESTÁNDAR IEEE ANEXO 2: MÓDULOS ACTUALES DE ERP PRAGMATIC ANEXO 3: CLASIFICACIÓN INICIAL DE REQUERIMIENTOS ANEXO 4: FORMATO INFORME OPERACIONAL ANEXO 5: GLOSARIO DE PALABRAS REFERENCIAS BIBLIOGRÁFICAS...158

5 ÍNDICE DE FIGURAS FIGURA N 1: Estructura Organizacional Copefrut S.A FIGURA Nº2: Evolución de los requerimientos...31 FIGURA Nº3: Gestión de cambios en los requerimientos FIGURA N 4: Diagrama de Flujo de Proceso...36 FIGURA N 5: Diagrama de Flujo de datos en el proceso FIGURA N 6: Esquema de Módulos Implementados de ERP...50 FIGURA N 7: Estructura básica de soluciones QlikView FIGURA N 8: Modelo de relación de entidades para el manejo de información FIGURA N 9: Esquema de Flujo de comunicación de la información FIGURA N 10: Script de lectura, carga y recarga de bases de datos FIGURA N 11: Pantalla de entrada prototipo indicadores de gestión de plantas FIGURA N 12: Hoja de Movimiento de Fruta, producción por planta FIGURA N 13: Hoja de Movimiento de Fruta, producción por especie FIGURA N 14: Hoja de Embalajes, embalajes por planta FIGURA N 15: Hoja de Embalajes, cajas embaladas por especie-planta FIGURA N 16: Hoja de Exportación, cajas estándar exportadas...1 FIGURA N 17: Hoja de Exportación, cajas estándar exportadas por especie... 1 FIGURA N 18: Hoja de Personal, número de trabajadores planta y temporada FIGURA N 19: Hoja de Personal, número de horas extras personas planta y temporada 107 FIGURA N 20: Hoja de Rendimiento, horas de detención de línea FIGURA N 21: Hoja de Rendimiento, porcentaje tiempo efectivo utilización de línea..108 FIGURA N 22: Hoja de Productividad, costos variables unitario por planta FIGURA N 23: Hoja de Productividad, costos variables unitario por especie-planta FIGURA N 24: Hoja de Presupuesto, costos variables directos-indirectos FIGURA N 25: Hoja de Presupuesto, costos totales FIGURA N 26: Hoja de Transporte, costos de tonelada transportada por especie FIGURA N 27: Hoja de Transporte, costos por tonelada transportada por transporte FIGURA N 28: Hoja de Informe Operacional, tablas directas parte del informe...112

6 ÍNDICE DE TABLAS TABLA N 1: Ejemplo de tablas de presentación para un requerimiento TABLA N 2: Formato de especificación de requerimientos TABLA N 3: Especificaciones kilogramos ingresados por planta y especie TABLA Nº4: Especificaciones kilogramos procesados por planta y especie TABLA Nº5: Especificaciones porcentaje embalado por planta y especie TABLA N 6: Especificaciones número personas de planta TABLA N 7: Especificaciones número personas de temporada...71 TABLA N 8: Especificaciones número personas totales TABLA N 9: Especificaciones número personas packing por turno...72 TABLA N 10: Especificaciones número horas extras personas planta y temporada...72 TABLA N 11: Especificaciones número cajas estándar producidas por especie TABLA N 12: Especificaciones número pallets y cajas despachados por especie...73 TABLA N 13: Especificaciones número cajas reembaladas por especie TABLA N 14: Especificaciones bins/cajas vaciados por hora...74 TABLA N 15: Especificaciones bins/cajas vaciados por hora por persona TABLA N 16: Especificaciones kilogramos procesados por persona TABLA N 17: Especificaciones horas de detención por línea y por planta TABLA N 18: Especificaciones porcentaje de tiempo efectivo de utilización de línea...76 TABLA N 19: Especificaciones porcentaje utilización de frío...76 TABLA N 20: Especificaciones costos variables unitarios por especie - Proceso TABLA N 21: Especificaciones costos variables unitarios por especie - Frío TABLA N 22: Especificaciones costos fijos, variables y totales unitarios por planta...78 TABLA N 23: Especificaciones costos por reembalajes TABLA N 24: Especificaciones costos variables directos por especie TABLA N 25: Especificaciones costos variables indirectos por planta TABLA N 26: Especificaciones costos variables totales TABLA N 27: Especificaciones costos fijos totales TABLA N 28: Especificaciones depreciación plantas TABLA N 29: Especificaciones ingresos frío, proceso y servicios...81

7 TABLA N 30: Especificaciones estado de resultado por planta...81 TABLA N 31: Especificaciones costos por tonelada transportada por especie TABLA N 32: Especificaciones costo de transporte por tonelada y tipo de transporte...82 TABLA N 33: Especificaciones número de viajes por ruta y tipo de transporte... 83

8 Capítulo 1: Definición y Formalización del Problema a Estudiar CAPÍTULO 1: DEFINICIÓN Y FORMALIZACIÓN DEL PROBLEMA A ESTUDIAR Este capítulo tiene como objetivo visualizar y formalizar la problemática que va a ser estudiada en la empresa exportadora Copefrut S.A., así como dar los primeros pasos en la búsqueda de herramientas para abordar los problemas detectados. Se comienza con el lugar de aplicación para posicionar dónde se estudiará la problemática de la empresa y el campo de estudio en que se enmarcará. Se plantean el objetivo general, como propósito de esta memoria, y los objetivos específicos, como tareas a realizar para conseguir el objetivo general, además se trazan los resultados tangibles finales como fruto de esta memoria. Juan Ignacio Pino Pizarro Página 8

9 Capítulo 1: Definición y Formalización del Problema a Estudiar Introducción La memoria se centra en un tema actualmente crítico para cualquier empresa exportadora en crecimiento y es el de contar con información relevante del negocio cuando ésta sea requerida. Contar con un adecuado acceso a la información y que ésta represente fehacientemente la realidad es esencial para que una institución pueda desempeñarse de manera eficiente y efectiva. Mientras mejor sea su información, ésta podrá administrar mejor sus recursos. En un ambiente competitivo, la institución con mejor información tendrá una ventaja comparativa. La experiencia que resulte de la aplicación práctica de esta memoria, que involucra la disposición de información oportuna y relevante, revelará en el tiempo aquellas ineficiencias que se van produciendo en ciertas unidades del proceso productivo. Las decisiones deberán basarse en un estudio sistemático sobre las necesidades de información de las personas involucradas con la institución, desde los directores hasta los clientes. En un sistema de información de nivel gerencial, el instrumento que todos los funcionarios ven y utilizan son los reportes, sin embargo, los reportes inadecuados son una deficiencia significativa en los sistemas de información. Éstos son fundamentales para distribuir información y permiten que los usuarios de esta información lleven a cabo su trabajo correctamente y tomen las decisiones apropiadas, por lo tanto, reportes inadecuados son una deficiencia significativa en los sistemas de información. Juan Ignacio Pino Pizarro Página 9

10 Capítulo 1: Definición y Formalización del Problema a Estudiar 1.1 Lugar de aplicación La empresa Copefrut S.A. tiene sus inicios en el año 1955 como una cooperativa agrícola y frutícola en la cuidad de Curicó, se dedica a la producción y exportación de fruta fresca y jugos concentrados. Su Casa Matriz se encuentra en la Ciudad de Curicó, y cuenta con Plantas de Proceso en las Ciudades de Buin (CENBUIN), Teno (CENKIWI), Curicó (CENFRUT) y Linares (CENLINARES). CENBUIN, se ubica en la Región Metropolitana. En esta planta se procesa aprox. el 12% de la producción anual de fruta fresca, mayoritariamente carozos (ciruelas, duraznos, damascos, nectarines) y cerezas. CENKIWI, se ubica en Longitudinal Sur Km En esta planta se procesa aprox. el 21% de la producción anual de fruta fresca: kiwis, carozos, berries, cerezas y hortalizas congeladas. Cuenta con instalaciones únicas en su género que se diseñaron especialmente para el procesamiento de kiwis. CENFRUT, se ubica en Longitudinal Sur Km En esta planta se procesa aprox. el 46% de la producción anual de fruta fresca: manzanas, peras, peras asiáticas y cerezas. Además se agrega ahí un industrializado proceso de jugos concentrados de manzanas y peras. CENLINARES, se ubica en Longitudinal Sur Km En esta planta se procesa aprox. el 21% de la producción anual de fruta fresca: manzanas, peras, uvas de mesa y cerezas. Sus instalaciones administrativas y comerciales están concentradas en Curicó, Planta Cenfrut, ubicada en Longitudinal Sur Km. 186 y es donde obtendrá la información relevante y se dispondrá de las instalaciones requeridas. Juan Ignacio Pino Pizarro Página 10

11 Capítulo 1: Definición y Formalización del Problema a Estudiar La producción de cajas de fruta fresca exportadas por Copefrut S.A. en la temporada asciende a 8,2 millones, un alza de 8,9% respecto de la temporada pasada ( ). Los principales mercados son Europa (44%), Norte América (19%), América Latina (16%), Lejano Oriente (16%) y Medio Oriente (5%). Las especies mas exportadas son: Manzanas Rojas (39%), Kiwis (21%), Ciruelas (14%), Manzanas Verdes (8%) y Cerezas (7%). La estructura organizacional en cada una de sus plantas, dependientes directamente de la Gerencia de Operaciones, tiene una tendencia hacia la horizontalidad, por lo que cada planta no tiene más a allá de 3 niveles de mando para los trabajadores de planta. Esto permite la toma de decisiones descentralizadas y con un tiempo de respuesta inmediato, pero también genera descoordinaciones entre departamentos puesto que no poseen toda la información respecto a las acciones de los otros departamentos Figura N 1: Estructura Organizacional Copefrut S.A. Juan Ignacio Pino Pizarro Página 11

12 Capítulo 1: Definición y Formalización del Problema a Estudiar 1.2 La problemática de la empresa La empresa no cuenta con un sistema de manejo de información que permita contar con indicadores de gestión, datos elaborados y medios gráficos en tiempo real y al alcance de los responsables de la toma de decisiones, que para esta memoria son los ejecutivos y supervisores del área de Gerencia de Operaciones de Copefrut S.A. En la actualidad, la empresa cuenta con una herramienta ERP 1 provista de módulos desarrollados para la gestión de información de sus procesos productivos. Sin embargo, ha determinado que esto es insuficiente y que se requiere la utilización de un sistema especializado de generación de informes que permita obtenerlos en tiempos más convenientes según las necesidades reales de los usuarios. Además, se desea que estos informes posean un mayor nivel de profundidad y que sean adaptables a los requerimientos particulares de cada planta. Para esto se ha adquirido recientemente una herramienta de negocio inteligente, QlikView 2, la cual es compatible con el ERP y puede servir de interfaz, permitiendo el análisis de los datos tomados desde el ERP corporativo. Los principales problemas presentados hoy en día con el sistema actual tienen relación con la generación de informes al final de temporada lo que no permite anticipar fallas en los sistemas productivos e impide implementar acciones correctivas, además estos informes, que son realizados en cada planta, presentan información generalizada y no hay un criterio común de requerimiento de información, por lo que se dificulta una visualización acabada del rendimiento de cada planta. Actualmente el ERP ofrece trabajar en base a informes básicos, pero estas funcionalidades no son suficientes para realizar un análisis de negocio con los parámetros específicos de cada usuario, ya sea por las limitaciones de personalización de indicadores e informes, sea por la imposibilidad de integrar datos de otros sistemas o como de una simple hoja de cálculo. El resultado suele ser que los usuarios 1 ERP (Enterprise Resourse Planning) o Planificación de los Recursos Empresariales es una solución comercial de software empaquetado compuesto de varios módulos configurables que integran en un solo sistema las actividades empresariales nucleares (finanzas, recursos humanos, manufactura, cadena del abastecimiento, gestión de clientes, ventas, entre otros). 2 QlikView es software de business intelligence que permite a los desarrolladores construir e implementar aplicaciones analíticas muy funcionales y de gran alcance. Las aplicaciones de QlikView proporcionan a los diferentes tipos de usuarios finales el análisis interactivo de la información crítica de negocio de una manera sumamente intuitiva, productiva y creativa. Juan Ignacio Pino Pizarro Página 12

13 Capítulo 1: Definición y Formalización del Problema a Estudiar elaboran sus informes manualmente, lo cual además de consumir tiempo innecesario, da lugar a errores e incoherencias en la información. Un sistema de Business Intelligence facilita esta tarea y permite disponer de la información de forma instantánea. Las aplicaciones de Business Intelligence son herramientas de soporte de decisiones que permiten, en tiempo real, acceso interactivo, análisis y manipulación de información crítica para la empresa. Estas aplicaciones proporcionan a los usuarios un mayor entendimiento que les permite identificar las oportunidades y los problemas de los negocios. Los usuarios son capaces de acceder y manejar una gran cantidad de información, analizar sus relaciones y entender las tendencias que últimamente están apoyando las decisiones de los negocios. El manejo de esta herramienta será, en términos prácticos, el punto más importante para la creación de los informes operacionales. 1.3 Área de investigación y estudio Las principales áreas de estudios para la realización esta memoria son: Gestión de Operaciones Gestión de Procesos y Personas Sistemas de Información Manejo de base de datos Diseño e interfaz de sistemas de información Ingeniería de Software Ingeniería de requerimientos Juan Ignacio Pino Pizarro Página 13

14 Capítulo 1: Definición y Formalización del Problema a Estudiar 1.4 Otros interesados No existen directamente otros interesados, pero existen potenciales interesados que son las empresas relacionadas, las cuales han adquirido gran parte de las mejoras incorporadas por la empresa. 1.5 Objetivo General Diseñar e implementar un sub-sistema de gestión de información para el área de operaciones de la empresa Copefrut S.A., con la utilización de herramienta business intelligence para la creación de informes de gestión que cumplan con los requerimientos de información y frontera de tiempo para el nivel Gerencial en la organización. 1.6 Objetivos Específicos Estudiar, conocer y analizar los procesos de las áreas de producción y logística de la empresa en busca de establecer un marco de referencia de aplicación del proyecto. Análisis de los flujos y gestión de la información actual para caracterizar los procesos de información. Manejar la metodología de funcionamiento e integración del sistema ERP corporativo y la herramienta de Business Intelligence para aprovechar la mayor parte de sus potencialidades. Determinar los requerimientos actuales para el sistema de gestión y realizar un levantamiento de requerimientos. Determinar la brecha de información entre los flujos actuales y los requerimientos para proponer recomendaciones de ajuste. Seleccionar y formular indicadores que permitan la toma de decisiones en los distintos niveles jerárquicos de la organización. Realizar un diseño acorde a los requerimientos de los usuarios del sistema y un plan de implementación para la conformación de informes para una frontera de tiempo determinada. Juan Ignacio Pino Pizarro Página 14

15 Capítulo 1: Definición y Formalización del Problema a Estudiar 1.7 Resultados Tangibles Esperados Identificación de la brecha de información elaborada entre lo que maneja actualmente la empresa y los requerimientos. Indicadores de gestión validados de acuerdo a los requerimientos de información de los distintos niveles. Implementación de un prototipo para el sistema de informes operacionales validado por la empresa. Juan Ignacio Pino Pizarro Página 15

16 Capítulo 2: Marco teórico relevante CAPÍTULO 2: MARCO TEÓRICO RELEVANTE En este capítulo se presentan las bases teóricas que permiten abordar un problema complejo adoptando una metodología de avance para encontrar una solución práctica a la problemática planteada. En esta memoria se desarrollará, como vía de solución, una metodología de ingeniería de requerimientos que tiene como finalidad la generación de especificaciones apropiadas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento de sistemas, y de esta manera se pretende minimizar los problemas relacionados al desarrollo o adecuación de sistemas en una organización. La ingeniería de requerimientos trata de establecer lo que el sistema debe hacer, sus propiedades emergentes deseadas y esenciales, y las restricciones en el funcionamiento del sistema y los procesos de desarrollo del software. Por lo tanto puede considerarse el proceso de ingeniería de requerimientos como el proceso de comunicación entre los clientes, usuarios del software y los desarrolladores del mismo. Los requerimientos del sistema están influenciados por las preferencias, aversiones y prejuicios de los usuarios y por cuestiones políticas y organizacionales. Juan Ignacio Pino Pizarro Página 16

17 Capítulo 2: Marco teórico relevante La determinación de requerimientos es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras. Un requerimiento es una característica que debe incluirse en un nuevo sistema. Pude ser una determinada forma para capturar o procesar datos, producir información, controlar una actividad en la empresa o brindar soporte a la gerencia. Es así como la determinación de requerimientos vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él. Ciertos tipos de requerimientos son tan fundamentales que son comunes en casi todas las situaciones. Dar respuestas a un grupo específico de preguntas será de gran ayuda para comprender los requerimientos básicos. También existen otra clase de requerimientos que dependen de si el sistema está orientado hacia transacciones, toma de decisiones o se extiende por varios departamentos. Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Para dos niveles bien definidos se distinguen, los requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y los requerimientos del sistema para designar una descripción detallada de lo que éstos deben hacer. Es necesario redactar los requerimientos en diversos niveles de detalle debido a que diferentes tipos de lectores los utilizan de distinta manera. Es por esto que necesitan saber con más precisión lo que el sistema será capaz de realizar ya que están interesados en cómo éste apoyará a los procesos de negocios, o están implicados en la implementación del sistema. Juan Ignacio Pino Pizarro Página 17

18 Capítulo 2: Marco teórico relevante 2.1 Ingeniería de Requerimientos Clasificación de requerimientos en funcionales y no funcionales Los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio. a) Funcionales: declaraciones de los servicios que debe proporcionar el sistema, cómo se debe comportar ante situaciones (lo que el sistema debe y no debe hacer). Dependen de tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización. Describen con detalle la función del sistema, sus entradas, salidas, excepciones etc. Deben alcanzar completitud (todos los servicios solicitados por el usuario deben estar definidos) y consistencia (los requerimientos no deben tener definiciones contradictorias) b) No funcionales: restricciones de los servicios o funciones ofrecidas por el sistema (restricciones de tiempo, proceso de desarrollo, estándares). Se refiere a las necesidades emergentes de sistema como fiabilidad, tiempo de respuesta y la capacidad de almacenamiento. Definen también las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Pueden especificar el rendimiento del sistema, la protección, la disponibilidad. A menudo son más críticos que los requerimientos funcionales ya que un problema de fiabilidad puede significar que el sistema entero sea inutilizable. Los requerimientos no funcionales son: Requerimientos del producto: especifican el comportamiento del producto (Ej.: requerimientos de rendimiento en la rapidez de ejecución del sistema y cuánta memoria requiere; requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; requerimientos de portabilidad y de usabilidad). Juan Ignacio Pino Pizarro Página 18

19 Capítulo 2: Marco teórico relevante Requerimientos organizacionales: se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador (Ej.: estándares en los procesos que deben utilizarse; requerimientos de implementación como lenguajes de programación y requerimientos de entrega que especifican cuándo se entregará el producto y su documentación). Requerimientos externos: éstos pueden incluir los requerimientos de interoperabilidad que definen cómo el sistema interactúa con sistemas de otras organizaciones; requerimientos legislativos que deben seguirse para asegurar que el sistema funcione dentro de la ley. c) Del Dominio: requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Se derivan del dominio de aplicación del sistema más que de las necesidades específicas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Si estos requerimientos no se satisfacen, puede ser imposible lograr que el sistema funcione de forma satisfactoria Requerimientos de usuario Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento detallado del sistema. Juan Ignacio Pino Pizarro Página 19

20 Capítulo 2: Marco teórico relevante Requerimientos de las transacciones de los usuarios Los sistemas en este nivel, capturan, procesan y almacenan datos por razones específicas. Se realizan preguntas del tipo: Qué es lo que forma parte de la transacción que está siendo procesada? Qué es lo que inicia la transacción? Quién inicia los pedidos? Con qué propósito? Con que frecuencia ocurren los pedidos? Qué volumen está asociado a cada pedido? Qué detalles son necesarios para procesar la transacción? Qué información se genera? Que datos se almacenan? Requerimientos del sistema Son versiones extendidas de los requerimientos del usuario que son utilizados por los ingenieros de software como punto de partida para el diseño del sistema. Agregan detalle y explican cómo el sistema debe proporcionar los requerimientos del usuario. A menudo se utiliza el lenguaje natural para redactar, además de los requerimientos del usuario, las especificaciones de requerimientos del sistema. Sin embargo, debido a que los requerimientos del sistema son más detallados que los requerimientos del usuario, las especificaciones en lenguaje natural pueden ser confusas y difíciles de entender. Para esto se pueden redactar los requerimientos del sistema en notaciones más especializadas como el lenguaje natural estructurado, modelos gráficos de los requerimientos como los casos de uso para las especificaciones matemáticas formales. Especificaciones en lenguaje estructurado Todos los requerimientos se redactan de una forma estándar. Mantiene la expresividad y comprensión del lenguaje natural, pero se impone cierto grado de uniformidad en la especificación. Se puede añadir información adicional como tablas o modelos gráficos para Juan Ignacio Pino Pizarro Página 20

21 Capítulo 2: Marco teórico relevante evitar la ambigüedad del lenguaje natural. Las tablas se pueden utilizar ante situaciones de alternativas posibles y se describen las acciones a tomar para cada una de ellas. Los modelos gráficos son útiles para mostrar como cambia el estado o cuando se necesite describir una secuencia de acciones Determinación de requerimientos Se determinan los requerimientos a través de tres grandes actividades: anticipación, investigación y especificación de requerimientos. Anticipación de requerimientos: el conocimiento y experiencia de los analistas sobre sistemas con características similares al de estudio, les permite anticiparse a ciertos problemas o características para un nuevo sistema. Investigación de requerimientos: los analistas estudian el sistema actual con la utilización de herramientas y habilidades, se documentan las características de los requerimientos y más a delante se realiza el análisis. Especificaciones de requerimientos: los datos obtenidos en la recopilación de hechos se analizan para describir las características del nuevo sistema. Pasa por tres etapas, el análisis de datos basados en hechos reales, la identificación de requerimientos esenciales que deben incluirse en el nuevo sistema y la selección de estrategias para satisfacer los requerimientos Requerimientos Básicos Comprensión del proceso: los analistas realizan preguntas del funcionamiento del proceso, las respuestas proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo. Juan Ignacio Pino Pizarro Página 21

22 Capítulo 2: Marco teórico relevante Identificación de datos empleados e información generada: detectar que datos se utilizan para realizar cada actividad. Frecuencia y volumen del proceso: se debe investigar con cuanta frecuencia se repite una actividad. Se pueden elaborar mas preguntas con relación a la razón y efecto de la frecuencia de las actividades de la empresa. El volumen de artículos manejados puede aumentar el tiempo necesario para completar la actividad. Identificación de controles: un buen control por parte de gerencia o de seguimiento del proceso puede determinar fácilmente si una actividad se ha llevado a cabo en forma adecuada Especificación de la interfaz La gran mayoría de los programas deben interactuar con otros sistemas ya que están implementados e instalados en un entorno. Si el sistema nuevo y los ya existentes deben trabajar juntos, las interfaces de estos últimos deben especificarse de forma precisa. Pueden definirse tres tipos de interfaces: Interfaces de procedimientos: los programas o subsistemas ofrecen servicios a los que se accede invocando a los procedimientos de la interfaz. Se les llama también Programas de aplicaciones o APIs Estructuras de datos: que pasan de un subsistema a otro. Existen modelos gráficos de datos para denotar este tipo de descripciones. Si es necesario, se pueden generar descripciones de programas en Java o C++ de estas descripciones. Representación de datos (como el orden de los bits): establecida para un sistema existente. Estas interfaces son muy comunes en sistemas de tiempo real embebido 3. 3 Un sistema embebido (a veces traducido del inglés como embebido, empotrado o incrustado) es un sistema informático de uso específico construido dentro de un dispositivo mayor. (Fuente: Wikipedia) Juan Ignacio Pino Pizarro Página 22

23 Capítulo 2: Marco teórico relevante Algunos lenguajes de programación como Ada soportan este nivel de especificación. Sin embargo, la mejor forma de describirlos es probablemente utilizando un diagrama de estructura con anotaciones que explique la función de cada uno de los bits Documento de requerimientos del software El documento de requerimiento de software (SRS) es la declaración oficial de qué deben implementar los desarrolladores del Sistema. Debe incluir los requerimientos del usuario y una especificación detallada de los requerimientos del sistema. Éste documento, debido a la gran diversidad de posibles usuarios, debe presentar un equilibrio entre la comunicación de los requerimientos a los clientes, la definición de los requerimientos en detalle para los desarrolladores y probadores, y la inclusión de información sobre la posible evolución del sistema. Varias organizaciones grandes, como el IEEE 4, han definido estándares para los documentos de requerimientos. Este estándar tiene asociado un formato para el documento de requerimientos el cual ha sido incorporado en el ANEXO 1 de este informe. 4 IEEE corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. (Fuente: Wikipedia) Juan Ignacio Pino Pizarro Página 23

24 Capítulo 2: Marco teórico relevante 2.2 Procesos de la ingeniería de requerimientos La meta del proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema. El proceso corresponde a cuatro subprocesos de alto nivel de la ingeniería de requerimientos. Éstos determinan la utilidad del sistema para el negocio (estudio de viabilidad); permiten el descubrimiento de requerimientos (obtención y análisis); la representación de estos requerimientos en formularios estándar (especificación), y la verificación de que los requerimientos realmente definen el sistema que quiere el cliente (validación) Estudios de viabilidad El proceso de ingeniería de requerimiento debe comenzar con un estudio de viabilidad. Los resultados del estudio de viabilidad debe ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema. El punto crítico en esta etapa es determinar si el sistema contribuye a los objetivos del negocio. Si no contribuye entonces no tiene un valor real para el negocio. Comprende la evaluación y recopilación de la información, y la redacción de informes. Para obtenerlos, se puede consultar fuentes de información como los jefes de los departamentos involucrados, expertos en tecnología y los usuarios finales del sistema para responder preguntas como: Cómo se las arreglaría la organización si no implementa este sistema? Cuáles son los problemas con los procesos actuales y cómo ayudaría un sistema nuevo a aliviarlos? Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos del negocio? La información se puede obtener y transferir a otros sistemas de la organización? Requiere el sistema tecnología que no se ha utilizado previamente en la organización? A qué debe ayudar el sistema y qué no necesita ayudar? Juan Ignacio Pino Pizarro Página 24

25 Capítulo 2: Marco teórico relevante Específicamente se analizan tres puntos indispensables: Factibilidad Operacional: Esta factibilidad comprende una determinación de la probabilidad de que el nuevo sistema se utilice como se supone debe ser utilizado. Factibilidad Técnica: Esta factibilidad comprende la evaluación de la disponibilidad y capacidades técnicas de equipos y software. También se considera si el personal cuenta con la calificación técnica para diseñar e implementar el nuevo sistema. Factibilidad Económica: Esta factibilidad comprende la evaluación de costos y beneficios asociados a las alternativas. Una vez que se tiene la información, se redacta un informe de viabilidad. Debería hacerse una recomendación sobre si se debe continuar o no el desarrollo del sistema. También se pueden proponer cambios en el alcance, el presupuesto y la confección de agendas de sistema y sugerir requerimientos adicionales de alto nivel para éste Obtención y análisis de requerimientos En esta actividad los ingenieros de software trabajan con los solicitantes, clientes y usuarios finales del sistema para determinar el dominio de la aplicación, que servicios debe proporcionar el sistema, el rendimiento requerido del sistema y las restricciones de hardware. Las dificultades para obtener información de los solicitantes son: Los solicitantes a menudo no conocen lo que desean obtener del sistema informático excepto en términos muy generales. Los solicitantes expresan los requerimientos con sus propios términos de forma natural y con un conocimiento implícito de su propio trabajo. Juan Ignacio Pino Pizarro Página 25

26 Capítulo 2: Marco teórico relevante Diferentes solicitantes tienen requerimientos distintos, que se pueden expresar de varias formas. Hay que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos. Los factores políticos pueden influir en los requerimientos del sistema. El entorno económico y de negocios en que se lleva a cabo el análisis es dinámico. Inevitablemente, cambia durante el proceso de análisis, por lo tanto la importancia de ciertos requerimientos pueden cambiar. Las actividades del proceso son: Descubrimiento de requerimientos Proceso de recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta información. Las fuentes de información incluyen la documentación, los solicitantes del sistema y la especificación de sistemas similares. También son parte de esta actividad el análisis de puntos de vista, las entrevistas, la evaluación de diferentes escenarios y la etnografía. a) Puntos de vista: Los enfoques orientados a puntos de vista para la ingeniería de requerimientos organizan tanto el proceso de obtención como los requerimientos mismos utilizando puntos de vista. Un punto clave es reconocer varias perspectivas y proporcionar un marco de trabajo para descubrir conflictos. Se puede utilizar como una forma de clasificar los solicitantes y otras fuentes de requerimientos. Existe el punto de vista de los intercambiadores que son los que actúan directamente sobre el sistema, puntos de vista indirectos que son los que no utilizan el sistema pero que influyen en los requerimientos y los puntos de vista del dominio que representan las características y restricciones del dominio que influyen en los requerimientos del sistema. En este proceso se debe identificar: Los proveedores y receptores de los servicios del sistema Los sistemas que deben interactuar directamente con el sistema Juan Ignacio Pino Pizarro Página 26

27 Capítulo 2: Marco teórico relevante Las regulaciones y estándares que se aplican la sistema Las fuentes de los requerimientos no funcionales y de negocio del sistema Los puntos de vista de la ingeniería, personas que desarrollan, administran y mantienen el sistema. Los puntos de vista del marketing, que reflejan las características que esperan los clientes y como el sistema debe reflejar la imagen externa de la organización. Para cualquier sistema no trivial, existe un enorme número de posibles puntos de vista, y es prácticamente imposible obtener requerimientos de todos ellos. Por lo tanto, es importante organizar y estructurar los puntos de vista en una jerarquía. Es probable que los puntos de vista en la misma rama compartan requerimientos comunes. b) Entrevistas: formales e informales, son parte de la mayoría de los procesos de ingeniería. El equipo de ingeniería de requerimientos hace preguntas para iniciar una conversación con los solicitantes sobre el sistema que utilizan y sobre el sistema a desarrollar. Es importante recordar que los entrevistados y los analistas conversan durante la entrevista, es decir no se interroga a los primeros. La entrevistas pueden clasificarse como estructuradas o no estructuradas. Las no estructuradas utilizan un formato pregunta-respuesta y son apropiadas cuando el analista desea adquirir información general acerca de un sistema. Por otro lado las estructuradas utilizan preguntas estándar en un formato de respuesta abierta o cerrada. El primero permite al entrevistado dar respuestas a las preguntas con sus propias palabras; el segundo utiliza un conjunto anticipado de respuestas. c) Escenarios: para las personas es más fácil dar ejemplos de la vida real que descripciones abstractas. Los escenarios pueden ser útiles para agregar detalles a un esbozo de la descripción de requerimientos. Cada escenario abarca una o más posibles interacciones, que comienzan con un esbozo de la interacción y, durante Juan Ignacio Pino Pizarro Página 27

28 Capítulo 2: Marco teórico relevante su obtención, se agregan detalles para crear una descripción completa de ésta. Los escenarios pueden incluir: Una descripción de lo que esperan el sistema y los usuarios cuando el escenario comienza. Descripción del flujo normal de eventos en el escenario Una descripción de lo que puede ir mal y cómo manejarlo. Información de otras actividades que podrían llevarse al mismo tiempo. Una descripción del estado del sistema cuando el escenario termina. d) Casos de uso: un caso de uso identifica el tipo de interacción y los actores involucrados. Los actores en el proceso se representan como figuras delineadas, y cada clase de interacción se representa como una elipse con su nombre. El conjunto de casos de uso representa todas las posibles interacciones a representar en los requerimientos del sistema. Los casos de uso identifican las interacciones particulares con el sistema y pueden ser apoyados por diagramas de secuencia, que muestran a los actores involucrados en la interacción, los objetos con los cuales interactúa y las operaciones asociadas con ese objeto. e) Etnografía: satisfacer los requerimientos sociales y organizacionales es crítico para el éxito del sistema. La etnografía es la técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Observación del trabajo diario y verificación de las tares reales en que los participantes están involucrados. Sirve para descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales en los que la gente está involucrada (disminuir la diferencia de información entre el trabajo supuesto y el real). La etnografía se puede combinar con la construcción de prototipos para requerir una menor cantidad de refinamientos. Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario final, este Juan Ignacio Pino Pizarro Página 28

29 Capítulo 2: Marco teórico relevante enfoque no es apropiado para descubrir requerimientos organizacionales o del dominio. Por lo tanto, debe utilizarse para complementar otros enfoques Validación de requerimientos La validación es la actividad que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. La validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. Durante el proceso de validación de requerimientos se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden: Verificaciones de validez: Los requerimientos deben haber sido solicitados por algún usuario. Verificaciones de consistencia: Los requerimientos no deben contradecirse. No deben haber restricciones o descripciones contradictorias de la misma función de sistema. Verificaciones de completitud: Los requerimientos deben definir todas las funciones y restricciones propuestas por el usuario del sistema. Verificaciones de realismo: Los requerimientos deben verificarse para asegurar que se puedan implementar. Verificabilidad: Los requerimientos siempre deben redactarse de tal forma que son verificables. Esto significa que debe poder escribir un conjunto de pruebas que demuestren que el sistema cumple cada uno de los requerimientos especificados. Juan Ignacio Pino Pizarro Página 29

30 Capítulo 2: Marco teórico relevante Revisiones de requerimientos Una adecuada técnica de validación de requerimientos que puede ser utilizada son las revisiones de requerimientos. Son procesos manuales de verificación del documento de requerimientos en cuanto a anomalías y omisiones. Las revisiones se pueden realizar informalmente, implicando que los desarrolladores deben tratar los requerimientos con la mayor cantidad de solicitantes que puedan. Se pueden realizar revisiones formales, donde el equipo de desarrollo debe conducir al cliente a través de los requerimientos del sistema, explicando las implicaciones de cada requerimiento. El equipo de revisión debe verificar cada requerimiento para la consistencia además de verificar los requerimientos como un todo para la completitud. También se puede comprobar la verificabilidad (puede probarse el requerimiento de modo realista), comprensibilidad (los usuarios finales comprenden el requerimiento), rastreabilidad (está claramente establecido el origen del requerimiento) y adaptabilidad (puede cambiarse el requerimiento sin causar efectos de gran escala sobre los otros requerimientos). La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado Gestión de requerimientos La gestión de requerimientos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Es necesario mantenerla para cada requerimiento particular y las dependencias que se puedan formar entre ellos, de forma que se pueda evaluar el impacto de los cambios en los requerimientos. Es esencial establecer un proceso formal para implementar las propuestas de cambio y vincularlos a los requerimientos del sistema. La actividad de evolución de los requerimientos es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Juan Ignacio Pino Pizarro Página 30

31 Capítulo 2: Marco teórico relevante Los requerimientos cambian por diferentes razones. Las más frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambió el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambió el ambiente de negocios. Porque cambió el mercado en el cual se desenvuelve el negocio. Conforme se va desarrollando la definición de los requerimientos, se va adquiriendo una mayor comprensión de las necesidades del usuario. Esto retroalimenta la información del usuario, quien puede entonces proponer un cambio en los requerimientos como se ve expresado en la figura Nº2. Comprensión inicial del problema Cambio en la comprensión del problema Requerimientos iniciales Requerimientos cambiados Tiempo Figura Nº2: Evolución de los requerimientos Desde una perspectiva evolutiva, los requerimientos se dividen en dos clases: Requerimientos duraderos: requerimientos estables que se derivan de la actividad principal de la organización y que están relacionados directamente con el dominio del sistema. Requerimientos volátiles: cambian durante el proceso de desarrollo del sistema o después de que éste se haya puesto en funcionamiento. Juan Ignacio Pino Pizarro Página 31

32 Capítulo 2: Marco teórico relevante Planificación de la gestión de requerimientos Para cada proyecto, la etapa de planificación establece el nivel de detalle necesario en la gestión de requerimientos. Durante la etapa de gestión de requerimientos, habrá que establecer: La identificación de requerimientos: cada requerimiento se debe identificar de forma única. Un proceso de gestión del cambio: conjunto de actividades que evalúan el impacto y costo de cambio. Políticas de rastreo: definen las relaciones entre los requerimientos, y entre éstos y el diseño del sistema que se debe registrar y la manera que estos registros se deben mantener Ayuda de herramientas CASE 5 : las herramientas que se pueden utilizar van desde sistemas de gestión de requerimientos especializados hasta hojas de cálculo y sistemas sencillos de bases de datos. Cuando se proponen cambios, se debe rastrear el impacto de estos cambios en los otros requerimientos y en el diseño del sistema. El rastreo es una propiedad de la especificación de requerimientos que refleja la facilidad de encontrar requerimientos relacionados. Existen tres tipos de información de rastreo que pueden ser mantenidos: Información de rastreo de la fuente: vincula los requerimientos con los solicitantes de requerimientos y la razón de éstos. Información de rastreo de los requerimientos: vincula los requerimientos dependientes en el documento de requerimientos. Es utilizada para rastrear el impacto de los requerimientos ante un cambio en alguno relacionado. 5 Las Herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas que ayudan en todos los aspectos del ciclo de vida de desarrollo del software, como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras (Fuente: Wikipedia). Juan Ignacio Pino Pizarro Página 32

33 Capítulo 2: Marco teórico relevante Información de rastreo del diseño: vincula los requerimientos a los módulos de diseño en los cuales son implementados. La gestión de requerimientos necesita de herramientas automatizadas de ayuda como las herramientas CASE, las cuales deberán ser elegidas durante el proceso de planificación. Se requerirán para casos como: Almacenar requerimientos: los requerimientos deben mantenerse en un almacén de datos seguro y administrado que sea accesible a todos los que están implicados en el proceso de ingeniería de requerimientos. Gestionar el cambio: se definen tres etapas, el análisis del problema y especificación del cambio, el análisis del problema y cálculo de costes, y la implementación del cambio. Gestionar el rastreo: las herramientas de ayuda para el rastreo permiten que se descubran requerimientos relacionados. Algunas herramientas utilizan técnicas de procesamiento del lenguaje natural para ayudar a descubrir posibles relaciones entre los requerimientos Para sistemas pequeños, el sistema de gestión se realiza a través de procesadores de texto, hojas de cálculo y bases de datos. Gestión del cambio de los requerimientos La gestión del cambio de los requerimientos debe ser aplicada a todos los cambios propuestos en los requerimientos. La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada. Existen tres etapas principales en un proceso de gestión de cambio como se ve en la figura Nº3. Juan Ignacio Pino Pizarro Página 33

34 Capítulo 2: Marco teórico relevante Problema identificado Análisis del problema y especificaciones del cambio Análisis del problema y cálculo de costes Implementación del cambio Requerimientos revisados Figura Nº3: Gestión de cambios en los requerimientos a) Análisis del problema y especificación del cambio: Comienza con la identificación de un problema en los requerimientos o una propuesta de cambio específica. Durante esta etapa el problema se analiza para verificar que sea válido. Los resultados del análisis se envían al solicitante y algunas veces se elabora una propuesta de cambio de requerimiento más específica. b) Análisis del cambio y cálculo de costes: El efecto de un cambio se valora a través de la información de rastreo y el conocimiento general de los requerimientos. El coste de hacer un cambio se valora en términos de modificaciones al documento de requerimientos y, si es apropiado, al diseño e implementación del sistema. c) Implementación del cambio: Se modifica el documento de requerimiento y, si es el caso, el diseño e implementación del sistema. Debe ser organizado el documento de requerimientos de modo que permita hacer cambios en él sin tener que hacer grandes reorganizaciones o redactar gran parte del mismo. Juan Ignacio Pino Pizarro Página 34

35 Capítulo 3: Diagnóstico situación actual CAPÍTULO 3: DIAGNÓSTICO SITUACIÓN ACTUAL En este capítulo se presentan las características más importantes del lugar de estudio las cuales son relevantes para el desarrollo de esta memoria. Los contenidos tratados tienen la finalidad de conocer la base en la cual se inserta del proyecto y las herramientas con que se cuentan para su progreso. En una primera parte se presenta una descripción de los procesos que se llevan a cabo en la empresa Copefrut S.A. para situarse en el concepto del negocio, luego sobre este proceso se revisan los flujos de información que se registran en los distintos puntos del proceso, lo que permite conocer que tipo de información se maneja y donde se origina. Por último se estudia el sistema ERP corporativo que permite el soporte de toda la información relevante para el negocio y es la fuente principal del proyecto. Se presenta también la herramienta de negocio inteligente QlikView para detallar su utilización y funciones desarrolladas. Juan Ignacio Pino Pizarro Página 35

36 Capítulo 3: Diagnóstico situación actual 3.1 Descripción de los procesos y logística de la empresa El conocimiento de los procesos productivos de una empresa permite la interiorización en las actividades que se realizan para la elaboración de productos terminados, además permite la visualización de la magnitud de proyectos a realizar, el nivel de tecnología que cuenta, el grupo humano que hay detrás, en general son puntos importante si lo que se requiere apoyar son los procesos productivos. Para identificar qué procesos se están apoyando y tenga sentido una base informática, se muestran a continuación las principales operaciones que se llevan a cabo en las plantas procesadoras. Recepción Materiales Control de Calidad Bodega Insumos Químicos Ducha Bins Almacenamiento Materiales Bodega de Materiales PROCESO PRODUCTIVO Palletizaje Control de Calidad Tarja Almacenamiento Cámara de Frío Despacho Embarque Pre Frío Inspección SAG (USDA y Origen) Figura N 4: Diagrama de Flujo de Proceso Juan Ignacio Pino Pizarro Página 36

37 Capítulo 3: Diagnóstico situación actual Proceso de recepción de fruta El proceso se inicia con la recepción de fruta en la planta, transportada por camiones particulares, identificando el producto en una guía de despacho donde debe estar el detalle del producto. Este proceso de recepción lo constituyen tres subprocesos según los estados en que puede llegar la fruta a la planta: recepción fruta granel, recepción fruta embalada, recepción fruta comercial. Recepción fruta granel: Corresponde a la cosecha de fruta a granel de distintos productores, sean estos propios o terceros, para ser almacenado y procesado en la planta. El proceso se inicia con el registro de camión con fruta a la planta (control portería), y termina con el camión destarado y fuera de la planta (control portería). Recepción fruta embalada: La funcionalidad es recibir un producto terminado, vale decir, fruta que tiene su proceso de embalaje terminado y que está en condiciones de ingresar a frigorífico para aplicación de prefrío (si corresponde) o directo a cámaras de mantención de frío, donde esperará para ser despachada al destino final. El proceso se inicia con la recepción de la fruta en Planta (control portería) y termina con el despacho del camión fuera de la planta (control portería). Recepción fruta comercial: Cumple el mismo ciclo de la Fruta a Granel, sólo que si corresponde a un servicio, se puede optar por no detallar los kilogramos en la guía de recepción definitiva. Para el caso de traslados entre plantas, se registrará un pesaje referencial para controlar el peso original. Toda la identificación de los bins se mantendrá. El proceso se inicia con registro de camión con fruta a la planta (control portería), y termina con el camión destarado y fuera de la planta (control portería). Juan Ignacio Pino Pizarro Página 37

38 Capítulo 3: Diagnóstico situación actual Proceso de ducha bins Aplicar ducha con determinados tipos de productos a la fruta que ingresa a planta, ya sea sólo agua o agua con productos como fungicidas y retardantes. Se controla la durabilidad de la ducha y rendimiento según las pasadas de la fruta Proceso de control de calidad Efectúa análisis de calidad a toda fruta que ingresa a la planta. El análisis o mediciones que se realizan variará según tipo de fruta, dependiendo si es fruta granel, embalada o comercial. Los subprocesos de control de calidad son: Programa Madurez. Recepción de Fruta Post Cosecha. Revisión y análisis de embalaje orientado a los procesos. Revisión y análisis fruta comercial. Control diario de temperatura a fruta en cámaras. Control de temperatura en preembarque Proceso de fruta embalada Se realiza en el Packing utilizando como materia prima la fruta a granel para producir fruta embalada. Su función es realizar procesos de embalajes de fruta para entregar un producto envasado con diversas características, como por ejemplo: envases, embalajes, categorías, calibres y cantidad de cajas por pallets y un producto de fruta comercial identificado por bins para mercado interno. El Packing realizará la producción de acuerdo a un programa de embalaje confeccionado por el Área de Producción en conjunto con el Área Comercial. El programa refleja las características de los pedidos de cada Recibidor o lo que se proyecta exportar a un mercado específico. Los procesos son individualizados por productor, especie, variedad y tipo de frío. El resultado de cada proceso reflejará el rendimiento de la Juan Ignacio Pino Pizarro Página 38

39 Capítulo 3: Diagnóstico situación actual fruta de exportación del productor, que debe ser informado mediante un informe denominado Cuadratura de proceso Proceso de control SAG Este subproceso se ejecuta al ser requerido por la planta al organismo SAG, para revisar fruta en origen, dependiendo del mercado a exportar. La planta presenta distintos lotes de fruta para la inspección (pallets). El detalle de la inspección se envía, a través de un medio magnético o por correo electrónico, al SAG para su registro y control Proceso de coordinación y despacho de fruta Éste proceso efectúa los despachos de fruta en sus distintos estados: despachos de fruta granel, despachos de fruta embalada y despachos de fruta comercial. Despacho fruta granel: Proceso que controla los traslados de la fruta a granel sin procesar, se realiza fundamentalmente por motivos de capacidad de frío en una planta o por condiciones de la fruta para distintos procesos. Despacho fruta embalada: Proceso que involucra la coordinación de 4 áreas operativas: Comercial, Tráfico, Frigorífico, Despacho. A través de una orden de venta o un contrato se identifica y caracteriza la fruta comprometida con los recibidores. Se coordinan los despachos a través de una orden de embarque que maneja toda la información del destino de la fruta y los controles que debe tener. Finalmente se coordina el camión despachado para el puerto y hora de embarque para cumplir las exigencias del recibidor. Despacho fruta comercial: Este proceso se inicia con la solicitud del cliente de revisar la fruta que desea comprar. Se confirman las condiciones del negocio con el cliente, confeccionándose una orden de venta de mercado interno. Se realiza un Juan Ignacio Pino Pizarro Página 39

40 Capítulo 3: Diagnóstico situación actual pesaje de camión y control de envases, luego se confirma el detalle definitivo, se asigna el precio de venta y despacha el camión. 3.2 Análisis de flujos y gestión de la información actual El análisis de flujos y gestión de información tiene como finalidad tener una magnitud de qué tipo, qué volumen, con qué tiempo, en qué lugar y dónde se almacena la información perteneciente a los procesos tanto productivos como internos. En esta etapa se realiza el estudio de cómo se genera la información en los distintos puntos de control de operaciones en la empresa. Para ello se realiza el seguimiento a los productos en las distintas partes de los procesos que se lleva a cabo. Guía SII Productor Guía Transitoria Recepción Guía Recepción Definitiva Análisis Control de Calidad Recepción Materiales Recepción y Salida Romana Control de Calidad Completación Guía Transitoria Recepción Bodega Insumos Químicos Ducha Bins Almacenamiento Materiales Almacenamiento Cámaras Frigoríficas Completación Guía Transitoria Recepción Orden de proceso Bodega de Materiales PROCESO PRODUCTIVO Palletizaje Control de Calidad Guía SII Precios Referenciales Planilla de control del SAG Planilla de antepuerto Tarja Almacenamiento Cámara de Frío Despacho Embarque Pre Frío Inspección SAG (USDA y Origen) Figura N 5: Diagrama de Flujo de datos en el proceso Juan Ignacio Pino Pizarro Página 40

41 Capítulo 3: Diagnóstico situación actual Proceso de recepción de fruta Los movimientos de recepción de fruta en este proceso están conformados por: Recepción fruta granel sin procesar El flujo y los procedimientos establecidos para realizar la recepción varían dependiendo del origen de la fruta y tipo de servicio contratado. Recepción fruta granel de huerto a) Ingreso a Romana Camión ingresa a romana para registrar los antecedentes de la Guía de SII del Productor especificando especie, variedad y cantidad de bultos. Obtención del peso del camión desde romana, cantidad de envases por calidad, total de kilogramos de envases y el tipo de servicio al que será sometido. Asignar número correlativo de recepción por planta. El contenido del camión será identificado por cada variedad, asignándole un número de lote de recepción compuesto por código de planta, especie y correlativo. Generar correlativo para el registro de Control de Calidad para cada lote de recepción. Romana confecciona la Guía de Recepción Transitoria; documento es entregado al conductor del camión para que continúe el ciclo por la planta y lo entregue en cada punto de control para complementar información. b) Control de Calidad Recibe copia de guía transitoria como respaldo para verificar las variedades indicadas por el productor, respecto a lo que físicamente contiene el camión. Indica si la fruta tendrá aplicación de ducha. Confirma el tratamiento de almacenaje al que viene destinada la fruta. Toma muestras de fruta de distintos bins para ser sometida a los análisis correspondientes. Juan Ignacio Pino Pizarro Página 41

42 Capítulo 3: Diagnóstico situación actual Resultados obtenidos serán registrados al lote de recepción determinado en la Guía Transitoria. c) Frigorífico Descarga la fruta del camión e identifica cada bins con el Número de Lote que indica la Guía Transitoria. Camarero ingresa los bins a cámara de mantenimiento, confeccionando el Plano de Estiba. El camión continúa ciclo, pasando a retirar envases y dirigirse a Romana para realizar el destare. d) Patio de Envases Controla cuenta corriente de envases del productor para permitir el retiro de nuevos envases. Carga envases al camión identificados por calidad y los registra en guía transitoria. e) Salida Romana El camión regresa a la romana para obtener el nuevo peso del camión y el peso de los envases (si corresponde), lo que dará origen al destare para determinar el peso neto de la fruta que ha quedado ingresada a la planta. Se distribuyen los kilogramos netos según la cantidad de bultos por lote de recepción. Genera la documentación necesaria para enviar al Productor y a los registros de control de la planta. Los documentos a entregar son: Guía de Recepción Definitiva, Guía de SII por Envases Retirados (si corresponde) y Análisis Control de Calidad (puede ser entregado en una etapa posterior). f) Portería Control de documentación. Juan Ignacio Pino Pizarro Página 42

43 Capítulo 3: Diagnóstico situación actual Recepción fruta granel plantas propias Corresponde al traslado de fruta desde una planta o frigorífico de la misma empresa a otra planta. Ingresa el camión a Romana para obtener un pesaje referencial, ya que se respetarán los kilogramos netos originales de cada Lote (informado a productor). El control de envases asociados al ingreso de fruta se registrará bajo las mismas condiciones de la recepción original, pero se llevará la cuenta corriente a la planta que envía los envases. El resto del ciclo es igual a recepción fruta granel de huerto. Recepción Fruta Embalada a) Frigorífico Recibe camión y retira guía de SII del Productor. Valida información documental según lo físico que se está recibiendo (el dato físico prevalece sobre los documentos enviados). Confecciona Tarja identificación de pallets, si no viene identificado. Registra información referida a la Guía de SII y el detalle de los pallets. Confecciona Anexo de Recepción con detalle de pallets para ser enviada al Productor. Despacha camión fuera de la planta. b) Portería Control de documentación. c) Frigorífico Almacenaje Registra número de pallets en plano de estiba, identificando la ubicación en una cámara determinada. Juan Ignacio Pino Pizarro Página 43

44 Capítulo 3: Diagnóstico situación actual Recepción Fruta Comercial a) Romana Registra el peso de entrada y detalle de fruta. Registra envases por calidad. Confecciona guía transitoria de recepción. b) Frigorífico Descarga fruta. Identifica bultos con tarja de identificación fruta comercial sólo servicio a terceros. Confecciona plano de estiba para almacenaje en cámara. Despacha camión a Romana. c) Romana Realiza destare de camión, para obtener los kilogramos netos de la fruta. Distribuye los kilogramos netos a bins dejados en la planta. Emite guía de recepción definitiva. Emite guía SII por envases si corresponde. d) Portería Control de Documentación Proceso de fruta embalada Se realiza en packing utilizando como materia prima la fruta a granel para producir fruta embalada. Su función es realizar procesos de embalajes de fruta para entregar un producto envasado con diversas características, como por ejemplo: envases, embalajes, categorías, calibres y cantidad de cajas por pallets y un producto de fruta comercial identificado por bins para Mercado Interno. El packing realizará la producción de acuerdo a un programa de embalaje confeccionado por el Área de Producción en conjunto con el Área Comercial. El programa refleja las características de los pedidos de cada Recibidor o lo que se proyecta Juan Ignacio Pino Pizarro Página 44

45 Capítulo 3: Diagnóstico situación actual exportar a un mercado específico. Los procesos son individualizados por productor, especie, variedad y tipo de frío. El resultado de cada proceso reflejará el rendimiento de la fruta de exportación del productor, que debe ser informados mediante un informe denominado Cuadratura de proceso. Flujo operativo Frigorífico despacha lotes de fruta a granel de acuerdo a Orden de Proceso. Packing recibe fruta a granel desde el frigorífico y realiza vaciado a las líneas de producción. Packing realiza la confección de pallets identificándolo con una tarja de pallets. Packing realiza pesaje por bins e identificación fruta comercial. Packing entrega a frigorífico de fruta embalada y fruta comercial para almacenaje en cámara. Cuadratura de proceso por productor, especie y variedad. Emisión informe proceso productor para visto bueno de jefe de planta. Enviar al Productor. Proceso Productivo a) Área de Producción Confecciona el Programa de Embalaje general, que de acuerdo a una programación periódica debe ejecutar el Packing específico a un pedido determinado. Este programa está basado en un alto porcentaje en el Programa Comercial, ajustable en el transcurso del tiempo. Indica características del embalaje solicitado, y eventualmente podrá indicar el mercado y / o recibidor. b) Jefe de Planta Genera Orden de Proceso que identifica el programa de embalaje y selecciona el pedido para el Packing, identificando el productor por cada una de ellas. Informa a las áreas involucradas los embalajes programados. Juan Ignacio Pino Pizarro Página 45

46 Capítulo 3: Diagnóstico situación actual c) Frigorífico Despacha la fruta granel del productor indicado en la Orden de Proceso. Confecciona un Traspaso Interno de Frigorífico, identificado por un correlativo de despacho, detallando el Lote de recepción, cámara y cantidad de bultos. Rebaja Existencias en forma transitoria, que se confirmarán una vez cerrada la orden de proceso. d) Packing Ejecuta el proceso de embalaje de acuerdo a las especificaciones recibidas en la Orden de Proceso. El proceso se inicia al recibir el documento de Traspaso Interno confeccionado por Frigorífico con la especificación de los Lotes del Productor. Identifica los bultos vaciados a la línea. Aquellos que no fueron vaciados deben ser devueltos a frigorífico. Genera fruta embalada para Exportación identificándola con una tarja de pallets. Pesaje de envases vacíos para fruta comercial. Genera fruta comercial, que no cumple las normas de embalaje, identificándola con una tarja comercial. Destare de bins con fruta comercial para obtener peso neto de la fruta. Entrega la fruta ordenada para almacenaje en frío. Como procedimiento de control, ningún pallets y/o bins puede ser retirado por frigorífico sin la identificación correspondiente. Realiza la cuadratura del proceso. Efectúa cierre de proceso. e) Control de Calidad Realiza controles de calidad, condición, plagas y enfermedades en la fruta. Toma muestras del peso de las cajas por envase y calibre, que determinarán un peso promedio para determinar los kilogramos de exportación. Juan Ignacio Pino Pizarro Página 46

47 Capítulo 3: Diagnóstico situación actual Proceso de coordinación y despacho de fruta Despacho Fruta Granel Proceso que controla los traslados de la fruta a granel sin procesar, se realiza fundamentalmente por motivos de capacidad de frío en una planta o por condiciones de la fruta para distintos procesos. La planta de origen emite una Orden de Traslado y Frigorífico procede a despachar a través de un Traspaso de Frigorífico Fruta Granel. La planta receptora conserva los datos que dieron origen a cada lote en la recepción inicial. Despacho Fruta Embalada a) Área Comercial Identifica a través de una Orden de Venta o un Contrato general las características de la fruta comprometida con los recibidores. b) Área Tráfico de Embarque: Coordina los despachos a las plantas a través del Instructivo de Embarque. Coordina el transporte y distribución de carga por empresa según porcentaje de participación atribuido por contrato. Realiza la cuadratura de los embarques desde las plantas respecto a lo recibido en Puerto. c) Frigorífico: Realiza físicamente el despacho, respaldándose en el instructivo de Embarque entregado por el área de Tráfico. Carga los camiones mediante un Plano de Carga, donde se indican los números de pallets. Confecciona Anexo de Despacho, identificando el detalle de la fruta por cada pallets y un resumen del camión. Emite Guía de SII con precios referenciales. Emite planillas de control del SAG. Emite planilla de Antepuerto. Juan Ignacio Pino Pizarro Página 47

48 Capítulo 3: Diagnóstico situación actual Genera información de la fruta despachada con inspección y envía al SAG. d) Portería Efectúa controles establecidos por la administración. Retira copias de documentos correspondientes. e) Puerto Recibe fruta desde plantas. Recibe documentación por camión (Anexo de despacho, guía de SII y planilla de Antepuerto). Confirma embarques a planta. Despacho Fruta Comercial Este proceso se inicia con la solicitud del Cliente de revisar la fruta que desea comprar. a) Área Mercado Interno Vende fruta comercial. Confirma las condiciones del negocio con el cliente, confecciona una Orden de Venta Mercado Interno. Autoriza al cliente cargar la fruta contratada. b) Romana Realiza pesaje del camión. Controla envases del cliente por calidad. Emite guía transitoria con característica de orden de venta. c) Patio de Envases Descarga de envases de fruta comercial. Juan Ignacio Pino Pizarro Página 48

49 Capítulo 3: Diagnóstico situación actual d) Frigorífico Efectúa la carga física de la fruta teniendo como referencia la Orden de Venta de Mercado Interno. Confecciona un Traspaso de Fruta Comercial por el total solicitado, pudiendo despachar algo distinto a la orden, identificando los envases por calidad. Despacha el camión a Romana para destare. e) Romana 1) Realiza pesaje definitivo, captura kilogramos reales. 2) Emite Guía Definitiva con el detalle de la distribución de los kilogramos netos asociados a la orden de venta de Mercado Interno. a) Área de Mercado Interno i) Confirma detalle de venta (prevalece lo despachado por frigorífico). ii) Asigna precios de venta. iii) Emite Guía de Despacho SII o Factura Comercial. b) Portería Realiza el control de la documentación y retira copias correspondientes Juan Ignacio Pino Pizarro Página 49

50 Capítulo 3: Diagnóstico situación actual 3.3 Estudio sistemas de información corporativos (ERP QlikView) ERP PRAGMATIC XXI En Copefrut S.A. se cuenta con un ERP Pragmatic XXI, especialmente diseñado para empresas del rubro frutícola. El ERP permite gestionar eficientemente las áreas más críticas del negocio como Producción, Logística y Comercio Exterior. Además permite el desarrollo de nuevos módulos y aplicaciones extendidas sobre el mismo programa, lo que da una mayor personalización y modernización del sistema de Gestión. Los principales módulos se presentan en la figura N 6. Figura N 6: Esquema de Módulos Implementados de ERP A continuación se detallan cada uno de estos módulos. Juan Ignacio Pino Pizarro Página 50