Tesis Vasquez Silva - Final

UNIVERSIDAD RICARDO PALMA FACULTAD DE INGENIERÍA ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA “DESARROLLO DE UN SISTEMA

Views 84 Downloads 1 File size 13MB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

UNIVERSIDAD RICARDO PALMA FACULTAD DE INGENIERÍA ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA “DESARROLLO DE UN SISTEMA WEB PARA EL CONTROL Y PLANIFICACIÓN DE LA PRODUCCIÓN PARA LA EMPRESA COGORNO S.A.”

TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO INFORMÁTICO PRESENTADO POR: MADELEYNE PRESILA SILVA RODRIGUEZ JONATHAN COLBERT VÁSQUEZ SEMINARIO

LIMA – PERÚ 2013

DEDICATORIA Dedicamos el presente trabajo a nuestros queridos padres, ya que gracias a ellos tuvimos la oportunidad de forjarnos un futuro venturoso.

AGRADECIMIENTOS Agradecemos especialmente a nuestros queridos padres que nos han dado la gran oportunidad de ser profesionales en la vida, así como a nuestro asesor el Dr. Humberto Linárez Coloma por todo el apoyo prestado a lo largo del desarrollo del presente proyecto de tesis. A nuestro jurado revisor Silverio Bustos, Lizardo Silva, Augusto Cortez y Hugo Vega por su paciencia y voluntad de apoyarnos cuando lo hemos necesitado. Por último, agradecer a la universidad Ricardo Palma por todos los materiales e infraestructura prestada a lo largo de la investigación.

EPÍGRAFE Hay una fuerza motriz más poderosa que el vapor, la electricidad y la energía atómica: la voluntad. Albert Einstein

RESUMEN Título

:

Autor : Seminario Asesor de Tesis Jurado Evaluador : Escuela)

Desarrollo de un sistema web para el control y planificación de la producción para la empresa Cogorno S.A. Madeleyne Presila Silva Rodriguez, Jonathan Colbert Vásquez :

Dr. Humberto Linárez Coloma Presidente: Dr. Hugo Vega

Huerta

(Director

de

Miembros: Dr. Silverio Bustos, Lic. Lizardo Silva, Mg. Augusto Cortez Fecha

:

22 Noviembre del 2013

El controlar la producción significa contemplar una serie de aristas que te aseguran una producción eficiente. En tal sentido, una parte importante y crucial del ciclo productivo es la planificación. La planificación contempla un análisis de los recursos con los que se cuenta, y los rendimientos de las líneas productivas, además de una proyección de la demanda las cuales pueden ser por zonas y por clientes específicos (exportación y clientes grandes), entre otros factores que se contempla se puede mencionar a las planificaciones de mantenimientos preventivos de las líneas de producción

así como los programas de

controles de calidad. Por otro lado, teniendo la planificación de la producción lista para realizarse el siguiente paso es el seguimiento de la puesta en producción de ésta y controlar las posibles desviaciones que pueda sufrir el programa por factores que no fueron controlados o fueron gestionados de manera inadecuada. Finalmente, la gestión de órdenes de compras que surge a raíz del uso de insumos es de suma importancia para los futuros programas de planificación. Palabras Claves: Planificación de la Producción, Sistemas Web, Controles Productivos, Estimado mensual de ventas, Rendimiento de líneas productivas, recursos inventariables y no inventariables, Familias (Divisiones) Productivas.

iv

ABSTRACT Title

:

Development of a web system for control and production planning for the company Cogorno S.A. Author : Madeleyne Presila Silva Rodriguez, Jonathan Colbert Vásquez Seminario Thesis Advisor : Dr. Humberto Linárez Coloma Jury Reviewer : President: Dr. Hugo Vega Huerta (Head of School) Members: Dr. Silverio Bustos, Lic. Lizardo Silva, Mg. Augusto Cortez Date : November 22, 2013 The output control means presents a series of edges that will ensure efficient production. In this regard, an important and crucial in the production cycle is planning. The plan includes an analysis of the resources that are available, and yields of the production lines, as well as a projection of demand which can be by zones and specific customers (export and large customers), among other factors is contemplated may be mentioned preventive maintenance schedules of production lines as well as quality control programs. On the other hand, having the production planning made ready for the next step is to monitor the implementation and control these production possible deviations that may occur to the program by factors that were not controlled or were improperly managed. Finally, management of purchase orders that arises from the use of inputs is critical for planning future programs. Keywords: Production Planning, Web Systems, Controls Productive Estimated monthly sales performance production lines, inventoried and non-inventoried resources, Families (Divisions) Productive.

v

FICHA CATALOGRÁFICA Silva Rodriguez, Madeleyne Presila Vásquez Seminario, Jonathan Colbert Desarrollo de un sistema web para el control y planificación de la producción para la empresa COGORNO S.A. H Information Systems H.4 Information Systems Applications (Lima, Perú 2013) Tesis, Facultad de Ingeniería, Escuela Profesional de Ingeniería Informática, Pregrado, Universidad Ricardo Palma. Formato 28 x 20 cm

Páginas 228

vi

ÍNDICE RESUMEN................................................................................................... IV ABSTRACT................................................................................................... V FICHA CATALOGRÁFICA..............................................................................VI INTRODUCCIÓN........................................................................................... 1 CAPÍTULO I - VISIÓN DEL PROYECTO ............................................................3 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

ANTECEDENTES DEL PROBLEMA....................................................................................3 FUNDAMENTACIÓN DEL PROBLEMA................................................................................7 OBJETIVOS DEL PROYECTO......................................................................................... 12 IMPORTANCIA.......................................................................................................... 16 ALCANCE DEL PROYECTO........................................................................................... 17 VIABILIDAD DEL PROYECTO........................................................................................18

CAPÍTULO II – MARCO TEÓRICO...................................................................43 2.1. DEFINICIONES DEL NEGOCIO......................................................................................43 2.2. INTRODUCCIÓN A LAS TECNOLOGÍAS BÁSICAS................................................................45 CAPÍTULO III – ESTADO DEL ARTE................................................................56 3.1. ERP IMPLEMENTATION FOR PRODUCTION PLANNING AT EA CAKES LTD..............................56 3.2. INTEGRATION OF PRODUCTION PLANNING AND SCHEDULING USING AN EXPERT SYSTEM AND A GENETIC ALGORITHM........................................................................................................ 60 3.3. PROCESS AND QUALITY MODEL FOR THE PRODUCTION PLANNING AND CONTROL SYSTEMS.....63 3.4. BENCHMARKING (ANÁLISIS COMPARATIVO CON OTRAS SOLUCIONES)..................................67 CAPÍTULO IV – MODELADO DEL NEGOCIO ....................................................75 4.1. 4.2. 4.3. 4.4.

REGLAS DE NEGOCIO............................................................................................... 75 CASOS DE USO DEL NEGOCIO....................................................................................76 DIAGRAMAS DE ACTIVIDADES DEL NEGOCIO..................................................................85 DIAGRAMA DE CLASES DE OBJETO DEL NEGOCIO ..........................................................87

CAPÍTULO V– REQUERIMIENTOS DEL PROYECTO...........................................89 5.1. 5.2. 5.3. 5.4.

REQUERIMIENTOS DEL SOFTWARE................................................................................89 CASOS DE USO DEL SISTEMA.....................................................................................92 MODELO CONCEPTUAL DEL SISTEMA............................................................................97 PROTOTIPOS DE LA SOLUCIÓN....................................................................................98

CAPÍTULO VI – ARQUITECTURA..................................................................111 6.1. 6.2. 6.3. 6.4. 6.5.

REALIZACIÓN DE LOS CASOS DE USO MÁS SIGNIFICATIVOS PARA LA ARQUITECTURA.............111 DIAGRAMA DE CLASES DE DISEÑO............................................................................137 MODELO DE DATOS...............................................................................................138 MODELO DE DESPLIEGUE........................................................................................148 MODELO DE COMPONENTES.....................................................................................148

CAPÍTULO VII – DESARROLLO Y PRUEBAS..................................................151 7.1. DESARROLLO........................................................................................................ 151 7.2. PRUEBAS.............................................................................................................. 152 CAPÍTULO VIII – GESTIÓN DEL PROYECTO..................................................165

vii

8.1. ORGANIZACIÓN DEL PROYECTO ................................................................................165 8.2. ESTIMACIÓN Y EJECUCIÓN DEL PROYECTO...................................................................166 8.3. GESTIÓN DE RIESGOS DEL PROYECTO........................................................................168 CONCLUSIONES.......................................................................................174 RECOMENDACIONES ................................................................................175 GLOSARIO DE TÉRMINOS..........................................................................176 178 SIGLARIO................................................................................................. 178 BIBLIOGRAFÍA..........................................................................................179 ANEXOS.................................................................................................. 183 ANEXO 01 .............................................................................................................. 184 ANEXO 02 .............................................................................................................. 196 ANEXO 03 .............................................................................................................. 202

viii

ÍNDICE DE FIGURAS

ÍNDICE DE TABLAS TABLA 1: SE MUESTRA LOS TIEMPOS QUE TOMA CADA ACCIÓN.....................12 TABLA 2: TABLA DE LICENCIAS Y DOMINIOS NECESARIOS..............................18 TABLA 3: TABLA DE HARDWARES NECESARIOS PARA LA IMPLEMENTACIÓN DEL PROYECTO...........................................................................................19 TABLA 4: TABLA DE VIABILIDAD ECONÓMICA DEL HARDWARE.......................20 TABLA 5: TABLA DE VIABILIDAD ECONÓMICA DEL SOFTWARE........................20 TABLA 6: TABLA DE VIABILIDAD ECONÓMICA DE RECURSOS HUMANOS..........21 TABLA 7: TABLA DE VIABILIDAD ECONÓMICA DE SERVICIOS PRESTADOS POR TERCEROS.................................................................................................. 21 TABLA 8: TABLA DEL TOTAL DE VENTAS.....................................................24 TABLA 9: TABLA DE BENEFICIO OBTENIDO. – ALTERNATIVA AL 50% DE MEJORA. ................................................................................................................. 24 TABLA 10: TABLA DEL TOTAL DE VENTAS....................................................26 TABLA 11: TABLA DE BENEFICIO OBTENIDO. – ALTERNATIVA AL 10% DE MEJORA...................................................................................................... 26 TABLA 12: MATRIZ DE RESPONSABILIDADES – ESTIMADO VENTAS. ...............32 TABLA 13: MATRIZ DE RESPONSABILIDADES – PLANEACIÓN MANTENIMIENTO. ................................................................................................................. 36 TABLA 14: MATRIZ DE RESPONSABILIDADES – PLANTA BALANCEADOS. .........39

ix

TABLA 15: MATRIZ DE RESPONSABILIDADES – MOLINO CALLAO. ...................42 TABLA 16: CUADRO COMPARATIVO DE SOLUCIONES ENCONTRADAS..............74 TABLA 17: DESCRIBE LA LISTA DE REGLAS DEL NEGOCIO..............................75 TABLA 18: LISTA DE REQUERIMIENTOS DEL PROYECTO.................................89 TABLA 19: LISTA DE REQUERIMIENTOS FUNCIONALES DEL PROYECTO..........90 TABLA 20: LISTA DE REQUERIMIENTOS NO FUNCIONALES DEL PROYECTO.....91 TABLA 21: CRONOGRAMA DE PLAN DE PRUEBAS.........................................153 TABLA 22: PRESUPUESTO TOTAL DEL PROYECTO........................................167

x

INTRODUCCIÓN Actualmente, todo proceso productivo del sector industrial enfocado en la producción de harinas como de fideos y alimentos balanceados (normado por la empresa a niveles de procedimientos) cuenta con una serie de controles, procedimientos, restricciones, etc. para la puesta en producción de los productos, desde la asignación de recursos inventariables y no inventariables hasta el empacado del producto. Las empresas del sector industrial, en su mayoría, analizan una serie de aristas para controlar la producción, la cual consiste en analizar el stock de productos disponibles y días de alcance de los mismos, elaborar un estrategia de demanda en base a las estimaciones de ventas semanal, mensual, trimestral, semestral y anual (depende mucho de la política de ventas de las empresa), controles de calidad a niveles de las líneas de producción, disponibilidad de insumos los cuales pueden ser recursos inventariables y no inventariables, disponibilidad de espacio en almacenes (parihuelas disponibles), disponibilidad y asignación de recursos humanos.

Figura 1: Reporte del consumo nacional de pastas. (Fuente: IPO Annual Survey on World Pasta Industry, 2012.)

1

Actualmente, el Perú ocupa la posición número 11 en la producción de pastas en el mundo, según la gráfica tomada de IPO Annual Survey on World Pasta Industry (October 2012), desplazando a países como Chile, Portugal y Colombia. Entonces, si deseamos mejorar posiciones a niveles productivos debemos obtener mejores controles sistematizados a niveles de producción. (Industry, 2012)

2

CAPÍTULO I - VISIÓN DEL PROYECTO 1.1. Antecedentes del Problema 1.1.1. El Negocio De origen familiar, fue fundada hace 85 años por Don Eugenio Cogorno y su esposa Clara. Es continuada por sus hijos Herminio, Rosa y Atilio. Se dedica a la fabricación de productos derivados del trigo: Harinas para diversos usos, fideos y alimentos balanceados para animales.

Colaboran con ellos calificados profesionales que cautelan el prestigio y la calidad de la empresa y de sus productos.

1.1.1.1. Organización Durante su trayectoria ha tenido un sólido crecimiento en sus plantas de producción ubicadas: en el Callao, La Perla, Ventanilla y Salaverry en Trujillo que superan los 150,000 m2. Además de la constante modernización de sus instalaciones, maquinarias y tecnología; tanto en los molinos y fábricas de fideos en Lima como en Trujillo, y que en los últimos tres años han superado los $ 15, 000,000 de dólares, todo ello en el marco de un plan de desarrollo denominado “Rumbo al Centenario”.

1.1.1.2. Visión Ser reconocida como la mejor comercializadora de productos de calidad y nutritivos a base de trigo, con una red de distribución a nivel nacional.

3

1.1.1.3. Misión Contribuir con la nutrición y alimentación saludable de nuestros clientes brindándoles productos de calidad en base a trigo.

Incrementar sosteniblemente las utilidades que garanticen tranquilidad de nuestros inversionistas. Garantizar un clima laboral adecuado que logre la superación personal y profesional de nuestro personal garantizando tranquilidad económica. (Cogorno, 2013)

1.1.1.4. Posicionamiento en el Mercado La industria de fideos está en pleno crecimiento. La ampliación de los canales de comercialización y la diversificación de presentaciones son las principales oportunidades para ampliar el mercado.

Actualmente en el mercado de Lima Metropolitana compiten alrededor de 20 marcas de fideos, entre marcas Premium, económicas y súper económicas. Las marcas económicas han presentado una mayor penetración en el mercado, y la seguirán teniendo, impulsadas por el mayor poder adquisitivo de los sectores C y D, así como por la apertura de nuevos supermercados y centros de abastos que tienen a estos sectores como público objetivo.

Nuestro

producto

tradicional

“fideos

Cogorno”

esta

posicionado en los sectores C y D por el factor precio que se toma mucho en cuenta, la desventaja es que la mayoría de los consumidores compran los fideos a granel lo cual significa que 4

no tienen fidelidad, conocimiento o no toman importancia a la marca, solo una pequeña parte de este grupo consume el producto envasado por cuestión de seguridad, salubridad y siente agrado por la marca. (Cogorno, Cogorno Blog, 2013)

1.1.2. Procesos del Negocio Actualmente, los procesos que intervienen en controlar la producción abarcan desde su planificación hasta el empacado del producto final. Partiendo

desde

dicha

premisa

se

mencionará

los

procesos

involucrados en la producción.

A continuación el Mapa de Negocio en la cual se aprecia la interacción de los procesos mencionados líneas atrás.

Figura 2: Procesos de Negocio del control de la producción. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

5

1.1.2.1. Ventas Este proceso se encarga de recoger la demanda del mercado interno para luego derivarlos al área de producción.

1.1.2.2. Calidad Se encarga de que los productos producidos tengan un grado de calidad óptimo para el consumo humano. Una arista de dicho control es la programación de controles de fumigación de las líneas de producción.

1.1.2.3. Mantenimiento Proceso que se encarga de que las líneas de producción y demás factores tangibles (maquinas, silos, molinos, entre otros) se encuentren en perfectas condiciones, para ello, se elaboran programas de controles preventivos.

1.1.2.4. Planificación En este proceso se recogen todos los datos de ventas, calidad, mantenimiento para elaborar el programa de la producción. Se debe tener presente que también intervienen otros factores para el desarrollo del programa, como son los rendimientos de moldes por línea de producción.

1.1.2.5. Producción En este proceso el programa entra en producción (elaboración de fideos, harinas y alimentos balanceados).

6

1.1.2.6. Empacado En este proceso el producto final arrojado por las divisiones, pasa por el procesos de empacado y agrupado con bobinas (caso fideos).

1.2. Fundamentación del Problema 1.2.1. Análisis del Problema Cuenta la historia que la gestión de la cadena de producción a niveles de MRP (Planificación de los Requerimientos de Material) nace en plena segunda guerra mundial por el gobierno de los Estados Unidos de América. Ya en la década de los 50 es a causa del boom computacional que los MRPs toman mayor connotación en los sectores de producción.

Ya en la década de los 60 y 70 (con el avance tecnológico) es que toman mayor relevancia debido a su apoyo en la reducción de niveles de inventario que a su vez generaban ahorros de dinero y tiempo.

Ahora bien, sabiendo que en el Perú comienza la sistematización de procesos tibiamente en la década de los 80, para tomar fuerza en los 90 y consolidarse como arteria vital de toda empresa en la actualidad, se puede deducir que la gestión de la cadena productiva se gestionaba a papel y lápiz, por ejemplo, el registro de inventario se hacían en Kardex, las órdenes de producción se efectuaban arbitrariamente y se apuntaban en papel, etc.

Los antecedentes de la empresa Cogorno no son ajenos a esta pasada realidad, puesto que como empresa Cogorno, adquirió el sistema ADAM a mediados del año 1992 en la cual se hacían los desarrollos en RPG, para luego en el 2006 adquirir un sistema visual llamado 7

SPEED400, el cual se tiene en la actualidad. Es recién en el año 2012 donde se adquiere el módulo de producción MRP de Costos y Control de la Producción, en la cual no se contemplan procesos de planificación de producción y flujos de comunicación para las aprobaciones del programa. (Cogorno, 2013)

1.2.2. Definición o formulación del problema El problema que aqueja a la mayoría de empresas es que no cuentan con sistemas que les permita mejorar sus controles productivos y a mantener una coordinación fluida con todas las áreas que intervienen en la producción.

En el caso de la empresa Cogorno, los procesos que intervienen en la producción están hechos en su mayoría en hojas de cálculo Excel, la cual es muy volátil cuando a datos nos referimos y también poco consolidable cuando se desea obtener reportes gerenciales para la toma de decisiones. Por ejemplo, las verificaciones de stock de productos es consultada de un sistema ERP (Planificación de Recursos Empresariales), tomando dichos datos para almacenarlos en una hoja Excel en la cual se calcula los días de alcance que tiene cada producto, así mismo, las planificaciones de fumigaciones de las maquinarias y silos están registradas en otra hoja Excel, así como también los controles de las líneas de producción. Por otro lado, las verificaciones de disponibilidad de repuestos para las líneas (por ejemplo, los moldes para la elaboración de distintas presentaciones de fideos) están contadas

manualmente

e

informadas

de

su

disponibilidad

presencialmente. Los rendimientos de las líneas de producción por moldes de presentación de los productos están registrados en una hoja Excel.

8

Figura 3: Controles de mantenimiento preventivo de las líneas de

producción. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

Ahora bien, para realizar la planificación de la producción se toman todos los datos mencionados en el párrafo anterior (restricciones), con ello se procede a realizar el programa en una hoja Excel siempre tomando como referencia el estimado de ventas mensual que entrega el área de ventas, también en una hoja Excel, así como la estimación de ventas

para

exportaciones

(que

es

responsable

el

área

de

exportaciones).

Con todas esas aristas el programador desarrolla su programa de planificación, el cual deberá ser aprobado por todas las áreas que intervienen en la cadena productiva. Ahora bien, una vez aprobado el programa ocurre que existen alteraciones del programa en curso, ya sea porque una línea de producción se averió, se acabaron los insumos o simplemente no llegaron a tiempo, o el área de exportación decide que se le debe dar prioridad a otro producto debido a que los importadores

variaron

sus

prioridades,

entonces

existe

una

coordinación más cerrada con el programador, es decir, los demás responsables no se enteran del cambio, es ahí donde se presentan los problemas de comunicación (ver figura 2).

9

Por otro lado, actualmente, se cuenta con un MRP que gestiona las órdenes de producciones, más no las planificaciones, es por ello, que el programa que desarrolla el área de planificación se encargará de alimentar dicho módulo. Por último, se puede apreciar que existen problemas a nivel de comunicación, consolidación de datos, generación de reportes que ayude a comparar las desviaciones del programa y tomar decisiones que mitiguen las causas del no cumplimiento del programa. Así mismo, la poca optimización que tendrá la integración de la planificación que la gestión de las OP (Órdenes de Producciones).

Finalmente se plantea como hipótesis la obtención de una mejor eficiencia en la gestión de la cadena de producción en ámbitos de planificación e integración con un sistema MRP, mediante el Sistema Web propuesto en la presente Tesis y por lo que la eficiencia se mostrará beneficiada con una producción más cercana a lo planeado.

10

1.2.3. Fundamentos Actualmente, se presentan ciertas deficiencias para

controlar la

producción en el ámbito de la programación (planificación).

Figura 4: Ciclo de la planificación de la producción en plantas Cogorno

S.A. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

En la Figura 4 se identifica la poca eficacia del uso del tiempo, y la alta volatilidad de los datos.

A continuación se mostrará un cuadro en la cual se especifica los tiempos que toma cada actividad, así como coordinaciones y acciones tomadas no registradas. 11

Actividad

Acción

Descripción

Tiempo (hrs-hombre)

a

Se verifica a través de otro No hay integridad de los sistema llamado speed400, datos. modulo de inventario.

3hr

b

Los reportes analizados están No hay integridad con los hechos a base Hojas Excel. datos.

4hr

c

Los controles de fumigaciones No hay integridad con los están en Hojas Excel. datos.

2hr

d

Se entrega el programa vía correo No hay control de vistos electrónico, previa reunión de buenos. comité y aprobación.

2hr

e

Se corrige sin comunicar a todos No hay comunicación los interesados, también se fluida ni control de gestión trabaja en Excel. de cambios del programa.

15hr (*)

Tabla 1: Se muestra los tiempos que toma cada acción. (Elaboración: Propia, 2013.)

(*) Las correcciones en promedio son 3 a la semana y cada una requiere 5hr hombre.

Nota: los datos recogidos en la tabla 1 fueron entregados por el área de Planeamiento.

1.3. Objetivos del Proyecto 1.3.1. Marco Lógico A continuación, se muestra el marco lógico con la cual se quiere lograr un análisis de las condiciones actuales del entorno, de tal modo, se pueda obtener una idea más clara, a nivel macro, de la problemática a nivel a de procesos (conceptualización del problema).

12

1.3.1.1. Árbol de Problemas A continuación, se muestra el árbol de problemas teniendo como punto central actividades poco óptimas para la planificación de la producción.

Figura 5: Árbol de problemas. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

13

1.3.1.2. Árbol de Objetivos A continuación, se muestra el árbol de objetivos teniendo como punto central actividades óptimas para la planificación de la producción.

Figura 6: Árbol de objetivos. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

14

1.3.2. Objetivo General El objetivo general del presente proyecto de tesis es lograr que la producción sea controlada a niveles de planificación, consolidación de información e integración de sistemas y una comunicación fluida. Finalmente, obteniendo un mejor control de la cadena de producción, se tendrá una mejor rentabilidad de dinero.

1.3.3. Objetivos Específicos • Integrar el estimado de ventas con la realización del programa de la producción. • Integrar el estimado de exportaciones con la realización del programa de la producción. • Sistematizar e integrar a la realización del programa de la producción el cálculo de los rendimientos de las líneas de producción por artículos a producir. • Replantear los programas cuando estos ya estén en producción y comunicar dichos cambios a los interesados de la realización del programa. • Integrar los controles de calidad con la realización del programa de la producción. • Integrar las programaciones de los mantenimientos preventivos con la realización del programa de la producción. • Comunicar a los responsables directos de la realización del programa ante cualquier alteración de este; por ejemplo, cuando se realicen re programaciones debido a paradas no programadas se deberá comunicar a todos los responsables de los ajustes realizados al programa. 15

1.4. Importancia 1.4.1. Beneficios Tangibles Reducción de costos: Se logrará la reducción de costos gracias a que se desarrollará e implementará un sistema Web que permita gestionar la planificación de manera eficaz, es decir, se producirá en los tiempos establecidos y de acuerdo la capacidad productiva y demanda del mercado. Pues de esta manera se evitará la pérdida por sobreproducción, tiempo y mano de obra en vano invertidos, etc.

Mayor precisión de la producción: La producción de acuerdo a lo que solicita el mercado, es vital en toda empresa, pues gracias a este sistema web se planificará de manera precisa y no habrá desperdicio de material debido a que no se tendrá sobre stock fuera del rango establecido en los días de alcance que tiene cada producto debido a una sobreproducción, ocasionando después que el producto se tenga que donar, vender a precios menores para que las pérdidas no sean tan cuantiosas, etc.

Rapidez y facilidad de la programación de la producción: Con todas las partes enteradas de lo que se necesita producir y con la capacidad productiva sentada, ya no habrá margen de error justificado (fuera de alguna avería ocasional de maquinaría) para programar la producción, en conclusión, los tiempos en el desarrollo del programa se verán disminuidos considerablemente. Se espera que el tiempo que toma el desarrollo del programa se vea reducido en un 40% teniendo como dato que en promedio el desarrollo toma 3 hrs.

16

1.4.2. Beneficios Intangibles Mejor coordinación entre las áreas: La comunicación fluida entre las áreas involucradas es de vital importancia debido a que no se caerá en la producción improvisada, es decir, sin que el encargado de almacén justifique y apruebe que se cuenta con los insumos necesarios para la producción o que se cuenta con la cantidad de bobinas necesaria para el empacado del producto, así mismo, que los responsables de planta de producción den visto bueno a líneas de producción.

Mayor prestigio de la empresa y satisfacción de los clientes: El cumplimiento en las fechas de entrega de los pedidos es muy importante tanto para los clientes como para la empresa, ya que los clientes quedarán satisfechos con las fechas de entrega de sus productos y confiaran en la empresa en un futuro, mientras que la empresa se beneficiará con esta confianza y ganará mayor respeto y dará a la marca mayor prestigio.

1.5. Alcance del Proyecto •

Modelado Total del Negocio.



Modelado Total de Sistema.



Diseño de la base de Datos.



Arquitectura del sistema WEB.



Desarrollo total del sistema Web.



Fiabilidad de la información.



Pruebas de software.



Manual de usuario.

17

1.6. Viabilidad del proyecto 1.6.1. Viabilidad técnica Para la realización del proyecto es fundamental contar con una serie de recursos tecnológicos que ayudarán a desarrollar el sistema. Se ha encontrado la mejor alternativa de entorno de desarrollo para el proyecto. A continuación se explicará dicho criterio. Propuesta La alternativa consiste en usar el protocolo HTTP permitiendo que el aplicativo Web se despliegue a través de cualquier browser de Internet. Ahora bien el Sistema Web estará comunicado con el modulo de producción del sistema SPEED400 (desarrollado en Visual Basic 6.0). Además, todas las transacciones que se hagan con esta aplicación serán a través del motor de base datos compartido DB2 - AS400. Se usará el Framework 4.0 para el desarrollo sistema y se aprovechará el mismo SGBD. Licencias y Dominio Se detalla los recursos a nivel de licencias necesarios para la implementación del sistema, las cuales han sido adquiridas por la empresa. Recurso

Detalle

Dominio

Una dirección IP pública que redireccione a nuestro servidor.

Licencia Visual Studio 2010

Dos licencias de Visual Studio 2010 profesional.

Licencia Windows Server 2003

Una licencia de Windows server 2003 para alojar la página web.

Start UML

Herramienta usada para el modelado del negocio y del sistema. Tabla 2: Tabla de licencias y dominios necesarios. (Elaboración: Propia, 2013.)

18

Tener presente que actualmente se cuenta con servicio de hosting propio en la empresa, además de poseer todas las licencias respectivas a nivel software. Hardware Las características con las que se cuentan a nivel de infraestructura de TI son las siguientes: Recurso

Detalle •

Procesador Pentium IV 3.0 GHz.



Disco Duro de 40 Gb.



Memoria RAM de 2 Gb.

Servidor de base de datos.



AS/400 – iSeries.

PC de desarrollo.



Procesador dual core 3.0 GHZ.



Disco duro de 160 Gb.



Memoria RAM de 2 Gb.



Fast Ethernet (RJ45) 100 Mbps.



Concentrador 100Base-T.

Servidor de aplicaciones.

Concentrador o Hub.

Tabla 3: Tabla de hardwares necesarios para la implementación del proyecto. (Elaboración: Propia, 2013.)

1.6.2. Viabilidad económica De acuerdo a los recursos de hardware y software que se necesitan para la ejecución del presente proyecto, se cuentan:

19

En cuanto al Hardware: Dispositivos (*)

Precio (1)

Cantidad

Subtotal

PC – Desarrollador Pentium 4 •

Disco duro de 80GB.



Procesador Intel 3.0GHz.



Memoria RAM de 2Gb.

Router para la conexión a internet.

2

0

0

1

0

0

1

0

0

PC - Servidor •

Disco duro de 500 Gb.



2 Procesadores de 3.0 GHz.



Memoria RAM de 4 Gb. Total (s/.)

0

Total en 12 Meses

0

Tabla 4: Tabla de viabilidad económica del Hardware. (Elaboración: Propia, 2013.)

En cuanto al Software: Software/ Licencia (*)

Cantidad

Precio (1)

Subtotal

Licencia de Visual studio.Net 2010.

2

0

0

Tabla 5: Tabla de viabilidad económica del Software. (Elaboración: Propia, 2013.)

(*) Representa que ya se cuenta con los recursos mencionados.

20

En cuanto a recursos Humanos: Personal

Cantidad

Costo/Hora

Costo Mensual (*)

Jefe Proyectos

1

S/. 31,25

S/. 6,000

Analista

2

S/. 14,06

S/. 5400

Diseñador

1

S/. 13,02

S/. 2500

Programador

2

S/. 10,42

S/. 4000

Tester

1

S/. 14,06

S/. 2700

Documentador

1

S/. 7,81

S/. 1500

Total (s/.) Total en 6 Meses

S/. 22,100 S/. 132,600

Tabla 6: Tabla de viabilidad económica de recursos humanos. (Elaboración: Propia, 2013.)

(*) En total de horas semanales laborables son 48 hrs que al mes serían 192 hrs. En cuanto a servicios prestados por terceros: Personal

Costo/Mensual

Conexión a internet.

Costo/Mensual (*)

S/. 23

S/. 23

Total (s/.)

S/. 23

Total en 12 Meses

S/. 276

Tabla 7: Tabla de viabilidad económica de servicios prestados por terceros. (Elaboración: Propia, 2013.)

(*) El costo actual del servicio de Internet es de $ 1,100 por 4mb de ancho de banda dedicado. Se toma como referencia dicho monto para realizar un aproximado del costo mensual en consumo de ancho de banda del aplicativo Web. Estimación del Presupuesto Total del Proyecto 21

Para la Estimación de retorno de inversión se han evaluado los costos de inversión en la implementación del sistema Web. Ahora bien, se procederá a demostrar los beneficios en materia de rentabilidad económica. A continuación, se muestra un cuadro de los gastos operativos por hora.

Figura 7: Tabla de remuneración diaria por hora. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

Nota: el tiempo invertido es del 30% del total del día, debido a que el otro 70% es usado para otras funciones.

Así mismo, los gastos actuales de los procesos son los que se muestran a continuación: 22

Figura 8: Tabla de gastos actuales de la empresa por proceso. (Elaboración: Propia, 2013. Fuente: Cogorno, 2006.)

En la figura 8 se aprecia los gastos que se tienen actualmente por proceso, así de cómo serán los gastos después de que el sistema sea implementado.

Por otro lado, el beneficio neto se obtiene en base a la diferencia entre el costo total sin sistema sumado a este las pérdidas ocasionadas (no producción total de lo planeado) menos los costo totales con sistema. El beneficio neto obtenido es de s/. 286,065.04.

Actualmente, el programa de la producción llega a cumplirse en un 80% de lo planificado. 23

Venta promedio mensual

Desviación Programa (%)

Total ventas producto no producido (s/.)

Pérdida estimada (30%)

Sin Sistema

9’500,000.00

20

1’900,000.00

570,000.00

Con Sistema

9’500,000.00

10

950,000.00

285,000.00

Tabla 8: Tabla del total de ventas. (Elaboración: Propia, 2013.)

De ese total no producido se estima que el 30% se pierde debido a que ya no se vende al precio real.

Con la implementación del sistema se estima que la planificación debe mejorar en un 50% sobre un incremento de la efectividad del 10% del programa. Costos y Pérdidas Mensuales Semanal procesos

Procesos

Ventas

Total

Costo Total (Actual)

S/. 692.75

S/. 2,771.00

S/. 570,000.00

S/. 572,771.00

Costo Total (Sistema)

S/. 426.49

S/. 1,705.96

S/. 285,000.00

S/. 286,705.96

Beneficio Bruto

S/. 266.26

S/. 1,065.04

S/. 285,000.00

S/. 286,065.04

S/. 0.00

S/. 0.00

S/. 0.00

S/. 0.00

S/. 266.26

S/. 1,065.04

S/. 285,000.00

S/. 286,065.04

Reducción en Gasto de Material Beneficio Neto

Tabla 9: Tabla de beneficio obtenido. – Alternativa al 50% de mejora. (Elaboración: Propia, 2013.)

Finalmente, como se estimo una mejora de producción en el proceso de planificación del 50% que representa en promedio el monto de s/. 285,000.00 como reducción en pérdidas, el retorno de la inversión comenzaría a partir del primer mes de puesto en producción el sistema.

24

El monto retorno de la inversión se daría en el segundo mes S/. 363.600,52.

Figura 9: Tabla de resultados TIR y VAN (Elaboración: Propia, 2013.)

Nota: Si

la mejora en el proceso de planificación es del 10% en

promedio, la rentabilidad representaría s/. 58,065.04 como reducción en pérdidas.

25

Actualmente, el programa de la producción llega a cumplirse en un 80% de lo planificado. Venta promedio mensual

Desviación Programa (%)

Total ventas producto no producido (s/.)

Pérdida estimada (30%)

Sin Sistema

9’500,000.00

20

1’900,000.00

570,000.00

Con Sistema

9’500,000.00

18

1’710,000.00

513,000.00

Tabla 10: Tabla del total de ventas. (Elaboración: Propia, 2013.)

De ese total no producido se estima que el 30% se pierde debido a que ya no se vende al precio real.

Con la implementación del sistema se estima que la planificación debe mejorar en un 10% sobre un incremento de la efectividad del 2% del programa. Costos y Pérdidas Mensuales Semanal procesos

Procesos

Ventas

Total

Costo Total (Actual)

S/. 692.75

S/. 2,771.00

S/. 570,000.00

S/. 572,771.00

Costo Total (Sistema)

S/. 426.49

S/. 1,705.96

S/. 513,000.00

S/. 514,705.96

Beneficio Bruto

S/. 266.26

S/. 1,065.04

S/. 57,000.00

S/. 58,065.04

S/. 0.00

S/. 0.00

S/. 266.26

S/. 1,065.04

Reducción en Gasto de Material Beneficio Neto

S/. 0.00 S/. 57,000.00

S/. 0.00 S/. 58,065.04

Tabla 11: Tabla de beneficio obtenido. – Alternativa al 10% de mejora. (Elaboración: Propia, 2013.)

26

Finalmente, el retorno de la inversión comenzaría al tercer mes de puesto en producción el sistema. El monto invertido se recuperaría al 7mo mes S/.149.808,93.

Figura 10: Tabla de resultados TIR y VAN. Alternativa al 10% de mejora (Elaboración: Propia, 2013.)

27

1.6.3. Viabilidad legal Políticas del negocio – Planeación 1. El Jefe de Programación de Producción enviará mensualmente la proyección de Consumo de Materia Prima e insumos a logística. 2. Todas las semanas se llevará a cabo la reunión de Programación de Producción. 3. En cada sesión se verán los siguientes puntos: Lista de Asistencia, Revisión del Cumplimiento del Programa de Producción, Revisión de las causas de desviación, Asignación de acciones a tomar, Planeación de producción de la siguiente semana, Aseguramiento de los insumos, Elaborar y Entregar Minuta de Reunión y Acuerdos. 4. Deberán participar/coordinar para esta reunión de programación de la producción

el

Jefe

Programación

de

Producción,

Jefe

de

Administración de Ventas y el Jefe de Planta. 5. El Jefe de Mantenimiento mandará primeramente al Asistente y Jefe de Planta quienes le remitirán a Jefe de PCP la programación de mantenimiento anual / mensual / semanal,

para que éste último,

según dicho programa, realice la programación

de Producción.

Cualquier cambio en el programa de Mantenimiento deberá ser comunicado con la debida anticipación al Jefe de PCP para que tome las medidas del caso. 6. El Programa de Producción semanal preliminar será enviado antes de las 3 pm. los días sábados vía mail a las áreas de Fabricación, Jefatura de Planta por el Jefe de Programación de Producción. 7. El Asistente de Planta entregará antes de las 5 pm. con copia a Jefe de Programación de producción, la reprogramación del día siguiente a fabricación y empaque si es necesario reprogramar. (Cogorno, 2006)

28

8. Diariamente el

Asistente de Planta Jefe de Programación de

Producción se reunirá 10 minutos con el Jefe de Planta para evaluar y dar seguimiento al cumplimiento con la producción según el requerimiento de despacho. 9. El canal oficial para solicitar producción y cambios de producción es el Jefe de Planta, la producción será evaluada y acordada con el Jefe de Programación de Producción. 10. Todo cambio de programación de producción y de requerimiento de despacho deberá ser notificado en el momento que se efectúa a las personas que asisten a la reunión de programación de producción vía mail. 11. El Jefe de Programación de la Producción y el Encargado de Planta, deberán revisar el indicador de días de inventario

de cualquier

producto requerido. 12. Es obligación de todos los participantes, asistir puntualmente a las reuniones estipuladas en la matriz de reuniones. (Cogorno, 2006)

Procedimientos A continuación, se describirá los procedimientos competentes a la planificación de la producción planta fideos.

A. Familia Fideos: 29

División planta fideos sistema de planeación de la producción –Estimado Ventas 1. Enviar Proyección Anual de Ventas: El Jefe de Administración de Ventas debe enviar en la segunda semana de Diciembre la proyección anual de ventas del siguiente año al Jefe de Programación de la Producción, al Jefe de Logística, al Jefe de Distribución y al Jefe de Planta. La proyección debe estar especificada por tipo de producto mes a mes, esto con el fin de planear los meses picos de producción y los mantenimientos integrales. 2. Enviar Proyección de Ventas de los siguientes 3 Meses. Última semana de cada Mes: Cada mes en la última semana del mismo, el Jefe de Administración de Ventas deberá enviar la proyección de los siguientes 3 meses al Jefe de Programación de la Producción, al Jefe de Logística, al Jefe de Distribución y al Jefe de Planta, esto con el fin de ajustar la proyección anual de ventas y anticipar posibles reprogramaciones de los meses picos de producción y mantenimientos integrales. 3. Enviar Proyección Semanal de Ventas del siguiente Mes: La última semana de cada mes el Jefe de Administración de Ventas debe enviar la proyección de ventas del siguiente mes disgregada en las semanas que correspondan a ese mes. Así un mes de cuatro semanas tendrá la proyección de cada semana. La proyección debe ser distribuida al Jefe de Programación de la Producción, al Jefe de logística, al Jefe de Distribución y al Jefe de Planta. 4. Revisar Semanalmente Terminados):

