Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS01/MemoriadeTrabajode... · Web...

CIS1430IS01Reprocesos GMO: Una automatización de los procesos de devolución, en búsqueda de aumentar

su eficiencia en la empresa

ALEXANDRA ARDILA SARMIENTO

PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

2014

Pontificia Universidad Javeriana Memoria de Trabajo de Grado - Aplicación Práctica

CIS1430IS01Reprocesos GMO: Una automatización de los procesos de devolución, en búsqueda de

aumentar su eficiencia en la empresa

Autor(es):

Alexandra Ardila Sarmiento

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Andrés Gómez Idárraga

Jurados del Trabajo de Grado

ANGELA CARRILLO RAMOS

MARIA CONSUELO FRANKY

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1430IS01/


CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

Diciembre 21 de 2014

Página1

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

http://pegasus.javeriana.edu.co/~CIS1430IS01/

Ingeniería de Sistemas <Istar- <Código>


CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Jorge Humberto Peláez Piedrahita, S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Decano del Medio Universitario Facultad de Ingeniería

P. Antonio José Sarmiento Nova, S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera

Página2


Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

Página3



AGRADECIMIENTOS

Los agradecimientos se quedan cortos al lado del interminable apoyo que he recibido para culminar este sueño que por varios momentos pensé dejar a un lado, fue solo el amor y dedicación de aquellos que siempre han estado a mi lado, lo que me hizo tener la fuerza suficiente para decidir darme cuenta de que si soy capaz de lograr cualquier cosa que me propongo.

A mi mama, por ser la mujer más increíble del mundo, por inspirarme con su dedicación, por ser un ejemplo de lucha y de profesionalismo, por ser siempre la mejor en su carrera y en todo lo que se propone, y sobre todo, por no haber dudado de mí y de mis cualidades, ni por un segundo, igual que mi padre, del que nunca recibí un regaño a pesar de mis mil errores, el que siempre me apoyo mental y económicamente a pesar de que sabía que era solo mi responsabilidad el que esto se alargara por tanto tiempo, gracias a él también por ser el mejor ingeniero que puede existir, por heredarme su gusto a esta linda profesión y su amor a las matemáticas. Gracias a los dos por siempre darme el primer lugar por encima de ellos, por estar siempre ahí sin juzgarme, solo intentando que saliera adelante, apoyándome bajo cualquier circunstancia, los amo, son increíbles, los mejores que existen en el mundo y perdón por tanto.

A mis hermanitos amados, porque tuvieron que lidiar con esto por tanto tiempo, por aguantarme, y no estar en mi contra a pesar de todo.

Gracias a todos mis compañeros de carrera, porque aunque no soy muy apegada a ellos, cada uno marco una etapa fundamental en mi vida.

Por último gracias a Juan Miguel, por ayudarme a tomar la decisión de enfrentarme a mis miedos y haber estado a mi lado ese día dándome esa fuerza que me faltaba.

Gracias a todos, especialmente a mi adorada familia, sin ustedes nada de esto hubiera sido posible.

Página4


CONTENIDO

CONTENIDO...............................................................................................................5

I - INTRODUCCIÓN..................................................................................................9

II - DESCRIPCION GENERAL..............................................................................10

1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES..........................................101.1. Formulación del problema que se resolvió............................................................111.2. Justificación del problema......................................................................................121.3. Impacto Esperado...................................................................................................12

2. DESCRIPCIÓN DEL PROYECTO..........................................................................132.1. Objetivo general......................................................................................................132.2. Objetivos específicos...............................................................................................13

3. METODOLOGÍA.................................................................................................14

4 – MARCO TEORICO............................................................................................17

III - CONTRIBUCIONES.........................................................................................20

1. ANÁLISIS DEL SOLUCIONES EXISTENTES Y HERRAMIENTAS...........................201.1. Análisis de Soluciones Existentes...........................................................................201.2. Selección de Herramientas.....................................................................................22

2. DESCRIPCIÓN DE LA SOLUCIÓN........................................................................272.1. Requerimientos funcionales:.......................................................................................272.2. Requerimientos no funcionales:..................................................................................282.3. ANALISIS...................................................................................................................302.3.1. Diagrama de clases..................................................................................................422.3.1.1. Diccionario de las clases......................................................................................432.3.2. Diagramas de caso de uso.......................................................................................542.4. DISEÑO.....................................................................................................................762.4.1. Requerimientos del sistema:....................................................................................772.4.1.1. Requerimientos del Hardware:.............................................................................772.4.1.2. Requerimientos del Software:...............................................................................782.4.2. Diagrama de despliegue..........................................................................................81

3. RESULTADOS....................................................................................................82

Página5



4. ANÁLISIS DE IMPACTO DEL DESARROLLO.......................................................90

5. CONCLUSIONES.................................................................................................91

IV- REFERENCIAS Y BIBLIOGRAFÍA...............................................................93

IV - ANEXOS.............................................................................................................96

ANEXO 1. GLOSARIO....................................................................................................96

ANEXO 2. DIAGRAMA DE FLUJO DEL SISTEMA.............................................................96

ANEXO 3. DESCRIPCIÓN DE LAS TABLAS DEL MODELO ENTIDAD-RELACIÓN..............96

ANEXO 4. MODULO GARANTÍAS MERMAS....................................................................96

ANEXO 5. PANTALLAZOS SISTEMA DE INFORMACIÓN.................................................96

ANEXO 6. VIDEO SOBRE FUNCIONAMIENTO DEL SISTEMA DE INFORMACIÓN..............96

ANEXO 7. PRESENTACIÓN PROPUESTA.........................................................................96

ANEXO 8. VALORES DE TABLAS...................................................................................96

ANEXO 9. PRUEBAS UNITARIAS....................................................................................96

ANEXO 10. ACTAS DE REUNIONES...............................................................................96

ABSTRACT

In GMO had a problem for some time, the reason was a sales company where mistakes and disagreements were generated in the product that is sold to the customer, why should be void and then make again, taking careful not affect accounting, inventory or invoices.

Previously this was done via email, filling out forms on Excel, Making calls between the persons involved, and no track record or is not handling the entire process through which must pass, creating problems of delays in different areas, triggering unrest on customers and on occasion, the request for the return of the money.

The solution to this problem was to build a web tool that will interact with the Gesti-optics application, which stores in the database all the information required for customer complaints that express power and Give them the best after-sales service.

Página6


RESUMEN

Desde hace un tiempo en GMO existia una dificultad, el motivo se asociaba a aquellas ventas de la empresa donde se generaban errores e inconformidades en el producto que se le ofrece al cliente, motivo por el cual se debía anular y posteriormente volver a realizar, teniendo mucho cuidado de no afectar la contabilidad, el inventario o las facturas.

Anteriormente todo esto se realizaba a través de correos, llenando formularios en Excel, haciendo llamadas entre las personas implicadas, y no se manejaba ningún registro o seguimiento a todo el procedimiento y el flujo por el que debe pasar, generando problemas de retrasos en las diferentes áreas, desencadenando malestar en los clientes y en ciertas ocasiones, la solicitud de la devolucion del dinero.

La solución a este problema fue la construcción de una herramienta web que interactuára con la aplicación Gesti-Ópticas, la cual almacena en la base de datos toda la información requerida para las inconformidades que expresan los clientes y poder brindales el mejor servicio post-venta, tanto a ellos como a los asesores de las tiendas, quienes son el usuario final a usar el aplicativo

Página7



Página8


I - INTRODUCCIÓN

El proyecto “Reprocesos GMO” es una idea que nace tras 6 meses de trabajo, al encontrar la manera de optimizar el proceso de garantías.

En GMO un reproceso es aquel pedido de error o inconformidad por parte del cliente al adquirir un producto, motivo por el cual se debe anular y posteriormente volver a realizar, todo esto sin que este paso afecte ningun otro proceso dentro del sistema de la empresa, tales como la contabilidad, el inventario,etc.

Todo esto origina retrasos en las diferentes áreas, por lo que puede verse afectada la producción y distribución de dichos encargos, desencadenando malestar en los clientes y en ciertas ocasiones, la solicitud de la devolución de su dinero. Para la empresa como tal conlleva a un efecto negativo en el nombre de la marca así como una baja en las ventas actuales.

Por estas razones, mejorar y sistematizar todo este procedimiento, implicó todo un beneficio para todas las areas de la empresa, al ser el area de TI la encargada de ejecutar actualmente todos los pasos, llevó a cabo la construcción de una herramienta web que interactua con la aplicación Gesti-Ópticas.

Esta es una herramienta de fácil manejo que ayuda a mejorar el procedimiento que se ejecuta para “Reprocesos GMO” buscando con este agilizar, ordenar y estandarizar el proceso, además de disminuir la posibilidad de errores que se presentaban anteriormente en él, tales como el envío de información incoherente y duplicación de reprocesos, también permitirá el seguimiento en todas las etapas de cada reproceso. Esto conlleva a la optimización del proceso, que mejora el cumplimiento de las entregas reprocesadas.

Una de las ventajas más significativas de este desarrollo es la facilitación de los reportes, a través de business Intelligence [1] se podrán ver cuáles son las principales causas de los reprocesos, Las áreas, tiendas o asesores que recurren más a estos. Las diferentes áreas pueden solicitar diferentes reportes sobre este proceso, que ayuda a definir diferentes decisiones y situaciones que se presentan.

Toda esta situación anterior impacta enormemente en la satisfacción del cliente, porque recibe en el tiempo adecuado aquellos encargos reprocesados, tanto aquellos en los cuales la responsabilidad sea de él o como aquellos en los que la responsabilidad sea de la empresa, y esta satisfacción se verá reflejada en la reducción de devoluciones, que representa un aumento neto de capital en las ventas definitivas de la empresa.

Página9



Página10


II - DESCRIPCION GENERAL

1. Oportunidad, Problemática, Antecedentes

El proyecto “Reprocesos GMO[2]” fue una idea que nació a raiz del trabajo que se tuvo dentro de la compañia,Y donde se encontró una manera de optimizar un proceso que se hacia dia a dia de manera mecánica.

En GMO un reproceso es aquella venta de la empresa, que por razones, que se explicaran mas adelante detalladamente, tiene algun error o inconformidad, motivo por el cual se debe anular y posteriormente volver a realizar, todo esto sin que este proceso afecte ningun otro proceso, tales como la contabilidad, el inventario o las facturas.

Anteriormente todo esto se realizaba a traves de correos, llenando formularios de excel, llamadas entre las personas implicadas, y no se manejaba ningun registro o seguimiento a todo el ciclo por el que debia pasar.

Todo esto originaba retrasos en las diferentes areas de la compañía, por lo que se veia afectada la produccion y distribucion de dichos encargos, desencadenando malestar en los clientes y en ciertas ocasiones, la solicitud de la devolucion de su dinero.

Era entonces un proceso que aunque tiene mucha importancia en la compañía, se hacia manera desordenada y conllevaba a un efecto negativo en el nombre de la marca asi como una baja en las ventas actuales.

Por estas razones, mejorar y sistematizar todo este procedimiento, implicó consecuencias positivas para todas las areas de la empresa, y al ser el area de TI la encargada de ejecutar anteriormente todos los pasos, fue una de las mas beneficiadas, ya que esto facilitó y ahorró horas de trabajo a las personas encargadas de realizar estos procedimientos, todo esto a través la construcción de una herramienta web que interactua con la aplicación Gesti-Ópticas( herramienta actual de la compañía, que maneja una gran parte de los datos de esta).

Esta propuesta busca tambien que en las fases posteriores se pueda usar la informacion que se guarda en las bases de datos, para poder sacar diferentes analisis de desempeño tanto de las areas internas de la empresa como las diferentes sucurcales que hay en el pais, buscando consigo grandes beneficios que puedan verse reflejado en la satisfaccion de los clientes asi como mas adelante, en las ventas netas de la empresa.

Página11



1.1. Formulación del problema que se resolvió

¿Cómo puede la empresa Ópticas GMO, desde el área de sistemas y mediante un sistema de información, mejorar, acelerar y rastrear que los reprocesos se hagan debidamente y bajo los tiempos correctos?

¿Fue posible usar la información que se recolectaba en este proceso, mejorar la calidad y el tiempo en la entrega de reprocesos, así como método de prevención para disminuir que se sigan dando estos errores?

Estudiando el caso actual se observó cómo se presentaba en GMO este proceso, y se decidió plantear tres diferentes fases de desarrollo para este proyecto, Obteniendo las siguientes fases.