Stocks APT

(Almacén

de

Productos

30

El Jefe de Distribución revisa semanalmente los Stocks de producto terminado para verificar las existencias y los alcances en días, esta revisión desde el punto de vista del área de Producción debe realizarse cada viernes para prever ruptura de Stocks. 5. Revisar Diariamente Stocks APT: El Jefe de Distribución debe estar informado de los Stock diarios de producto terminado de acuerdo a los despachos

e ingresos al

almacén de producto terminado, esto con el fin de determinar posibles faltas de producto y realizar a tiempo los requerimientos a producción. 6. Revisar el indicador de Días de Inventario: El Jefe de Distribución antes de emitir el requerimiento semanal de despacho debe revisar el indicador de días de inventario, esto con la finalidad de ajustar el requerimiento y evitar sobre stocks. 7. Enviar el Requerimiento Semanal de Despacho con proyección quincenal: El Jefe de Distribución debe entregar como máximo a las 5 p.m. los días viernes por mail el requerimiento semanal de despacho de las siguientes dos semanas, siendo la primera semana un requerimiento oficial y la segunda semana una proyección tentativa que será oficializada al siguiente viernes. El requerimiento debe ser enviado al Jefe de Administración de Ventas, al Jefe de Planta y al Jefe de Programación de Producción. 8. Enviar el Indicador de Venta Perdida: El Jefe de Distribución envía al Jefe de Programación de la Producción el indicador de Venta Perdida periódicamente. (Cogorno, 2006) Matriz de responsabilidades – Estimado Ventas 31

Documento

Responsable de Generación

Frecuencia de Elaboración

Distribución

Fecha de Elaboración

Fecha de Distribución

Vigencia

Responsable de Archivo

Proyección anual de ventas

Jefe de Administración Ventas

Anual

Jefe de Planta

N/A

N/A

N/A

Jefe de Planta

Proyección de ventas de los siguientes tres meses

Jefe de Administración Ventas

Trimestral

Jefe de Planta, Jefe de PCP

N/A

N/A

N/A

Jefe de PCP

Proyección semanal de ventas del siguiente mes

Jefe de Administración Ventas

Mensual

Jefe de Planta , Jefe de PCP

N/A

N/A

N/A

Jefe de PCP

Indicador de Dias de Inventario

Asistente de PCP

Semanal/diario

Jefe de planta

N/A

N/A

N/A

Asistente de PCP

Reporte de Causas de desviación

Asistente de PCP

Cada Turno

Asistente de PCP

N/A

N/A

N/A

Asistente de PCP

Requerimiento semanal de despacho

Asistente de PCP

Cada turno

Asistente de PCP

N/A

N/A

N/A

Asistente de PCP

Tabla 12: Matriz de responsabilidades – estimado Ventas. (Fuente: Cogorno, 2006.)

División planta fideos sistema de planeación de mantenimiento 1. Enviar Plan Anual de Mantenimiento: El Jefe de Mantenimiento debe enviar el plan anual de mantenimiento al Jefe de Programación de Producción, al Jefe de Logística y al Jefe de Planta con el fin de informar los requerimientos de disposición de equipos y líneas de producción. De esta manera se pueden prever los repuestos y la planeación de producción de manera integral asegurando la disponibilidad de líneas para los meses picos de producción.

2. Enviar Programa de Mantenimiento Mensual/Semanal: La segunda semana de cada mes el Jefe de Mantenimiento debe enviar el programa de mantenimiento tanto preventivo como 32

correctivo, que requiera paro de línea para que sea considerado en la programación de la producción. El programa de mantenimiento con requerimiento de paro de equipos o líneas de producción debe estar disgregado de forma semanal indicando el tiempo que se requiere de la

disposición

de

estos

equipos

o

líneas.

El

programa

mensual/semanal debe ser distribuido al Jefe de Programación de Producción, al Jefe de Logística y al Jefe de Planta. 3. Revisar Diariamente Stocks APT: El Jefe de Programación de Producción realiza una revisión diaria de los Stock en el almacén de producto terminado para verificar que las entregas vayan de acuerdo al plan de producción y de acuerdo a los alcances de almacén según los días establecidos para ello. 4. Evaluar Requerimiento Semanal de Despacho: El Jefe de Programación de la Producción evalúa el requerimiento de despacho considerando los requerimientos de mantenimiento, los tiempos de producción, cantidades a producir y en especial, el indicador de días de inventario. 5. Elaborar Programa de Producción Semanal: El Jefe de Programación de la Producción realiza el programa de producción de la semana siguiente a más tardar el sábado a las 3 p.m. con carácter de programa preliminar. Este programa debe tener el detalle de programación de todos los días de la semana. El programa queda como oficial una vez que se ha definido el lunes a las 11 am considerando las observaciones de las diferentes áreas. Se entrega a Jefaturas de Planta, Control de Calidad, Logística y Mantenimiento. 6. Entregar Programa a Jefaturas:

33

El Jefe de Programación de Producción entrega los programas de producción con detalle diario a las diferentes áreas para asegurar que éstas estén informadas con anticipación de las cantidades y tipos de productos a producir, planeando también con anticipación el retiro de insumos para la producción. 7. Preparar y Enviar Proyección de trigo a Liberar y transportar: El Jefe de Programación de la Producción debe enviar la proyección quincenal de consumos de trigos

los días lunes al área de

compras/liberaciones para asegurar las existencias en planta a tiempo. Además de hacer las coordinaciones de traslado y movimientos de trigo. 8. Asegurar la provisión de insumos para producción: El Jefe de Distribución debe enviar al Jefe de Logística el requerimiento semanal de despacho para prever el aseguramiento de los insumos necesarios para la producción. Asimismo, el Jefe de Mantenimiento deberá enviar a logística el plan de mantenimiento mensual/semanal para asegura la compra a tiempo de los repuestos necesarios. 9. Participar en Reunión Semanal de Programación de Producción: Semanalmente deberán participar en la reunión de programación de la producción el Jefe Programación de Producción, el Jefe de Control de Calidad, el Jefe de Administración de Ventas, el Jefe de Distribución, el Jefe de Logística y el Jefe de Planta. En la reunión se deben planear las acciones para asegurar la producción de la siguiente semana, asegurar la de la semana actual así como la evaluación de la eficiencia de la programación de la semana anterior. Esta reunión de Programación está regida por una agenda definida y representa el canal oficial para la toma de decisiones en cuanto a la producción de los 3 Molinos. 34

10. Revisar Indicadores y Reportes: En las reuniones de programación de producción se deben revisar los indicadores de cumplimiento al programa de producción. Se deben revisar los compromisos acordados y documentados en la minuta semanal. La reunión tiene formalidad semanal y con una duración mínima de una hora. Adicionalmente a esta reunión semanal debe realizarse una reunión diaria entre el Jefe de Programación de Producción y el Jefe de Distribución para dar seguimiento al requerimiento y a la entrega de producto terminado. (Cogorno, 2006)

Matriz de responsabilidades - Sistema de planeación de mantenimiento Documento

Responsable de Generación

Frecuencia de Elaboración

Distribución

Fecha de Elaboración

Fecha de Distribución

Vigencia

Responsable de Archivo

Informe Semanal de Supervisión

Supervisor de Mantenimiento

Semanal

Supervisor de mantenimiento

Sábados

Lunes

N/A

Supervisor de Mantenimiento

Plan de Mantenimiento

Jefe de Mantenimiento

Anual/ Mensual/ Semanal

Jefe de Mantenimiento

Primera Quincena de Diciembre

Primera Quincena de Enero

N/A

Jefe de Mantenimiento

35

Indicadores de Mantenimiento

Jefe de Mantenimiento

Semanal/ Diario

Jefe de Planta

Inicio del Mes

Reunión de Directorio

N/A

Jefe de Mantenimiento

Vale de Suministros

Supervisor de Mantenimiento

Cada turno

Jefe de Mantenimiento

N/A

N/A

N/A

Supervisor de Mantenimiento

Reporte de Causas de Desviación

Supervisor de Mantenimiento

Cada Turno

Jefe de Mantenimiento

N/A

N/A

N/A

Supervisor de Mantenimiento

Solicitud de Horas Extras

Supervisor de Mantenimiento

Cada turno

Jefe de Mantenimiento

N/A

N/A

N/A

Supervisor de Mantenimiento

Reporte de Inasistencias

Supervisor de Mantenimiento

Cada turno

Jefe de Mantenimiento, Jefe de PCP

N/A

N/A

N/A

Supervisor de Mantenimiento

Órdenes de Trabajo

Supervisores de Mantenimiento

Diario

Supervisor de Mantenimiento

N/A

N/A

N/A

Supervisor de Mantenimiento

Tabla 13: Matriz de responsabilidades – planeación mantenimiento. (Fuente: Cogorno, 2006.)

B. Familia Alimentos Balanceados: A continuación, se describirá los procedimientos competentes a la planificación de la producción de planta fideos. División planta balanceados sistema programación de la producción. 1. Enviar Programa de Mantenimiento Mensual/Semanal: La segunda semana de cada mes el Jefe de Mantenimiento debe enviar el programa de mantenimiento tanto preventivo como correctivo que requiera paro de línea para que sea considerado en la programación de la producción. El programa de mantenimiento con requerimiento de paro de equipos o líneas de producción debe estar disgregado de forma semanal indicando el tiempo que se requiere de la

disposición

de

estos

equipos

o

líneas.

El

programa

mensual/semanal debe ser distribuido al Jefe de Programación de Producción, al jefe de Logística y al Jefe de Planta. 2. Revisar Diariamente Stocks APT: 36

El Jefe de Programación de Producción realiza una revisión diaria de los Stock en el almacén de producto terminado para verificar que las entregas vayan de acuerdo al plan de producción y de acuerdo a los alcances de almacén según los días establecidos para ello. 3. Evaluar Requerimiento Semanal de Despacho: El Jefe de Programación de la Producción evalúa el requerimiento de despacho considerando los requerimientos de mantenimiento, los tiempos de producción, cantidades a producir y sobretodo el indicador de días de inventario. 4. Elaborar Programa de Producción Semanal: El Jefe de Programación de la Producción realiza el programa de producción de la semana siguiente a más tardar el sábado a las 3 p.m. con carácter de programa preliminar. Este programa debe tener el detalle de programación de todos los días de la semana. El programa queda como oficial una vez que se ha definido el lunes a las 11 am considerando las observaciones de las diferentes áreas y es distribuido a los responsables de Empacado y de Fabricación. 5. Entregar Programa a Fabricación y Empaque y Control de Calidad: El Jefe de Programación de Producción entrega los programas de producción con detalle diario, el mismo que es ratificado por Asistente y Jefe de Planta;

y se comunica

a las diferentes áreas de

embolsado, control de calidad y fabricación para asegurar que éstas áreas están informadas con anticipación de las cantidades y tipos de productos a producir, planeando también con anticipación el retiro de insumos para la producción. 6. Preparar y Enviar Proyección de consumo quincenal de harinas Subproducto al Molino Callao:

37

El Jefe de Programación de la Producción Asistente de Planta debe enviar la proyección semanal quincenal de consumos de harinas los días lunes al Molino Callao para asegurar la existencias de harinas en planta a tiempo. 7. Asegurar la provisión de insumos para producción: El Jefe de Distribución Asistente de planta debe enviar al Jefe de Logística el requerimiento mensual semanal de despacho para prever el aseguramiento de los insumos necesarios para la producción. Así mismo el jefe de Mantenimiento deberá enviar a logística el plan de mantenimiento mensual/semanal para asegura la compra a tiempo de los repuestos necesarios. 8. Participar en Reunión Semanal de Programación de Producción: Semanalmente deberán participar en la reunión de programación de la producción el Jefe Programación de Producción, el Jefe de Control de Calidad, el Jefe de Administración de Ventas, el Jefe de Distribución, (vía telefónica ó correo)

el Jefe de Logística,

Facturador/despachador, Asistente y el Jefe de Planta. En la reunión se deben planear las acciones para asegurar la producción de la siguiente semana, asegurar la de la semana actual así como la evaluación de la eficiencia de la programación de la semana anterior. Esta reunión de Programación está regida por una agenda definida y representa el canal oficial para la toma de decisiones en cuanto a la producción de las diferentes líneas. 9. Revisar Indicadores y Reportes: En las reuniones de programación de producción se deben revisar los indicadores de cumplimiento al programa de producción. Se deben revisar los compromisos acordados y documentados en la minuta semanal. La reunión tiene formalidad semanal y con una duración 38

mínima de una hora. Adicionalmente a esta reunión semanal debe realizarse una reunión diaria entre el Jefe de Programación de Producción y el Jefe de Distribución para dar seguimiento al requerimiento y a la entrega de producto terminado. (Cogorno, 2006)

División planta balanceados sistema de programación de la producción matriz de responsabilidades Documento

Responsable de Generación

Frecuencia de Elaboración

Distribución

Fecha de Elaboración

Fecha de Distribución

Vigencia

Responsable de Archivo

Programación de la Producción

Jefe de PCP

Quincenal

Jefe de Planta, Responsable de Planta, Jefe de mantenimiento.

N/A

N/A

N/A

Jefe de PCP

Proyección del consumo de insumos y materias Primas y pedido

Jefe de PCP

Semanal

Jefe de Planta, Jefe de PCP

Los lunes

Todos los lunes

N/A

Jefe de PCP

Ingreso de datos de producción al sistema

Asistente de PCP

Diario

Jefe de PCP

N/A

N/A

N/A

Jefe de PCP

Indicador de PCP

Jefe de PCP

Semanal/diario

Jefe de planta

N/A

N/A

N/A

Jefe de PCP

Reporte de Causas de desviación

Asistente de PCP

Cada Turno

Responsable de Planta

N/A

N/A

N/A

Jefe de PCP

Vale de suministros

Asistente de PCP

Cada turno

Responsable de Planta

N/A

N/A

N/A

Jefe de PCP

Tabla 14: Matriz de responsabilidades – planta balanceados.

(Fuente: Cogorno, 2006.) C. Familia Harinas A continuación, se describirá los procedimientos competentes a la planificación de la producción planta harinas. División planta molino-callao sistema de planeación de la producción 1. Enviar Proyección Anual de Ventas:

39

El Jefe de Administración de Ventas debe enviar en la segunda semana de Diciembre la proyección anual de ventas del siguiente año al Jefe de Programación de la Producción, al Jefe de Logística, al Jefe de Distribución y al Jefe de Planta. La proyección debe estar especificada por tipo de producto mes a mes, esto con el fin de planear los meses picos de producción y los mantenimientos integrales. 2. Enviar Proyección de Ventas de los siguientes 3 Meses. Última semana de cada Mes: Cada mes en la última semana del mismo, el Jefe de Administración de Ventas deberá enviar la proyección de los siguientes 3 meses al Jefe de Programación de la Producción, al Jefe de Logística, al Jefe de Distribución y al Jefe de Planta, esto con el fin de ajustar la proyección anual de ventas y anticipar posibles reprogramaciones de los meses picos de producción y mantenimientos integrales. 3. Enviar Proyección Semanal de Ventas del siguiente Mes: La última semana de cada mes el Jefe de Administración de Ventas debe enviar la proyección de ventas del siguiente mes disgregada en las semanas que correspondan a ese mes. Así un mes de cuatro semanas tendrá la proyección de cada semana. La proyección debe ser distribuida al Jefe de Programación de la Producción, al Jefe de logística, al Jefe de Distribución y al Jefe de Planta. 4. Revisar Semanalmente Stocks APT: El Jefe de Distribución revisa semanalmente los Stocks de producto terminado para verificar las existencias y los alcances en días, esta revisión desde el punto de vista producción debe realizarse cada viernes para prever ruptura de Stocks. 5. Revisar Diariamente Stocks APT: 40

El Jefe de Distribución debe estar informado de los Stock diarios de producto terminado de acuerdo a los despachos

e ingresos al

almacén de producto terminado, esto con el fin de determinar posibles faltas de producto y realizar a tiempo los requerimientos a producción. 6. Revisar el indicador de Días de Inventario: El Jefe de Distribución antes de emitir el requerimiento semanal de despacho debe revisar el indicador de días de inventario, esto con la finalidad de ajustar el requerimiento y evitar sobre stocks. 7. Enviar el Requerimiento Semanal de Despacho con proyección quincenal: El Jefe de Distribución debe entregar como máximo a las 5 p.m. los días viernes por mail el requerimiento semanal de despacho de las siguientes dos semanas, siendo la primera semana un requerimiento oficial y la segunda semana una proyección tentativa que será oficializada al siguiente viernes. El requerimiento debe ser enviado al Jefe de Administración de Ventas, al Jefe de Planta y al Jefe de Programación de Producción. 8. Enviar el Indicador de Venta Perdida: El Jefe de Distribución envía al Jefe de Programación de la Producción el indicador de Venta Perdida periódicamente. (Cogorno, 2006) Matriz de responsabilidades división planta molino-callao Documento

Responsable de Generación

Frecuencia de Elaboración

Distribución

Fecha de Elaboración

Fecha de Distribución

Vigencia

Responsable de Archivo

Programación de la Producción

Jefe de PCP

Quincenal

Jefe de Planta, Jefe de Control de calidad, Jefe de turno, Jefe de Mantenimiento, Jefe de logística, Jefe de APT, Jefe de distribución.

N/A

N/A

N/A

Asistente de PCP

41

Proyección del consumo de harinas y pedido

Jefe de PCP

Semanal

Jefe de Planta, Jefe de Distribución

Los lunes

Todos los lunes

N/A

Asistente de PCP

Ingreso de datos de producción al sistema

Asistente de PCP

Diario

Jefe de PCP

N/A

N/A

N/A

Asistente de PCP

Indicador de PCP

Jefe de PCP

Semanal / diario

Jefe de planta

N/A

N/A

N/A

Asistente de PCP

Reporte de Causas de desviación

Asistente de PCP

Cada Turno

Jefe de Turno

N/A

N/A

N/A

Asistente de PCP

Vale de suministros

Asistente de PCP

Cada turno

Jefes de área

N/A

N/A

N/A

Asistente de PCP

Tabla 15: Matriz de responsabilidades – molino callao.

(Fuente: Cogorno, 2006.) Conclusiones • Primero, con la implementación del sistema Web se desea producir de acuerdo a la demanda del mercado. • Segundo, con la implementación del sistema Web se desea sentar un mejor flujo de comunicación y coordinación entre los responsables de la cadena productiva. • Tercero, automatizar gran parte de los procesos de la planificación de la producción e integrar los datos que actualmente están en Excel hacia el SGBD DB2.

42

CAPÍTULO II – MARCO TEÓRICO 2.1. Definiciones del Negocio 2.1.1. Planificación de la Producción Según Anaya Tejero, expone que partiendo de la premisa de que PRODUCCIÓN es todo aquel proceso que mediante el uso de tecnología se logra transformar recursos en bienes y servicios, entonces se define que la producción en términos industriales es todo aquel proceso que en base a recursos inventariables y no inventariables son transformados en base a procesos tecnológicos en recursos tangibles. (Anaya Tejero, 2011)

Según Chapman indica que planificar, en casi todo ámbito está orientado a satisfacer la demanda real del mercado. Cabe resaltar que en la mayoría de casos la producción suele ser mayor a la demanda real, para evitar ello se deberá partir a partir de un estimado de ventas. (CHAPMAN, 2006)

La visión de fabricación bajo pedido de una PV&O Actualmente, en Cogorno S.A. la fabricación se realiza bajo demanda de planificado de ventas, esto quiere decir lo siguiente: “Cuando el producto es de fabricación bajo pedido, por lo general no existe inventario de bienes terminados. Se levanta el pedido y a continuación se inicia la producción para satisfacerlo. Al conjunto de pedidos que está en espera de producción suele denominársele cartera de pedidos”. La salvedad del caso es que en Cogorno si existe un inventario de bienes terminados. (CHAPMAN, 2006)

43

A continuación, en la figura 11 se aprecia como la producción está enfocada a las ventas. Cabe resaltar que en la figura también hay desviaciones en la producción.

Figura 11: Tabla de producción. (Fuente: Chapman, 2006.)

Ahora bien, en la actualidad, para planificar la producción, se toma como referencia las estimaciones del mercado nacional e internacional para proceder con la realización del programa, pero antes de ello, se pasa por un ciclo de análisis, el cual se menciona a continuación:

1) Al momento de programar se deberá considerar los días inoperativos de las maquinas, es decir, en esos días se pueden hacer controles de calidad o de mantenimiento, por lo que las maquinas están reservadas para otro fin.

2) Al momento de programar se analiza los insumos y recursos inventariables con los que se cuenta en stock.

3) Al momento de programar se deberá analizar la capacidad productiva de molde por línea de producción para un artículo específico.

44

2.1.2. Aprobación del Programa Una vez publicado el programa de la producción este pasa por un proceso de evaluación por

todas las partes competentes hacia la

división (familia) afectada. Cada responsable analiza el programa y da su visto bueno para generar la orden de producción.

2.1.3. Replanteamiento del Programa Una vez puesto en producción el programa este puede ser susceptible a alteraciones debido a paradas no programadas, por ejemplo, la avería de una línea de producción, el desperfecto de un molde o la falta de bobina para el enrollado de algún producto debido, puede darse el caso, por una mala gestión de comunicación con el responsable del área de almacenes, en algunos casos, pese a haber aprobado el programa en primera instancia.

Conclusión Las actividades se mencionan en la tabla 1 (ver figura 4) serán remplazadas por actividades automatizadas a través de un sistema web, el cual permita una comunicación fluida con los responsables de cada división de producción. Además, los rendimientos de cada línea productiva serán obtenidos de manera automática para una programación de la producción más eficiente. Como se observa es de suma importancia que dicho programa cuente ya con los controles de calidad y mantenimiento programados, de ese modo el planeador tendrá los días productivos de cada línea definidos.

2.2. Introducción a las Tecnologías Básicas

45

Hoy en día todas las aplicaciones Web se basan en el protocolo HTTP el cual junto al protocolo TCP/IP se encarga de establecer comunicación entre el cliente Web a través de cualquier browser

(IE9, opera, Firefox, Chrome,

Safari, etc.) y el servidor Web.

Figura 12: Ubicación de los protocolos HTTP y TCP/IP en el diagrama de Red. (Elaboración: Propia, 2013.)

Actualmente, en el mercado de Software existen diversas plataformas para desarrollar aplicaciones Web, entre otras tecnologías. A continuación, se describirán las más importantes:

2.2.1. Plataforma Microsoft .Net La plataforma de desarrollo que auspicia Microsoft es Visual Studio .Net la cual está orientada a desarrollar aplicaciones de escritorio y móviles, sitios, aplicaciones Web, hasta sistemas operativos. (Microsoft, 2013)

Visual Studio.Net 2010 ofrece las siguientes posibilidades: • Diseñar aplicaciones distribuidas. 46

• Administrar soluciones, proyectos y archivos. • Trabajar con código, HTML y archivos de recursos. • Conectarse a recursos remotos con el Explorador de servidores. • Generar, depurar y probar. • Implementar aplicaciones y componentes. • Manipular el entorno de desarrollo.

2.2.1.1. ASP.NET Cojoc afirma que “ASP.NET es una parte de Microsoft. NET Framework, por lo que tiene todas las ventajas de los objetos orientados a capacidades del marco de programación. Las páginas web creadas con ASP.NET son básicamente objetos que tienen comportamientos (los eventos dentro de la página)”. (Cojoc, 2013)

2.2.1.2. Componentes del Visual Studio 2010 Según Microsoft, afirma que: “.NET Framework es un entorno de ejecución administrado que proporciona diversos servicios a las aplicaciones en ejecución. Consta de dos componentes principales: Common Language Runtime (CLR), que es el motor de ejecución que controla las aplicaciones en ejecución; y la biblioteca de clases de .NET Framework, que proporciona una biblioteca de código probado y reutilizable al que pueden llamar los desarrolladores desde sus propias aplicaciones. Los servicios que ofrece .NET Framework a las aplicaciones en ejecución son los siguientes”: (Microsoft, 2013) a) Common Language Runtime (CLR) Gestiona el código en tiempo de ejecución y provee los servicios básicos, como 47

administración de memoria, control de excepciones y control de hilos de ejecución.

b) Base

Class

Library

Contiene

la

mayor

cantidad

de

funcionalidades el desarrollo de cualquier tipo de Software. Encapsula los tipos básicos, clases para la entrada/salida, seguridad, colecciones de datos, entre muchas cosas más.

Figura 13: Arquitectura del Framework 4.0. (Fuente: Microsoft C. , 2013.)

2.2.2. JSP - Java Sun Java Server Page es una tecnología orientada al desarrollo de páginas Web, tanto estáticas como dinámicas

y para ello hace uso de

programación java. Cabe resaltar que JSP es multiplataforma, es decir, se puede ejecutar en cualquier servidor Microsoft o Linux. Así mismo, JSP es la combinación de HTML con XML en la cual se incrustan

48

etiquetas especiales para colocar código java (java mediante Scripts) y también se pueden usar librerías de terceros.

2.2.2.1. Servlet “Un servlet es una clase de lenguaje de programación Java que se utiliza para ampliar las capacidades de los servidores que alojan aplicaciones accesibles a través de un modelo de programación de petición-respuesta. Aunque servlets pueden responder a cualquier tipo de solicitud, que se utilizan comúnmente para extender las aplicaciones alojadas en servidores web. Para tales aplicaciones, la tecnología Java Servlet HTTP define clases específicas de servlets”.

Según Affiliates, afirma que: “Los paquetes javax.servlet y javax.servlet.http proporcionar interfaces y clases para escribir servlets. Todos los servlets debe implementar la interfaz Servlet, que define los métodos de ciclo de vida. Al implementar un servicio genérico, puede utilizar o extender la clase GenericServlet siempre con la API Java Servlet. La clase HttpServlet proporciona métodos, tales como doGet y doPost, para el manejo de servicios específicos de HTTP”. (affiliates, 2010)

2.2.2.2. Arquitectura MVC La arquitectura más usual usando estás dos tecnologías (JSP y Servlets) es MVC. A continuación una muestra de la arquitectura MVC. 49

Figura 14: Arquitectura MVC. (Elaboración: Propia, 2013.)

Nota: La forma más usual y correcta de usar JSP con servlets es empleando la arquitectura MVC.

Conclusión De las dos plataformas de desarrollo mencionadas la que usará para el 50

desarrollo del sistema Web será la de Visual Studio.net 2010 por los siguientes motivos: •

Política de la empresa.



Integración de todos los sistemas Web en una sola plataforma la cual es .NET.



Actualmente, se cuenta con las licencias respectivas de Visual Studio.NET.

Nota: lo mencionado anteriormente no quiere decir el uso tecnología Java no aplica para el desarrollo del proyecto. Tanto java como .NET son buenos entornos de desarrollo para proyectos de sistemas Web.

2.2.3. JavaScript JavaScript es propiamente un lenguaje de programación que se ejecuta en el lado del cliente, es decir no necesita compilarse en el lado del servidor (consumo de recursos). Java Script es creado a raíz de la necesidad de que el usuario interactué de manera más fluida con las aplicaciones Web. Con Java Script se puede crear las siguientes funcionalidades: (propia, 2013) •

Contadores de visita.



Efectos visuales.



Validaciones en los formularios.



Calculadoras.



Eventos que son realizados por el usuario.



Operaciones matemáticas.



Comportamientos personalizados de los controles.

51

A Continuación, un ejemplo del uso de JavaScript en una página HTML básica.

Figura 15: Código Java Script. (Elaboración: Propia, 2013.)

Nota: Cabe resaltar que todo código Java Script deberá estar enmarcado por la etiqueta .

En el ejemplo, se puede apreciar que en el evento onClick se hace el llamado a la función EsMayorEdad(), la cual se encarga de determinar, en base a la edad ingresada por el usuario, si la persona registrada es menor o mayor de edad.

Funciones Básicas: 52



document.getElementById(id): obtiene el objeto a partir del id.



elemento.getElementsByTagName(name): obtiene los elementos a raíz del nombre de un objeto, por el ejemplo el tag tr de una tabla HTML.



string.split(caracter): divide una cadena según el caracterer pasado por parámetro.



elemento.focus: sitúa el foco en el elemento indicado.



document.createElement(tag). Crea un elemento



elemento.removeChild: remueve un elemento.



Alert(mensaje): envía un mensaje de alerta.

Por último, es importante mencionar que JavaScript soporta funciones iterativas y condicionales (for, while do, do while, if then, foreach).

2.2.4. Lenguajes de Marcada HTML XML Según la W3C, afirma que el estándar desarrollado por la World Wide Web se basa en crear etiquetas para definir la estructura de textos. Cabe resaltar que los lenguajes de marcado no tienen las mismas cualidades que los lenguajes de programación, es decir, realizar operaciones aritméticas o fungir como variables para cualquier tipo de operación. (W3C, 2012)

2.2.2.3. HTML La totalidad de codificación de una página web está desarrollada en HTML. Gracias a las etiquetas se pueden definir

estructuras como tablas, etiquetas DIVs, párrafos,

saltos de línea, entre más características. Para ver la estructura de una página Web ver la Figura 8.

53

2.2.2.4. XML El lenguaje de marcas XML nace con la finalidad de sentar un estándar para el intercambio de información estructura entre distintas plataformas, un claro ejemplo, es en el empleo de las WebServices debido a que está tecnología usa el formato XML para procesar la información.

Ventajas de las aplicaciones WEB •

No necesita instalación alguna en la PC cliente debido a que su ejecución es a través de un navegador web.



Puede ser ejecutado desde cualquier región del Perú (o del mundo), si necesidad de estar conectados a la red de la empresa.



El despliegue de las actualizaciones es inmediata y recae sobre todos al mismo tiempo.



Es multiplataforma debido a que puede ser ejecutado desde cualquier sistema operativo.



Hay un consumo de recursos más óptimo, debido a que las transacciones se pueden ejecutar en el lado del cliente usando tecnologías con AJAX.

Desventajas de las aplicaciones WEB •

La disponibilidad depende de la conexión a internet tanto en el cliente como en el servidor.



Actualmente, se cuenta con respaldos de Back Up de internet .



En el caso que se ejecuten fuera de la red de la empresa, muchas veces es necesario instruir al usuario para que actualice alguna opción del navegador y la web funcione correctamente, por ejemplo, permitir ejecuciones de JavaScript. 54



Al usar la red de internet se es susceptible en cuanto a seguridad nos referimos.



Robo de información.



Alteración de la información.



Saturación adrede por parte de usuarios maliciosos, apoyados por herramientas informáticas.

55

CAPÍTULO III – ESTADO DEL ARTE

3.1. ERP Implementation for Production Planning at EA Cakes Ltd. Según Victor Portougal, autor de la presente publicación y profesor asociado al Departamento de Sistemas de Información y Gestión de Operaciones, en la Escuela de Negocios de la Universidad de Auckland en Nueva Zelandia, nos describe de una manera detallada la puesta en funcionamiento del sistema (SAP) y su módulo de planificación de producción de productos para la empresa EA Cakes Ltd. Ésta es una prospera compañía dedicada a la fabricación de comida rápida que comparte el mercado de Nueva Zelandia y la región de Asia- Pacífico y la cual produce más de 400 clases de diferentes productos de comida fresca y congelada. (Portougal, 2005) Portougal, expone que por muchos años la compañía EA Cakes Ltd

fue

desarrollando una marca de gran prestigio y disfruto de un mercado estable, es así que su estrategia de producción dominante siempre fue MTO (Make-toOrder o Fabricar para la Orden). Fue así que clientes permanentes como supermercados, tiendas y restaurantes hicieron sus pedidos con entrega para la próxima semana o para intervalos más largos, entonces la compañía proveyó de un buen servicio al cliente en relación a la calidad y tiempo de entrega. (Portougal, 2005) Pero para fines de los 90s, EA Cakes Ltd. disminuyo su participación en muchos de los mercados tradicionales ya que la principal razón fue el aumento de precios debido a los costes de producción altos de la compañía y por consiguiente las empresas competidoras brindaron precios inferiores sobre productos similares. La famosa marca de la compañía no atrajo suficientes clientes para apoyar los precios más altos.

56

Pronto la compañía fue forzada a reconsiderar su estrategia de ventas y producción, por lo que es aquí en donde se origino una disyuntiva. Por un lado su equipo de especialistas de TI estaba seguro de que el software SAP existente podía proveer el soporte suficiente al proceso de planificación de la producción de la empresa y por otro lado el personal del proceso mencionado tenía dudas acerca de los módulos preestablecidos de SAP. Ante la incertidumbre de que si ¿un sistema de software estándar como SAP pueda dar el soporte informático suficiente al diseño de un sistema de la empresa desarrollado por separado?, la dirección de la empresa invito a una compañía consultora la cual sugirió diseñar rápidamente un sistema de prototipo desigual. (Portougal, 2005) El nuevo sistema de planificación de la producción constaría de tres niveles.

Aggregate Capacity Planning ACP

Master Production Scheduling M.P.s

Shop Floor Scheduling

Figura 16: Niveles de la planificación de la producción. (Fuente: Portougal, 2005.)

Aggregate Capacity Planning (ACP) 57

El presupuesto de las ventas no es solo un pronóstico simple de la cantidad de productos que podían ser vendidos en el futuro, también es una herramienta de dirección para el control del rendimiento de la compañía por parte del directorio, por lo que debe ser objetivo y definir claramente lo que podría ser vendido además de satisfacer los objetivos de negocio y financieros de la compañía. El presupuesto de ventas es una herramienta de dirección que hace uso el directorio para controlar el rendimiento de la compañía. El departamento de mercadotecnia provee otras contribuciones como el lanzamiento de nuevos productos y otras iniciativas de mercadotecnia.

Master Production Scheduling(M.P.s) Es la herramienta de directiva más importante para el director de operaciones de una compañía de MTS.

Las entradas principales de M.P.s son: •