1. Fase desarrollo aplicativo funcional: En esta fase se dejó elAplicativo funcionando al desarrollado, cubriendo el proceso actual en un 100%, el aplicativo facilitó el orden y seguimiento a los reprocesos, y toda la información fue guardada en una base de datos creada para este fin.

2. Fase desarrollo de reporteria: Como anteriormente no se contaba con un registro de todos estos reprocesos, y la información que existía era almacenaba en diferentes archivos, de manera desordenada y bajo ningún estándar, los análisis que se pudieron hacer fueron muy escasos.

En esta segunda fase se desarrollaron reportes que analizan las cifras Algunas otras estadísticas, estos reportes sirven para las diferentes áreas de la compañía, ya que la mayoría están involucradas en todos los campos, se lleva registro histórico de todo lo que pase en este proceso.

3. Fase desarrollo orientado al Business Intelligence:

Gracias a las anteriores fases, se buscan las herramientas necesarias, para transformar los datos en información, cuestión que será útil para la compañía, y ayudara en el objetivo final de dar mayor satisfacción al cliente. Esta fase de Business Intelligence se planteó de manera abierta, ya que es necesario tener desarrolladas las dos fases anteriores, para poder realizarla a futuro.

Página12


1.2. Justificación del problema

Requieren los diferentes usuarios internos de la compañía consultar los reprocesos que se ingresan y a su vez saber el estado actual de estas, así como requieren las áreas encargadas del proceso, analizar y comprender la información recopilada durante sus operaciones, es entonces como el trabajo de grado propuesto busca hacer posible tales operaciones de forma eficiente y correcta así como lograr un acceso completo y fácil de usar, que le brinde a la organización una ventaja competitiva, al transformar la información almacenada en conocimiento accesible a sus miembros.

1.3. Impacto Esperado

Se propuso entonces, a partir de la experiencia acumulada en estos meses de trabajo en la compañía y de los grandes posibles beneficios que ven las diferentes áreas involucradas en este proyecto, desarrollar una herramienta de fácil manejo que pudiera mejorar el procedimiento que se ejecuta para “Reprocesos GMO” buscando con este agilizar, ordenar y estandarizar el proceso, además de disminuir la posibilidad de errores que se presentaban en él, tales como el envío de información incoherente y duplicación de reprocesos, como también el seguimiento en todas las etapas de cada reproceso.

Todo esto, como se mencionó en numerales anteriores, conlleva a la optimización del proceso, que ayuda a mejorar el tiempo y el cumplimiento de las entregas reprocesadas.

Con las siguientes fases de desarrollo se busca facilitar los reportes y las herramientas necesarias, para prevenir los problemas que anteriormente se presentaban, no a nivel del proceso, sino poder identificar las causas para que se presenten todos estos inconvenientes, es decir, a través de Business Intelligence ver cuáles son las principales causas de los reprocesos, las áreas, tiendas o asesores que recurren más a estos. Viendo también como se vaya dando el desarrollo de la aplicación, las diferentes áreas podrán solicitar diferentes reportes sobre este proceso, que ayuden a definir diferentes decisiones y situaciones que se presenten, todo esto bajo un alcance real bajo el tiempo del trabajo de grado.

Todo esto busca impactar de manera final, en la satisfacción del cliente, quien podrá recibir en el tiempo adecuado aquellos encargos reprocesados ya sea por su culpa o por culpa de la compañía, y esta satisfacción se verá traducida en la reducción de devoluciones, que representa el aumento neto de capital en las ventas definitivas de la empresa.

Página13



2. Descripción del Proyecto

2.1. Objetivo general

Desarrollar e implementar una herramienta web que sistematice y automatice los “Reprocesos” que usa la empresa GMO, buscando convertir este proceso, en uno más confiable, rápido y estructurado.

2.2. Objetivos específicos

Objetivos específicos:

1. Crear un aplicativo Web que sustituya y automatice el proceso manual con el que se trabajan los “Reprocesos GMO”.

2. Diseñar e implementar un sistema de información web que sostenga el aplicativo inicial, y que a la vez permita ser consultado a través de un módulo de reportes.

3. Construcción de un módulo de reportes, que permitan a la empresa consultar los estados actuales y resultados de los reprocesos, esto con el fin de mejorar el funcionamiento involucrado a reprocesos de cada área.

4. Determinar el impacto del uso del aplicativo web, mediante datos históricos del actual proceso, y los nuevos resultados una vez esté implementado este.

El objetivo específico de realización de en un aplicativo WEB contará con la ayuda y seguimiento de las siguientes áreas relacionadas en GMO Colombia: Área de TI como principal involucrado, Área Comercial, Centro de Distribución y tiendas. Se cuenta con la aprobación del jefe de Sistemas Daniel Troncoso, para la implementación de este aplicativo, así como con el visto bueno de todas las demás áreas involucradas.

Las fases que se llevaran a cabo son:

Fase 1 (Investigación especulativa):

Página14


- Recolectar la información requerida del proceso actual, para la creación del aplicativo, de modo que no se omita ningún detalle del proceso manual que se ejecuta actualmente.


- Diseñar las diferentes clases y estructuras necesarias (diseño) para la respectiva construcción del aplicativo web.

Fase 3 (Inducción):

- Construir el aplicativo web que permita acceder a los usuarios al proceso automatizado, así como a diferentes reportes estadísticos y de resultados del aplicativo.

Fase 4 (Experimental):

- Validar por medio de pruebas con todos los usuarios, que el proceso haya sido reemplazado en su totalidad, funcione correctamente, y las personas se hayan adaptado a este.

3. Metodología

Las fases que se llevaran a cabo son:

1.1 Fase Metodológica 1


Recolectar la información requerida del proceso actual, para la creación del aplicativo, de modo que no se omita ningún detalle del proceso manual que se ejecuta actualmente [3].

Metodología:

1. Investigación basada y apoyada en los actores de las áreas que interactúan en este proceso, las variables que afectan en él y el proceso que se ejecuta actualmente.2. Relacionar las variables encontradas entre sí.

Página15



3. Acotar que variables se manejarán para este modelo, cuales tienen verdadera utilidad en este aplicativo.4. Definición de pasos que son estrictamente necesarios en el proceso, y de cuales pueden optimizarse,5. Construcción de documento explicando las metas planteadas definitivas para este aplicativo web.6. Investigar y definir el software que será usado para la construcción del portal, sus ventajas y diferentes impactos



Diseñar las diferentes clases y estructuras necesarias (diseño) para la respectiva construcción del aplicativo web.

Metodología: 1. Investigación sobre las diferentes estructuras de almacenamiento que puedan usarse en la construcción del aplicativo, y ver su impacto en la eficiencia de este.2. Construir las diferentes estructuras de almacenamiento. 3. Realizar los correspondientes diagramas de clases, casos de uso, y otros diagramas que sean necesarios para el proyecto. 4. Construir modelo general definitivo con la definición de las diferentes estructuras de almacenamiento y clases, que serán usadas para la creación del portal web.


Fase 3 (Inducción):

Construir el aplicativo web que permita acceder a los usuarios al proceso automatizado, así como a diferentes reportes estadísticos y de resultados del aplicativo [4].

Metodología:

Esta fase contendrá 3 fases o momentos internos, fase desarrollo aplicativo funcional, fase desarrollo de reporteria y Fase desarrollo orientado al Business Intelligence, los cuales fueron descritos en este documento en la sección de formulación de este

Página16


trabajo de grado (1.1), cada uno de estos seguirá la siguiente secuencia de pasos, e irán desarrollándose una después de la otra:

1. Construcción inicial bajo los parámetros tenidos en cuenta en las fases anteriores. 2. Pruebas sobre el prototipo inicial logrado. 3. Revisión junto a las personas de todas las áreas involucradas sobre el prototipo.4. Corrección de errores y mejoras sobre el prototipo inicial.5. Lanzamiento en vivo de fase correspondiente.


Fase 4 (Experimental):

Validar por medio de pruebas con todos los usuarios, que el proceso haya sido reemplazado en su totalidad, funcione correctamente, y las personas se hayan adaptado a este.

Metodología: 1. Comparación entre el nuevo prototipo y los requerimientos esperados en el documento inicial.2. Mejoras finales.3. Construcción del documento definitivo y la correspondiente memoria de grado.

La metodología técnica que ya se usó en este desarrollo, se podrá visualizar en el anexo 11. Metodología Aplicada.

Página17



4 – MARCO TEORICO

GMO es una empresa especialista en gafas de sol y ópticas, es marca líder en Latinoamérica, su mercado está orientado a cuidar la salud visual, y se distribuye sobre los países con una red de tiendas por las principales ciudades.

En Latinoamérica GMO empezó su mercado en Chile, en el año de 1999, y llego a Colombia bajo el año 2006, siendo en este momento propiedad de una franquicia española llamada MultiOpticas.

A partir de mediados del 2011, Luxottica Group adquiere el 97% de participación en la propiedad de la franquicia MultiOpticas, por lo cual GMO pasa a ser parte de su propiedad.

Es Luxottica Group una importante multinacional Italiana, con presencia en más de 130 países en el mundo, es la mayor compañía de gafas del mundo, controla además las principales marcas de gafas del mundo, Sus marcas propias más conocidas son Ray-Ban, Persol y Oakley [26]. También produce gafas de sol y gafas graduadas para marcas de diseñadores como Chanel y Prada, se usan bajo licencia [27].

Fue entonces este cambio de propietarios, un paso muy significativo para la empresa, que implicaba consigo mismo una probabilidad muy alta de expansión, crecimiento y desarrollo.

"Chile y América Latina, en general, representan una región estratégica para el desarrollo de Luxottica y estimamos un significativo crecimiento en los próximos años", dijo Alberto Fernández, Gerente General de GMO Chile [25].

Este cambio traía consigo una serie de cambios que implicaban en la empresa ponerse al margen de las últimas tecnologías tanto para ópticas como para grandes empresas en general.

A nivel de Latinoamérica, GMO tiene presencia en Perú, Chile, Ecuador, Colombia con más de 320 tiendas, y a nivel Colombia cuenta con más de 70 de ellas.

Para conocer más sobre el planteamiento de GMO en Colombia remitámonos a su misión, visión, filosofía y valores corporativos:

Página18


Misión: Satisfacer las necesidades visuales de todas las personas a través de soluciones técnicas y estéticas.

Visión: Consolidarnos como la primera empresa en tamaño y cobertura a nivel nacional, y ser la marca de mayor prestigio, por su responsabilidad, calidad y servicio, en el mercado óptico de Colombia.

Nuestra filosofía: GMO ofrece soluciones básicas en salud visual, a personas de todos los niveles socioeconómicos y culturales y de todas las edades, a través de puntos de venta ubicados en las principales ciudades del país, donde un excelente equipo humano capacitado, asesora con calidez a nuestros clientes, ofreciendo el producto que más le conviene al cliente.

Nuestros valores corporativos:

Actitud: Ofrecer a nuestros clientes un rato amale, acogedor y personalizado. “Un servicio diferente”.

Ámbito: El diseño de nuestras instalaciones es moderno y acogedor, la distribución interna de las tiendas permiten que el cliente se sienta cómodo y especial; es “Un lugar pensado para entenderlo a usted”.

Accesibilidad: GMO ofrece variedad de productos y servicios, diferentes formas de pago, ubicación estratégica, precios al alcance de todos, horarios flexibles de atención al público. “TODO AL ALCANCE DE TODOS”

Pertenencia a la organización: Cumplimiento de principios, amor y entrega a la compañía.

Aptitud: Contar con la disposición y desempeño para hacer las cosas.

Trabajo en equipo: Enfocados todos hacia el mismo norte con el fin de lograr el objetivo estratégico de la compañía.

Responsabilidad: Dar respuesta por mis actos asumiendo las consecuencias.

Disciplina: Actuar dentro del orden establecido por la compañía siendo perseverante para encontrar un resultado.

Página19



Es entonces como el marco de toda la filosofía de GMO Colombia, y de los cambios que traen consigo una expansión como la que empieza Luxottica Group, que se maneja el contexto ideal para un proyecto como el que se desarrolló a través de este semestre, y que a través de esta memoria de grado será explicado y adaptado a la realidad y actualidad de la compañía.

Página20


III - CONTRIBUCIONES

1. Análisis del Soluciones Existentes y Herramientas

1.1. Análisis de Soluciones Existentes

Después del levantamiento de los requerimientos se empezó a establecer un horizonte que contemplaba la idea para cubrir la necesidad que se presentaba en la empresa, en este caso se examinó como primera manera recurrir a la compra de un software que permitiera gestionar de forma correcta las mermas y las garantías, se investigaron varias opciones, entre ellas están las siguientes:

Vertis Software

Vertis es un software desarrollado con el objetivo de, básicamente y de la forma más eficaz, ayudar en la gestión del retorno de las mercancías en la cadena de suministro, y todo ello buscando el precio más económico [5].

El módulo para devoluciones desarrollado por el Grupo V10 bajo el nombre comercial Vertis, es la solución para gestionar las devoluciones en una empresa.

La experiencia acumulada de 15 años en el sector farmacéutico sitúa el software como especialista en el suministro de sistemas de trazabilidad, control de lotes, devoluciones, fechas de caducidad y números de serie.

El software gestiona los procesos de retorno de excesos de inventario, devoluciones de clientes, productos obsoletos e inventarios estacionales.

La forma de presentar este software consiste en tener una sostenibilidad que permite crear relaciones estables a largo plazo con nuestros clientes, empleados y proveedores. Determinados clientes tienen necesidades muy particulares que el producto estándar no cubre. En estos casos, V10 tiene la agilidad, capacidad y experiencia para atender a tal necesidad y desarrollar ingeniería electrónica a la medida.

Vertis [6] estandariza las tareas de repaso de los retornos de mercancías, racionaliza las operaciones de las devoluciones, disminuye la complejidad de la gestión del retorno de las mercancías, facilita la gestión administrativa de las devoluciones.

Página21



Gestión de garantías RMA

RMA es un desarrollo web para simplificar la interacción con sus clientes y gestionar su logística reversa internacional de la manera más eficiente [7].

El sistema permite a sus clientes-consumidores finales cargar solicitudes de cambio por productos bajo garantía, así como realizar un seguimiento de los casos generados y actualizarlos.

La interfaz permite también la administración de un stock de productos, la generación de reportes exportables en formato CSV [24] y la posibilidad de configurar distintos usuarios administradores, con niveles de acceso diferenciado.

En toda instancia del proceso RMA brinda herramientas para mantener a sus clientes satisfechos, así como permitir la gestión eficiente de las devoluciones y solicitudes de cambio de producto.

Características principales:

Control de garantías por número de serie Recepción del producto averiado Generación del comprobante justificante de recepción al cliente Abono, sustitución o reparación del mismo Generación del documento correspondiente Movimientos de stock correspondiente en caso de que corresponda Generación del envío al proveedor según el número de RMA[8]

Las opciones anteriores se observaron con la intención de hacerles un pequeño seguimiento y verificar si se podía tomar la determinación de adquirir cualquiera de estos dos productos, se podía observar que aunque estos dos software que nos ofrecía el comercio web eran muy completos y en cierta manera podía cubrir en un alto porcentaje las necesidades de la empresa en ese momento, hubo ciertos puntos que llevaron a la idea de no adquirirlos, teniendo encuentra la opinión de los empleados que manejaban el sistema actual de la empresa; estospuntos son los siguientes:

1. Comprar un producto nuevo implicaba tener que volver a capacitar a todos los empleados de la empresa, puesto que iba a ser un software completamente nuevo, con instrucciones distintas al software que siempre ha funcionado en la empresa y que ya estaban acostumbrados a manejar, y el proceso de capacitación en tiempo y dinero iba a ser mayor.

2. El departamento de sistemas de la empresa buscaba que su sistema de información fuera modular, quiere decir que no se manejaran diversos sistemas de software independientes, sino que el sistema que tienen

Página22


actualmente pudiera subdividirse por módulos y pudiera ir creciendo con el tiempo.

3. Como toda empresa siempre se piensa primero en el factor económico antes de determinar qué productos le pueden servir a la empresa y que no salga tan costoso, obteniendo así una buena combinación entre el costo vs beneficio [9].Así pues luego de pensar bien los argumentos que se tenían anteriormente, se notó más eficaz construir propiamente la herramienta que pudiera ser modular al sistema que actualmente se trabaja, con una sistema de manejo similar al software que se encuentra actualmente trabajando y también que saliera más económica la inversión.

1.2. Selección de Herramientas

En el momento que se pensó en el lenguaje de programación, la decisión que se tuvo que tomar no fue tan difícil, puesto que como se anotó anteriormente, la empresa decidió que la parte que había que desarrollar nueva fuera un módulo del sistema completo que había en el momento, el cual está desarrollado en el lenguaje de programación PHP[10] con motor de base de datos MYSQL, sin embargo, si se pensó previamente en otros lenguajes de programación, como java y .net[20], y también se hizo una completa comparación acerca de la ventaja de usar PHP sobre las otras herramientas para este proyecto.En este caso se va a comparar PHP frente a JAVA y lo mismo con .NET

PHP frente a JAVA:

PHP fue creado específicamente para la web, como un lenguaje de script del lado servidor para incrustar en páginas HTML, mientras que Java fue inicialmente destinado para el software cliente y applets en el navegador y ahora es además una infraestructura clave para muchas aplicaciones web[11].

Java es construido sobre tipado estático (las variables deben tener un tipo declarado). PHP usa tipado dinámico (las variables asumen el tipo del valor más recientemente contenido en ellas y pueden cambiar su tipo para satisfacer casteos o conversiones implícitos). Ambos lenguajes tienen tipos primitivos[13].

Después de la versión de PHP 5, un punto clave en la introducción de un paradigma de objetos serio, PHP está evolucionando hacia la programación orientada a objetos y ha tomado más de los productos java. Por su parte, Java fue creado bajo el paradigma orientado a objetos desde su origen[22].

Las clases, funciones y estructuras de datos PHP, cuando no emplean infraestructura externa como cachés o bases de datos, son creadas en un script y son desechadas al final de la solicitud. Las aplicaciones Java por su parte se mantienen en memoria entre solicitudes. PHP trae a ejecución solo lo que necesita, y se paga con la incapacidad de correr tareas periódicas. Las

Página23



aplicaciones Java pueden iniciar múltiples hilos, pero su gestión es mucho más compleja [17].

PHP es simple para desplegar en su forma básica (scripts .php), pero esto significa que cada vez más a menudo el desarrollador promedio tiene que usar frameworks que construyan características de infraestructura estándar sobre el interpretador PHP. Irónicamente. Los frameworks de Java tienen características nativas que se adhieren a un estándar, los contenedores servlets. Las capacidades de PHP son obstaculizadas por la ausencia de estándares[23].

PHP ofrece una gran cantidad de funciones estáticas, mientras que en java la mayoría de ellas se encapsulan como métodos de objetos (cadena1.equals(cadena2) en Java y str_cmp(cadena1, cadena2) en PHP)[15].

La carencia de espacios de nombres en PHP adiciona un espacio de dominios oscuro de un proyecto PHP, pues no es fácil ver las relaciones entre los objetos en términos de una jerarquía organizacional, mientras que en Java esto es una necesidad.

Para ganar funcionalidad adicional, en PHP se tiene que importar archivos en lugar de clases, lo cual es conceptualmente diferente. Las clases estáticas pueden tener el mismo efecto en Java. El comportamiento por defecto en Java es usar instancias de clases mientras en PHP para muchos aun parece ser usar colecciones de funciones y librerías de funciones.

PHP es un poderoso lenguaje e intérprete, ya sea incluido como parte de un servidor web en forma de módulo o ejecutado como un binario CGI separado, es capaz de acceder a archivos, ejecutar comandos y abrir conexiones de red en el servidor. Estas propiedades hacen que cualquier cosa que sea ejecutada en un servidor web sea insegura por naturaleza. Java, por su parte utiliza una serie de mecanismos de seguridad, con el fin de dificultar la escritura de programas maliciosos que pudiesen afectar la integridad de las aplicaciones y los datos de los usuarios (el “security manager” por ejemplo, o incluso la misma máquina virtual que evita el acceso directo a los recursos del sistema).

Ventajas de PHP

Es realmente OpenSource. No depende tanto de librerías y/o aplicaciones de terceros, como en el caso de

J2EE. Es posible desarrollar más rápido y es más fácil de depurar en proyectos

pequeños, por eso como este sistema no es robusto, se decidió contemplar más fácil la posibilidad de hacerlo en este lenguaje[12]

Una implementación de PHP en servidor es más barata que una de Java (descontando TomCat y JBoss).

Muy fácil de aprender. Se caracteriza por ser un lenguaje muy rápido. Soporta en cierta medida la orientación a objeto. Clases y herencia.

Página24


Es un lenguaje multiplataforma: Linux, Windows, entre otros. Capacidad de conexión con la mayoría de los manejadores de base de datos:

MysSQL, PostgreSQL. Oracle, MS SQL Server, entre otras. Capacidad de expandir su potencial utilizando módulos. Posee documentación en su página oficial la cual incluye descripción y ejemplos

de cada una de sus funciones [15]. Es libre, por lo que se presenta como una alternativa de fácil acceso para todos. Incluye gran cantidad de funciones. No requiere definición de tipos de variables ni manejo detallado del bajo nivel

[16].

Algunas de las razones por las cuales no se pensó en java:

Hay diferentes tipos de soporte técnico para la misma herramienta, por lo que el análisis de la mejor opción se dificulta

Para manejo a bajo nivel deben usarse métodos nativos, lo que limita la portabilidad.El diseño de interfaces gráficas con awt y swing no es simple o Existen herramientas como el JBuilder que permiten generar interfaces gráficas de manera sencilla, pero tienen un costo adicional.

Puede ser que no haya JDBC para bases de datos poco comerciales. Algunas Herramientas tienen costo adicional.

PHP frente a .NET:

A continuación se mencionan algunos aspectos de comparación entre PHP y .NET con el mismo objetivo anterior, ofrecer algún tipo de orientación sobre cuál opción es la más adecuada de acuerdo a la situación:

Asp.Net es un lenguaje optimizado y compilado, es decir, el código que escriba se reduce a un conjunto de instrucciones específicas de la máquina antes de ser guardado como un archivo ejecutable. Php por el contrario es un lenguaje interpretado, lo que significa que se guarda como el código escrito y se ejecuta directamente desde el mismo[21].