Plan de capacidad total por el seguimiento dos meses,



Niveles de acción verdaderos, y



Pronóstico de demanda de corto plazo.

Otras funciones de este nivel son: 1. Guardar niveles de acción deseables. 2. Implementar un" principio de "Velocidad - para - mercado": reacción frente a los cambios importantes en la demanda del mercado rápidamente.

58

Shop Floor Scheduling Este nivel lleva a cabo la planificación verdadera durante la próxima semana (con una subdivisión diaria), especificado por líneas de producción y productos.

Las restricciones de planificación (para tantos hombres como la planificación de máquinas) han sido trabajadas como programas recomendados fijos para las proporciones diferentes del producto. (Portougal, 2005)

La planificación es llevada a cabo inicialmente al principio de la semana planeada (la carrera principal) en el orden que trabaja un programa semanal óptimo. Al final de cada día, cuando la realimentación sobre la producción verdadera se pone disponible, el procedimiento es la carrera para el resto del período de planificación (una carrera de control). Durante esta corrida el plan actualizado por los siguientes días, sujeto a las mismas restricciones de planificación, es producido.

Utilidad en la Tesis El autor nos da a conocer que debido a los problemas presentados por la empresa, y según el análisis realizado a estos, por parte de los especialistas de TI y el personal de planificación de la producción, se llegó a la conclusión de que implementar los módulos existentes en el software SAP y haciendo uso completo

sus funcionalidades a la vez de modificar los procesos de la

empresa, aunque corriendo algunos riesgos, resultaría más barato, en comparación a modificar a gran medida este software para que pueda cumplir

59

con los procesos de planificación de la empresa, además del costo por brindar soporte al software.

Master Production Scheduling(M.P.s): Se menciona que la producción obedece a una demanda de corto plazo. El proyecto de tesis, priorizará la programación de la producción

semanal y

mensual.

Shop Floor Scheduling: Menciona que la producción debe considerar restricciones de producción. El proyecto de tesis, considerará y tomará dicho punto como referencia para el desarrollo del sistema web, la cual tendrá una sección para considerar dichas restricciones.

3.2. Integration of production planning and scheduling using an expert system and a genetic algorithm Según A. Lawrynowicz, autor de la presente publicación, los enfoques tradicionales con respecto a los procesos de planificación y programación se dan de manera secuencial, donde el plan de proceso es determinado antes que la planificación verdadera sea llevada a cabo. Es por eso que los sistemas de planificación prácticos tienen que poder reaccionar frente a los eventos de tiempo real con un tiempo de respuesta aceptable y cambiar la programación apropiadamente. (Lawrynowicz, 2008)

Por lo tanto el autor nos propone una nueva metodología con la aplicación de la inteligencia artificial para soportar la planificación de la producción y la programación en la red de suministro. En donde el problema de planificación de la producción es solucionado primero y luego el problema de la programación es considerado con la restricción de la solución. 60

Se tiene en cuenta que los sistemas de planificación prácticos tienen que poder reaccionar frente a los eventos importantes de tiempo real, dentro de un lapso de respuesta aceptable y replantear la programación apropiadamente. En muchos procesos de producción, la información de tiempo real puede ser obtenida de computadoras de control de proceso y otros sistemas de observación.

El enfoque es implementado como una combinación del sistema experto y el algoritmo genético.

La pregunta respecto a cómo un programador de horarios debe responder a los cambios en un sistema dinámico en este ambiente es muy importante para muchas empresas. Entre la creación de programa y la ejecución, uno o algunas suposiciones podrían haber cambiado con respecto a, por ejemplo, la disponibilidad

de

máquina,

material

que

suministro

o

cambio

del

mantenimiento programan (Percy y Kobbacy2000).

Tradicionalmente

requerimientos

importantes

que

planean

(MRP),

planificación de recurso de fabricación (MRPII) y sistemas de planificación (ERP) de recurso de la empresa son usados por empresas grandes como la planificación de producción y las herramientas de planificación. Porque el implementar el coste de tal sistema es muy alto, muchas empresas pequeñas y medianas combinan esto con la otra planificación de producción y controlan conceptos, como la tecnología de producción justo a tiempo y optimizado. (Lawrynowicz, 2008)

Por lo tanto, la presente investigación se concentra en lo siguiente: (a)

Cómo hacer un plan de proceso flexible teniendo en cuenta el estado del área de trabajo y diseñar la información;

(b)

cómo hacer un programa eficiente teniendo en cuenta las situaciones 61

dinámicas del área de trabajo y la complejidad de las restricciones de recurso; (c)

cómo hacer un modelo integrado apropiado, que incluye las restricciones varias.

Utilidad en la Tesis La presente investigación que ha tenido como propósitos principales, mejorar la eficiencia de la planificación tradicional y controlar los métodos, demuestra cómo puede ser usada una técnica de inteligencia artificial para optimizar la fabricación, los planes de construcción y programación para diferentes objetivos como es minimizar el tiempo y maximizar la utilización. Por lo tanto se establece la generación de los planes de producción sobre la base de recursos internos disponibles subcontratando computadoras. Además, los métodos inteligentes propuestos pueden ser aplicados cuando hay una necesidad ara re-plantear o reprogramar. Es de conocimiento general que en una fábrica de la vida real ocurre a menudo la interrupción de la producción, por lo tanto en tal situación, el sistema experto y el algoritmo genérico ejecutan el re-planteado y reprograman muy rápidamente.

Con este enfoque, el problema de la planificación de producción es solucionado primero y luego el problema de planificación es considerado con la restricción de la solución. Como una desventaja se tiene que no ofrece la planificación de la reducción a corto plazo y la planificación para cubrir requisitos del mercado cambiando para que pueda utilizar la mejor capacidad disponible de sistemas de fabricación.

La propuesta de combinar del sistema experto y el algoritmo genético ha sido evaluada usando datos de fábricas legítimas.

62

Finalmente, se coincide en que todo plan de proceso productivo debe ser flexible, pero en el presente proyecto no se tomará como base un diseño de algoritmo genético, sino los cambios obedecerán a paradas no programadas. 3.3. Process and Quality Model for the Production Planning and Control Systems Según el Dr. Halim Kazan, del Instituto de Tecnología de Gebze, el Dr. Ahmet Ergülen, de la Universidad de Nigde, y el Dr. Haluk Tanriverdi de la Universidad de Sakarya, autores de la presente investigación, todos en Turquía, presentan en primera instancia una base para la tecnología del proceso y el sistema. Luego presentan el sistema de control y modelos de calidad para la planificación de la producción. (Kazan, Ergal, Alen, & Tanriverdi, 2006)

Descripción del problema Cada situación en un determinado escenario tienen que ser planeado cuidadosamente paso a paso a lo largo de la planificación de la producción y controlar el proceso de la investigación en la medición de la producción. Sin embargo en la presente investigación no se provee un modelo con enfoque en procedimientos para tasar, mejorar y controlar la calidad del proceso.

Esta investigación desarrolla un proceso y modelo (PQAM) de calidad que pueda ser usada para tasar el rendimiento de un sistema en la cadena de suministros y sub-sistemas para ayudar a identificar aéreas problemáticas.

El proceso y el modelo de calidad (PAQM) El modelo PAQM consta de quince módulos integrados. Los detalles y los pasos relacionados con el procedimiento de cada módulo son los siguientes. (Kazan, Ergal, Alen, & Tanriverdi, 2006) 63



Módulo A1. Su propósito es definir el proceso, la tecnología y el sistema que todos requerirán para las actividades.



Módulo A2. Su propósito es diseñar el sistema de & C de PP.



Módulo A3. Su propósito es implementar el proceso, la tecnología y sistema.



Módulo A4. Su propósito es dirigir la planificación de producción y controlar sistemas.



Módulo A5. Su propósito es mejorar el proceso, la planificación de producción y los sistemas de control.



Módulo A6. Su propósito es identificar la cantidad apropiada a lo largo del proceso en la producción.



Módulo A7. Su propósito es identificar el tiempo apropiado para el proceso, la planificación de producción y los sistemas de control.



Módulo A8. Su propósito es identificar el nivel apropiado de la cantidad en la línea de montaje y controlar sistemas.



Módulo B1. Su propósito es controlar el sistema y la calidad a lo largo de la planificación de producción y controlar el proceso.



Módulo B2. Su propósito es identificar requisitos del cliente (interno y externo), las expectativas y la impresión en orden de mejorar el rendimiento de servicio al cliente constantemente.



Módulo B3. Su propósito es establecer y refinar la definición de la calidad en la planificación de la producción y el sistema de control.



Módulo B4. Su propósito es identificar el coste actual, la productividad y las medidas del servicio e identificar brechas en 64

las mediciones actuales. •

Módulo B5. Su propósito es valorar el rendimiento actual y poner los padrones para la productividad del coste.



Módulo B6. Su propósito es identificar e implementar los cambios para mejorar el rendimiento de proceso de planificación de la producción en conjunto.



Módulo B7. Su propósito es controlar y monitorear el rendimiento de productividad y servicio para asegurar que el proceso cubra los padrones.

Planificación de Producción y Control En 1997 DeToro y Tenner provea un enfoque gradual para la mejora de proceso. Su modelo es sobre la base de los principios establecido por Crosby, Deming, Juran y Feigenbaum. Los pasos involucrados en su proceso de mejora ininterrumpido lo son: (Kazan, Ergal, Alen, & Tanriverdi, 2006)

1. Comprensión al cliente. Comprenda los requisitos del cliente final y valore la habilidad de la organización de cubrir estos requisitos.

2. Tasación de la eficiencia. Recoja los datos sobre medidas de proceso internas y determine si el proceso está cubriendo tales demandas como el coste, el tiempo del ciclo o la variabilidad.

3. Análisis del proceso. Determine la eficiencia y la eficacia del proceso, en este paso, la mejora apropiada de que la ruta debe ser identificado: la mejora ininterrumpida, benchmarking, o reingeniería. Si la mejora ininterrumpida es el sendero 65

apropiado entonces luego el paso cuatro es llevado a cabo.

4.

Mejora del proceso. El estudio del plan es usado como un enfoque para mejorar el proceso.

5.

Implementación de los cambios. Haga los ajustes necesarios.

6.

Normalización y monitoreo. Estar al día con el rendimiento, monitoreo del proceso y mejora continua.

Utilidad en la Tesis PAQM provee una metodología para implementar un programa de calidad o mejorar uno existente. Por lo tanto a través de esta serie de módulos, el modelo PAQM nos ofrece un método para la identificación del proceso, la medición y el control. Además es una metodología sistemática que prescribe: •

Los aspectos específicos de la calidad debe ser medida.



Un método para medir estos aspectos de la calidad.

• Un método para usar tales medidas en valorar, mejorar y controlar en conjunto el sistema de la cadena de suministro. Finalmente, para el presente caso no aplica el método PAQM, debido a que los procesos y forma de trabajo ya están establecidos.

66

3.4. Benchmarking (Análisis comparativo con otras soluciones). 3.4.1. Soluciones encontradas 3.5.1.1. Preactor 11 APS Desarrollador: Preactor Última versión: 11 Tipo de licencia: Comercial Costo: según funcionalidades. Plataforma: Microsoft Windows (todas las versiones) Preactor® es un software de origen Español, especializado en planificación y programación de la producción de bienes y servicios, que utiliza el concepto de secuenciación a capacidad finita. Los softwares de programación de la producción generados por Preactor® se basan en la disponibilidad efectiva de recursos productivos, la existencia de restricciones operacionales, las condiciones de demanda y las políticas de atención de la empresa. (Technologies, 2006)

Figura 17: Modelo de trabajo de software Preactor APS . (Fuente: SIMLog, 2013.)

67

EL Sistema APS Preactor se basa fundamentalmente en proponer un balance entre las proyecciones de ventas y la capacidad productiva instalada en planta para aumentar la productividad.

Utilidad en el proyecto El presente proyecto de tesis recoge la idea del software Preactor, es decir, que debe existir un balance entre el estimado de ventas y la capacidad productiva de planta. Además,

3.5.1.2. ERP Sistrade® Desarrollador: Sistrade Última versión: 11 Tipo de licencia: Comercial Costo: Por alojamiento en servidor. Plataforma: Web Internet Explorer V 8/9/10/11 SISTRADE - Software Consulting, S.A. es una empresa portuguesa especializada en el desarrollo de software y en la prestación de servicios de consultoría para diferentes sectores. El ERP Sistrade® es una solución de gestión empresarial desarrollada por SISTRADE orientada hacia la gestión de los procesos. Es una solución tecnológica que ofrece a las empresas de mediana y gran dimensión las funcionalidades básicas de presupuestos, gestión de Pedidos, compras, stocks, gestión de la producción, contabilidad, entre otras funcionalidades. Además ésta aplicación está orientada a un entorno web. (SISTRADE, 2012) 68

El sistema ERP Sistrade gestiona procesos financieros, inventarios, despachos, producción, etc. Para el análisis del sistema Web nos basaremos en el modulo de producción orientada a la planificación.

Gestión de la producción Sistrade permite una gestión de la producción gracias a que contempla los procesos de planificación, control y costes industriales cruzados con las informaciones adquiridas de los procesos de fábrica relacionados con la organización. (SISTRADE, 2012)

Figura 18: Planificación dinámica. (Fuente: SISTRADE, 2012)

Como principales características del modulo de producción se pueden resaltar las siguientes: •

Estructurar los métodos de producción.



Planificar y controlar las diversas fases de fabricación.



Seguimiento de los pedidos en producción, previsión de entrega y lanzamiento de los productos en Stock.



Ajuste de los costes de producción. 69



Análisis de eficiencias por Línea, Sección, Máquina y Empleado.



Reducción de costes de producción.



Análisis de los trabajos en curso.



Mantenimiento de la información.



Planificación de la producción.



Simulación de la Planificación de la producción.



Ejecución de la Producción.



Control de la Producción.



Análisis de la Producción – Consultas.



Costes de la Producción.



Presupuestos.



Actualización de Tiempos de Producción.



Especificaciones Generales.

Utilidad en el proyecto Sistrade

realiza

sus

programaciones

en

base

a

los

rendimientos de las líneas de producción. Para el presente proyecto de tesis se empleará este análisis previo para obtener un programa más ajustado a capacidad productiva de planta. Por otro lado, se coincide en que el proyecto de tesis sea desarrollado en Web debido a que se aprovechará la portabilidad para desplegarse en cualquier sistema operativo.

3.5.1.3. PlannerOne© Desarrollador: ORTEMS Última versión: 11 Tipo de licencia: Comercial Costo: por implementación. 70

Plataforma: Web Internet Explorer V 8/9/10/11 Depende: Microsoft Dynamics NAV 2009, Microsoft Dynamics NAV 2013 PlannerOne©es el resultado de años de investigación y constituye una revolución para la planificación y programación de la producción. En el marco del programa Europeo de investigación

EUREKA, ORTEMS

ha

desarrollado este

innovador componente, integrado vía Web Services, para maximizar el uso del módulo de producción de los ERP. Esta desarrollada como una aplicación Web (Microsoft ASP.NET) que permite una navegación dinámica entre el ERP y la misma aplicación. (ORTEMNS, 2012) Funcionalidades •

Planificación

a

capacidad

finita

con

restricciones

planificación multi-criterio sobre la base de criterios elementales adaptados a cada tipo de industria, que pueden ser combinados de forma ilimitada para crear criterios complejos y dar así respuesta a los objetivos y particularidades de la empresa. •

Optimización de los tiempos de cambio para gestionar correctamente los tiempos de cambio y reagrupamientos en campañas de producción.



Planning

gráfico

e

interactivo

con

sincronización

instantánea con las modificaciones realizadas en el ERP. PlannerOne

aplica

las

modificaciones

y

refleja

las

consecuencias instantáneamente, garantizando en todo momento que el planning sea realizable y de acuerdo con las restricciones de producción.

71



Marcadores

visuales

parametrizables

para

informar

gráficamente de un incidente específico sobre cualquier operación del planning y agilizar el proceso de resolución del problema. •

Análisis detallado del Planning visualización de la carga a capacidad finita o infinita para la detección de los cuellos de botella.



Contempla la disponibilidad de materias primeras para integrar con el cálculo de necesidades netas. (ORTEMNS, 2012)

Utilidad en el proyecto PlannerOne toma como criterio la reprogramación. En el presente proyecto de tesis se considerará está característica para el desarrollo de la tesis. Así mismo, se registrará en base de

datos

las

incidencias

que

dieron

pase

a

una

reprogramación, con la finalidad de evaluar y tomar medidas preventivas a futuro.

Cabe resaltar que la aplicación se

despliega en un entorno Web, la cual también será tomada por el presente proyecto de tesis.

72

3.4.2. Evaluación de las soluciones encontradas FUNCIONALIDADES

Preactor 11 APS

Aplicativo Web.

ERP Sistrade®

PlannerOne©

Sistema Web para el control y planificación de la Producción





~



Módulo de Planificación de Actividades 

Base de datos, menús y rutinas personalizables.

~

Tiempos de proceso por artículo, por hora y por lote.









Averías y mantenimiento preventivo, etc., manuales e interactivos.



~





Generador de informes.









Sistema de mensajería en tiempo real.

~



Cálculos y reprogramaciones durante la producción.

~







Planificación Remota Multiplanta.

~







Asistente de importación / exportación de ficheros.









Tiempos de proceso dependientes por centro de trabajo.

~



Seleccionar y arrastrar un artículo para asignarle un horario de producción.



Multiusuario.



Planificación multicriterio.













73

PUNTAJE TOTAL

35

48

48

65

Tabla 16: Cuadro comparativo de soluciones encontradas. (Elaboración: Propia, 2013.)

Leyenda: • El símbolo ( ), aporta un puntaje de 5. Significa que cumple con la función a cabalidad. • El símbolo

(~), aporta un puntaje de 3. Significa que no cumple

completamente con la función, o existe la posibilidad de integrarse en una versión superior no requerida.

Análisis: El de mayor puntaje es el Sistema Web para el control y planificación de la Producción porque cumple con los requerimientos de la empresa.

74

CAPÍTULO IV – MODELADO DEL NEGOCIO 4.1. Reglas de Negocio A continuación, se describirán las reglas de negocio. LISTA DE REGLAS DE NEGOCIO NRO

ROL

TAREA

HERRAMIENTA

1

Gerente Regional

Elaborar las estimaciones de ventas regionales.

Excel

2

Asistente de Ventas

Elaborar las estimaciones de ventas mensuales del mercado nacional.

Excel

3

Control de Calidad

Generar el plan de control de fumigaciones.

Excel

4

Supervisor Mantenimiento Molino

Generar plan de mantenimientos preventivos – molino.

Excel

5

Supervisor Mantenimiento Fábrica

Generar plan de mantenimientos preventivos – molino.

Excel

6

Jefe de Planeamiento

Generar los programas de producción.

Excel

7

Comité aprobador – Molino

Aprobar el programa para la producción de la siguiente semana.

Reunión presencial

8

Comité aprobador – Fábrica

Aprobar el programa para la producción de la siguiente semana.

Reunión presencial

9

Supervisar almacenes

Verificará y generar Órdenes de Compra de insumos.

Speed400

10

Proyectos – Exportación

Entregar reporte de ventas semanal exportación.

Excel

Reglas de Operación Simple 1

El programa de planta fideos se aprueba en comité todos los jueves.

2

El programa de Molino se aprueba en comité todos los martes.

3

Todos los programas son puestos en producción los días lunes.

4

Cuando ocurre una reprogramación se debe comentar a todos los involucrados del comité.

5

Toda insumo debe cumplir con los días de alcance establecidos. Tabla 17: Describe la lista de reglas del negocio. (Elaboración: Propia, 2013.)

75

4.2. Casos de Uso del Negocio 4.2.1. Relación de Casos de Uso del Negocio A continuación, los CUN’s más significativos:

Figura 19: Lista de Casos de Uso del Negocio. (Elaboración: Propia, 2013.)

4.2.2. Diagrama de Casos de Uso del Negocio A continuación, el diagrama de los CUNs por Actores de Negocio.

Figura 20: Diagrama de CUN´s por actores de negocio. (Elaboración: Propia, 2013.)

76

4.2.3. Especificaciones de Casos de Uso del Negocio A continuación las especificaciones de caso de uso del negocio.

5.3.3.1. ECUN Generar estimación de ventas mensual

Caso de Uso

Generar estimación de ventas mensual

Fuentes

Área de Ventas

Actor

Gerente regional

Descripción

En el presente CUN se describe la generación del estimado de ventas mensual.

Flujo básico

1. Generación de Estimado de Ventas a) El gerente regional solicita reporte de ventas semanal a los vendedores b) El vendedor entrega reporte de venta semanal. c) El gerente regional toma los datos de los reportes y obtiene una tendencia para las ventas del siguiente mes. d) Fin

Flujos alternos

No presenta.

Pre-condiciones

Reporte de ventas del vendedor

Post-condiciones

Reporte de estimación de ventas mensual

Reglas del Negocio

1

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

El reporte ventas que entrega el Gerente regional es enviada a lima para ser analizada por el área de ventas.

77

5.3.3.2. ECUN Generar estimación de ventas semanal

Caso de Uso

Generar estimación de ventas semanal

Fuentes

Área de Ventas

Actor

Asistente Ventas

Descripción

En el presente CUN se describe la generación del estimado de ventas semanal.

Flujo básico

1. Generación de Estimado de Ventas semanal a) El Asistente Ventas solicita reporte de ventas mensual enviado por los gerentes regionales. b) Los gerentes regionales entregan las estimaciones de venta mensual de sus regiones asignadas. c) El Asistente Ventas toma los datos de los reportes y obtiene una tendencia para las ventas de la siguiente semana. a) Fin

Flujos alternos

No presenta

Pre-condiciones

Reporte de ventas de los gerentes regionales.

Post-condiciones

No presenta

Reglas del Negocio

2

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

La estimación de ventas semanal se entregará al jefe de planeamiento para que realice el programa de la producción.

78

5.3.3.3. ECUN Generar plan de fumigaciones

Caso de Uso

Generar plan de fumigaciones

Fuentes

Área de Calidad

Actor

Jefe de Calidad

Descripción

En el presente CUN describe el plan de fumigaciones para las líneas de producción de cada división.

Flujo básico

Generación plan de fumigaciones a) El jefe de calidad agrupa de las líneas de producción de división. b) Si la división es Fideos se hace lo siguiente: ir al punto g c) Toma como referencia la fecha del último control d) Toma como referencia los puntos muertos de producción 15 días después de la elaboración del plan de fumigaciones. e) En dichos puntos se programa las fumigaciones. f)

Fin

g) Si la división es Harinas o alimentos balanceados se hace lo siguiente: ir al punto h h) Toma como referencia la fecha del último control (intervalo de tiempo bimestral) i)

Toma como referencia los puntos muertos de producción 15 días después de la elaboración del plan de fumigaciones.

j)

En dichos puntos se programa las fumigaciones. Fin.

Flujos alternos

Presencia de plagas a) Se para la producción b) Se procede con las fumigaciones c) Fin

Pre-condiciones

Reportes anteriores de plan de fumigaciones

Post-condiciones

No presenta

Reglas del Negocio

3

Puntos de inclusión

No presente

79

Puntos de extensión No presenta Notas

Los datos de los programas de fumigaciones se entregan al área de planeamiento para la elaboración del programa.

5.3.3.4. ECUN Generar controles preventivos

Caso de Uso

Generar controles preventivos

Fuentes

Área de mantenimiento

Actor

Super. Mant. Molino, Super. Mant. Fideos,

Descripción

En el presente CUN describe los controles preventivos de las líneas de producción de las divisiones de fideos, harinas y alimentos balanceados.

Flujo básico

1. Generación de plan de mantenimientos preventivos a) Si el control es en Fideos hacer lo siguiente: ir al paso b) b) El Supervisor de Mantenimiento elabora su plan cada mes c) Fin d) Si el control es en Harinas o Alimentos balanceados hacer lo siguiente: ir al paso e) e) El Supervisor de Mantenimiento elabora su plan cada 2 meses f)

Fin

Flujos alternos

No presenta

Pre-condiciones

No presenta

Post-condiciones

No presenta

Reglas del Negocio

4,5

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

El programa de controles preventivos se entregará al jefe de planeamiento para que realice el programa de la producción.

80

5.3.3.5. ECUN Generar estimación de ventas – exportación

Caso de Uso

Generar estimación de ventas – exportación

Fuentes

Area de Exportación

Actor

Jefe de Proyectos – Exportación

Descripción

En el presente CUN describe los controles preventivos de las líneas de producción de las divisiones de fideos, harinas y alimentos balanceados.

Flujo básico

1. Generación de reporte de exportación semanal a) El cliente envía su pedido vía correo electrónico, previa coordinación telefónica o presencial. b) El Jefe de Proyectos – exportación toma pedido. c) Elabora el reporte de ventas de exportación d) Fin