PHP es un lenguaje relativamente más sencillo de usar que ASP.net. Inicialmente, PHP fu escrito en el lenguaje de programación C para sustituir a un conjunto de scripts de Perl. Esa es la razón por la cual la codificación en PHP sigue siendo simple, incluso hoy en día. ASP.net tiene un montón de opciones cuando se trata de lenguajes (C #, J #, C, VB.net.) Por lo tanto, ASP.net tiene mejor oferta. Pero

Página25



PHP no es menos, ya que puede trabajar muy bien, incluso con sus mínimas herramientas de lenguaje[14].

PHP tiene mucho mejor soporte para el sistema de gestor base de datos MySQL. ASP.net también tiene soporte para MySQL, pero PHP es unánimemente aclamado por las masas y las clases por igual, por su gran apoyo para este sistema gestor de base de datos.

Quienes usan tanto PHP como ASP.net también mantienen su opinión de que PHP es mejor en cuanto al apoyo integrado con otro sistema de gestión de base de datos (SQLite)[18].

PHP tiene un muy buen soporte para la programación orientada a objetos. ASP.net también proporciona un soporte muy bueno para programación orientada a objetos.

Debido a que PHP es open source el soporte provisto puede venir libremente de todas partes del mundo. En la mayoría de los casos, las soluciones de PHP se hacen al instante. Mientras que ASP.net puede tomar un poco más de tiempo para dar soluciones, pues es propiedad de Microsoft, y es el equipo de desarrollo de Microsoft que tendrá que responder a la consulta de soporte.

PHP es un lenguaje de programación de código abierto, lo que significa que es libre para cualquiera lo use. ASP.net está disponible para los usuarios de Windows cuando lo compran.

ASP.net se compila en la memoria en código binario por lo que puede necesitar más tiempo en proceso, ya que los códigos deben ser recuperados de la memoria. Sin embargo, PHP no se compila en la memoria como ASP.net. Se interpreta en tiempo de ejecución. Esa es la razón por la cual la codificación PHP puede conducir a una mayor velocidad y eficiencia, incluso.

Los gastos de hosting, tanto en PHP y ASP.net son bastante baratos. ASP.Net requiere una licencia de Microsoft, además tiene una sola plataforma y

sólo se ejecutan en los servidores web de Microsoft. PHP es libre y open source y tiene muchos IDEs gratuitos disponibles que son muy impresionantes y bien soportados (por ejemplo, Eclipse), y se ejecuta en el servidor Apache, que es de código abierto, además de tener soporte de múltiples plataformas.

PHP es más fácil de aprender debido a su estructura básica del lenguaje de scripting y construcción de funcionalidad. Por su parte ASP.Net requiere un conocimiento básico de conceptos orientado a objetos.

ASP.Net se ejecuta sobre ISS. PHP se ejecuta sobre IIS 6.0 e IIS 7.0. Las aplicaciones ASP.Net pueden ser desarrolladas con la impresionante IDE

Visual Studio.Net que ofrece amplia gama de características, que hacen mucho más fácil la codificación y el desarrollo productivo. La mayoría de los IDEs PHP, por su parte requieren gran cantidad de complementos con el fin de añadir funciones similares a Visual Studio.

PHP no tiene soporte nativo para AJAX, requiere complementos. ASP.Net incorpora soporte para AJAX desde Net Framework 3.5

Página26


El Framework de .NET (el motor sobre el que se ejecuta ASP.Net) tiene capacidades de manejo de errores más sofisticadas que PHP.

ASP.Net permite una mejor separación del diseño y la lógica de la aplicación usando de páginas de código subyacente (code-behind) y controles de usuario.

Algunas de las razones por las cuales no se pensó en .Net:

Una de las limitaciones en el desarrollo con ASP es que con el tradicional utilizamos lenguajes de scripting no tipeados comoVSBcrip o JScrip. Podemos instalar otros motores scripting que impongan verificación de tipos; sin embargo, no son universalmente conocidos o utilizamos como los anteriores[19].

Tiene que correr en PCs normales que tengan Windows y un servidor Web.

Aunque existen diferentes soluciones en el mercado, que se enfocan a resolver el proceso de devoluciones en todo tipo de empresas, las razones por las cuales se decidió realizar el aplicativo con desarrollo interno, y en las tecnologías seleccionadas, fueron:

- Los asesores que trabajan en la empresa, no tienen conocimiento tecnológico, en la mayoría de los casos cuentan hasta con estudios primarios, y muchos ni siquiera habían manejado un computador antes de llegar a la compañía. Por lo cual presentarles un nuevo software causaría mucho malestar e indisposición en ellos.

- Los asesores ya estaban acostumbrados a manejar el aplicativo “Reporteador” por lo cual adaptarse a una nueva funcionalidad dentro de este, facilitaría el aprendizaje rápido de la herramienta.

- El “Reporteador” ya manejaba toda la seguridad y creación de usuarios, tanto para los comités, los jefes y las tiendas, por lo cual se evitaba la creación de nuevas tablas que podrían duplicar información de la empresa.

- Una nueva herramienta necesitaría ser explicada a todos los usuarios, por lo cual deberían darse capacitaciones a todas las personas, y la empresa GMO no estaba dispuesta a incurrir en costos en capacitaciones.

Página27



Por todas estas razones, decidió adaptarse a toda las tecnologías usadas en el desarrollo del reporteador, ya que era la que más ventajas a todos los usuarios de la compañía daba.

2. Descripción de la Solución

2.1. Requerimientos funcionales:

RF1: El sistema debe permitir configurar un conjunto de reglas, y dejar registro de un conjunto de políticas, para la evaluación de la prestación de la operación de apoyo. Estas reglas y políticas tienen que ver con restricciones y condiciones, de garantías, sobre convenios y otras condiciones especiales que se definirán

RF2: El sistema debe tener un modelo de privilegios de usuario que otorgue o denegué ciertas características.

RN3: El sistema debe permitir cargar los datos principales del cliente y por consiguiente de la factura del mismo en el área de las garantías cuando se va a llenar el formulario.

RF4: El sistema debe permitir modificar los datos de contacto del cliente en el formulario de garantías.

RF5: El sistema debe permitir poder seleccionar el tipo de garantía (producto adquirido) por la cual se va a reclamar, dependiendo del producto debe también permitir seleccionar si la garantía es por mala calidad o por adaptación.

RF6: El sistema debe estar en capacidad de validar si la garantía está dentro del tiempo que estipuló la empresa al cliente en el momento de la adquisición del producto.

RF7: El sistema debe permitir ingresar todos los datos y las características de la garantía que está reclamando el cliente.

RF8: El sistema debe estar en la capacidad de almacenar de igual manera los datos del asesor que está haciendo la diligencia de la ejecución de la garantía, como el nombre del solicitante, la cedula, la especificación de la montura o el lente, lo que espera el cliente recibir después de la queja, el procedimiento que la empresa elige hacer, y un espacio para observaciones.

RF9: El sistema debe tener un submodulo donde se pueda verificar todas las garantías que están pendientes por procesar, deben poder clasificarse por fecha de pedido de garantía, deben tener el código del producto, el número de la solicitud, el estado en que se encuentra la solicitud y el código de la tienda donde es solicitada la garantía.

RF10: El sistema debe estar en capacidad de tener tres tipos de respuesta después de valorar el tipo de garantía que pide el cliente, estas respuestas deben ser aprobada, pre-aprobada o negada.

RF11: El sistema debe validar la solicitud de la merma asociada a la garantía, este proceso debe tener también validación de privilegios de usuario.

Página28


RF12: El sistema debe permitir cargar los datos principales del cliente, del vendedor y por consiguiente los datos de solicitud de la merma.

RF13: El sistema debe permitir ingresar y relacionar con el reproceso, el nuevo encargo dependiendo de la merma, debe tener todos los datos del cliente, del vendedor, datos totales de la merma y crear un número de encargo.

RF14: El sistema debe permitir generar un reporte de las actividades realizadas en el ciclo de vida de la generación de garantías.

2.2. Requerimientos no funcionales:

SEGURIDAD

RN1: No sobrepasar los controles de seguridad, Integridad de las configuraciones de seguridad del servidor, integridad de los recursos del sistema, autoprotección independiente, verificación del ambiente de operación y detección de fallas externas.

RN2: Autenticación de usuario, autenticación de procesos, advertencia de autenticación, mecanismos de identificación y autenticación, ruta de autenticación confiable, información de autenticación, autenticación con el backend de la aplicación, intentos no exitosos y periodos de bloqueo, autenticación fuerte de usuarios de altos privilegios, contraseñas fuertes, permitir cambio de contraseñas por el usuario y autenticación por cada sesión.

RN3: Autorización de usuario, herramienta de administración de autorizaciones, mínimos privilegios de la aplicación, modelo de autorización, mecanismos de autorización, inactividad de la sesión, número máximo de sesión, integridad de la información de autorización, disponibilidad de la información de autorización.

USABILIDAD

RN4: Permitir la integración con herramientas BPM que permitan la automatización de procesos.

RN5: Permitir la integración con portales, herramientas de colaboración, sistemas de gestión documental y GRC

RN6: Permitir la publicación de los procesos con todos sus componentes en un ambiente web

RN7: Permitir el diseño y generación de informes y gráficos personalizados, para luego poder exportar el resultado a diferentes formatos (Excel, pdf)

RN8: Permitir el manejo y la escalabilidad en el volumen de las transacciones y de los usuarios.

RN9: Permitir diseñar, construir, mantener y manipular los modelos que componen la arquitectura.

Página29



MANTENIBILIDAD

RN10: Contar durante la ejecución de transacciones con puntos de chequeo o checkpoints, los cuales serán los puntos de retorno en el caso que la aplicación falle o se encuentre no disponible. El retorno a los puntos de chequeo debe garantizar un estado consistente en la transacción.

RN11: Verificar cuándo la aplicación se reinicie (aunque sea después de un fallo), que no se encuentre afectado ninguno de los controles de seguridad, que la información no esté corrupta o faltante, y que los componentes de la aplicación no se hayan modificado.

RN12: Contar con manuales técnicos en formato digital. En estos se debe contar con información del diccionario de bases de datos, interrelación, servicios de integración, monitoreo de base de datos, información de instalación.

RN13: Registrar los errores con los detalles de la causa raíz del error, el usuario, el proceso que lo generó y la excepción generada, con el fin de entregarle datos al administrador.

RN14:La solución debe tener una arquitectura que permita su actualización de versión sin afectar los desarrollos propios de la empresa

RN15: Soporta dispositivos móviles con sistema operativo Android, IOS y BlackBerry OS.

Página30


2.3. ANALISIS

Esta fase se utiliza para realizar una descripción de lo que el sistema es capaz de hacer; gracias al levantamiento de información ya se conocen los actores involucrados y las actividades que estos realizan, Ahora el paso siguiente es analizar todos los conceptos que se recogieron de la información obtenida para darle un seguimiento metódico al sistema de información de GMO. A continuación se nombran los modelos a utilizar en la fase de análisis de sistemas:

Página31



Descripción detalla del problema

A comienzos de este año, junto con los cambios que venían con los nuevos dueños de la compañía, se venía entonces uno de los proyectos con mayor impacto tanto para el área tecnológica, como para el resto de áreas de la compañía, un proyecto tan grande como la migración o en este caso la implementación de una ERP. Se buscaba entonces, que todos los países Latinoamericanos de GMO, implementaran SAP como sistema de gestión de los recursos, ya que hasta el momento, no se contaba con algún sistema grueso que soportara todas las operaciones que puede tener la empresa.

Fue entonces cuando en los días de salida en vivo de esta implementación, SAP solicitaba el ingreso de todos los encargos o ventas de la empresa, en un estado específico, para poder ser migrados a este nuevo software.

Al hacer la búsqueda de todos los encargos se encontraron aproximadamente 160 encargos que estaban aún abiertos, pero que no tenían un estado específico, este era desconocido, y aparentemente estaban desaparecidos dentro del flujo interno de la compañía. Si estos encargos no tenían un estado específico, no podrían ser migrados a SAP, y la salida en vivo no podría ser realizada, o seria realizada de una manera incompleta, lo cual representaba un riesgo para la compañía, al estar pasando información incompleta, a un sistema tan estable como SAP. Al hacerles un seguimiento detallado a estos encargos, se encontró una coincidencia en la mayoría de estos, esta era que todos los encargos eran de tipo merma o garantía.

• Se considera una garantía, toda aquella reclamación presentada por concepto de CALIDAD, está puede ser por material (Lentes-Montura) o por formula (Lentes).

• Es considerado como merma, todo aquel ERROR que represente un reproceso inmediato dentro de la producción de lentes; bien sea por error en tienda (asesoría, formulación, otros) o por daño durante la fabricación de estos.

Fue entonces cuando se empezó a analizar cómo funcionaban este tipo de encargos en la compañía, cuál era el flujo que seguían, el proceso por el que pasaban, y el procedimiento por el cual se regían. Y la conclusión fue una sola, el desorden y la falta de especificación y automatización en este proceso era absolutamente notable.

Página32


Ya veremos más adelante en este documento cual era el proceso manual por el cual estaban pasando estos encargos, pero empecemos contando como este, que para nada tiene que ver con algo tecnológico, al no ser estándar ni automatizado, y en medio de tener que acceder manual y directamente a bases de datos, se estaba dejando como responsabilidad de área de Sistemas. Fue así, que cuando en la junta directiva de resultados de cómo iba la migración a SAP, la única área con posibles retrasos, era Sistemas, debido a estos encargos, que muy seguramente ni siquiera eran su responsabilidad, pero que por desconocimiento de su estado original, recaían en el área.

Para solucionar el problema temporalmente y no originar ningún retraso de la salida en vivo, tuvo que recolectarse manualmente el estado de cada uno de estos 160 encargos, y hacer la migración manual de estos, proceso que implico 2 días cada uno aproximadamente de 18 horas trabajo seguidas, con dedicación de 3 personas del área, para poder lograrlo. Pero claramente quedo marcado la urgencia de solucionar de raíz este problema que se estaba presentando.

Conoceremos entonces todos aquellos encargos que se creen por causa de una merma o una garantía, como “Reprocesos GMO”, ya que son encargos que alguna vez ya fueron creados y en la mayoría de casos producidos y entregados, y que deben ser anulados, vueltos a crear, sin afectar ninguna de las operaciones de la empresa, por lo tanto serán reprocesados.

En el siguiente numeral vamos a estudiar el flujo manual que seguía el proceso de “Reprocesos GMO”, antes de ser creada la aplicación, y con la implementación de SAP ya lanzada en la empresa GMO Colombia.

Página33



Flujo Manual Reprocesos GMO

Vamos a hacer seguimiento de esta grafica que está representado el flujo anterior por el cual se daba el proceso de “Reprocesos GMO”.

Tenemos dos posibles maneras de empezar este flujo, la más recurrente es por una acción del cliente, quien es quien interpone una queja sobre el producto o encargo adquirido.

La segunda es cuando la tienda o el centro de producción descubren una falla antes de entregar el encargo, por lo cual daría inicio también al flujo.

En el caso l cliente se dirige a una tienda, en la cual su solicitud es recibida específicamente por un asesor, quien puede no ser el vendedor original del pedido, en el segundo caso la tienda ya es dueña del flujo y responsable de dar inicio a este, por lo cual el seguimiento a este flujo una vez encontrado el caso lo tiene a cargo la tienda, la cual debe recibir el encargo, encontrar en el sistema GESTIOPTICAS, el cual es el sistema de ventas de la empresa, a que numero corresponde, por medio de diferentes datos como el nombre de la persona, la fecha del encargo, a que productos corresponde esta venta, etc.

Una vez encuentre esta información, debe pasar a diligenciar un formulario de EXCEL, hasta el momento la persona que está asesorando el caso no tiene información acerca de si la garantía se encuentra en el tiempo, así que deberá

Página34


recibirlo de todas las maneras, y el cliente dejara su producto, sin la seguridad de que de verdad este pueda ser cambiado.

Una vez llenado este formulario, el asesor debe tener en cuenta algunos criterios sobre el flujo o dirección que debe seguir con este correo, este podrá ser guiado dependiendo de tipo de garantía o merma del que sea la solicitud, ya que algunos tipos requieren ser autorizados, para que de esta manera GMO asuma el costo, o en otros debido a errores de la misma tienda, el asesor es quien asumirá el costo, por lo cual no debe tener ninguna autorización, sino deberá enviar el correo lo más rápidamente posible, para dar inicio a todo el proceso de producción del nuevo producto.

Nombre Autorización

Garantía -

Error Digitación 0

RX 0

Mala Asesoría 0

Manipulación 0

Perdida Tienda 0

Anulacambio 1

Primera Merma 1

Perdida Distribuidor 1

Empleado Retirado 1

Las razones que tienen como autorización un 0, son aquellas que su costo deberá ser asumido por la tienda y por lo cual no requieren una autorización previa, y las razones que tienen como autorización 1, requieren de una previa aprobación, por lo cual antes de empezar un proceso de producción.

Página35



En caso de que sea una garantía, lo primero que se mira es el tiempo en el cual se compró el encargo, si esta garantía está en un rango de máximo un año, la garantía quedaría pre-aprobada, si no, se rechaza de una vez, después esta garantía puede pasar al comité de lentes, o al comité de monturas, dependiendo claramente de la cual de las dos razones por la cual se solicite la garantía, las siguiente razones en las cuales se basaran los comités para tomar la decisión, son criterios ya establecidos por cada uno de ellos, y que no pueden ser estructurados en alguna base de datos, ya que son intangibles, como por ejemplo el cuidado que se le ha dado a los lentes, basado en cómo se encuentre la montura o los rayones de estos mismos lentes. Estos criterios ya se dejan a cargo de cada comité quien solo dará respuesta de si fue o no aprobado, y las razones para esto.

Podemos encontrar problemas en la montura o en los lentes tales como, estos aplican para todas las razones nombradas en la anterior tabla:

Criterio

Pin Roto

Brazo Suelto

Flex Roto

Montura Torcida

Aro Roto

Guía de Aro Caída

Brazo Roto

Deterioro de Pintura

Puente Roto

Levantamiento Polarizado

Accesorio Roto

Manipulación Cliente

Tornillo Roto

Página36


Ajuste Tienda

Fuera de Tiempo

OTROS

Desprendimiento AR

Desprendimiento Fotocromatico

Estrías AR

Estrías Fotocromatico

Ajuste Taller

Grados

Manipulación Cliente

Altura

Montura Errónea

Astillado

Poros

Color

Tensión

Espesor

Ventanas

Formula (RX)

Fuera Tiempo

Parámetros

Página37



Una vez decidido el flujo por el cual se debe enviar el correo, se escribe el asunto con temas que puedan dar algún indicio de que es una garantía o merma, y se adjunta el formulario que se llenó anteriormente.

En caso que requiera de una autorización, tanto la jefe nacional, o el comité correspondiente encargado de esto, debe estudiar el caso, y tomar la decisión sobre si será o no aprobado, y debe devolver un correo a la tienda dando esta respuesta, en caso que sea aprobado, debe copiar a las personas de soporte de sistemas.

Una vez la tienda recibe respuesta sobre la garantía pueden ocurrir dos cosas, una que la garantía fue negada, hasta ese momento no había forma de comunicación con el cliente, por lo cual se esperaba hasta que el cliente volviera a la tienda por decisión propia, para informarle de esta decisión, si él está conforme sobre la negación, se hace devolución del encargo original entregado, pero no se lleva un registro diferente a los correos, de toda la situación y como se desencadeno, de lo contrario, intentando evitar problemas legales, se ingresa a un sistema satélite de GMO, llamado SAC, que llevara a un proceso nuevo, del que están encargados los comités, para llegar a una serie de negociaciones, pero este proceso ya se hace ajeno al objetivo principal de “Reprocesos GMO”.

El otro caso es cuando la garantía fue aprobada por la persona encargada de este caso, aquí la tienda debe entonces crear un nuevo presupuesto en GESTIOPTICAS, con los datos enviados en el documento de Excel, ya con este número de presupuesto, se envía un correo a las personas de sistemas para que den inicio a la creación de un nuevo encargo.

Una vez las personas de sistemas reciben este correo, deben primero, comparar el presupuesto, y todos los datos que este incluye, con el documento de Excel, que reenvió la jefatura o comité, y comprobar que los datos son exactamente iguales.

Muchas veces se cometen errores o se presentan diferencias entre los dos, por lo cual sistemas deberá devolver el caso a la tienda, para que este vuelva a crear un presupuesto exactamente igual al documento adjunto original de Excel.

Este flujo se repetirá hasta que las dos partes estén completamente conformes, o mejor dicho coincidan los datos.

Una vez sistemas encuentre esta igualdad, podrá proceder a crear un nuevo encargo, para esto necesitara tanto los datos del presupuesto creado, algunos más del

Página38


documento de Excel, y finalmente deberá entrar a la base de datos del encargo original para adquirir la información final.

Ya con estas entradas podrá proceder a crear el nuevo encargo en el sistema, guardara este número en un registro de Excel, que relacionara el encargo original, el presupuesto creado para la merma, y el nuevo número de encargo.

Debe entonces enviar un correo a la tienda, informándole que el nuevo encargo ya está creado, y ellos con esta información, liberaran el encargo a SAP.

Al mismo tiempo deberán entonces enviar al CDD, o Centro de Distribución, el encargo original, para que ellos puedan reutilizar las partes del encargo que no cubre la garantía, ya sea los lentes o la montura. Para esto crearan una encomienda, y relacionaran el número de encomienda con el nuevo número de encargo creado, esto lo llevaran en un registro propio de Excel, no existen formatos estándar para ningunos de estos registros, cada tienda lo llevara como mejor sienta puede organizarse.

Tampoco existen formatos o seguimientos para los casos que tienen abiertos cada una de la tiendas, y esta información también deberá ser llevada como mejor sienta la tienda, le puede funcionar.

El CDD recibe la encomienda, tal cual como un encargo normal, y al n o saber que es una garantía o merma, lo fabricara en el tiempo normal, sin darle ningún tipo de prioridad. La única manera para que esto suceda es porque la tienda llame y avise de manera especial que requieren esto urgentemente.

Una vez terminado el nuevo encargo, el CDD lo despacha a la tienda, de la misma manera que envía los encargos normales, lo cual puede llevar unos días de demora.

Como vemos él envió de tantos correos, espera a respuestas, falta de seguimiento, y demoras en la producción, hacen que en muchos casos, la espera sea mayor a 15 días, el cual es el número de días máximo que por ley tiene una garantía para ser entregada, y al ser incumplido este plazo máximo, el dinero debe devolverse, lo cual representa una pérdida en la compañía.

Por último la tienda al recibir el encargo, debe esperar que la persona se acerque a recoger el encargo, y si no está conforme, proceder de la misma manera que la descrita anteriormente.

Página39



Página40


Este es el nuevo diseño del flujo después de creada la aplicación “Reprocesos GMO”, vemos que aunque tiene varios pasos que también se tenían en cuenta en el anterior diagrama, esta vez son muchos más estructurados y todos se hacen a través de sistemas confiables, vemos como se erradica tanto los pasos de envíos y recepciones de correos electrónicos, así como las llamadas para poder comunicar información, tiene también ahora el cliente, la notificación del estado final de su producto, para poderse acerca a la tienda una vez reciba esto.

Otra de las diferencias más significativas, es ver que en el diagrama se incorporan dos nuevas áreas de trabajo, tanto Inventario, como control Interno, ya que el seguimiento a todo el producto, y la interferencia de estas mermas y garantías en este control, prácticamente no se estaba realizando, y estas áreas tenían que hacer ajustes manuales, para que cuadran estos resultados, lo cual permitía muchos robos y perdidas de mercancía. El incorporar estas dos áreas al sistema, le da a la compañía mayor facilidad de seguimiento al producto o inventario final que maneja, además que automatiza también el proceso para estas áreas, en especial para Control Interno, el cual al final de mes tenía que lograr que todos los reportes que presentaba a la junta directiva cuadraran totalmente, y muchas veces debían simplemente ajustar como dados de baja, sin tener conocimiento de que en verdad había pasado con esta mercancía.

La empresa entonces gracias a esto conocerá el estado verdadero de lo que pasa en la compañía, o por lo menos con este proceso, y la junta podrá tomar otro tipo importante de decisión con respecto a esto.

Por ultimo también trae beneficios legales, ya que la tienda a través del aplicativo ya puede imprimir la carta de satisfacción, y de entrega de producto al cliente, por lo cual el proceso se hace más confiable y los clientes firman el acuerdo tanto al inicio como al final del proceso.

El flujo entonces aunque claramente repite pasos del proceso manual, cambia 100% la metodología del proceso, y la manera en que todo funciona, le da seguridad, confiabilidad, automatización, y nuevas funcionalidades al proceso.

Página41



2.3.1. Diagrama de clases

Página42


2.3.1.1. Diccionario de las clases

Métodos DescripciónAdicionar Método que permite adicionar nuevos registros en todas las

clases.Consultar Método que permite consultar a todos los registros que manejan

el sistema.Modificar Método que permite modificar los registros que maneja el

sistema.Eliminar Método que permite eliminar cualquier registro.

Clase:MAG_GRTIACB

Definición: Esta tabla se utiliza para administrar todos los datos generales de una solicitud de garantía.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOcdg Código Único de la garantía VARCHAR (11) NOT

NULLconsecutivo Consecutivo para la creación

de garantía INT

Fecha Fecha en la que se creó esta garantía

DATE

idCiudad Ciudad donde se realizó la compra

VARCHAR (50)

Tienda Código de identificación de tienda GMO donde se realizó la compra

VARCHAR (10)

Encargo Código único del encargo al que se le quiere crear garantía

VARCHAR (11)

EstadoRecepcion Describe el estado en el que se recibieron las gafas

TEXT

Solicitud Descripción de las razones de la solicitud de la garantía.

TEXT

Procedimiento Descripción del procedimiento que debe realizarse al producto

TEXT

Observaciones Campo para observaciones que puedan realizarse en el proceso.

TEXT

Página43



Encargado Nombre del asesor que vendió el encargo.

VARCHAR (50)

Tipo Tipo de solicitud VARCHAR (25)EsAnulacambio Corresponde o no a tipo

anula cambio, 0 o 1.INT

Merma Relación con merma al ser creada

VARCHAR (11)

No_Solicitud Numero único de la solicitud de la creación

INT

Estado Número de personas matriculadas

INT

Clase:MAG_GRTIALN

Definición: Las solicitudes de garantías cuentan con datos específicos para cada uno de los productos de la solicitud, para poder almacenar estos datos se utiliza esta tabla

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOCdg Código único de la tabla VARCHAR

(15)NOT NULL

grtiacb Numero de Garantía Cabecera VARCHAR (11)

NOT NULL

Estado Número que identifica el estado actual

INT NOT NULL

articulo Numero de artículo de la línea VARCHAR (50)

responsable Asesor encargado de la venta VARCHAR (10)

RoleAsigando Rol del asesor encargado VARCHAR (10)

OrigenLente Descripción centro origen lente VARCHAR (10)

Agrupar Código para agrupar líneas INTlinea Número de líneas INTurl_fotos Dirección para las fotos del

estado actual del articuloVARCHAR (200)

Página44


Clase:MAG_Evento

Definición: Esta tabla almacena los datos de cualquier tipo de acción que se realice sobre la solicitud de garantía, tales como: Aprobación, Rechazo, Negación.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOId Código único de la tabla INT NOT NULLIdentgrtialn Línea correspondiente a la

garantíaVARCHAR (13)

NOT NULL

linea Numero de línea INT

Justificacion Observaciones sobre la justificación de la correspondiente acción

VARCHAR (500)

Notas Descripción sobre el procedimiento aplicado

VARCHAR (500)

Usuario Usuario que realizo la acción VARCHAR (50)

Fecha Fecha en la que se ejecuta la acción.

DATE

NvoEstado Estado actual del producto INTEstadoAnterior Estado anterior del producto INTEncomienda Numero de encomienda en la

que se envíaBIGINT

Procesado Esta o no procesado TINYINTFecha_Procesado Fecha en la cual se proceso DATETIME

Página45



Clase:MAG_DAdaptacion

Definición: Tabla utilizada para registrar los datos adicionales que se necesitan para realizar una solicitud de garantía de adaptación, tales como:

Formula Numero de encargos nuevos

Tipo lente nuevo encargoATRIBUTO DESCRIPCIÓN TIPO DATO NULO

Num_Encargis Número del encargo correspondiente

INT

Familia_Lente Familia del lente del encargo VARCHAR (30)

Esfera_OD Esfera del ojo derecho del encargo

FLOAT

Esfera_OI Esfera del ojo izquierdo del encargo

FLOAT

Cilindro_OD Cilindro del ojo derecho del encargo

FLOAT

Cilindro_OI Cilindro del ojo izquierdo del encargo

FLOAT

EjeOD Eje del ojo derecho del encargo INTEjeID Eje del ojo izquierdo del

encargoINT

Esfera_CercaOD Esfera de cerca del ojo derecho del encargo

FLOAT

Esfera_CercaOI Esfera de cerca del ojo izquierdo del encargo

FLOAT

AdicionOD Adición del ojo derecho del encargo

FLOAT

AdicionOI Adición de cerca del ojo izquierdo del encargo

FLOAT

DNPL_OD DNPL de cerca del ojo derecho del encargo

FLOAT

DNPL_OI DNPL de cerca del ojo izquierdo del encargo

FLOAT

DNPC_OD DNPC de cerca del ojo derecho del encargo

FLOAT

Página46


DNPC_OI DNPC de cerca del ojo izquierdo del encargo

FLOAT

grtiacb Numero de Garantía VARCHAR (11)

NOT NULL

Clase:MAG_Estado

Definición: Tabla que controla los posibles estados que puede tener una solicitud de garantía.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOID Identificación del estado INT NOT NULLEstado Descripción del estado VARCHAR

(15)

Clase:MAG_CriteriosXSolicitud

Definición: Esta tabla se utiliza para registrar los criterios de negación o aprobación de las solicitudes de garantía.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOLnGrtia Numero de garantía VARCHAR

(15)NOT NULL

ID_Criterio Tipo de criterio a tener en cuenta

VARCHAR (50)

NOT NULL

Página47



Clase:MAG_TablaReferencial

Definición: En esta tabla se registran datos que serán usados de referencia para la aplicación, actualmente se almacena la siguiente información:

Datos de Ciudades, Departamento y Código DANE. Datos con los criterios de valoración utilizados por los diferentes comités (lentes y

monturas).

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOCodigo Código único de la tabla VARCHAR

(50)NOT NULL

Tabla Numero de tabla relacionada INT NOT NULLDescripcion1 Datos de ciudades, Depto. y

CódigoVARCHAR (50)

NOT NULL

Descripcion2 Criterios de evaluación. VARCHAR (100)

NOT NULL

Observaciones Observaciones sobre el proceso

VARCHAR (100)

NOT NULL

Clase:MAG_Tiempo_Garantía

Definición: Tabla utilizada para almacenar el tiempo de garantía que tienen los productos, el registro en la tabla se realiza a nivel de subfamilia.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOFamilia Familia a la que pertenece el

productoVARCHAR (10)

NOT NULL

Subfam Subfamilia a la que pertenece el producto

VARCHAR (10)

NOT NULL

Grupofam Grupo al que pertenece el producto

VARCHAR (10)

NOT NULL

TiempoRecepcion Tiempo transcurrido desde la recepción para la garantía

INT

Tiempo Tiempo total de garantía INT

Página48


Clase:MAG_Mail

Definición: Mediante esta tabla se administra el envío notificación a los clientes mediante correo electrónico.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOID_Mail Id único de la tabla INT NOT NULLDestinatario Correo del usuario final VARCHAR

(50)Asunto Estado de su solicitud VARCHAR

(100)Cuerpo Descripción del estado de su

solicitudTEXT

Fecha Fecha en la que se envía el correo

DATE

Clase:MAG_Cliente

Definición: En esta tabla se registran datos de contacto del cliente, que luego serán comparados contra los datos registrados en la BD del POS.

Estos datos se analizaran y se tomara la decisión sobre actualizar la BD del POS o no.ATRIBUTO DESCRIPCIÓN TIPO DATO NULO

Cdg Código único del registro INT NOT NULLcedula Cedula del cliente VARCHAR

(20)Nombre Nombre del cliente VARCHAR

(50)Telefono Cedula del cliente INTIndicativo Indicativo de la ciudad del

clienteTINYINT

Cel Celular del cliente INTdirección Dirección del cliente VARCHAR

(50)email Correo del cliente VARCHAR

(50)

Página49



Clase:MAG_Merma

Definición: Tabla utilizada para registrar los datos generales de una solicitud de merma.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOcdg Código único de la tabla INT NOT NULLEncargo Numero de encargo original VARCHAR

(15)Num_Presupuesto Número del nuevo

presupuesto creadoVARCHAR (50)

Fecha Fecha en la que se solicita la merma

DATETIME

Consecutivo Numero de consecutivo de merma creada

INT

Tienda Tienda donde se realizó la compra

VARCHAR (5)

IDEstado Id del estado actual del producto

INT

Comentarios Comentarios que se han dado en el proceso

VARCHAR (300)

Encargado Asesor encargado del proceso

VARCHAR (25)

Responsable Asesor encargado de la venta VARCHAR (10)

Nuevo_Encargo Numero de nuevo encargo creado

VARCHAR (15)

RoleAsigando Numero de rol asignado INTgrtiacb Numero de garantía VARCHAR

(11)NOT NULL

Motivo Tipo de motivo por la que se dio este proceso

INT NOT NULL

Página50


Clase:MAG_Motivo_Merma

Definición: Tabla que define los motivos o causas por las cuales se deben realizar solicitudes de mermas.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOID_Motivo Código único de la tabla INT NOT NULLNombre Descripción del motivo VARCHAR

(25)Autorizacion Número que dice si requiere o

no autorización para ser procesada

INT

Clase:MAG_Suplementos

Definición: Tabla utilizada para registrar los valores de los suplementos del nuevo encargo solicitado en la merma.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOAltura_OD Altura del Ojo Derecho INTAltura_OI Altura del Ojo Izquierdo INTCurva_Base_OD Medida de la curva del Ojo

DerechoINT

Curva_Base_OI Medida de la curva del Ojo Izquierdo

INT

Espesor_Borde_OD Espesor del borde del Ojo Derecho

INT

Espesor_Borde_OI Espesor del borde del Ojo Izquierdo

INT

Color Color del lente VARCHAR (50)

Tipo_Lente Clasificación del lente VARCHAR (50)

Merma Identificación única número merma.

INT NOT NULL

Página51



Clase:MAG_Medidas_Montura

Definición: Mediante esta tabla se registran las medidas de la montura del nuevo encargo.

ATRIBUTO DESCRIPCIÓN TIPO DATO NULOVertical Medida Vertical de las gafas INTHorizontal Medida Horizontal de las gafas INTPuente Medida del puente de las gafas INTDiagonal Medida Diagonal de las gafas INTTipo_Montura Tipo de clasificación de la

monturaINT

Merma Identificación única número merma.

INT NOT NULL

Página52


Clase:MAG_EventoMerma

Definición: Tabla utilizada para registrar las acciones que se realizan sobre una solicitud de merma, tales como:

Aprobar Negar

Pre-aprobarATRIBUTO DESCRIPCIÓN TIPO DATO NULO

id Código de identificación único para la tabla

INT NOT NULL

Justificacion Descripción sobre la solicitud de la merma y lo ocurrido

VARCHAR (500)

Usurio Cliente final dueño del producto

VARCHAR(50)

Fecha Fecha en la cual se registró la novedad

DATETIME

NvoEstado Número que representa el estado anterior

INT

EstadoAnterior Número que representa el actual estado

INT

Procesado Esta o no procesado aun TINYINTFecha_Procesado Fecha en la que se procesó en

caso de que ya haya sucedidoDATETIME

Merma Numero único de identificación para la merma que se está trabajando

INT NOT NULL

Página53



2.3.2. Diagramas de caso de uso

Ingresar al Sistema

RF - <id del registro> Ingresar al sistemaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los usuarios del sistema de

información tener acceso al sistema para una interacción adecuada.

Descripción En este caso de uso se ilustra los pasos necesarios para el ingreso de un usuario debidamente registrado y en consecuencia pueda utilizar el sistema.

Precondición Es necesario que el usuario este previamente registrado para tener acceso al sistema de información, de lo contrario no podrá realizar ningún tipo de consultas.

Secuencia normal Paso Acción

1 Ingresar nombre de usuario y password.

2 ingresar3 Verificar datos

Post condición El usuario podrá interactuar con el sistema de información.

Excepciones Si los datos de cuenta son incorrectos no se tendrá acceso al sistema de información.

Rendimiento 40 segundos.Urgencia Ninguno.

Caso de uso ingresar al sistema.

Página54


Diagrama de Caso de uso ingresar al sistema.

Página55



Adicionar garantía

RF - <id del registro> Adicionar garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que adicionen

toda la información la petición de una garantía

Descripción En este caso de uso se ilustra los pasos necesarios para adicionar el tipo de reclamo

Precondición Es necesario que el funcionario ingrese al sistema para poder adicionar garantía.

Secuencia normal Paso1

AcciónIngresar al sistema

2 Seleccionar el menú de garantía.3 Ingresa la información de la

garantía.4 Guardar los datos.5 Almacenar en la base de datos

Post condición Debe quedar guardada toda la información de la garantía en la base de datos.

Excepciones En caso que no se ingresen todos los datos obligatorios, no deja guardar, y se dispara advertencia

Rendimiento 15 segundos después de la orden de guardar

Urgencia Ninguno.

Caso de uso Adicionar Garantía.

Página56


Diagrama de Caso de uso Adicionar garantía.

Página57



Consultar garantía

RF - <id del registro> Consultar garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios consultar toda

la información de las garantías.Descripción En este caso de uso se ilustra los pasos

necesarios para consultar los datos de las garantías

Precondición Es necesario que el funcionario ingrese al sistema para poder consultar garantías



2 Consultar garantía.3 Ingresar dato básico.4 Consultar datos5 Buscar en la base de datos

Post condición Se visualiza la información registradaExcepciones Si no existe la garantía buscada, no se

visualiza ningunaRendimiento 20 segundos.Urgencia Ninguno.

Caso de uso Consultar Garantía.

Página58


Diagrama de Caso de uso Consultar garantía.

Página59



Adicionar solicitante garantía:

RF - <id del registro> Adicionar solicitante garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que adicionen

toda la información de la persona que solicita la garantía

Descripción En este caso de uso se ilustra los pasos necesarios para adicionar los datos del cliente




2 Seleccionar el menú de garantía.3 Ingresa la información del cliente

que solicita la garantía4 Guardar los datos.5 Almacenar en la base de datos

Post condición Debe quedar guardada toda la información del solicitante en la base de datos.


Rendimiento 15 segundos después de la orden de guardar

Urgencia Ninguno.Caso de uso Adicionar Solicitante Garantía.

Página60


Diagrama de Caso de uso Adicionar Solicitante Garantía.

Página61



Consultar solicitante garantía

RF - <id del registro> Consultar solicitante garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que consulten

toda la información de la persona que solicita la garantía

Descripción En este caso de uso se ilustra los pasos necesarios para consultar los datos del cliente

Precondición Es necesario que el funcionario ingrese al sistema para poder consultar garantía.



2 Consultar solicitante garantía.3 Ingresar dato básico.4 Consultar datos5 Buscar en la base de datos

Post condición Se visualiza la información registradaExcepciones Si no existe el solicitante buscado, no se

visualiza ninguno.Rendimiento 40 segundos.Urgencia Ninguno.

Caso de uso Consultar Solicitante Garantía.

Página62


Diagrama de Caso de uso Consultar Solicitante Garantía.

Página63



Adicionar valoración solicitud garantía

RF - <id del registro> Adicionar valoración solicitud garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que verifiquen

la información y agreguen acepten la gestión de la garantía

Descripción En este caso de uso se ilustra los pasos necesarios para adicionar los datos de la solicitud





solicitud de la garantía4 Guardar los datos.5 Almacenar en la base de datos

Post condición Debe quedar guardada toda la información de la valoración en la base de datos.



Caso de uso Adicionar valoración solicitud garantía

Página64


Diagrama de Caso de uso valoración solicitud garantía

Página65



Consultar valoración solicitud garantía

RF - <id del registro> Consultar valoración solicitud garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que consulten

toda la información de la persona que solicita valoración de solicitud de garantía


Precondición Es necesario que el funcionario ingrese al sistema para poder consultar garantía.



2 Consultar solicitante garantía.3 Ingresar dato básico.4 Consultar datos5 Buscar en la base de datos

Post condición Se visualiza la información registradaExcepciones Si no existe la valoración buscada, no se

visualiza ninguna.Rendimiento 40 segundos.Urgencia Ninguno.

Caso de uso Consultar valoración solicitud garantía

Página66


Diagrama de Caso de uso Consultar valoración solicitud garantía

Página67



Adicionar merma garantía

RF - <id del registro> Adicionar merma garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que adicionen

toda la información la petición de una merma asociada a la garantía

Descripción En este caso de uso se ilustra los pasos necesarios para adicionar la merma

Precondición Es necesario que el funcionario ingrese al sistema para poder adicionar merma




merma4 Guardar los datos.5 Almacenar en la base de datos

Post condición Debe quedar guardada toda la información de la garantía en la base de datos.



Caso de uso Adicionar merma garantía

Página68


Diagrama de Caso de uso Adicionar merma garantía

Página69



Consultar merma garantía

RF - <id del registro> Consultar merma garantíaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que consulten

toda la información de la merma asociada a la garantía


Precondición Es necesario que el funcionario ingrese al sistema datos para poder consultar la merma asociada a la garantía



2 Consultar merma.3 Ingresar dato básico.4 Consultar datos5 Buscar en la base de datos

Post condición Se visualiza la información registradaExcepciones Si no existe la garantía buscada, no se

visualiza ninguna.Rendimiento 40 segundos.Urgencia Ninguno.

Caso de uso Consultar merma garantía

Página70


Diagrama de Caso de uso Consultar merma garantía

Página71



Adicionar valoración solicitud merma

RF - <id del registro> Adicionar valoración solicitud mermaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que adicionen

toda la información para la verificación de la solicitud de la merma

Descripción En este caso de uso se ilustra los pasos necesarios para validar y justificar la solicitud de la merma.

Precondición Es necesario que el funcionario ingrese al sistema para poder validar la merma




merma4 Guardar los datos.5 Almacenar en la base de datos

Post condición Debe quedar guardada toda la información de la valoración en la base de datos.



Caso de uso valoración solicitud merma

Página72


Diagrama de Caso de uso valoración solicitud merma

Página73



Consultar valoración solicitud merma

RF - <id del registro> Consultar valoración solicitud mermaVersión GMOActores Usuario, sistema, base de datos.Fuentes funcionariosObjetivos asociados Permitir a los funcionarios que consulten

toda la información de la merma asociada a la garantía


Precondición Es necesario que el funcionario ingrese al sistema datos para poder consultar la merma asociada a la garantía



2 Consultar merma.3 Ingresar dato básico.4 Consultar datos5 Buscar en la base de datos

Post condición Se visualiza la información registradaExcepciones Si no existe la valoración, no se visualiza

ninguna.Rendimiento 30 segundos.Urgencia Ninguno.

Caso de uso Consultar valoración solicitud merma

Página74


Diagrama de Caso de uso consultar valoración solicitud merma

Página75



2.4. DISEÑO

En esta fase se realiza una actividad mediante la cual se define el modelo de diseño del sistema, incluyendo los objetivos de diseño del proyecto y descomponiéndolo en subsistemas más pequeños que pueden ser realizados por equipos individuales. El diseño del sistema también conduce a la selección de la plataforma de hardware/software, la cual se realizará implementando la metodología OMT con notación UML.

Página76


2.4.1. Requerimientos del sistema:

2.4.1.1. Requerimientos del Hardware:

Los requerimientos mínimos para que el Sistema de Información funcione adecuadamente son los siguientes:

Servidor:

Computador con Intel DUO CORE (o superior) 2 GB de RAM (o superior). 500 GB de espacio en disco duro para las instalaciones del servidor Apache y

la base de datos.

Cliente:

Computadores de escritorio 1 GB de RAM1 (o superior). Tarjeta de Red o MODEM para acceso a la Intranet.

Los requerimientos ideales son:

Servidor:

Computador con Procesador COREi5 o superior. 4GB de memoria RAM (o Superior). Tarjeta de Red o MODEM2 para acceso a la Intranet. 1 Tera GB de espacio en disco duro para instalación del servidor Apache y la

Base de Datos.

1

2

Página77



Cliente:

Computador de escritorio 1 GB de memoria RAM o superior. Tarjeta de Red o MODEM para acceso a la Intranet.

2.4.1.2. Requerimientos del Software:

Servidor:

Sistema Operativo:

Windows 2000 Server3

Aplicaciones Instaladas:

My SQL PHP 5 Apache Adobe Acrobat Reader Versión 11.

Navegador: Se puede tener cualquiera de los siguientes navegadores:

Internet Explorer. Mozilla Firefox

Cliente:

Sistema Operativo:

Windows xp o superior. Aplicaciones Instaladas: Internet Explorer u otro navegador. Adobe Acrobat Reader Versión 11.

2.4.1.3 Aspectos Técnicos

3

Página78


Este diagrama técnico, describe también la situación con la que se maneja el reporteador, que es la plataforma donde incluimos nuestro aplicativo “Reprocesos GMO”, por lo cual la seguridad y la estructura ya había sido planteada en un proyecto anterior en GMO, y como es una necesidad adaptarse a esta plataforma, entonces simplemente re utilizaremos lo ya planteado en la compañía, para nuestro proyecto “Reproceso GMO”.

A un lado de la gráfica contamos con todos los usuarios, quienes se conectan desde diferentes ciudades del país, tenemos dos tipos principales de usuario, los asesores, quienes accederán desde las tiendas, y los jefes o comités, quienes se encuentran en la sede administrativa. En cualquier de las tiendas y en la sede administrativa, la conexión es a través de la misma red de GMO.

Todos estos clientes se conectaran al aplicativo “Reprocesos GMO”, donde se encuentra también “Procesos y Reportes” el cual se encuentra alojado en la Intranet.

Contamos después con el firewall, el cual no permitirá acceder a la intranet y por lo tanto a los aplicativos, desde un sitio diferente a todas las instalaciones de GMO.

Página79



En nuestro servidor 10.216.29.4 encontramos alojado todo el desarrollo de la aplicación, aquí esta tanto el código fuente, como los diferentes ejecutables, está en este servidor también instalado XAMPP V1.7.4, el cual es una distribución de apache totalmente gratuita, este contendrá MySQL, PHP, las cuales son dos aplicaciones totalmente necesarias para nuestro desarrollo.

Tenemos dos servidores adicionales, el 10.216.29.3, donde tenemos alojada la MultiBase, la cual es una base de datos en Cosmos, es la base de datos original y principal de toda la compañía, y recurrimos a ella para poder obtener toda la información historial de la empresa, en nuestro caso, requerimos de los encargos anteriores y principalmente de los presupuestos, para dar respuesta a el proceso, por lo cual debemos acceder a esta base de datos.

En el servidor 10.216.29.11 tenemos la base de datos MSSQ 2005, en SQL server estamos creando todas nuestras tablas para el aplicativo, aquí se aloja toda la nueva información creada, además de datos actuales del cliente de los cuales también necesitamos.

Es MSSQ 2005 una réplica de la mayoría de información que contiene nuestra MultiBase, y se actualiza parcialmente cada hora automáticamente, en las noches hay una carga réplica del resto de información que MSSQ 2005 requiere.

Los datos de nuestro aplicativo no pasan nunca a MultiBase, y se mantendrán por lo pronto, solo en SQL server.

Por último la conexión casi siempre es directa a MSSQ 2005, ya que las consultas son más fáciles de ejecutar en este tipo de base de datos, y solo en tablas que esta base de datos no tiene, se hace necesaria la conexión a MultiBase

Página80


2.4.2. Diagrama de despliegue

Diagrama de despliegue

Página81



3. Resultados

Los resultados se adjuntan como archivo anexo -> Anexo 9. Pruebas unitarias.

Como conclusión de los resultados de los diferentes objetivos se tiene:

Como objetivo general se buscaba “desarrollar e implementar una herramienta web que sistematice y automatice los “Reprocesos” que usa la empresa GMO, buscando convertir este proceso, en uno más confiable, rápido y estructurado”, el objetivo se cumplió, debido a que el sistema fue desarrollado para la empresa, cubriendo de manera automática el proceso que se daba de manera manual, en su totalidad. Cumple diferentes reglas, por lo cual es confiable y más rápido, y la dase de diseño ayuda con la estructura requerida en GMO.

Con respecto a los objetivos específicos: Tanto como “Crear un aplicativo Web que sustituya y automatice el proceso manual con el que se trabajan los “Reprocesos GMO”.” y “Diseñar e implementar un sistema de información web que sostenga el aplicativo inicial, y que a la vez permita ser consultado a través de un módulo de reportes.” Se cumplieron en su totalidad, dadas las mismas razones de cumplimiento del objetivo general.

Por su parte la “Construcción de un módulo de reportes, que permitan a la empresa consultar los estados actuales y resultados de los reprocesos, esto con el fin de mejorar el funcionamiento involucrado a reprocesos de cada área” el objetivo se cumplió en un 90%, ya que aunque existe el módulo de reportes, que sostiene la operación inicial, y que además tiene algunas funcionalidades de mas, no se logró llegar al 100% de los reportes que se hubiesen podido crear con utilidades nuevas,

Para finalizar el objetivo “Determinar el impacto del uso del aplicativo web, mediante datos históricos del actual proceso, y los nuevos resultados una vez esté implementado este.”, no logro hacerse una comparación definitiva con el proceso inicial, ya que los datos que la empresa tenía no estaban disponibles, y los que existían no eran suficientes para esto.La fase de Business Intelligence se realizara a futuro, sin tener que modificar el desarrollo actual, ya que este fue pensado y diseño, tanto en la base de datos como en la programación, para que soportara este propósito.

A continuación se adjuntan una muestra de las encuestas realizadas a las diferentes tiendas de GMO, en las cuales está en funcionamiento el aplicativo.

Página82


Página83



Página84


Página85



Página86


Página87



Podemos analizar en todas estas encuestas, la inconformidad abajo la que se encontraban trabajándolos asesores, con el proceso manual de “Reprocesos GMO”, y como muchos de ellos tuvieron que asumir costos que no consideraban justos. Vemos también como actualmente en su totalidad las tiendas están usando el aplicativo, y les genera una sensación de confiabilidad y seguridad mucho más grande que el proceso anterior, se sienten conformes también con la facilidad de manejar este software, y lo califican en promedio con 8.8, lo cual es una respuesta muy positiva, ya que la satisfacción que tienen con este es tan grande, que les gustaría de esta misma manera, automatizar algunos otros procesos que tengan oportunidades en la empresa.

A continuación se adjunta también una carta, enviada para la javeriana, por el jefe de sistemas de OPTICAS GMO COLOMBIA, donde muestra la satisfacción que genero este proyecto sobre la compañía:

Página88


Página89



4. Análisis de Impacto del Desarrollo

Los impactos que se trataran en esta sección, están todos relacionados directamente, con los resultados dados en y para la empresa GMO Colombia.

Desde el punto de vista económico podemos hablar de cómo la aplicación, al tener bajo control las fechas de vencimiento y de entrega de todas las mermas y garantías, permite un control de estas mismas, donde la única razón por la que estas fechas se vencerían, seria por descuido de los mismos empleados o proveedores, y en caso de que esta sea la razón, son ellos mismos entonces los que tienen que asumir los costos de esto, por lo cual la empresa no incurrirá en gastos de ningún tipo de reproceso. Teniendo en cuenta que al mes en GMO se reciben aproximadamente unos 800 reprocesos, y que el promedio de compra de estos esta en aproximadamente unos $200000, tenemos 160 millones mensuales que están en riesgo de tener que ser devueltos, lo cual representaría un alto porcentaje en las ventas, y en las perdidas en caso de que lleguen a tener que hacerse efectivas las devoluciones.

Desde la perspectiva disciplinar vemos como el área de sistemas, la cual está encargada de automatizar estos procesos en la empresa, estaba prestando un servicio manual, desordenado muy repetitivo y en contra de los principios del área y de la profesión, por lo cual no estaba cumpliendo en esta ocasión, con los propósitos del área en GMO, al realizar la aplicación, todas las áreas que interactúan de cualquier manera con esta aplicación, tuvieron respuestas positivas inmediatas, ya que se mejoró una parte de su proceso, y se les ahorró tiempo al no tener que llevar un registro manual de todo lo que realizan, además se sienten más seguros de que el proceso se está llevando de manera correcta, la imagen por lo tanto que proyecto el área al resto de la compañía, con esta aplicación, fue absolutamente positiva.

Desde la perspectiva social se puede tocar el tema de cómo el cliente directo final, que son los asesores, quienes al ser personas de no tan altos recursos, y no tener acceso a mucha educación, no pueden trabajar con aplicaciones muy complejas porque se confunden y pueden cometer muchos errores, por lo cual la aplicación fue pensada y construida, en un ambiente familiar y con fácil acceso para ellos, por lo que se adaptaron rápidamente. También se tiene en cuenta el hecho, de que antes de que existiera esta aplicación, muchos tenían que llevar registros en Excel, o algunos hasta a mano, por lo cual los perdían de vista, y muchas veces al exigirse la devolución, tenían que responder por el monto perdido, lo cual representaba un alto porcentaje en su salario, y era una pérdida significativa, con este aplicativo, solo con ser juiciosos, y hacer control del aplicativo, tienen la seguridad no tendrán estas pérdidas. Por ultimo quiero hablar acerca de cómo el proceso al ser tan manual, se prestaba para permitir fraudes, tanto de parte de algunos empleados hacia otros, como de empleados a la compañía, con el diseño y el desarrollo de la aplicación, los fraudes ya no pueden ser realizados, lo cual beneficio a ambas caras de la compañía.

Página90


5. Conclusiones

Con la implementación del Sistema de Información de GMO, se logró que esta fuera reconocida por su organización en el manejo de los datos, obteniendo interactividad con sus funcionarios y usuarios.

La utilización de las herramientas que ayudaron a la realización de este sistema fueron un excelente objeto de aprendizaje, puesto que en el transcurso de la carrera solo se asimila un comportamiento básico de estos programas, pero gracias a la fundamentación en el desarrollo de la lógica que la universidad inculca al estudiante, se puede comprender fácilmente su funcionamiento.

Para la creación de este proyecto es de primordial importancia tener en cuenta la planificación y estandarización de las actividades y procesos de desarrollo, igualmente una buena investigación preliminar de información, entendiendo que estos factores son la base principal en la implementación del sistema.

Es imprescindible la elección de un buen ciclo de vida, teniendo en cuenta todo el desarrollo que se maneja de acuerdo a las necesidades y las características del sistema, igualmente la reutilización de código es fundamental a la hora de cumplir los objetivos propuestos y agilizar los procesos.

Con la programación orientada a objetos en las etapas de análisis y diseño los modelos pueden llevar un proceso de pruebas, con el fin de descubrir errores antes que se trasciendan hacia una próxima iteración, haciendo que el trabajo realizado sea más productivo.

Durante todo el proceso de la práctica se realizó un alto nivel de investigación en todo el concepto que rodea el desarrollo general de un sistema de información, ayudando a que los conocimientos del practicante se retroalimenten y de igual manera experimente el compromiso que se debe tener en este tipo de proyectos.

Las franquicias que compone toda la organización GMO Colombia ahora cuentan con un sistema de información el cual les permite compartir registros de reprocesos valederos, completos, seguros y con la capacidad de tener suficiente espacio para un crecimiento progresivo.

Página91



Gracias al haber escogido esta práctica empresarial como medio de opción para optar al título de Ingeniero de Sistemas, se logró adquirir experiencia en el entorno laboral, asumiendo realmente una gran responsabilidad y aprendiendo a tener un buen trato con los compañeros de trabajo.

Página92


IV- REFERENCIAS Y BIBLIOGRAFÍA

[1] BUSSINES INTELLIGENCE. ( 2009). Qué es el Business Intelligence. Disponible en http://www.buyto.es/general-business-intelligence/que-es-y-para-que-sirve-el-business-intelligence

[2]GMO Colombia.(2014). Servicios de garantía en GMO. Disponible en http://www.gmo.com.co/servicios/

[3]LUD WINO MAR TEJADA.Ciencias especulativas.(2013). Disponible en http://ludwinomartejada.blogspot.com/2013/02/ciencias-especulativas-ciencias.html

[4]BOLETIN COMUNISTA.(2012) Disponible enhttp://www.fractioncommuniste.org/ficci_esp/b03/b03_1.html

[5] V10 VERTIS. Nuestras soluciones IT simplifican y mejoran su Logística.(2013)Disponible en http://www.grupov10.com/vertis.html)software

[6] V10 VERTIS. VERTIS - SOFTWARE PARA DEVOLUCIONES.(2013) Disponible en http://www.guiaerp.com/f/3771/vertis-software-para-devoluciones/espaa/gestin-de-almacenes/gestin-de-produccin/gestin-de-proyectos

[7] GLOBAL TECH. RMA ON LINE.(2014). Disponible en

http://www.globaltechsa.com.ar/index.php/soluciones/rma-online

[8]COMPONENTES DE CONTROL C.L RMA SOFTWARE(2014).Disponible enhttp://viii.es/v3rma.html

[9]EXPANSION.COM. Relación costo vs beneficio. RMA SOFTWARE(2014).Disponible en http://www.expansion.com/diccionario-economico/analisis-costebeneficio.html

[10] IBRUGOR.Que es php? (2014). Disponible en

http://www.ibrugor.com/blog/que-es-php-para-que-sirve/

Página93


http://www.ibrugor.com/blog/que-es-php-para-que-sirve/

http://www.globaltechsa.com.ar/index.php/soluciones/rma-online

http://www.guiaerp.com/f/3771/vertis-software-para-devoluciones/espaa/gestin-de-almacenes/gestin-de-produccin/gestin-de-proyectos

http://www.guiaerp.com/f/3771/vertis-software-para-devoluciones/espaa/gestin-de-almacenes/gestin-de-produccin/gestin-de-proyectos

http://www.grupov10.com/vertis.html)software

http://www.gmo.com.co/servicios/

http://www.buyto.es/general-business-intelligence/que-es-y-para-que-sirve-el-business-intelligence

http://www.buyto.es/general-business-intelligence/que-es-y-para-que-sirve-el-business-intelligence


[11] ALVAREZ, Miguel Angel. Breve historia de PHP.( 2009). Disponible en http://www.desarrolloweb.com/articulos/436.php

[12] Apéndice A_ Historia de PHP y proyectos relacionados.( 2000). Disponible en http://www.hospedajeydominios.com/mambo/documentacion-manual_php-pagina-history.html

[13] BUYTAERT, Dries. Why PHP (and not Java)?. (2006). Citado el 30 de septiembre de 2010. Disponible en http://buytaert.net/why-php-and-not-java

[14] JAVAZ, Jasir. Php Vs ASP.net: a simple comparison.( 2010). Disponible en http://enewsz.com/2010/01/19/php-vs-asp-net-a-simple-comparison/

[15] Historia de PHP y proyectos relacionados. (2009). Disponible en http://www.php.net/manual/es/history.php

[16]Historia de PHP. (2010). Disponible en http://www.supertutoriales.com/web-14.html

[17] MENCHACA MÉNDEZ, Rolando. Arquitectura de la Máquina Virtual Java. (2000). Disponible en http://www.revista.unam.mx/vol.1/num2/art4/index.html

[18] NASPINSKY. Asp.Net vsphp : speed comparison. (2009)Disponible en http://naspinski.net/post/AspNet-vs-php--speed-comparison.aspx

[19] SIRONI, Giorgio. Java versus PHP [on line]. (2010).Disponible en http://giorgiosironi.blogspot.com/2010/04/java-versus-php.html

[20] PÉREZ VALDÉS, Damián. Los diferentes lenguajes de programación para la web.(2007). Disponible en http://www.maestrosdelweb.com/principiantes/los-diferentes-lenguajes-de-programacion-para-la-web/

[21] PHP Vs ASP.net. (2007). Disponible en http://www.bizfive.com/articles/web-design/comparing-php-and-asp.net/

Página94

http://www.bizfive.com/articles/web-design/comparing-php-and-asp.net/

http://www.bizfive.com/articles/web-design/comparing-php-and-asp.net/

http://www.maestrosdelweb.com/principiantes/los-diferentes-lenguajes-de-programacion-para-la-web/

http://www.maestrosdelweb.com/principiantes/los-diferentes-lenguajes-de-programacion-para-la-web/

http://giorgiosironi.blogspot.com/2010/04/java-versus-php.html

http://naspinski.net/post/AspNet-vs-php--speed-comparison.aspx

http://www.revista.unam.mx/vol.1/num2/art4/index.html

http://www.supertutoriales.com/web-14.html

http://www.supertutoriales.com/web-14.html

http://www.php.net/manual/es/history.php


[22] RASEUR, Richard. PHP vs Java for Webapps- Quality & Maintainability of

Code. (2010). Disponible en

http://www.richardrauser.com/index.php/2010/01/18/php-vs-java-for-webapps-quality-maintanability-of-code/

[23] TOSUN, Hasari. PHP vs. Java.(2010). Disponible en http://www.cs.montana.edu/~tosun/phpvsjava.pdf

[24]UNIT TESTING - PRUEBAS UNITARIAS - CAP 1. Disponible en http://www.calidadysoftware.com/testing/pruebas_unitarias1.php

[25] Luxottica adquiere el control de las tiendas ópticas GMO, Sun Planet y Econópticas. (2011). Disponible en

http://www.emol.com/noticias/economia/2011/05/23/483211/luxottica-adquiere-el-control-de-las-tiendas-opticas-gmo-sun-planet-y-econopticas.html

[26] "Luxottica to Buy a U.S. Sunglasses Maker". in The New York Times June 21, 2007. 2007-06-21.

[27] Crutchfield, Dean. Forbes Disponible en http://www.forbes.com/sites/deancrutchfield/2012/11/27/luxottica-sees-itself-as-king-raising-questions-about-brand-authenticity/

[28] Agudelo, Gustavo. Ópticas GMO (2011) Disponible en: http://www.slideshare.net/gustavoagudelo/opticas-gmo

Página95


http://www.calidadysoftware.com/testing/pruebas_unitarias1.php

http://www.cs.montana.edu/~tosun/phpvsjava.pdf




IV - ANEXOS

Anexo 1. Glosario.

Anexo 2. Diagrama de flujo del sistema.

Anexo 3. Descripción de las tablas del modelo Entidad-Relación.

Anexo 4. Modulo garantías mermas.

Anexo 5. Pantallazos Sistema de información.

Anexo 6. Video sobre funcionamiento del sistema de información.

Anexo 7. Presentación propuesta.

Anexo 8. Valores de tablas.

Anexo 9. Pruebas unitarias.

Anexo 10. Actas de reuniones.

Anexo 11. Metodología Aplicada

Anexo 12. Manual Usuario

Anexo 13. Video Manual Merma

Anexo 14. Video Manual Garantía

Anexo 15. Consultar Garantías

Anexo 16. Consultar Merma

Página96

Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS01/MemoriadeTrabajode... · Web...

Documents

Transcript of Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1430IS01/MemoriadeTrabajode... · Web...