Flujos alternos

No presenta.

Pre-condiciones

Solicitud de compra por parte del cliente.

Post-condiciones

No presenta

Reglas del Negocio

10

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

El programa de ventas de exportación se entregará al jefe de planeamiento para que realice el programa de la producción.

81

5.3.3.6. ECUN Elaborar Programa Caso de Uso

Elaborar Programa

Fuentes

Area de Planeamiento

Actor

Jefe de Planeamiento

Descripción

En el presente CUN se describirá los pasos para elaborar el programa de la producción.

Flujo básico

1. Generación del programa a) El planeador recoge y analiza reporte de fumigaciones b) El planeador recoge y analiza reporte de Mantenimientos preventivos c) El planeador recoge y analiza reporte de estimación de ventas semanal d) El planeador recoge y analiza reporte de estimación de ventas – exportación e) El planeador, analiza los rendimientos de líneas de producción por producto a producir (moldes) f)

Analiza disponibilidad de recursos inventariadles (bobinas, papel tocuyo, etc.)

g) Analiza disponibilidad de insumos en almacén para la elaboración de los productos h) Procede con la elaboración del programa por división (familia de producción) i) Flujos alternos Pre-condiciones

Fin

No presenta. •

Generación de Estimado de Ventas semanal



Generación plan de fumigaciones



Generación de plan de mantenimientos preventivos



Generación de reporte de exportación semanal

82

Post-condiciones

No presenta

Reglas de Negocio.

6

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

El programa será enviado al comité para su aprobación.

5.3.3.7. ECUN Aprobar Programa

Caso de Uso

Aprobar Programa

Fuentes

Área de Planeamiento

Actor

Comité aprobador

Descripción

En el presente CUN se describirá los pasos para aprobar el programa de la producción.

Flujo básico

1. Generación del programa a) El comité recibe el programa b) Si aprueba es puesto en producción. Ir al paso d. c) Si no aprueba es devuelto al jefe de planeamiento para su corrección. Ir al paso d. d) Fin

Flujos alternos

No presenta. •

Pre-condiciones

Programa de la planificación de la producción.

Post-condiciones

No presenta

Reglas del Negocio

7,8

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

El programa de la producción es enviada a producción fideos, molino y alimentos balanceados para su puesta en producción.

83

5.3.3.8. ECUN Generar Órdenes de Compra

Caso de Uso

Generar Órdenes de Compra

Fuentes

Area de Planeamiento

Actor

Supervisor de Almacenes

Descripción

En el presente CUN se describirá los pasos generar una Orden de Compra.

Flujo básico

1. Generación de Orden de Compra a) En caso sea por Programa producción hacer lo siguiente: ir al paso b) b) El almacenero analiza los días de alcance cada insumo. c) El almacenero analiza los requisitos de insumos para la producción d) El almacenero analiza los requisitos de recursos inventaríales para la producción e) Finalmente, genera Orden de Compra de acuerdo a la necesidad del programa y a los días de alcance. f)

Fin

g) En caso sea por una avería en la línea de producción ir al paso h) h) Se avisa a las áreas competentes y solicita al jefe de planeamiento que ajuste su programa debido a una parada no programada. Flujos alternos

No presenta. •

Pre-condiciones

Programa de la producción

Post-condiciones

No presenta

Reglas del Negocio

9

84

Puntos de inclusión

No presente

Puntos de extensión No presenta Notas

4.3. Diagramas de Actividades del Negocio 4.3.1. Diagrama de Actividades del CUN Generación de Estimación de Ventas

Figura 21: Diagrama de actividades consolidado de generación de estimación de ventas. (Elaboración: Propia, 2013.)

85

4.3.2. Diagrama de Actividades del CUN Elaborar Programa

Figura 22: Diagrama de actividades consolidado de Elaborar Programa. (Elaboración: Propia, 2013.)

86

4.4. Diagrama de Clases de Objeto del Negocio A continuación, se muestra el diagrama de clases de objeto del negocio.

Figura 23: Diagrama de clases de objeto del negocio. (Elaboración: Propia, 2013.)

Conclusión

87

Las reglas negocios mencionadas son propias de la empresa. Por otro lado, en el presente proyecto de tesis no se va a alterar ningún proceso de negocio.

88

CAPÍTULO V– REQUERIMIENTOS DEL PROYECTO 5.1. Requerimientos del software 5.1.1. Relación de requerimientos A continuación, se listará los requerimientos del proyecto. Nro. Req.

Descripción

1

Permitir que se puedan registrar los programas de planificación de la producción.

2

Permitir que se puedan registrar los programas de controles de fumigación.

3

Permitir que se puedan registrar los mantenimientos preventivos.

4

Permitir que se puedan reutilizar los programas de producción.

5

Permitir que se pueda enviar vía correo electrónico a aprobación el programa a los responsables de la línea de negocio afectada.

6

Permitir que se puedan copiar semanas de planificación. Ejemplo, copiar la semana 18 a la 19.

7

Permitir que se puedan enviar alertas de escases de insumos.

8

Permitir que el programa sea susceptible a paradas no programadas.

9

Permitir visualizar en un reporte, las cantidades a producir, horas maquina programada y descripción del producto; agrupadas todas por líneas de producción.

10

Permitir ver el estado de aprobación del programa.

11

Permitir mover los programas hacia un histórico.

12

Permitir enviar un correo electrónico al momento de rechazar el programa por parte de algún integrante del comité especificando la causa del rechazo. Tabla 18: Lista de requerimientos del proyecto. (Elaboración: Propia, 2013.)

89

5.1.2. Especificación de requerimientos (funcionales y no funcionales) A continuación, se mencionará tanto los requerimientos funcionales como no funcionales. 6.2.2.1. Requerimientos Funcionales Requerimiento

Descripción

Registrar Programa

El usuario ingresará lo datos necesarios para registrar el programa de la producción.

Replantear programa

El usuario podrá replantear un programa debido a eventos aislados, como por ejemplo, una parada no programada (avería de maquina)

Mover versión

El usuario podrá mover una versión hacia un histórico

Consultar Históricos

El usuario podrá consultar programas.

Programar controles de calidad

El usuario podrá programar las fumigaciones de las distintas líneas de producción.

Programación de Mantenimientos Preventivos

El usuario podrá programar los mantenimientos preventivos de las distintas líneas de producción, por ejemplo, renovación de moldes para la línea p400.

Publicar Programa

El usuario al momento de terminar con la programación de la producción, dicho programa será enviado por el usuario a publicación para su aprobación por parte del comité

Generar Reporte de Programa

El usuario podrá generar el reporte del programa de la producción., en la cual, se mostrarán las cantidades de producción y horas maquina necesarias.

Tabla 19: Lista de requerimientos funcionales del proyecto. (Elaboración: Propia, 2013.)

90

6.2.2.2. Requerimientos No Funcionales Requerimiento

Descripción •

El sistema deberá soportar un aproximado de 20 Usuarios simultáneos.



El sistema deberá proveer un tiempo de acceso a los datos en menos de 20 segundos de empezado el acceso (sujeto a varianza del ancho de banda).



El consumo de recursos por parte del cliente no será mayor 100Mb de memoria RAM.



El sistema deberá completar el 100% de 1 transacción en menos de 1 minutos.



El usuario deberá ser capaz de utilizar cualquier función del sistema, utilizando solamente los elementos de ayuda del sistema (manual de usuario) entre 5 a 20 minutos dependiendo del grado de conocimiento del usuario.



Disponibilidad: El sistema de Planificación de la Producción se implantará para estar 99.9% operativo durante las 24 horas del día.



MTBF (Tiempo estimado entre fallas): El tiempo estimado entre fallas será no mayor a un 0.1% por usuario (mientras está utilizando el sistema).



MTTR (Tiempo estimado entre reparaciones) En caso de reparación por fallas el tiempo fluctuará entre una y seis horas, dependiendo de la magnitud de la falla.



La carga de las páginas en el navegador: menor a 15 segundos.



La utilización de recursos:

Funcional

Usabilidad

Fiabilidad

Rendimiento



o

Memoria RAM (en MB): mayor a 15Mb (depende carga).

o

Base de Datos: depende de la cantidad de transacciones (datos).

Restricción del entorno del sistema o

Restricciones de Diseño •



El Software será elaborado en el lenguaje de programación Asp.Net C# utilizando la herramienta Visual Studio .NET 2010, utilizará el administrador de base de datos DB2 AS400

Restricciones de Arquitectura o

Seguridad

y menor de 100Mb

El sistema deberá ser desarrollado en arquitectura de capas.

El sistema contará con claves de usuario encriptados, debido a que se usa el SGBD DB2 AS400. Además, se contará con la característica de caducidad de claves o intentos fallidos (tercer intento). Por último, la validación de usuario será a través del propio motor del AS400.

Tabla 20: Lista de requerimientos No funcionales del proyecto. (Elaboración: Propia, 2013.)

91

5.2. Casos de Uso del Sistema 5.2.1. Diagrama de Actores del sistema. A continuación, el diagrama de actores del sistema.

Figura 24: Diagrama de actores del sistema. (Elaboración: Propia, 2013.)

5.2.2. Diagrama de Paquetes A continuación, el diagrama de paquetes del sistema.

Figura 25: Diagrama de paquetes del sistema. (Elaboración: Propia, 2013.)

92

5.2.3. Casos de Uso del Sistema 6.3.3.1. Diagrama de Casos de Uso del Sistema A continuación, se muestra la figura 25 que contiene el diagrama general de CUS.

Figura 26: Diagrama General de Casos de Uso del Sistema. (Elaboración: Propia, 2013.)

93

6.3.3.2. Diagrama de CUS del Paquete Reportes

Figura 27: Diagrama CUS del paquete reportes. (Elaboración: Propia, 2013.)

6.3.3.3. Diagrama de CUS del Paquete Planear Producción

Figura 28: Diagrama CUS del paquete planear producción. (Elaboración: Propia, 2013.)

94

6.3.3.4. Diagrama de CUS del Paquete Control de Calidad

Figura 29: Diagrama CUS del paquete control de calidad. (Elaboración: Propia, 2013.)

6.3.3.5. Diagrama de CUS del Paquete Mantenimiento Planta

Figura 30: Diagrama CUS del paquete mantenimiento planta. (Elaboración: Propia, 2013.)

95

5.2.4. Matriz de CUN´s vs CUS’s A continuación, se muestra la matriz de requerimientos vs CUS.

96

Figura 31: Matriz de CUN’s vs CUS. (Elaboración: Propia, 2013.)

5.3. Modelo Conceptual del sistema 5.3.1. Diagrama del Modelo Conceptual A continuación, se muestra el diagrama del modelo conceptual.

Figura 32: Diagrama del modelo conceptual. (Elaboración: Propia, 2013.)

97

5.4. Prototipos de la Solución Interfaz Ingreso a la Aplicación Web

98

Interfaz borradores de programas creados

99

Interfaz publicar versión

Nota: La interfaz se superpone al menú principal.

100

Interfaz copiar versiones para trabajarlas en un programa nuevo

Nota: La interfaz se superpone al menú principal.

101

Interfaz Mover Versión hacia un histórico

Nota: La interfaz se superpone al menú principal.

102

Interfaz de registro del programa

103

Interfaz de registro del programa – se pueden trabajar hasta 4 semanas en una sola pantalla por línea de producción

104

Interfaz de registro del programa – la forma de agregar un artículo a producir será por medio de arrastre

105

Interfaz de registro del programa – una vez posicionado el artículo podemos correrlos a los demás días, gracias a la creación de controles personalizados

106

Interfaz de registro del programa – herramienta de correr artículos – menú contextual

Nota: La interfaz se superpone al menú principal.

107

Interfaz de registro del programa – resultado de correr los ítems 5 horas y media.

108

Interfaz de consolidado del programa por línea de producción.

109

Conclusiones • Se formularon los CUS de acuerdo a los requerimientos funcionales del negocio y con la cual se obtuvieron los parámetros necesarios para diseñar el prototipo de la solución web. • El sistema propuesto es único en comparación a otras soluciones encontradas, debido a que está diseñado a medida de los requerimientos del negocio.

110

CAPÍTULO VI – ARQUITECTURA

6.1. Realización de los casos de uso más significativos para la arquitectura 6.1.1. Diagrama de Casos de Uso más significativos para la arquitectura

Figura 33: Diagrama de CUS más significativos para la arquitectura. (Elaboración: Propia, 2013.)

111

6.1.2. Especificación de los Casos de Uso del Sistema 7.2.2.1. Especificación del CUS Registrar Versión Breve descripción: En este caso de uso se programara la semana, los días y horas necesarias para la producción de una línea, y para la cual se seleccionaran las características respectivas para producir dicho artículo como son: la sub familia, el tipo, sub tipo, la línea, el molde, el envase, la presentación, el origen, la marca y sub marca. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Selecciona una versión base u otra.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada.

3.

Selecciona la opción “Copiar”.

4.

Muestra una pantalla para ingresar el nombre y un comentario de la nueva versión a copiarse.

5.

Ingresa datos de la versión: número de semana y día. Luego selecciona “Guardar”.

6.

Muestra un mensaje preguntando si se está seguro de copiar la versión o si se desea cancelar.

7.

Selecciona la opción “Aceptar”.

8.

Inmediatamente saca una copia y la muestra en la lista de versiones de la bandeja de entrada. La nueva versión se encuentra en estado “Registrado”.

9.

Selecciona la nueva versión.

10.

Muestra seleccionada la versión requerida en la bandeja de entrada.

11.

Selecciona la opción “Editar”.

12.

Muestra la interfaz de registrar versión para ser completada.

13.

Selecciona datos necesarios para la fabricación de un artículo. Estos son: sub familia, tipo, sub tipo, línea, molde, envase, presentación, origen, marca y sub marca. Ingresa los datos de la versión. Selecciona la opción “Filtrar.”

15.

Filtra de acuerdo a lo seleccionado y carga los artículos disponibles

14.

112

para su puesta en producción. 16.

Selecciona un artículo y lo arrastra asignando un horario. Luego selecciona la opción de “Guardar Versión”.

17.

Muestra en pantalla un mensaje indicando que la versión se ha guardado correctamente. Regresa a la bandeja de entrada.

FLUJO ALTERNATIVO Datos no ingresados. 1.

No ingresa los datos de la nueva versión y luego selecciona la opción “Guardar”.

2.

Muestra en pantalla un mensaje indicando que ya existe una versión con el mismo nombre.

Opción “Cancelar”. 1.

Estando en la pantalla donde se deben ingresar los datos para la nueva versión, selecciona la opción “Cancelar”.

2.

Regresa a la bandeja de entrada.

1.

Estando en la interfaz de registrar versión selecciona “Cancelar”.

2.

Regresa a la bandeja de entrada y no guarda ningún cambio de la versión.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales. Pre-condiciones: Para registrar una nueva versión es necesario tomar como referencia una anteriormente creada. Post-condiciones: Una vez registrada la versión su estado inicial es “Registrado”. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.2. Especificación del CUS Mover Versión Breve descripción: 113

En este caso de uso el usuario tendrá la posibilidad de mover una versión desde su bandeja de entrada que es la real a otra bandeja de históricos. De igual manera podrá mover desde la bandeja de históricos a la real. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Selecciona una versión de su bandeja de entrada donde viene trabajando en tiempo real.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada, es decir la real.

3.

Selecciona la opción de “Copiar”.

4.

Muestra una pantalla para ingresar el nombre y un comentario de la nueva versión a copiarse.

5.

Selecciona la opción “Histórico” de la interfaz.

6.

Muestra la bandeja de históricos y una lista de versiones incluyendo la última movida.

FLUJO ALTERNATIVO Selecciona la opción “Real”. 1.

Estando en la bandeja de Históricos, selecciona una versión.

2.

Muestra seleccionada la versión requerida en la bandeja de históricos.

3.

Selecciona la opción “Mover” de la interfaz.

4.

Inmediatamente mueve el archivo de la versión, a la bandeja de entrada, es decir la “Real”.

5.

Selecciona la opción “Real” de la interfaz.

6.

Muestra la bandeja de entrada y una lista de versiones incluyendo la última movida.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales.

Pre-condiciones:

114

Para que la versión pueda ser movida de la bandeja “Real” a la bandeja de “Histórico” y viceversa, ésta no se debe encontrar en estado “Por aprobar”. Post-condiciones: La versión se encuentra disponible para ser trabajada ya sea en la bandeja de entrada o en la bandeja de “Histórico.” Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.3. Especificación del CUS Copiar Versión Breve descripción: En este caso de uso se obtiene la copia de una versión base u otra que es tomada como referencia de la lista mostrada en la bandeja de entrada, y que después será editada para su programación. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Selecciona una versión base u otra de la bandeja de entrada.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada.

3.

Selecciona “Copiar”.

de

4.

Muestra una pantalla para ingresar el nombre y un comentario de la nueva versión a copiarse.

5.

Ingresa los datos de la nueva versión y luego selecciona la opción “Guardar”.

6.

Muestra un mensaje preguntando si se está seguro de copiar la versión o si se desea cancelar.

7.

Selecciona la opción “Aceptar”.

8.

Inmediatamente saca una copia y la muestra en la lista de versiones de la bandeja de entrada. La nueva versión se encuentra en estado “Registrado”.

la

opción

FLUJO ALTERNATIVO

115

Datos no ingresados. 1.

No ingresa los datos de la nueva versión y luego selecciona la opción “Guardar”.

2.

Muestra en pantalla un mensaje indicando que ya existe una versión con el mismo nombre.

2.

Regresa a la bandeja de entrada.

Opción “Cancelar”. 1.

Estando en la pantalla donde se deben ingresar los datos para la nueva versión, selecciona la opción “Cancelar”.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales. Pre-condiciones: Para que se pueda obtener una copia de la versión seleccionada, ésta no se debe encontrar en estado “Por aprobar”. Post-condiciones: La nueva versión se muestra en la lista de versiones de la bandeja de entrada disponible para ser trabajada. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.4. Especificación del CUS Publicar Programa Breve descripción: En este caso de uso se publica una versión cuando el usuario encargado está seguro de haber terminado correctamente la programación de una línea de producción y debe publicar la versión para que sea aprobada por cada uno de los responsables de cada familia. 116

Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Selecciona una versión en estado “Registrado” de la bandeja de entrada.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada.

3.

Selecciona la opción de “Publicar”.

4.

Muestra una pantalla de “publicar versión”, esperando que se ingrese la semana y el día para la publicación.

5.

Selecciona la semana e indica el día que ha de publicarse la versión. Selecciona “Grabar”.

6.

Muestra una pantalla de mensaje preguntando si se está seguro de publicar la versión.

7.

Selecciona “Aceptar” para publicar la versión.

8.

Muestra la bandeja de entrada y cambia el estado de la versión de “Registrado” a “Por Aprobar”, también envía alertas a los correos de los responsables de cada familia.

FLUJO ALTERNATIVO Datos ingresados no correctos. 1.

Estando en la pantalla de “Publicar versión” donde debe ingresar los datos de la publicación, ingresa erróneamente la semana y día, luego selecciona “Grabar”.

2.

Muestra un mensaje en pantalla indicando que los datos se han ingresado incorrectamente. Regresa a la pantalla de “Publicar versión” para ingresar nuevamente los datos.

2.

No guarda ningún cambio realizado y regresa a la bandeja de entrada.

Opción “Cancelar”. 1.

Estando en la pantalla de “Publicar versión” donde debe ingresar los datos de la publicación, selecciona la opción “Cancelar”.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales.

Pre-condiciones:

117

La

versión

a

publicar

debe

encontrarse

en

estado

“Registrado”. Post-condiciones: La versión publicada se encuentra en la lista de versiones de la bandeja de entrada con el estado “Por Aprobar” e inhabilitada para ser seleccionada. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.5. Especificación del CUS Editar Versión Breve descripción: En este caso de uso se programara la producción, para la cual se tomara una versión previamente creada y se modificara sus características como son: la sub familia, el tipo, sub tipo, la línea, el molde, el envase, la presentación, el origen, la marca y sub marca. También se podrá asignar o modificar los horarios para la fabricación del producto. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Selecciona una versión de la bandeja de entrada.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada.

3.

Selecciona la opción de “Editar”.

4.

Muestra la interfaz cargada con los datos de la versión ya sean completos o incompletos.

5.

Modifica o selecciona algunos o todos los datos de la versión. Selecciona la opción “Filtrar.” Selecciona un articulo y puede modificar o no el horario de producción arrastrando dicho

6.

Filtra de acuerdo a lo seleccionado y carga los artículos disponibles para su puesta en producción.

7.

118

artículo. 8.

Selecciona la opción de “Guardar Versión”.

9.

Muestra en pantalla un mensaje indicando que la versión se ha guardado correctamente. Regresa a la bandeja de entrada.

FLUJO ALTERNATIVO Opción “Cancelar”. 1.

Estando en la interfaz de editar, selecciona la opción “Cancelar”.

2.

No guarda ningún cambio realizado y regresa a la bandeja de entrada.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales. Pre-condiciones: Para editar una versión esta debe encontrarse en estado “Registrado” y puede encontrarse en la bandeja de entrada o bandeja de históricos. Post-condiciones: La versión modificada se muestra en la lista de la bandeja de entrada o bandeja de históricos según donde se haya encontrado

inicialmente.

Su

estado

se

mantiene

en

“Registrado”. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.6. Especificación del CUS Reporte Programa Planta Breve descripción:

119

En este caso de uso se mostrará un reporte indicando las horas y cantidades requeridas para la producción de una línea que ya se ha planificado en una versión. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Estando en la interfaz de la bandeja de entrada, selecciona una versión y luego ingresa a la opción de “Programación”.

2.

Muestra la interfaz de consolidado del programa, cargada con las horas y cantidades a producir por una línea de producción durante la semana indicada en la versión.

3.

Selecciona la opción ”Cerrar”.

4.

Cierra la interfaz de consolidado del programa y regresa a la interfaz anterior (bandeja de entrada).

FLUJO ALTERNATIVO Selecciona semana. 1.

Estando en la interfaz de consolidado del programa, selecciona una semana.

2.

Actualiza y muestra la interfaz cargada con las horas y cantidades a producir por línea de producción para dicha semana seleccionada.

No selecciona versión. 1.

Estando en la interfaz de la bandeja de entrada, ingresa a la opción de “Programación” (no selecciona ninguna versión).

2.

Muestra la interfaz de consolidado del programa vacía, es decir sin ningún dato.

3.

Selecciona la semana programación para filtrar.

4.

Muestra la interfaz de consolidado del programa, cargada con las horas y cantidades a producir por una línea de producción durante la semana seleccionada.

de

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales. Pre-condiciones: 120

Para poder seleccionar la opción “Programación” y ver el Reporte Programa Planta, no se necesita previamente haber seleccionado una versión. Post-condiciones: Este caso de uso no presenta post-condición. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.7. Especificación del CUS Aprobar Programa Breve descripción: En este caso de uso, el usuario comité decidirá si es correcto aprobar la versión del programa, de no ser así, se procederá a la desaprobación y futuro replanteamiento del mismo. Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Estando en la interfaz de la bandeja de entrada, ingresa a la opción “Aprobar Programa”.

2.

Muestra la interfaz de aprobar programa.

3.

Selecciona una Línea de Producción o una versión, y filtra por medio de un botón.

4.

Muestra la interfaz cargada con los datos de la versión y la línea de producción seleccionada anteriormente.

5.

Si está de acuerdo con la versión, selecciona “Aprobar Versión”.

6.

Muestra en pantalla un mensaje indicando que la versión ha sido aprobada correctamente.

7.

Si todos los responsables de aprobar la versión, realizan el mismo proceso, el sistema cambia el estado de la versión de “Por Aprobar” a “Publicado”. Finalmente regresa a la bandeja de entrada.

FLUJO ALTERNATIVO

121

No se está de acuerdo con la versión. 1.

Si no está de acuerdo con la versión, ingresa observaciones y selecciona “Desaprobar Versión”.

2.

Muestra en pantalla un mensaje preguntando si se está seguro de desaprobar a versión.

3.

Selecciona la opción “Desaprobar”

4.

Muestra en pantalla un mensaje indicando que la versión ha sido desaprobada.

5.

Muestra la interfaz de bandeja de entrada.

Requerimientos especiales: Este caso de uso deberá ser aplicado por cada uno de los responsables de una familia. Pre-condiciones: Para que una versión sea aprobada, previamente debió ser publicada por el usuario programador y por lo cual ésta versión deberá encontrarse en estado “Por Aprobar”. Post-condiciones: La versión se mantiene en estado “Por Aprobar” hasta que cada uno de los responsables de una familia apruebe y el estado de dicha versión cambie a “Publicado” o desapruebe y su estado cambie a “Registrado”. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

7.2.2.8. Especificación del CUS Replantear Programa Breve descripción: En este caso de uso se reestructurará la programación de la producción de una línea de acuerdo a lo establecido por el comité de aprobación. 122

Flujo básico y alternativo: FLUJO BÁSICO USUARIO

SISTEMA

1.

Cuando la versión ha sido rechazada y su estado ha cambiado de “Por Aprobar” ha “Registrado”. Selecciona dicha versión.

2.

Muestra seleccionada la versión requerida en la bandeja de entrada.

3.

Selecciona la opción “Editar”.

4.

Muestra la interfaz cargada con los datos de la versión.

5.

Replantea seleccionando nuevamente los datos necesarios para la fabricación de una línea. Estos son: sub familia, tipo, sub tipo, línea, molde, envase, presentación, origen, marca y sub marca. Guarda.

6.

Modifica el horario de producción arrastrando nuevamente el artículo para su puesta en producción.

7.

Muestra en pantalla un mensaje preguntando si se está seguro de guardar la versión.

9.

Guarda la modificación de la versión.

Selecciona guardar versión. 8.

Selecciona “Aceptar”.

FLUJO ALTERNATIVO Selecciona “Cancelar”. 1.

Estando en la interfaz de registrar versión selecciona “Cancelar”.

2.

Regresa a la bandeja de entrada y no guarda ningún cambio de la versión.

Requerimientos especiales: Este caso de uso no presenta requerimientos especiales. Pre-condiciones: Este caso de uso no presenta pre-condiciones. Post-condiciones: 123

Este caso de uso no presenta post-condiciones. Puntos de extensión: Este caso de uso no presenta puntos de extensión.

124

6.1.3. Diagrama de secuencias. 7.2.3.1. Diagrama de Secuencia del CUS Registrar Versión CUS - Registrar Versión

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Copiar Versión()

2 : Seleccionar Editar Versión() 3 : Ingresa Interface Registrar Versión() 4 : GetDatosVersión() 5 : GetDatosVersión() 6 : Set Entidad()

7 : Get Entidad() 8 : Retorna Verisón() 9 : Muestra Verisón() 10 : Selecciona Línea de Producción()

11 : Selecciona Otros filtros para ubicar el articulo a programar()

12 : Arrastra los articulos a la grilla de acuerdo a la hora programada()

13 : Presiona el boton Guardar() 14 : Set Entidad()

16 : GuardarVersión()

15 : Get Entidad() 17 : Guardar Versión()

18 : Get Result() 19 : Get Result() 20 : Ejecuta Filtrar Versión() 21 : GetDatosVersion() 22 : GetDatosVerisión() 23 : Set Entidad()

24 : Get Entidad() 25 : Retorna Versión() 26 : Muestra Versión()

Figura 34: Diagrama de secuencia del CUS Registrar Versión. (Elaboración: Propia, 2013.)

125

7.2.3.2. Diagrama de Secuencia del CUS Replantear Versión CUS - Replantear Programa

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Reprogramar Versión()

2 : Ingresa Interface Registrar Versión()

3 : GetDatosVersión() 4 : GetDatosVersión() 5 : Set Entidad()

6 : Get Entidad() 7 : Retorna Verisón() 8 : Muestra Verisón() 9 : Selecciona Línea de Producción()

10 : Selecciona Otros filtros para ubicar el articulo a programar()

11 : Arrastra los articulos a la grilla de acuerdo a la hora programada()

12 : Presiona el boton Guardar() 13 : Set Entidad()

15 : GuardarVersión()

14 : Get Entidad() 16 : Guardar Versión()

17 : Get Result() 18 : Get Result() 19 : Ejecuta Filtrar Versión() 20 : GetDatosVersion() 21 : GetDatosVerisión() 22 : Set Entidad()

23 : Get Entidad() 24 : Retorna Versión() 25 : Muestra Versión()

Figura 35: Diagrama de secuencia del CUS Replantear Versión. (Elaboración: Propia, 2013.)

126

7.2.3.3. Diagrama de Secuencia del CUS Aprobar Versión CUS - Aprobar Versión

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

E VersiónXResponsable

: Usuario 1 : Seleccionar Aprobar Versión()

2 : Ingresa Interface Registrar Versión() 3 : GetDatosVersión() 4 : GetDatosVersión() 5 : Set Entidad()

6 : Get Entidad() 7 : Retorna Verisón() 8 : Muestra Verisón() 9 : Selecciona Línea de Producción()

10 : Presiona el Boton Filtrar()

11 : FiltrarVersiónPorLinea() 12 : FiltrarVersionPorLinea() 13 : Set Entidad()

14 : Get Entidad() 15 : Retorna Detalles Por Linea() 16 : Muestra Detalles() 17 : Selecciona Aprobar Verisón() 18 : Set Entidad()

20 : ApruebaVersión()

19 : Get Entidad() 21 : ApruebaVersión()

22 : Result Aprobado() 23 : Result Estado() 24 : Muestra pantalla de menú de plan.Producción()

Figura 36: Diagrama de secuencia del CUS Aprobar Versión. (Elaboración: Propia, 2013.)

127

7.2.3.4. Diagrama de Secuencia del CUS Control de Calidad CUS - Controles de Calidad

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Familia o division a trabajar()

2 : Seleccionar Opción Control() 3 : Ingresa Interface Control Calidad() 4 : GetDatosBase() 5 : GetDatosBase() 6 : Set Entidad()

7 : Get Entidad() 8 : Retorna Datos Base() 9 : Muestra Datos Base() 10 : Selecciona Semana y Línea de Producción()

11 : Selecciona Restricción para programa()

12 : Arrastra la restricción a la grilla de acuerdo a la hora programada()

13 : Presiona el boton Guardar() 14 : Set Entidad()

16 : GuardarControl()

15 : Get Entidad() 17 : GuardarControl()

18 : Get Result() 19 : Get Result() 20 : Ejecuta FiltrarControl() 21 : GetFiltrarControl() 22 : GetFiltrarControl() 23 : Set Entidad()

24 : Get Entidad() 25 : Retorna ControlBase() 26 : Muestra ControlBase()

Figura 37: Diagrama de secuencia del CUS Control de Calidad. (Elaboración: Propia, 2013.)

128

7.2.3.5. Diagrama de Preventivos

Secuencia

del

CUS

Mantenimientos

CUS - Mantenimientos Preventivos

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Familia o division a trabajar()

2 : Seleccionar Opción Control() 3 : Ingresa Interface Control Mantenimientos() 4 : GetDatosBase() 5 : GetDatosBase() 6 : Set Entidad()

7 : Get Entidad() 8 : Retorna Datos Base() 9 : Muestra Datos Base() 10 : Selecciona Semana y Línea de Producción()

11 : Selecciona el mantenimiento para programa()

12 : Arrastra el Mantenimiento a la grilla de acuerdo a la hora programada()

13 : Presiona el boton Guardar() 14 : Set Entidad()

16 : GuardarControl()

15 : Get Entidad() 17 : GuardarControl()

18 : Get Result() 19 : Get Result() 20 : Ejecuta FiltrarMantenimiento() 21 : GetFiltrarMantenimiento() 22 : GetFiltrarMantenimiento() 23 : Set Entidad()

24 : Get Entidad() 25 : Retorna ControlBase() 26 : Muestra ControlBase()

Figura 38: Diagrama de secuencia del CUS Mantenimientos Preventivos. (Elaboración: Propia, 2013.)

129

7.2.3.6. Diagrama de Secuencia del CUS Editar Versión CUS - Editar Versión

I - Pantalla Menú Plan.Producciòn

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Editar Versión()

2 : Ingresa Interface Registrar Versión() 3 : GetDatosVersión() 4 : GetDatosVersión() 5 : Set Entidad()

6 : Get Entidad() 7 : Retorna Verisón() 8 : Muestra Verisón()

9 : Selecciona Línea de Producción() 10 : Presiona el boton Filtrar() 11 : GetDatosVersion() 12 : GetDatosVerisión() 13 : Set Entidad()

14 : Get Entidad() 15 : Retorna Versión() 16 : Muestra Versión() 17 : Utiliza el menú contextual para editar articulos()

18 : Selecciona articulos y arrastra hasta la grilla()

19 : Utiliza el menú contextual para editar articulos()

20 : Presiona el boton Guardar()

21 : Set Entidad()

23 : GuardarVerision()

22 : Get Entidad() 24 : GuardarVersion()

25 : Return result() 26 : Mostrar Resultado()

130

Figura 39: Diagrama de secuencia del CUS Editar Versión. (Elaboración: Propia, 2013.)

131

7.2.3.7. Diagrama de Secuencia del CUS Publicar Programa CUS - Publicar Programa

I - Pantalla Menú Plan.Producciòn

L - Mantenimiento

AD - Mantenimiento

U - Utilitarios

E - Versión

E - VersionResponsable

: Usuario 1 : Seleccionar Versión a publicar()

2 : Presionar el botón Publicar() 3 : Muestra ventana modal de publicación()

4 : selecciona semana de producción() 5 : Presiona ejecutar() 6 : Set Entidad()

7 : Get Entidad() 8 : Set Entidad()

9 : Get Entidad()

10 : PublicarVerion() 11 : PublicarVersion()

12 : Get Result() 13 : Muestra Resultado() 14 : Envía Alerta de publicación a responsables() 15 : EnviaMail()

16 : Get Result() 17 : Muestra Pantalla Inicial()

Figura 40: Diagrama de secuencia del CUS Publicar Programa. (Elaboración: Propia, 2013.)

132

7.2.3.8. Diagrama de Secuencia del CUS Copiar Versión

CUS - Copiar Versión

I - Pantalla Menú Plan.Producciòn

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Seleccionar Versión a Copiar()

2 : Presionar el botón Copiar() 3 : Muestra ventana modal de Copiar()

4 : Ingresa versión provisional y comentario() 5 : Presiona ejecutar() 6 : Set Entidad()

7 : Get Entidad() 8 : CopiarVerion() 9 : CopiarVersion()

10 : Get Result() 11 : Muestra Resultado()

Figura 41: Diagrama de secuencia del CUS Copiar Versión. (Elaboración: Propia, 2013.)

133

7.2.3.9. Diagrama de Secuencia del CUS Mover Versión

CUS - Mover Versión

I - Pantalla Menú Plan.Producciòn

L - Mantenimiento

AD - Mantenimiento

E - Versión

: Usuario 1 : Selecciona Versión a Mover()

2 : Presionar el botón Mover() 3 : Muestra ventana modal de Mover()

4 : Ingresa versión provisional() 5 : Presiona ejecutar() 6 : Set Entidad()

8 : MoverVerion()

7 : Get Entidad()

9 : MoverVersion()

10 : Get Result() 11 : Muestra Resultado()

Figura 42: Diagrama de secuencia del CUS Mover Versión. (Elaboración: Propia, 2013.)

134

7.2.3.10. Diagrama de Secuencia del CUS Calcular Rendimientos

CUS - Calcular Rendimientos

I - Pantalla Registrar Versión

L - Mantenimiento

AD - Mantenimiento

AD - LLamadas RPG

E - Versión

: Usuario Include CUS - Registrar Versión, CUS Editar Versión

1 : GuardarVersión() 2 : Guardar Versión() 3 : Ejecutar_RPG_Rendimientos() 4 : Set Entidad()

5 : Get Entidad()

6 : Get Result() 7 : Ejecuta Filtrar Versión()

Figura 43: Diagrama de secuencia del CUS Calcular Rendimientos. (Elaboración: Propia, 2013.)

7.2.3.11. Diagrama de Secuencia del CUS Alertas de Consumo

CUS - Alertas de Consumo

I - Pantalla Menú Plan.Producciòn

: Usuario

L - Mantenimiento

AD - Mantenimiento

AD - LLamadas RPG

U - UTILITARIOS

Include CUS - Publicar Versión

1 : PublicarVerion() 2 : PublicarVersion()

3 : Get Result() 4 : DeterminarStockInsumo()

5 : RetornaValores() 6 : EnviaAlertaConsumo() 7 : EnviaAlertaConsumo()

8 : ReturnResult()

Figura 44: Diagrama de secuencia del CUS Alertas de Consumo. (Elaboración: Propia, 2013.)

135

7.2.3.12. Diagrama de Secuencia del CUS Reporte Programa Planta CUS - Reporte Programa Planta

I - Pantalla Menú Plan.Producciòn

I - Pantalla Reporte Incidencias

L - Listas

AD - Listas

E - Versión

: Usuario 1 : Presionar botón Reporte Programa() 2 : Muestra pantalla Reporte Planta() 3 : Seleeciona Semana() 4 : GetDatosReportePrograma() 5 : GetDatosReportePrograma() 6 : Set Entity()

7 : Get Entity() 8 : RetornaDatosReportePrograma() 9 : MuestraDatosReportePrograma()

Figura 45: Diagrama de secuencia del CUS Reprogramar Planta. (Elaboración: Propia, 2013.)

7.2.3.13. Diagrama de Secuencia del CUS Consultar Incidencias CUS - Consultar Incidencias

I - Pantalla Menú Plan.Producciòn

I - Pantalla Reporte Incidencias

L - Listas

AD - Listas

E - Versión

: Usuario 1 : Presionar botón Reporte Incidencias() 2 : Muestra Pantalla Reporte Incidencias()

3 : Selecciona semana, versión()

4 : Presiona botón Consultar() 5 : GetDatosReporteIncidencias() 6 : GetDatosReporteIncidencias() 7 : Set Entity()

8 : Get Entity() 9 : RetornaDatosReporteIncidencias() 10 : MuestraDatosReporteIncidencias()

Figura 46: Diagrama de secuencia del CUS Consultar Incidencias. (Elaboración: Propia, 2013.)

136

6.2. Diagrama de Clases de Diseño.

Figura 47: Diagrama de Clases de Diseño. (Elaboración: Propia, 2013.)

137

6.3. Modelo de Datos 6.3.1. Diagrama del Modelo de Datos.

138

TPMXL TPLIN

TPFAM FAMCVE: NUMERIC(3) R_18

FAMDES: CHARACTER(50) FAMSIT: NUMERIC(1)

LINCVE: NUMERIC(3) (FK) MOLCVE: NUMERIC(3) (FK)

LINCVE: NUMERIC(3) R_8

TPMOL R_3

MOLCVE: NUMERIC(3)

MOLDES: CHARACTER(40) MOLSIT: NUMERIC(1) MOLTMH: NUMERIC(8,3) MOLTCM: NUMERIC(8,3) MOLTMM: NUMERIC(8,3) MOLTAR: NUMERIC(8,3)

FAMCVE: NUMERIC(3) (FK) R_1 LINDES: CHARACTER(40) LINUBI: CHARACTER(2) LINSIT: NUMERIC(1)

MOLNUM: CHARACTER(10) MOLDES: CHARACTER(40) MOLSIT: NUMERIC(1) R_13

TPSFA FAMCVE: NUMERIC(3) (FK) SFACVE: NUMERIC(3)

TPRGD

SFADES: CHARACTER(50) SFASIT: NUMERIC(1)

PRDSEM: NUMERIC(2) PRDHOI: NUMERIC(4,2) PRDHOF: NUMERIC(4,2) PRHSEC: NUMERIC(10) (FK)

R_5 TPRGH PRHSEC: NUMERIC(10) PRHFAM: NUMERIC(3) PRHVRS: CHARACTER(9) PRHCMT: CHARACTER(200) PRHSIT: CHARACTER(1) PRHFRE: NUMERIC(8) PRHURE: CHARACTER(10) PRHFMO: NUMERIC(8) PRHUMO: CHARACTER(10) PRHRE1: CHARACTER(100) PRHRE2: CHARACTER(100) PRHRE3: CHARACTER(100)

TPRES RESCVE: CHARACTER(10) RESTIP: CHARACTER(1) RESITU: CHARACTER(1)

R_11

R_4

TPRXF R_9

RXFSIT: CHARACTER(1)

R_6

TPMAR

TPSMA MARCVE: NUMERIC(3) (FK) SMACVE: NUMERIC(3)

R_14

SMADES: CHARACTER(50) SMASIT: NUMERIC(1)

RESCVE: CHARACTER(10) (FK) FAMCVE: NUMERIC(3) (FK) PRHSEC: NUMERIC(10) (FK) RXFSIT: CHARACTER(1) APRFEC: NUMERIC(8) APRHOR: NUMERIC(4)

ARTCOD: CHARACTER(10)

PRDLUN: CHARACTER(10) PRDMAR: CHARACTER(10) PRDMIE: CHARACTER(10) PRDJ UE: CHARACTER(10) PRDVIE: CHARACTER(10) PRDSAB: CHARACTER(10) PRDDOM: CHARACTER(10) PRDCOR: NUMERIC(2) PRDRE1: CHARACTER(50) PRDRE2: CHARACTER(50) PRDRE3: CHARACTER(50) LINCVE: NUMERIC(3) (FK) R_15

FAMCVE: NUMERIC(3) (FK) RESCVE: CHARACTER(10) (FK)

TPAPR

TARTP

MARCVE: NUMERIC(3) MARDES: CHARACTER(50) PROCVE: NUMERIC(3) MARSIT: NUMERIC(1)

FAMCVE: NUMERIC(3) (FK) TIPCVE: NUMERIC(3) (FK) MOLCVE: NUMERIC(3) (FK) MARCVE: NUMERIC(3) (FK) ARTCSA: NUMERIC(3) ARTSMA: NUMERIC(3) ARTIPO: NUMERIC(3) ARTSTI: NUMERIC(3) ARTPRE: NUMERIC(3) ARTENV: NUMERIC(3) ARTORG: NUMERIC(3) ARTR01: CHARACTER(15) ARTR02: CHARACTER(15) ARTR03: CHARACTER(15) ARTR04: CHARACTER(15) ARTFMT: CHARACTER(40) ARTSIT: CHARACTER(1)

R_12 TPSTI TIPCVE: NUMERIC(3) (FK) STICVE: NUMERIC(3) FAMCVE: NUMERIC(3) (FK) STIDES: CHARACTER(50) STISIT: CHARACTER(1)

TPTIP R_16

TIPCVE: NUMERIC(3) FAMCVE: NUMERIC(3)

R_17

TIPDES: CHARACTER(50) TIPSIT: CHARACTER(1)

139

Figura 48: Diagrama de Modelo de Datos. (Elaboración: Propia, 2013.)

6.3.2. Diccionario de datos. Tabla: SPEEDOBJEM/TPRES (RESPONSABLE) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

RESCVE

CHARACTER

10

No

PK

Identificador de Responsable

RESTIP

CHARACTER

1

No

FK

Identificador del Tipo

RESITU

CHARACTER

2

No

NO

Situación

Tabla: SPEEDOBJEM/TPRXF (RESPONSABLEPORDIVISION) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

RESCVE

CHARACTER

10

No

PK

Identificador de Responsable

FAMCVE

NUMERIC

3

No

FK

Identificador de la familia

RXFSIT

CHARACTER

2

No

NO

Situación

Tabla: SPEEDOBJEM/TPLIN (LINEA DE PRODUCCION) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

LINCVE

NUMERIC

3

No

PK

Identificador de la línea

FAMCVE

NUMERIC

3

No

FK

Identificador de la familia

140

LINDES

CHARACTER

40

No

NO

Descripción de la línea de producción

LINUBI

CHARACTER

2

SI

No

Ubicación de la línea la línea de producción

LINSIT

CHARACTER

2

NO

No

Situación

Tabla: SPEEDOBJEM/TPMOL (MOLDE) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

MOLCVE

NUMERIC

3

No

PK

Identificador del molde

MOLNUM

CHARACTER

10

No

NO

Número de molde

MOLDES

CHARACTER

40

No

NO

Descripción del molde

MOLSIT

CHARACTER

2

NO

NO

Situación

Tabla: SPEEDOBJEM/TPMXL (DETALLE LINEA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

MOLCVE

NUMERIC

3

No

PK

Identificador del molde

LINCVE

NUMERIC

3

NO

FK

Identificador de la línea

MOLDES

CHARACTER

40

NO

No

Código de molde

MOLSIT

CHARACTER

2

NO

No

Situación

MOLTMH

NUMERIC

8

3

NO

No

Tm por hora

MOLTCM

NUMERIC

8

3

NO

No

Tiempo cambio molde

MOLTMM

NUMERIC

8

3

NO

No

Tm mínima

141

MOLTAR

NUMERIC

8

3

NO

No

Tiempo de arranque

Tabla: SPEEDOBJEM/TPAPR (APROBACIÓN) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

RESCVE

CHARACTER

10

NO

PK

Identificador de usuario

FAMCVE

NUMERIC

3

NO

FK

Identificador de la familia

PRHVRS

CHARACTER

9

NO

FK

Código de la versión

RXFSIT

CHARACTER

2

NO

No

1= ESP 2=APR 3 RECH

APRFEC

NUMERIC

8

NO

No

Fecha de aprobación

APRHOR

NUMERIC

4

NO

No

Hora de aprobación

Tabla: SPEEDOBJEM/TPRGH (PROGRAMA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

PRHSEC

NUMERIC

10

NO

PK

Identificador de programa

PRHVRS

CHARACTER

9

NO

FK

Identificador de la versión

PRHFAM

NUMERIC

3

NO

FK

Identificador de la familia

PRHCMT

CHARACTER

200

NO

NO

Comentarios

PRHSIT

CHARACTER

1

NO

NO

1=REG 2=P.APRO 3=PUB

142

PRHFRE

NUMERIC

8

NO

NO

Fecha registro

PRHURE

CHARACTER

10

NO

NO

Usuario registro

PRHFMO

NUMERIC

8

NO

NO

Fecha modificar

PRHUMO

CHARACTER

10

NO

NO

Usuario modificar

PRHRE1

CHARACTER

100

SI

NO

Referencia 1

PRHRE2

CHARACTER

100

SI

NO

Referencia 2

PRHRE3

CHARACTER

100

SI

NO

Referencia 3

Tabla: SPEEDOBJEM/TPRGD (PROGRAMA DETALLE) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

PRDSEC

NUMERIC

10

NO

PK

Identificador de programa

PRDSEM

NUMERIC

2

NO

FK

Semana

PRDLIN

CHARACTER

3

NO

FK

Línea de producción

PRDHOI

NUMERIC

4

2

NO

NO

Hora inicio

PRDHOF

NUMERIC

4

2

NO

NO

Hora fin

PRDLUN

CHARACTER

10

NO

NO

Art lunes

PRDMAR

CHARACTER

10

NO

NO

Art martes

PRDMIE

CHARACTER

10

NO

NO

Art miércoles

PRDJUE

CHARACTER

10

NO

NO

Art jueves

PRDVIE

CHARACTER

10

NO

NO

Art viernes

PRDSAB

CHARACTER

10

NO

NO

Art sábado

PRDDOM

CHARACTER

10

NO

NO

Art domingo

PRDCOR

NUMERIC

2

NO

NO

Correlativo

PRDRE1

CHARACTER

50

SI

NO

Referencia 1

PRDRE2

CHARACTER

50

SI

NO

Referencia 2

143

PRDRE3

CHARACTER

50

SI

NO

Referencia 3

Tabla: SPEEDOBJEM/TARTP (ARTÍCULO) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

ARTCOD

CHARACTER

10

NO

FK

Código de articulo

ARTCFA

NUMERIC

3

NO

NO

Código familia

ARTCSA

NUMERIC

3

NO

NO

Código sub familia

ARTMAR

NUMERIC

3

NO

NO

Código marca

ARTSMA

NUMERIC

3

NO

NO

Código sub marca

ARTCMO

NUMERIC

3

NO

NO

Código molde

ARTIPO

NUMERIC

3

NO

NO

Código tipo

ARTSTI

NUMERIC

3

NO

NO

Código sub tipo

ARTPRE

NUMERIC

3

NO

NO

Código presentación

ARTENV

NUMERIC

3

NO

NO

Código envase

ARTORG

NUMERIC

3

NO

NO

Código origen

ARTR01

CHARACTER

15

NO

NO

Referencia 1

ARTR02

CHARACTER

15

NO

NO

Referencia 2

ARTR03

CHARACTER

15

NO

NO

Referencia 3

ARTR04

CHARACTER

15

NO

NO

Referencia 4

ARTFMT

CHARACTER

40

NO

Formato

144

ARTSIT

NUMERIC

1

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPFAM (FAMILIA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

FAMCVE

NUMERIC

3

NO

PK

Identificador de la familia

FAMDES

CHARACTER

50

NO

NO

Descripción

FAMSIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPMAR (MARCA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

MARCVE

NUMERIC

3

NO

PK

Identificador de la marca

MARDES

CHARACTER

50

NO

NO

Descripción

PROCVE

NUMERIC

3

NO

NO

Producción

MARSIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPTIP (TIPO) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

TIPCVE

NUMERIC

3

NO

PK

Identificador del tipo

FAMCVE

NUMERIC

3

NO

NO

Código familia

145

TIPDES

CHARACTER

50

NO

NO

Descripción

TIPSIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPSFA (SUB FAMILIA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

FAMCVE

NUMERIC

3

NO

PK

Identificador de la familia

SFACVE

NUMERIC

3

NO

FK

Identificador de la sub familia

SFADES

CHARACTER

50

NO

NO

Descripción

SFASIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPSMA (SUB MARCA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

MARCVE

NUMERIC

3

NO

PK

Identificador de la marca

SMACVE

NUMERIC

3

NO

FK

Identificador de la sub marca

SMADES

CHARACTER

50

NO

NO

Descripción

SMASIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEEDOBJEM/TPSTI (SUB TIPO) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

TIPCVE

NUMERIC

3

NO

PK

Identificador del tipo

146

STICVE

NUMERIC

3

NO

FK

Identificador del sub tipo

STIDES

CHARACTER

50

NO

NO

Descripción

STISIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEED400EM/TPFOH (FORMULA) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

FOHCFO

NUMERIC

10

NO

PK

Identificador de la fórmula

FOHCAR

CHARACTER

10

NO

FK

Identificador del artículo

FOHALM

CHARACTER

2

NO

NO

Código almacén

FOHFCR

NUMERIC

8

NO

NO

Fecha creación

FOHFMO

NUMERIC

8

NO

SI

Fecha modificación

FOHUCR

CHARACTER

10

NO

NO

Usuario creación

FOHUMO

CHARACTER

10

NO

SI

Usuario modificación

FOHCMT

CHARACTER

200

NO

NO

Comentario

FOHSIT

NUMERIC

1

NO

NO

1=HABIL 2= NO HABIL

Tabla: SPEED400EM/TPFOD (FORMULA DETALLE) Campo

Tipo

Largo

Acepta Nulos

Es Primary Key

Descripción

FODCFO

NUMERIC

10

NO

PK

Identificador de la fórmula

FODCFD

NUMERIC

10

NO

FK

Identificador del detalle

FODINS

CHARACTER

50

NO

NO

Insumo

FODCANT

NUMERIC

8 2

NO

NO

Cantidad

FODUNI

CHARACTER

20

NO

NO

Unidad

147

FODFOR

CHARACTER

50

NO

NO

Formato

6.4. Modelo de Despliegue

Servidor de Correo

HTTP (AJ AX llamadas asincronas )

PC Usuario

FireWall

Servidor Web

TCP

HTTP (XHTML) Servidor AS 400

Figura 49: Diagrama de Modelo de Despliegue. (Elaboración: Propia, 2013.)

6.5. Modelo de Componentes COPIAR ACCESO_ ODBC

EDITAR

PUBLICAR

REPLANTEAR

AS400_ DB2

PLAN_ PRODUCCION_ WEB

PLANEAR_ PRODUCCIÓN_

CONTROL_ CALIDAD

CONTROL_ CALIDAD_

MANTENIMIENTOS_ PLANTA_

MANTENI MIENTO_ PREVENTIVO

REPORTES_

INCIDENCIAS

MOVER

PROGRAMA_ PLANTA

Figura 50: Diagrama de Modelo de Componentes. (Elaboración: Propia, 2013.)

148

Conclusión Para la integración de cualquier otro sistema con el planteado en la presente tesis, será

a través de archivos planos o Web Services debido a que el

modelo de datos desarrollado presenta tablas exclusivas para el correcto funcionamiento del sistema propuesto y no para ser usados por otros sistemas a nivel transaccional que puedan ocasionar una corrupción a nivel de integridad de datos.

149

150

CAPÍTULO VII – DESARROLLO Y PRUEBAS

7.1. Desarrollo 7.1.1. Plataforma Tecnológica Tecnología: Para el desarrollo de la solución de software propuesta en la presente investigación se utilizará la plataforma: Visual Studio .NET 2010 y el lenguaje de programación C# (C Sharp), ya que cumple con las políticas del entorno de desarrollo de la empresa. Se usará también JavaScript y la Librería JQUERY para la presentación de los controles y manipulación de información en la capa de presentación (WebForms).

Además todas las transacciones serán a través del motor de base datos compartido DB2 - AS400.

Framework: La aplicación web usará el Framework .NET 4.0 conformada por las librerías necesarias para el desarrollo.

Patrones: En cuanto al patrón de arquitectura a utilizar, éste será el de capas: Entidades, Acceso a Datos, Lógica, Presentación y Servicio de Host.

7.1.2. Descripción de los estándares de desarrollo (Ver Anexo I)

151

7.2. Pruebas 7.2.1. Plan de Pruebas del Proyecto Propósito: El plan de pruebas propuesto para este proyecto, tiene como propósito cumplir con los siguientes objetivos: • Identificar las principales funcionalidades de la aplicación, para ser probadas. • Listar las estrategias o tipos de prueba a realizar. • Realizar pruebas respectivas según los principales requisitos identificados. • Mostrar los resultados de las pruebas ejecutadas.

Entorno: El siguiente plan de pruebas se desarrollara sobre el entorno de la aplicación de planificación de la producción propuesto en la presente investigación, la cual se encontrara desarrollada bajo una plataforma web, frameworks ASP.NET y lenguaje de programación C Sharp.

Alance: Se realizara las pruebas de “caja negra” la cual permitirá: • Identificar las funcionalidades requeridas. • Asegurar la entrada de datos. • Mantener seguro el procesamiento interno de los datos. • Mostrar y analizar los resultados o datos de salida.

152

Cronograma plan pruebas Tipo

Unidad

Unidad de Prueba

CNT

1

PCUS

Registrar versión

DEF

El usuario ingresa versión a planificar.

una

01/05/2013

Madeleyne Silva

Jonathan Vásquez

CNT

2

PCUS

Calcular rendimientos

DEF

El sistema calcula los rendimientos de articulo por molde-linea de producción.

09/05/2013

Madeleyne Silva

Jonathan Vásquez

CNT

3

PCUS

Editar versión

DEF

El usuario edita el programa de la producción.

18/05/2013

Madeleyne Silva

Jonathan Vásquez

CNT

4

PCUS

Mover versión

DEF

El usuario mueve las versiones hacia la bandeja real o historica.

24/05/2013

Madeleyne Silva

Jonathan Vásquez

CNT

5

PCUS

Copiar versión

DEF

El usuario obtiene una copia en base a su versión base u otra.

30/05/2013

Madeleyne Silva

Jonathan Vásquez

CNT

6

PCUS

Publicar programa

DEF

El usuario pùblica la versiòn para su respectiva aprobación en comité.

05/06/2013

Madeleyne Silva

Jonathan Vásquez

CNT

7

PCUS

Alerta consumos

DEF

El sistema envia alertas de falta de stock de insumos para la producción

12/06/2013

Madeleyne Silva

Jonathan Vásquez

CNT

8

PCUS

Replantear programa

DEF

El usuario replantea el programa debido a una aalteración en la producción real.

19/06/2013

Jonathan Vásquez

Madeleyne Silva

CNT

9

PCUS

Aprobar programa

DEF

Los involucrados en la producción aprueban la publicación del programa (visto bueno).

22/06/2013

Jonathan Vásquez

Madeleyne Silva

CNT

10

PCUS

Lanzar orden de producción

DEF

El sistema envía a producción la versión publicada.

24/06/2013

Jonathan Vásquez

Madeleyne Silva

CNT

11

PCUS

Mantenimientos preventivos

DEF

El area de mantenimiento planta ingresa su plan de mantnimiento por lineas de producción.

30/06/2013

Jonathan Vásquez

Madeleyne Silva

CNT

12

PCUS

Reporte programa planta

DEF

El usuario consulta el reporte de la versión final del programa.

02/07/2013

Jonathan Vásquez

Madeleyne Silva

CNT

13

PCUS

Consultar incidencias

DEF

El usuario consulta las incidencias de los replanteos del programa.

06/07/2013

Jonathan Vásquez

Madeleyne Silva

CNT

14

PCUS

Controles calidad

DEF

El area de calidad planta ingresa su plan de mantnimiento por lineas de producción.

12/07/2013

Jonathan Vásquez

Madeleyne Silva

de Prueba

de

de

Fecha Planificada

Responsable de la Unidad

Nro

Fase

Descripción

Tester

Tabla 21: Cronograma de plan de pruebas. (Elaboración: Propia, 2013.)

153

Leyenda Fase: CNT = Construcción Tipo de unidad: PCUS = Prueba de programación de caso de uso. Unidad de prueba: Es el artefacto específico que se va a someter a prueba. Tipo de prueba: DEF = Definitiva Descripción: Es la descripción detallada de lo que se pretende probar respecto al artefacto en el contexto del sistema. Tester: Es el revisor o la persona encargada de hacer la prueba. Responsable de la Unidad: Es la persona que desarrolló el artefacto o unidad de prueba.

7.2.2. Casos de uso de pruebas del proyecto para los casos de uso de la arquitectura Se realizara las pruebas respectivas a los siguientes casos de uso de prueba identificados del diagrama de caso de uso del sistema: 1.

Paquete Control Calidad. • CUP_001: Controles de Calidad.

2.

Paquete Planear Producción. • CUP_002: Registrar Versión. • CUP_003: Editar Versión. • CUP_004: Copiar Versión. • CUP_005: Mover Versión. 154

• CUP_006: Publicar Programa. • CUP_007: Replantear Programa.

3.

Paquete Mantenimiento Planta • CUP_008: Mantenimientos Preventivos.

4.

Paquete Consultas. • CUP_009: Reporte programa planta. • CUP_010: Consultar Incidencias.

7.2.3. Análisis de las pruebas con sus respectivos reportes de ejecución 8.3.3.1. Pruebas del paquete control de calidad CUP_001: Controles de Calidad Descripción:

Registrar

el

programa

de

controles

de

fumigaciones para una semana determinada. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión base de una determinada familia de producción y presiona editar. Resultado 1: El sistema muestra la pantalla de registro de los controles de calidad

Paso 2: El usuario selecciona la semana y las horas por línea de producción a reservar y selecciona guardar. 155

Resultado 1: el sistema guarda los registros ingresados por la jefa de control de calidad. Resultado 2: el sistema muestra un mensaje de conformidad.

8.3.3.2. Pruebas del paquete planear producción CUP_002: Registrar Versión Descripción: Registrar nueva versión de programación. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión base. Luego selecciona “Copiar”. Resultado 1: El sistema muestra una pantalla indicando ingresar el nombre y observaciones de la nueva versión.

Paso 2: El usuario digita el nombre y observaciones de la nueva versión. Luego selecciona “Guardar”. Resultado 1: El sistema muestra un mensaje en pantalla preguntando si se está seguro de guardar la versión.

Paso 3: El usuario selecciona “Aceptar”. Resultado 1: El sistema guarda la nueva versión con el estado “Registrado” y la muestra en la bandeja de entrada. 156

Paso 4: El usuario selecciona la nueva versión creada. Luego selecciona la opción “Editar”. Resultado 1: El sistema muestra la interfaz de registrar versión, con los datos (familia, línea, artículo, etc.) vacios y horarios de producción aun no establecidos.

Paso 5: El usuario ingresa los datos (familia, línea, artículo, etc.) y asigna horarios de producción. Luego selecciona “Guardar”. Resultado 1: El sistema muestra una pantalla preguntando si se está seguro de guardar la versión.

Paso 6: El usuario selecciona “Aceptar”. Resultado 1: El sistema guarda los datos de la versión y muestra la interfaz de la bandeja de entrada.

CUP_003: Editar Versión Descripción: Modificar los datos y horarios de producción de una versión. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la lista mostrada en la bandeja de entrada. Luego selecciona “Editar”.

157

Resultado 1: El sistema muestra la interfaz de registrar versión, cargada con los datos (familia, línea, artículo, etc.) y horarios

de producción

establecidos para dicha versión.

Paso 2: El usuario modifica los datos (familia, línea, artículo, etc.) y asigna horarios de producción. Luego selecciona “Guardar”. Resultado 1: El sistema muestra una pantalla preguntando si se está seguro de guardar la versión. Paso 3: El usuario selecciona “Aceptar”. Resultado 1: El sistema guarda la versión y muestra la interfaz de la bandeja de entrada.

CUP_004: Copiar Versión Descripción: Obtener una copia de una versión. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la bandeja de entrada. Luego selecciona “Copiar”.

Paso 2: El usuario digita el nombre y observaciones de la nueva versión. Luego selecciona “Guardar”. Resultado 1: El sistema muestra un mensaje en pantalla preguntando si se está seguro de guardar la versión.

158

Paso 3: El usuario selecciona “Aceptar”. Resultado 1: El sistema guarda la nueva versión y la muestra en la interfaz de la bandeja de entrada.

CUP_005: Mover Versión Descripción: Mover una versión, de la bandeja de entrada a la bandeja de histórico y viceversa. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la bandeja de entrada. Luego selecciona la opción “Mover”.

Resultado

1:

El

sistema

mueve

la

versión

seleccionada a la bandeja de históricos y ya no la muestra en la lista de la bandeja de entrada.

Paso 2: El usuario selecciona la opción “Histórico” de la bandeja de entrada. Resultado 1: El sistema muestra la bandeja de históricos con la versión movida anteriormente.

Paso 3: El usuario selecciona una versión de la bandeja de históricos. Luego selecciona la opción “Mover”. Resultado

1:

El

sistema

mueve

la

versión

seleccionada a la bandeja de entrada y ya no la muestra en la bandeja de históricos.

159

Paso 4: El usuario selecciona la opción “Real” de la bandeja de históricos. Resultado 1: El sistema muestra la bandeja de entrada con la versión movida anteriormente.

CUP_006: Publicar Programa Descripción: Publicar una versión programada en estado “Registrado” para su debida aprobación. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la bandeja de entrada. Luego selecciona la opción “Publicar”. Resultado 1: El sistema muestra una pantalla esperando que se ingrese la semana y el día de la publicación de dicha versión. Paso 2: El usuario ingresa la semana y el día de la publicación. Luego selecciona “Publicar”. Resultado 1: El sistema muestra una pantalla preguntando si se está seguro de publicar la versión.

Paso 3: El usuario selecciona “Aceptar”. Resultado 1: El sistema cambia el estado de la versión a “Por Aprobar” y muestra un mensaje de información indicando que la versión se ha publicado correctamente y se ha enviado mails de aviso a los responsables de las familias para su respectiva aprobación. 160

Paso 4: El usuario selecciona “Aceptar”. Resultado 1: El sistema muestra la bandeja de entrada y la versión con el estado cambiado a “Por Aprobar”.

CUP_007: Replantear Programa Descripción: Cuando la versión ha sido desaprobada y se encuentra en estado “Registrado”, se replantea a versión modificándola. Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la lista mostrada en la bandeja de entrada. Luego selecciona “Editar”.

Resultado 1: El sistema muestra la interfaz de registrar versión, cargada con los datos (familia, línea, artículo, etc.) y horarios

de producción

establecidos para dicha versión.

Paso 2: El usuario modifica los datos (familia, línea, artículo, etc.) y asigna horarios de producción. Luego selecciona “Guardar”. Resultado 1: El sistema muestra una pantalla preguntando si se está seguro de guardar la versión.

161

Paso 3: El usuario selecciona “Aceptar”. Resultado 1: El sistema guarda la versión y muestra la interfaz de la bandeja de entrada.

8.3.3.3. Pruebas del paquete mantenimientos preventivos CUP_008: mantenimientos preventivos Descripción: Registrar el programa con las restricciones para las líneas de producción en una semana determinada Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión base de una determinada familia de producción y presiona editar. Resultado 1: El sistema muestra la pantalla de registro de los mantenimientos preventivos.

Paso 2: El usuario selecciona la semana y las restricciones por línea de producción a reservar y selecciona guardar.

Resultado 1: el sistema guarda los registros ingresados por el jefe de mantenimiento. Resultado 2: el sistema muestra un mensaje de conformidad.

8.3.3.4. Pruebas del paquete reportes CUP_009: Reporte programa planta Descripción: Consultar las horas y cantidad de producción de una determinada semana. 162

Datos de entrada: Selecciona una versión. Paso 1: El usuario selecciona una versión en estado “Registrado” de la lista mostrada en la bandeja de entrada. Luego selecciona la opción “Programación”. Resultado 1: El sistema muestra la interfaz de programación

con

el

resumen

de

horas

y

cantidades de producción para dicha versión.

Paso 2: El usuario selecciona una semana en una opción de la interfaz. Resultado 1: El sistema muestra el resumen de horas y cantidades de producción para dicha semana.

CUP_010: Consultar Incidencias Descripción:

Consultar

las

incidencias

de

paradas,

mantenimientos, imprevistos, repetición y reprogramación de versiones, etc. Datos de entrada: No requiere ninguno. Paso

1:

El

usuario

selecciona

la

opción

“Consultar

Incidencias” de la bandeja de entrada. Resultado 1: El sistema muestra la interfaz de “Consultar Incidencias” con los reportes requeridos.

Conclusiones • Se realizaron pruebas de caja negra para evaluar el correcto funcionamiento de cada CUS. 163

• Para el desarrollo del proyecto de tesis se construyó la arquitectura en capas, empleando para la programación web el IDE Visual Studio 2010.Net (framework 4.0) y se usaron librerías como JQUERY, AjaxControlToolkit, entre otras.

164

CAPÍTULO VIII – GESTIÓN DEL PROYECTO 8.1. Organización del proyecto 8.1.1. Organigrama del proyecto A continuación, el diagrama de todos los involucrados en el proyecto. Jefe de sistemas

Analista de Sistemas

Control de Calidad

Analista Funcional

Desarrollador Figura 51: Organigrama del proyecto. (Elaboración: Propia, 2013.)

8.1.2. EDT del proyecto Representa el desagregado del proyecto por módulos y entregables.

Figura 52: representa el desagregado del proyecto por módulos y entregables. 165

(Elaboración: Propia, 2013.)

8.2. Estimación y Ejecución del Proyecto 8.2.1. Cronograma de Ejecución del Proyecto El presente cronograma dará un tiempo estimado para el desarrollo de la tesis. A continuación se muestra el cronograma del proyecto.

Figura 53: Cronograma del proyecto de tesis.

166

(Elaboración: Propia, 2013.)

8.2.2. Estimación del Presupuesto Total del Proyecto Teniendo en cuenta lo ya mencionado en el punto de la viabilidad técnica y económica (pág. 51 al 55), en la cual se especifica el costo 0 a nivel de hardware y

el costo 0 a nivel de licencias de software, se

concluye que se usarán las herramientas de desarrollo e infraestructura de TI con las cuales cuenta la empresa para desarrollar el proyecto de tesis. A continuación se muestra el presupuesto general que se necesitará para el

desarrollo de tesis (ver factibilidad técnica y económica para

mayor referencia pág. 51 al 55). Criterio

Descripción

A B

Hardware para el desarrollo Licencias para el desarrollo

C E

Equipo del Proyecto Coste de Mantenimiento TOTAL:

Monto (S/.) 0.00 0.00 32,400.00 5,400.00 37,800.00

Tabla 22: Presupuesto total del proyecto. (Elaboración: Propia, 2013.)

Criterios: A: Hardware necesario para el desarrollo y prueba del sistema. B: Licencias necesarias para el desarrollo del proyecto de tesis. C: Costes del equipo de proyecto, tomando 5h/día, 5 días/semana durante todo el tiempo de desarrollo del proyecto estimado en el cronograma. D: Costes de mantenimiento, tomando 2 mes luego de la entrega final. Debido a que la empresa cuenta con personal calificado para mantener el software de manera adecuada.

167

8.3. Gestión de Riesgos del Proyecto Propósito El propósito es identificar los riesgos más significativos a los que está expuesto el proyecto de investigación propuesto, y a su vez proponer la mejor solución para mitigarlos o formular un plan de contingencias. Alcance Abarca todas aquellas incidencias presentadas durante el desarrollo del proyecto, desde su concepción hasta las pruebas finales.

8.3.1. Riesgos No Predecibles Indisponibilidad de Stakeholders. •

Descripción: Cuando el usuario comprometido con el proceso del negocio a sistematizar no presenta disponibilidad de tiempo para brindar los requerimientos funcionales necesarios para el desarrollo del proyecto.



Impactos: Sobre el modelado y desarrollo del sistema pero fundamentalmente en la concepción.



Indicadores: Cuando en reiteradas ocasiones no se llega capturar los requerimientos necesarios para cumplir con el avance establecido en el cronograma.



Estrategia de Mitigación: Ante este riesgo, se deberá buscar otro stakeholder involucrado en el proceso del negocio.



Plan de Contingencia: Se asignara un stakeholder como remplazo en caso el stakeholder principal se encuentre indispuesto.

168

Indisponibilidad de los autores del proyecto. •

Descripción: Cuando los autores del proyecto propuesto se encuentren indispuestos por motivos de salud, trabajo u otros.



Impactos: Sobre el modelado y desarrollo del sistema desde su concepción hasta las pruebas finales.



Indicadores: Cuando en reiteradas ocasiones no se llega a cumplir con el avance establecido en el cronograma.



Estrategia de Mitigación: Ante este riesgo, se deberá reasignar las tareas no cumplidas hacia el otro autor del proyecto por lo que se deberá ajustar los tiempos en el cronograma.



Plan de Contingencia: Se deberá haber establecido un tiempo de holgura en el cronograma para algunas tareas críticas. Por lo que se podrá reasignar las tareas no cumplidas.

Retraso en el desarrollo del sistema. •

Descripción: Cuando los usuarios adicionen nuevos requerimientos establecidos por el negocio ya sea por la inclusión de una nueva regla o norma de la empresa.



Impactos: Sobre el modelado y desarrollo del sistema desde su concepción hasta las pruebas finales.



Indicadores:

Cuando

se

presenten

nuevos

requerimientos

inesperados durante el desarrollo del sistema. •

Estrategia de Mitigación: Ante este riesgo, se deberá repartir las nuevas tareas entre los autores del proyecto y por lo que se deberá ajustar los tiempos en el cronograma.

169



Plan de Contingencia: Se deberá haber establecido un tiempo de holgura en el cronograma para las nuevas tareas establecidas y por lo que se podrá asignar éstas sin afectar el cronograma.

Cambio de fechas en el cronograma. •

Descripción: Cuando por motivos de fuerza mayor no contemplados en el inicio del proyecto, se tenga que modificar las fechas establecidas en el cronograma.



Impactos: Sobre el modelado y desarrollo del sistema desde su concepción hasta las pruebas finales.



Indicadores: Cuando durante el desarrollo del proyecto se deba modificar

forzosamente

las

fechas

establecidas

por

motivos

inesperados y que el cronograma se vea afectado. •

Estrategia de Mitigación: Ante este riesgo, se deberá ajustar los tiempos de las tareas entre los autores del proyecto y por consiguiente ajustar el cronograma.



Plan de Contingencia: Se deberá haber establecido un tiempo de holgura en el cronograma para los cambios o ajustes de fechas y así no afecten las tareas establecidas.

8.3.2. Riesgos Predecibles Hardware deshabilitado •

Descripción: Cuando durante el desarrollo o pruebas del sistema, la empresa decida hacer algún tipo de mantenimiento o surjan incidentes a los servidores que están siendo utilizados por los autores del proyecto. 170



Impactos: Principalmente sobre el desarrollo y/o pruebas del sistema.



Indicadores: Cuando el desarrollo o pruebas se vea detenido por las incidencias de los servidores y no se llegue a cumplir con lo establecido el cronograma.



Estrategia de Mitigación: Ante este riesgo, se deberá repartir las tareas entre los autores del proyecto y por lo que se deberá ajustar los tiempos en el cronograma.



Plan de Contingencia: Se deberá haber establecido un tiempo de holgura en el cronograma para las tareas no cumplidas y por lo que se podrá reasignar éstas sin afectar el cronograma.

Conclusiones a) En cuanto a costos En cuanto a los gastos de Hardware y Software el costo es cero, debido a que se cuenta con todas las licencias y hardware necesario para el desarrollo del proyecto. Finalmente, la plataforma de desarrollo que se usará para la codificación del aplicativo web será Visual Studio 2010, debido a que actualmente se están

desarrollando proyectos con el

mismo entorno, por tal motivo, se desea mantener la misma línea de plataforma para evitar gastos en mantenimientos de mano de obra futuras.

El total de costos estimado para el desarrollo del proyecto por el periodo de un año es de S/. 132,876.

171

b) En cuanto a rentabilidad (ver capítulo I) Alternativa al 50% de mejora: Si se estima una mejora de producción en el proceso de planificación del 50% que representa en promedio el monto de s/. 285,000.00 como reducción en pérdidas, el retorno de la inversión comenzaría a partir del primer mes de puesto en producción el sistema. El monto retorno de la inversión se daría en el segundo mes S/. 363.600,52. Alternativa al 10% de mejora: Si la mejora en el proceso de planificación es del 10% en promedio, la rentabilidad representaría s/. 58,065.04 como reducción en pérdidas. Finalmente, el retorno de la inversión comenzaría al tercer mes de puesto en producción el sistema. El monto invertido se recuperaría al 7mo mes S/.149.808,93.

172

173

CONCLUSIONES •

Para planificar la producción es indispensable considerar los siguientes puntos: o Coordinaciones con las áreas competentes o Conocer las limitaciones de los recursos tanto inventariables como no inventariables. o Conocer

de antemano el plan de mantenimiento y controles de

calidad de las distintas líneas de producción o Conocer de antemano el estimado de ventas tanto nacional como de exportaciones. •

Una planificación mas de acorde a la realidad de la demanda del mercado produce un ahorro de insumos, espacios en almacén, capacidad productiva, etc, la cual se transforma en dinero para la empresa (ver capitulo 8).



Controlar parte del proceso productivo (planificación de la producción) con un sistema que cumpla con los requerimientos tanto funcionales como no funcionales y además parametrizado de acuerdo a sus políticas

(ver

capítulo I), permitirá una mejor gestión del proceso y explotación de la información, por lo tanto no se ha creado nuevos flujos o actividades que no estén enmarcados en los procedimientos mencionados. •

Se logró integrar el estimado de ventas y exportaciones con la realización del programa de la producción.



Se logró integrar los controles de calidad así como las programaciones de los mantenimientos preventivos con la realización del programa de la producción.

174



También se logró sistematizar e integrar a la realización del programa de la producción, el cálculo de los rendimientos de las líneas de producción por artículos a producir.



Finalmente se logró sistematizar el replantear los programas cuando estos se encuentren en producción y por consiguiente una comunicación fluida entre los responsables de cada familia ante los cambios u observaciones en la realización o aprobación del programa.

RECOMENDACIONES 175



Si se desea integrar un nuevo sistema al ya desarrollado y que no sea compatible tanto a nivel de plataforma de desarrollo como de SGBD, se recomienda emplear el uso de archivos planos o WebServices para la comunicación de estas ya que así no se dependerá del cambio de alguno de los sistemas integrados.



Si se desea añadir alguna funcionalidad a futuro se recomienda seguir los procedimientos y políticas establecidas por la empresa, así como los estándares de desarrollo, GUI y base de datos a fin de mantener una estructura escalable y de fácil acceso a cambios en el futuro.



Durante la realización del presente proyecto de tesis se hizo una profunda investigación acerca de los procesos del negocio y sus relaciones, obteniendo desde diferentes fuentes y puntos de vista, la información necesaria para la toma de la mejor alternativa de desarrollo del software, por lo que al cumplir a cabalidad con los requerimientos y expectativas de los stakeholders así como el correcto diseño del sistema, se obtiene un producto de calidad.

GLOSARIO DE TÉRMINOS División o Familia: Se refiere a las familias que agrupan los distintos artículos 176

que produce la empresa. • Harinas • Fideos • Alimentos Balanceados Estimado de Ventas: Se refiere a las proyecciones de ventas que entregan los gerentes regionales. Las proyecciones son mensuales y se clasifican por regiones. Exportaciones: Se refiere a las ventas pactadas con clientes que están fuera del territorio Peruano. Líneas de producción: Se refiere a las maquinas que corresponden a cada división o familia. Paradas no Programadas: Se refiere a cuando deja de operar una maquina en plena producción. Programa o programa de la producción: Se refiere al resultado final que se deriva a raíz de la programación de la producción. El programa es entregado a producción para su puesta en ejecución. Restricciones del Programa: Se considera restricciones a aquellos días en los cuales no se puede producir y las cuales están reservadas para programar mantenimientos preventivos y controles de sanidad de las líneas de producción. Recursos inventariables: Definido de todo aquel insumo que se extrae del almacén.

Stocks APT: Se refiere a la cantidad de productos terminados que se encuentran disponibles en almacén.

177

SIGLARIO

1. APT: Almacén de Productos Terminados. 2. CUN: Caso de Uso del Negocio. 178

3. CUS: Caso de Uso del Sistema. 4. EDT: Estructura de Descomposición del Trabajo. 5. ERP: Planificación de Recursos Empresariales. 6. MRP: Planificación de los Requerimientos de Material.

BIBLIOGRAFÍA TEXTOS ELECTRÓNICOS: 1. (Affiliates 10) Affiliates, O. a. The Java EE 5 Tutorial 179

Visitado el 21 de Marzo del 2013. http://docs.oracle.com/javaee/5/tutorial/doc/bnafe.html

2. (Cogorno 13) Cogorno. Cogorno Visitado el 02 de Marzo del 2013. http://www.cogorno.com.pe/

3. (Cogorno 13)Cogorno. Cogorno Blog Visitado el 02 de Marzo del 2013. http://cogornosperu.blogspot.com/

4. (Industry 12) Industry, I. A. International pasta Visitado el 10 de Marzo del 2013. http://www.internationalpasta.org/resources/report/IPOreport2012.pdf

5. (Kazan-Ergal-Alen-Tanriverdi 06) Kazan, H., Ergal, A., Alen, & Tanriverdi, H. ProQuest Central Visitado el 18 de Abril del 2013. http://search.proquest.com/docview/222859545?accountid=45097

6. (Lawrynowicz 08) Lawrynowicz, A. ProQuest Central Visitado el 26 de Abril del 2013. http://search.proquest.com/docview/231309357?accountid=45097

7. (Microsoft 13) Microsoft. 180

Microsoft Partner. Visitado el 12 de Marzo del 2013. http://msdn.microsoft.com/es-es/library/vstudio/hh425099.aspx

8. (Microsoft 13) Microsoft, C. LO4D Visitado el 18 de Marzo del 2013. http://en.lo4d.com/s/microsoft-.net-framework-v4.0.30319-indir

9. (ORTEMNS 12) ORTEMNS. ORTEMNS agile manufacturing software Visitado el 20 de Marzo del 2013. http://www.ortems.com/es-planificacion-programacion/soluciones/plannerone.php

10. (Portougal 05) Portougal, V. ProQuest Central Visitado el 08 de Marzo del 2013. http://search.proquest.com/docview/198655150?accountid=45097

11. (SISTRADE 12) SISTRADE. SISTRADE - Software Consulting, S.A. Visitado el 15 de Marzo del 2013. http://www.sistrade.com/es/Soluciones/mis-erp-sistrade-scheduling.htm

12. (Technologies 06) Technologies, B. Binary Technologies Visitado el 25 de Abril del 2013. http://www.b-technologies.com/aplicaciones.htm

13. (W3C 12) W3C. W3C 181

Visitado el 16 de Abril del 2013. http://www.w3.org/Style/Examples/011/firstcss.es.html#HTML

DOCUMENTOS IMPRESOS:

14. (Cogorno 06) Cogorno. Póliticas y procedimientos de producción. Lima, Callao, Perú, ene.01.2006

15. (CHAPMAN 06) CHAPMAN, S. N. Planificación y Control de la Producciòn. EE.UU,, 2006.

16. (Cojoc 13) Cojoc, M. Visually altering user controls in ASP.NET with . EE.UU, ago. 2013.

17. (Tejero-J 11) Anaya Tejero, J. J. Logística Integral: La gestión operativa de la empresa. Lima, Perú, 2011.

18. (Propia 13) Propia, A. Perú.

182

ANEXOS

183

ANEXO 01 Manual de Estándares

184

MANUAL DE ESTÁNDARES Este documento se encarga de pautar las reglas que se respetarán a lo largo del Proyecto de Tesis, así como la estética a seguir en los informes, con el fin de lograr que la documentación sea ordenada y de fácil mantenimiento. 1. Estándares de Documentación •

Los títulos y subtítulos serán escritos en negrita. Los títulos de cada capítulo serán en mayúsculas y los otros títulos tendrán sólo la primera letra de la palabra inicial será escrita en mayúscula.



El texto debe estar justificado.



El título principal de cada capítulo debe ser como sigue: EJEMPLO: CAPITULO 1



Arial 14, Negrita

El título principal de cada página a excepción de los capítulos debe ser como sigue: EJEMPLO: Resumen



Arial 14, Negrita

El sub-título de cada página debe ser como sigue: EJEMPLO: 1. Introducción 1.1 Propósito

Arial 12, Negrita Arial 12, Negrita

185



En la descripción de cada ítem se podrá hacer uso de viñetas, en el orden que sigue: Primer orden: Segundo orden: Tercer orden: EJEMPLO: •

Ítem Numero 1 o Ítem Numero 1  Ítem Numero 1



Desarrollo del documento

Arial 11, con interlineado 1.5.



Pie de página

Arial 10, en modo oculto.

EJEMPLO: Página 1

Confidencial



Encabezado o Primero  Nombre del proyecto  Tipo de proyecto o Segundo

Arial 20 Arial 10 Arial 10

EJEMPLO: Encabezado Primero: Titulo de la tesis Encabezado Segundo: Titulo de la tesis

Fecha

: 25/03/13

186

Paginación a partir de la primera página. El formato es el siguiente: “Página 1” •

Los ejemplos e información relevante será enmarcada por un cuadro de línea simple.

2. Estándares de Diseño - GUI •

Colores o Fondo blanco. o Borde plomo, o Cabecera roja.



Fuente o Letras del contenido las grillas: Times New Roman 10 o Letras de los títulos de las grillas: Times New Roman 10 o Títulos de los controles: Times New Roman 10 o Todas las letras usadas deberán ser mayúsculas a excepción de la cabecera de la página web. o El logotipo tendrá un tamaño de 18.5 y estará justificada a la izquierda.



Ventanas modales o Fuente  Times New Roman 10  Letras en mayúsculas o Color  Cuerpo blanco  Cabecera ploma  Pie plomo

187

3. Estándares de Análisis • •

No se hará uso de tildes. Las siglas a usar son como sigue:

Caso de Uso de Negocio

CUN

Caso de Uso de Sistema Actores (Business Actor)

CUS BA

Entidades (Business Entity) Diagrama de Casos de Uso de Negocio

BE DCUN

Diagrama de Casos de Uso de Sistema Especificación de Casos de Uso del Negocio

DCUS ECUN

Realización de Casos de Uso del Negocio Diagrama de estados

RCUN DE

Diagrama de Actividades de la Especificación del CUN Diagrama de Actividades de la Realización del CUN

DAE DAR

Diagrama de Actores del Sistema Diagrama de Modelo Conceptual

DAS DMC

Diagrama de Paquetes Diagrama de Objetos del Negocio

DP DON

Diagrama de Clases Diagrama de Clases de Análisis

DC DA

Diagrama de Secuencia de Análisis Diagrama de Secuencia de Diseño

DSA DSD

Diagrama de Componentes Diagrama de Despliegue

DC DD

Modelo Conceptual

MC

Modelo de Clases Persistentes

MCP

Entidades

E

Interfaces

I

Controladora

C

188



Todos los diagramas deben poseer título, donde la primera letra debe ser escrita en mayúscula y las demás en minúsculas, salvo palabras relevantes.



(Ejemplo: Caso de Uso) que comenzaran con letra mayúscula. Deberá ser incluido en el diagrama como una nota en la parte superior izquierda. EJEMPLO: Diagrama de Casos de Uso de Negocio “Registrar Programa”



El nombre de los paquetes serán escritos: la primera letra de cada palabra con mayúsculas. EJEMPLO: Actores Negocio



El nombre de los diagramas consistirá por las siglas del tipo de diagrama en mayúscula, underline y el nombre respectivo de éste (letra inicial en mayúscula y el resto en minúsculas). EJEMPLO: DCUN_Registrar_programa



El nombre de los actores y entidades consistirá por su prefijo seguido de un signo menos y seguido del nombre correspondiente. Si el nombre contiene más de una palabra, cada una de éstas comenzará con mayúscula. EJEMPLO: BA_Planificador



BE_Familia

Las Entidades del Negocio podrán ser identificadas de color celeste en los 189

diagramas.

4. Estándares de Base de Datos Se usará estándares específicos para nombrar las tablas y columnas de la base de datos, el conjunto de dichos estándares será llamado nomenclatura. De esta forma lograremos identificar rápidamente el contenido de las tablas y columnas, así como también lograremos recordar fácilmente sus nombres.

Estándares para nombrar objetos de la base de datos: El estándar general radica en que los nombres de los objetos solo podrán contener letras mayúsculas y serán de longitud de 5 caracteres. Nomenclatura A: El nombre de un objeto de la base de datos seguirá la siguiente estructura:

Donde: TP

:

Primer Prefijo

NOM

:

Nombre del objeto de la base de datos.

Primer Prefijo: Identificará las tablas del modulo de produccion: TP

:

Tabla Producción

Segundo Prefijo: identificará a las entidades NOM

:

Nombre de la tabla

190

Nomenclatura B: En caso se trate de una tabla que representa el detalle de otra tendrá el inicio del segundo sufijo con la palabra S y las dos letras finales serán el inicio de las dos primera letras del segundo sufijo de la alternativa A. Donde: TP

:

Primer Prefijo

S

:

segundo sufijo.

NO

:

Nombre del objeto de la base de datos.

Primer Prefijo: Identificará las tablas del modulo de producción: TP

:

Tabla Producción

Segundo Prefijo: identificará a las entidades S

:

Identificador de detalle

Tercer Prefijo: identificará a las entidades NO

:

Nombre de la tabla

191

Algunos de los prefijos identificados son: FAM

:

Objeto con información de las familias de producción.

MOL

:

Objeto con información de los moldes de producción.

LIN

:

Objeto con información de las líneas de producción.

TIP

:

Objeto con información de los tipos de artículos.

PRE

:

Objeto con información de las presentaciones de artículos.

ORI

:

Objeto con información de los orígenes de los artículos.

ENV

:

Objeto con información de los envases de los artículos

MAR

:

Objeto con información de las marcas de los artículos

SMA

:

Objeto con información de las sub marcas de los artículos.

STI

:

Objeto con información de los sub tipos de los artículos.

SFA

:

Objeto con información de las sub familias de los artículos.

ART

:

Objeto con información de los artículos.

Estándares para nombrar columnas Nomenclatura: El nombre de una columna de una tabla seguirá la siguiente estructura:

Donde: PPP NCO

: :

Primer prefijo. Nombre de la Columna.

192

Primer Prefijo: Identificará de que tabla procede la columna. Ejemplo: se tomará como referencia la tabla TPFAM. Prefijo FAM

:

Tipo

Procede de la tabla familia

Segundo Prefijo: Identificará el rol que cumple el atributo en la tabla. Prefijo DES

:

Tipo

Descripción de la familia

5. Estándares de Código Controles Web Tipo de Control Button

Prefijo btn

Ejemplo btnEnviar

Calendar

cld

cldCalendario

Checkbox

chk

chkAutorizaciones

CheckedListBox

lst

lstAutorizacionDelegados

GridView

gv

grvPrograma

DropDownList

cmb

ddlFamilia

HyperLink

hlk

hlkPagina

Image

img

imgImagen

Label

lbl

lblNombre

LinkButton

lnk

lnkButtonSitioWeb

RadioButton

rbtn

rbtnVerdadero

Table

tbl

tblClientes

TextBox

txt

txtNombre

ValidationSummary

vld

vldMensajes

193

Prefijos Objetos ADO.NET Tipo de Objeto

Prefijo

Ejemplo

Connection

cn

cnConexion

Command

cmd

cmdReporte

DataReader

dr

drCliente

DataAdapter

da

daConexion

DataSet

ds

dsCliente

DataTable

dt

dtProductos

Modelo Capas Capa

Descripción

Presentación

Las páginas comenzarán con el sufijo frm seguido del nombre específico del formulario. Ejemplo: frm_Registrar_version frm_Editar_version frm_Reporte_programa

Lógica del negocio

Solo existirán tres tipos de clases de lógica de negocio. Ejemplo: log_mantenimiento 194

log_lista log_ejecutar_programas Entidad de negocio

Tendrán el sufijo de E seguido del alias de cada entidad. Ejemplo: Efamilia EMolde EProgramaCabecera EProgramaDetalle

Acceso a Datos

Solo existirán tres tipos de clases de acceso a datos. Ejemplo: dao_mantenimiento dao_lista dao_ejecutar_programas

195

ANEXO 02 Manual de Instalación

196

MANUAL DE INSTALACIÓN REQUERIMIENTOS DE HARDWARE Servidor BD: Procesador: Intel de doble núcleo 2.20 GHz Memoria RAM: 2Gb Disco duro: 80GB Cliente Web: Procesador: Intel doble núcleo de 1.6 GHz Memoria RAM: 2Gb Espacio en disco: 2Gb Navegador Web: Internet Explorer 7, 8, 9,10, Mozilla Firefox.

REQUERIMIENTOS DE SOFTWARE Servidor bd: Sistema Operativo: •

Microsoft Windows 2003 o superior

Motor de Base de Datos: • AS 400 – DB2 • IBM I System access for windows version 6 release 1. Otros • •

Microsoft Frameworks 2.0, 3.0, 4.0. IIS 6 o superior

Cliente Web: Sistema Operativo: •

Cualquiera que soporte los navegadores Internet Explorer 7, 8, 9,10, Mozilla Firefox (Windows o Linux) 197

Primer paso Ubicar y Copiar el compilado generado en una carpeta compartida la cual será accedida desde el Servidor Web.

Figura 1 Nota: el compilado se ha generado desde la misma herramienta de visual studio.Net

198

Figura 2

Segundo paso Conectarse por algún medio al servidor Web. En este caso la conexión es vía conexión a Escritorio remoto. (utilitario Microsoft)

Figura 3 Luego ubicar la carpeta compartida donde se encuentra el compilado generado. 199

Figura 4

Tercer paso Copiar el contenido del compilado de la carpeta compartida.

Figura 5 Y pegarlo en la siguiente ruta del Servidor Web

200

Nota: previamente se debe tener configurado un directorio virtual en el sitio web del IIS, en nuestro caso el directorio virtual tienen por nombre producción.

201

ANEXO 03 Manual de Usuario

MANUAL DE USUARIO 1. INTRODUCCIÓN 202

Con el presente manual todo usuario que tenga acceso al sistema web será capaz de poder entender y aplicar cada funcionalidad que se le presente.

Logeo Para acceder al sistema web se deberá colocar el usuario, la contraseña y la librería donde se va trabajar. •

Usuario: asignado por el administrador web



Contraseña: asignado por el administrador web



Librería: o EM: librería de producción o PR: librería de pruebas. Enter o clic

203

Dar clic en el modulo de producción.

Cli c

Se muestra lista de opciones para los usuarios.

204

2. PLANEAR PRODUCCIÓN A continuación, la bandeja de entrada del responsable de planear la planificación de la produccion.

Como se visualiza, hay tres versiones BASE cada una le corresponde a una familia de producción distinta.

Registrar versión Si se desea registrar una versión se deberá copiar alguna versión base de una familia de producción ya registrada. Seleccionamos la versión base y le damos clic al botón copiar.

205

Cli c

En la ventana modal se deberá colocar lo siguiente: •

Versión: nombre provisional de la versión a trabajar



Comentario: un comentario referente a la versión a trabajar.

Finalmente presionamos el botón celeste y nos mostrará un mensaje de confirmación, el cual le damos aceptar.

Cli c

206

Versión creada.

Editar versión Si se desea editar alguna versión registra, tan solo se deberá seleccionar dicha versión el presionar el botón editar

Cli c

207

Antes de comenzar a programar la producción hay que tener las siguientes consideraciones:



Seleccionar la semana de producción.



Seleccionar la línea de producción



Seleccionar si se desea cargar el estimado de ventas. La carga la realiza el sistema y programa los artículos según disponibilidad de tiempos en las líneas de produccion.

Sema na

Líne a Car ga

En caso que el usuario seleccione la carga estimada

El Excel es escaneado y analizado por el sistema web:

208

Y cargará el Excel a la grilla.

209

En caso que el usuario no seleccione la carga estimada

El programador de la producción deberá seleccionar los artículos que desea programar y apoyarse de las herramientas que le brinda el sistema web para una fácil programación.

Arrastrar y soltar articulo

Clic derecho sobre el ítem y se mostrará un menú contextual.

210

Clic derecho

Menú contextual: •

Inicio: marca el inicio desde donde se desea copiar



Fin: marca el fin hasta donde se desea copiar



Copiar: opción pegar contenido.



Cortar: opción cortar contenido



Correr: ventana modal: se deberá indicar la cantidad de horas a copiar o sobre escribir. o Correr: si encuentra artículos delante estos correrán las mismas horas que faltan por copiar. o Sobre escribir sobre escribirá los artículos que tenga por delante o Detener: si encuentra algún artículo delante se detendrá.



Borrar: borrar ítem seleccionado 211



Ayuda: descripción del artículo.

Cli c

En está ocasión se mostro la opción de sobre escribir.

212

Nota 1: tener presente que se podrá programar para 4 semanas consecutivas en la misma grilla.

213

Nota 2: tener presente que se existe opciones adicionales. •

Copiar semana



Calculo de horas de producción.



Exportar Excel.

Copiar semana

Calculo de horas de producción

Cli c

Cli c

Publicar versión

Seleccionar alguna versión previamente trabajada y dar clic en Publicar. El sistema mostrará una ventana modal en la cual se le solicitará seleccionar lo siguiente: 214



Semana: semana en la que entrará en producción el programa.



Día: día en que el programa entra en producción.

Finalmente, clic en ejecutar.

Cli c

Y seleccionamos el botón aceptar.

Cli c

215

La versión quedará en estado por aprobar. Se les enviará una alerta (mail) a cada responsable de la familia de producción ara la aprobación o rechazo del programa.

Nota 1: si se deseará hacer un seguimiento a la versión publicada se deberá dar clic en el botón ESTADO. Como se muestra en la ventana modal, tan solo existe un responsable de la familia de producción fideos el cual su aprobación está en estado de espera.

216

Eliminar Versión Si se desea eliminar alguna versión, está tan solo podrá ser posible en estado registrado.

Cli c

Finalmente, clic en aceptar.

217

Cli c

Mover Versión El sistema brinda la posibilidad de tener dos bandejas, una real y la otra histórica, la primera se refiere a la versiones con las cuales se está trabajando y la segunda guarda las versiones que ya no se usan, pero que se guardan en un histórico para luego tentar la posibilidad de volver a usarlas (copiarlas)

El sistema solicitará los siguientes datos: •

Versión: versión con la cual será movida al histórico.

218

Cli c

El sistema traslado la versión al histórico

Nota 1: si se desea mover la versión del histórico al real el procedimiento tan solo variará en que moveremos desde la bandeja del histórico. 219

Aprobar Versión

Una vez lanzada a publicación la versión está tendrá que ser aprobada o rechazada por los responsables competentes a la familia involucrada directamente con la versión.

Para ver el detalle de lo que se programado, se deberá seleccionar una línea de producción y seleccionar filtrar

Clic

220

En caso se rechace la versión El responsable deberá enviar un mail a todos los responsables expresando su motivo. El programador tendrá que ajustar el programa para su puesta en publicación posteriormente.

En caso se apruebe la versión Mensaje de confirmación y se pulsa aceptar

221

Si todos los responsables aceptaron la versión, esta pasa a producción. A cada responsable le llega una alerta (mail) de puesta en produccion del programa.

Finalmente, la se muestra la aplicación ya publicada.

222

3. CONTROL CALIDAD Se muestra la lista con la versión base asignada al responsable del área de calidad.

Para programar controles de calidad para una línea de produccion se deberá seleccionar la versión base y presionar el botón control.

Clic

Se deberá pulsar y arrastrar la restricción hacia la hora indicada y finalmente dar clic en guardar.

223

Cli c

4. MANTENIMIENTO PLANTA

Se muestra la lista con la versión base asignada al responsable del área de calidad.

Para programar mantenimientos de planta para una línea de produccion se deberá seleccionar la versión base y presionar el botón control.

224

Se deberá pulsar y arrastrar la restricción hacia la hora indicada y finalmente dar clic en guardar.

Cli c

Nota 1: en caso ya existan restricciones por el área de control de calidad, ya no se podrán usar dichas horas debido a que el sistema bloquea las horas reservadas por dicha área.

225

Nota 2: cuando el programador registra versiones, se puede dar el caso que encuentre horas reservadas (el sistema bloquea el ítem en la hora reservada) por control de calidad y mantenimiento.

5. REPORTES Este reporte es usado tanto por los programadores como por los responsables de cada familia de produccion, y por el personal de planta.

En el siguiente: se cuadro se muestra las cantidades a producir en un determinado intervalo de horas para una línea de produccion y semana especifica.

226

227