para determinar la viabilidad del proyecto, se llevó a

Para determinar la viabilidad del proyecto, se llevó a cabo una evaluación económica apoyada en la metodología Rational Unified Process (RUP). English Just like the name of the work, the general objective is to determine the functional requirements of the software. Generally, before the beginning of the software design or during the initial phase, it’s mandatory to proceed with a complete analysis of the business, the processes and the process structure on which the company works. This analysis consists of the determination of the processes map and the definition of the processes into the Macro-processes. From this point forward the work was to determine the proposed situation of the processes in order to have a base to design the use cases (This is one of the graphic and descriptive tools include in the Unified Modeling Language UML). The last step of this chapter was to determine de functional requirements of the software based on the use cases. Finally, the economic viability of the project was supported by the Rational Unified Process (RUP).

1

“DETERMINACIÓN DE LOS REQUERIMIENTOS FUNCIONALES PARA UN SOFTWARE QUE INTEGRE LOS PROCESOS OPERATIVOS DEL DISTRIBUIDOR CGC DE COMCEL”

DIEGO ALEJANDRO INFANTE PINZÓN

PONTIFICIA UNVIERSIDAD JAVERIANA FACULTAD DE INGENIERIA INDUSTRIAL

BOGOTA, D.C. 2009

2

“DETERMINACIÓN DE LOS REQUERIMIENTOS FUNCIONALES PARA UN SOFTWARE QUE INTEGRE LOS PROCESOS OPERATIVOS DEL DISTRIBUIDOR CGC DE COMCEL”

DIEGO ALEJANDRO INFANTE PINZÓN

Director: JUAN BERNARDO MERINO ZULETA

Ingeniero Industrial

PONTIFICIA UNVIERSIDAD JAVERIANA FACULTAD DE INGENIERIA INDUSTRIAL

BOGOTA, D.C. 2009

3

Contenido

1. Introducción 8 2. Objetivos 11

2.1. Objetivo general 11 2.2. Objetivos específicos 11

3. Contexto del problema 12 4. Análisis de la situación funcional actual de CGC 14

4.1. Mapa de procesos de CGC 14 4.1.1. Justificación de los cambios entre el mapa de procesos inicial y el final 16 4.1.2. Descripción del mapa de procesos final 18 4.2. Análisis de los proceso actuales 19

5. Priorización de los procesos a sistematizar 21

5.1. Identificación de los procesos operativos y su influencia sobre los administrativos 21 5.1.1. Determinación de los procesos operativos y administrativos 21 5.1.2. Determinación del grado de impacto de los procesos operativos sobre los administrativos 22 5.1.3. Procesos priorizados para sistematizar 28

6. Situación propuesta de los procesos susceptibles a sistematizar 31

6.1. Identificación de las necesidades de los usuarios 31 6.1.1. Conclusiones y aspectos importantes producto de las entrevistas 34 6.2. Diagramación y caracterización de los procesos propuestos 35 6.2.1. Caracterización de diagramas de procesos propuestos 56

7. Sistema de información y usuarios 57

7.1. Información gerencial 57 7.2. Posibles sistemas de información 57 7.2.1. Sistema a nivel operativo 58 7.2.2. Sistema a nivel administrativo 59 7.3. Tipos de datos 60 7.4. Datos vs Usuario 66 USUARIO 66 7.4.1. Usuarios del sistema 68

8. Pasos a seguir para documentar los requerimientos del software 70

8.1. Orden propuesto para documentar los requerimientos 71

9. Desarrollo de los requerimientos del usuario 74 10. Desarrollo de la especificación de los requerimientos del software 77

10.1. Conjunto de casos de uso 77 10.2. Casos de uso 78 10.3. Casos de uso por prioridad 80 10.4. Requerimientos funcionales 81 10.4.1. Requerimientos funcionales con Prioridad 10 81 10.4.2. Requerimientos funcionales con prioridad 7 87 10.4.3. Requerimientos funcionales con prioridad 5 87 10.4.4. Requerimientos funcionales con prioridad 3 89

4

11. Evaluación económica 90

11.1. Plan de trabajo para el desarrollo del software 90 11.1.1. RUP 90 11.1.1.1. Por etapas en lo macro 91 11.1.1.2. Iterativo en lo micro 92 11.1.1.3. Establece hitos claros e incrementales a través del tiempo 92 11.1.1.4 Soportado por las mejores prácticas probadas 92 11.1.2. Enfoque y preguntas clave para cada fase según IBM 93 11.1.3. Estimación del tiempo para el desarrollo del software 93 11.2 Evaluación económica 94 11.2.1. Costo del desarrollo del software 95 11.2.2. Costos iguales a cero 95 11.2.3. Costos diferentes de cero 96 11.2.4. Distribución del costo en el tiempo 98 11.2.5. Beneficios del desarrollo del software 99 11.2.6. Cálculo del beneficio 101

12. Conclusiones 103 13. Recomendaciones 104 14. Bibliografía 105

5

Anexos

Anexo 1: Diagramación del proceso Ventas 106 Anexo 2: Caracterización del proceso Ventas 107 Anexo 3: Diagramación del proceso Activaciones 110 Anexo 4: Caracterización del proceso Activaciones 111 Anexo 5: Diagramación del proceso Nomina 113 Anexo 6: Caracterización del proceso Nomina 114 Anexo 7: Diagramación del proceso Compra de equipos 115 Anexo 8: Caracterización del proceso Compra de equipos 116 Anexo 9: Diagramación del proceso Compra de recargas o Sim Card 118 Anexo 10: Caracterización del proceso Compra de recargas o Sim Card 119 Anexo 11: Diagramación del proceso Control de inventarios 121 Anexo 12: Caracterización del proceso Control de inventarios 122 Anexo 13: Diagramación del proceso Capacitaciones asesores antiguos 124 Anexo 14: Caracterización del proceso Capacitaciones de asesores antiguos 124 Anexo 15: Diagramación del proceso Capacitaciones asesores nuevos 126 Anexo 16: Caracterización del proceso Capacitaciones de asesores nuevos 127 Anexo 17: Diagramación del proceso Servicio al cliente Reposición 128 Anexo 18: Caracterización del proceso Servicio al cliente Reposición 129 Anexo 19: Diagramación del proceso Servicio al cliente Recargas 131 Anexo 20: Caracterización del proceso Servicio al cliente Recargas 132 Anexo 21: Diagramación del proceso Pago de facturas 134 Anexo 22: Caracterización del proceso Pago de facturas 135 Anexo 23: Entrevista # 1 136 Anexo 24: Entrevista # 2 137 Anexo 25: Entrevista # 3 139 Anexo 26: Entrevista # 4 140 Anexo 27: Entrevista # 5 141 Anexo 28: Entrevista # 6 143 Anexo 29: Entrevista # 7 145 Anexo 30: Guía para usar el formato de casos de uso 146 Anexo 31: Casos de uso 149 Anexo 32: Estado de resultados 2008 178 Anexo 33: Pantallas propuestas 181

Anexo 34: Proyecto de grado 186

6

Lista de tablas

Tabla 1. Justificación de los cambios entre el mapa de proceso inicial y final 16 Tabla 2. Descripción del mapa de proceso final 18 Tabla 3. Clasificación de los procesos 21 Tabla 4. Impacto 22 Tabla 5. Tipos de diagramas matriciales 22 Tabla 6. Descripción y calificación del impacto de cada proceso operativo sobre los procesos administrativos 24 Tabla 7. Diagrama matriz en L 27 Tabla 8. Puntajes diagrama matriz 28 Tabla 9. Ejemplo subvaloración de inventarios 29 Tabla 10. Preguntas de las entrevistas 31 Tabla 11. Cuadro de entrevistas 32 Tabla 12. Conclusiones y aspectos importantes de las entrevistas 34 Tabla 13. Caracterización propuesta para el proceso de ventas 37 Tabla 14. Caracterización propuesta para el proceso de activaciones 41 Tabla 15. Caracterización propuesta para el proceso de equipos y Sim Card 45 Tabla 16. Significado de siglas de codificación 47 Tabla 17. Caracterización propuesta para el proceso de control de inventarios 49 Tabla 18. Significado de siglas de codificación 50 Tabla 19. Caracterización propuesta para el proceso de Servicio al cliente reposiciòn 52 Tabla 20. Significado de siglas de codificación 53 Tabla 21. Caracterización propuesta del proceso de Servicio al cliente recargas 55 Tabla 22. Significado de siglas de codificación 55 Tabla 23. Tipos de datos 61 Tabla 24. Tratamiento de los usuarios sobre los datos 66 Tabla 25. Requerimientos del usuario 74 Tabla 26. Conjunto de casos de uso 77 Tabla 27. Casos de uso por prioridad 80 Tabla 28. Fases del RUP 91 Tabla 29. Porcentaje del tiempo total 91 Tabla 30. Disciplinas del RUP 92 Tabla 31. Preguntas claves y enfoque de cada fase según IBM 93 Tabla 32. Estimación del tiempo para el desarrollo 93 Tabla 33. Costos del desarrollo 95 Tabla 34. Costo de las pruebas 97 Tabla 35. Distribución del costo 98 Tabla 36. Distribución del beneficio 101

7

Lista de gráficos Gráfico 1. Secuencia de pensamiento 10 Gráfico 2. Mapa de procesos inicial 14 Gráfico 3. Mapa de procesos final 15 Gráfico 4. Diagrama de flujo propuesto para el proceso de ventas 36 Gráfico 5. Diagrame de flujo propuesto para el proceso de activaciones 40 Gráfico 6. Diagrama de flujo propuesto para el proceso de compra de equipos y Sim Card 44 Gráfico 7. Diagrama de flujo propuesto para el proceso de control de inventarios 48 Gráfico 8. Diagrama de flujo propuesto para el proceso de Servicio al cliente reposición 51 Gráfico 9. Diagrama de flujo propuesto para el proceso de Servicio al cliente recargas 54 Gráfico 10. Relación de los casos de uso 79 Gráfico 11. Listas caso de uso 2 81 Gráfico 12. Lista caso de uso 3 82 Gráfico 13. Lista caso de uso 5 82 Gráfico 14. Lista caso de uso 6 83 Gráfico 15. Lista caso de uso 13 83 Gráfico 16. Lista caso de uso 15 84 Gráfico 17. Lista caso de uso 16 84 Gráfico 18. Lista caso de uso 17 84 Gráfico 19. Lista caso de uso 18 85 Gráfico 20. Lista caso de uso 19 85 Gráfico 21. Lista caso de uso 23 86 Gráfico 22. Lista caso de uso 8 87 Gráfico 23. Listas caso de uso 10 87 Gráfico 24. Lista caso de uso 14 88 Gráfico 25. Lista caso de uso 21 88 Gráfico 26. Lista caso de uso 24 88 Gráfico 27. Lista caso de uso 7 89 Gráfico 28. Hump chart / Tabla de joroba 90

8

1. Introducción El presente trabajo de grado que tiene como título “Determinación de los requerimientos funcionales para un software que integre los procesos operativos del distribuidor CGC de Comcel”. Como su nombre lo dice, el objetivo general es determinar los requerimientos funcionales de un software. Generalmente, antes de emprender un desarrollo de software o durante su fase inicial, es necesario llevar a cabo un análisis profundo del negocio, sus procesos y en general la estructura de procesos sobre la cual la compañía trabaja. Si este análisis no se hace, es muy posible que los requerimientos funcionales que se levanten sean inservibles y que los resultados de la sistematización no sean los esperados. Desarrollar este análisis preliminar de los procesos en CGC no fue fácil. En el pasado, CGC, contrató 2 personas para levantar los procesos. Al parecer las personas que hicieron este trabajo no tenían muy claro el concepto de proceso y todo lo demás que esto conlleva, por esta razón la conceptualización de la estructura del mapa de procesos y por ende los procesos estaban mal diseñados. El mapa de procesos que se encontró en la compañía tiene características típicas de un mapa mal levantado: Gran cantidad de macro procesos; aparecen muchos actores (diferentes al cliente) en la entrada y en la salida del mapa; actores alrededor del mapa que no cumplen ninguna función; macro procesos que no le agregan valor al producto dentro de los macro procesos misionales; en resumen, un sinfín de errores conceptuales que no dejaban claramente planteado cual era la estructura funcional de la empresa. Dado lo anterior, el principio del trabajo fue precisamente el levantamiento del mapa de procesos correcto de CGC. Luego se prosiguió a definir los procesos dentro de los macro procesos. Una vez se tuvieron los procesos, el panorama del negocio se empezó a vislumbrar de una manera más clara. De ahí en adelante fue más fácil documentar los procesos. Para lograr lo anterior se diagramaron y se caracterizaron la mayoría de los procesos de CGC. Se dejaron por fueran aquellos que no estaban dentro del alcance de este trabajo de grado. Esta modelación del negocio, a partir de diagramas de flujo y caracterizaciones, se determinó con el fin de tener una situación actual de los procesos facilitando así la reorganización de los mismos. Retomando el nombre del proyecto, se puede ver claramente su alcance: no se van a analizar todos los procesos de CGC. Para levantar los requerimientos, únicamente se tendrán en cuenta los operativos. Dado que la magnitud de los requerimientos a sistematizar puede ser alta se hizo una priorización de los procesos a sistematizar. Esta se determinó a través de un diagrama matriz. De esta priorización y del diseño de una entrevista y aplicación de la misma a los actores de los procesos, nacieron los diagramas y caracterizaciones que responden a la situación propuesta de los procesos operativos del negocio. Una vez se obtuvo la situación propuesta de los procesos a sistematizar, fue clave para el proyecto empezar a indagar dentro de los mismos procesos a cerca de información que se maneja, flujos normales de las actividades, relación de los actores de los procesos con el

9

actual software, y en general información que empezara a alimentar la definición de los requerimientos funcionales. Para levantar esta información se usaron las entrevistas y adicionalmente se interactuó directamente con estos actores para entrar a definir detalles mucho más profundos de los procesos. Toda esta información que se levantó fue el apalancamiento para determinar los posibles usuarios del sistema y posteriormente levantar sus requerimientos. Es importante hacer claridad que los requerimientos de los usuarios son diferentes a los requerimientos funcionales, los requerimientos del usuario son declaraciones en lenguaje natural de los servicios que se espera que el sistema provea y los requerimientos funcionales son las descripciones formales de un conjunto de elementos que describen la funcionalidad o los servicios que se espera que el sistema provea. A esta altura del trabajo se escogió la metodología para levantar los requerimientos. Luego de esta investigación acerca de desarrollo de software, se escogió la herramienta (UML) y una metodología (RUP) que guiaron el trabajo hasta el final. La primera se llama UML (Unified modeling language) y se trata de una herramienta común entre los diseñadores de software. Es la herramienta más utilizada y más completa en el medio. Brinda diversos elementos gráficos para modelar el desarrollo del software. Dentro de todos los elementos que ofrece UML están los casos de uso, esta fue la herramienta fundamental para levantar los requerimientos funcionales, su propósito es dar un panorama gráfico de lo que serían las interacciones de los usuarios con el sistema. Además de esto, se hizo uso del formato para documentar los casos de uso diseñado por Karl E. Weigers, autor de varios libros de requerimientos para software. La razón; el formato de Karl E. Weigers es mucho más completo que la herramienta de documentación de UML sin dejar de lado que su apoyo gráfico fue clave para el entendimiento de los casos de uso. De los casos de uso nacen los requerimientos funcionales. En un desarrollo de software óptimo la relación entre los casos de uso y los requerimientos funcionales debe ser 1 a 1. Posteriormente se procedió a evaluar económicamente el proyecto. Aquí es donde entra en uso la metodología RUP (Rational unified process). Una de las prácticas en las cuales se basa esta metodología es UML, razón por la cual fue pertinente diseñar el plan de trabajo para el desarrollo bajo esta metodología. Para terminar, luego de que se tenía diseñado el plan de trabajo se llevó a cabo la evaluación económica del proyecto tomando en cuenta el tiempo que tomará llevar a término el proyecto. En el gráfico 1 se encuentran la secuencia del pensamiento que se siguió para alcanzar el objetivo del trabajo de grado.

10

Gráfico 1. Secuencia de pensamiento

Fuente: Autor del presente trabajo

11

2. Objetivos 2.1. Objetivo general Determinar los requerimientos funcionales necesarios para el desarrollo de un software, que integre los procesos operativos susceptibles de sistematización en la empresa CGC.

2.2. Objetivos específicos

• Identificar los procesos operativos, su influencia sobre los administrativos y de esta manera determinar cuáles procesos deben tener prioridad o son susceptibles para su sistematización.

• Determinar los requerimientos de los usuarios del software para los procesos que se

priorice sistematizar.

• Definir los requerimientos funcionales del software.

• Basados en la Estimación económica del desarrollo de software y el plan de trabajo para la implementación, realizar una evaluación económica del proyecto.

12

3. Contexto del problema En marzo del 2003 CGC, una compañía con sede principal en Bogotá, se convirtió oficialmente en un distribuidor de Comcel. En ese año firmó un contrato a término indefinido para comercializar en forma exclusiva sus productos (planes de voz y planes de datos), prestar servicio post venta a sus clientes (Recargas y reposiciones) y recaudar facturación de clientes en la región centro-oriental de Colombia, comprometiéndose también a cumplir con metas u objetivos que Comcel asigna mensualmente (Promedio mes 2008 – 7.000 nuevos clientes). Esta es la compañía que va a ser objeto de estudio en el presente trabajo. Teniendo en cuenta que el Departamento de Cundinamarca y Distrito Capital representa el 50% del potencial de clientes del mercado celular en Colombia, CGC definió concentrar sus operaciones en esta zona, buscando así crecer en el futuro en los Departamentos de Boyacá, Casanare, Santander, Norte de Santander, Tolima, Huila y Antiguos Territorios Nacionales. Hasta el momento no se ha expandido a estos departamentos pero si ha crecido en relación con algunos distribuidores; cuenta con 9 Centros de Pago y Servicio (CPS: Centro de pagos y servicios), 7 en Bogotá, 1 en La Vega y 1 en Villeta; adicionalmente, cuenta con 215 puntos de sub distribuidores repartidos en todos los puntos de la ciudad de Bogotá. Desde el 2003 hasta el 2008 el porcentaje de cumplimiento de metas de ventas más bajo que tuvo fue del 75% y los porcentajes más altos superan el 110%. Estos porcentajes le han garantizado siempre un puesto dentro de los 3 mejores distribuidores de Comcel. La nomina de CGC cuenta con 79 empleados divididos en 35 vendedores y 44 empleados administrativos y operacionales, lo cual significa que se ha convertido en una mediana empresa gracias a su crecimiento acelerado, razón que los llevó a buscar soluciones informáticas para integrar y automatizar sus procesos. En esta búsqueda, la compañía le prestó atención a un ex directivo de Comcel que estaba liderando el desarrollo de un software que integraba los procesos operativos de los distribuidores de Comcel. Luego de comprarlo por $20’000.000 y de comprometerse a pagar $800.000 mensuales para su administración, se dieron cuenta que debieron tomarlo en arrendamiento para llevar a cabo las pruebas necesarias. Desafortunadamente el hecho de no haber realizado pruebas con el software (Software actual) les ocasionó algunos inconvenientes. Luego de la implementación del software actual, las directivas de CGC se dieron cuenta de todas las falencias que tenía y por lo tanto optaron por re parametrizarlo de tal manera que satisficiera sus necesidades. Ésta re parametrización culminó sin mucho éxito, razón por la cual pensaron que un desarrollo de software propio es la solución. Además de que la re parametrización no fue exitosa la razón por la cual no pueden corregir los errores del software actual es que luego de incurrir en todos los costos que significaron los errores del software actual las relaciones con el proveedor del software se deterioraron al punto en que se le revocó la licencia del software a CGC. En un principio, y a simple vista, el software actual tenía muchos problemas referentes a la interacción con sus usuarios, pero luego de un buen tiempo se presentaron nuevos problemas más preocupantes que los problemas con los usuarios. Uno de estos problemas fue que el software actual distorsionó los costos de los inventarios. En un principio cuando el software arrojó los primeros informes no fue preocupante, ya que como las personas no estaban capacitadas en su totalidad para manipular el software pensaron que el error

13

había sido humano. Luego de la valorización de los inventarios físicos se dieron cuenta que esta valorización estaba arrojando un valor por debajo del valor del inventario en el balance general. En ese momento todos los demás errores parecían no importarle a la gerencia de CGC ya que el software actual estaba subvalorando el costo de inventario, arrojando utilidades muy altas para los años 2006 y 2007. Lo realmente preocupante no fue la subvaloración de los inventarios sino que al final del ejercicio 2006 y 2007 la compañía repartió utilidades irreales a los socios, generando iliquidez en la misma. Luego de darse cuenta del mal manejo que el software actual le daba a los inventarios, la gerencia de CGC, se convenció de que la solución era un desarrollo inhouse.

14

4. Análisis de la situación funcional actual de CGC

4.1. Mapa de procesos de CGC

El gráfico 2, es el mapa de procesos inicial que fue proporcionado por CGC. Acá se puede ver con claridad diferentes problemas conceptuales en la definición de los procesos de la empresa:

Gran cantidad de “actores” que intervienen en cada lado del mapa Demasiados macro procesos Macro procesos que no le agregan valor al producto haciendo parte de los macro procesos

misionales. Los macro procesos misionales están separados en dos líneas, una para el cliente y otra

para los sub distribuidores. Al dividir los macro procesos misionales se da a entender que la compañía maneja 2 o más productos totalmente diferentes y esta no es la realidad de CGC.

Macro procesos que no constituyen un macro proceso, y en algunos casos ni siquiera constituyen un proceso. Ejemplo: Un macro proceso para la atención del PBX.

Tomando como punto de partida este mapa de procesos se generó una base sobre la cual se dio inicio al trabajo. El punto de partida fue una errada estructura funcional de la compañía.

Gráfico 2. Mapa de procesos inicial

Fuente: Comunicaciones Globales Colombia (CGC) El propósito de diseñar un nuevo mapa de procesos es generar un mejor entendimiento del negocio y de sus procesos. Básicamente se trata de establecer una estructura funcional clara para la compañía. En el marco del trabajo de grado, este mapa nos facilitará el correcto levantamiento de los procesos y sus respectivas actividades.

15

A partir de este mapa de procesos (Gráfico 2) se generó el mapa de procesos final de CGC (Gráfico 3). Todos los cambios que se generaron del mapa de procesos inicial al final están explicados en la tabla 1 “Justificación de los cambios entre el mapa de procesos inicial y el final”. Luego de haber diseñado el mapa de procesos final de CGC (gráfico 3), se hizo más evidente la falta de análisis en sus propios procesos por parte de la compañía, la mala estructura de procesos que manejaba, la no claridad de los productos que ofrecen y por ende la incapacidad de ubicar los procesos postventa y demás procesos de soporte. La parte estratégica es más flexible a la hora de hacer el mapa de procesos. Por lo general las compañías siempre apuntan a determinar un macro proceso de definición y evaluación de objetivos y otro de lineamientos estratégicos, que es básicamente lo que tenían en el mapa de procesos inicial pero mal estructurado. Gráfico 3. Mapa de procesos final

PRO

DU

CTO

S

NEC

ESID

AD

ES D

E LO

S C

LIE

NTE

S

CLIEN

TES SATISFEC

HO

S


16

4.1.1. Justificación de los cambios entre el mapa de procesos inicial y el final

La transición entre el mapa de procesos que nos entregó la compañía y el mapa de procesos final se encuentra justificada en el siguiente cuadro. Las razones por las cuales se desarrollaron las reubicaciones, eliminaciones y cambio de orientación estratégica están explicadas a continuación (tabla 1):

Tabla 1. Justificación de los cambios entre el mapa de procesos inicial y final

MA

CR

O

PRO

CES

O

CAMBIOS

PRO

CES

OS

DE

DIR

ECC

IÓN

El nombre cambió a macro procesos de direccionamiento estratégico, porque de los macro procesos que tiene esta categoría dependen; - El rumbo que tome la empresa - Las decisiones que afectan a todos los empleados - La permanencia y crecimiento de la empresa en el mercado. Las "Políticas y directrices generales" no representan un macro proceso. Los lineamientos estratégicos de una compañía se definen y se reevalúan periódicamente. Tal como estaba planteado en el primer mapa de procesos, se podía interpretar como si las políticas y las directrices generales fueran estacionarias y no dinámicas, cuando en realidad son un proceso de definición y reevaluación constante. Por esta razón se eliminó este "macro proceso" y se reemplazó por el proceso "Definición o reevaluación de los lineamientos estratégicos". Los "procesos de junta directiva" no representan un macro proceso ni tampoco un proceso. Las juntas directivas varían según las necesidades de la empresa, y al ser una reunión tan cambiante no se puede diseñar un proceso para la misma. Los "procesos de gerencia" no representan un macro proceso ni tampoco un proceso. Las actividades que se llevan a cabo en cualquier gerencia (de ventas, financiera, de mercado, etc.) aparecen dentro de muchos procesos en la compañía, pero no representan procesos por si solas. El macro proceso que se encuentra ahora en la categoría de "Macro procesos de direccionamiento estratégico" es "Gestión estratégica".

PRES

TAC

IÓN

DEL

SER

VIC

IO G

ENER

AC

IÓN

DE

VALO

R

El nombre que propone el primer mapa de procesos para esta categoría es "Prestación del servicio y generación de valor". Este nombre cambió a "Macro procesos misionales" ya que de esta manera no se limita solo a los servicio y la generación de valor. Por otro lado, el nombre "Prestación del servicio y generación de valor" no dejaba claro el concepto de macro proceso, lo cual se puede prestar para malentendidos, en cambio, "Macro procesos misionales" resume todas los actividades que le agregan valor al producto y deja claro que es una categoría de Macro procesos. En esta categoría se estaban planteando dos líneas de macro procesos, una para el cliente y otra para el sub distribuidor. Primero, en la categoría de macro procesos misionales no hace falta hacer claridad que estos procesos benefician al cliente, segundo, para efectos prácticos los sub distribuidores son equivalentes a un vendedor, por lo que generar estas dos líneas es innecesario. Por estas dos razones en el nuevo mapa de procesos aparecerá una sola línea. Los macro proceso incluidos en la categoría “Macro procesos misionales” le agregan valor al producto directamente. Los procesos que conforman la "Gestión Comercial" en CGC son las capacitaciones para asesores nuevos y antiguos, estos procesos no le agregan valor directamente al producto, por lo tanto pertenecen a la categoría “Macro procesos de apoyo o soporte” En CGC el “Servicio al cliente” se considera un “Soporte al servicio” ya que cuando un cliente adquiere un producto (un plan de voz o de datos) y vuelve a pagar la factura generada por Comcel o a hacer una reposición, se está le está brindando un soporte al servicio que se le prestó. "Activación" es un macro proceso que le agrega valor a cliente, ya que un celular sin activar no cumple su función principal. La palabra "Inventarios" es muy vaga a la hora de interpretarla en un mapa de procesos. Si estuviéramos hablando de "Control de Inventarios", no constituiría un macro proceso. El "control de inventarios" es un proceso de soporte que está inmerso en la "Gestión Administrativa" y no le agrega valor al producto. En un CPS se llevan a cabo dos tipos de recaudos: Recaudo del dinero de las facturas generadas por Comcel y recaudo del dinero de ventas en un CPS o en un sub distribuidor. En ninguno de estos dos tipos de recaudos se le da valor agregado al producto, por lo tanto no constituye un macro proceso misional. El "Pago de facturas" o recaudo del dinero es un proceso de soporte dentro del macro proceso soporte al servicio, ya que luego de una venta de un celular se le ofrece al cliente un soporte al servicio para el pago de su factura. El "Pago de comisiones" no constituye un macro proceso ni tampoco un proceso. Esta actividad es muy sencilla ya que consta de filtros en Excel para la liquidación de las comisiones y además es una actividad administrativa que no

17

MA

CR

O

PRO

CES

O

CAMBIOS

le genera valor al producto. La "Venta" es un macro proceso que le agrega valor al cliente, por esta razón este macro proceso se conservará en el nuevo mapa de procesos.

PRO

CES

OS

SOPO

RTE

El nombre de esta categoría cambió únicamente para dejar claro que es una categoría de macro procesos. El nuevo nombre es "Macro procesos de apoyo o soporte". "Gestión comercial" es un macro proceso que le da soporte al macro proceso de "Venta" ya que las capacitaciones de los vendedores nuevos y antiguos depende de la "Gestión comercial". La "Tesorería" por definición es la ejecución de pagos y cobros, la gestión de caja y diversas gestiones bancarias. Este proceso se conservó en el macro proceso “Gestión financiera”. "Contabilidad" y "Revisoría fiscal" son procesos que soportan las actividades de la compañía y están incluidos como procesos de la "Gestión financiera". "Control interno" es un área de las compañías que controla la efectividad de las funciones administrativas y otros aspectos del desarrollo de la empresa, como crecimiento, rentabilidad y liquidez, pero en general es un área que, como lo dice su nombre, controla; mide y evalúa los indicadores de la compañía con el ánimo de proponer ideas para mejorar los procesos. Por lo tanto no constituye un proceso dentro de la compañía. Anteriormente se había tocado el tema de "Pago de comisiones" y debido a su simplicidad no puede constituir un macro proceso por sí solo. Los "Sistemas" son simplemente un medio a través del cual se llevan a cabo procesos o actividades de las compañías, por esta razón no se puede considerar como un macro proceso. Las "Activaciones" son un macro proceso que le agrega valor al cliente, lo cual lo excluye inmediatamente de la categoría de "Macro procesos de apoyo o soporte" y lo ubica en la de "Macro procesos misionales" como ya se había mencionado antes. Las "Cajas" no representan un proceso por si solas ya que su función consiste en recaudar dinero y almacenar mercancía. La "Coordinación de CPS" se puede considerar como el nombre que se le da al cargo de la persona que lidera el proceso de "Capacitaciones para vendedores antiguos y nuevos", pero no se pude considerar como un proceso ya que de todas las funciones que cumple un coordinador, la única que es un proceso es "capacitaciones", las demás funciones son muy cambiantes ya que se basan en gestión de personal. "PBX" por sus siglas en ingles significa Private Branch Exchange cuya traducción al español seria intercambio de sucursales privadas. Se trata de una central telefónica conectada directamente a la red pública de teléfono para gestionar, además de las llamadas internas, las entrantes y salientes con la posibilidad de utilizar cualquier otra central telefónica. Esta definición deja claro que PBX es un dispositivo o un sistema de líneas que facilita la gestión de las llamadas de la compañía y no puede ser tratado como un proceso por ninguna razón. La "Coordinación de servicio al cliente" es el cargo de la persona que interviene en el proceso de "Pago de facturas" en el momento que el cliente no trae la factura impresa. Esta persona la imprime, la diligencia y se la entrega al cliente para que prosiga a pagarla en la caja. Al ser un actor de un proceso no se puede tratar como un proceso. "Compras" se sustituyó por los procesos "Compra de equipos" y "Compras de recargas y Sim Card", pero no se pueden considerar como un macro proceso ya que su alcance no es suficiente. El proceso de selección de personal y nomina en CGC es un outsourcing a cargo de la compañía THR, por lo tanto, no puede ser tratado como un proceso o un macro-proceso. Los "Servicios Generales" son todas las actividades de aseo de los CPS y como tal no soporta ningún macro proceso misional ni de direccionamiento estratégico, por lo tanto no puede ser tratado como un macro proceso de apoyo o soporte. El "Comité ejecutivo", "Comité de gerencia" y "Comité de gestión" son reuniones que se llevan a cabo con el objetivo de evaluar situaciones de la compañía en diferentes ámbitos. Estas reuniones o comités tienen un orden pero no son siempre iguales, es decir, al igual que los "Procesos de junta directiva" son actividades cambiantes y que depende de las necesidades de la compañía. Por esta razón no pueden ser tratados como Macro procesos.

En los extremos laterales del mapa de procesos inicial (gráfico 2) se pueden apreciar varios actores. En un mapa de procesos bien diseñado solo entra el cliente con necesidades y sale satisfecho.


18

4.1.2. Descripción del mapa de procesos final

En la tabla 2 se describe el nuevo mapa de procesos de CGC con sus respectivos macro procesos y procesos. Además, se explica porque se decidió no diagramar algunos de estos procesos o donde encontrar los que si se diagramaron (Los diagramas se encuentra anexos a este trabajo y hacen parte de la sección 4.1.3. Análisis de los procesos actuales).

Tabla 2. Descripción del mapa de procesos final

MACRO PROCESO PROCESOS DIAGRAMACIÓN

Gestión estratégica

Definición o reevaluación de los

lineamientos estratégicos

Este proceso seria corto y no es parte del alcance del estudio

Definición de objetivos a corto plazo Este proceso seria corto y no es parte del alcance del estudio

Control de objetivos a corto plazo

Este proceso en su mayoría es de creatividad y como tal es imposible estandarizar algo tan variable. No se diagrama este proceso por no estar dentro del alcance del estudio.

Ventas Ventas Anexo 1 (Diagramas de procesos) Activaciones Activaciones Anexo 3 (Diagramas de procesos)

Gestión administrativa

Nomina Anexo 5 (Diagramas de procesos)

Soporte al software

Este proceso está direccionado a brindar un soporte al software que se diseñe, por tal razón es recomendable diseñarlo luego de su implementación. Si el software no está diseñado e implementado el proceso no responderá a las condiciones reales del software. El soporte a Sicacom y a Poliedro es proporcionado por Comcel de manera que no hay necesidad de tener una persona encargada del soporte a estos software.

Compra de equipos Anexo 7 (Diagramas de procesos) Compra de recargas o

Sim Card Anexo 9 (Diagramas de procesos)

Control de inventarios

Anexo 11 (Archivo Diagramas de procesos) Este proceso se lleva a cabo mensualmente y semestralmente. Semestralmente el actor que solicita la justificación de inventario es Comcel y el que la procesa es el Coordinador Administrativo, en cambio, mensualmente el actor que solicita la justificación de inventarios es el Coordinador Administrativo y el que la procesa es el Coordinador de CPS. Lo demás permanece igual.

Gestión comercial

Capacitaciones para vendedores antiguos y

nuevos Anexo 13 y 15 (Diagramas de procesos)

Gestión financiera

Tesorería

El es proceso que se encarga de recibir los ingresos de la compañía y administrarlos de manera correcta. Este proceso es “relativamente estándar en todas las compañías”, por esta razón la diagramación del mismo no aporta al estudio. No se diagrama este proceso por no estar dentro del alcance del estudio.

Contabilidad

Los procesos que lleva a cabo un asistente de contaduría o un contador, en su mayoría, “son estándar” para cualquier tipo de empresa, por esta razón diagramar estos procesos sería inútil para el estudio. No se diagrama este proceso por no estar dentro del alcance del estudio.

Revisoría fiscal Los procesos de un revisor fiscal son “relativamente” estándar para cualquier empresa e inútiles para el estudio, ya que prácticamente se trata de una auditoría.

Soporte al servicio

Servicio al cliente Reposición Anexo 17 (Diagramas de procesos)

Servicio al cliente Recargas Anexo 19 (Diagramas de procesos)

Pago de facturas Anexo 21 (Diagramas de procesos) Fuente: Autor del presente trabajo

19

4.2. Análisis de los proceso actuales

En esta sección se encuentran los diagramas de flujo de los procesos actuales de CGC (Estos diagramas se encuentra en los anexos 1, 3, 5, 7, 9, 11, 13, 15, 17, 19 y 21). Los procesos se diagramaron con la ayuda de los actores que interactúan en los diferentes procesos, y se complementaron con la observación del flujo real de los mismos. Esta diagramación se hizo para determinar de manera clara el flujo actual de los procesos. Analizando los procesos a través de esta herramienta se pudieron observar errores como:

• Duplicación de documentos • Reproceso de información • Actores importantes ausentes en los procesos • Ausencia de actividades necesarias • Responsabilidades mal asignadas

A partir de la información suministrada por los empleados o actores de los procesos de los diagramas que se determinaron anteriormente, se construyeron las caracterizaciones de cada proceso (Las caracterizaciones se encuentran en los anexos 2, 4, 6, 8, 10, 12, 14, 16, 18, 20 y 22). Estas caracterizaciones constan de los siguientes elementos: Macro proceso: Macro procesos al cual pertenece el proceso caracterizado. Proceso: Proceso caracterizado. Objetivo: Meta o finalidad a cumplir con este proceso. Líder o responsable del proceso: Persona responsable de que este proceso se lleve a cabo de forma correcta. Actividades: Acción que se lleva a cabo en el proceso. Entrada: Todas las actividades de los procesos requieren entradas para su ejecución. Estas entradas pueden ser materiales, necesidades, información, etc. Salida: Al igual que las entradas, el producto de la actividad es una salida, la cual se materializa en materiales, necesidades, información, etc. Formato de entrada y salida: Se trata de la forma en la cual se presenta la entrada o la salida. Proceso proveedor de la entrada: Cualquier entrada de una actividad tiene que ser generada por otro proceso o por el proceso caracterizado. Este proceso se especificado en este espacio. Proceso cliente de la salida: Al igual que las entradas son generadas por algún proceso, las salidas son utilizadas por algún proceso. Estos procesos que se benefician de las salidas de las actividades, son especificados en este espacio.

20

Procesos relacionados: A lo largo del proceso existen procesos proveedores de entradas o clientes de las salidas. Estos son ejemplo de lo que podrían ser procesos relacionados a el proceso caracterizado. Recursos: En este espacio se especifican los recursos humanos, económicos, físicos y electrónicos que se utilizan a través del proceso. Documentos internos: En este espacio se especifican los documentos que se generan en CGC y que se utilizan o se generan a través del proceso. Documentos externos: En este espacio se especifican los documentos que se no genera CGC y que se utilizan o se generan a través del proceso. Indicadores: Se trata de la forma en la cual es medido el desempeño del proceso o elementos del mismo. Es importante aclarar que tanto en el proceso de ventas como en el de activaciones no se desarrollo la codificación de los documentos debido a que todos los documentos usados a través de los procesos son proporcionados por Comcel y no deben sufrir ningún tipo de modificación por parte del distribuidor. Por último se identificaron oportunidades de mejora como:

• Codificación de los documentos (La codificación de las caracterizaciones es propuesta por el autor del trabajo)

• Información reprocesada • Posible digitalización de información.

La diagramación y caracterización de los procesos actuales de CGC clarifica la actividad de la empresa y brinda una base para la situación propuesta de los procesos susceptibles a sistematizar (Capitulo 6. situación propuesta de los procesos susceptibles a sistematizar). Con el desarrollo de la situación propuesta se garantiza que los requerimientos funcionales respondan a unos procesos estructurados y bien diseñados, de otra forma cualquier modificación futura en el diseño de los procesos repercute significativamente sobre los requerimientos funcionales del software. Esta es la razón por la cual tener claros los procesos actuales es vital para el proyecto.

21

5. Priorización de los procesos a sistematizar

5.1. Identificación de los procesos operativos y su influencia sobre los administrativos 5.1.1. Determinación de los procesos operativos y administrativos Dado que se elaboró una diagramación y caracterización preliminar de los procesos de CGC, y tomando en cuenta la relación entre ellos, es ahora necesario priorizar los procesos. Si no se hace ahora, el alcance del trabajo puede verse comprometido.

Luego de una entrevista con el Gerente General y con el Coordinador Administrativo de CGC, donde se analizaron los diagramas de flujo de los procesos con sus respectivas caracterizaciones, se concluyó que los procesos operativos son aquellos que tienen connotación de ejecución de las actividades propias del negocio y es necesario ejecutarlos permanentemente para poder agregar valor al producto o al servicio post-venta que se le presta al cliente final. Por otro lado, los procesos administrativos son aquellos que tienen como objeto direccionar el funcionamiento del negocio y están compuestos por las funciones de planeación, organización y control. A partir de estas definiciones se determinaron cuales procesos de la compañía son operativos y cuales son administrativos (tabla 3):

Tabla 3. Clasificación de los procesos MACRO PROCESO PROCESOS Tipo de proceso

Gestión estratégica

Definición o reevaluación de los lineamientos estratégicos Administrativo

Definición de objetivos a corto plazo Administrativo

Control de objetivos a corto plazo Administrativo

Ventas Ventas Operativo

Activaciones Activación Operativo

Gestión administrativa

Nomina Administrativo

Compra de equipos Operativo

Compra de recargas o Sim Card Operativo

Control de inventarios Operativo

Gestión comercial Capacitaciones para asesores antiguos y nuevos Operativo

Gestión financiera Contabilidad Administrativo

Revisoría fiscal Administrativo

Soporte al servicio

Servicio al cliente Reposición Operativo

Servicio al cliente Recargas Operativo

Pago de facturas Operativo


22

5.1.2. Determinación del grado de impacto de los procesos operativos sobre los administrativos

En función de la priorización de los procesos operativos susceptibles a sistematizar, es necesario determinar el grado de impacto de los estos procesos sobre los administrativos. Este grado de impacto se cuantificará a través de la herramienta diagrama matriz1. A continuación se encuentra el desarrollo de esta herramienta dentro del marco del trabajo de grado. Objetivos de la construcción del diagrama: Determinar el grado de impacto de los procesos operativos sobre los administrativos.

Definición del impacto: Grado de afectación en el cual generar información no fiable en un proceso operativo afecta un proceso administrativo.

Tabla 4. Impacto

Grado Explicación0 La información generada en el proceso operativo no afecta de ninguna manera el proceso administrativo. 1 La información no fiable generada en el proceso operativo afecta de manera leve el proceso administrativo.

2 La información no fiable generada en el proceso operativo causa dificultades en el flujo normal del proceso administrativo.

3 La información no fiable generada en el proceso operativo impide que el proceso administrativo se lleve a cabo eficiente y eficazmente.

Fuente: Autor del presente trabajo Existen diferentes tipos de diagramas matriciales dependiendo del número de factores que se quieran relacionar. Los factores representan las variables que se van a estudiar en el diagrama. Diagramas matriciales:

Tabla 5. Tipos de Diagramas matriciales Tipo de diagrama Explicación Gráfico

Diagrama matricial en L Es el diagrama matricial básico, se utiliza para representar relaciones entre 2 tipos de factores distintos

Diagrama matricial en A Este modelo de diagrama es un caso particular del diagrama matricial en L. Se utiliza para representar las relaciones entre los factores que componen un tipo determinado A.

Diagrma matricial en T Es la combinación de 2 diagramas matriciales en L. se utiliza para representar la relación entre 3 tipos de factores distintos

1 http://www.fundibeq.org/metodologias/herramientas/diagrama_matricial.pdf; Consultada el 10/09/09 7:14 pm

23

Tipo de diagrama Explicación Gráfico Diagrama matricial en Y Es la combinación de 3 diagramas

matriciales en L. Se utiliza para representar relaciones entre 3 tipos distintos de factores.

Diagrama matricial en X Es la combinación entre 4 diagramas matriciales en L. Se utiliza para representar las relaciones entre cuatro tipos de factores diferentes.

Diagrama matricial en C Se utiliza para representar las relaciones entre tres tipos de factores diferentes, teniendo en consideración 3 puntos de vista simultáneamente.

Fuente: http://www.fundibeq.org/metodologias/herramientas/diagrama_matricial.pdf

En este caso los factores son los procesos operativos y los administrativos y se analizarán bajo un diagrama matricial en L. Tipos de factores: 1) Procesos administrativos 2) Procesos operativos. La identificación de los factores que intervienen en cada diagrama no tiene una metodología definida ya que pueden ser de muy diversas clases. En general es necesario el uso de otra herramienta para desarrollar este paso como por ejemplo:

Lluvia de ideas Diagrama de árbol Encuestas Estudios de mercado Análisis sobre diagramas de flujo (Diagramas de flujo de los procesos actuales de CGC

Anexos impares del 1 al 21): Esta fue la herramienta que se utilizó y el análisis se llevó a cabo junto con el Gerente general y el Coordinador administrativo de CGC, como se mencionó anteriormente

En la tabla 6 se explica y cuantifica el impacto que tiene cada uno de los procesos operativos sobre los administrativos. Los procesos a los cuales se les asocie un impacto mayor o igual al 10 % del total serán susceptibles a sistematizar.

24

Tabla 6. Descripción y calificación del impacto de cada proceso operativo sobre los procesos administrativos

Proceso operativo Proceso

administrativo Impacto Calificación

Ventas

Definición o reevaluación de los lineamientos

estratégicos

No hay. 0

Ventas Definición de

objetivos a corto plazo

Dificultad para la definición de los pronósticos de demanda mensuales (estacionales): La información usada para los pronósticos es brindada por Poliedro. La información ingresada en Poliedro es generada por el área de ventas, por lo tanto los errores en la información de ventas afectarían la definición de los objetivos de ventas de CGC.

3

Ventas Control de


Si se genera información de ventas incorrecta se dificulta el control de los objetivos a corto plazo. 2

Ventas Nomina

Los asesores de ventas en CGC son medidos a través de la información de ventas; Las novedades de nomina de asesores de ventas se basan en las evaluaciones de los mismos, por lo tanto, información no fiable de ventas dificultaría la generación de novedades de nomina de la compañía.

2

Ventas Contabilidad Información no fiable de ventas afectaría gravemente los estados financieros generados en contabilidad 3

Ventas Tesorería La generación de información no fiable de ventas dificultaría el cálculo del flujo de caja, dando lugar a malas decisiones del tesorero.

2

Ventas Revisoría fiscal No hay. 0

Activación


estratégicos

No hay. 0

Activación Definición de


Mensualmente se establecen metas de un mínimo de errores para los activadores dependiendo de su desempeño en el mes anterior. La generación de información no fiable en activaciones afectaría la definición de estos objetivos. Por otro lado, la información de ventas se basa en las de activaciones, por ende, si la información de activaciones no es fiable también afecta los pronósticos de demanda mensuales.

3

Activación Control de


La generación de información no fiable de activaciones dificultaría el control de los objetivos de errores mínimos definidos para un periodo en específico.

2

Activación Nomina No hay. 0

Activación Contabilidad

Información no fiable de activaciones dificultaría la generación de estados financieros de la compañía ya que como ya se dijo, la información de ventas está basada en la información de activaciones.

3

Activación Tesorería No hay. 0 Activación Revisoría fiscal No hay. 0

Compra de equipos


estratégicos

No hay. 0

Compra de equipos Definición de


Información no fiable de compra de equipos dificultaría la definición de los objetivos propuestos, ya que uno de los factores que afecta la consecución de los objetivos es el inventario disponible, dando lugar a comprar insuficientes en meses venideros..

3

Compra de equipos Control de


La información no fiable de compra de equipos dificultaría el control de los objetivos trazados para ventas. 2

Compra de equipos Nomina No hay. 0

25



Compra de equipos Contabilidad La generación de información no fiable en la compra de equipos dificultaría la generación de los estados financieros de la compañía.

2

Compra de equipos Tesorería La compra de equipos disminuye el fluyo de caja por lo tanto la mala información de compra de equipos afectaría este estado financiero, dando lugar a malas decisiones de compra.

3

Compra de equipos Revisoría fiscal No hay. 0

Compra de recargas o Sim Card


estratégicos

No hay. 0


Definición de objetivos a corto

plazo

Mensualmente se establecen metas de ventas y para esto hay que tener información fiable de “Compra de recargas o Sim Card”, por lo tanto errores en la información de este proceso afectaría las compras de meses venideros

1


Control de objetivos a corto

plazo

Parte del control de los objetivos trazados periódicamente para las ventas está compuesto por ventas de recargas y Sim Card, por lo tanto información no fiable de este proceso afectaría gravemente este control.

3

Compra de recargas o Sim Card Nomina No hay. 0

Compra de recargas o Sim Card Contabilidad La generación de información no fiable de compras de recargas

o SIM CARD afectaría los estados financieros de la compañía 3

Compra de recargas o Sim Card Tesorería

La compra de recargas o SIM CARD disminuye el fluyo de caja por lo tanto la mala información de compra de recargas o Sim Card afectaría el flujo de caja, dando lugar a malas decisiones de compra.

3

Compra de recargas o Sim Card Revisoría fiscal No hay. 0



estratégicos

No hay. 0



plazo

La información no fiable de control de inventarios dificulta las compras de cualquier producto en meses venideros, por lo tanto los objetivos definidos para las compras se definirían de manera errónea.

3


Control de objetivos a corto plazo

La información no fiable de control de inventarios dificulta el control de objetivos de compras, ya que si el control de inventarios no es exacto los sobrantes o faltantes afectarán el Kardex de inventarios.

2

Control de inventarios Nomina No hay. 0

Control de inventarios Contabilidad

Los informes para la gerencia muchas veces son balance general, estado de resultados, entre otros. Uno de los insumos para generar estos informes son los inventarios por lo tanto una mala gestión de los mismos tergiversa los informes para la gerencia.

3

Control de inventarios Tesorería No hay. 0

Control de inventarios Revisoría fiscal No hay. 0

Capacitaciones para vendedores

antiguos y nuevos


estratégicos

No hay. 0


antiguos y nuevos


plazo No hay. 0

26




antiguos y nuevos


plazo No hay. 0


antiguos y nuevos Nomina No hay. 0


antiguos y nuevos Tesorería No hay. 0


antiguos y nuevos Contabilidad No hay. 0


antiguos y nuevos Revisoría fiscal No hay. 0

Servicio al cliente Reposición


estratégicos

No hay. 0



plazo No hay. 0



plazo

La información no fiable de reposiciones afecta el control de objetivos de ventas. El inventario para atender las reposiciones se tiene que tener en cuenta a la hora de hacer los pedidos de equipos y si estos pedidos no son hechos de manera correcta las ventas se verán afectadas por el inventario consumido por reposiciones. Este inventario consumido por reposiciones (no planificado) cambiaría las ventas reales del periodo, afectando a su vez la información que se utiliza para hacer el control de los objetivos de ventas.

3

Servicio al cliente Reposición Nomina No hay. 0

Servicio al cliente Reposición Contabilidad

Debido a que las reposiciones afectan los inventarios de la compañía, la generación de información no fiable dificultaría la generación de estados financieros.

3

Servicio al cliente Reposición Tesorería

Cada reposición atendida aumenta el flujo de caja, esto quiere decir que si la información de reposiciones atendidas no es correcta el flujo de caja tampoco lo será.

3

Servicio al cliente Reposición Revisoría fiscal No hay. 0

Servicio al cliente Recargas


estratégicos

No hay. 0



plazo

La generación de información no fiable de las ventas de recargas afectaría las compras de recargas de meses venideros, esto quiere decir que los objetivos se definirían mal.

3



plazo

La generación de información no fiable de ventas de recargas dificultaría el control de los objetivos de ventas de recargas 2

Servicio al cliente Recargas Nomina No hay. 0

Servicio al cliente Recargas Contabilidad No hay. 0

Servicio al cliente Recargas Tesorería

La venta de recargas incrementa el flujo de caja por lo tanto la mala información de las ventas de recargas afectaría el manejo del flujo de caja.

3

Servicio al cliente Recargas Revisoría fiscal No hay. 0

27



Pago de facturas


estratégicos

No hay. 0

Pago de facturas Definición de


La información de pago de facturas afectaría la definición de objetivos de recaudos en meses venideros, además, con base en los objetivos de recaudos mensuales se reevalúa la capacidad de atención en las cajas, por ende, definir mal la capacidad de atención afectaría el servicio prestado a los clientes.

3

Pago de facturas Control de


La mala información de pago de facturas dificultaría el control de los objetivos de recaudos. 1

Pago de facturas Nomina

Dependiendo de la información de recaudos se aumenta, se disminuye o se mantiene la capacidad de atención en las cajas, es decir las novedades de nomina en las cajas se ven afectadas por la información de recaudos.

2

Pago de facturas Contabilidad La generación de información no fiable en pago de facturas afecta la generación de estados financieros en contabilidad. 3

Pago de facturas Tesorería La generación de información no fiable de pago de facturas afectaría la generación del flujo de caja por lo tanto se vería afectada la gestión de tesorero.

3

Pago de facturas Revisoría fiscal No hay. 0 Fuente: Autor del presente trabajo

Para la priorización de los procesos se construyó un diagrama matricial en L (tabla 7) con base en los impactos definidos en la tabla 6.

Tabla 7. Diagrama matriz en L Procesos operativos

Ven

tas

Activación

Com

pra

de

equi

pos

Compra de

recargas o

Sim Card

Con

trol d

e in

vent

ario

s

Cap

acita

cion

es p

ara

vend

edor

es

antig

uos

y nu

evos

Ser

vici

o al

cl

ient

e R

epos

ició

n

Ser

vici

o al

cl

ient

e R

ecar

gas

Pag

o de

fa

ctur

as

Procesos administrativos


estratégicos

0 0 0 0 0 0 0 0 0


plazo 3 3 3 1 3 0 0 3 3


plazo 2 2 2 3 2 0 3 2 1

Nomina 2 0 0 0 0 0 0 0 2Contabilidad 3 3 2 3 3 0 3 0 3

Revisoría fiscal 0 0 0 0 0 0 0 0 0

Tesorería 2 0 3 3 0 0 3 3 3 Gran Total

Total 12 8 10 10 8 0 9 8 12 77

Peso sobre el

Total 16% 10% 13% 13% 10% 0% 12% 10% 16% 100%


28

Los puntajes resultantes del diagrama matriz se pueden apreciar seguidamente en la tabla 8 en donde adicionalmente se identifica cual es la plataforma de software que hoy en día apoya el proceso:

Tabla 8. Puntajes diagrama matriz

Operativos Total Peso % sobre el total

Software de apoyo actual

Ventas 12 16% Software actual Activación 8 10% Poliedro y software actual

Compra de equipos 10 13% Poliedro y software actual

Compra de recargas o Sim Card 10 13% Poliedro y software actual

Control de inventarios 8 10% Software actual Capacitaciones para vendedores antiguos y

nuevos 0 0% Poliedro Servicio al cliente Reposición 9 12% Poliedro y software actual

Servicio al cliente Recargas 8 10% Poliedro y software actual

Pago de facturas 12 16% SiCaCom Total 77 100%


En esta tabla podemos ver que los proceso operativos, menos las capacitaciones, contribuyen con un porcentaje mayor o igual a 10%, lo cual significa que a excepción de un proceso operativo los demás afectan a los administrativos. Con lo anterior se puede hacer un primer acercamiento a una primera conclusión y es que todos los procesos (menos capacitaciones) son susceptibles de sistematizar. Ahora, si continuamos analizando la tabla 8 se puede apreciar que los procesos se llevan a cabo a través de software diferentes y en algunas ocasiones combinados. Esto no quiere decir que la compañía tenga implementados varios software para la integración y sistematización de los procesos sino que los software diferentes del software actual son sistemas de apoyo brindados por Comcel y de uso obligatorio. Esto significa que los procesos que están soportados por los software proporcionados por Comcel ya están sistematizados y no pueden ser reemplazados o re parametrizados. Con esta nueva información se replantea la primera conclusión de la siguiente manera: los procesos que estén apoyados únicamente por el software actual o en combinación de otro software son susceptibles de sistematizar. 5.1.3. Procesos priorizados para sistematizar Ventas: (Puntaje diagrama matriz: 12=16%) Este proceso actualmente está siendo apoyado

únicamente por el software actual de manera que es uno de los procesos susceptibles de sistematizar.

29

Activaciones: (Puntaje diagrama matriz: 8=10%) En el proceso de activaciones es obligatorio hacer uso del sistema de apoyo Poliedro para generar nuevos números de celular e ingresar los datos demográficos de los clientes. Por otro lado, el proceso de activaciones tiene que estar alineado con el de control de inventarios ya que en el momento de la activación tienen que verificar el inventario y descargar los celulares asignados; Esta área es la que nos interesa para la sistematización de este proceso, por ende, es susceptible de sistematización.

Compra de equipos: (Puntaje diagrama matriz: 10=13%) El proceso de compra de equipos se

apoya en el sistema poliedro en el momento en que se envían los pedidos a Comcel, pero antes de enviar los pedidos es necesario consolidar los pedidos de los coordinadores de CPS para lo cual hay que verificar los inventarios; para esto es importante que el proceso de activaciones este alineado con el manejo de inventarios, por lo tanto activaciones es susceptible a sistematización.

Control de inventarios: (Puntaje diagrama matriz: 8=10%) El proceso de control de

inventarios es el proceso que mas requiere ser sistematizado ya que el costo de inventarios fue subvalorado por el software actual, ocasionando así repartición de utilidades mayores a los socios; a partir de este problema se puede concluir que este proceso es susceptible de sistematización. En la tabla 9 se ilustra un ejemplo para dimensionar el problema de control de inventarios que presenta el software actual:

Tabla 9. Ejemplo subvaloración de inventarios

Costo Precio de venta por unidad Unidades Costo del

inventario Utilidad neta por unidad

Utilidad neta total

Real 100.000 120.000 1.000 100.000.000 20.000 20.000.000 Software 50.000 120.000 1.000 50.000.000 70.000 70.000.000


Servicio al cliente Reposición: (Puntaje diagrama matriz: 9=12%) El proceso de servicio al cliente Reposición tiene un actividad de “verificación de disponibilidad de seriales” lo cual significa que es necesario verificar el inventario para llevar a cabo una reposición, por ende, este proceso tiene que estar alineado con el manejo de inventarios convirtiéndolo en uno de los procesos susceptibles a sistematizar.

Servicio al cliente Recargas: (Puntaje diagrama matriz: 8=10%) Este proceso consta de pocas

actividades en las cuales el único cliente interno es Caja y Bodega. Los dos servicios que ofrece este proceso son recargas y tarjetas prepago, que para efectos de uso son lo mismo, pero para vender no lo son. Para vender tarjetas prepago es necesario hacer las descargas de las tarjetas vendidas a medida que se venden, por esta razón el proceso tiene un componente de manejo de inventarios que nos sugiere sistematizarlo.

Por otro lado, luego de la entrevista que se tuvo con el gerente general y el coordinador administrativo, se dio a conocer nueva información para este proceso: Después que la compañía analizara los dos servicios de recargas concluyeron que la única diferencia entre los dos es el plástico, el cual cuesta más y no cumple ninguna función ya que los empleados de caja y bodega están obligados a hacer las recargas ellos mismos. En vista de esto la compañía no comprará más tarjetas

30

prepago y de ahora en adelante solo venderá recargas a través de línea celular. Al eliminar este servicio del proceso no es necesario llevar un control de inventarios ya que el componente físico del servicio desaparece. En resumen este proceso no es susceptible de sistematizar.

Compra de recargas o Sim Card: (Puntaje diagrama matriz: 10=13%) Este proceso tiene el

mismo componente de control de inventarios que el de “Compra de equipos”, por esto se puede decir que es susceptible de sistematización, aunque luego de la explicación del proceso “Servicio al cliente Recargas” este componente de control de inventarios desaparece (parcialmente) haciendo que este proceso pierda parte del factor que lo hacía susceptible de sistematización. No obstante, el factor de control de inventarios de este proceso está compuesto por dos productos; Sim Card y recargas, de los cuales solo se llevará control de inventarios para las Sim Card. En conclusión este proceso es susceptible de sistematización y se fusionará con el proceso compra de equipos. El nuevo nombre de este proceso será compra de equipos y Sim Card.

Pago de facturas: (Puntaje diagrama matriz: 12=16%) El proceso de pago de facturas

generadas por Comcel está apoyado completamente en el software SiCaCom proporcionado por Comcel. Por esta razón el proceso no es susceptible de sistematización.

Los siguientes son los procesos susceptibles de sistematizar:

1) Ventas 2) Activaciones 3) Compra de equipos y Sim Card (Nuevo proceso) 4) Control de inventarios 5) Servicio al cliente reposición

Es vital hacer claridad acerca de que va a pasar con el proceso Servicio al cliente recargas. En vista que este proceso se separó, una parte se fusionó con Compra de equipo y la otra quedó independiente, la diagramación y caracterización se actualizará con el ánimo de dejar definidos los procesos por separado. La diagramación y caracterización del proceso Servicio al cliente recargas no implica que sea susceptible sistematización. Por otro lado, esta priorización de los procesos susceptibles a sistematizar representa el alcance del análisis de los procesos. El alcance se demarca con esta priorización.

31

6. Situación propuesta de los procesos susceptibles a sistematizar 6.1. Identificación de las necesidades de los usuarios

En aras de un mejor levantamiento de información relevante acerca de los procesos susceptibles a sistematizar, y de indagar acerca de las necesidades de los usuarios se aplicaron entrevistas a los empleados que actúan en estos procesos. En este caso se va a tomar una muestra “no probabilística, de criterio y conveniencia” ya que la población de empleados involucrados en los procesos es muy pequeña. En la tabla 10 se encuentran las preguntas que se aplicaron en cada entrevista y el propósito de cada una:

Tabla 10. Preguntas de las entrevistas No Pregunta Proposito 1 ¿Cuáles son las actividades del proceso que, a su juicio, el

software actual lleva a cabo de forma correcta? ¿Por qué? Detectar qué actividades soporta de manera correcta el software actual para empezar a alinear los procesos a lo que serían los requerimientos funcionales del nuevo software.

2 ¿Cuáles son las actividades del proceso en las cuales el software actual falla? ¿Por qué?

Detectar qué actividades el software actual no soporta de manera correcta para saber algunos de los errores que no se pueden cometer en los nuevos requerimientos funcionales.

3 ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar?

Empezar a detectar las áreas que está olvidando el software actual y de esta manera tenerlas en cuenta en los nuevos requerimientos funcionales.

4 ¿Qué información requiere para llevar a cabo sus actividades? Determinar las entradas de las actividades de los procesos.

5 ¿Cómo se genera esta información y qué o quién se la proporciona?

Determinar los procesos que proveen la información de las actividades de un proceso en específico.

6 ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.)

Determinar el formato de las entradas de las actividades.

7 ¿Qué información debe arrojar su proceso? Determinar las salidas de las actividades. 8 ¿Cómo genera usted la información? (forma, medio, orden,

momento, etc.) Determinar las actividades centrales de un proceso.

9 ¿Quién utiliza la información que su proceso arroja y para que la utiliza?

Determinar los “procesos cliente” de las salidas de las actividades.

10 ¿Qué problemas presenta actualmente el proceso? Determinar oportunidades de mejora para los procesos propuestos.

11 ¿Qué otra persona además de usted tiene acceso al software en su área y por qué lo utiliza? En caso de que usted sea el único usuario en su área en este momento ¿Qué otra persona debería tener acceso al software y por qué?

Determinar usuarios no obvios en los procesos.

12 Sugerencias Sugerencias para mejorar los procesos actuales. Fuente: Autor del presente trabajo

En la tabla 11 se muestran las respuestas de todos los actores de los procesos susceptibles a sistematizar. Para mas detalles ver los anexos 23 al 29.

32

Tabla 11. Cuadro de entrevistas

Proceso

Ventas Activaciones Compra de equipos - Compra de Sim Card Control de inventarios Servicio al cliente reposición

Numero de encuestas 3 encuestas

E1: Asesor de ventas E2: Líder de activaciones

E6: Líder de caja y bodegas.

3 encuestas E1: Asesor de ventas

E2: Líder de activaciones E6: Líder de caja y bodegas.

2 encuestas E7: Coordinador de CPS

E3: Coordinador administrativo.



2 encuestas E5: Líder de servicio


1) Actividades que el software actual lleva a cabo de forma correcta - - - - -

2) Actividades que el software actual lleva a cabo de forma incorrecta

E1, E2. Control de inventarios E2. No hay control entre activaciones y caja. E6. Kardex de inventarios

Las respuestas son las mismas que las del proceso de ventas ya que los actores son los mismos, comparten algunas actividades y un proceso contiene al otro.

E7. Manejo de inventarios. E3. Manejo de inventarios.

E7. En el momento que se quiere realizar un inventario físico la información que arroja el sistema no es fiable. En el momento en que caja asigna seriales el software presenta una falencia ya que en ocasiones asigna dos veces el mismo producto. E4. Manejo de la toma física del inventario

E5. Asignación de Sim Card E6. Kardex de inventarios

3) Actividades que no soporta el software actual o actividades que debería soportar

E1. El software actual debería soportar la asignación automática de equipos. E2. Control de inventarios. E6. Inventarios


E7. Generación de reportes de la disponibilidad del inventario.

E7. Control de inventarios E4. Las solicitudes: Para poder hacerle seguimiento al trabajo del comprador el sistema debería almacenar las solicitudes de los coordinadores CPS. Con esto se sabe cuánto y cuando pidió cada coordinador de CPS.

E5. La facturación en línea: Alinear las actividades de asignación de Sim Card con la facturación. E6. Inventarios

4) Info para llevar a cabo sus actividades

E1. Info 1. Condiciones de venta vigentes E2. Info 1. Información demográfica del cliente Info 2. Información de los seriales del equipo. E6. Info 1. Datos demográficos del cliente Info 2. Valor de las ventas Info 3. Datos de los productos


E7. Info1. Disponibilidad de inventario. Info 2 Necesidades de equipos. E3. Info 1. Las necesidades de cada CPS Info 2. Estado de cartera Info 3. La disponibilidad de inventario de CGC

E7: Info1. Kardex de inventarios E4. Info 1. Cruce del Kardex con el inventario físico Info 2. Solicitud justificación inventario Info 3. Informe de inventario Ok del CPS Info 4. Justificación de sobrantes y faltantes.

E5. Info 1. Datos demográficos del cliente. E6. Info 1. Datos demográficos del cliente Info 2. Valor de la reposición Info 3. Datos de los productos.

5) Como se genera esta información

E1. Info 1. Cada coordinador de CPS las consolida pero en realidad la información se genera en Comcel.E2. Info 1. La generan los asesores preguntándole al cliente Info 2. La genera “automáticamente” el sistema.E6. Info 1. Escritos por el asesor de ventas Info 2. Liquidado en el contrato de la venta Info 3. Escrito por el asesor y asignado por el sistema.


E7. Info 1. Generada automáticamente por el sistema Info 2. Según los asesores de ventas y los lideres de servicio. E3. Info 1. Cada coordinador de CPS Info 2. La proporciona el área de contabilidad Info 3. La proporción Comcel

E7: Info 1. El sistema la debería generar automáticamente. E4. Info 1. El coordinador lo hace (Manual) Info 2. Comcel: Lo genera el área de control de inventarios en Comcel. Info 3. Excel (Cada coordinador) Info 4. Una carta o memorando. Coordinador administrativo.

E5. Info 1. El cliente proporciona la información. E6. Info 1. Escritos por el líder de servicio Info 2. Liquidado en el contrato de la venta Info 3. Escrito por el líder de servicio y asignado por el sistema.

33

Proceso













6) Forma de la Info. Que necesita

E1. Info 1. Se mantienen constantemente en carpetas en el lugar de trabajo. E2. Info 1. Escrita en los contratos. Info 2. Archivo plano en el sistema, y manipulable E6. Info 1. Escrito por el asesor en el contrato en el momento de la venta (el orden lo determina el formato del contrato.) Info 2. Misma manera de la info. 1 Info 3. Escrito por el asesor. El sistema debería asignar los productos automáticamente.


E7. Info 1: Archivo de Excel Info 2. Verbalmente y consolidadas en un archivo de Excel. E3. Info 1. Vía mail, un archivo informativo Info 2. Vía mail en Excel informando la cantidad de facturas vencidas y los valores de c/u Info 3. Archivo en Excel en el formato.

E7: Info 1: Impreso y en una tabla con dos columnas: referencia y serial E4. Info 1. Excel con los datos de los equipos, cuando se requiera Info 2. Formato de solicitud. (Encabezado: IMEI, ICCID, referencia de equipo) Info 3. Encabezado IMEI, ICCID, referencia de equipo, cada vez que se requiera Info 4. Memorando Cada vez que se requiera.

E6. Info 1. Escrito por el líder de servicio en el contrato en el momento de la reposición. Info 2. Misma manera de la info. 1 Info 3. Escrito por el líder de servicio. El sistema debería asignar los productos automáticamente.

7) Info. Que debe arrojar su proceso

E1. Info 2. Los documentos necesarios diligenciados para continuar con la activación. E2. Info 3. El numero de celular que se le da al cliente.


E7. Info 3. Necesidades de equipos del CPS. E3. Info 4. Las cantidades de equipos necesitadas y las compradas.

E7. Info 2. El cruce de inventarios Info 3. El memorando de inventarios ok Info 4. Si es el caso justificación de inventario E4. Info 5. Estado actual del kardex.

8) Como genera la información

E1. Info 2. Se diligencian a mano. E2. Info 3. Ingresa los datos del contrato a poliedro y poliedro arroja el número de celular automáticamente.


E7. Info 3. Consolidando toda la información de las necesidades de equipos del CPS y cruzándola con la disponibilidad de inventarios. E3. Info 4. Cruzando las necesidades de cada CPS con la disponibilidad de Comcel.

E7 Info2. Archivo en Excel Info 3. Archivo en Word Info 4. Archivo en WordE4. Info 5. Cruzando los inventarios de los CPS confirmados y consolidados con los de Comcel.

9) ¿Quién utiliza la información que arroja su proceso y para qué?

E1. Info 2. Activaciones y Caja: Una vez los documentos tienen el sello de caja activaciones prosigue con la activación del equipo. E2. Info 3. Comisiones: Para liquidación de comisiones. Asesor de ventas: Para la entrega de los equipos activados. E6. El proceso si genera información pero es interna, se trata del Kardex de inventarios, el cual se debería actualizar automáticamente con las asignaciones de productos que se hagan.


E7. Info 3 El coordinador administrativo para consolidar todas las necesidades de todos los CPS. E3. Info 4. Comcel para la asignación de equipos.

E7 Info 2, Info 3 e Info 4: A corto plazo, el coordinador administrativo, y a largo plazo Comcel. La utilizan para llevar un control de los inventarios. E4. Info 5. Comcel: para verificar las existencias de inventario que tiene cada distribuidor. Coordinador: Para verificar el inventario físico en su bodega.

E5. Caja para facturarlo y bodega para asignar el equipo. Comcel para verificar la cantidad de clientes atendidos. E6. El proceso si genera información pero es interna, se trata del Kardex de inventarios, el cual se debería actualizar automáticamente con las asignaciones de productos que se hagan.

10) Problemas que presenta actualmente el proceso

E1: Búsqueda de equipo y Activaciones. E2. No se respeta el proceso de activaciones, existe desorden en los pasos para llevar a cabo el proceso por el afán de cerrar una venta. E6. El control errado de inventarios.


E7. La generación de reportes de disponibilidad de inventario debería ser automática no manual.

E7. Ninguno, debería ser mas automatizado, pero de igual forma se lleva a cabo a mano.

E6. El control errado de inventarios.

34

Proceso













11) Personas que utilizan el software además del entrevistado

E2. Planillador: Persona que genera los volantes de consignación. Esta persona tiene acceso al sistema para ingresar información de las consignaciones.E6. Auxiliar de caja y bodegas: Para efectos prácticos las funciones son las mismas que las de un líder de caja y bodegas entonces necesitaría los mismos accesos.


E6. Auxiliar de caja y bodegas: Para efectos prácticos las funciones son las mismas que las de un líder de caja y bodegas entonces necesitaría los mismos accesos.

Sugerencias E2. En el software actual no está discriminada la forma de pago. Es necesario tener la forma de pago para el proceso de activaciones.


Fuente: Autor del presente trabajo 6.1.1. Conclusiones y aspectos importantes producto de las entrevistas En este cuadro se encuentran las conclusiones más importantes que se generaron luego de la aplicación de las entrevistas.

Tabla 12. Conclusiones y aspectos importantes de las entrevistas Proceso

Ventas y Activaciones Compra de equipos - Compra de Sim Card Control de inventarios Servicio al cliente reposición

Es importante mejorar el manejo de inventario del sistema. Es importante mejorar el manejo de inventario del sistema.

El kardex de inventario debería ser perfecto (Manejo de inventarios) Asignación de Sim Card perfecta.

Integrar las actividades entre activaciones y caja.

Dentro del manejo de inventario se deberían crear buenos reportes de disponibilidad de inventarios.

Asignación de seriales perfecta; si el sistema no descarga los seriales apropiadamente se presta para doble asignación de un mismo serial.

El kardex de inventario debería ser perfecto (Manejo de inventarios)

El sistema debería asignar los equipos perfectamente. (Manejo de inventarios)

El ingreso de inventarios debería ser perfecto ya que si la actividad que alimenta los inventarios no es perfecta, el problema de manejo de inventarios sería peor.

Alinear las actividades de asignación de seriales con la facturación de las ventas y reposiciones.

Existe un usuario que no se ha tratado a lo largo de la diagramación y caracterización de los procesos ya que su actividad es de auditoría. Este usuario es el planillador y es importante tomarlo en cuenta para el levantamiento de sus requerimientos.

Es importante mejorar el manejo de inventario del sistema.

El activador necesita la forma de pago para llevar a cabo sus actividades.


35

6.2. Diagramación y caracterización de los procesos propuestos En los gráficos 4 al 9 y en las tablas 13 a la 22 se encuentra la situación propuesta de los procesos susceptibles de sistematizar. Estos procesos están diagramados tomando en cuenta las entrevistas aplicadas a los actores de los procesos y las oportunidades de mejora que surgieron luego de analizar los procesos actuales con las directivas de Comcel. En cada uno de los procesos se pueden apreciar los cambios que se realizaron. Las burbujas rojas explican y apuntan hacia el lugar donde se llevó a cabo el cambio. Esta situación propuesta de los procesos tiene como fin proponer una reorganización de los procesos e interiorización de los mismos por parte de los actores. Esta interiorización o aplicación de los procesos debería hacerse antes de empezar con el diseño del software. Esta fase de modelación del negocio es vital para el trabajo ya que sin ella los requerimientos que se levanten podrían ser inútiles.

36

Gráfico 4. Diagrama de flujo propuesto para el proceso de ventas


37

Tabla 13. Caracterización propuesta para el proceso de Ventas MACROPROCESO: MACRO PROCESOS MISIONALES

PROCESO: VENTAS

OBJETIVO: Vender cualquiera de los productos que generan ingresos para CGC..

LIDER O RESPONSABLE DEL PROCESO: Asesor PROCESO

PROVEEDOR DE LA ENTRADA

ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO

SALIDA SALIDA PROCESO CLIENTE DE LA SALIDA

1. Capacitaciones antiguos, Capacitaciones nuevos y Ventas

1. Portafolio de productos. 2. Necesidades del cliente

1. Material proporcionado por Comcel.

Ofrecer portafolio de productos.

1. Esta elección se da verbalmente por parte del cliente

1. Elección de plan y equipo 1. Ventas

1. Ventas 1. Información demográfica del cliente

1. Escrito en los formatos necesarios para la venta

Verificar estatus de data crédito.

1. Estatus de data crédito se consulta online en Poliedro y luego se imprime

1. Estatus de data crédito

1. Activaciones y ventas

1. Ventas 2. Activaciones

1. Documentos necesarios dependiendo del tipo de venta. 2. Formatos necesarios dependiendo del tipo de venta.

1. Fotocopias de los documentos necesarios para la venta 2. Formatos impresos necesarios para la venta

Conseguir y diligenciar los documentos necesarios.

1. Fotocopias de documentos (Ej. Cedula del cliente) necesarios para la venta 2. Formatos impresos y diligenciados para la venta.

1. Documentos necesarios 2. Formatos diligenciados para procesar la venta.

1. Ventas 2. Ventas.

1. Ventas 1. Ventas


1. Fotocopias de los documentos necesarios para 2. Formatos impresos necesarios para la venta

Verificar documentos y datos de los formatos.

1. Esta verificación se le comunica al asesore de ventas verbalmente

1. Aprobación de formatos y documentos.

1. Ventas

1. Ventas 1. información necesaria para la venta

1. Escrito en los formatos para la venta.

Pre ingresar los datos de la venta

1. Almacenado en el sistema.

1. Datos básicos de la venta ingresados en el sistema

1. Activaciones y Ventas


1. Contrato diligenciado.2. Datos básicos de la venta ingresados en el sistema.

1. Contrato Impreso y diligenciado 2. Datos almacenados en el sistema.

Recaudar valor de la venta.

1. Recibo de caja impreso 1. Recibo de caja. 1. Ventas y

Activaciones

1. Asesor de ventas 2. Líder o Auxiliar de caja y bodega

1. Documentos y formatos necesarios para la activación del

1. Formatos impresos y diligenciados

Activar equipo. 1. Equipo activado en el sistema y copia de contrato

1. Equipo activado, copia de contrato 1. Ventas

38

MACROPROCESO: MACRO PROCESOS MISIONALESPROCESO: VENTAS






equipo 2. Recibo de caja.

2. Recibo de caja impreso.

adjunta al contrato original.

1. Ventas 1. Copia del contrato 1. Formato impreso y diligenciado. Generar Factura 1. Factura impresa 1. Factura 1. Ventas

1. Ventas y Activaciones

1. Factura original y copia del contrato.

1. Factura impresa y copia del contrato adjunta al contrato original

Buscar y entregar el equipo al asesor junto con los formatos y factura

1. Equipo físico 2. Copias del contrato adjunto al contrato original 3. Factura impresa.

1. Equipo 2. Formatos 3. Factura

1. Ventas 2. Ventas 3. Ventas

1. Ventas

1. Equipo físico 2. Copias del contrato adjunto al contrato original 3. Factura impresa.

1. Equipo 2. Formatos 3. Factura

Entregar el equipo o la Sim Card o los dos, copia de contrato y factura original al cliente.

1. Cliente satisfecho

PROCESOS RELACIONADOS: Activaciones, Capacitaciones antiguos, Capacitaciones nuevos

RECURSOS: Humanos; Asesor, Líder de Caja y Bodega, Auxiliar de Caja y Bodega, Líder de activaciones. Económicos: Dinero dependiendo del plan y el equipo. Físicos: Formatos necesarios dependiendo del tipo de venta, Computadores, Instalaciones de la sede principal de CGC. Electrónicos: Software actual, SICACOM. DOCUMENTOS INTERNOS: Venta post-pago: (Consecutivo Comcel) Contrato Persona Natural ò Contrato Persona Jurídica. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos.

DOCUMENTOS EXTERNOS: Venta post-pago: Fotocopia de la cedula tamaño normal. Venta datos: Fotocopia de la cedula tamaño normal.

39

MACROPROCESO: MACRO PROCESOS MISIONALESPROCESO: VENTAS






Venta datos: (Consecutivo Comcel) Contrato Persona Natural Datos ò Contrato Persona Jurídica Datos. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo de 3G. (Consecutivo Comcel) Anexo de Checklist. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta pre-pago (KIT): (Consecutivo Comcel) Planilla legalización prepago. Factura original del recaudo según la venta.

INDICADORES: Reporte de inconsistencias en proceso de revisión de ventas en Activaciones. (Numero de inconsistencias encontradas en activaciones / Numero de ventas) Este indicador le deja ver al vendedor cuantas ventas está perdiendo por inconsistencias en sus contratos. Buzón de Sugerencias de los clientes: En este buzón los clientes pueden registrar cualquier sugerencia o queja que tengan para luego ser procesada por el coordinador de CPS.


40

Gráfico 5. Diagrama de flujo propuesto para el proceso de activaciones


41

Tabla 14. Caracterización propuesta para el proceso de Activaciones MACROPROCESO: MACRO PROCESOS MISIONALES

PROCESO: ACTIVACIONES

OBJETIVO: Activar un producto de CGC vendido por un asesor.

LIDER O RESPONSABLE DEL PROCESO: Líder de activaciones. PROCESO


ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA PROCESO CLIENTE DE

LA SALIDA

1. Ventas 1. Liquidación de contrato y check list diligenciados


Verificar formatos diligenciados

1. Esta verificación se le da al asesor de ventas verbalmente 2. Copias adjuntas al contrato original.

1. Aprobación de formatos y documentos. 2. Copia amarilla y rosada del contrato.

1. Activaciones

1. Ventas 1. Liquidación de contrato y check list diligenciado


Verificar datos de los documentos

1. Esta verificación se le da al asesor de ventas verbalmente

1. Aprobación de de los datos 1. Activaciones.

1. Ventas 1. información necesaria para la venta

1. Esta información viene escrita en los formatos para la venta.

Pre ingresar los datos de la venta

1. Estos datos son almacenados en el sistema.

1. Datos básicos de la venta 1. Activaciones y Ventas

2. Líder de activaciones 1. Cliente (Persona jurídica o natural).

1. Contrato diligenciado. 2. Datos básicos de la venta

1. Contrato impreso y diligenciado. 2. Estos datos son almacenados en el sistema.

Recaudar valor de la venta con los datos pre ingresados

1. Recibo de caja impreso 1. Recibo de caja. 1. Ventas y Activaciones

1. Activaciones y Ventas 1. Información de la venta

1. Esta información se encuentra almacenada en el sistema.

Asignar el equipo en el sistema.

1. Este serial queda almacenado en el sistema.

1. IMEI (Serial del equipo) 1. Ventas y Activaciones.

42

MACROPROCESO: MACRO PROCESOS MISIONALESPROCESO: ACTIVACIONES





LA SALIDA

1. Activaciones 2. Ventas y Activaciones.

1. IMEI 2. Datos de la venta

1. Almacenado en el sistema 2. Almacenado en el sistema

Activar equipo.

1. MIN: Esta activación se lleva a cabo a través de Poliedro y luego se ingresa el MIN en el sistema.

1. MIN (Número de celular) 1. Ventas

1. Ventas 1. Copia del contrato 1. Formato impreso y diligenciado. Generar Factura 1. Factura impresa 1. Factura 1. Ventas

PROCESOS RELACIONADOS: Ventas.

RECURSOS: Humano: Líder de activaciones, Líder de caja y bodega, Auxiliar de caja y bodega, Asesor. Económico: Dinero dependiendo del plan y del equipo. Físicos: Computadores, Papelería, Formatos, Instalaciones de la sede principal de CGC. Electrónicos: Software actual, Microsoft office, SICACOM.

DOCUMENTOS INTERNOS: Venta post-pago: (Consecutivo Comcel) Contrato Persona Natural ò Contrato Persona Jurídica. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta datos: (Consecutivo Comcel) Contrato Persona Natural Datos ò Contrato Persona Jurídica Datos. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio.


43

MACROPROCESO: MACRO PROCESOS MISIONALESPROCESO: ACTIVACIONES





LA SALIDA

(Consecutivo Comcel) Anexo de 3G. (Consecutivo Comcel) Anexo de Checklist. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta pre-pago (KIT): (Consecutivo Comcel) Planilla legalización prepago. Factura original del recaudo según la venta. INDICADORES: Reporte de Comcel de contratos inconsistentes. (Contratos con inconsistencias reportados por Comcel / Contratos enviados a Comcel): Este indicador se mide en porcentaje para tener un control a largo plazo, pero a corto plazo se fijan metas de # de inconsistencias.


44

Gráfico 6. Diagrama de flujo propuesto para del proceso de Compra de equipos y Sim Card


45

Tabla 15. Caracterización propuesta para el proceso de Compra de equipos y Sim card MACROPROCESO: GESTIÓN ADMINISTRATIVAPROCESO: COMPRA DE EQUIPOS Y SIM CARD

OBJETIVO: Comprar equipos de cualquier clase (post-pago o KIT) para la venta y distribuirlos según la necesidad de cada CPS.

LIDER O RESPONSABLE DEL PROCESO: Coordinador administrativo. PROCESO PROVEEDOR DE

LA ENTRADA ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO


1. Compra de equipos y Sim Card.

1. Necesidades según el staff del CPS, y según la disponibilidad de inventario.

1. Estas necesidades se transmiten verbalmente (Staff) y se verifican en el sistema.

Solicitar equipos o Sim Card.

1. Estos archivos de todos los CPS se ven a través del sistema

1. PCE SC 01 1. Compra de equipos y Sim Card.

1. Compra de equipos y Sim Card. 1. PCE SC 01

1. Estos archivos de todos los CPS se ven a través del sistema

Consolidar las necesidades de todo CGC.

1. Este archivo consolidado lo debe arrojar automáticamente el sistema

1. PCE CS 02 1. Compra de equipos y Sim Card.

1. Compra de equipos y Sim Card 2. Compra de equipos y Sim Card 3. Contabilidad

1. PCE CS 02 2. Reporte diario de Comcel de inventario disponible 3. Reporte de cartera.

1. Este archivo consolidado lo debe arrojar automáticamente el sistema 2. Este disponibilidad de inventario de Comcel se consulta en Poliedro. 3. El área de contabilidad debe enviar este reporte cada vez que se le pida.

Verificar inventario disponible y cartera al día (solo para KIT prepago y Sim Card).

1. Esta solicitud de pedido se envía a través de Poliedro. 2. Según la disponibilidad de inventario se envía el reporte de nodisponibilidad a los coordinadores de CPS.

1. Solicitud de pedido 2. PCE RD 03

1. Compra de equipos y Sim Card 2. Compra de equipos y Sim Card

1. Compra de equipos y Sim Card

1. Solicitud de pedido

1. Esta solicitud de pedido se envía a través de poliedro

Enviar pedido a Comcel.

1. Esta solicitud de pedido se envía a través de poliedro

1. Solicitud de pedido enviada.


46

MACROPROCESO: GESTIÓN ADMINISTRATIVAPROCESO: COMPRA DE EQUIPOS Y SIM CARD






1. Solicitud de pedido

1. A través de poliedro

Verificación y aprobación de pedido

1. Esta aprobación es online, justo después de enviar la solicitud de pedido a través de poliedro

1. Aprobación de pedido



1. Remisión y factura de Comcel

1. La remisión y la factura son entregadas impresas en el momento del retiro de los equipos de las bodegas de Comcel

Reclamar equipos en bodegas y distribuirlos según las necesidades de cada CPS.

1. Equipos físicos

1. Equipos solicitados



1. Remisión y factura de Comcel

La remisión y la factura son entregadas impresas en el momento del retiro de los equipos de las bodegas de Comcel

Ingresar el inventario nuevo

1. Este nuevo inventario será almacenado en el sistema

1. Nuevo inventario ingresado al sistema

1. Ventas 1. Activaciones 1. Reposición / 1. Control de 1. Compra de equipos y Sim Card

PROCESOS RELACIONADOS: Ventas, Activación, Control de inventarios.

RECURSOS: Humanos: Coordinador administrativo, Coordinador de CPS, Personal de Comcel para la programación y despacho de equipos. Físicos: Computadores, CPS's CGC, Medio de transporte de CGC. Económicos: Pago de los KIT. Electronicos: Software actual, Internet, microsoft office.

DOCUMENTOS INTERNOS: DOCUMENTOS EXTERNOS:

47

MACROPROCESO: GESTIÓN ADMINISTRATIVAPROCESO: COMPRA DE EQUIPOS Y SIM CARD





PCE SC 01 Archivos de todos los CPS con las solicitudes de equipos. PCE CS 02 Archivo consolidado de todas las solicitudes. PCE RD 03 Reporte de no disponibilidad.

- Reporte de diario de Comcel de inventario disponible. - Remisión de Comcel.

INDICADORES:


Tabla 16. Significado de siglas de codificación Codificación documentosSigla SignificadoPCE Proceso de compra de equipos CS Consolidado de todas las solicitudes RD Reporte de no disponibilidad SC Archivos de todos los CPS con las solicitudes de equipos. # Consecutivo


48

Gráfico 7. Diagrama de flujo propuesto para el proceso de Control de inventarios


49

Tabla 17. Caracterización propuesta para el proceso de Control de inventarios MACROPROCESO: GESTIÓN ADMINISTRATIVA

PROCESO: CONTROL DE INVENTARIOS

OBJETIVO: Cruce de los inventarios físicos de CGC con los teóricos. Cruce de los inventarios físicos de los CPS con los teóricos.

LIDER O RESPONSABLE DEL PROCESO: Coordinador administrativo. PROCESO


ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA PROCESO

CLIENTE DE LA SALIDA

1. Control de inventarios 2. Control de inventarios

1. PCI SI 01 2. Solicitud justificación inventario.

1. Formato en Excel 2. Formato en Excel

_ Enviar solicitud inventario CPS _ Enviar solicitud justificación inventario.

1. Archivo vía email (Excel) 2. Archivo vía email (Excel)

1. PCI SI 01 enviada. 2. Solicitud justificación inventario CGC enviada.



1. PCI K 02 2. PCI K 03


_ Cruzar Kardex VS inventario físico _ Cruzar Kardex VS Inventario Comcel

1. Formato en Excel 2. Formato en Excel 3. Memorando vía email4. Memorando vía email

1. PCI CI 04 2. PCI CI 05 3. PCI II 06 4. PCI II 07

1. Control de inventarios 2. Control de inventarios 3. Control de inventarios 4. Control de inventarios



1. Archivo (Excel) 2. Archivo (Excel) 3. Memorando vía email4. Memorando vía email

Verificar documento

1) Formato en Excel 2. Formato en Excel 3. Memorando vía email.

1. PCI RSF 08 2. Reporte de sobrantes o faltantes CGC. 3. Aprobación documento

1. Control de inventarios 2. Control de inventarios 3. Control de inventarios


1. PCI RSF 08 2. Reporte de sobrantes o faltantes CGC.


Justificar sobrantes y faltantes.

1. Memorando vía email2. Memorando vía email

1. PCI JSF 09 2. PCI JSF 10


PROCESOS RELACIONADOS: Compras equipos, Compras recargas y Sim Card. RECURSOS: Humanos: Coordinador administrativo, Representante de Comcel, RRHH de Comcel para verificación de inventarios, Coordinador de CPS. Físicos: CPS's CGC, Computadores. Electrónicos: Internet, Software actual, Microsoft office. DOCUMENTOS INTERNOS: DOCUMENTOS EXTERNOS:

50

MACROPROCESO: GESTIÓN ADMINISTRATIVAPROCESO: CONTROL DE INVENTARIOS


LIDER O RESPONSABLE DEL PROCESO: Coordinador administrativo. PROCESO


ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA PROCESO

CLIENTE DE LA SALIDA

PCI SI 01 Solicitud inventario CPS PCI K 02 Kardex CPS PCI K 03 Kardex CGC PCI CI 04 Cruce completo de inventarios CGC. PCI CI 05 Cruce completo de inventarios CPS. PCI II 06 Informe de inventario CGC ok. PCI II 07 Informe de inventario CPS ok. PCI RSF 08 Reporte de sobrantes o faltantes CPS. PCI JSF 09 Justificación de sobrantes y faltantes CGC. PCI JSF 10 Justificación de sobrantes y faltantes CPS.

- Solicitud justificación inventario. - Reporte de sobrantes o faltantes CGC.

INDICADORES:


Tabla 18. Significado de siglas de codificación Codificación documentosSiglas SignificadoPCI Proceso de control de inventarios SI Solicitud inventario CPS K Kardex CI Cruce completo de inventarios II Informe de inventario RSF Reporte de sobrantes o faltantes CPS JSF Justificación se sobrantes o faltantes # Consecutivo


51

Gráfico 8: Diagrama de flujo propuesto para el proceso de Servicio al cliente Reposición


52

Tabla 19. Caracterización propuesta para el proceso de Servicio al cliente Reposición MACROPROCESO: SOPORTE AL SERVICIO.

PROCESO: SERVICIO AL CLIENTE REPOSICIÓN.

OBJETIVO: Brindarle un servicio post-venta al cliente haciéndoles una reposición de cualquier tipo.

LIDER O RESPONSABLE DEL PROCESO: Servicio al cliente. PROCESOS O

PERSONA PROVEEDOR DE LA

ENTRADA


SALIDA SALIDA

PROCESOS O PERSONA CLIENTE DE

LA SALIDA DEL PROCESO

1. Servicio al cliente reposición 2. Servicio al cliente reposición. 3. Servicio al cliente reposición

1. Necesidades del cliente. 2. Formato de cambio de servicio 3. Copia de cédula del cliente.

2. Formato de cambio de servicio impreso 3. Fotocopia de la cedula del cliente.

Elegir tipo de reposición

1. Esta elección se transmite verbalmente por parte de cliente. 2. Formato de cambio de servicio impreso y diligenciado. 3. Fotocopia de la cedula del cliente

1. Elección del tipo de reposición. 2. Formato de cambio de servicio diligenciado 3. Copia de la cedula del cliente

1. Servicio al cliente reposición. 2. Servicio al cliente reposición. 3. Servicio al cliente reposición.

1. Servicio al cliente reposición.

1. Datos demográficos del cliente

1. Estos datos están escritos en el formato de cambio de servicio diligenciado.

Verificar titularidad del cliente.

1. Esta consulta de la titularidad se hace a través de Poliedro por lo tanto se ve en una pantalla de poliedro.

1. Titularidad o no titularidad del cliente sobre el equipo.

1. Servicio al cliente reposición.

1. Servicio al cliente reposición 2. Servicio al cliente reposición 3. Servicio al cliente reposición 4. Servicio al cliente reposición

1. Datos de la venta 2. Serial equipo actual.3. Datos del cliente 4. PSR RDS 01

1 y 2. Los datos de la venta y del cliente se encuentran en el formato de cambio de servicio diligenciado 2. Los seriales se le piden al cliente. 4. La disponibilidad de inventario se ve en el sistema.

Verificar disponibilidad de seriales de reposición y seriales del equipo actual.

1. La disponibilidad de inventario para la reposición se ve en una pantalla del sistema 2. La verificación de IMEI y ICCID se ve en una pantalla de Poliedro

1. PSR RDS 01 2. Aprobación de IMEI e ICCID

1. Servicio al cliente reposición. 2. Servicio al cliente reposición.

1. Servicio al cliente reposición 2. Servicio al cliente reposición.

1. Formato de cambio de servicio diligenciado2. Copia de cédula del cliente.

1. El formato de cambio de servicio está impreso y diligenciado 2. Fotocopia de la cedula del cliente.

Recaudar valor de la reposición

1. Factura original impresa 2. Formato de cambio de servicio con el sello de pagado.

1. PSR OF 02 2. Formato de cambio de servicio con timbre de pagado.

1. Servicio al cliente reposición. 2. Servicio al cliente reposición.

1. Servicio al cliente 1. Formato de cambio 1. El formato de Activar Equipo o SIM 1. Equipo o SIM 1. Equipo o SIM 1. Servicio al cliente

53

MACROPROCESO: SOPORTE AL SERVICIO.PROCESO: SERVICIO AL CLIENTE REPOSICIÓN.


LIDER O RESPONSABLE DEL PROCESO: Servicio al cliente. PROCESOS O

PERSONA PROVEEDOR DE LA

ENTRADA


SALIDA SALIDA

PROCESOS O PERSONA CLIENTE DE

LA SALIDA DEL PROCESO

reposición. 2. Servicio al cliente reposición.

de servicio con timbre de pagado. 2. Copia de cédula del cliente.

cambio de servicio está impreso y diligenciado 2. Fotocopia de la cedula del cliente

CARD o los dos. CARD física 2. Copia adjunta al original del cambio de servicio. 3. Factura original Impresa.

CARD activada o los dos. 2. Copia amarilla del formato de cambio de servicio. 3. PSR OF 02

reposición. 2. Servicio al cliente reposición. 3. Servicio al cliente reposición.

1. Servicio al cliente reposición. 2. Servicio al cliente reposición. 3. Servicio al cliente reposición

1. SIM CARD o equipo o los dos activados. 2. Copia amarilla del formato de cambio de servicio. 3. PSR OF 02

1. SIM CARD o equipo o los dos físicos 2. Copia adjunta al original del formato de cambio de servicio 3. Original de la factura impresa.

Entregar equipo o Sim Card activados o los dos al cliente 1. Cliente satisfecho.

PROCESOS RELACIONADOS: Compra de equipos y Sim Card. RECURSOS: Humanos: Líder de servicio, Líder de caja y bodega, Auxiliar de caja y bodega. Físicos: Instalaciones CPS's CGC, Papelería, Computadores. Económicos: Pago de la reposición. Electrónicos: Software actual, SICACOM, POLIEDRO. DOCUMENTOS INTERNOS: PSR RDS 01 Disponibilidad de inventario PSR OF 02 Original factura.

DOCUMENTOS EXTERNOS: - Copia de cédula del cliente.

INDICADORES: SIAC (Sistema de información de administración de clientes) Indica los números de usuarios atendido y el número de usuarios que desistieron en cada uno de los puntos


Tabla 20. Significado de siglas de codificación Codificación documentos

Siglas SignificadoPSR Proceso de servicio al cliente reposición RDS Reporte disponibilidad de SIM CARD OF Original factura # Consecutivo


54

Gráfico 9. Diagrama de flujo propuesto para el proceso de Servicio al cliente Recargas


55

Tabla 21. Caracterización propuesta del proceso de Servicio al cliente recargas MACROPROCESO: SOPORTE AL SERVICIO.

PROCESO: SERVICIO AL CLIENTE RECARGAS.

OBJETIVO: Venta de recargas para los celulares de los cliente Comcel.

LIDER O RESPONSABLE DEL PROCESO: Líder de caja y bodegas.

PROCESOS O PERSONA PROVEEDOR DE LA ENTRADA ENTRADA FORMATO

ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA

PROCESOS O PERSONA CLIENTE DE LA SALIDA DEL

PROCESO

1. Servicio al cliente recargas 1. Necesidades del cliente.

1. Estas necesidades son transmitidad verbalmente por parte del cliente.

Recaudar valor de la recarga.

1. Original de la factura Impreso 1. PR OF 01 1. Servicio al cliente recargas.

1. Servicio al cliente recargas. 2. Servicio al cliente recargas.

1. Numero de celular 2. Valor de la recarga.

1. El numero de celular lo proporciona el cliente verbalmente 2. El valor de la recarga se encuentra en el PR OF 01

Confirmar número telefónico y realizar recarga

1. Carga realizada. 2. Cliente satisfecho

PROCESOS RELACIONADOS: RECURSOS: Humanos: Líder de caja y bodega, Auxiliar de caja y bodega. Físicos: CPS's de CGC. Económicos: Pago de Tarjeta pre-pago o recarga. Electrónicos: Software actual. DOCUMENTOS INTERNOS: PR OF 01 Original factura

DOCUMENTOS EXTERNOS:

INDICADORES:


Tabla 22. Significado de siglas de codificación Codificación documentosSiglas SignificadoPR Proceso servicio al cliente recargas OF Original factura # Consecutivo

Fuente: Autor del actual trabajo

56

6.2.1. Caracterización de diagramas de procesos propuestos Como se pudo ver, después de cada diagrama del flujo de cada proceso se encuentra su respectiva caracterización. Es importante resaltar que al proceso de “compra de equipos” se le cambió el nombre a “Compra de equipos y Sim Card” unificándolo con el proceso de “Compra de recargas o Sim Card”. Esta unificación de procesos se llevó a cabo por las siguientes razones:

• El proceso de “compra de recargas o Sim Card” es exactamente igual al de “compra de equipos” ya que al igual que los Kit pre-pago, las Sim Card son compradas y por ende son propias de CGC.

• En el proceso de “compra de recargas o Sim card” se manejaba la compra de tarjetas prepago pero al ver que este servicio post-venta desaparece, no hay necesidad de determinar un proceso para el mismo.

Por otro lado, debido a que la compañía decidió no comprar más tarjetas pre-pago, el proceso de “Servicio al cliente Recargas” tuvo algunos cambios y por esto se propuso un nuevo diagrama de procesos con su respectiva caracterización para la actualización de las actividades de este proceso. Los elementos que se manejaron en estas caracterizaciones son los mismos que se manejaron en las caracterizaciones de la situación actual. La codificación de los documentos usados en los procesos propuestos fue actualizada debido a la inclusión o supresión de algunos documentos. Por último, las situaciones propuestas de los procesos representan los cimientos de los requerimientos funcionales, esto se debe a que la disciplina “modelación del negocio” (Ver capitulo 11.1.1. RUP) se define como el entendimiento del negocio de la organización. Esto no quiere decir que el entendimiento del negocio sea suficiente, por lo contrario, muchas veces es necesario hacer reingeniería en sus procesos antes de pensar en diseñar una solución informática para el mismo. La razón es que si se diseña una solución informática sobre un proceso que se lleva a cabo ineficiente e ineficazmente, por lo general, el esfuerzo va a ser en vano ya que tarde o temprano los procesos se modificarán.

57

7. Sistema de información y usuarios

7.1. Información gerencial Uno de los propósitos de la sistematización de los procesos de una compañía es mejorar la fiabilidad de los datos que son manipulados con el fin de que la información que se genere con estos también sea fiable. Además de la información que se maneja entre los usuarios del sistema, la gerencia de CGC requiere información relevante para la toma de decisiones; los informes que requiere la gerencia de CGC son 2:

Inventarios de baja rotación: Con el fin de hacerle seguimiento a las diferentes referencias de celular que ofrece Comcel, la gerencia requiere la información de la rotación de los inventarios para tomar decisiones. Por ejemplo existe una referencia x de la cual se tienen 100 celulares en inventario hace 6 meses. La gerencia puede tomar decisiones como sacar promociones para mejorar la rotación de esa referencia x o aclarar con el coordinador del CPS si es que los vendedores no le están dando la fuerza necesaria a la referencia. Existen varias decisiones que puede tomar la gerencia, pero solo se pueden tomar correctamente con la información necesaria y fiable del sistema.

Información de planes vendidos: Con el fin de controlar la gestión de los asesores de ventas, la gerencia de CGC requiere la información de los planes vendidos (abiertos, cerrados y corporativos) por CPS para analizar el comportamiento de las ventas.

CGC ofrece planes de datos y de voz de gama alta (ej. plan ilimitado) y de gama baja (ej. Planes junior), por ende, los asesores de venta tienen un portafolio amplio para ofrecer a la hora de la venta. Esto les da la libertad de analizar las necesidades del cliente y ofrecerles los productos que más se ajusten a sus necesidades. Esta es una de las mejores prácticas de los vendedores siempre y cuando estén basándose en las necesidades del cliente y no en sus propias preferencias. Al sesgar a los clientes con sus preferencias, por lo general, se enfocan en un solo producto y esto se ve reflejado en la información de planes vendidos por CPS.

Una de las decisiones que se pueden tomar en este caso es una reunión con los asesores para informarles que tienen que darle más fuerza a los demás productos de la compañía. De esta manera se les hace saber que la gerencia está al tanto de lo que están haciendo y que si lo siguen haciendo se verá reflejado nuevamente en los informes de planes vendidos. Decisiones como esta solo son posibles cuando la información es la correcta. 7.2. Posibles sistemas de información Ahora que se sabe cómo se comportan los procesos dentro de la organización, y además la información que solicita la gerencia para tomar decisiones, es posible determinar que tipos de sistemas son adecuados para CGC.

Hay dos tipos de sistemas, los sistemas formales y los informales. Los sistemas formales se apoyan en definiciones fijas y aceptadas de datos y procedimientos para recolectar, almacenar, procesar, distribuir y utilizar estos datos. Los informales se basan, por el

58

contrario, en reglas de comportamiento no establecidas. Para este estudio se determinará que sistemas de información formal son apropiados para CGC.2

Existen 4 tipos de sistemas de información formal, sistemas a nivel operativo, sistemas a nivel de conocimientos, sistemas a nivel administrativo y sistemas a nivel estratégico.

De acuerdo a la situación actual de los procesos de CGC y la situación propuesta anteriormente, se recomienda que la compañía desarrolle los siguientes tipos de sistemas de información formal: 7.2.1. Sistema a nivel operativo Este sistema es el más importante a desarrollar en este momento por las siguientes razones:

La mayoría de los impactos explicados en el “cuadro de descripción y calificación” y la puntuación final del diagrama matriz, dejan ver que todos los procesos operativos (exceptuando capacitaciones de asesores antiguos y nuevos) afectan a los procesos administrativos, lo cual significa que los datos con los cuales se está generando la información en los procesos operativos no son fiables, por ende, un sistema de información a nivel operativo serviría para mejorar la fiabilidad de la información en este nivel.

En el anteproyecto de grado (anexo 31) se explicó a cabalidad el problema que presenta el software actual con el control de inventarios, además, en la explicación de los procesos que se priorizaron para sistematizar (en el presente trabajo) se brindó un ejemplo del impacto que tiene una la subvaloración del costo de inventarios en las decisiones de CGC.

Los sistemas a nivel operativo apoyan a los gerentes operativos en el seguimiento de las actividades y transacciones elementales de la organización como ventas y control de inventarios. Esto quiere decir que un sistema de información a nivel operativo mejoraría la información de manejo de inventarios y al mismo tiempo (en este caso) evitaría la subvaloración del costo de inventarios que presenta el software actual.

Actualmente existe reproceso de información a través de los procesos operativos de CGC. Por ejemplo, en el proceso de ventas, se está verificando dos veces el estatus de Data crédito causando multas de Comcel que no se deberían causar. Por cada consulta que no constituya una venta Comcel cobra $2500, es decir que cuando se hacen 2 consultas de Data crédito se corre el riesgo de incurrir en una multa de $5000 si no se cierra la venta.

Estas multas se podrían evitar si la información fluyera correctamente y además si la información, luego de ser ingresada o consultada, estuviera disponible para posteriores consultas. Estos se puede lograr si el sistema de información almacenara el estatus de data crédito de los clientes, de esta manera, la segunda consulta no se haría en línea con Comcel sino que sería información del sistema.

En este momento el proceso “ventas” no fluye de manera correcta por varias razones, una de ellas es que el software actual no almacena la información ingresada, por ejemplo, los datos demográficos del cliente y los datos de la venta ingresados por el líder de activaciones no son almacenados, de manera que líder de caja y activaciones se ve obligado a ingresar la información por segunda vez. Si el software actual almacenara los datos que ingresa el líder de activaciones, el líder de caja solo tendría que jalarlos con la

2 Sistemas de información gerencial (administración de la empresa digital), Kenneth C. Laudon, Jane P. Laudon, 10ma edición, 2008.

59

cedula o el numero de contrato de la venta y de esta manera la velocidad del proceso mejoraría.

En el proceso “control de inventarios” se presentan problemas tales como la asignación doble de seriales, es decir que cuando en el proceso “ventas” o “activaciones” se le asigna un equipo a una venta, este no está siendo descargado de forma correcta del inventario, dando lugar a una segunda asignación del mismo serial. A raíz de esto se presentan otros problemas como cuellos de botella a la hora de asignar equipos para las ventas, ya que en la segunda asignación que hace el software actual el líder de caja no encuentra el equipo y esto lentifica el proceso de ventas.

Estos problemas se podrían solucionar si la descarga de equipos fuera correcta, es decir, si el sistema a nivel operativo fuera más efectivo.

7.2.2. Sistema a nivel administrativo

Este sistema es importante para la compañía en este momento ya que sin este no se podrían entregar los informes que quiere la gerencia. Estos informes son dos y ya se explicaron con anterioridad: • Inventarios de baja rotación • Información de planes vendidos

Otra de las razones por las cuales se debería desarrollar un sistema a nivel administrativo y por la cuales un sistema a nivel estratégico no es adecuado, es que al desarrollar un sistema a nivel estratégico también se desarrolla un modulo exclusivamente para este fin. Este modulo es manipulado por las directivas de la compañía y en este caso el gerente general quiere únicamente la generación de informes pero no quiere acceso al sistema. De manera que este acceso se le puede relegar al coordinador administrativo para que esta persona prepare la información para las directivas de CGC.

En conclusión, por el momento no es adecuado desarrollar un sistema a nivel estratégico ya que estos sistemas son un apoyo para la toma de decisiones en aspectos estratégicos y tendencias a largo plazo, tanto en la empresa como en su entorno externo, respondiendo preguntas como:

o ¿Cuáles serán los niveles de empleo dentro de 5 años? o ¿Cuáles las tendencias a largo plazo de los costos de la industria donde encaja

nuestra empresa? o ¿Qué otro mercados se puede atacar? o ¿Qué otro productos podemos desarrollar?

Estos aspectos no son relevantes pero tampoco son importantes para CGC ya que CGC es un proveedor de ventas para Comcel lo que lo ata automáticamente a las decisiones de Comcel con respecto al entorno externo. Ademas no existe cultura estratégica en la compañía por lo cual no es relevante en el momento direccionar un software en ese sentido. CGC es un distribuidor de Comcel lo cual lo restringe a comercializar los productos ofrecidos por este operador de telefonía celular., por lo tanto, no es adecuado diseñar un sistema de información a nivel de conocimientos ya que estos sistemas promueven la creación de conocimiento nuevo y garantizan que éste y la experiencia técnica se integren adecuadamente en la empresa. Estos sistemas son adecuados para empresas que desarrollan productos nuevos o para departamentos de ingeniería donde se está innovando constantemente.

60

A partir de la propuesta de esto dos sistemas de información se puede hacer un primer acercamiento a los datos que se manejarían en los sistemas. 7.3. Tipos de datos

En aras de la definición de los posibles usuarios del sistema de información, se determinará que datos son creados, consultados o modificados por los usuarios. Para esto, se hará un primer acercamiento a los tipos de datos en el sistema. Es un primer acercamiento ya que para determinar los tipos de datos definitivos hay que hacer un estudio profundo acerca de las clases del sistema. A continuación, se expone porque se sale del alcance del proyecto el estudio de las clases del sistema, sus respectivos atributos y asociaciones. Un clasificador modela un concepto discreto que describe cosas (objetos) que tiene identidad, estado, comportamiento, relaciones y una estructura interna opcional. Los tipos de clasificadores incluyen clases, interfaces y tipos de datos (El término más familiar es clase). Otros tipos de clasificadores son materializaciones de conceptos de comportamiento, elementos en el entorno o estructuras de implementación. Estos clasificadores incluyen casos de uso, actor colaboración, componente y nodo, así como varios tipos de comportamiento. Los clasificadores que se estudiarán a profundidad en este documento son los casos de uso, protagonistas de los diagramas de casos de uso. Una clase representa un concepto discreto dentro de la aplicación que se está modelando y esta a su vez representa un elemento de un tipo particular –un elemento cosa física (como un avión), un elemento de negocio (como solicitud), un elemento lógico (como la programación de la retransmisión de un evento), un elemento de una aplicación (como el botón de cancelar), un elemento de computación (como una tabla indexada) o un elemento de comportamiento (como un tarea). Una clase es el descriptor para un conjunto de objetos con similar estructura, comportamiento y relaciones. Todos los atributos y operaciones se vinculan a clases u otros clasificadores. El estado de una clase se describe mediante atributos y asociaciones. Todo lo anterior, referente a clases de un sistema, es producto de un excelente levantamiento de los requerimientos funcionales, y a su vez, este levantamiento de requerimientos depende de los casos de uso que se documenten. La dinámica de un caso de uso se puede especificar mediante interacciones de UML (unified modeling language: ver sección de requerimientos del software), materializadas en descripciones informales de texto. Cuando se implementan los casos de uso, éstos son realizados mediante colaboraciones entre clases del sistema. Una clase puede participar en múltiples colaboraciones y, por lo tanto, en múltiples casos de uso. Un caso de uso es una descripción lógica de una funcionalidad. No es una construcción manifiesta de la implementación de un sistema, en su lugar, cada caso de uso es el origen de las clases que implementan un sistema. El comportamiento del caso de uso, es el origen de las transiciones y operaciones de las clases. En la medida en la que una clase puede desempeñar múltiples roles en la implementación de un sistema, puede por lo tanto realizar partes de varios casos de uso. Parte de la tarea de diseño es encontrar clases que combinen limpiamente los roles adecuados para implementar todos los casos de uso. 3 En conclusión, es tarea de diseñador de software llevar a cabo este estudio de las clases del sistema y es claro que el estudio de las clases se sale del alcance del proyecto. Por último, es importante hacer claridad que los tipos de datos en este documento son simplemente un primer acercamiento a lo que serían los tipos de datos definitivos del 3 Lenguaje unificado de modelado Manual de referencia. Pearson education 2007

61

sistema. Este primer levantamiento de los tipos de datos se hace con el fin de poder determinar los usuarios del sistema analizando quien consulta, crea o modifica los mismos. Tipos de datos: • Texto: Es una cadena de caracteres alfanuméricos (letras, números, se pueden incluir

caracteres especiales o espacios en blanco). Ej. Apellido del cliente, Nombre del cliente, Dirección, Teléfono.

• Numérico: Son números destinados a realizar operaciones. • Auto numérico: Es un valor numérico que incrementa de modo automático cada vez que

se agrega un registro a una tabla. Ej.: Código de venta. • Fecha y hora: Fecha y hora de algún registro. • Memo: Este tipo de dato se utiliza para casos como los comentarios de servicio al cliente

donde el usuario puede registrar lo que quiera. • Moneda: Valores de moneda o valores numéricos que representan cantidades

expresadas con un formato de moneda. Ej. Precio de un producto. • SI/NO o lógico: Se utiliza para registrar datos que solo tengan dos posibilidades o datos

booleanos. Ej. Si-no, 0-1, falso-verdadero, etc. Ej. Saber si un pedido ha sido enviado. • Objeto OLE: SE utiliza para objetos tales como: gráficos, texto, imágenes. En la tabla 23 se muestran los tipos de datos que posiblemente se manipularán en el sistema:

Tabla 23. Tipos de datos No. Datos Tipo Ejemplo Software donde se crea Proceso

Creación Uso

1 Nombre del cliente Texto Diego Software actual

Ventas / Servicio al

cliente reposición

Ventas / Activaciones / Servicio al cliente

reposición

2 Apellido del cliente Texto Infante Software actual


cliente reposición


reposición

3 Cedula del cliente

Numérico 80.875.601 Software actual


cliente reposición


reposición

4 Dirección de

residencia del cliente

Texto Cll 162 # 54-95 Software actual


cliente reposición


reposición

5 Ciudad del cliente Texto Bogotá Software actual


cliente reposición


reposición

6 Teléfono del cliente Texto 8018034 Software actual


cliente reposición


reposición

7 No. Contrato de la venta

Numérico 1207527

Software actual: Estos seriales son asignados por Comcel y no puden sufrir ningún cambio en el proceso de ventas

de CGC.


cliente reposición


62

No. Datos Tipo Ejemplo Software donde se crea Proceso

Creación Uso reposición

8 Descripción del material Texto 1208 NOKIA

NUEVO

Software actual: Esta descripción de material viene con la remisión de los

pedidos a Comcel.

Compra de equipos y Sim Card

Control de inventarios / Compra

de equipos y Sim Card

9 Plan Texto Plan Más Software actual


cliente reposición


reposición

10 Fecha de la venta

Fecha y hora

13/09/2009, 2:00 pm Software actual: Día/Mes/Año


cliente reposición


reposición

11 Valor de la venta Moneda $ 57.200 Software actual


cliente reposición


reposición

12 Estatus de data crédito

Booleano Aplica

Poliedro: Esta información la muestra poliedro pero el estatus de data crédito tiene que ser ingresado manualmente al sistema. La razón por la cual tiene

que ser ingresada manualmente es que data crédito arroja mucha información con la cual se analiza el cliente y se

determina si aplica o no aplica para la venta.

Ventas


reposición

13 MIN (Numero del celular)

Numérico 10120

Software actual: Estos códigos vienen junto con la remisión de los pedidos a

Comcel. Excel: Estos códigos los envía Comcel con los informes de disponibilidad de

inventario

Activaciones Ventas

14

Cantidad solicitada por el coordinador

del CPS

Numérico 13 Software actual



15

Fecha Pedido del

coordinador del CPS

Fecha y hora




16

Responsable (del pedido de

material del CPS)

Texto Diego Infante Software actual Compra de equipos y Sim Card


17 Bodega CGC Numérico 1807

Excel: Estos códigos los envía Comcel con los informes de disponibilidad de

inventario: 1807: Bodega ppal cgc 2017: Reposición Cgc Venecia 2061: CGC San andresito 2076: CGC Villeta


Compra de equipos y Sim Card / Control de inventarios

18 Descripción bodega CGC Texto Bodega ppal

CGC Excel: Ver tipo de dato 17 Compra de equipos y Sim Card


19 IMEI Numérico 11355


Comcel. Excel: Estos códigos los envía Comcel



63


Creación Uso con los informes de disponibilidad de

inventario reposición / Control de inventarios

20 Precio del material Moneda $ 57.200


Comcel.



21

Descuento (Otorgado por

Comcel a CGC)

Numérico 3%


Comcel.



22 Plazo de pago Numérico 2


Comcel. La unidad de este número viene siempre en meses



23 Código del material

Numérico 10815



inventario



reposición / Control de inventarios

24 Centro Numérico 1750



inventario 1750: post pago 2000: reposición




25 Almacén Booleano Activo


inventario. El propósito de este dato es saber si el producto está o no está en

bodega. Activo: En bodega

No activo: No en bodega




26 Fecha de

registro del material

Fecha y hora





27 Estado final Booleano Activo


inventario. El propósito de este dato es saber si el producto está o no está

activado. Activo: Producto activado

No activo: Producto no activado



28 CPS Texto Calle 13

Software actual: Estos códigos se encuentran en la disponibilidad de

inventario de CGC. En vista de que Comcel solo maneja 4 bodegas de CGC, es necesario tener un manejo de inventarios que incluya

en que cual de las 9 bodegas se encuentran los productos.



29 Estado Booleano

Ok en bodega


inventario de CGC. Son la forma de verificar si la

disponibilidad de inventario que envía Comcel corresponde a la disponibilidad



64


Creación Uso de CGC.

Ok en bodega: Informe ok No en bodega: Informe no ok

30 Estado s&f Booleano Sobrante


inventario de CGC. Son la forma de saber si hay faltantes o sobrantes con respecto a el informe de

disponibilidad de inventarios de Comcel.

Sobrante:

Producto que no se encuentra en el inventario de

Comcel

Faltante:

Producto que no se encuentra en el inventario de

CGC



31 Titularidad Booleano Titular

Poliedro: Este dato lo entrega poliedro al hacer la consulta de si el cliente es el

titular o no es el titular del equipo al cual se le está brindando algún servicio

(Ej. Reposición). Titular: Cliente titular

No titular: Cliente no titular

Servicio al cliente

reposición

Servicio al cliente

reposición

32 Serial

correspondiente al plan

Booleano

Serial y plan ok

Poliedro: Este dato lo entrega poliedro al hacer la consulta de si el serial

corresponde al plan del equipo al cual se le está brindando algún servicio (Ej.

Reposición).

Seria y plan ok:

Serial corresponde al

plan

Serial y plan no ok:

Serial no corresponde al

plan

Servicio al cliente

reposición

Servicio al cliente

reposición

33 Numero de factura

Auto numéric

o

300.442-1-75.432

Software actual: Este serial es asignado por la DIAN el 1er número

corresponde al número de CGC, el 2do número corresponde al número del CPS de galerías y el 3er número

corresponde al número de la factura.


cliente reposición

Activaciones / Ventas / Servicio al

cliente reposición

34 Numero de pedido de

coordinador

Auto numéric

o 23

Software actual: Este consecutivo corresponde a la suma de todos los

pedidos hechos hasta el momento por parte de los coordinadores de CPS más

1.




CGC

Auto numéric

o 10


pedidos hechos hasta el momento por parte de CGC más 1. Como ya se

sabe, no todos los pedidos que hacen los coordinadores de CPS se hacen

efectivos.



36

Numero de orden de

compra de Kits

Auto numéric

o 5


pedidos de kits hechos hasta el momento más 1.



37 Fecha de la reposición

Fecha y hora

13/09/2009, 2:00 pm Software actual: Día/Mes/Año Servicio al

cliente Activacione

s

65


Creación Uso reposición

38 Status cartera Booleano Cartera ok

Software de contabilidad: En el momento que el coordinador

administrativo necesita el estado de la cartera este software debería arrojarlo.

Cartera ok: No hay pagos pendientes

Cartera no ok: Hay pago pendientes



39 Fecha status Fecha y hora




40 ICCID Numérico 836759



inventario.




41 Numero de ventas

Numérico 543

Software actual: Este número corresponde a la suma de las ventas

efectivas de un producto Ventas

42 tiempo en inventario

Numérico 50

Software actual: Este número corresponde al número de días que

permanece un producto en inventario


43 Numero de documento

Numérico 1008498912

Software de contabilidad: Este número corresponde al número de documento

de contabilidad en el cual está registrado el importe a pagar



44 Fecha de documento

Fecha y hora

13/09/2009, 2:00 pm Software de contabilidad: Día/Mes/Año



45 Días en mora Numérico 3

Software de contabilidad: Este número corresponde a la suma de los días que lleva en mora el pago correspondiente.



46 Importe Moneda $514.924 Software de contabilidad: Este valor

corresponde al valor a pagar al acreedor.



47 Descripción Texto RECARGA

PASATIEMPO

Software de contabilidad: Este es un espacio para describir el concepto de la

deuda.



48 Valor de la recarga Moneda $10.000

Software actual: Este valor corresponde al valor de la recarga que quiere hacer

el cliente

Servicio al cliente

recargas

Servicio al cliente

recargas

49 Fecha de la recarga

Fecha y hora


Servicio al cliente

recargas

Servicio al cliente

recargas

50 Min de la recarga

Numérico 32

Software actual: Este valor corresponde a la equivalencia en minutos de la

recarga.

Servicio al cliente

recargas

Servicio al cliente

recargas


66

7.4. Datos vs Usuario

La tabla 24 muestra las acciones que llevan a cabo los usuarios del sistema sobre los datos especificados en la tabla 23. Estas acciones pueden ser crear (Ingresar datos nuevos al sistema), modificar (Editar algún dato) o consultar (visualizar algún dato), o combinaciones de las mismas. Esta tabla contribuirá a la determinación de los usuarios de sistema.

Tabla 24. Tratamiento de los usuarios sobre los datos USUARIO

No. Datos Asesor

de ventas

Líder de caja y

bodega / Auxiliar

Líder de activaciones

Coordinador CPS

Coordinador administrativo

Líder de servicio Planillador

1 Nombre del cliente Consulta Crea y

modifica Consulta

2 Apellido del cliente Consulta Crea y

modifica Consulta

3 Cedula del cliente Consulta Crea y

modifica Consulta

4 Dirección de

residencia del cliente

Consulta Crea y modifica Consulta

5 Ciudad del cliente Consulta Crea y

modifica Consulta

6 Teléfono del cliente Consulta Crea y

modifica Consulta

7 No. Contrato de la venta Consulta Crea y

modifica Consulta

8 Descripción del material Consulta Crea y

modifica Consulta Crea y modifica Consulta Consulta

9 Plan Consulta Crea y modifica Consulta

10 Fecha de la venta Consulta Crea Consulta

11 Valor de la venta Consulta Crea y

modifica Consulta

12 Estatus de data crédito Consulta Crea y

modifica Consulta

13 MIN (Numero del celular) Consulta Crea Consulta

14

Cantidad solicitada por el coordinador del

CPS

Crea y modifica Consulta

15 Fecha Pedido

del coordinador del CPS

Crea Consulta

16

Responsable (del pedido de

material del CPS)

Crea Consulta

17 Bodega CGC Crea y modifica Consulta

_ Crea y modifica

_ Consulta

18 Descripción bodega CGC Crea y

modifica Consulta _ Crea y modifica

_ Consulta

19 IMEI Crea Consulta Consulta Consulta Consulta

20 Precio del material

_ Crea y modifica

_ Consulta

21 Descuento (Otorgado por _ Crea y

modifica

67

USUARIO

No. Datos Asesor

de ventas

Líder de caja y

bodega / Auxiliar


Coordinador CPS



Comcel a CGC) _ Consulta

22 Plazo de pago _ Crea y modifica

_ Consulta

23 Código del material Crea y

modifica Consulta Crea y modifica Consulta Consulta

24 Centro Crea y modifica

_ Crea y modifica

_ Consulta

25 Almacén Consulta _ Crea y modifica

_ Consulta

26 Fecha de

registro del material

Crea Consulta Consulta Consulta

27 Estado final Crea y modifica Consulta Consulta Consulta

28 CPS Crea y modifica Consulta Consulta

29 Estado Crea y modifica Consulta Consulta Consulta

30 Estado s&f Consulta Crea y modifica

31 Titularidad Consulta Crea y modifica Consulta

32 Serial y

correspondiente plan

Consulta Crea y modifica Consulta

33 Numero de factura Crea y

modifica Consulta Consulta


coordinador Crea

Consulta Consulta

35 Numero de pedido de CGC Crea

Consulta

36 Numero de orden de

compra de Kits Consulta Crea y

consulta

37 Fecha de la reposición Consulta _Crea

_Consulta

38 Status cartera _ Crea y modifica

_ Consulta

39 Fecha status _ Crea y modifica

_ Consulta

40 ICCID Crea Consulta Consulta Consulta Consulta

41 Numero de ventas Crea Consulta

42 tiempo en inventario _Crea

Consulta

43 Numero de documento

_ Crea _ Consulta

44 Fecha de documento

_ Crea _ Consulta

45 Días en mora _ Crea

_ Consulta

46 Importe _ Crea

_ Consulta

68

USUARIO

No. Datos Asesor

de ventas

Líder de caja y

bodega / Auxiliar


Coordinador CPS



47 Descripción _ Crea

_ Consulta

48 Valor de la recarga

_ Crea_

Consulta

49 Fecha de la recarga

_ Crea_

Consulta

50 Min de la recarga

_ Crea_

Consulta


7.4.1. Usuarios del sistema En este cuadro se puede ver con claridad que el asesor de ventas no tendría contacto con el sistema. Esto se debe a que la función principal de esta persona es generar información en los formatos que le proporciona Comcel al distribuidor. Esta información se registra a mano en los formatos y el ingreso de los datos relevantes al sistema está a cargo del líder de activaciones. En conclusión, el asesor de ventas no sería un usuario del sistema, simplemente es un recolector de datos escritos a mano para alimentar el sistema. Por otro lado, en la última columna, se puede apreciar un cargo diferente a los que se vienen tratando, el cual no está incluido en los procesos susceptibles a sistematizar ya que la única función que lleva a cabo es la verificación de los datos ingresados a poliedro con los datos ingresados al sistema. Estos datos se ven reflejados en las planillas de legalización exigidas por Comcel. Las planillas están prediseñadas en poliedro, tiene un registro máximo de 25 líneas y son generadas automáticamente. Para la legalización de las ventas, CGC tiene que enviar paquetes de 25 líneas activadas junto con la planilla y todos los documentos necesarios para la venta. Después de la anterior explicación es claro que el Planillador es una pieza clave para la legalización de las ventas de CGC y por ende requeriría un usuario para consultar la información ingresada al sistema y compaginarla con la de Poliedro. Es importante recordar que por cada legalización mal hecha Comcel aplica sanciones según el caso. En conclusión, los usuarios que arroja este cuadro son: Usuarios por CPS: • Líder de activaciones • Líder de caja y bodega • Auxiliar de caja y bodega • Líder de servicio • Planillador • Coordinador de CPS Usuario en la sede administrativa: • Coordinador administrativo

69

• Administrador del sistema (Este usuario es necesario en cualquier sistema de información)

70

8. Pasos a seguir para documentar los requerimientos del software El paso a seguir ahora es la definición de los requerimientos de los usuarios. Estos requerimientos se levantarán tomando en cuenta los usuarios que se definieron en el capítulo anterior y en el formato propuesto a continuación. En este capítulo se va a explicar el orden en el que se van a documentar los requerimientos del usuario hasta los requerimientos funcionales (Incluyendo la metodología en la cual se basa el diseño de los casos de uso). Tigris.org (open source software engineering tools) es un portal de información en Internet cuya misión es proveer fuentes de información para profesionales de ingeniería de software y estudiantes. Según esta fuente de información la documentación de los requerimientos de un software se debería estructurar de la manera en que se describirá en esta sección. Por otro lado, se agregaron y se removieron algunos pasos de estos formatos ya que en general el documento de requerimientos no tiene un formato predeterminado y cada diseñador de software debería moldear los formatos preliminares de acuerdo a sus necesidades de tal manera que los requerimientos queden claros y fáciles de interpretar. Debido a que el proyecto que se está desarrollando es un proyecto Inhouse (desarrollo en casa), no se tomarán en cuenta secciones como “publico objetivo y beneficios” ya que inicialmente el producto no es para su comercialización. Algunos de los elementos mencionados en estos formatos ya están documentados en el proyecto de grado (anexo 31), o en el presente trabajo, razón por la cual se especificará en que numeral del proyecto o del trabajo se pueden encontrar. En el orden que se va a seguir, existe un numeral que exige documentación de los casos de uso. Esta documentación se hizo basada en el libro “El lenguaje unificado de modelado. Manual de referencia” de Booch, Jabobson y Rumbauch. “El lenguaje unificado de modelado (UML por su siglas en ingles) es un lenguaje de modelado visual de propósito general que se utiliza para especificar, visualizar, construir y documentar los artefactos de un sistema software. Captura decisiones y conocimiento sobre sistemas que deben ser construidos. Se usa para comprender, diseñar, ojear, configurar, mantener y controlar la información sobre tales sistemas. Está pensado para ser utilizado con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. El lenguaje de modelado pretende unificar la experiencia pasada sobre las técnicas de modelado e incorporar las mejores prácticas de software actuales en una aproximación estándar. UML incluye conceptos semánticos, notación y principios generales. Tiene partes estáticas, dinámicas, de entorno y organizativas. Está pensado para ser apoyado por herramientas de modelado visuales e interactivas que dispongan de generadores, tanto de código, como de informes. La especificación de UML no define un proceso estándar, pero está pensado para ser útil en un proceso de desarrollo iterativo. Pretende dar apoyo a la mayoría de los procesos de desarrollo orientados a objetos existentes.” A partir de esta definición dada por sus autores, es claro que es una herramienta excelente y nos apoyaremos en ella, específicamente en su parte de casos de uso.4 Además del apoyo que brinda la metodología de UML, también se utilizará el formato de documentación de casos de uso propuesto por Karl E. Wiegers en su libro “More About Software Requirements”: Thorny Issues and Practical Advice (Microsoft Press, 2006).

4 Lenguaje unificado de modelado Manual de referencia. Pearson education 2007

71

Se decidió usar este formato ya que la documentación que propone este autor es mucho más completa que la del libro de UML, sin dejar de lado que el apoyo para la herramienta gráfica es mejor en el libro de Booch, Jacobson y Rumbauch. En conclusión se tomaron las mejores herramientas para construir y documentar casos de uso que nos direccionen hacia los requerimientos funcionales correctos. 8.1. Orden propuesto para documentar los requerimientos5

Propuesta del proyecto: Esta propuesta, será usada por las directivas de la compañía para determinar si se aprobará o no trabajar en este proyecto. Un plan de proyecto claro y preciso ayuda a definir las expectativas que serán usadas mas tarde para evaluar el éxito del proyecto. En este caso como el proyecto de grado (anexo 31) se ha venido trabajando junto con las directivas de CGC, no hay necesidad de ponerlo en tela de juicio para su desarrollo.

o Entorno y antecedentes: ¿Cuáles son las necesidades o problemas que está tratando de resolver? ¿Por qué esas necesidades o problemas (aún) existen? ¿Por qué vale la pena resolver estos problemas? ¿Quiénes se beneficiarían? Esta información se encuentra registrada en el numeral 2 “Planteamiento del problema” y en el numeral 3 “Justificación del proyecto” del proyecto de grado (anexo 31).

o Objetivo: ¿Cuál es el objetivo de este proyecto?, Esta información se encuentra registrada en el numeral 5 “Objetivo General” del proyecto de grado (anexo 31).

o Alcance: ¿Cuáles son los objetivos de alto nivel que planea realizar, y cuáles no? ¿Cuáles son sus supuestos o simplificaciones más importantes?, esta información se encuentra registrada en el numeral 6 “Objetivos específicos” y numeral 8 “Restricciones” del proyecto de grado (anexo 31).

o Riesgos y recompensas: Enliste brevemente los mayores riesgos. Los Riesgos son detallados en el borrador del plan del proyecto. En el la estimación del desarrollo del software se especifica que esta tarea es conveniente que se lleve a cabo por parte de los ingenieros jefe y desarrollador.

o Plan del proyecto: Este plan será usado para evaluar y administrar el proyecto. Las suposiciones principales que puedan afectar el plan deberán ser documentadas aquí. El plan del proyecto deberá ser actualizado durante el ciclo de vida del proyecto. Como se dijo en la introducción, la metodología que se utilizará para el desarrollo del software es RUP (Detallada en la evaluación económica). La estimación del tiempo del desarrollo del software almacena la información del plan de proyecto.

o Resumen de la metodología: ¿Que acercamiento (en general) se utilizará para el desarrollo?, ¿Cómo estará organizado el equipo del proyecto?, ¿Qué herramientas de desarrollo y colaboración se utilizarán?, esta información se encuentra registrada en el presente trabajo de grado en la sección de la evaluación económica en la explicación del la metodología RUP (Rational Unified Process).

o Estructura de trabajo y estimados: Enumere las tareas que serán necesarias para este proyecto. Asigne los riesgos en cada actividad. Esta información se encuentra registrada en la estimación del tiempo del desarrollo. Es recomendable retomar la fase de inicio del desarrollo del sistema con la asignación de los riesgos de software. Esta asignación de riesgos la deben

5 http://readyset.tigris.org/nonav/es/templates/user-needs.html; Consultada 16/09/09; 5:30

72

hacer los ingenieros líder y desarrollador ya que ellos tomarán en cuenta tanto los requerimientos funcionales como los no funcionales. De esta manera los riesgos abarcarán gran parte del proyecto.

o Recursos necesarios para el proyecto: Esta propuesta será usada por las directivas de la compañía para determinar si se aprobará o no trabajar en este proyecto. Esta información está registrada en el numeral 11 “recursos” del proyecto de grado (anexo 31), Aunque los recursos económicos detallados del desarrollo del software se encuentran en la evaluación económica.

o Publico objetivo y beneficios: Este documento ayuda a identificar clientes potenciales y a definir sus características. Esto ayuda a sugerir y dar peso a sus requerimientos. La lista de beneficios le da al equipo de ventas información sobre cómo vender el producto, y remarca importantes casos de uso y los casos de prueba. Esta sección se omitirá ya que los requerimientos que se documentarán no apuntan hacia la comercialización de un sistema de información, será más bien un sistema de información personalizado para CGC.

Requerimientos del usuario: Establece los documentos con las necesidades del

usuario y explica los deseos actuales de los inversionistas (directivas de CGC) de forma breve en sus propias palabras. Qué es lo que desean nunca es exactamente los que el producto provee. Documentando las necesidades del usuario aquí, independientemente de la SRS (Software requirement specifications), ayuda a mantener el SRS preciso y hace que las tareas de verificación y validación sean más efectivas. Este documento no es un borrador informal del SRS, es un documento diferente con un propósito complementario. El SRS será equivalente a la sección de conjunto de casos de uso, casos de uso y requerimientos funcionales.

o Objetivos acordados: ¿Hay una definición clara del objetivo global de este proyecto con el que los inversionistas estén de acuerdo? Si es así, incluyalo aquí. Si no, debería resumir lo que entiende de los objetivos del proyecto en sentencias breves e intentar que los inversionistas estén de acuerdo con ellas. En este proyecto los inversionistas son las directivas de CGC ya que los requerimientos apuntan hacia un software personalizado y desarrollado por ellos mismos.

o Ambiente: Describa brevemente varios aspectos del ambiente donde el software será usado. Describa el ambiente como es o será, no como desearía que fuera.

o Inversionistas / Actores y requerimientos (por rol): Enumere y describa a los actores de este producto. Estos pueden ser nombrados como individuos o por sus roles. Para cada actor, mencione sus necesidades primarias (Requerimientos). Considere el conocimiento técnico esperado de los inversionistas y que tan seguido ellos utilizarían el sistema, así como cualidades importantes, debilidades, preferencias, u otras características.

o Notas de entrevistas y lluvia de ideas: Mantenga un registro de su recolección de requerimientos. Cualquier entrevista en vivo o por teléfono con los inversionistas o de las sesiones de lluvia de ideas con los miembros del equipo de desarrollo. Si la comunicación se llevo a cabo por medios electrónicos, inclúyalos aquí.

o Experiencias de los usuarios: Escriba historias cortas de los usuarios explicando cómo varios actores podrían interactuar con el sistema (directa e indirectamente) para lograr un objetivo real. Las historias de los usuarios no son casos de uso: sus historias deben ser breves (3-5 oraciones) párrafos

73

que describan un escenario específico en términos concretos. En esta descripción de las necesidades de usuario no haga suposiciones sobre los detalles del sistema, concéntrese en los usuarios.

o Necesidades de rendimiento capacidad: Enliste brevemente las características deseadas por los inversionistas para algunos aspectos de la capacidad del sistema.

Especificación de requerimientos de software: Especificación de Requerimientos de

Software (SRS Software Requirements Specification) define de forma precisa el producto de software que se va a construir. El SRS está basado en información de los documentos de la propuesta del proyecto y requerimientos del usuario. El conjunto de requerimientos de SRS deben ser satisfechos en el diseño del sistema. No sobra recordar que los requerimientos que se espera que este proyecto determine son únicamente los funcionales, ya que este formato especifica requerimientos funcionales, no funcionales y ambientales.

o Casos de uso: Los actores son descritos en el documento de requerimientos

de usuario. o El “conjunto de casos de uso”: Un conjunto de casos de uso es

simplemente una lista de los casos de uso individuales. Esta lista tiene como objetivo, enumerar los casos de uso desde diferentes perspectivas y de esta manera no dejar ningún caso de uso sin analizar. Además se le asociará una prioridad definida con las directivas de CGC para detectar los requerimientos más importantes. Asignación de la prioridad del caso de uso. Esta prioridad significa el grado de urgencia para su desarrollo y se debe acordar con los inversionistas del software que en este caso son las directivas de CGC.

o Diagramación y documentación de los casos de uso: Se documentarán y diagramarán los casos de uso.

o Requerimientos funcionales: A partir de los casos de uso determinar los requerimientos funcionales del software. Un buen levantamiento de los casos de uso tiene una relación 1 a 1 entre los casos de uso y los requerimientos funcionales.

o Requerimientos no funcionales: Describa los requerimientos no funcionales para esta entrega. No aplica para este proyecto.

o Requerimientos ambientales: Describa los requerimientos ambientales para esta entrega. Los requerimientos ambientales describen los sistemas más grandes (hardware, software) con los que este producto debe trabajar. (Ejemplo: Poliedro, Sicacom). No se sabe aún si el software va a tener una interfaz para comunicarse con los software actuales. No aplica para este proyecto. Esta fase queda a cargo del ingeniero líder y desarrollador.

74

9. Desarrollo de los requerimientos del usuario

Todos los aspectos analizados en la tabla 25 están definidos dentro del proceso de diseño e implementación del software, por ejemplo, cuando en el aspecto “proyecto” se especifica que es un “Software para integrar los procesos operativos del distribuidor CGC de Comcel” no se refiere al trabajo de grado sino al proyecto global al cual apunta este documento. Por otro lado, para la generación de este documento fue vital todo el trabajo previo, es decir, desde el análisis de la situación actual hasta la determinación de los usuarios se extrajo información para levantar este documento. Para mayor información acerca de este formato ver capítulo 8.

Tabla 25. Requerimientos del usuario

REQUERIMIENTOS DEL USUARIO Proyecto: Software para integrar los procesos operativos del distribuidor CGC de Comcel. Versión: 1

Objetivos acordados Desarrollo de un software, que integre los procesos susceptibles de sistematización en la empresa CGC.

Ambiente Ambiente de negocios

Los empleados de CGC que son actores en los procesos operativos, comparten información de ventas, activaciones, caja y bodega, inventarios y reposiciones, por lo tanto esta información debe estar disponible para el que la necesite (dependiendo de sus condiciones), actualizada y modificable según las necesidades.

Ambiente físico del sistema Las diferentes sedes de CGC brindan buena iluminación, son espaciosas, las áreas de trabajo están bien delimitadas, en general se cuenta con buenas condiciones ergonómicas para el trabajo. El computador de menor rendimiento que tiene CGC es un Pentium 4, memoria RAM de 2 GB, Disco duro de 250 GB, pantalla plana de 17 pulgadas. Los demás computadores sobrepasan todas las características del anterior. Todas estas características son reales y bajo las mismas tiene que ser implementado el software.

Ambiente tecnológico del sistema Luego de una reunión con los 2 ingenieros de sistemas y el gerente general de CGC se llegó a las siguientes conclusiones:

1. CGC no está dispuesto a pagar ninguna licencia para el software que no sea diferente a las licencias de Windows. En el pasado se invirtieron $ 20’000.000 en el software actual y no vale la pena invertir más recursos económicos teniendo herramientas gratuitas disponibles.

2. El sistema tiene que ser orientado a web ya que todos los CPS tienen que estar conectados. 3. El lenguaje tiene que ser PHP ya que es un lenguaje interpretado mas no compilado, lo cual le daría

mucho más dinamismo al sistema. Lenguajes compilados son C++, Visual Basic, etc., los cuales solo corren únicamente sobre Windows, en cambio, los lenguajes interpretados corren sobre cualquier plataforma, convirtiendo el software en un software multiplataforma.

4. Se utilizará un servidor Apache ya que su licencia es gratuita. 5. El motor de base de datos será Postgres ya que su licencia es gratuita, es robusto y apropiado para el

sistema.

Inversionistas / Actores y requerimientos (por rol)

1) Coordinador administrativo: Esta persona trabaja junto con el gerente general de CGC y por lo tanto es la encargada de brindarle información relevante de la actividad de CGC. Para esta labor necesita información fiable que resuma la actividad de la empresa y revele oportunidades de mejora o en su defecto resultados deseables. Por otro lado, también es la persona encargada del proceso "Compras de equipos y Sim Card" y de "control de inventarios". Requerimientos: _ Información de inventarios de baja rotación _ Información de planes vendidos _ Kardex de CGC _ Solicitudes de equipos y Sim Card de cada CPS _ Reporte de cartera _ Disponibilidad de inventarios

75

REQUERIMIENTOS DEL USUARIO Proyecto: Software para integrar los procesos operativos del distribuidor CGC de Comcel. Versión: 1 2) Líder o auxiliar de caja y bodega: Esta persona está encargada de las cajas de Comcel y de CGC, por lo tanto está encargada de recaudar el valor de todas las facturas que genera Comcel y sean pagadas en los CPS (estas transacciones se llevan a cabo a través del software SiCaCom), además también recauda el valor de todas las ventas, reposiciones y recargas hechas en cada CPS. Por otro lado, las bodegas de los CPS están dentro del espacio que se utiliza para las cajas, de forma que son ellos los encargados del manejo físico del inventario. Requerimientos: _ Condiciones de venta y reposición _ Información de activaciones _ Disponibilidad de inventarios 3) Líder de activaciones: Esta persona es la encargada de las activaciones de los productos ofrecidos por CGC, tiene comunicación constante con Comcel a través de Poliedro y además es la encargada de asignar los equipos para todas las ventas y reposiciones de los CPS. Requerimientos: _ Información de la venta _ Información de reposición _ Información de poliedro _ Disponibilidad de inventario 4) Coordinador CPS: Esta persona es la encargada de la administración del CPS (El que le corresponda), de las capacitaciones de los asesores antiguos y nuevos y también hace parte de los procesos "Control de inventarios" y "Compra de equipos y Sim Card". Esta persona es el jefe directo de todas las personas en el CPS de tal forma que también está encargada de la gestión del recurso humano del CPS. Requerimientos: _ Kardex del CPS _ Disponibilidad de inventario _ Solicitud de inventario CPS _ Necesidades de equipos y Sim Card del CPS _ Comportamiento de las ventas en su CPS

5) Líder de servicio: Esta persona es la encargada de asesorar a los clientes en el pago de sus facturas, de las reposiciones y de orientar a los clientes que entren al CPS dependiendo de sus necesidades. Requerimientos: _ Disponibilidad de inventario 6) Planillador: Es la persona encargada de la verificación de los datos ingresados a poliedro con los datos ingresados al sistema. Esta persona trabaja en las horas de la noche y la madrugada. Requerimientos: _ Información de poliedro _ Información de reposición _ Información de venta _ Información de activaciones 7) Directivas de CGC: En este caso los inversionistas son las directivas de CGC ya que ellos son los que decidieron poner en marcha el proyecto del diseño de software: Requerimientos: _ Gestión de inventarios _ Gestión de cajas _ Costeo de inventario (Llevar a cabo correctamente PEPS / FIFO)8) Administrador de Software: Esta persona es la encargada de llevar a cabo funciones secundarias en el software, como mantenimiento y administración del sistema. Requerimientos: _ Consultar el comportamiento del software _ Crear usuarios _ Crear usuario de activaciones

Notas de entrevistas y lluvias de ideas Toda la información de las entrevistas se encuentran en el cuadro de entrevistas completo y en el resumen de las

conclusiones de las entrevistas. Experiencias de los usuarios

76

REQUERIMIENTOS DEL USUARIO Proyecto: Software para integrar los procesos operativos del distribuidor CGC de Comcel. Versión: 1 1) Asignación de seriales y recaudo del valor de la venta:En el momento en que los asesores de ventas llegan a activaciones para que les asignen un equipo, no se toman el tiempo de esperar a la confirmación de la disponibilidad de inventarios y para la generación de seriales en Poliedro. En cambio de esto, con el ánimo de cerrar la venta, van "agilizando" el tramite en caja a sabiendas de que si activaciones aún no les ha asignado el equipo el líder de caja o el auxiliar no pueden generar la factura porque para esto se necesitan los seriales del equipo. Como el líder o auxiliar de caja no tiene forma de saber si activaciones ya asignó el equipo hasta que no llega la información de los seriales escrita en el contrato, el asesor de ventas presiona diciendo que si no lo facturan rápido el cliente se va, generaron así ocasiones en las cuales no hay disponibilidad de inventario y hay que devolverle el dinero al cliente. (Fuente: Líder de activaciones de Calle 13) 2) Asignación doble de seriales: En el momento de llevar a cabo una venta es necesario hacer la asignación de los seriales para la venta. Esta asignación tiene que ser única de otra forma se presenta el problema que tiene el software actual, y es que como no descarga de manera correcta los seriales del inventarios algunas veces asigna el mismo serial para dos ventas. En la primera venta no hay ningún problema, pero como este serial queda disponible para una futura venta con las mismas características es muy posible que se asigne nuevamente este serial. Cuando el líder de caja o al auxiliar tiene que buscar el equipo para entregarlo es evidente que no lo encuentra generando 2 problemas 1. La capacidad de atención de la caja disminuye momentáneamente debido a la demora que se toma la búsqueda del equipo y 2. La lenificación del proceso de ventas y activaciones. (Fuente: Líder de activaciones Calle 13) 3) Clasificación de inventario: El software actual no permite clasificar el inventario que existe en ventas y reposiciones, es decir que CGC tiene inventario de equipos y Sim Card para la venta, equipos y Sim Card para reposición y equipos con Sim Card para Kit Pre-pago. Los inventarios de ventas y reposiciones tienen las mismas características pero tienen que ser clasificados ya que salen de dos bodegas diferentes de Comcel y a la hora de hacer Control de inventario no es posible verificar el origen del producto. Esto lleva a los activadores la asignación de equipos para la venta en reposición y viceversa. (Fuente: Coordinador de CPS Engativa y Avenida 19) 4) Control de inventarios: El control de inventarios que se lleva en este momento es completamente "manual" porque el software actual no soporta el control de manera correcta. Un ejemplo de esto es que cuando llegan los equipos que piden los coordinadores de CPS, al recibirlos se dan cuenta que el software actual arroja que tienen inventario disponible de esta referencia. Lo cual no es verdad porque ya se han perdido ventas causadas por la no disponibilidad de inventario, de manera que tienen que hacer un inventario manual para ver que referencias tienen y verificar el pedido que hicieron. (Fuente: Coordinador administrativo) 5) Cierres de caja:A raíz de los problemas que tiene el software actual con el inventario y con la rigidez a la hora de actualizar las condiciones de venta, los cierres de caja toman mucho tiempo al final del todos los días, haciendo que CGC incurra en horas extras. (Fuente: Líder de caja y bodega Calle 13) 6) Control de inventarios con Comcel: El proceso de control de inventarios con Comcel es muy lento porque en el momento que llega la solicitud de inventario de Comcel se les envía la solicitud de inventario a los CPS. Los Coordinadores de CPS por su parte se toman mucho tiempo cruzando el kardex de ellos con la parte de la solicitud de inventarios de Comcel que les corresponda. Esto se debe a que el Kardex que arroja el software actual no representa la realidad del inventario, entonces tienen que valerse del historial de compras y de ventas del CPS para recrear este Kardex. (Fuente: Coordinador administrativo)

Necesidades de rendimiento y capacidad Por ahora las necesidades de rendimiento y capacidad que se pueden especificar son las características de flujo de usuario. Estas necesidades son: Usuarios totales: (6 usuarios por CPS X 9 CPS) + 1 Administrador + 1 Coordinador administrativo = 56 Usuarios Usuarios por CPS:

Líder de activaciones Líder de caja y bodega Auxiliar de caja y bodega Líder de servicio Planillador Coordinador de CPS

Usuario en la sede administrativa:

Coordinador administrativo Administrador del sistema

Usuarios conectados simultáneamente: 56 Usuarios - 9 Planilladores nocturnos - 1 Administrador = 46 Usuarios conectados simultáneamente


77

10. Desarrollo de la especificación de los requerimientos del software 10.1. Conjunto de casos de uso En la tabla 26 se encuentra la documentación del conjunto de casos de uso. (Para mayor información acerca de este formato ver explicación en el capítulo 8).

Tabla 26. Conjunto de casos de uso

CONJUNTO DE CASOS DE USO Proyecto: Software que integre los procesos operativos del distribuidor CGC de Comcel. Versión: 1

Casos de uso por área funcional No _ Coordinación administrativa _ Prioridad 14 Generar informe de inventarios de baja rotación 5 15 Generar informe de planes vendidos 10 16 Generar Kardex de CGC 10 24 Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas 5 7 Consultar el reporte de cartera 3 3 Cambiar precios de venta en el sistema 10

20 Ingresar inventario 10 _Activaciones

23 Pre ingresar los datos de la venta en el sistema 10 2 Asignar y activar el equipo en el sistema 10

10 Consultar información de activaciones 5 8 Consultar facturas 7

_ Coordinación de CPS 21 Ingresar solicitud de equipos o de Sim Card 5 6 Consultar disponibilidad de inventario 10

17 Generar Kardex de CPS 10 _ Servicio al cliente

6 Consultar disponibilidad de inventario 10 _ Caja y Bodegas

5 Cierres de caja diarios 10 18 Generar recibo de caja 10 19 Generar Factura 10 13 Generar factura para recarga 10

Casos de uso de inversionista No _ Directivas de CGC _ Prioridad 14 Generar informe de inventarios de baja rotación 5 15 Generar informe de planes vendidos 10 2 Asignar y activar el equipo en el sistema 10 3 Cambiar precios de venta en el sistema 10 6 Consultar disponibilidad de inventario 10 5 Cierres de caja diarios 10

16 Generar Kardex de CGC 10 18 Generar recibo de caja 10 19 Generar factura 10 13 Generar factura para recarga 10

Casos de uso por prioridad No _ Esenciales _ Prioridad 9 Consultar indicadores del comportamiento del software 5

11 Crear usuarios 10

78

CONJUNTO DE CASOS DE USO Proyecto: Software que integre los procesos operativos del distribuidor CGC de Comcel. Versión: 1 12 Editar el perfil de un usuario 10 4 Cerrar sesión 10

22 Iniciar sesión 10 _ Esperados

25 Recordar cambio de clave por seguridad 10 1 Acceso denegado 10

_ Deseados - No hay casos de uso deseados

_ Opcionales - No hay casos de uso opcionales

Casos de uso por actores No _ Coordinador administrativo = Coordinación administrativa _ Prioridad

_ Líder de activaciones = Activaciones 23 Pre ingresar los datos de la venta en el sistema 10 2 Asignar y activar el equipo en el sistema 10

_ Planillador = Activaciones 10 Consultar información de activaciones 5 8 Consultar facturas 7

_ Coordinación de CPS = Coordinador de CPS 26 Transferencia de mercancía de un CPS a otro 10

_ Líder de servicio al cliente = Servicio al cliente _ Líder o auxiliar de Caja y Bodegas = Caja y Bodegas

_ Administrador del software 9 Consultar indicadores del comportamiento del software 5

11 Crear usuarios 10 12 Editar el perfil de un usuario 10 4 Cerrar sesión 10

22 Iniciar sesión 10 25 Recordar cambio de clave por seguridad 10 1 Acceso denegado 10


10.2. Casos de uso En esta sección se exponen los casos de uso diagramados y documentados. Estos casos de uso se encuentran en el Anexo 31 y la guía para leer el cuadro de documentación de cada caso de uso se encuentra en el Anexo 30. El documento de los requerimientos de usuario es la base de la lista de casos de uso, y esta lista garantiza que no se va a dejar ningún caso de uso por fuera del análisis. En su mayoría, cada caso de uso interactúa en algún proceso de los propuestos. Esta es la razón por la cual fue tan rigurosa la diagramación y caracterización de los procesos (Actuales y propuestos). Por ejemplo, las caracterizaciones brindan un mejor entendimiento de las actividades, y estas a su vez apuntan hacia los flujos normales o alternativos de cada caso de uso.

79

El gráfico 10 representa las relaciones que existen entre todos los casos de uso. Este diagrama muestra como unos casos de uso tiene relaciones de extensión o inclusión (uso). Extensión es cuando un caso de uso añade comportamiento incremental al caso de uso base insertando secuencias de acción adicionales. Inclusión o uso denota la inclusión de la secuencia de comportamiento del caso de uso proveedor en la secuencia de interacción de un caso de uso cliente.

Gráfico 10. Relación de los casos de uso


80

10.3. Casos de uso por prioridad

En la tabla 27 se pueden apreciar los casos de uso ordenados según la prioridad que se le asoció. Esta prioridad se discutió con las directivas de CGC y con los ingenieros de sistemas que van a liderar el proceso de diseño e implementación del sistema de información final. En la última fila de la tabla se encuentra el único caso de uso que tiene prioridad menor que 5. Este caso de uso y su requerimiento funcional no se van a tomar en cuenta en el desarrollo del software ya que, por ahora, el proceso “Contabilidad” no se va a integrar con este software. De cualquier forma se dejará como recomendación diseñar un modulo que integre el proceso “Contabilidad”, ya que sería de gran utilidad para el proceso “Compras de equipos y Sim Card”. Por ahora, las actividades que apoya este caso de uso se pueden llevar a cabo a través de Comcel ya que el estado de cartera está disponible diariamente en Poliedro. El diseñador de software debe seguir el orden de esta tabla para diseñar las funcionalidades del software. Debe atacar primero las funcionalidades resultantes de los casos de uso con mayor prioridad y luego las de menor prioridad. Cabe aclarar que en cada nivel de prioridad (Ej. 10) el diseñador puede atacar las funcionalidades en el orden que quiera.

Tabla 27. Casos de uso por prioridad No Caso de uso Prioridad

1 Acceso denegado 10

2 Asignar y activar el equipo en el sistema 10

3 Cambiar precios de venta en el sistema 10

4 Cerrar sesión 10

5 Cierres de caja diarios 10

6 Consultar disponibilidad de inventario 10

11 Crear usuarios 10

12 Editar el perfil de un usuario 10

13 Generar factura para recarga 10

15 Generar informe de planes vendidos 10

16 Generar Kardex de CGC 10

17 Generar Kardex de CPS 10

18 Generar recibo de caja 10

19 Generar factura 10

20 Ingresar inventario 10

22 Iniciar sesión 10

23 Pre ingresar los datos de la venta en el sistema 10

25 Recordar cambio de clave por seguridad 10

26 Transferencia de mercancía de un CPS a otro 10

8 Consultar facturas 7

9 Consultar indicadores del comportamiento del software 5

81

No Caso de uso Prioridad

10 Consultar información de activaciones 5

14 Generar informe de inventarios de baja rotación 5

21 Ingresar solicitud de equipos o de Sim Card 5

24 Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas 5

7 Consultar el reporte de cartera 3


10.4. Requerimientos funcionales En algunos requerimientos funcionales se van a mostrar unas listas (Gráficos 11 al 27), las cuales son un boceto de las “clases” de estos requerimientos. Estas “clases” están basadas en los formatos usados actualmente en CGC (Ej. Formato para hacer pedidos de equipos). Las clases son producto de cada caso de uso asociado a un requerimiento funcional. Es importante hacer claridad que estas no son las clases definitivas ya que para determinarlas se requiere de un estudio mucho más profundo el cual apunta hacia un diagrama de clases, el cual se sale del alcance del proyecto. La intención que se tiene al mostrar estas “clases” es brindarle al desarrollador del software información para implementar las herramientas propuestas en la vista estática de UML (Diagrama de clases).

10.4.1. Requerimientos funcionales con Prioridad 10 Requerimiento funcional resultante del caso de uso 1: Acceso denegado Los permisos otorgados a los usuarios del software varían según el área y el cargo que desempeñan, por lo tanto, el software debe restringir las transacciones que no sean necesarias para desempeñar los cargos. En el momento que un usuario quiera ingresar a una transacción para la cual no tiene permiso, el software le debe hacerle saber al usuario que no tiene permiso para ingresar a esa transacción. Requerimiento funcional resultante del caso de uso 2: Asignar y activar equipo en el software El líder de activaciones debe tener permiso para asignar equipos y activarlos en el sistema. El software le debe permitir discriminar si es una venta o una reposición, ya que el tratamiento es diferente. A continuación se muestran los datos que se ingresan según el caso:

Gráfico 11. Listas caso de uso 2


82

Por otro lado, en caso de que no haya inventario disponible para la venta el software debe remitir al usuario a la funcionalidad “Consultar inventario disponible” con el fin consultar si hay inventario en otro CPS. En caso de que si haya, el software debe remitir al usuario a la funcionalidad “Transferencia de mercancía de un CPS a otro” para transferir la mercancía que necesite. Cuando el usuario termine de transferir la mercancía, el software lo debe remitir a la funcionalidad “Asignar y activar equipo en el software” para terminar de ingresar la información, según sea el caso. Requerimiento funcional resultante del caso de uso 3: Cambiar precios de venta en el software El usuario del coordinador administrativo debe estar habilitado para actualizar y generar nuevos precios de venta con las respectivas características del producto. A continuación se muestran los datos que debe permitirle cambiar, crear y consultar:

Gráfico 12. Lista caso de uso 3


Requerimiento funcional resultante del caso de uso 4: Cerrar sesión El software debe permitirle al cualquier usuario cerrar la sesión que inició. En el momento que el usuario decida de cerrar la sesión el software debe verificar que el usuario se encuentre en la ventana de menú principal, sino, debe preguntarle si quiere guardar los cambios realizados en la ventana actual (si es que está llevando a cabo una transacción). Luego de guardar los cambios el software debe cerrar la sesión automáticamente. Requerimiento funcional resultante del caso de uso 5: Cierres de caja diarios Los usuarios de los lideres y auxiliares de caja y bodega deben tener la opción de hacer el cierre de caja diario. Este cierre debe contener todos los movimientos del día, de forma que tiene que proporcionarle un resumen de todas las facturas generadas. La información de las facturas es la siguiente:



83

Requerimiento funcional resultante del caso de uso 6: Consultar disponibilidad de inventario El software debe permitirle al usuario consultar la disponibilidad de inventario, tanto en su CPS como en los demás. La información que se debe consultar es la siguiente.



Requerimiento funcional resultante del caso de uso 11: Crear usuarios El usuario del administrador del sistema debe tener la opción de crear nuevos usuarios cuando sea necesario. El software le debe permitir elegir los permisos del usuario, así como su clave inicial y su ID en el sistema. Requerimiento funcional resultante del caso de uso 12: Editar el perfil de un usuario El usuario del administrador del sistema debe tener la opción de editar los perfiles de los usuarios ya creados, o agregar y quitar los permisos a cualquier usuario. Esta funcionalidad le debe permitir visualizar los perfiles de los usuarios ya creados y a partir de ahí editarlos de la manera que quiera, incluso borrar el usuario o bloquearlo momentáneamente. Requerimiento funcional resultante del caso de uso 13: Generar factura para recarga Los usuarios de los lideres y auxiliares de caja y bodega deben tener la opción de generar las facturas por concepto de las recargas vendidas a los usuarios. Esta opción está separada de la opción de “Generar factura” ya que esta opción es para las facturas de las ventas diferentes a las recargas. La información que debe poder ingresar el usuario, exceptuando número de factura, es la siguiente:



84

Requerimiento funcional resultante del caso de uso 15: Generar informe de planes vendidos El usuario del coordinador administrativo debe tener la opción de generar un informe de planes vendidos con la siguiente información:



Requerimiento funcional resultante del caso de uso 16: Generar Kardex de CGC El usuario del coordinador administrativo debe tener la opción de generar el Kardex de CGC con la siguiente información:



Requerimiento funcional resultante del caso de uso 17: Generar Kardex de CPS Los usuarios de los coordinadores de CPS deben tener la opción de generar el Kardex de su respectivo CPS con la siguiente información:



Requerimiento funcional resultante del caso de uso 18: Generar recibo de caja Los usuarios de los lideres y auxiliares de caja y bodega deben tener la opción de generar recibos de caja luego de el pre ingreso de la información de ventas por parte del líder de activaciones. Este

85

recibo de caja le garantiza al líder de activaciones que ya se recaudo el valor de la venta. El recibo de caja debe tener la siguiente información.


Recibo de caja de venta o reposición

Fecha de la venta o de la repo Nombre del cliente Apellido del cliente Cedula del cliente Valor de la venta o reposición Número de factura


Requerimiento funcional resultante del caso de uso 19: Generar factura Los usuarios de los lideres y auxiliares de caja y bodega deben tener la opción de generar las facturas una vez el activador haya asignado y activado el producto en el sistema. Cuando es reposición no hay necesidad de confirmar data crédito y por ende tampoco de hacer pre ingresos de los datos de la reposición porque la información del cliente ya está en el sistema o en su defecto en Poliedro. De manera que en este caso el sistema debe permitirle al usuario la generación de la factura sin un recibo de caja previo ni pre ingreso de los datos por parte de líder de activaciones. La siguiente es la información que debe aparecer en la factura para el cliente:



Requerimiento funcional resultante del caso de uso 20: Ingresar inventario El usuario del coordinador administrativo debe tener la opción de “ingreso de inventario” nuevo para alimentar los inventarios que manejará el sistema. Como se dijo en el TBD (to be defined) del caso de uso # 20, las directivas todavía no saben si darle este permiso también a los lideres y auxiliares de caja y bodega para que ellos ingresen el inventario de referencias antiguas y que el coordinador administrativo solo ingrese una referencia de los nuevos productos. Esto garantizará que los lideres y auxiliares de caja y bodega no comentan errores al ingresar nuevas referencias y por otra parte se puede disminuir la carga laboral del coordinador administrativo ya que es bastante pesada.

86

La información que debe ingresar el usuario es la misma de “disponibilidad de inventario” (ver del requerimiento funcional resultante del caso de uso 6) Requerimiento funcional resultante del caso de uso 22: Iniciar sesión Todos los usuarios del sistema tiene que tener la opción de iniciar sesión para poder llevar a cabo cualquier transacción para la cual este autorizado el usuario de los mismo. Requerimiento funcional resultante del caso de uso 23: Pre ingresar los datos de la venta en el sistema El sistema debe permitirle al usuario del líder de activaciones hacer el pre ingreso de los datos de la venta o la reposición. Estos datos son los diferentes según el caso y se pueden apreciar a continuación:



Requerimiento funcional resultante del caso de uso 25: Recordar cambio de clave por seguridad Por razones de seguridad, el sistema le debe recordar a todos los usuarios cambiar su clave mensualmente. El cambio de clave es opcional, si el usuario no quiere cambiar la clave es responsabilidad del mismo, el sistema solo debe recordarle que la debe cambiar. Requerimiento funcional resultante del caso de uso 26: Transferencia de mercancía de un CPS a otro Los usuarios de los coordinadores de CPS deben tener la opción de transferir mercancía o inventario de un CPS a otro. No olvidar que este requerimiento funcional también es una extensión del requerimiento funcional “Asignar y activar el equipo en el sistema” así que los usuarios también se comparten. La información que debe ser ingresada y procesada para transferir mercancía de un CPS a otro es la misma de “disponibilidad de inventario” (ver del requerimiento funcional resultante del caso de uso 6). El único atributo editable en esta información sería “CPS”.

87

10.4.2. Requerimientos funcionales con prioridad 7 Requerimiento funcional resultante del caso de uso 8: Consultar facturas El usuario del planillador debe tener la opción de consultar las facturas generadas en la funcionalidad “Generar factura”. La información que debe mostrarle el sistema al planillador es:



10.4.3. Requerimientos funcionales con prioridad 5 Requerimiento funcional resultante del caso de uso 9: Consultar indicadores del comportamiento del software El usuario del administrador del sistema debe tener la opción de consultar los indicadores del comportamiento del software tales como flujo de usuarios, usuarios en línea, velocidad de respuesta de las transacciones, etc. Requerimiento funcional resultante del caso de uso 10: Consultar información de activaciones El usuario del planillador debe tener la opción de consultar la información generada en la funcionalidad “asignar y activar el equipo en el sistema”. La información que debe mostrarle el sistema al planillador es:



Requerimiento funcional resultante del caso de uso 14: Generar informe de inventarios de baja rotación El usuario del coordinador administrativo debe tener la opción de generar los informes de inventarios de baja rotación para la gerencia de CGC.

88

La información que debe contener este informe es la siguiente:



Requerimiento funcional resultante del caso de uso 21: Ingresar solicitud de equipos o de Sim Card El usuario de los coordinadores de CPS debe tener la opción de ingresar las solicitudes de equipos o de Sim Card para que luego sean consolidadas en la funcionalidad “Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas”. La información que deben ingresar los coordinadores de CPS es la siguiente:



Requerimiento funcional resultante del caso de uso 24: Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas El usuario del coordinador administrativo debe tener la opción de recibir las solicitudes de equipos y Sim Card de todos los CPS consolidadas. La información que debe mostrar el sistema debe ser la siguiente:



89

10.4.4. Requerimientos funcionales con prioridad 3 Requerimiento funcional resultante del caso de uso 7: Consultar el reporte de cartera El usuario del coordinador administrativo debe tener la opción de consultar el reporte de cartera para tomar la decisión de comprar o no comprar Kit Pre-pago y Sim Card. La información que debe mostrar el sistema es la siguiente:



Finalmente, luego de analizar los procesos actuales y propuestos, luego de haber levantado una gran cantidad de información (documento de requerimientos de usuario, entrevistas, etc) luego de haber construido la lista de casos de uso y por último haberlos diagramado y documentado, el producto final de esta cadena se llama “requerimientos funcionales”. No es un proceso sencillo, pero es necesario. Muchos expertos dicen, que un levantamiento mediocre de los requerimientos funcionales puede ocasionar grandes aumentos en los costos del desarrollo. Es importante hacer énfasis en que gran parte de este trabajo de grado está en función de los requerimientos funcionales, cuidando así los costos del desarrollo. La mayoría de los casos de uso interactúa en un proceso propuesto, lo cual quiere decir que también se está cuidando el aspecto de la integración de los procesos a través de los requerimientos funcionales. Por último, no sobra recordar que los requerimientos evolucionan a través del RUP, y no solo evolucionan sino que en algunos casos también se crean más requerimientos, incluso justo antes de la implementación.

90

11. Evaluación económica

11.1. Plan de trabajo para el desarrollo del software Antes de llevar a cabo la evaluación económica del proyecto, es importante describir la metodología que se llevará a cabo para el desarrollo de sistema. Esta explicación es necesaria ya que en base a esta metodología se trazará un cronograma de las fases de la misma y el tiempo que se demore cada una de ellas determinará el costo del desarrollo del software in house. 11.1.1. RUP6 El IBM RUP (rational unified process) es un proceso o sistema de desarrollo prescriptivo y bien definido, usualmente usado para desarrollar sistemas orientados a objetos y/o tecnologías basadas en componentes. Está basado en principios de ingeniería de software como iteratividad, requerimientos y desarrollo del software orientado a la arquitectura. Este proceso provee varios mecanismos tales como iteraciones de corto plazo con hitos bien definidos y puntos de decisión al final de cada fase con el fin de proveer visibilidad gerencial dentro del proceso de desarrollo. El gráfico 28 se muestra el ciclo de vida del RUP, comúnmente llamado el diagrama “hump chart” (tabla de joroba). Las jorobas horizontales para cada disciplina muestran a grandes rasgos lo que sería la distribución de esfuerzo en cada fase. Este gráfico es un mecanismo visual que aclara que tanto se utiliza una disciplina en cada fase:

Gráfico 28. Hump chart / Tabla del joroba

Fuente:http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.html Las características del ciclo de vida del RUP son las siguientes: 6 The rational unified process an introduction, 2nd ed. Kuchten Philippe

91

• Por etapas en lo macro. • Iterativo en lo micro. • Establece hitos claros e incrementales a través del tiempo. • Soportado por las mejores prácticas probadas.

11.1.1.1. Por etapas en lo macro El RUP está estructurado en dos dimensiones: fases, las cuales representan los cuatro estados más grandes por los cuales tiene que atravesar un proyecto a través del tiempo, y disciplinas, que representan las actividades lógicas que son protagonistas a través del proyecto. El aspecto por etapas del RUP se refleja en las fases y el aspecto iterativo en las disciplinas. Cada fase termina con un hito bien definido y tiene un set específico de objetivos, los cuales se abordan dentro de las iteraciones de la fase, de esta manera los hitos de las fases pueden ser alcanzados. Las fases constituyen el factor adherente que mantiene al RUP junto y las disciplinas representan el corazón del RUP. Las fases son las siguientes:

Tabla 28. Fases del RUP

Fase Explicación Inicial Las principales metas de la fase inicial son llegar a un acuerdo con los inversionistas

(stakeholders/directivas de CGC) acerca de los objetivos del proyecto y obtener fondos para el mismo. Para hacer esto es necesario hacer un modelo de requerimientos de alto nivel que delimitarán el alcance el proyecto, y, potencialmente, iniciar el desarrollo de un prototipo de interfaz de usuario (UI user inteface). Se empezará a instalar el entorno de trabajo y a adaptar el proceso para el equipo de trabajo. También se desarrollará un plan de alto nivel respecto a cómo se llevará a cabo el proyecto. El producto de esta fase son los objetivos del ciclo de vida.

Elaboración Durante la fase de elaboración se especifican los requerimientos detalladamente y se valida la arquitectura para el sistema. Los requerimientos son detallados para entender los riesgos de la arquitectura y para asegurar que hay un entendimiento del alcance de cada requerimiento para su posterior planeación. Al final de esta fase se debe tener la arquitectura del ciclo de vida.

Construcción El enfoque de la fase de construcción es desarrollar el sistema hasta el punto en que esté listo para la implementación. El énfasis ahora se concentra en priorizar los requerimientos, completar sus especificaciones, analizarlas, diseñar una solución para satisfacerlas, escribir el código y probar el software. Si es necesario, las primeras versiones de sistema se implementan, ya sea internamente o externamente, para obtener retroalimentación de los usuarios. Al final de esta fase es necesario hacer una revisión de la capacidad operacional inicial.

Transición La fase de transición se enfoca en entregar el sistema en el negocio. Será puesto a prueba por los usuarios finales así como también se harán los re procesos correspondientes y los afinamientos finales. Para este punto el entrenamiento de los usuarios finales, el staff de soporte y de operaciones debe estar hecho. En el final de esta fase se debe tener listo el lanzamiento del producto.

Fuente: A managers introduction to the rational unified process (RUP). Scott W. Ambler. Dec 4 2005

El porcentaje del tiempo total del desarrollo que tarda cada fase es:

Tabla 29. Porcentaje del tiempo total

Fase Porcentaje Inicial 10% Elaboración 25% Construcción 55% Transición 10%

Fuente: Fuente: A managers introduction to the rational unified process (RUP). Scott W. Ambler. Dec 4 2005

92

11.1.1.2. Iterativo en lo micro Las fases del RUP esta dividas en iteraciones. Cada iteración abarca una pequeña parte del sistema que se está desarrollando (A diferencia del método de cascada que intenta hacerlo todo de una sola vez). Cada iteración tiene un plan específico con un objetivo claro. Cada iteración se basa en el trabajo hecho en la anterior de forma que ensambla incrementalmente el sistema final. Cada vez que una iteración termina (particularmente en la fase de construcción) quiere decir que un sub sistema ha sido terminado. Las nueve disciplinas del RUP son:

Tabla 30. Disciplinas del RUP Disciplina Explicación De modelación del negocio

La meta es entender el negocio de la organización, generalmente este “negocio” no es más que el ámbito de la empresa que es relevante para el desarrollo. Muchas veces no basta con entender el negocio si no que hay que hacer reingeniería en sus procesos antes de pensar en diseñar una solución informática para el mismo. La razón es que si se diseña una solución sobre un proceso que se lleva a cabo ineficientemente e ineficazmente, por lo general, el esfuerzo va a ser en vano ya que tarde o temprano los procesos se modificarán.

De los requerimientos

La meta es levantar, documentar y llegar a un acuerdo sobre el alcance de los que se va y lo que no se va a construir. Esta información es usada por analistas, diseñadores y programadores para construir el sistema, por probadores para verificar el sistema y por el líder del proyecto para planear y gerencia el proyecto.

Del análisis y el diseño

La meta es analizar los requerimientos del sistema, diseñar una solución para que sea implementada y hallar todas las limitaciones y todas las normas y directrices aplicables.

Del desarrollo La meta es transformar el diseño en un código ejecutable y realizar una prueba de nivel básico. De la prueba La meta es realizar una evaluación objetiva para asegurar la calidad del sistema. Esto incluye,

encontrar los defectos, validar que el sistema responde al diseño y verificar que los requerimientos fueron satisfechos.

De la implementación

La meta es planear la entrega del sistema y ejecutar el plan para habilitar el sistema a los usuarios finales.

De la configuración y el manejo del cambio.

La meta es manejar el acceso a los productos del proyecto. Esto no solo incluye hacerle seguimiento a las versiones del sistema sobre el tiempo, sino que también incluye controlar y manejar los cambios en las mismas.

De la gerencia del proyecto

La meta es dirigir las actividades que toman lugar en el proyecto. Esto incluye, manejar los riesgos, dirigir la gente (asignar tareas, seguimiento de los progresos, etc.) y coordinar que el sistema se entrega a tiempo y usando el presupuesto asignado.

Del ambiente La meta es soportar el resto del esfuerzo asegurando que la guía (estándares y lineamientos) y herramientas (hardware, software, etc.) están disponibles para el equipo en la medida de lo necesario.

Fuente: A managers introduction to the rational unified process (RUP). Scott W. Ambler. Dec 4 2005

11.1.1.3. Establece hitos claros e incrementales a través del tiempo Todas las versiones del sistema evolucionan a través del tiempo. Nuevas funcionalidades son agregadas, mejoras pedidas por los usuarios también son agregadas, nuevos estándares son adoptados, etc.

11.1.1.4 Soportado por las mejores prácticas probadas Existen muchas prácticas que soportan este método. En octubre del 2005 IBM anunció una lista revisada de las mejores prácticas para el RUP. Estas prácticas son:

1. Adaptar el proceso

93

2. Balancear las prioridades de las partes interesadas (stakeholders) 3. Colaboración entre los equipos 4. Demostrar valor iterativamente 5. Elevar el nivel de abstracción 6. Enfocarse continuamente en la calidad.

11.1.2. Enfoque y preguntas clave para cada fase según IBM7 El RUP fue diseñado por IBM, razón por la cual es importante tomar en cuenta el enfoque que ellos proponen para cada una de las fases. La tabla 30 nombra los enfoques de cada fase y las preguntas claves que se deben hacer los integrantes del equipo de desarrollo durante todo el RUP.

Tabla 31. Preguntas claves y enfoque de cada fase según IBM Fase Inicial De elaboración De construcción De transición

Pregunta clave ¿Deberíamos construirlo? ¿Podemos construirlo? ¿Estamos construyéndolo? ¿Ya lo construimos?Enfoque Alcance Riesgo Funcionalidad Entrega

Fuente: http://www.ibm.com/developerworks/rational/library/1826.html; 1/10/09

11.1.3. Estimación del tiempo para el desarrollo del software De acuerdo a la metodología explicada en el numeral 11.1.1. RUP y en la tabla 31. se estimó la cantidad de tiempo que puede tomar cada una de las fases en el desarrollo del software. Según el RUP cada fase tiene un porcentaje aproximado de tiempo para llevarse a cabo. Basado en esto se le preguntó a los ingenieros jefe y desarrollador el tiempo estimado para desarrollar el software completo, a lo que respondieron 8 meses. Con base en estos 8 meses y a los porcentajes del RUP se acordó un número de semanas por fase. Los hitos representan los elementos cruciales para cada fase del desarrollo del software. Tanto lo hitos, como el tiempo que toma cada fase y su respectivo porcentaje sobre el total del tiempo se muestran en la tabla 32.

Tabla 32. Estimación del tiempo para el desarrollo Fase Semanas

Fase inicial (RUP = 10 % del tiempo total)

4 semanas (11,7% del tiempo total)

Hito Fecha de terminación Requerimientos del producto desde la perspectiva del usuario Viernes 6 de noviembre de 2009

Principales casos de uso Viernes 13 de noviembre de 2009 Refinamiento del Plan de desarrollo del proyecto Viernes 20 de noviembre de 2009

Determinación y asociación de los riesgos a los casos de uso. Viernes 27 de noviembre de 2009

Fase Semanas Fase de elaboración

(RUP = 25 % del tiempo total) 7 Semanas

(20,5% del tiempo total) Hito Fecha de terminación

Análisis de los requerimientos Viernes 4 de diciembre de 2009 Desarrollo de un prototipo de arquitectura (incluyendo las partes más relevantes y/o críticas del sistema) Al final de esta fase, todos

Viernes 8 de enero de 2010

7 http://www.ibm.com/developerworks/rational/library/1826.html; 1/10/09

94

los casos de uso correspondientes a requisitos que serán implementados en el primer prototipo (1.0) de la fase de construcción deben estar analizados y diseñados. La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase. También se analizarán y aprobarán los riesgos levantados en la fase inicial y si es necesario se agregarán más. Cada riesgo debe tener una forma de manejarlo o mitigarlo.

Viernes 15 de enero de 2010

Fase Semanas Fase de construcción


(50% del tiempo total) Hito Fecha de terminación

Terminan de analizar y diseñar todos los casos de uso Viernes 5 de febrero de 2010

El producto se construye en base a varias iteraciones, cada una produciendo un prototipo al cual se le aplican las pruebas y se valida con el cliente/usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión final del sistema (Prototipo n,0 /: donde n depende el numero de iteraciones).

Viernes 14 de mayo de 2010

Fase Semanas Fase de transición


(17,6% del tiempo total) Hito Fecha de terminación

En esta fase se prepara la implementación final, asegurando un cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios.

Viernes 28 de mayo de 2010

El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario y la finalización del entrenamiento de los usuarios.

Miércoles 30 de junio de 2010

Tiempo total 8 Meses


Este trabajo de grado proporciona los requerimientos funcionales basados en los casos de uso especificados, diagramados y priorizados (Aunque ya se sabe que estos requerimientos y casos de uso se reevalúan a lo largo del RUP) para la fase inicial y la fase de elaboración. Por otro lado, para la fase inicial, la modelación del negocio está completa (Análisis de los procesos y posibles sistemas de información). Esta es la razón por la cual el tiempo es más que suficiente y el cronograma simplemente marca el inicio y el final del desarrollo. En conclusión, es posible que les sobre tiempo a los ingenieros en las primeras dos fases, tiempo que pueden utilizar en las dos últimas fases. Este proyecto será iniciado el lunes 2 de noviembre del 2009 y por lo tanto será finalizado el miércoles 30 de Junio del 2010, 8 meses después de su inicio. 11.2 Evaluación económica La evaluación económica tiene como objetivo determinar la viabilidad del proyecto midiendo si genera o no valor, lo cual se realiza a través de los criterios universales existentes; Valor presente neto (VPN), tasa interna de retorno (TIR), relación costo beneficios. Su empleo requiere de dos

95

elementos: Los flujos de caja proyectados de la inversión y la tasa de interés que se utiliza para descontarlos, es decir, para traerlos al periodo inicial o cero. Para realizar la proyección de los flujos de caja debe integrarse la información recopilada en el análisis estratégico, la investigación de mercados, el tamaño y la localización del proyecto, la ingeniería del proyecto y las inversiones. El único sistema que permite esta consolidación de información es la construcción de los estados financieros que proporcionan los registros contables de periodos pasados, que para este caso serían los esperados o proyectados. El otro elemento que se requiere para la evaluación es la tasa de interés de descuento.8 Para este caso los costos y los beneficios son equivalentes a los flujos del proyecto y la tasa de descuento que se tomará será del 4,1% mes vencido, tasa proporcionada por el departamento de contabilidad de acuerdo a la utilidad neta/ventas actuales. Los beneficios del proyecto serán la reducción de pérdidas proyectada correspondiente al costo financiero y al aumento en la utilidad neta. Estos beneficios se proyectarán de acuerdo a los datos proporcionados por el estado de resultados de 2008. Estos valores se generarán con el valor futuro equivalente al periodo del año 2010 o 2011. 11.2.1. Costo del desarrollo del software La tabla 33 contiene los costos del desarrollo del software. Estos costos se explicarán uno a uno en las siguientes dos secciones.

Tabla 33. Costos del desarrollo

Concepto Costo Uso del lenguaje PHP $ 0- Servidor Apache $ 0- Motor de base de datos Postgres $ 0- 2 computadores para los ingenieros de programación $ 960.000 Ingeniero jefe de proyecto (Salario 8 meses) $ 36.000.000 Ingeniero desarrollador (Salario 8 meses) $ 9.600.000 Trabajo diseñador industrial $1.500.000 Carga prestacional por los 2 ingenieros $ 23.256.000 2 Cubículos $ 16.000.000 Tiempo de usuarios en pruebas (usuarios del software en calle 13) $ 2.550.000 Carga prestacional de las pruebas (usuarios del software en calle 13) $ 1.300.500 Total $ 91.166.500


11.2.2. Costos iguales a cero Los costos que se explican en esta sección no representan una carga económica para el proyecto ya que sus licencias o permisos son gratuitos. Luego de una reunión con los 2 ingenieros de sistemas y el gerente general de CGC se llegó a las siguientes conclusiones:

8 Formulación y evaluación de proyectos de inversión. Una visión integral para empresas manufactureras y de servicios, Cengage learning, Jorge Rosillo, 2007

96

Uso del lenguaje PHP: El lenguaje tiene que ser PHP ya que es un lenguaje interpretado mas no compilado, lo cual le daría mucho más dinamismo al sistema. Lenguajes compilados como C++, Visual Basic, etc., solo corren sobre Windows, en cambio, los lenguajes interpretados como PHP corren sobre cualquier plataforma, convirtiendo el software en un software multiplataforma. Su licencia es gratuita.

Servidor Apache: Se utilizará el servidor Apache ya que su licencia es gratuita y proporciona el dinamismo que el sistema requiere.

Motor de base de datos Postgres: El motor de base de datos será Postgres ya que su licencia es gratuita, es robusto y apropiado para el sistema.

11.2.3. Costos diferentes de cero

2 Computadores: Tanto el ingeniero líder como el ingeniero desarrollador requieren computadores para llevar a cabo sus actividades. Estos computadores son de CGC por lo tanto su adquisición no tendrá ningún costo. Por otro lado, una firma de contadores es arrendataria de 3 computadores de CGC. El costo del alquiler por computador es $60.000 mensuales. Por lo tanto el costo de los dos computadores para los ocho meses será de $960.000.

Ingeniero jefe del proyecto (salario 20 meses): El salario mensual del ingeniero jefe de proyecto es de $1’800.000 (20 meses=desarrollo software 8 meses + soporte 12 meses). Es claro que este salario es bajo pero ya esta negociado con el ingeniero jefe de proyecto. Este salario multiplicado por los veinte meses del desarrollo y soporte da como resultado $36’000.000.

Ingeniero desarrollador (Salario 8 meses): El salario mensual del ingeniero desarrollador es de $1’200.000. Este salario también es bajo pero, al igual que el salario del jefe, ya esta negociado el ingeniero desarrollador. Este salario multiplicado por los ocho meses del desarrollo da como resultado $9’600.000.

Carga prestacional por los 2 ingenieros: Esta carga prestacional se calculó multiplicando el total de los salarios de los dos ingenieros para los 20 meses por el 51%. Esta carga tiene un valor de $ 23’256.000

Trabajo del diseñador industrial: El costo de diseñar las pantallas del software es de $1’500.000. Este costo se dividió entre los dos últimos meses del desarrollo.

2 Cubiculos: A los dos ingenieros del proyecto se les asignarán 2 cubículos para que tengan un espacio en donde trabajar. En este momento CGC es el arrendador de tres cubículos para la firma de contadores que comparte el local de calle 13 con CGC. Por lo tanto se tomará ese precio como costo de cada cubículo de los ingenieros. El arriendo de cada cubículo es de $1.000.000. Por lo tanto el costo de los dos cubículos de los 2 ingenieros es de $ 16’000.000.

Pruebas (usuarios del software en calle 13): Los futuros usuarios del sistema tienen que invertir tiempo para la pruebas que se van a llevar a cabo en las fases entre iteración e interacción. Como las iteraciones de las fases son incalculables antes que se termine la fase, se estima que los usuarios inviertan cada uno, como mínimo, el tiempo equivalente a 2 semanas laborales durante los ocho meses del desarrollo. Los salarios de los empleados que van a ser usuarios del sistema se muestran en la tabla 34:

Tabla 34. Costo de las pruebas Usuario Salario mensual Salario semanal Líder de caja y bodega $ 550.000 $ 137.500 Líder de activaciones $ 550.000 $ 137.500 Coordinador del CPS $ 1.100.000 $ 275.000 Coordinador administrativo $ 1.800.000 $ 450.000 Planillador $ 550.000 $ 137.500 Líder de servicio $ 550.000 $ 137.500

Total para 2 semanas $ 2.550.000

97

Fuente: Autor del presente trabajo De los usuarios que se definieron anteriormente no se tomaron en cuenta los siguientes:

Auxiliar de caja y bodega: Tiene las mismas funciones del líder de caja y bodega Administrador del sistema: Las pruebas del administrador las llevaran a cabo los ingenieros a

cargo del proyecto. Con base en esto, el costo total (sin carga prestacional) de las pruebas es de $ 2.550.000. Esta cifra se dividirá en partes iguales durante los ocho meses ya que en el RUP se ejecutan pruebas contantemente con el fin de mejorar el desarrollo del software.

Carga prestacional de las pruebas: Esta carga prestacional se halló igual que la de los dos ingenieros con la diferencia que se halló sobre el total de las pruebas. Esta carga tiene un valor de $ 1.300.500.

En resumen, el desarrollo del software tendrá un costo de $ 91.166.500.

98

11.2.4. Distribución del costo en el tiempo La tabla 35 muestra la distribución del costo en el tiempo:

Tabla 35. Distribución del costo

nov-

09

dic-

09

ene-

10

feb-

10

mar

-10

abr-

10

may

-10

jun-

10

Jul-1

0

Ago

-10

Sept

-10

Oct

-10

Nov

-10

Dic

-10

Ene-

11

Feb-

11

Mar

-11

Abr

-11

May

-11

Jun-

11

Salarios de los ingenieros

3.000.000

3.000.000

3.000.000

3.000.000

3.000.000

3.000.000

3.000.000

3.000.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

1.800.000

Carga prestacional (ing)

1.530.000

1.530.000

1.530.000

1.530.000

1.530.000

1.530.000

1.530.000

1.530.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

918.000

Cubículos

2.000.000

2.000.000

2.000.000

2.000.000

2.000.000

2.000.000

2.000.000

2.000.000

Trabajo diseñador industrial - - - - - -

750.000

750.000

Computadores

120.000

120.000

120.000

120.000

120.000

120.000

120.000

120.000

Pruebas 318.750

318.750

318.750

318.750

318.750

318.750

318.750

318.750

Carga prestacional (pruebas)

162.563

162.563

162.563

162.563

162.563

162.563

162.563

162.563

Total 7.131.313

7.131.313

7.131.313

7.131.313

7.131.313

7.131.313

7.881.313

7.881.313

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000

2.718.000


El valor presente neto del costo a noviembre del 2009 es igual a:

7.131.3137.131.313

1,0417.131.313

1,0417.131.313

1,0417.131.313

1,0417.131.313

1,0417.881.313

1,0417.881.313

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,0412.178.000

1,041$70.074.806

99

11.2.5. Beneficios del desarrollo del software En el anexo 32 se puede apreciar el estado de resultados del 2008 donde se pueden ver en rojo 3 filas. Estas filas corresponden a los costos causados por el mal manejo de inventarios, las multas generadas por Comcel y el costo financiero de los préstamos necesarios para subsanar el error de la subvaloración del costo de inventarios. Para efectos del cálculo del beneficio únicamente se va a tomar la “no causación” del costo financiero. El costo generado por la subvaloración de inventarios no será un beneficio (Dado el caso que no se siga incurriendo en el mismo) ya que el dinero que CGC repartió entre los socios por las utilidades ficticias no se perdió, el costo se generó cuando las directivas de CGC se dieron cuenta que esta repartición de las utilidades ficticias había ocasionado iliquidez en la empresa. En aras mejorar la liquidez de la compañía, se pidieron préstamos a los bancos. Estos préstamos llevan consigo intereses que para efectos prácticos son el costo real del error de haber repartido esas utilidades ficticias. El hecho de no incurrir en este costo financiero, lo convierte automáticamente en un beneficio. Otra de las filas subrayadas en el estado de resultados es el costo causado por las multas impuestas por Comcel debido a los errores por parte del distribuidor. Algunos de estos errores son:

Equipos CAD – Vencidos: Los distribuidores tienen un plazo de 60 días para vender los equipos en consignación. Equipos en consignación son aquellos equipos que se adquieren para ventas post-pago, es decir, estos equipos no son de CGC, son de Comcel, y una vez vendidos Comcel otorga la comisión correspondiente.

Trafico de KITS: Cada vez que se vende un kit pre-pago CGC tiene que demostrar que este equipo tiene tráfico entrante y saliente de llamadas a través de Comcel. Si un cliente se cambia a otro operador antes de cumplir un año de haber comprado el plan, CGC tiene que pagar ese equipo a full precio.

No entrega oportuna: Existe una penalización por no entregar los contratos después de 48 horas de haber sido activado el equipo. Después de las 48 horas de activado empieza a correr una multa de $ 4000 por cada día que se pase cada contrato.

Corrección de errores: Si se tiene que enviar un contrato para no incurrir en la multa de las 48 horas, pero se sabe que va con algún error, hay un plazo de 48 horas más para corregirlo y si no se corrige también se penaliza.

La reversión de una activación: La cancelación de una activación tiene un costo y es considerado como una multa.

Fondos insuficientes de un cheque: Cuando un cheque enviado a Comcel no tiene fondos la sanción es del 20 % de la consignación.

Para el proyecto de grado (anexo 31), las directivas de CGC brindaron información acerca de los totales de las multas generadas por errores. El total para el 2008 era $ 93’786.101 (Cifra nombrada en el proyecto de grado (anexo 31) en el capítulo de planteamiento del problema). Luego de una reunión las mismas directivas aclararon que gran parte de esas multas son simbólicas. Esto quiere decir que muchas de esas multas son negociadas con nuevas metas para el mes en cuestión. Es tal el nivel de reducción al que se puede llegar, que en el 2008 el total de las multas fue de $ 18.129.129. Estas multas, que se vuelven efectivas, son inevitables y ni siquiera negociándolas se pueden rebajar. Esto quiere decir que son causadas por errores humanos o por fraudes por parte de los clientes. Estos errores son imposibles de mitigar con calidad de la información, es decir que el

100

desarrollo del software no podrá disminuir este rubro, por lo tanto no generará ningún beneficio sobre las multas. Esto nos deja únicamente con el costo financiero generado por los préstamos adquiridos para corregir la repartición de utilidades ficticias a causa de la subvaloración del costo de inventarios. Para efectos del cálculo del beneficio del proyecto es necesario tomar en cuenta que el software estará implementado para finales del Junio del 2010. Para la evaluación económica del proyecto, el departamento de contabilidad aportó los siguientes datos para el estudio:

• Tasa de oportunidad de CGC: 4.1% mes vencido (de acuerdo a la utilidad neta/ventas) • Por cada punto porcentual que aumenten las ventas, la utilidad neta aumenta en una 8.5%.

Para el cálculo de aumento de utilidad se va a tomar la utilidad del 2008 sin el costo causado por la subvaloración de inventarios y por ende tampoco se tomará en cuenta el costo financiero de los préstamos. La razón por la cual se va a tomar la utilidad del 2008 es porque no hay suficiente información del 2009. Cada utilidad hallada del 2008 se llevará al periodo equivalente del 2010 o del 2011 para considerar el valor del dinero en el tiempo. Los valores de las utilidades del 2008 se encuentran en el anexo 32.

Tomando en cuenta que el control de inventarios que lleva a cabo el software actual no es optimo, se puede asumir que con un software que mejore el manejo de inventarios, las ventas aumentarían. Es decir, que debido a que ya no va a haber inventarios faltantes en ningún intervalo del año, se va a poder atender la demanda total anual. Esto ocasionará un aumento en las utilidades del 2010 y el 2011. Para efectos del cálculo del beneficio se supondrá un aumento del 1% en las ventas de Julio-2010 a Junio-2011. Este 1 % no es algo imposible para CGC es más, según el gerente general, 1% es una meta baja para el distribuidor.

101

Por otro lado, para el cálculo del costo financiero que se ahorrará la compañía con la implementación del software, se tomará el costo financiero que se causo en los meses del 2008 y se llevará al periodo correspondiente. La razón por la cual se tomarán valores del costo financiero del 2008 es la misma por la cual se tomaron las utilidades del 2008. No existe suficiente información en el 2009. 11.2.6. Cálculo del beneficio El beneficio en el primer año luego de la implementación del software se distribuye de la siguiente manera

Tabla 36. Distribución del beneficio

jul-10 ago-10 sep-10 oct-10 nov-10 dic-10 ene-11 feb-11 mar-11 abr-11 may-11 jun-11Aumento en la utilidad -9.143.878 -3.576.554 15.700.417 -2.807.141 -2.719.484 2.725.622 49.431.092 31.627.284 25.706.614 26.259.239 25.065.016 27.248.484Disminución del costo financiero 20.907.943 19.908.732 19.334.628 19.629.531 10.748.249 18.784.762 43.760.077 43.112.327 49.041.142 39.394.204 37.984.927 37.745.925Total 11.764.065 16.332.178 35.035.045 16.822.390 8.028.764 21.510.384 93.191.169 74.739.611 74.747.756 65.653.443 63.049.943 64.994.409


Con la información de la tabla 36 se pueden proponer 2 escenarios Escenario 1: Únicamente con la disminución del costo financiero. El VPN del beneficio a noviembre de 2009 es de:

20.907.9431,041

19.908.7321,041

19.334.6281,041

19.629.5311,041

10.748.2491,041

18.784.7621,041

43.760.0771,041

43.112.3271,041

49.041.1421,041

39.394.2041,041

37.984.9271,041

37.745.9251,041

$ 268′391.969

Relación costo beneficio 1:

$ 268′391.969$70′074.806

,

La relación costo beneficio es mayor a uno, por lo tanto es aconsejable llevar a cabo el proyecto. Ahora veamos el 2do escenario.

102

Escenario 2: Con la disminución del costo financiero y el aumento de la utilidad. El beneficio a noviembre de 2009 es de:

11′764.0651,041

16.332.1781,041

35.035.0451,041

16.822.3901,041

8.028.7641,041

21.510.3841,041

93.191.1691,041

74.739.6111,041

74.747.7561,041

63.049.9431,041

63.049.9431,041

64.994.4091,041

$ 341′861′. 755 Gracias al aumento del 1% de las ventas, el beneficio del proyecto aumenta considerablemente Relación costo beneficio 2:

$ 341′861.755$70′074.806

, Con esta relación costo beneficio, también es recomendable llevar a cabo el proyecto. Aunque no hacía falta proponer el 2do escenario para ver la viabilidad del proyecto, si era necesario para el planteamiento que hicimos de la reducción de pérdidas. Es muy probable que los VPN de los beneficios sean altos porque se están trasladando valores del 2008 al 2010 y al 2011. Es decir que el aumento de la utilidad y la disminución de costo financiero de Jul-2010 a Dic-2010 se tienen que trasladar 24 meses, y de Ene-2011 en adelante se tienen que trasladar 36 meses. Dado el caso que se hiciera una proyección rigurosa del aumento de la utilidad y de la disminución del costo financiero haciendo uso de datos más recientes y variabilidad del mercado, el beneficio del proyecto no disminuiría tanto como para perjudicar la viabilidad del proyecto. Prueba de esto es que si se traslada el costo financiero total del 2008 (aprox. $ 100’000.000, línea de intereses del anexo 32. Estado de resultados 2008), a los periodos del 2010 o 2011 a una tasa de 4,1 % mes vencido a través de 24 o 36 meses, el valor resultante sería alto. De acuerdo a lo dicho anteriormente, la decisión sigue siendo la misma. El proyecto es favorable para CGC.

103

12. Conclusiones

Emprender un desarrollo de software propio es la mejor decisión que puede tomar CGC, ya que después de buscar una solución en el mercado, implementarla y no obtener buenos resultados, el único ente que puede garantizar un desarrollo óptimo y a la medida de un nuevo software (requerimientos, diseño e implementación) es el mismo usuario. La diagramación y caracterización de los procesos actuales de CGC aclaró la actividad de la empresa y brindó una base para la situación propuesta de los procesos susceptibles a sistematizar. Con el desarrollo de la situación propuesta de los procesos se garantiza que los requerimientos funcionales respondan a unos procesos estructurados y diseñados correctamente, de otra forma cualquier modificación futura en el diseño de éstos repercute significativamente sobre los requerimientos funcionales del software. El proceso que se siguió hasta la definición de los requerimientos funcionales fue riguroso y detallado con el fin de garantizar que en un futuro no se incrementen los costos del desarrollo del software, ya que una de las razones del aumento de los costos del desarrollo es el levantamiento deficiente de los requerimientos. Para que las cifras de reducción de pérdidas sean realidad, lo primero que tiene que hacer CGC es ajustar sus procesos a los procesos propuestos en este trabajo, de manera que los requerimientos levantados estén alineados con la construcción e implementación del software. Si no se hace uso de los procesos propuestos, de nada sirve un software que va a interactuar con procesos que no están alineados al mismo. Los procesos que resultaron susceptibles a sistematizar, son los procesos que llevados eficiente y eficazmente (de acuerdo a los procesos propuestos) garantizan la reducción de pérdidas importantes generadas por el software actual. Después de la proyección de reducción de pérdidas, se ve claramente que CGC necesita este sistema de información para evitar que se subvalore el costo del inventario nuevamente. Aunque se podría comercializar el software para cubrir la inversión, sólo con la reducción de pérdidas se generará un beneficio considerable. Por último, según el RUP (Rational unified process) el levantamiento de los requerimientos no se detiene en la fase inicial del desarrollo del software. Por lo tanto, es vital para el proyecto que los requerimientos que se levantaron en este trabajo evolucionen y si es necesario se generen más a través de todas las fases. Esto no quiere decir que los requerimientos que se levantaron estén mal definidos, simplemente se debe tener en cuenta que a medida que avanza el proyecto las condiciones de las fases cambian y por ende se tienen que reevaluar los requerimientos.

104

13. Recomendaciones Luego de que CGC implemente el software y se asegure de que funcione adecuadamente, es recomendable emprender un proyecto para su comercialización teniendo en cuenta que existen 38 clientes potenciales (distribuidores Comcel) que estarían interesados en adquirir el producto debido a que no existe una solución competitiva en el mercado. Para el registro de los movimientos económicos del desarrollo y comercialización del software se recomienda que se cree un centro de costos nuevo, equivalente a un CPS, con el ánimo de independizar los movimientos económicos del sistema con respecto a los demás movimientos del distribuidor (ventas de productos de Comcel, reposiciones, recaudos, etc.) Luego de implementar el software que integre los procesos operativos de CGC (prioridad en este momento) es pertinente desarrollar interfaces que permitan la comunicación entre el software de “Contabilidad” y “tesorería” y el software de los proceso operativos con el fin de integrar todos los demás procesos y agregarle valor al software que se desarrolle. Es recomendable retomar la fase de inicio del desarrollo del sistema con la asignación de los riesgos. Esta asignación la tienen que hacer los ingenieros líder y desarrollador ya que ellos toman en cuenta tanto los requerimientos funcionales como los no funcionales. De esta manera los riesgos abarcarán gran parte del proyecto. Es recomendable documentar todos los resultados de este trabajo de grado formalmente para el desarrollo del software. Existen documentos que ya están en los formatos para archivar como los requerimientos de usuario, conjunto de casos de uso y documentación y diagramación de casos de uso. Los ingenieros no deben perder de vista la modelación de negocios, el análisis y diseño, las pruebas o prototipos y la implementación (desarrollo) a través de todas las fases, ya que a diferencia de lo que se pensaba en el pasado, el desarrollo de software no se lleva a cabo disciplina por disciplina sino que todas las disciplinas interactúan en las diferentes fases. En el anexo 33 se pueden apreciar las pantallas más importantes del sistema para los el ingeniero desarrollador y líder tengan una idea o los pre-diseños para construir las pantallas del software. Sin embargo es recomendable que CGC contrate un diseñador industrial, o una persona idónea en el campo del diseño para que el software sea amigable con los usuarios tanto gráficamente como funcionalmente. El sueldo de este diseñador está contemplado en la evaluación económica. Inmediatamente después de la implementación es recomendable que se diseñe el proceso de “soporte al software” ya que mínimo una persona tiene que estar brindando soporte en caso de que falle o para monitorear el desempeño del software (Está persona puede ser el usuario “Administrador del sistema”). Es recomendable diseñar este proceso después de la implementación ya que si se diseña antes el proceso no responderá a las necesidades del software. Como en todos los procesos de transición existen riesgos asociados a la resistencia al cambio, implementación de los nuevos procesos, escépticos hacia el nuevo software, etc., por estas razones y muchas más es recomendable que CGC adopte políticas de incentivos para los empleados con el ánimo de mitigar estos riesgos y evitar barreras humanas a la hora de implementar el software.

105

14. Bibliografía

• Lenguaje unificado de modelado Manual de referencia. Pearson education 2007. • Managing software requirements a use case approach 2nd ed. Leffingwell, Dean. Addison

Wesley 2003 • The rational unified process an introduction, 2nd ed. Kuchten Philippe • Sistemas de información gerencial (Administración del empresa digital), Kenneth C.

Laudon, Jane P. Laudon, 10ma edición, 2008. • Formulación y evaluación de proyectos de inversión. Una visión integran para empresas

manufactureras y de servicios, Cengage learning, Jorge Rosillo, 2007 Páginas de internet

• http://readyset.tigris.org/nonav/es/templates/user-needs.html; Consultada 16/09/09; 5:30 pm

• http://www.fundibeq.org/metodologias/herramientas/diagrama_matricial.pdf; Consultada 10/09/09; 7:14 pm

• Fuente:http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.html

• http://www.ibm.com/developerworks/rational/library/1826.html; 1/10/09 • http://www.fundibeq.org/metodologias/herramientas/diagrama_matricial.pdf; Consultada el

10/09/09 7:14 pm

106

Anexos

Anexo 1: Diagramación del proceso Ventas

107

Anexo 2: Caracterización del proceso Ventas

CARACTERIZACIÓN DE PROCESOS

MACROPROCESO: MACRO PROCESOS MISIONALES PROCESO: VENTAS

OBJETIVO: Llevar a cabo una venta un plan de datos o de voz.

LIDER O RESPONSABLE DEL PROCESO: Asesor PROCESO PROVEEDOR DE LA ENTRADA

ENTRADA FORMATO ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA PROCESO CLIENTE DE LA SALIDA

1. Capacitaciones antiguos, Capacitaciones nuevos 2. Ventas

1. Portafolio de productos. 2. Necesidades del cliente


Ofrecer portafolio de productos 1. Elección de plan y

equipo 1. Ventas

1. Ventas 1. Información demográfica del cliente

1. Escrito en los formatos necesarios para la venta.

Verificar estatus de data crédito.

1. Impreso directamente de Poliedro.

1. Estatus de data crédito

1. Ventas y activaciones.


1. Documentos necesarios dependiendo del tipo de venta. 2. Formatos necesarios dependiendo del tipo de venta.

1. Fotocopias de los documentos necesarios dependiendo del tipo de venta. 2. Formatos impresos dependiendo del tipo de venta.

Conseguir y diligenciar los documentos necesarios.

1. Fotocopias de los documentos necesarios 2. Formatos impresos y diligenciados para procesar la venta


1. Activaciones 2. Activaciones

1. Ventas

1. Contrato diligenciado.

1. Formato de contrato de venta


1. Factura impresa 2. Copia adjunta al contrato original

1. Factura original 2. Copia del contrato. 1. Ventas

1. Ventas

1. Factura original 2. Copia del contrato.

1. Factura impresa 2. Copia adjunta al contrato original

Buscar y entregar el equipo al asesor. 1.Equipo físico 1. Equipo. 1. Ventas

1. Activaciones

1. Documentos necesarios para la activación del equipo.

1. Formatos para la venta y fotocopia de los documentos necesarios para la venta.

Activar producto.

1. Copia del contrato para la venta y fotocopia de los documentos necesarios para la venta. El equipo se entrega físico y activado

1. Equipo activado, copia de contrato y copia de la factura.

1. Ventas

1. Ventas

1. Equipo, copia del contrato y copia de factura.

1. El equipo se entrega físico junto con las copias del contrato y la factura.

Entregar el producto. 1. Cliente satisfecho

108






PROCESOS RELACIONADOS: Activaciones, Capacitaciones antiguos, Capacitaciones nuevos

RECURSOS: Humanos; Asesor, Líder de Caja y Bodega, Auxiliar de Caja y Bodega, Líder de activaciones. Económicos: Dinero dependiendo del plan y el equipo. Físicos: Formatos necesarios dependiendo del tipo de venta, Computadores, Instalaciones de la sede principal de CGC. Electrónicos: Software actual, SICACOM.

DOCUMENTOS INTERNOS: Venta post-pago: (Consecutivo Comcel) Contrato Persona Natural ò Contrato Persona Jurídica. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta datos: (Consecutivo Comcel) Contrato Persona Natural Datos ò Contrato Persona Jurídica Datos. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo de 3G. (Consecutivo Comcel) Anexo de Checklist. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta pre-pago (KIT): (Consecutivo Comcel) Planilla legalización prepago.


109






Factura original del recaudo según la venta.

INDICADORES: Reporte de inconsistencias en proceso de revisión de ventas en Activaciones. (Numero de inconsistencias encontradas en activaciones / Numero de ventas) Este indicador le deja ver al vendedor cuantas ventas está perdiendo por inconsistencias en sus contratos. Buzón de Sugerencias de los clientes: En este buzón los clientes pueden registrar cualquier sugerencia o queja que tengan para luego ser procesada por el coordinador de CPS.

110

Anexo 3: Diagramación del proceso Activaciones

111

Anexo 4: Caracterización del proceso Activaciones


MACROPROCESO: MACRO PROCESOS MISIONALES PROCESO: ACTIVACIONES

OBJETIVO: Activar un plan de voz o de datos vendido por un asesor de ventas.

LIDER O RESPONSABLE DEL PROCESO: Líder de activaciones. PROCESO PROVEEDOR DE LA ENTRADA


1. Ventas

1. Contrato diligenciado.

1. Formato de contrato diligenciado


1. Factura impresa y copia del contrato adjunta al mismo.

1. Factura original y copia del contrato.

1. Ventas

1. Ventas 1. Copia del contrato 1. Copia del contrato

adjunta al mismo Verificar y aprobar contrato diligenciado.

1. Esta aprobación se brinda verbalmente.

1. Aprobación o rechazo del contrato 1. Activaciones.

1. Ventas

1. Información del contrato: Datos personales del cliente, precio.

1. Escrito en los formatos de la venta

Asignar el equipo en el Software actual.

1. Factura impresa y el MIN escrito en el contrato.

1. Factura Software actual, MIN (Número del celular).

1. Activaciones.

1. Ventas

1. datos personales del cliente.

1. Escritos en el contrato de la venta Activar equipo. 1. El equipo se entrega

físico y activado 1. Equipo activado 1. Ventas.

1. Ventas y Activaciones

1. Datos del equipo: MIN, serial. 1. Escrito Descargar el equipo del

Software actual. 1. Físico e impreso

1. Equipo seleccionado con el contrato y la factura adjuntados.

1. Ventas y activaciones

1. Ventas

1. Equipo seleccionado con el contrato y la factura adjuntados.

1. Físico e impreso Entregar equipo activado. 1. Cliente satisfecho

PROCESOS RELACIONADOS: Ventas.

RECURSOS: Humano: Líder de activaciones, Líder de caja y bodega, Auxiliar de caja y bodega, Asesor. Económico: Dinero dependiendo del plan y del equipo. Físicos: Computadores, Papelería, Formatos, Instalaciones de la sede principal de CGC. Electrónicos: Software actual, Microsoft office, SICACOM.

DOCUMENTOS INTERNOS: Venta post-pago: (Consecutivo Comcel) Contrato Persona Natural ò Contrato Persona Jurídica. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio.

DOCUMENTOS EXTERNOS: Venta post-pago: Fotocopia de la cedula tamaño normal. Venta datos:

112


MACROPROCESO: MACRO PROCESOS MISIONALES PROCESO: ACTIVACIONES

OBJETIVO: Activar un plan de voz o de datos vendido por un asesor de ventas.

LIDER O RESPONSABLE DEL PROCESO: Líder de activaciones. PROCESO PROVEEDOR DE LA ENTRADA


(Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta datos: (Consecutivo Comcel) Contrato Persona Natural Datos ò Contrato Persona Jurídica Datos. (Consecutivo Comcel) Cláusula de permanencia. (Consecutivo Comcel) Anexo calidad del servicio. (Consecutivo Comcel) Anexo de 3G. (Consecutivo Comcel) Anexo de Checklist. (Consecutivo Comcel) Anexo guía para uso del servicio de datos en el exterior. (Consecutivo Comcel) Anexo acuerdo para la expedición y aceptación de entrega de factura clientes postpago. (Consecutivo Comcel) Anexo autorización data créditos. (Consecutivo Comcel) Anexo entrega de equipos. Venta pre-pago (KIT): (Consecutivo Comcel) Planilla legalización prepago. Factura original del recaudo según la venta.

Fotocopia de la cedula tamaño normal.

INDICADORES: Reporte de Comcel de contratos inconsistentes. (Contratos con inconsistencias reportados por Comcel / Contratos enviados a Comcel): Este indicador se mide en porcentaje para tener un control a largo plazo, pero a corto plazo se fijan metas de # de inconsistencias.

113

Anexo 5: Diagramación del proceso Nomina

114

Anexo 6: Caracterización del proceso Nomina


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: NOMINA

OBJETIVO: Para el pago de la nomina por parte de outsourcing es necesario entregar el archivo de nomina actualizado a THR; Outsourcing de nomina de CGC.

LIDER O RESPONSABLE DEL PROCESO: Coordinador administrativo. PROCESO PROVEEDOR DE LA ENTRADA


1. Contabilidad 2. Gestión comercial

1. PN IS 01 2. PN NN 02

1. Formato de contabilidad para los salarios de los empleados. 2. No tiene formato

Generar archivo de nomina.

1. Formato de contabilidad para los salarios de los empleados

1. PN IS 01 actualizado.

1. Nomina

1. Nomina. 1. PN AN 03 1. Archivo vía email (Excel) Pagar nomina 2. Comprobantes

impresos por THR

1. Nomina pagada. 2. Comprobantes de pago

1. Nomina 2. Nomina

PROCESOS RELACIONADOS: Contabilidad. RECURSOS: Humanos: Auxiliar de contaduría, Coordinador administrativo, Personal de TECNOVA para el pago de la nomina. Físicos: Computadores, Instalaciones de la sede principal de CGC (Calle 13), Instalaciones TECNOVA (Calle 147 #21- 62) oficina 5, Datafonos de TECNOVA para paga nomina. Económicos: Pago de nomina. Electrónicos: Internet, Microsoft office. DOCUMENTOS INTERNOS: PN IS 01 Información acerca de los salarios de los empleados de la compañía. PN NN 02 Novedades de la nomina PN AN 03 Archivo de nomina final

DOCUMENTOS EXTERNOS: Comprobantes del pago de la nomina por parte de TECNOVA.

INDICADORES:

Codificación documentosSigla SignificadoPN Proceso de nomina IS Información salarios NN Novedades de nomina # Consecutivo

115

Anexo 7: Diagramación del proceso Compra de equipos

116

Anexo 8: Caracterización del proceso Compra de equipos


MACROPROCESO: GESTIÓN ADMINISTRATIVAPROCESO: COMPRA DE EQUIPOS




1. Compra de equipos.

1. Necesidades según los coordinadores de los CPS

1. Las necesidades las transmiten los asesores verbalmente al coordinador del CPS

Solicitar equipos. 1. No hay formato, solo se envía un mail con las necesidades

1. Archivos de todos los CPS con las solicitudes de equipos.



1. PCE SC 01 1. No hay formato, solo se envía un mail con las necesidades

Consolidar las necesidades de todo CGC.

1. Formato para consolidar las necesidades usado por el coordinador administrativo.

1. PCE CS 01 1. Compras de equipos.


1. PCE CS 01 2. Reporte de diario de Comcel de inventario disponible

1. Formato para consolidar las necesidades usado por el coordinador administrativo. 2. Archivo consultado en poliedro.

Verificar inventario disponible (para post-pago y kit pre-pago) y de cartera al día (para KIT prepago).

1. La solicitud se ingresa a través de poliedro. 2. Este reporte llega vía email

1. Solicitud de pedido 2. Reporte de no disponibilidad

1. Compra de equipos. 2. Compra de equipos.

1. Compra de equipos

1. Remisión de Comcel

1. Remisión en poliedro y en el momento del retiro de los equipos de las bodegas de Comcel

Reclamar equipos en bodegas y distribuirlos según las necesidades de cada CPS.

1. Equipos físicos 1. Equipos solicitados


PROCESOS RELACIONADOS: Ventas, Activación, Control de inventarios.

RECURSOS: Humanos: Coordinador administrativo, Coordinador de CPS, Personal de Comcel para la programación y despacho de equipos. Físicos: Computadores, CPS's CGC, Medio de transporte de CGC. Económicos: Pago de los KIT. Electrónicos: Software actual, Internet, Microsoft office.

DOCUMENTOS INTERNOS: DOCUMENTOS EXTERNOS:

117


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: COMPRA DE EQUIPOS

PCE CS 01 Archivo consolidado de todas las solicitudes.

- Reporte de diario de Comcel de inventario disponible. - Remisión de Comcel.

INDICADORES:

Codificación documentosSigla SignificadoPCE Proceso de compra de equipos SC Archivos de todos los CPS con las solicitudes de equipos. # Consecutivo

118

Anexo 9: Diagramación del proceso Compra de recargas o Sim Card

119

Anexo 10: Caracterización del proceso Compra de recargas o Sim Card


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: COMPRA DE RECARGAS O SIM CARD

OBJETIVO: Comprar recargas para los celulares (vía celular) o Sim Card para la venta.



1. Compra de recargas o Sim Card

1. Saldo de la línea que se usa para las recargas vía celular.

1. Vía celular (*300)

Determinar necesidades de recargas o Sim Card. 1. Verbalmente

1. Pedido de Sim Card y Tarjetas prepago por CPS2. Necesidades de recargas y Sim Card de CGC.

1. Compra de recargas y Sim Card. 2. Compra de recargas y Sim Card

1. Contabilidad 1. PCR RC 01 1. Formato de contabilidad para el reporte de cartera.

Verificar estatus de cartera.

1. No hay formato. La decisión es verbal.

1. Decisión compra de recargas o tarjetas pre-pago.

1. Compra de recargas o Sim Card.


1. Verificación de disponibilidad en poliedro

1. La verificación se ve online en poliedro

Verificar disponibilidad de cupo en Comcel.

1. No hay formato. La decisión es verbal.

1. Decisión compra de SIM CARD.



1. Respuesta de poliedro.

1. La respuesta se ve en una ventana Online en poliedro.

Solicitar ampliación de cupo a Comcel

1. Llamada al representante de Comcel actual para pedir ampliación.



1. Remisión de Sim Card y de tarjetas pre-pago.

1. La remisión se puede ver online en poliedro o en el momento de entrega del producto Comcel entrega la remisión.

_ Transferir recargas _ Entregar Tarjetas pre-pago _ Entregar Sim Card

1. Recargas transferidas a los celulares de recargas. 2. Sim Card y tarjetas prepago entregadas (Programar con la logística de los equipos)

1. Compra de recargas o Sim Card 2. Compra de recargas o Sim Card

120


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: COMPRA DE RECARGAS O SIM CARD

OBJETIVO: Comprar recargas para los celulares (vía celular) o Sim Card para la venta.



PROCESOS RELACIONADOS: Compra de equipos, Contabilidad, Ventas. RECURSOS: Humanos: Coordinador administrativo, Representante de Comcel, RRHH de Comcel para compra y despacho del producto, Auxiliar de contabilidad, Físicos: Instalaciones de la sede principal de CGC (calle 13), computadores, Computadores, Medios de transporte de CGC Económicos: Pago de Sim Card y recargas. Electrónicos: Software actual, Microsoft office.

DOCUMENTOS INTERNOS: PCR RC 01 Reporte de cartera.

DOCUMENTOS EXTERNOS: - Reporte de cupo de Comcel agotado. - Remisión de Sim Card.

INDICADORES:

Codificación documentosSigla SignificadoPCR Proceso de compra de recargas o Sim Card RC Reporte de cartera. # Consecutivo

121

Anexo 11: Diagramación del proceso Control de inventarios

122

Anexo 12: Caracterización del proceso Control de inventarios


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: CONTROL DE INVENTARIOS





1. PCI SI 01 2. Solicitud justificación inventario.


_ Enviar solicitud inventario CPS _ Enviar solicitud justificación inventario.

1. Archivo vía email (Excel) 2. Archivo vía email (Excel)

1. PCI SI 01 enviada. 2. Solicitud justificación inventario CGC enviada.



1. PCI K 02 2. PCI K 03


_ Cruzar Kardex VS inventario físico _ Cruzar Kardex VS Inventario Comcel

1. Formato en Excel 2. Formato en Excel 3. Memorando vía email4. Memorando vía email





1. Archivo (Excel) 2. Archivo (Excel) 3. Memorando vía email4. Memorando vía email

Verificar documento

1) Formato en Excel 2. Formato en Excel 3. Memorando vía email.

1. PCI RSF 08 2. Reporte de sobrantes o faltantes CGC. 3. Aprobación documento

1. Control de inventarios 2. Control de inventarios 3. Control de inventarios


1. PCI RSF 08 2. Reporte de sobrantes o faltantes CGC.


Justificar sobrantes y faltantes.

1. Memorando vía email2. Memorando vía email

1. PCI JSF 09 2. PCI JSF 10


PROCESOS RELACIONADOS: Compras equipos, Compras recargas y Sim Card. RECURSOS: Humanos: Coordinador administrativo, Representante de Comcel, RRHH de Comcel para verificación de inventarios, Coordinador de CPS. Físicos: CPS's CGC, Computadores. Electrónicos: Internet, Software actual, Microsoft office.

123


MACROPROCESO: GESTIÓN ADMINISTRATIVA PROCESO: CONTROL DE INVENTARIOS




DOCUMENTOS INTERNOS: PCI SI 01 Solicitud inventario CPS PCI K 02 Kardex CPS PCI K 03 Kardex CGC PCI CI 04 Cruce completo de inventarios CGC. PCI CI 05 Cruce completo de inventarios CPS. PCI II 06 Informe de inventario CGC ok. PCI II 07 Informe de inventario CPS ok. PCI RSF 08 Reporte de sobrantes o faltantes CPS. PCI JSF 09 Justificación de sobrantes y faltantes CGC. PCI JSF 10 Justificación de sobrantes y faltantes CPS.

DOCUMENTOS EXTERNOS: - Solicitud justificación inventario. - Reporte de sobrantes o faltantes CGC.

INDICADORES:

Codificación documentosSiglas SignificadoPCI Proceso de control de inventarios SI Solicitud inventario CPS K Kardex C Cruce completo de inventarios II Informe de inventario RSF Reporte de sobrantes o faltantes CPS JSF Justificación se sobrantes o faltantes # Consecutivo

124

Anexo 13: Diagramación del proceso Capacitaciones asesores antiguos

Anexo 14: Caracterización del proceso Capacitaciones de asesores antiguos


MACROPROCESO: GESTIÓN COMERCIAL PROCESO: CAPACITACIONES PARA ASESORES DE VENTA ANTIGUOS.

OBJETIVO: Capacitar a los asesores en los nuevos productos, condiciones y entregarles el nuevo material de trabajo.

LIDER O RESPONSABLE DEL PROCESO: PROCESO PROVEEDOR DE LA ENTRADA ENTRADA FORMATO

ENTRADA ACTIVIDADES FORMATO SALIDA SALIDA PROCESO CLIENTE DE LA

SALIDA

1. Capacitaciones de asesore antiguos

1. Disponibilidad salón.

1. Se hace una llamada al coordinador del CPS que tiene el salón disponible para apartar el salón

Planear la capacitación. 1. Verbalmente

1. Programación de la capacitación.



1. Nuevo material, nuevos productos, nuevas


Asistir a la capacitación. 1. Material proporcionado por Comcel.

1. Nuevo material con nuevas condiciones y productos.

1. Capacitaciones de asesore antiguos y Ventas 1. Capacitaciones de asesore antiguos y Ventas

125


MACROPROCESO: GESTIÓN COMERCIAL PROCESO: CAPACITACIONES PARA ASESORES DE VENTA ANTIGUOS.

condiciones. 2. Asesores capacitados

PROCESOS RELACIONADOS: Ventas. RECURSOS: Humanos: Coordinador de CPS. Asesores de ventas. Físicos: CPS's de CGC, Video beam, tablero, marcadores, portafolio actualizado. Electrónicos: Internet, Microsoft office.

DOCUMENTOS INTERNOS: - Nuevo material con nuevas condiciones y productos.

DOCUMENTOS EXTERNOS: - Nuevos Brochures. - Nuevas condiciones. - Material de nuevos productos.

INDICADORES:

126

Anexo 15: Diagramación del proceso Capacitaciones asesores nuevos

127

Anexo 16: Caracterización del proceso Capacitaciones de asesores nuevos


MACRO PROCESO: GESTIÓN COMERCIAL PROCESO: CAPACITACIONES PARA ASESORES DE VENTA NUEVOS.

OBJETIVO: Capacitar a los asesores en ventas por primera vez, introducirlos al ámbito del distribuidor y entregarles el portafolio actualizado

LIDER O RESPONSABLE DEL PROCESO: PROCESO PROVEEDOR DE LA ENTRADA


1. Capacitaciones de asesores nuevos.

1. Disponibilidad de los salones. 2. Disponibilidad de los asistentes.

1. Verbalmente 2. Verbalmente Planear la capacitación. 1. Verbalmente 1. Programación de

la capacitación.

1. Capacitaciones de asesores nuevos.

1. Capacitaciones de asesores nuevos

1. Nuevas condiciones y productos. 1. Impreso Impresión del portafolio. 1. Impreso

1. Actualizar el portafolio e imprimirlo.

1. Capacitaciones de asesores nuevos

PROCESOS RELACIONADOS: Ventas. RECURSOS: Humanos: Coordinador de CPS. Asesores de ventas. Físicos: CPS's de CGC, Video beam, tablero, marcadores, portafolio actualizado. Electrónicos: Internet, Microsoft office.

DOCUMENTOS INTERNOS: - Nuevo portafolio.

DOCUMENTOS EXTERNOS: - Nuevos Brochures. - Nuevas condiciones. - Material de nuevos productos.

INDICADORES:

128

Anexo 17: Diagramación del proceso Servicio al cliente Reposición

129

Anexo 18: Caracterización del proceso Servicio al cliente Reposición


MACROPROCESO: SOPORTE AL SERVICIO. PROCESO: SERVICIO AL CLIENTE REPOSICIÓN.


LIDER O RESPONSABLE DEL PROCESO: Servicio al cliente. PROCESO PROVEEDOR DE LA ENTRADA


1. Servicio al cliente reposición. 2. Servicio al cliente reposición. 3. Servicio al cliente reposición.

1. Necesidades del cliente. 2. Formato cambio de servicio 3. Fotocopia de cédula del cliente. 4. Fotocopia del denuncio

2. Formato de cambio de servicio proporcionado por Comcel 3. Fotocopia de la cedula. 4. Fotocopia del denuncio.

Elegir tipo de reposición

2. Formato de cambio de servicio proporcionado por Comcel 3. Fotocopia de la cedula 4. Fotocopia del denuncio

1. Elección de la reposición. 2. Formato cambio de servicio 3. Copia de la cedula del cliente 4. Copia del denuncio.

1. Servicio al cliente reposición 2. Servicio al cliente reposición 3. Servicio al cliente reposición 4. Servicio al cliente reposición

1. Servicio al cliente reposición

1. Datos demográficos del cliente

1. Escrito en el formato de cambio de servicio

Verificar titularidad del cliente. 1. Pantalla de poliedro.

1. Titularidad o no titularidad del cliente sobre el equipo.


1. Servicio al cliente reposición 2. Servicio al cliente reposición 3. Servicio al cliente reposición

1. Formato cambio de servicio 2. Copia de la cedula del cliente 3. Copia del denuncio.

1. Formato de cambio de servicio (Comcel) 2. Fotocopia de la cedula3. Fotocopia del denuncio

Diligenciar formatos.

1. Formato de cambio de servicio diligenciado2. Fotocopia de la cedula 3. Fotocopia del denuncio

1. Formato cambio de servicio diligenciado.2. Copia de la cedula del cliente 3. Copia del denuncio.



1. Datos de la venta 1. Pantalla del Software actual

Verificar disponibilidad de seriales

1. Pantalla del Software actual. 1. PSR RDS 01 1. Servicio al cliente

reposición

1. Servicio al cliente reposición 2. Servicio al cliente reposición

1. Serial equipo actual. 2. Datos del cliente

1. Se ve en el equipo actual del cliente. 2. Escritos en el formato de cambio de servicio

Verificar seriales del equipo. 1. Pantalla de poliedro. 1. PSR VP 02



1. Formato cambio de servicio diligenciado 2. Copia de cédula del cliente. 3. Copia del denuncio

1. Impreso y escrito 2. Fotocopia de la cedula3. Fotocopia del denuncio

Recaudar el valor de la reposición

1. Factura impresa 2. Formato de cambio de servicio diligenciado con el timbre de pagado

1. Original factura. 2. Formato cambio de servicio con timbre de pagado.

1. Líder de servicio.

130


MACROPROCESO: SOPORTE AL SERVICIO. PROCESO: SERVICIO AL CLIENTE REPOSICIÓN.


LIDER O RESPONSABLE DEL PROCESO: Servicio al cliente. PROCESO PROVEEDOR DE LA ENTRADA


1. Servicio al cliente reposición 2. Servicio al cliente reposición

1. Formato cambio de servicio 2. Copia de cédula del cliente.

1. Formato de cambio de servicio impreso y escrito 2. Fotocopia de la cedula

Activar SIM CARD.

1. Sim Card física 2. Copia adjunta al cambio de servicio 3. Factura impresa

1. SIM CARD activada. 2. Copia amarilla de Formato cambio de servicio 3. Original de la factura.


1. Líder de servicio. 2. Líder de servicio. 3. Líder o auxiliar de caja y bodega

1. SIM CARD o equipo activada. 2. Copia amarilla de Formato cambio de servicio 3. PSR OF 03

1. Equipo o Sim Card físicos 2. Copia adjunta al cambio de servicio. 3. Factura impresa

Recibir Equipo o Sim Card Activados o los dos. 1. Cliente satisfecho.

PROCESOS RELACIONADOS: Compra de equipos, Compra de recargas o Sim Card. RECURSOS: Humanos: Líder de servicio, Líder de caja y bodega, Auxiliar de caja y bodega. Físicos: Instalaciones CPS's CGC, Papelería, Computadores. Económicos: Pago de la reposición. Electrónicos: Software actual, SICACOM, POLIEDRO. DOCUMENTOS INTERNOS: (Consecutivo Comcel) Formato cambio de servicio. PSR RDS 01 Reporte disponibilidad de SIM CARD PSR VP 02 Verificación en POLIEDRO. PSR OF 03 Original factura.

DOCUMENTOS EXTERNOS: - Copia de cédula del cliente. - Copia del denuncio.

INDICADORES: SIAC (Sistema de información de administración de clientes) Indica los números de usuarios atendido y el número de usuarios que desistieron en cada uno de los puntos

Codificación documentosSiglas SignificadoPSR Proceso de servicio al cliente reposición RDS Reporte disponibilidad de SIM CARD VP Verificación en poliedro OF Original factura # Consecutivo

131

Anexo 19: Diagramación del proceso Servicio al cliente Recargas

132

Anexo 20: Caracterización del proceso Servicio al cliente Recargas


MACROPROCESO: SOPORTE AL SERVICIO. PROCESO: SERVICIO AL CLIENTE RECARGAS.

OBJETIVO: Venta de recargas para los celulares de los cliente Comcel.

LIDER O RESPONSABLE DEL PROCESO: Líder de caja y bodegas. PROCESO PROVEEDOR DE LA ENTRADA


1. Servicio al cliente recargas

1. Necesidades del cliente. Realizar Venta Recarga 1. Las indicaciones se

dan verbalmente 1. Indicaciones para pagar en caja.



1. Valor a pagar por la recarga

1. El valor se comunica verbalmente

Recaudar valor de la recarga. 1. Factura impresa 1. PR OF 01


1. Servicio al cliente recargas 2. Servicio al cliente recargas

1. Numero de celular 2. Valor de la recarga.

1. El cliente debe confirmar el celular verbalmente 2. El valor de la recarga se encuentra en la factura.

Confirmar número telefónico y realizar recarga

1. Cliente satisfecho


1. Necesidades del cliente. Realizar Venta Tarjeta

pre-pago 1. Las indicaciones se dan verbalmente

1. Indicaciones para pagar en caja.



1. Valor a pagar por la recarga

1. El valor se comunica verbalmente

Recaudar valor de la recarga. 1. Factura impresa 1. PR OF 01



1. Número celular del cliente 2. Valor de la recarga.

1. El cliente debe confirmar el celular verbalmente 2. El valor de la recarga se encuentra en la tarjeta prepago

Realizar recarga con la tarjeta pre-pago 1. Cliente satisfecho

PROCESOS RELACIONADOS: Compra de recargas o Sim Card. RECURSOS: Humanos: Líder de caja y bodega, Auxiliar de caja y bodega. Físicos: CPS's de CGC. Económicos: Pago de Tarjeta pre-pago o recarga. Electrónicos: Software actual. DOCUMENTOS INTERNOS: PR OF 01 Original factura

DOCUMENTOS EXTERNOS:

133


MACROPROCESO: SOPORTE AL SERVICIO. PROCESO: SERVICIO AL CLIENTE RECARGAS.

INDICADORES:

Codificación documentosSiglas SignificadoPR Proceso servicio al cliente recargas OF Original factura # Consecutivo

134

Anexo 21: Diagramación del proceso Pago de facturas

135

Anexo 22: Caracterización del proceso Pago de facturas

Codificación documentosSiglas SignificadoPF Proceso de pago de facturasOF Original factura# Consecutivo


MACROPROCESO: SOPORTE AL SERVICIO. PROCESO: PAGO DE FACTURAS.

OBJETIVO: Recaudar dinero de las facturas generadas por Comcel.

LIDER O RESPONSABLE DEL PROCESO: Líder de caja y bodega, Auxiliar de caja y bodega. PROCESO PROVEEDOR DE LA ENTRADA


1. Pago de facturas

1. Factura del cliente o cliente sin factura

1. Factura generada por Comcel Verificar factura.

1. La verificación se hace verbal con la factura proporcionada por comcel

1. Factura verificada. 1. Pago de facturas

1. Pago de facturas 1. Valor a cancelar

1. Escrito en la factura proporcionada por Comcel

Diligenciar factura con el valor a cancelar.

1. Factura diligenciada proporcionada por el líder de servicio.

1. Factura diligenciada

1. Pago de facturas.

1. Pago de facturas 1. PF CF 01

1. Factura original del pago realizado por el cliente

Recaudar valor de la factura

1. Factura impresa con el sello de recibido

1. PF OF 01 con timbre de recibido.

PROCESOS RELACIONADOS: N/A RECURSOS: Humanos: Líder de caja y bodega, Auxiliar de caja y bodega. Físicos: CPS's CGC, computadores, impresora de facturas. Económicos: Pago de factura. Electrónicos: SICACOM. DOCUMENTOS INTERNOS: PF OF 01 Original factura con timbre de recibido.

DOCUMENTOS EXTERNOS: - Factura del cliente.

INDICADORES: Comcel reporta al final del mes el total de los recaudos realizados por cada CPS durante el mes. Se verifica el promedio del último trimestre y con eso se fija la cuota para el siguiente mes.

136

Anexo 23: Entrevista # 1

Nombre: Mónica Ramírez Cargo: Asesor de ventas Proceso: Ventas

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Por qué? R: Ninguna, el software presenta muchas inconsistencias.

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Porqué?

R: Manejo de inventarios, porque la información que arroja el software nunca representa la realidad de los inventarios y al final el proceso de asignación de equipos hay que hacerla manualmente

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: Asignación automática: Para vender un equipo primero tiene que verificar si está en la bodega en físico y al momento de facturarlo tiene que decirle al sistema que equipo es el que quiere.

4) ¿Qué información requiere para llevar a cabo sus actividades?

R: Las condiciones de venta vigentes

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: El coordinador de cada CPS se la proporciona y se genera en Comcel.

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: La tienen constantemente en carpetas en el puesto de trabajo

7) ¿Qué información debe arrojar su proceso? R: Los documentos necesarios diligenciados para continuar con la activación.

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.)

R: A mano

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: Activaciones y caja porque ellos diligencian los documentos para que facturen el equipo, y ya con el sello caja se lo envían a activaciones para que procedan con la activación del equipo.

10) ¿Qué problemas presenta actualmente el proceso?

R: Búsqueda del equipo y activaciones

137


Nombre: Victoria Moreno Cargo: Líder de activaciones Proceso: Activaciones

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Porqué? R: Usan aprobación y facturación de contratos, Todo es a mano y por lo tanto depende del activador que se lleve a cabo bien o no. En resumen ninguna actividad

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Por qué? R: Manejo de inventarios. No falla sino que no tiene los filtros necesarios. No hay un control entre activaciones y caja.

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: Inventarios.

4) ¿Qué información requiere para llevar a cabo sus actividades? R: La información demográfica del cliente y la información de los seriales del equipo.

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: El cliente: A mano El sistema: Automáticamente, arroja los seriales de los equipos

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: Cliente: escrita en los contratos Seriales: Dependiendo del inventario que haya en ese momento en bodega (Archivo plano en el sistema, y manipulable)

7) ¿Qué información debe arrojar su proceso? R: El numero de celular que se le da al cliente. Online es inmediatamente. O 3 días hábiles cuando se tramitan activaciones tradicionales.

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.) R: La página web la arroja, El activador ingresa los datos a poliedro (contrato) y poliedro arroja el número de celular para el cliente.

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: Comisiones: para la liquidación de comisiones Vendedor: para la entrega de los equipos activados

10) ¿Qué problemas presenta actualmente el proceso? R: No se respeta el proceso de activaciones, existe desorden en los pasos para llevar a cabo el proceso por el afán de cerrar una venta.

11) ¿Qué otra persona además de usted tiene acceso al software en su área y por qué lo utiliza? En caso de que usted sea el único usuario en su área en este momento ¿Qué otra persona debería tener acceso al software y por qué?

138

R: El planillador es la persona que genera los volantes de consignación, dan la pauta para determinar cuándo se envían los contratos a Comcel. Esta persona tiene acceso al sistema para ingresar información de las consignaciones. Sugerencias: (Incluir sugerencias para mejorar actividades o procesos ajenos al analizado en esta encuesta.) En el software actual no está discriminada la forma de pago. Es necesario tener la forma de pago.

139


Nombre: Milton Florez Cargo: Coordinador administrativo Proceso: Compra de equipos

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Porqué? R: Nada, el software presenta muchas inconsistencias.

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Porqué? R: Manejo de inventarios: En el momento que se consulta el inventario y el sistema dice si hay inventario disponible

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: N/A

4) ¿Qué información requiere para llevar a cabo sus actividades? R: Las necesidades de cada CPS Estado de cartera La disponibilidad de inventario de CGC

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: Cada coordinador de CPS Contabilidad Comcel

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: Vía mail, un archivo informativo Via mail en Excel informando la cantidad de facturas vencidas y los valores de c/u Archivo en Excel en el formato.

7) ¿Qué información debe arrojar su proceso? R: Las cantidades de equipos necesitadas y las compradas.

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.) R: Cruzando las necesidades de cada CPS con la disponibilidad de Comcel

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: Comcel para la asignación de equipos

10) ¿Qué problemas presenta actualmente el proceso? R: Ninguno

140


Nombre: Milton Florez Cargo: Coordinador administrativo Proceso: Control de inventarios

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Porqué? R: Nada

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Por qué? R: Manejo de la toma física del inventario

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: Las solicitudes: Para poder hacerle seguimiento al trabajo del comprador el sistema debería sistematizar las solicitudes de los coordinadores. Con esto se sabe cuánto y cuando pidió cada coordinador.

4) ¿Qué información requiere para llevar a cabo sus actividades? R: Cruce del Kardex con el inventario físico Solicitud justificación inventario Informe de inventario Ok del CPS Justificación de sobrantes y faltantes

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: El coordinador lo hace (Manual) Comcel, Lo genera el área de control de inventarios en Comcel. Excel (Cada coordinador.) Una carta o memorando. Coordinador administrativo

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: Excel con los datos de los equipos, cuando se requiera Formato de solicitud. (Encabezado IMEI, ICCID, referencia de equipo) Encabezado IMEI, ICCID, referencia de equipo, cada vez que se requiera Memorando Cada vez que se requiera

7) ¿Qué información debe arrojar su proceso? R: Estado actual del kardex

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.) R: Cruzando los inventarios de los CPS confirmados y consolidados con los de Comcel

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: Comcel: para verificar las existencias de inventario que tiene cada distrib. Coordinador: Para verificar el inventario físico en su bodega.


141


Nombre: Leyder Castillo López Cargo: Líder de servicio Proceso: Servicio al cliente Reposición

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Porqué? R: Asignación de Sim Card

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Por qué? R: Ninguna

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: La facturación en línea: Alinear las actividades de asignación de Sim Card con la facturación

4) ¿Qué información requiere para llevar a cabo sus actividades? R: Datos demográficos del cliente.

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: El cliente

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) N/A

7) ¿Qué información debe arrojar su proceso? R: No arroja información específicamente solo lleva a cabo la reposición. Lo único es la información demográfica del cliente que es la misma que necesita para hacer la reposición.

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.) N/A

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: Caja para facturarlo y bodega para asignar el equipo. Comcel para verificar la cantidad de clientes atendidos.


143


Nombre: Ricardo Cuervo Cargo: Líder de caja y bodegas Proceso: Control de inventarios

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Porqué? R: Nada

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Por qué? R: Kardex de inventarios

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: Inventarios.

4) ¿Qué información requiere para llevar a cabo sus actividades? R: Datos demográficos del cliente Valor de las ventas Datos de los productos.

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: Escritos por el asesor de ventas o líder de servicio Liquidado en el contrato de la venta Escrito por el asesor y asignado por el sistema

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: Escrito por el asesor en el contrato en el momento de la venta (el orden lo determina el formato del contrato.) Escrito por el asesor en el contrato en el momento de la venta (el orden lo determina el formato del contrato.) Escrito por el asesor. El sistema debería asignar los productos automáticamente

7) ¿Qué información debe arrojar su proceso? R: Nada

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.) R: N/A

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza? R: El proceso si arroja información pero es interna, se trata del Kardex de inventarios, el cual se debería actualizar automáticamente con las asignaciones de productos que se hagan.

10) ¿Qué problemas presenta actualmente el proceso? R: El control errado de inventarios

11) ¿Qué otra persona además de usted tiene acceso al software en su área y por qué lo utiliza? En caso de que usted sea el único usuario en su área en este momento ¿Qué otra persona debería tener acceso al software y por qué?

144

R: La otra persona que utiliza el software es el auxiliar de caja, pero para efectos prácticos las funciones son las mismas.

145


Nombre: Reynel Nuñez Cargo: Coordinador de CPS Proceso: Control de inventarios

1) ¿Cuáles son las actividades del proceso que, a su juicio, el software actual lleva a cabo de forma correcta? Por qué? R: Ninguna

2) ¿Cuáles son las actividades del proceso en las cuales el software actual falla? Por qué?

R: En el momento que se quiere realizar un inventario físico la información que arroja el sistema no es fiable, es decir que el cálculo de inventarios por parte de sistema es errado. En el momento en que caja asigna seriales el software presenta una falencia ya que en ocasiones asigna dos veces el mismo producto.

3) ¿Qué actividades del proceso no soporta el software actual o que actividades debería soportar? R: Control de inventarios

4) ¿Qué información requiere para llevar a cabo sus actividades?

R: Kardex de inventarios

5) ¿Cómo se genera esta información y qué o quién se la proporciona? R: El sistema en forma impresa.

6) ¿Cómo necesita que le llegue esta información? (forma, medio, orden, momento, etc.) R: Impreso y en una tabla con dos columnas: referencia y serial

7) ¿Qué información debe arrojar su proceso? R: El cruce de inventarios El memorando de inventarios ok Si es el caso justificación de inventario

8) ¿Cómo genera usted la información? (forma, medio, orden, momento, etc.)

R: Archivo en Excel Archivo en Word Archivo en Word

9) ¿Quién utiliza la información que su proceso arroja y para que la utiliza?

R: A corto plazo, el coordinador administrativo, y a largo plazo Comcel. La utilizan para llevar un control de los inventarios.

10) ¿Qué problemas presenta actualmente el proceso?

R: Ninguno, debería ser mas automatizado, pero de igual forma se lleva a cabo a mano.

146

Anexo 30: Guía para usar el formato de casos de uso9 Esta sección provee una explicación de cada sección en el formato de caso de uso.

1. Identificación del caso de uso

a. ID del caso de uso Dele a cada caso de uso un identificador que sea una secuencia de entero única. Ej. 1

b. Nombre del caso de uso Establezca un nombre que describa los resultados del caso de uso. Este nombre reflejará las tareas que el usuario tendrá que llevar a cabo a través del sistema. Incluya un verbo en acción y un nombre. Ej.

• Ver información del numero de las partes • Hacer una orden para un CD

2. Historial del caso de uso a. Creado por

Provee el nombre de la persona que inicialmente documentó este caso de uso b. Fecha de creación

Provee la fecha en la cual el caso de uso fue documentado por primera vez c. Ultima actualización por

Provee el nombre de la persona que actualizó el caso de uso por última vez d. Fecha de la última actualización

Provee la fecha en la cual el caso de uso fue actualizado por última vez 3. Definición del caso de uso

o Actores Un actor es una persona o una entidad externa al sistema (software) que interactúa con el sistema y protagoniza casos de uso para llevar a cabo tareas. Diferentes actores corresponden a diferentes clases de usuarios que previamente fueron identificados en el nicho de clientes para el cual se está diseñando el software. En este caso no existen clientes potenciales por que el software no va a ser comercializado. Para el proyecto el nicho de clientes sería únicamente CGC y los usuarios sus empleados ya identificados. Nombre el actor que inicializa este caso de uso y cualquier otro que participara a través del caso de uso.

o Evento desencadenador Identifique el evento que inicializa el caso de uso. Se puede tratar de un evento externo al negocio o al sistema que conlleva al inicio del caso de uso, o puede ser el primer paso del flujo normal.

o Descripción Proporcionar una breve descripción de la razón por la cual se necesitan los resultados de este caso de uso, o en su defecto una descripción de alto nivel de la secuencia de las acciones y los resultados al ejecutarse este caso de uso.

o Precondiciones Liste todas las actividades que se deben llevar a cabo, o cualquier otra condición que deba cumplirse, antes de que el caso de uso se inicie.

o Pos condiciones

9 http://www.processimpact.com/elearning.shtml; 13/08/09; 6:00 pm

147

Describa el estado del sistema al terminar la ejecución del caso de uso Numere cada pos condición. Ej.

Acceso concedido al usuario. El precio del producto ha sido actualizado en la base de datos

o Flujo normal Proporcione una descripción detallada de las acciones del usuario y las respuestas del sistema, que tendrán lugar durante la ejecución del caso de uso en condiciones normales o esperadas. Esta secuencia conducirá finalmente a cumplir el objetivo indicado en el nombre y en la descripción del caso de uso. Esta descripción puede ser escrita como una respuesta a la pregunta, ¿Cómo puedo llevar a cabo la tarea que se indica en el nombre del caso de uso? La manera de hacerlo es como una lista numerada de las acciones hechas por el actor, alternándolas con las respuestas proporcionadas por el sistema. El flujo normal es numerado de la siguiente manera: "X.0", donde "X" es el ID del caso de uso y 0 el flujo normal.

o Flujos alternativos Documente cualquier otro flujo que se acepte en este caso de uso. La forma de numerar estos flujos alternativos es la siguiente: “X.Y” donde X es el ID del caso de uso y Y es el numero del flujo alternativo. Ej. 5.3 es el tercer flujo alternativo para el uso de caso 5.

o Excepciones Describa cualquier condición errada que pueda tener lugar durante la ejecución del caso de uso y responda como se supone que el sistema respondería a este comportamiento. También describa como se supone que el sistema debería responder si la ejecución del caso de uso falla a raíz de cualquier razón no anticipada. Si el caso de uso permanece por mucho tiempo en una base de datos o fuera del sistema, determine si el paso se completa correctamente (sin importar el tiempo que tome), se completa parcialmente, o en su defecto se deja en un estado indeterminado como resultado de la excepción. La forma de numerar las excepciones es la siguiente: “X.Y.E.Z”, donde X es el ID del caso de uso, Y es 0 para el flujo normal o Y>0 para el flujo alternativo en el cual esta excepción se presenta, E indica una excepción y Z es el número secuencial para las excepciones. Ej. 5.0.E.2 es la segunda excepción que se presenta en el flujo normal del caso de uso 5.

o Casos de uso incluidos Liste cualquier otro caso de uso que sea llamado por, o esté incluido dentro de este caso de uso. Funcionalidades comunes que se presenten en múltiples casos de uso se pueden separar y crear un nuevo caso de uso para luego ser incluidas en los casos de uso que las requieran.

o Prioridad Indique la prioridad relativa asociada a este caso de uso en relación a su funcionalidad. Esta prioridad debe ser la misma para la especificación de requerimientos del software. La puntuación se hará de 1-10 siendo 1 la puntuación para un caso de uso que no es significativo a la funcionalidad central y que tendrá poca participación en la arquitectura y 10 la puntuación para un caso de uso significativo a la funcionalidad central y que tendrá participación importante en la arquitectura.

o Frecuencia de uso Estime el número de veces que este caso de uso será utilizado por los actores por unidad de tiempo.

o Políticas de la empresa o del negocio

148

Liste cualquier política del negocio o de la empresa que influencie este caso de uso.

o Requerimientos especiales Identifique cualquier requerimiento adicional, tales como requerimientos no funcionales, para este caso de uso que sean necesarios para el diseño o la implementación. Esto puede incluir requerimientos de rendimiento u otros atributos de calidad. Estos requerimientos especiales se salen del alcance del proyecto.

o Supuestos Liste los supuestos que fueron hechos en el análisis que llevó a aceptar este caso de uso.

o Notas y TBD Liste cualquier nota adicional de este caso de uso o TBD’s (to be defineds) que tienen que ser resueltos. Identifique quien resolverá cada TBD, la fecha límite para resolverlo y cuál sería la solución final.

Formato de caso de uso

ID del caso de uso:

Nombre del caso de uso:

Creado por: Última actualización por: Fecha de creación: Fecha de la última

actualización:

Actores:

Descripción: Evento desencadenador:

Precondiciones: 1. Pos condiciones: 1.

Flujo normal: 1. Flujos alternativos:

Excepciones: Casos de uso incluidos:

Prioridad: Frecuencia de uso:

Políticas de CGC o del negocio: Supuestos:

Notas y TBD:

Historial de revisión Para efectos de impresión, este cuadro debería ir al final de todos los casos de uso y a medida que vaya creciendo (El responsable en CGC) tendría que usar una sola hoja para el mismo.

Nombre Fecha Razones del cambio Versión

Diego Infante 25/09/09 1ra versión 1

149

Anexo 31: Casos de uso

ID del caso de uso: 1 Nombre del caso de uso:

Acceso denegado

Creado por: Diego Infante Última actualización por: Diego Infante Fecha de creación: 25/09/09 Fecha de la última

actualización: 25/09/09

Actores: Coordinador administrativo, Líder o auxiliar de caja y bodega, Líder de activaciones,

Coordinador CPS, Líder de servicio, Planillador, Administrador de Software. Descripción: El resultado de este caso de uso es necesario porque no todos los usuarios que va a tener el

sistema van a tener los mismos permisos, de manera que cuando intenten ingresar a una transacción que no está incluida dentro de sus permisos el sistema tiene que denegarle el ingreso al usuario correspondiente.

Evento desencadenador: Intento de ingreso por parte de un usuario a una transacción que no está incluida dentro de sus permisos.

Precondiciones: 1. Usuario en sesión Pos condiciones: 1. Acceso denegado al usuario

2. Pantalla de menú Flujo normal: 1.0

1. Usuario en sesión 2. Intento de ingreso a una transacción no permitida para este usuario 3. Mensaje del sistema “Su usuario no tiene permiso para realizar esta transacción” 4. El sistema debe devolverlo a la ventana de menú principal.

Flujos alternativos: Excepciones:

Casos de uso incluidos: 21. Iniciar sesión Prioridad: 10

Frecuencia de uso: Cuando algún usuario intente ingresar a una transacción no permitida para el mismo. Políticas de CGC o del

negocio:

Proceso en el cual interactúa este caso de

uso

Este caso de uso no interactúa en ningún proceso.

Supuestos: Suponiendo que los usuarios no van a tener los mismos permisos para interactuar con el sistema, este mismo tiene que restringirles la entrada a las transacciones que no fueron especificadas en la creación de usuario o al editarlo.

Diagrama caso de uso 1

150


Asignar y activar el equipo en el sistema



Actores: Líder o auxiliar de caja y bodega, Líder de activaciones, Poliedro.

Descripción: El resultado de este caso de uso es necesario porque si no se asigna el equipo y si no se activa el mismo no se puede generar factura y en general no se puede terminar el proceso de venta.

Evento desencadenador: Generación de recibo de caja Precondiciones: 1. El líder o auxiliar de caja tiene que haber generado el recibo de caja.

Pos condiciones: 1. Los datos de los seriales y el Min de la sim (si es el caso) ya tiene que estar ingresados y almacenados en el sistema.

Flujo normal: 2.0 1. Líder o auxiliar de caja envía la información de la venta registrada en el contrato adjuntando el recibo de caja. 2. Completar los datos de la venta. 3. El sistema le asigna un equipo o Sim Card o los dos a la venta. Si no hay inventario disponible el Líder de activaciones consulta la disponibilidad de inventario y en caso de que otro CPS tenga el producto se procede a transferir la mercancía de un CPS a otro. 4. El líder de activaciones se remite al software Poliedro y activa el producto. 5. El líder de activaciones ingresa el Min del producto si es el caso 6. Datos de la venta almacenados exitosamente.

Flujos alternativos: 2.1 1. Líder o auxiliar de caja envía la información de la venta registrada en el contrato adjuntando el recibo de caja. 2. Completar los datos de la venta. 3. El sistema le asigna un equipo o Sim Card o los dos a la venta. Si no hay inventario disponible el Líder de activaciones consulta la disponibilidad de inventario y en caso de que otro CPS tenga el producto se procede a transferir la mercancía de un CPS a otro. 4. Si es una reposición de equipo el líder de activaciones liga el equipo a la Sim Card del cliente en Poliedro y copia el Min actual del cliente en los datos de venta.

5. Datos de la venta almacenados exitosamente. 2.2

1. Líder o auxiliar de caja envía la información de la venta registrada en el contrato adjuntando el recibo de caja. 2. Completar los datos de la venta. 3. El sistema le asigna un equipo o Sim Card o los dos a la venta. 4. Si es una reposición de Sim Card el líder de activaciones liga la Sim Card al equipo del cliente en Poliedro y copia el Min actual del cliente en los datos de venta.

5. Datos de la venta almacenados exitosamente. Excepciones: 2.0.E.1. Cuando se trata de una reposición el recibo de caja (elemento del evento

desencadenador) se cambia por la factura original ya que en la reposición no hay pre ingreso de los datos de la venta ya que esos datos ya existen por ser un cliente actual de Comcel.

Casos de uso incluidos: 6. Consultar disponibilidad de inventario 25. Transferencia de mercancía de un CPS a otro

Prioridad: 10 Frecuencia de uso: Promedio de ventas mensuales: 1600

Días hábiles al mes: 26 Numero de CPS: 10 1600/26 = 61,5/10 = 6,15 => 6 / día en promedio

Políticas de CGC o del negocio:


uso

Ventas, Servicio al cliente reposición y Activaciones

Supuestos: El sistema debe manejar el método de costeo de inventarios PEPS o FIFO, por ende el sistema es el que debe asignar los equipos para evitar malas prácticas de inventarios.

151

Diagrama Caso de uso 2

152


Cambiar precios de venta en el sistema



Actores: Coordinador administrativo,

Descripción: El resultado de este caso de uso es necesario ya que si no se cambian los precios de venta en el sistema tanto los líderes de caja como los líderes de activaciones van a estar imposibilitados a verificar la información de ventas y además la facturación estaría afectada.

Evento desencadenador:

Reporte diario de Comcel de precios vigentes

Precondiciones: . Pos condiciones: 1. Precios actualizados en el sistema.

Flujo normal: 3.0 1. Verificación diaria de los precios en Poliedro 2. Si hay cambios, actualizar los precios de venta en el sistema

Flujos alternativos: Excepciones: 3.0.E.1. En caso de que no se puede verificar los precios en Poliedro, comunicarse con el

representante de Comcel para CGC. Casos de uso incluidos: 18. Generar recibo de caja

Prioridad: 10 Frecuencia de uso: 1 / día


18. Generar recibo de caja y factura


uso

Este caso de uso actualiza la información de los precios de venta que es generada en el pre ingreso de los datos de la venta. Esta información es usada por los líderes o auxiliares de caja y bodega para generar recibos de caja y facturas para la venta. Los procesos donde se tienen que generar estos elementos son activaciones y ventas y servicio al cliente reposiciones.

Supuestos: Los líderes de activaciones no van a tener que ingresar a Poliedro para verificar los precios de venta y los líderes o auxiliares de caja y bodega tampoco van a tener que consultar Poliedro para generar un recibo de caja o una factura, ya que ingresar a poliedro lentifica mucho los procesos.


153


Cerrar sesión




Coordinador CPS, Líder de servicio, Planillador, Administrador de Software. Descripción: El resultado de este caso de uso es necesario ya que los usuarios eventualmente o al final del

día van a tener que dejar su puesto de trabajo, por esta razón cerrar sesión es indispensable para evitar que un empleado diferente use el sistema.

Evento desencadenador: Fin del día, Almuerzo, Dejar el puesto de trabajo por alguna razón válida por la compañía. Precondiciones: 1. Haber iniciado sesión

2. Tiene que haber cerrado todas las ventas de transacciones hasta llegar a la ventana de menú principal

Pos condiciones: 1. Sesión finalizada Flujo normal: 4.0

1. Iniciar sesión 2. Llevar a cabo cualquier actividad permitida del usuario 3. Volver a la ventana de menú principal 4. Cerrar sesión por cualquiera de las razones nombradas en el evento desencadenador.

Flujos alternativos: Excepciones: 4.0.E.1 En caso de que el usuario no haya cerrado todas las ventanas, el sistema tendrá que

preguntarle al usuario si quiere guardar los cambio hecho en la transacción correspondiente. Casos de uso incluidos: 22. Iniciar sesión

Prioridad: 10 Frecuencia de uso: Las veces que se necesite


Política de CGC: Cualquier empleado que tenga acceso a cualquier software de apoyo de la compañía, al dejar su puesto por cualquier razón, tiene cerrar sesión de todos los software.


uso


Supuestos: Cualquier software que se diseñe tiene que tener la opción de cerrar sesión para evitar que otras personas lleven a cabo transacciones en usuarios ajenos.


154


Cierres de caja diarios



Actores: Líder o auxiliar de caja y bodega.

Descripción: El resultado de este caso de uso es necesario ya que al final de todos los días se tienen que hacer cierres de caja en las diferentes cajas del CPS incluyendo la de ventas propias.


Fin del día

Precondiciones: 1. Fin del día, Puertas del CPS cerradas, todas las ventas y servicios restantes del día atendidos.

Pos condiciones: 1. Cierre de caja hecho. Flujo normal: 5.0

1. Fin del día. 2. Atender todas las ventas y servicios restantes. 3. Llevar a cabo el cierre de la caja.

Flujos alternativos: 5.1 1. Abandono del lugar de trabajo sin intención de volver en todo el día. 2. Llevar a cabo el cierre de caja.

Excepciones: 5.1.E.1. Este abandono de lugar de trabajo tiene que estar previamente autorizado por el coordinador del CPS.

Casos de uso incluidos: Prioridad: 10

Frecuencia de uso: 1 / día Políticas de CGC o del

negocio: Política de CGC: Todos los permisos para abandonar el puesto de trabajo parcial o totalmente durante el día deben ser notificados por lo menos con 1 día de anticipación al coordinador de CPS.


uso

Este caso de uso no interactúa en ningún proceso. Se trata de una de las funciones principales de los cajeros de un establecimiento comercial.

Supuestos: El sistema debe arrojar facturas y recibos de caja para los procesos de ventas, activaciones y servicio al cliente reposición, por lo tanto el sistema debe tener la opción de hacer los cierres de caja CGC. Cualquier sistema que maneje las cajas de un establecimiento comercial tiene que tener una opción para hacer cierres de caja.


155


Consultar disponibilidad de inventario



Actores: Coordinador de CPS, Coordinador administrativo, Líder de servicio al cliente, Líder de

activaciones Descripción: El resultado de este caso de uso es necesario ya que consultar el inventario disponible es vital

para el coordinador de CPS para hacer sus pedidos de productos y para el líder de servicio al cliente para ver si hay equipos o Sim Card para reposición.

Evento desencadenador: 1. Solicitud de equipos o Sim Card por parte del coordinador de CPS 2. Verificación de titularidad de cliente por parte del líder de servicio en el proceso

“servicio al cliente reposición” 3. El sistema no puede asignar equipo para la venta ya que el producto no está

disponible en el CPS Precondiciones:

Pos condiciones: Flujo normal: 6.0

1. Necesidad por cualquiera de los usuarios con este permiso de consultar la disponibilidad de inventario 2. El sistema debe Mostrar la disponibilidad de inventario en el CPS o en CGC según lo que necesiten.



Frecuencia de uso: Cada vez que sea necesario Políticas de CGC o del

negocio:


uso

Ventas, Servicio al cliente reposición, Activaciones, Compra de equipos y Sim Card.

Supuestos: El sistema va a manejar los inventarios del CGC, por lo tanto la opción de consultar la disponibilidad de inventarios en CGC o en el CPS tiene que estar habilitada para verificar la gestión del sistema y para apoyar los procesos que requieran de esta opción.


156


Consultar el reporte de cartera



Actores: Coordinador administrativo

Descripción: El resultado de este caso de uso es necesario ya que en un futuro este sistema también debería estar integrado con el proceso de contabilidad. Mientras no esté integrado el reporte se puede actualizar periódicamente por el coordinador administrativo. Por ahora el reporte diario de cartera se puede ver en Poliedro ya que Comcel lo actualiza diariamente.


Necesidades consolidadas de todo CGC.

Precondiciones: 1. El coordinador administrativo debe haber recibido todos los pedidos de todos los CPS. Pos condiciones: 1. Verificación de status de cartera

Flujo normal: 7.0 1. El coordinador administrativo debe haber recibido todos los pedidos de todos los CPS. 2. De acuerdo a estos pedidos consolidados, el sistema debe mostrar cuáles son Kit prepago y Sim Card ya que estos dos productos son lo que requieren cartera al día por parte de Comcel. 3. El sistema debe mostrar el status de cartera para tomar la decisión de comprar o no comprar.



Frecuencia de uso: Cada vez que se vaya a hacer un pedido a Comcel. Políticas de CGC o del

negocio:

Supuestos: El sistema va a integrar también el proceso de contabilidad en un futuro, así que esta opción de consultar el reporte de cartera es importante para el proceso de compras.


uso

Compra de equipos y Sim Card.

Notas y TBD: Llevar a cabo el levantamiento los requerimientos para el software que integre los procesos de contabilidad a los procesos sistematizados e integrados en este sistema. Este TBD queda a cargo de los arquitectos de software luego de la implementación del presente sistema.


7. Consultar elreporte de cartera

Sistema

Poliedro*

*

*

*

157


Consultar facturas



Actores: Planillador

Descripción: El resultado de este caso de uso es necesario ya que el planillador nocturne precisa del ingreso al sistema para verificar todos los datos ingresados a Poliedro contra los del sistema.

Evento desencadenador: Gestión normal del planillador. Precondiciones: 1. Planillador llevando a cabo su trabajo.


1. Comienzo del trabajo del planillador 2. El sistema le debe dejar consultar las facturas del CPS


Casos de uso incluidos: 10. Consultar información de activaciones Prioridad: 7

Frecuencia de uso: Las veces que sea necesario según el planillador Políticas de CGC o del

negocio:

Proceso en el cual interactúa este caso de uso

Este caso de uso no interactúa en ningún proceso. Este caso de uso es para la labor que lleva a cabo el planillador, que no tiene ninguna relación con ningún proceso.

Supuestos: El sistema va a almacenar todas las facturas generadas por cada CPS de manera que el planillador tiene que tener el permiso de consultar las facturas ya que sin este seria imposible verificar los datos ingresados a Poliedro.

Diagrama caso de uso 8

158


Consultar indicadores del comportamiento del software



Actores: Administrador del software

Descripción: El resultado de este caso de uso es necesario ya que el administrador del Software se va a basar en los indicadores de comportamiento del software para tomar decisiones sobre este.

Evento desencadenador: Mantenimientos y administración del software. Precondiciones:


1. Necesidad del administrador del software de checkear los indicadores de comportamientos del software. 2. El sistema debe mostrar todos los indicadores de comportamiento al administrador del software.



Frecuencia de uso: Cada vez que el administrador del software lo requiera. Políticas de CGC o del

negocio:


uso


Supuestos: El sistema va a tener comportamientos y estos comportamientos son utiles tanto para el administrador de software como para otras personas como los inversionistas. Comportamientos como, número de usuarios en línea, cantidad de información almacenada, etc.


159


Consultar información de activaciones



Actores: Planillador

Descripción: El resultado de este caso de uso es necesario ya que el planillador nocturno precisa del ingreso al sistema para verificar todos los datos ingresados a Poliedro contra los del sistema.

Evento desencadenador: Gestión normal del planillador. Precondiciones: 1. Planillador llevando a cabo su trabajo.


1. Comienzo del trabajo del planillador 2. El sistema le debe dejar consultar la información de activaciones del CPS


Casos de uso incluidos: 8. Consultar facturas Prioridad: 5

Frecuencia de uso: Las veces que sea necesario según el planillador Políticas de CGC o del

negocio:


uso



uso

Este caso de uso no interactúa en ningún proceso. Este caso de uso es para la labor que lleva a cabo el planillador, que no tiene ninguna relación con ningún proceso.

Supuestos: El sistema va a almacenar todas las asignaciones y activaciones de productos por parte del líder de activaciones y por cada CPS de manera que el planillador tiene que tener el permiso de consultar la información de activaciones ya que sin este sería imposible verificar los datos ingresados a Poliedro.


Planillador

8. Consultarfacturas

Sistema

Poliedro**

**

10. Consultarinformación de activaciones

«uses»

160


Crear usuarios



Actores: Administrador del software.

Descripción: El resultado de este caso de uso es necesario ya que sin la opción de creación y personalización de usuarios no se podría diferenciar entre un usuario y otro en relación a sus permisos.

Evento desencadenador: Usuario nuevo Precondiciones: 1. Saber que necesita el usuario

Pos condiciones: 1. Usuario creado Flujo normal: 11.0

1. El administrador del software define que permisos debe tener este usuario. 2. El sistema debe permitirle crear nuevos usuarios 3. Usuario creado con permisos definidos.


Casos de uso incluidos: 1. Acceso denegado Prioridad: 10

Frecuencia de uso: Cada vez que se quiera crear un usuario nuevo. Políticas de CGC o del

negocio:



Supuestos: El sistema debe permitir la creación de nuevo usuarios. Además los usuarios que se van a crear en el diseño del software puede que no sean los únicos que se crean a través del tiempo.


161


Editar el perfil de un usuario



Actores: Administrador del software.

Descripción: El resultado de este caso de uso es necesario ya que sin la opción de editar perfil de usuario los permisos no se podrían agregar o quitar. Generalmente a medida que las compañías crecen los perfiles de los empleados cambian y en este caso los permisos de sus usuarios también.

Evento desencadenador: Necesidad de editar un usuario Precondiciones: 2. Saber las necesidades nuevas.

Pos condiciones: 2. Usuario editado Flujo normal: 12.0

1. El administrador del software define que quiere editar del usuario. 2. El sistema le debe permitirle editar los usuarios. 3. Usuario editado.


Casos de uso incluidos: 1. Acceso denegado Prioridad: 10

Frecuencia de uso: Cada vez que se quiera editar un usuario. Políticas de CGC o del

negocio:


uso


Supuestos: El sistema debe permitir editar los usuarios. Por otro lado, si no se pudiera editar los usuarios siempre se tendrían que crear nuevos usuarios cuando, por ejemplo, este no necesite un permiso que le concedido desde su creación.


162


Generar factura para recarga



Actores: Líder o auxiliar de caja y bodega

Descripción: El resultado de este caso de uso es necesario ya que además de las facturas que se generan por ventas y reposiciones también hay que generar facturas para las ventas de recargas que hagan los lideres o auxiliares de caja y bodega.


Venta de una recarga

Precondiciones: 1. Tener recargas disponibles Pos condiciones: 1. Factura generada de la recarga

Flujo normal: 13.0 1. Atender las necesidades del cliente en relación a recargas 2. Recaudar valor de la recarga 3. El sistema debe generar una factura con los datos de la venta

Flujos alternativos: 13.1 1. Atender las necesidades del cliente en relación a recargas 2. Recargas no disponibles 3. Comprar más recargas a través de SiCaCom 4. Esperar la transferencia de las recargas 5. Recaudar valor de la recarga 6. El sistema debe generar una factura con los datos de la venta

Excepciones: 13.1.E.1. En caso de que las recargas de celular se acaben es necesario comprar más a través de SiCaCom. El sistema no tendría nada que ver aca el único inconveniente es que lentificaría el proceso de servicio al cliente recargas. Muy rara vez se queda sin recargas CGC ya que Comcel no cobra por compra sino por la cantidad de recargas que venda.


Frecuencia de uso: Cada vez que se venda una recarga. Se vende 120´000.000 al mes y PROCESO CLIENTE DE LA SALIDA 0.000 por punto en promedio. Es muy difícil saber la frecuencia ya que el valor de las recargas varía mucho.



uso

Servicio al cliente recargas.

Supuestos: El sistema va a soportar las funciones de caja, y como la venta de recargas esta dentro de las funciones de caja y para esto se necesita generar un factura, el sistema debe permitir generar esta factura y además incluir estos movimientos en el cierre de caja CGC.


163


Generar informe de inventarios de baja rotación




Descripción: El resultado de este caso de uso es necesario ya que las directivas de CGC necesitan esta información para hacerle seguimiento a las diferentes referencias de celular que ofrece Comcel

Evento desencadenador: Petición del informe por parte de las directivas de CGC Precondiciones:

Pos condiciones: 1. Informe generado Flujo normal: 14.0

1. Las directivas piden el informe 2. El sistema debe permitirle al coordinador administrativo la generación del informe de inventarios de baja rotación



Frecuencia de uso: Cuando las directivas lo pidan Políticas de CGC o del

negocio:


Este caso de uso no interactúa en ningún proceso. Este informe es el producto de uno de los requerimientos de las directivas de CGC.

Supuestos: El sistema de información no solo va a ser de a nivel operativo sino también a nivel administrativo permitiéndole así generar informes para la gerencia.

Diagrama de Caso de uso 14

164


Generar informe de planes vendidos




Descripción: El resultado de este caso de uso es necesario ya que las directivas de CGC necesitan esta información para analizar el comportamiento de las ventas.

Evento desencadenador: Petición del informe por parte de las directivas de CGC Precondiciones:

Pos condiciones: 1. Informe generado Flujo normal: 15.0

1. Las directivas piden el informe 2. El sistema debe permitirle al coordinador administrativo la generación del informe de planes vendidos.



Frecuencia de uso: Cuando las directivas lo pidan Políticas de CGC o del negocio:


Este caso de uso no interactúa en ningún proceso. Este informe es el producto de uno de los requerimientos de las directivas de CGC.

Supuestos: El sistema de información no solo va a ser de a nivel operativo sino también a nivel administrativo permitiéndole así generar informes para la gerencia.


165


Generar Kardex de CGC




Descripción: El resultado de este caso de uso es necesario ya que para el proceso de control de inventario es vital el cruce el inventario de saldos que envía Comcel con el Kardex de CGC.

Evento desencadenador: Solicitud de justificación de inventario por parte de Comcel Precondiciones: 1. Comcel debe haber empezado el proceso de control de inventarios

Pos condiciones: 1. Kardex de CGC generado Flujo normal: 16.0

1. Comcel envía la solicitud de justificación de inventario 2. El sistema debe permitirle al coordinador administrativo generar el Kardex de CGC

Flujos alternativos: Es una obligación llevar el Kardex en el PUC. El Kardex de inventarios es el libro auxiliar de la cuenta de inventarios. 16.1 1. Diariamente el sistema debe almacenar los movimientos del inventario.

Excepciones: Casos de uso incluidos:

Prioridad: 10 Frecuencia de uso: Cada vez que Comcel envíe la solicitud de justificación de inventario.



Control de inventarios.

Supuestos: El sistema va a manejar los inventarios de CGC por ende tiene que tener la opción de genera Kardex por CPS o de CGC.


166


Generar Kardex de CPS



Actores: Coordinador de CPS

Descripción: El resultado de este caso de uso es necesario ya que para el proceso de control de inventario es vital el cruce el inventario de saldos por CPS que envía el coordinador administrativo con el Kardex del CPS.

Evento desencadenador: Solicitud de justificación de inventario por parte del Coordinador administrativo Precondiciones: 1. El Coordinador administrativo debe haber empezado el proceso de control de

inventarios. Pos condiciones: 2. Kardex del CPS generado

Flujo normal: 17.0 1. Comcel envía la solicitud de justificación de inventario 2. El Coordinador administrativo desglosa la justificación de inventario por CPS. 2. El sistema debe permitirle al coordinador del CPS generar el Kardex del CPS



Frecuencia de uso: Cada vez que el coordinador administrativo envíe la solicitud de justificación de inventario. Políticas de CGC o del

negocio:


Control de inventarios.

Supuestos: El sistema va a manejar los inventarios de CGC por ende tiene que tener la opción de genera Kardex por CPS o de CGC.


167


Generar recibo de caja




Descripción: El resultado de este caso de uso es necesario ya que en el proceso “Ventas” y “Activaciones” es necesario generar recibos de caja después de pre ingresar los datos de la venta.

Evento desencadenador: Pre ingreso de los datos de la venta Precondiciones: 1. Datos de la venta pre ingresados en el sistema

Pos condiciones: 1. Recibo de caja generado Flujo normal: 18.0

1. El líder de activaciones pre ingresa los datos de la venta 2. Recaudo del valor de la venta 3. Generación de recibo de caja


Casos de uso incluidos: 23. Pre ingresar los datos de la venta o la reposición en el sistema 2. Asignar y activar el equipo en el sistema





uso

Ventas y activaciones.

Supuestos: El sistema va a manejar las cajas de CGC, de manera que debe tener la opción para generar recibos de caja con el fin de recaudar el valor de las ventas antes de activar los productos. Además de esta forma las facturas tendrán la información completa de venta.


168


Generar Factura




Descripción: El resultado de este caso de uso es necesario ya que tengo el proceso “ventas” como “activaciones” y “Servicio al cliente reposición” contienen una actividad que es generar factura.

Evento desencadenador: 1. Activación del producto 2. Formato de cambio de servicio diligenciado

Precondiciones: 1. Activación del producto 2. Formato de cambio de servicio diligenciado

Pos condiciones: 1. Factura generada Flujo normal: 19.0

1. El Líder de activaciones activa el producto 2. El asesor de venta lleva la copia del contrato a la caja 3. El sistema le debe permitir al Líder de caja y bodega generar la factura, y la información complementaria de la venta debe ser jalada con el numero del contrato o con la cedula de cliente.

Flujos alternativos: 19.1 1. El Líder o auxiliar de caja y bodega recauda el valor de la reposición 2. El sistema debe jalar los datos del cliente y generar la factura de acuerdo a la cedula del cliente.

Excepciones: 19.1.E.1 Cuando es reposición no hay necesidad de confirmar data crédito y por ende tampoco de hacer pre ingresos de la reposición porque la información del cliente ya está en el sistema o en su defecto en Poliedro.

Casos de uso incluidos: 2. Asignar y activar el equipo en el sistema Prioridad: 10

Frecuencia de uso: Promedio de ventas mensuales: 1600 Días hábiles al mes: 26 Numero de CPS: 10 1600/26 = 61,5/10 = 6,15 => 6 / día en promedio



uso

Ventas, Activaciones y Servicio al cliente reposición.

Supuestos: El sistema va a manejar las cajas de CGC, de manera que debe tener la opción para generar recibos de caja con el fin de recaudar el valor de las ventas antes de activar los productos. Además de esta forma las facturas tendrán la información completa de venta.


169


Ingresar inventario




Descripción: El resultado de este caso de uso se necesita ya que ingresando el inventario nuevo se alimentan los inventarios de cada CPS, y si los inventarios no se alimentan bien, todos los procesos se ven afectados (Menos servicio al cliente recargas)

Evento desencadenador: Remisión y factura de Comcel Precondiciones: 1. La remisión y factura del pedido ya debe estar en poder de CGC al igual que los equipos

ya deben estar repartidos en los CPS para ese momento. Pos condiciones: 1. Inventario nuevo ingresado completamente

Flujo normal: 20.0 1. Llega la remisión y la factura que Comcel proporciona con la mercancía del pedido. 2. El sistema debe permitirle al coordinador administrativo ingresar el nuevo inventario, discriminando de que bodega de Comcel viene y a que Bodega y CPS de CGC va.



Frecuencia de uso: Cada vez que llegue un pedido. Políticas de CGC o del

negocio:

Supuestos: El sistema va a manejar los inventarios, por lo tanto tiene que tener una opción para alimentar el inventario con los pedidos a Comcel.


uso


Notas y TBD: En este momento no saben si darle también este permiso a los líderes de caja y bodega ya que ellos podrían alimentar el inventario de referencias ya ingresadas y el coordinador administrativo podría alimentar únicamente las referencias nuevas.



Sistema

**

20. Ingresarinventario

Comcel**

170


Ingresar solicitud de equipos o de Sim Card



Actores: Coordinador de CPS

Descripción: El resultado de este caso de uso es necesario ya que en el proceso “Compra de equipos y Sim Card” este usuario tiene que hacer solicitudes al coordinador administrativo y la mejor manera de hacerlo es a través del sistema y que este mismo consolide las solicitudes de todos los coordinadores de CPS.


Coordinador administrativo inicia proceso “Compra de equipos y Sim Card”

Precondiciones: 1. El Coordinador administrativo tiene que haber empezado el proceso “Compra de equipos y Sim Card”

Pos condiciones: 1. Solicitud ingresada al sistema Flujo normal: 21.0

1. El Coordinador administrativo le hace saber a los Coordinadores de CPS que van a hacer un pedido de equipos y Sim Card a Comcel 2. El sistema debe permitirle al Coordinador de CPS el ingreso de la solicitud al sistema

Flujos alternativos: 21.1 1. Coordinadores de CPS hacen solicitudes para hacer un pedido 2. El Coordinador administrativo le hace saber a los Coordinadores de CPS que van a hacer un pedido de equipos y Sim Card a Comcel 3. El sistema debe permitirle al Coordinador de CPS el ingreso de la solicitud al sistema.

Excepciones: 21.1.E.1. Cuando las necesidades de los CPS se acumulan y requieren de un pedido antes de que el Coordinador administrativo inicie el proceso “Compra de equipos y Sim Card” el evento desencadenador es ahora las necesidades acumuladas de los CPS.

Casos de uso incluidos: 24. Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas Prioridad: 5

Frecuencia de uso: Cada vez que lo diga el Coordinador administrativo o cada vez que se requiera. Políticas de CGC o del

negocio:


uso

Compras de equipos y Sim Card.

Supuestos: El sistema va a manejar los inventarios de CGC y parte de manejar los inventarios es la planeación de los pedidos de materia prima, que en este caso serían los equipos y las Sim Card, de manera que el sistema debe permitirle a los coordinadores de CPS hacer los pedido a través del mismo para que la consolidación de los pedidos sea precisa.

171


Coordinador de CPS

Sistema

*

*

21. Ingresar solicitudde equipos o de Sim

CardCoordinador administrativo

Staff del CPS

*

*

*

*

24. Recibir las solicitudes deequipos y Sim Card de los

todos los CPS consolidadas

«uses»

172


Iniciar sesión



Actores: Coordinador administrativo, Líder o auxiliar de caja y bodega, Líder de activaciones, Coordinador

CPS, Líder de servicio, Planillador, Administrador de Software. Descripción: El resultado de este caso de uso es necesario ya que los usuarios del sistema tienen que iniciar

su sesión para llevar a cabo alguna transacción en el sistema. Además es el opuesto de cerrar sesión ya que si hay que cerrar cada vez que se deje el puesto de trabajo cuando se retomen las actividades tiene que haber una opción para iniciar sesión y viceversa.


Inicio o retoma de las actividades del día

Precondiciones: 1. Sesión finalizada. Pos condiciones: 2. Sesión iniciada.

Flujo normal: 22.0 1. Cerrar sesión 2. Abandonar el puesto de trabajo 3. Iniciar sesión



Frecuencia de uso: Las veces que se necesite Políticas de CGC o del

negocio: Política de CGC: Cualquier empleado que tenga acceso a cualquier software de apoyo de la compañía, al dejar su puesto por cualquier razón, tiene cerrar sesión de todos los softwares. A su vez cada vez que vuelva al puesto de trabajo tiene que tener la opción de volver a iniciar sesión.


uso


Supuestos: Los usuarios del sistema tienen que tener la opción de iniciar sesión con una clave secreta.


Coordinador administrativo, Líder o auxiliarde caja y bodega, Líder de activaciones,

Coordinador CPS, Líder de servicio, Planillador,Administrador de Software.

Sistema

22. Iniciar sesión**

173


Pre ingresar los datos de la venta en el sistema



Actores: Líder de activaciones

Descripción: El resultado de este caso de uso es necesario ya que agilizar el proceso de venta y activaciones al brindarle información rápida y acertada al Líder de caja y bodega para generar los recibos de caja.


Verificación de datos del contrato

Precondiciones: 1. Documentos y formatos diligenciados de la venta y verificados por el Líder de activaciones. Pos condiciones: 1. Datos de la venta pre ingresados al sistema

Flujo normal: 23.0 1. El asesor de ventas llega al área de activaciones con los documentos y formatos diligenciados de la venta y se los entrega al Líder de activaciones 2. El líder de activaciones verifica los formatos diligenciados y los documentos necesarios para le venta 3. Si los formatos y los documentos están bien, el sistema le debe permitir al activador pre ingresar los datos de la venta.

Flujos alternativos: Excepciones: Casos de uso

incluidos: 18. Generar recibo de caja.





uso

Ventas y Activaciones.

Supuestos: Como el sistema va a ayudar a transportar de un lado a otro la información con más rapidez, la idea es que los líderes de activaciones hagan un pre ingreso de los datos de la venta y ayuden a descongestionar el flujo de clientes en caja y a que el Líder o auxiliar de caja y bodega se toma mucho tiempo ingresando los datos al sistema actual recaudando el valor de la venta al mismo tiempo.


174


Recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas




Descripción: El resultado de este caso de uso es necesario ya que el coordinador administrativo tiene que estar constantemente consolidando las solicitudes de los coordinadores de CPS para enviar el pedido a Comcel y la mejor forma de no cometer errores en esta actividad y de agilizarla es que el sistema las consolide y el Coordinador administrativo las analice.


Los coordinadores de CPS envía las solicitud de equipos o de Sim Card

Precondiciones: 1. Solicitudes de los Coordinadores de CPS enviadas Pos condiciones: 1. Solicitudes consolidadas

Flujo normal: 24.0 1. Los coordinadores de CPS envía las solicitudes de equipos y de Sim Card a través del sistema 2. El sistema consolida las solicitudes 3. El sistema debe permitirle al coordinadore administrativo recibir las solicitudes de equipos y Sim Card de los todos los CPS consolidadas


Casos de uso incluidos: 21. Ingresar solicitud de equipos o de Sim Card Prioridad: 5

Frecuencia de uso: En el momento en que los coordinadores de CPS envíen las solicitudes de equipos y Sim Card Políticas de CGC o del

negocio:


uso


Supuestos: El sistema va a manejar los inventarios de CGC y parte de manejar los inventarios es la planeación de los pedidos de materia prima, que en este caso serían los equipos y las Sim Card, de manera que el sistema debe permitirle a los coordinadores de CPS hacer los pedido a través del mismo para que la consolidación de los pedidos sea precisa.

175


176


Recordar cambio de clave por seguridad




Coordinador CPS, Líder de servicio, Planillador, Administrador de Software. Descripción: El resultado de este caso de uso es necesario ya que si no se le recuerda a los usuarios

cambiar la clave de acceso pueden presentarse oportunidades para fraudes o para malentendidos con los usuarios del sistema.

Evento desencadenador: Fin del mes Precondiciones: 1. Fin del mes

Pos condiciones: 1. Recordatorio hecho al usuario Flujo normal: 25.0

1. Fin de mes 2. El sistema debe recordarle al usuario cambiar su clave de acceso

Flujos alternativos: Excepciones: 25.0.E.1. Si se presenta el caso en que el usuario no inicie sesión el ultimo día del mes, el

sistema debe recordarle al usuario la siguiente ves que inicie sesión. Casos de uso incluidos:

Prioridad: 10 Frecuencia de uso: 1 / mes


Todos los empleados que tengan usuarios para cualquier software de apoyo de los procesos de CGC tienen que cambiar sus claves como mínimo cada mes.



Supuestos: Todos los sistemas de información deben tener medidas de seguridad con los usuarios.


177


Transferencia de mercancía de un CPS a otro



Actores: Coordinador de CPS.

Descripción: El resultado de este caso de uso es necesario ya que si algún CPS (1) no tiene un producto y otro CPS (2) lo tiene pero no lo va a usar en el corto plazo, este producto se puede trasladar digital y físicamente al CPS (1)

Evento desencadenador: Inventario agotado en un CPS (1) Precondiciones: 1. Mercancía disponible en otro CPS (2)

Pos condiciones: 1. Mercancía trasladada Flujo normal: 26.0

1. Mercancía agotada en un CPS (1) 2. Mercancía disponible en otro CPS (2) 3. El sistema debe permitir al coordinador de CPS trasladar la mercancía del CPS (1) al CPS (2)

Flujos alternativos: Excepciones: 26.0.E.1. En caso de que haya inventario disponible en otro CPS (2) pero que vaya a ser

usado en el corto plazo la transferencia se cancela. Esta confirmación se hace vía celular. Casos de uso incluidos: 6. Consultar disponibilidad de inventario

Prioridad: 10 Frecuencia de uso: Cada vez que un CPS se quede sin mercancía.


Todos los Coordinadores deben colaborar con estas transferencias ya que en parte de ellas dependen las ventas de todo el CPS.


Activaciones, Ventas y Servicio al cliente reposición.

Supuestos: El sistema va a manejar los inventarios de CGC y parte de esto son las transferencias de inventario de un punto al otro. (Movimiento de inventario)


Coordinador de CPS

Sistema

*

*

26. Transferencia demercancía de un CPS a

otro

6. Consultardisponibilidad de inventario

*

*«extends»

178

Anexo 32: Estado de resultados 2008 Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total Ventas Netas

355.655.832

275.410.679

266.639.690

258.044.582

286.207.039

244.900.923

358.176.119

338.833.386

327.465.723

352.172.431

289.662.480

434.092.118

3.787.261.002

Comisiones

391.314.124

357.510.125

326.146.793

317.140.653

316.693.088

370.567.043

309.668.188

291.089.291

357.152.789

336.801.704

334.168.047

319.968.054

4.028.219.899

Total Ventas

746.969.956

632.920.804

592.786.483

575.185.235

602.900.127

615.467.966

667.844.307

629.922.677

684.618.512

688.974.135

623.830.527

754.060.172

7.815.480.901

Devolucion Y Descuentos

20.172.637

36.762.328

18.688.346

11.964.849

14.103.424

42.139.973

10.976.888

21.008.074

17.699.976

22.677.461

23.006.989

42.046.694

281.247.639

Total Devolucion Ventas

20.172.637

36.762.328

18.688.346

11.964.849

14.103.424

42.139.973

10.976.888

21.008.074

17.699.976

22.677.461

23.006.989

42.046.694

281.247.639

Total Ventas Netas

726.797.319

596.158.476

574.098.137

563.220.386

588.796.703

573.327.993

656.867.419

608.914.603

666.918.536

666.296.674

600.823.538

712.013.478

7.534.233.262

Costo de Ventas

316.886.745

232.282.677

230.953.281

226.424.698

251.167.882

216.899.121

323.446.964

305.099.092

298.192.307

319.357.615

247.630.848

350.255.799

3.318.597.029

Comis. Postpago y up grade

39.903.278

53.389.168

46.976.319

30.131.969

40.950.574

35.769.012

99.543.210

75.090.726

37.738.278

95.984.512

113.627.615

60.976.841

730.081.502

Comisi. kit financiado

-

-

-

-

-

-

-

-

-

-

-

-

-

Costo Sancion Inventarios

63.229.300

49.919.600

37.589.300

32.726.000

33.826.650

38.933.800

24.138.350

28.476.750

24.048.980

26.936.039

28.250.500

-

388.075.269

Costo Sancion Activaciones

2.000.352

2.155.709

1.397.900

1.524.744

1.773.636

1.971.296

1.448.441

1.480.057

1.274.335

1.160.019

1.109.962

832.678

18.129.129

Comis. Postpago Diversas

13.938.285

3.006.255

2.766.650

3.345.089

3.617.318

4.696.180

6.379.704

4.572.452

4.905.757

10.918.105

7.580.822

5.030.054

70.756.671

Bonificaciones Recaudos

1.000.000

-

430.000

85.000

899.222

-

836.201

-

2.475.961

2.063.444

2.167.403

1.826.387

11.783.618

Comis. Tarj. Prepago

-

-

-

-

-

-

-

-

-

-

-

32.261.958

32.261.958

Otras 522.834

4.381.758

1.030.000

1.800.000

1.580.450

2.033.439

1.157.051

1.600.075

1.563.557

-

-

-

15.669.164

Costo de Comisiones

-

-

-

-

-

-

-

-

-

-

-

-

-

179

Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total Total Costo de Ventas

120.594.049

112.852.490

90.190.169

69.612.802

82.647.850

83.403.727

133.502.957

111.220.060

72.006.868

137.062.119

152.736.302

100.927.918

1.266.757.311

Utilidad Operacional

437.480.794

345.135.167

321.143.450

296.037.500

333.815.732

300.302.848

456.949.921

416.319.152

370.199.175

456.419.734

400.367.150

451.183.717

4.585.354.340

Gastos Operacionales

289.316.525

251.023.309

252.954.687

267.182.886

254.980.971

273.025.145

199.917.498

192.595.451

296.719.361

209.876.940

200.456.388

260.829.761

2.948.878.922

Gastos Operacionales de Ventas

216.113.776

219.670.507

221.312.777

235.678.560

220.694.321

239.313.731

267.918.578

241.624.483

268.318.549

252.817.539

249.562.983

262.657.930

2.895.683.734

Utilidad Operacional

73.202.749

31.352.802

31.641.910

31.504.326

34.286.650

33.711.414

(68.001.080)

(49.029.032)

28.400.812

(42.940.599)

(49.106.595)

(1.828.169)

53.195.188

+ Ingresos No Operacionales

20.689.470

26.262.810

19.364.157

26.597.058

18.285.828

19.917.714

21.016.990

22.023.531

36.610.808

21.731.314

22.506.107

26.654.497

281.660.285

Gastos bancarios

-

1.849.600

311.734

23.811

-

-

124.912

311.734

31.034

37.534

-

620.766

3.311.125

Comisiones

1.220.888

1.000.876

475.483

1.534.264

361.436

343.401

432.751

410.283

1.776.444

1.599.972

3.419.971

638.538

13.214.308

intereses 10.300.346

10.147.877

11.543.415

9.272.697

8.940.978

8.884.721

7.970.651

7.589.726

7.370.863

7.483.287

4.097.512 -

93.602.073

Descuentos comerciales condicionados

-

33.000

-

-

-

-

580.000

265.350

-

-

-

-

878.350

Gastos financieros

11.521.234

13.031.353

12.330.632

10.830.772

9.302.414

9.228.122

9.108.314

8.577.093

9.178.341

9.120.794

7.517.482

1.259.304

111.005.856

Gastos extraordinarios

3.393.703

2.753.498

2.534.795

2.565.659

2.385.325

2.675.383

3.040.511

2.690.256

2.817.247

2.659.984

2.072.680

2.988.298

32.577.339

Gastos diversos

-

-

-

-

-

-

-

-

-

-

-

-

-

- Gastos Financieros y Extraordinarios

14.914.937

15.784.851

14.865.428

13.396.431

11.687.739

11.903.505

12.148.826

11.267.348

11.995.588

11.780.778

9.590.162

4.247.602

143.583.196

Utilidad Antes de Ajustes

78.977.282

41.830.761

36.140.640

44.704.953

40.884.739

41.725.623

(59.132.915)

(38.272.850)

53.016.032

(32.990.063)

(36.190.650)

20.578.726

191.272.277

180

Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total -Provision Impuesto de Renta

7.267.913

5.961.584

5.732.238

5.632.203

5.887.967

5.733.279

5.632.203

5.480.231

5.665.043

5.665.043

-

-

58.657.704

-Depreciaciones Operativo

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

8.354.280

100.251.360

Utilidad Neta del Período

63.355.089

27.514.897

22.054.122

30.718.470

26.642.492

27.638.064

(73.119.398)

(52.107.361)

38.996.709

(47.009.386)

(44.544.930)

12.224.446

32.363.213

181

Anexo 33: Pantallas propuestas A continuación se ilustran los pre-diseños de las pantallas más importantes del sistema llevados a cabo en el software LABVIEW. Es necesario reevaluarlas en las fases de construcción y transición. Pantalla para caso de uso 23. Pre ingresar los datos de la venta en el sistema: Esta es la primera pantalla que debería ver el líder de activaciones antes de pre ingresar los datos de la venta. Si todas estas condiciones se cumplen, entonces, el sistema debería llevar al líder de activaciones a la pantalla de pre ingreso de la venta completa (Jalando los datos ya diligenciados en esta pantalla).

182

Pantalla para caso de uso 20. Ingresar inventario: Antes de ingresar el inventario el sistema debería habilitar al usuario del coordinador administrativo para crear nuevas referencias de tal forma que el trabajo de los líderes de caja y bodega sea solo ingresar el inventario y no generar nuevas referencias de nuevos productos.

Pantalla para caso de uso 20. Ingresar inventario: Luego de que el coordinador administrativo crea las nuevas referencias, es poco probable que los líderes o auxiliares de caja y bodega cometan errores ingresando el inventario. Es importante aclarar que el espacio “descripción de material” no sería editable. Por esta razón el espacio “material” podría tener opciones para que se puedan ingresar las referencias que hayan sido creadas por el coordinador administrativo.

183

Pantalla para caso de uso 18: Generar recibo de caja: Esta es la pantalla que podría ver el líder o auxiliar de caja y bodega para crear un recibo de caja. Los únicos espacios editables serían “contrato”, “cliente” y “tipo de pago”. Con los dos primeros, el sistema debería buscar los datos de la venta y jalarlos a la pantalla para generar el recibo de caja. Todos estos datos se generarían cuando el líder o auxiliar de caja presione el botón ok en contrato o en cliente. El botón ok de abajo es para ingresar el pago e imprimir el recibo de caja automáticamente. Por último, a raíz de la sugerencia de los líderes de activaciones, se creó el espacio de tipo de pago ya que es necesario para llevar a cabo sus actividades.

184

Pantalla para caso de uso 26: Transferencia de mercancía de un CPS a otro.

Pantalla para caso de uso 21. Ingresar solicitud de equipos o de Sim Card: Esta es la pantalla que podrían ver los coordinadores de CPS para ingresar una solicitud de equipos o de Sim Card al sistema.

Pantalla para caso de uso 14. Generar informe de inventarios de baja rotación: Esta es la primera pantalla que podría ver el coordinador administrativo. Luego de ingresar estos datos, el sistema le debería arrojar el informe de inventarios de baja rotación.

185

Pantalla para caso de uso 15. Generar informe de planes vendidos: Esta es la primera pantalla que podría ver el coordinador administrativo. Luego de ingresar estos datos, el sistema le debería arrojar el informe de planes vendido completo.

Pantalla para caso de uso 6. Consultar disponibilidad de inventario: En esta pantalla se puede apreciar que los usuarios pueden filtrar la disponibilidad por varias variables. De hecho se dejó una de estas variables en blanco haciendo referencia a que se pueden agregar más.

186

Anexo 34. Proyecto de grado

CONTENIDO

1. TITULO 189 2. PLANTEAMIENTO DEL PROBLEMA 189

2.1. Antecedentes .........................................................................................................................189

2.2. Planteamiento del problema ..................................................................................................191 2.2.1. Histórico de ventas .........................................................................................................191

2.3. Procesos que se llevan a través del software actual ............................................................194

3. JUSTIFICACIÓN DEL PROYECTO 198 4. MARCO TEÓRICO 199

4.1. Procesos ................................................................................................................................199 4.1.1. Componentes básicos de un proceso ............................................................................199 4.1.2. Clasificación de los procesos .........................................................................................199 4.1.3. Actores que intervienen en cada proceso ......................................................................200 4.1.4. ¿Cómo identificar un proceso? .......................................................................................200 4.1.5. Etapas básicas de los procesos .....................................................................................200 4.1.6. Aspectos relevantes .......................................................................................................200

4.2. Sistemas de información .......................................................................................................201 4.2.1. Principales tipos de sistemas en las organizaciones .....................................................202

4.3. Requerimientos .....................................................................................................................204 4.3.1. Especificaciones de requerimientos ...............................................................................204 4.3.2. Requerimientos funcionales y no funcionales ................................................................204

4.4. Requerimientos del usuario y del sistema ............................................................................204 4.4.1. Requerimientos del usuario ............................................................................................205 4.4.2. Los requerimientos del sistema ......................................................................................205

4.5. Casos de uso .........................................................................................................................205 4.5.1. Definiciones Básicas .......................................................................................................205 4.5.2. Descripción de los Casos de Uso ...................................................................................207

5. OBJETIVO GENERAL 208 6. OBJETIVOS ESPECÍFICOS 208 7. METODOLOGÍA 209 8. RESTRICCIONES 211 9. TABLA DE CONTENIDO PROPUESTA DEL TRABAJO FINAL 211 10. CRONOGRAMA 212 11. RECURSOS 213 BIBLIOGRAFIA 214

187

LISTA DE TABLAS

Pág.

Tabla 1. Empleados……………………………………………………………………………….189 Tabla 2. Histórico de ventas……………………………………………………………………...191 Tabla 3. Problemas en proceso (software actual)……………………………….………….....195 Tabla 4. Sanciones impuestas por COMCEL…………………………………………………..196 Tabla 5. Problemas en procesos manuales………………………………………………….....197 Tabla 6. Total costos adicionales………………………………………………………………..197 Tabla 7. Tipos de sistemas………………………………………………………………………..202 Tabla 8. Ejemplo descripción de caso de uso…………………………………………………..207

188

LISTA DE GRAFICOS

Pág.

Grafico 1. Organigrama…………………………………………………………………………..190 Grafico 2. Comportamiento anual de recaudos………………………………………………..192 Grafico 3. Comportamiento anual ventas totales ……………………………………………...193 Grafico 4. Comparativo cuotas – ventas totales………………………………………………193 Grafico 5. Comparativo cuotas – recaudos reales……………………………………………194 Grafico 6. Ilustración procesos………………………………………………………………….199 Grafico 7. Ejemplo grafico caso de uso………………………………………………………..206

189

1. TITULO DETERMINACIÓN DE LOS REQUERIMIENTOS FUNCIONALES PARA UN SOFTWARE QUE INTEGRE LOS PROCESOS OPERATIVOS DEL DISTRIBUIDOR CGC COMCEL 2. PLANTEAMIENTO DEL PROBLEMA 2.1. Antecedentes En enero de 1994 se abrió una de las licitaciones más importantes en la historia de Colombia. Se trataba de la adjudicación de la telefonía celular. La licitación consistía de tres zonas de operación del servicio: Bogotá y la Región Oriental; Medellín, Cali y el Occidente; y la Costa Atlántica. En el segundo semestre del mismo año ya se sabía quiénes iban a ser los operadores que obtuvieron los permisos: Celumóvil, Comcel, Cocelco, Occel, Celumovil de la Costa y Celcaribe. Desde el principio Comcel fue uno de los mejores operadores y el que atraía mayor número de clientes. Para simplificar la gestión de estos operadores se crearon los distribuidores, quienes se encargan de la comercialización de los planes ofrecidos por COMCEL y recaudo del dinero de las facturas generadas por el consumo de los usuarios. Esto los libera de muchas de las actividades comerciales del negocio (exceptuando mercadeo, imagen, publicidad y servicio al usuario). Uno de estos distribuidores es CGC (Comunicaciones Globales Colombia S.A.), empresa objeto de estudio en este trabajo de grado. ¿Qué es Comunicaciones Globales Colombia? Es un distribuidor de Comcel que firmó en Marzo de 2003 un contrato a término indefinido para comercializar en forma exclusiva sus productos (planes, equipos, tarjetas prepago), prestar servicio a sus clientes (cambios de plan, reposiciones, cambios de número celular, cesiones de contrato, etc.) y recaudar facturación de clientes en la región centro - oriental de Colombia, comprometiéndose también a cumplir con unas metas u objetivos que Comcel asigna mensualmente (Promedio mes 2008 – 7.000 nuevos clientes). Teniendo en cuenta que el Departamento de Cundinamarca y Distrito Capital representa el 50% del potencial de clientes del mercado celular en Colombia, CGC definió concentrar sus operaciones en esta zona, buscando así crecer en el futuro en los Departamentos de Boyacá, Casanare, Santander, Norte de Santander, Tolima, Huila y Antiguos Territorios Nacionales. A la fecha, CGC cuenta con 11 Centros de Pago y Servicio (CPS), 9 en Bogotá, 1 en La Vega y 1 en Villeta; adicionalmente, cuenta con 230 puntos de subdistribución repartidos en todos los puntos de la ciudad de Bogotá. Los empleados en cada CPSs y en general de toda la empresa son contratados a través de TECNOVA, una compañía de selección de personal y temporalidad, encargada de vincular el personal a la empresa; este personal se distribuye de la siguiente forma: Tabla 1. Empleados

TIPO DE PERSONAL CANTIDAD Vendedores 35 Administrativos y operacionales 44 Fuente: Departamento contable Comunicaciones Globales Colombia Estos empleados, exceptuando los vendedores que están distribuidos en los diferentes CPSs, están organizados tal como los muestra el grafico 1 “organigrama”:

Gráfico 1. O

Fuente: Au A continuacompañía ( Gerencia glos procesooperación a Contabilida Revisoría f Coordinaciimportantes Coordinaci Activacioneencargada Coordinaci Verificador Líder de sencargada

Organigrama

utor del prese

ación se exp(en la Figura

general: Al igos, velar por arroje ganan

ad: Se encarg

fiscal: Es el á

ón comercias en los mism

ón administr

es: Consistede activar la

ón de tesore

r de informac

servicio: Es de atender l

a

ente trabajo

lican algunaa 1 se puede

gual que en los recursos

ncias.

ga de la con

área encarga

al: Es el ármos.

rativa: Vela p

e en una peras líneas ven

ería: Lleva a

ción: Provee

una personlos clientes q

as de las áren ver el núm

la mayoría ds de la comp

tabilidad de

ada de la aud

rea encarga

por el sosten

rsona (o mándidas a nom

cabo la gest

visitas domic

na (o más que necesita

eas y cargosmero de perso

de las compapañía y llevar

CGC.

ditoria de la c

da de adm

imiento de to

ás personas mbre de CGC

tión de tesore

ciliarias de lo

personas dn un servicio

s mencionadonas por áre

añías, la gerr a cabo su g

contabilidad

inistrar cada

oda la red de

dependiendC.

ería de CGC

os clientes po

dependiendo o posventa.

dos en el orga entre paré

rencia se engestión de ta

de CGC.

a CPS y to

e CPSs.

do de la acti

C.

otenciales.

de la activ

ganigrama dntesis).

carga de lidal manera qu

omar decisio

ividad del C

vidad del C

190

e la

erar ue la

ones

CPS)

CPS)

191

Como distribuidor autorizado de Comcel, CGC está habilitado para proponer y abrir al público CPSs. Esto les permite tener establecimientos con un servicio total que, basados en el flujo constante de clientes pagando facturas (en la actualidad, 60,000 mensuales), aseguran un potencial de clientes suficiente para mantenerse como el segundo distribuidor de planes pospago en la zona Centro del país. Los CPSs de CGC, ubicados estratégicamente por toda la ciudad (Cedritos, 7 de Agosto, Galerías, Centro Av. 19, San Andresito Calle 13, Restrepo, Venecia, Kennedy y Engativá), se han convertido en centros de acopio, venta y activación de las ventas generadas por los subdistribuidores. Los subdistribuidores son microempresas que comercializan los productos Comcel para luego radicar los contratos en los puntos de acopio donde se analizan y activan los planes vendidos (Los subdistribuidores depende directamente de CGC no de Comcel). La activación de los planes y la prestación del servicio se lleva a cabo utilizando el software proporcionado por Comcel, llamado BSCS –Bussiness support and Customer Service (Soporte de negocio y servicio al cliente)-, al cual tienen acceso los distribuidores con el uso de Internet a través de una aplicación llamada POLIEDRO. El recaudo de facturas de clientes se tiene como un producto adicional, basados en que CGC tiene como política desde sus inicios, abrir al público solamente CPS’s (Centros de Pago y Servicio). 2.2. Planteamiento del problema La buena gestión de las directivas de CGC y el profundo conocimiento en telefonía celular por parte del gerente general (ex directivo de COMCEL) le han permitido a CGC permanecer siempre en el Top 5 en ventas entre los distribuidores de Comcel Zona Centro Oriente. Como lo demuestran las cifras, el crecimiento en los cinco años transcurridos ha sido acelerado, tanto en puntos de venta directos como en subdistribuidores y por supuesto en ventas.

2.2.1. Histórico de ventas Tabla 2. Histórico de ventas MES

ITEM

VENTAS (unidades)

RECAUDO

POSTP. KITS PWP TOTAL TOTAL 2003

Cuota Comcel 1117 897 1097 3111 30.000 Ventas reales 1060 1320 1067 3447 57.557 Cumplimiento (%) 95% 147% 97% 111% 192% Estructura de ventas 31% 38% 31% 100%

TOTAL 2004


TOTAL 2005


TOTAL Cuota Comcel 20202 77288 45685 143175 513.792

192

MES

ITEM

VENTAS (unidades)

RECAUDO

POSTP. KITS PWP TOTAL 2006 Ventas reales 18715 44004 44287 107006 523.136

Cumplimiento (%) 93% 57% 97% 75% 102% Estructura de ventas 17% 41% 41% 100%

TOTAL 2007


TOTAL 2008

Cuota Comcel 16085 20620 42745 79450 726.294 Ventas reales a Oct. 2008

13565 11441 45684 70690 656.673

Cumplimiento (%) 84% 55% 107% 89% 90% Estructura de ventas 19% 16% 65% 100%

Fuente: Departamento contable Comunicaciones Globales Colombia COLUMNA SIGNIFICADO POSTP. (POSTPAGO) Ventas postpago KITS (PREPAGO) Ventas prepago PWP(prepaid welcome back plan)

Plan de prepago para usuarios provenientes de otro operador.

Gráfico 2. Comportamiento anual de recaudos


COMPORTAMIENTO ANUAL DE RECAUDOS

4.643 5.513 5.180 5.283 5.083 6.8507.408 8.799 11.768 12.38421.208 21.208

22.525 21.863 23.209 25.415 25.665 27.67226.532 25.24328.177 27.258

28.492 31.28930.740 33.308 31.991 34.131 34.771

37.02736.017 35.79442.479 40.747

43.161 40.26644.807 46.010 45.290

49.010 49.32950.22647.799 43.975

51.332 48.130

52.230 53.239

59.698 60.105 59.438

65.886 60.311

67.30466.031

62.550

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

Ene Feb Mar Abr May Jun Jul Ago Sep Oct Nov Dic

2003 2004 2005 2006 2007 2008

193

Gráfico 3. Comportamiento anual ventas totales

Fuente: Autor del presente trabajo Gráfico 4. Comparativo cuotas – ventas totales


COMPORTAMIENTO ANUAL VENTAS TOTALES

468 418 368 425 445 1.3231.956 1.447 1.033 1.405 2.210 3.0244.341 3.844 4.548 4.132

5.468

12.493

6.718 7.347 7.664

13.354

7.8459.364

110569490

12945

99768618

22891

9.4057.207

11.072

8.705

8.269

8.832

9.803

8.603

8.850

8.369 7.122

10.769

6.6407.454

7.141

6.199

6.374

6.885

7.856

6.455

5.699

5.6605.793

8.922

7.2227.331

0

10000

20000

30000

40000

50000

60000

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov Dic

2003 2004 2005 2006 2007 2008

COMPARATIVO CUOTAS - VENTAS TOTALES

0

20.000

40.000

60.000

80.000

100.000

120.000

140.000

160.000

180.000

AÑO

VENTAS REALES 3.447 45.901 127.268 107.006 81.078 70.690

CUOTA 3.111 41.129 156.252 143.175 100.143 79.450

2003 2004 2005 2006 2007 2008

194

Gráfico 5. Comparativo cuotas – recaudos reales

Fuente: Autor del presente trabajo Al analizar las gráficas de las ventas totales y de los recaudos, anuales y mensuales (gráficas 1-4), se puede apreciar que los recaudos siempre han mostrado un crecimiento constante y aunque las ventas totales muestran un decrecimiento luego del año 2005, este decrecimiento se debe únicamente a la saturación del mercado, lo que quiere decir que ni está fallando la fuerza de ventas ni están disminuyendo por razones propias de CGC. Este crecimiento llevó a la Compañía en el año 2006 a buscar en el mercado local una solución tecnológica que les permitiera automatizar los procesos. En este proceso de selección, la compañía le prestó atención a un ex directivo de Comcel que estaba liderando el desarrollo de un software que integraba los procesos operativos de los distribuidores de Comcel, de forma que se interesaron en su compra. Luego de comprarlo por $20’000.000 e implementarlo, se dieron cuenta que debieron tomarlo en arrendamiento para llevar a cabo las pruebas necesarias. Desafortunadamente el hecho de no haber realizado pruebas con el software (Software actual) les ocasionó algunos inconvenientes. A continuación se desglosarán los procesos que soporta el software luego de su implementación y aunque han pasado dos años aun no muestra que sea la solución. El software cuenta con dos módulos: Caja e Inventarios, los cuales están integrados. 2.3. Procesos que se llevan a través del software actual INVENTARIOS Y CAJAS

• Ingreso de inventario Consiste en el ingreso de la información del producto en cada bodega de cada CPS, relacionándola con la clase de plan para el cual fue adquirido.

• Activación de planes

COMPARATIVO CUOTAS - RECAUDOS REALES

0

100.000

200.000

300.000

400.000

500.000

600.000

700.000

800.000

AÑO

CA

NT.

CUOTA 30.000 211.500 358.000 513.792 604.083 726.294

REAL 57.557 224.764 368.959 523.136 669.447 656.673

2003 2004 2005 2006 2007 2008

195

Este es uno de los procesos más sencillos; consiste únicamente en el soporte del proceso de activaciones, brindando una pequeña base de datos que liga el equipo con el plan, aunque en la mayoría de los casos no la genera de manera correcta.

• Proceso de caja Consiste en la liquidación de los planes con sus respectivos equipos, cálculo del IVA y generación de algunos reportes.

Luego de la implementación del software actual, CGC optó por reparametrizarlo de una manera más eficiente debido a algunos problemas que presentó el software (ver Tabla 3). Esta reparametrización culminó sin mucho éxito, razón que los llevó a pensar que un desarrollo de software propio es la solución. Debido a la rigidez e ineficiencia del software actual se presentaron nuevos problemas más preocupantes que los problemas que existían antes de pensar en integrar los procesos. Uno de estos problemas fue que el software actual distorsionó los costos de los inventarios. En un principio cuando el software arrojó los primeros informes no fue preocupante, ya que como las personas no estaban capacitadas en su totalidad para manipular el software pensaron que el error había sido humano. Luego de valorizar los inventarios físicos, arrojaron un valor por debajo del valor del inventario en el balance general. En ese momento el error se hizo más notable pues el software acual estaba subvalorando el costo de inventario, por ende arrojó una utilidad muy alta para los años 2006 y 2007. Lo realmente preocupante de este error es que al final del ejercicio 2006 y 2007 la compañía repartió utilidades irreales a los socios, generando iliquidez en la misma. A la fecha, después de mucho trabajo en el año 2008, se ha logrado ajustar el inventario a valores reales: de hecho, Noviembre es el último mes de ajuste. Las siguientes tablas enuncian y explican algunos de los problemas más importantes que se presentaron luego de la implementación del software actual, y otros problemas que podrían tener una solución potencial con un desarrollo de software propio: Tabla 3. Problemas en proceso (software actual) PROCESO EN EL SOFTWARE ACTUAL

PROBLEMA QUE GENERÓ

IMPACTO

Cálculo del costo de venta Distorsión de los costos de inventarios

Costo de Inventario subvalorado. Es decir que la empresa tenía un inventario de $80’000.000 y el software calculaba un valor de $400’000.000. Esta distorsión del costo de inventario se presento entre los años 2006 y 2008.

Caja e Inventarios Retraso para la legalización de contratos en Comcel

Sanciones y demoras para el pago de comisiones por parte de Comcel. Contrato: $ 4000 por cada día que CGC se demore en legalizarlo. En el cuadro siguiente se puede apreciar la magnitud de estas penalizaciones.

196

PROCESO EN EL PROBLEMA QUE Ó

IMPACTO Cierre de caja Cierres errados de caja.

Para llevar a cabo un cierre de caja al final del día en un establecimiento que vende en promedio 4 millones de pesos diarios, divididos en diferentes tipos de cajas, es necesario que el software proporcione mayor cantidad de información, más oportuna y mejor.

Robo por parte de los 11 diferentes cajeros por cifras que alcanzan los $ 200.000 mensuales

Fuente: Autor del presente trabajo. Tabla 4. Sanciones impuestas por COMCEL

Fuente: Contabilidad CGC Equipos CAD – Vencidos: 60 días para vender los equipos en consignación. No recepción 30 días: control de lo que se activo diariamente , una plantilla, y esa plantilla cuando se envía a calle 13 tiene que marcarla con la planilla. El sistema avisa cuales se están pasando. Cada vez que se vende un kit hay que demostrar que tiene trafico entrante y saliente, sig no tiene nada que hacer porque si un clienteva y se cambia a la competencia toca pagarlo a full precio. Hay una pelanización por pasarse de las 48 horas de activado y no entregar los contratos penalización no entrega oportuna. Yo entrego el contrato hoy y lo mando con un error y tengo 48 para corregirlo y si no lo corrige también tiene penalización La reversión de una activación Cuando el cheque no tiene fondos la sanción es del 20 % de penalización A continuación se enumeran los procesos manuales de la compañía. Estos procesos siguen siendo manuales por dos razones: La primera es q a pesar de estar integrando los procesos, algunos de ellos no estaban integrados por el software actual; la segunda es que al adquirir un software de integración no se puede pasar inmediatamente a procesos automatizados, en un principio y simultáneamente hay que llevar a cabo los procesos manualmente y con el software para verificar los resultados de la integración.

C ATE GOR IA TIPO 2006 2007 2008 TotalC ALDIS T 3.004.873 2.654.940 4.880 5.664.693 DIF E R E NC IA E N C ONS IGNAC ION 3.686.484 837.535 509.844 5.264.527 E QUIPOS C AD ‐ VE NC IDOS 45.546.240 67.197.428 27.047.672 160.151.372 FALTANTE S C AJ A 2.383.602 9.431.330 12.987.215 27.439.847 FR AUDE ‐ INC ONS . DOC 221.138.172 3.588.815 2.170.324 228.879.039 P E NAL IZA C OR R E C C ION DE DATOS 118.000 354.500 805.210 1.336.760 NO R E C E P C ION 30 DIAS 10.563.765 190.000 743.080 11.496.845 P E NAL IZA NO C ONS IGNAC ION OPOR T 16.890.444 887.000 ‐ 17.777.444 P E NAL IZA NO C UMPL VE NTAS ‐ K IT 102.294.250 14.026.624 44.164.729 167.178.372 P E NAL IZA NO E NTR E GA OPOR T 22.464.000 3.671.516 ‐ 26.135.516 P E NAL IZA NO S OLUC I 9.120.000 1.892.837 5.034.147 16.663.337 P E NAL IZAC ION R E VE R S ION 4.474.704 ‐ ‐ 4.474.704 S ANC ION C HE QUE S 917.328 6.064.072 319.000 7.300.400

442.601.862 110.796.597 93.786.101 679.762.856

(*) Datos actualizados al 15 de Abril de 2009

P E NAL IZAC ION

Total

197

Tabla 5. Problemas en procesos manuales PROCESOS MANUALES PROBLEMA IMPACTO Activaciones Distorsión de los costos de

inventarios Costo de inventario subvalorado. Inventario real $80’000.000. Inventario calculado por el software $400’000.000.

Cruce del inventario físico con el contable

Reproceso de las facturas 1 hora extra diaria ($ 50.036) (1 empleado por CPS) X 6 días a la semana X cada CPS (11 CPSs) X 6 meses = $19’814.256.

Activaciones Retraso para la legalización de contratos en Comcel

Sanciones y demoras para el pago de comisiones por parte de Comcel. Contrato: $ 4000 por cada día que CGC se demore en legalizarlo

Asignación de equipos y Activaciones

Activación de equipos con planes diferentes para los cuales fueron adquiridos (entiéndase como libres el hecho de que no está ligado a ningún operador)

Comcel cobra el equipo a full precio (precio de mercado de un equipo libre) si se activa un postpago como prepago.

Inventarios Perdida de inventario por el descontrol que ocasionó la diferencia del costo de venta.

El impacto varía siempre, porque, debido a la distorsión de los costos de inventario, al verificar el inventario físico no se sabe qué cantidad de equipos se puede perder o cuánto puede costar cada uno.

Fuente: Autor de presente trabajo En resumen, si sumamos todas las sanciones, costo de inventarios subvalorado, costos adicionales por contrataciones para corregir errores, etc.; solo en el 2008 obtenemos la siguiente cifra, lo cual es impactante para la compañía y razón suficiente para tomar decisiones que cambien la situación actual:

Tabla 6. Total costos adicionales

Concepto Valor Inventario subvalorado $ 320.000.000 Contrataciones adicionales (todo el año y una por cada CPS (11))

$ 132.095.040

Sanciones $ 93.786.101 Robo por parte de los cajeros $ 26.400.000 TOTAL $ 572.281.141

Fuente: Contabilidad CGC

198

Después de contar con la asesoría de un ingeniero externo para intentar hacer que el software funcionara, se llegó a la conclusión de que es preferible desarrollar rápidamente una solución alterna, hecha a la medida, por cuanto que la compañía esta facturando $12.000.000.000 al año. En conclusión, el problema principal generado es el descontrol de los procesos de la compañía a causa de un crecimiento económico acelerado mal llevado y el empeoramiento de la situación por la implementación de un software imperfecto que no responde a las necesidades de los procesos. Por lo tanto, ¿cuáles serían los requerimientos a partir de los cuales se pueda llevar a cabo un diseño de software que integre los procesos de CGC de manera eficiente?

3. JUSTIFICACIÓN DEL PROYECTO

El problema que surge de no solucionar a plenitud los inconvenientes a los cuales se esta enfrentando la organización, va mas allá de no tener una buena comunicación horizontal y vertical en la empresa, o de no generar productos o servicios internos eficientemente. Uno de los problemas tiene que ver con los costos en los cuales esta incurriendo la empresa, ya que los conceptos por los cuales se están causando no le aportan valor al proceso, conceptos tales como: Costos por prevención (implementación del software, salario del ingeniero a cargo del proyecto), Costos por evaluación (Personal nocturno dedicado a la verificación del desempeño diario del software), Costos por fallas internas (Descuadre de inventarios, cálculos erróneos de IVA, verificación doble del data crédito, etc.), Costos por fallas externas (correcciones de activaciones posteriores a la venta, sanciones por parte de Comcel). Otros de los problemas son las inconsistencias en los inventarios, cajas y ventas, ya que muchas veces hay que reprocesar información ya analizada que determina indicadores importantes para la empresa como, rotación de inventario, rendimiento del patrimonio, y en resumen todos los indicadores financieros que se quieran calcular serán incorrectos y el panorama para la empresa será incierto siempre.

Un planteamiento correcto de la integración de procesos en la compañía beneficiaría a todos los empleados de la compañía, ya que al mejorar el desempeño y colaboración en todas las áreas de la compañía se van a poder cumplir los objetivos planteados por la gerencia, además van a mejorar las relaciones entre las áreas y mas importante entre los empleados. A parte de estos beneficiarios también lo serán los acreedores de la compañía ya que al disminuir todos los costos ya mencionados la rentabilidad de la compañía va a mejorar. Por último, los clientes también van a ser beneficiarios de este proyecto ya que uno de los objetivos al integrar los procesos de la compañía es mejorar la calidad del servicio prestado, y muchos de los servicios y productos que ofrece la empresa requieren contacto directo con el cliente.

Para nadie es un secreto que la sociedad ha convertido la telefonía celular en un servicio indispensable, por lo tanto, la manera en la cual se adquiere este producto y servicio debería ser un valor agregado. Entonces, si los clientes están conformes con el servicio que están recibiendo en los CPS, o en sus subdistribuidores, quiere decir que CGC está mejorando la calidad de su servicio.

Académicamente podemos notar la estrecha relación que existe entre la ingeniería de sistemas y la ingeniería industrial, aunque ya hay muchos software de integración importantes (SAP) que demuestran esto, esperamos que este trabajo de grado le sea útil a las nuevas generaciones de ingenieros industriales para valorar la importancia de pensar de manera lógica y estructurada, a n a l i z a r l o s p r o b l e m a s y d i s e ñ a r s o l u c i o n e s p a r a l o s m i s m o s .

Por último podemos concluir que emprender un desarrollo de software propio es la mejor decisión que puede tomar CGC ya que después de buscar una solución en el mercado, implementarla y no obtener buenos resultados, el único ente que puede garantizar un desarrollo optimo y a la medida (en términos de usuarios, módulos e integración de módulos) es el mismo usuario.

199

4. MARCO TEÓRICO 4.1. Procesos10 o Es una organización racional de personas, materiales, energía, equipos y procedimientos en

actividades concebidas para producir un resultado final específico, o bien, también se puede definir como un Conjunto de pasos que se realizan de forma sucesiva en distintas dependencias, con el objeto de transformar una serie de entradas específicas en una salidas (bienes o servicios) deseadas, añadiendo valor.

4.1.1. Componentes básicos de un proceso o Materias primas o insumos o Actividades o Resultados

Grafico 6. Ilustración procesos

Fuente: Página de Internet de la gobernación del Valle del cauca. No se concibe un proceso sin un objetivo, ya sea un bien o servicio, ni tampoco que ese resultado no esté asociado a un cliente que tenga una necesidad por satisfacer. Los procesos en la organización se identifican a partir constitución de la compañía, quien define sus objetivos, productos o servicios, y funciones. Estos en conjunto con la definición de la misión de la organización, la cual determina el valor agregado de la entidad, formalizan los procesos y subprocesos que debe adelantar la empresa, a fin de cumplir con sus objetivos, productos o servicios que le son demandados.

4.1.2. Clasificación de los procesos En toda organización se identifican los procesos misionales (de producción o básicos), transversales (estratégicos) y de apoyo

• 10 www2.valledelcauca.gov.co/SIISVC/documentos/

ligarcia%20453960/QU%C9%20SON%20LOS%20PROCESOS.doc, consultada 20-01-09

PRODUCTOS O SERVICIOS

ENTRADAS

SALIDAS INSUMOS

PROCESO

200

Los procesos misionales o básicos hacen realidad la misión organizacional. A través de ellos es posible satisfacer las necesidades de la comunidad, así como capitalizar las posibilidades de la organización y del entorno. Los procesos transversales o estratégicos introducen las acciones tácticas de la organización, las que permiten asumir con características propias la responsabilidad de producir unos resultados definidos. Los procesos de apoyo, soportan el desarrollo de los demás procesos, introduciendo las herramientas logísticas requeridas en la organización.

4.1.3. Actores que intervienen en cada proceso Los proveedores: son quienes suministran los materiales y las informaciones de acuerdo con los requisitos. Los responsables del proceso o productores: son todos aquellos que aportan su trabajo personal en las diferentes etapas del proceso para lograr un producto o servicio que cumpla con todos los requisitos exigidos por el cliente. Los clientes: Los destinatarios finales del producto o servicio y los que en definitiva juzgan su calidad, en la medida en que satisface sus necesidades y expectativas.

4.1.4. ¿Cómo identificar un proceso? Puede establecerse una jerarquía que divida a un macroproceso en subprocesos, y estos en microprocesos hasta integrar las dos perspectivas. Otra concepción es adoptar la perspectiva de los clientes como punto de partida, identificando en primer lugar todos los productos o servicios puestos a su disposición y, a continuación, todos los pasos que se realizan para proporcionárselos.

4.1.5. Etapas básicas de los procesos Preparatorios: Las actividades que permiten la iniciación del proceso De ejecución: o de transformación, en los que los insumos son sometidos a la transformación que producirá valor agregado. De resultados: es decir el producto o servicio resultante de la transformación de los insumos. La actividad de control está presente en cada una de las actividades descritas, a efectos de garantizar el valor agregado esperado y la calidad del producto o servicios a satisfacción del usuario.

4.1.6. Aspectos relevantes

Si nos detenemos un momento a reflexionar sobre la entidad que vive, se transforma y crece, encontramos que los procesos:

201

• Son mutuamente dependientes, ya que ninguno coexiste sin la ayuda o intervención de otro.

No existen procesos autónomos, así se trate del más breve o humilde. • Se interceptan unos con otros y se retroalimentan en forma permanente. • Se agregan valor o se desgastan entre sí. • Tienen cabeza o iniciación que son la finalización o cola de otros. • Bien ejecutados facilitan la ejecución exitosa de otros • Cruzan líneas fronterizas organizacionales, porque usualmente tienen que ver con más de una

dependencia de manera directa o indirecta. 4.2. Sistemas de información11

Un sistema de información se puede definir técnicamente como un conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen información para apoyar la toma de decisiones y el control en una organización. Además de apoyar la toma de decisiones, la coordinación y el control, los sistemas de información también pueden ayudar a los gerentes y trabajadores a analizar problemas, visualizar asuntos complejos y crear productos nuevos.

Los sistemas de información contienen información acerca de gente, lugares y cosas importantes dentro de la organización y en el entorno en que se desenvuelven. Por información se entienden los datos que se han moldeado en una forma significativa y útil para los seres humanos. En contraste, los datos son secuencias de hechos en bruto y representan eventos que ocurren en las organizaciones o en el entorno físico antes de ser organizados y ordenados en una forma que las personas puedan entender y utilizar.

Hay tres actividades en un sistema de información que producen la información que esas organizaciones necesitan para tomar decisiones, controlar operaciones, analizar problemas y crear nuevos productos o servicios, Estas actividades son entradas, procesamiento y salidas. La entrada captura o recolecta datos en bruto tanto de interior de la organización como de su entorno externo, el procesamiento convierte esta entrada de datos en una forma más significativa. La salida transfiere la información procesada a la gente que la usara o las actividades para las que se utilizara. Los sistemas de información también requieren retroalimentación, que es la salida que se devuelve al personal adecuado de la organización para ayudarle a evaluar o corregir la etapa de entrada.

Hay dos tipos de sistemas, los sistemas formales y los informales. Los sistemas formales se apoyan en definiciones fijas y aceptadas de datos y procedimientos para recolectar, almacenar, procesar, distribuir y utilizar estos datos. Los sistemas informales de información se basan, por el contrario, en reglas de comportamiento no establecidas. No hay consenso sobre lo que es información o sobre cómo se almacenará o se procesara ésta. Tales sistemas informales son esenciales para la vida de una organización.

Los sistemas formales de información pueden estar basados en computadora o ser manuales. Los sistemas manuales utilizan la tecnología de papel y lápiz. Por el contrario, los sistemas de información basados en computadora se apoyan en la tecnología de software y hardware de cómputo para procesar y distribuir la información.

11 SISTEMAS DE INFORMACIÓN GERENCIAL (ADMINISTRACIÓN DE LA EMPRESA DIGITAL), Kenneth C. Laudon, Jane P. Laudon, 10ma edición, 2008.

202

Aunque los sistemas de información basados en computadora utilizan tecnología de cómputo para procesar datos en bruto y obtener información significativa, hay una distinción bien definida entre una computadora y un programa de cómputo por una parte, y un sistema de información por otra. Las computadoras electrónicas y los programas de software relacionados son la base técnica, las herramientas y el material de los modernos sistemas de información. Las computadoras proveen el equipo para almacenar y procesar la información. Los programas de cómputo, o software, son conjuntos de instrucciones funcionales que dirigen y controlan el procesamiento por computadora. Saber cómo funcionan las computadoras y los programas de cómputo es importante para el diseño de soluciones a problemas de la organización, pero las computadoras son sólo parte de un sistema de información.

4.2.1. Principales tipos de sistemas en las organizaciones

Cuatro principales tipos de sistemas de información dan servicio a los diferentes niveles de la organización: sistemas a nivel operativo, sistemas a nivel del conocimiento, sistemas a nivel administrativo y sistemas a nivel estratégico. Los sistemas a nivel operativo apoyan a los gerentes operativos en el seguimiento de las actividades y transacciones elementales de la organización como ventas, ingresos, depósitos en efectivo, nomina, decisiones de crédito y flujo de materiales en una fábrica. Las preguntas que podría responder este tipo de sistema son: ¿Cuántas partes hay en el inventario? ¿Qué pasó con el pago del señor Gutiérrez? En general, para contestar este tipo de preguntas la información debe estar a la mano y ser actual y precisa.

Los sistemas a nivel de conocimiento apoyan a los trabajadores del conocimiento y de datos de una organización. El propósito de estos sistemas es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organización a controlar el flujo del trabajo de oficina. Los sistemas a nivel del conocimiento, especialmente en forma de estaciones de trabajo y sistemas de ofician, están entre las aplicaciones del crecimiento más rápido en los negocios actuales.

Los sistemas a nivel administrativo sirven a las actividades de supervisión, control, toma de decisiones y administrativas de los gerentes de nivel medio. La pregunta principal que plantean estos sistemas es: ¿van bien las cosas? Por lo general, este tipo de sistemas proporciona informes periódicos más que información instantánea de operaciones. Un ejemplo es un sistema de control de reubicación que informe los costos totales de mudanza, búsqueda de vivienda y financiamiento de vivienda para empleados de todas las divisiones de la compañía y notifique cualquier costo actual que exceda los presupuestos.

Los sistemas a nivel estratégico ayudan a los directores a enfrentar y resolver aspectos estratégicos y tendencias a largo plazo, tanto en la empresa como en el entrono externo. Su función principal es compaginar los cambios del entorno externo con la capacidad organizacional existente. ¿Cuáles serán los niveles de empleo dentro de 5 años? ¿Cuáles las tendencias a largo plazo de los costos de la industria donde encaja nuestra empresa?.

Tabla 7. Tipos de sistemas

TIPOS DE SISTEMAS Sistemas a nivel estratégico

Sistemas de apoyo de ejecutivos

Pronóstico de plan de tendencia de ventas a 5 años

Plan operativo a 5 años

Pronóstico de presupuesto para 5 años

Planeación de utilidades

Planeación de personal

203

TIPOS DE SISTEMAS Sistemas a nivel administrativo

Sistemas de información gerencial

Administración de ventas

Control de inventario

Elaboración del presupuesto anual

Análisis de inversión de capital

Análisis de reubicación

Sistemas de apoyo a la toma de

decisiones

Análisis de la región de ventas

Programación de la producción

Análisis de costos

Análisis de fijación de precios y rentabilidad

Análisis de costo de contratos

Sistemas a nivel del conocimiento Sistemas de trabajo de

conocimiento

Estaciones de trabajo para ingeniería

Estaciones de trabajo para gráficos

Estaciones de trabajo para gerentes

Sistemas de oficina

Procesamiento de texto Digitalización de documentos

Calendarios electrónicos

Sistemas a nivel operativo Sistemas de

procesamiento de

transacciones

Seguimiento de pedidos

Control de máquinas

Negociación de valores

Nómina Compensaciones

Procesamiento de pedidos

Programación de la planta

Administración del efectivo

Cuentas por pagar

Capacitación y desarrollo

Control de movimiento de materiales

Cuentas por cobrar

Registro de empleados

Ventas y Marketing

Manufactura Finanzas Contabilidad Recursos humanos

Fuente: SISTEMAS DE INFORMACIÓN GERENCIAL (ADMINISTRACIÓN DE LA EMPRESA DIGITAL)

De igual forma los sistemas también se pueden dividir por funcionalidad, pueden haber sistemas para ventas y marketing, para manufactura, para finanzas, para contabilidad y para recursos humanos.

Por último, es bueno saber que existen muchos sistemas alternativos de construcción de sistemas. Los sistemas difieren en cuanto a tamaño, complejidad tecnológica y problemas organizacionales que están destinados a resolver. Puesto que hay diferentes tipos de sistemas, se han desarrollado varios métodos para construir sistemas.

204

4.3. Requerimientos12

4.3.1. Especificaciones de requerimientos

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema.

4.3.2. Requerimientos funcionales y no funcionales 4.3.2.1. Requerimientos funcionales Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer. Son un conjunto de elementos de un sistema que describen la funcionalidad o los servicios que se espera que éste provea. Un ejemplo de requerimiento funcional de un software de contabilidad seria “imprimir cheques de sueldos”. Los requerimientos dependen del tipo de software, del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo. 4.3.2.2. Requerimientos no funcionales

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema. 4.3.2.3. Requerimientos del dominio

Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria. 4.4. Requerimientos del usuario y del sistema

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se 12 http://www. Mitecnologico.com/Main/Especificaciones De Requerimientos, consultada 13-01-09 8:00 PM.

205

hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detallada para establecer un puente entre la ingeniería de requerimientos y las actividades de diseño. Los requerimientos del usuario, los del sistema y la especificación del diseño de software se definen de la siguiente manera:

4.4.1. Requerimientos del usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.

Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.

4.4.2. Los requerimientos del sistema

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.

Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

4.5. Casos de uso13 Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.” Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido.

4.5.1. Definiciones Básicas Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor.

13 http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf

206

A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso. El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Grafico 7. Ejemplo grafico caso de uso

Fuente: http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo información de pedidos y no Generando información de pedidos. Los casos de uso tienen las siguientes características: 1) Están expresados desde el punto de vista del actor. 2) Se documentan con texto informal. 3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción. 4) Son iniciados por un único actor. 5) Están acotados al uso de una determinada funcionalidad –claramente diferenciada– del sistema. El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene un único caso de uso Usando el Sistema. Sin embargo, la especificación resultante sería de poca utilidad para entenderlo; sería como implementar un gran sistema escribiendo un único programa. La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos. Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por esto se hace importante usar el sentido común en estas decisiones.

207

4.5.2. Descripción de los Casos de Uso Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. A continuación se muestra una parte simplificada de la descripción del caso de uso “Ingresando Pedido”.

Tabla 8. Ejemplo descripción de caso de uso

Fuente: http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir un sistema en el cual la interacción con el usuario es muy simple: ingresa un conjunto básico de datos, y con esos datos el sistema realiza una gran cantidad de cálculos, aplicando complejas fórmulas. ¿Cómo hago con un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de texto informal. Por lo tanto, deberemos usar una nueva notación para especificar este comportamiento interno, algo equivalente a los diagramas de flujo de datos del análisis estructurado. En UML (Unified Modelling language) se propone usar una notación llamada “Diagrama de Actividad”, el moderno heredero del diagrama de flujo, o “flowchart”. Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la descripción del caso, las decisiones e iteraciones. De esta forma, es común que en las descripciones de los casos se deba recurrir a frases como “Se repite el paso X hasta que ocurre C”, o “Si ocurre C se pasa al paso X”. En estas situaciones lo importante no es la forma en la que se expresan las condiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripción del caso fuera muy compleja, es conveniente usar notaciones gráficas, por ejemplo los diagramas de actividad.

208

5. OBJETIVO GENERAL Determinar los requerimientos funcionales necesarios para el desarrollo de un software, que integre los procesos susceptibles de sistematización en la empresa CGC.

6. OBJETIVOS ESPECÍFICOS

• Identificar los procesos operativos, su influencia sobre los administrativos y de esta manera determinar cuáles procesos deben tener prioridad o son susceptibles para su sistematización.

• Determinar los requerimientos de los usuarios del software para los procesos que se


• Definir los requerimientos funcionales del software.

• Basados en la Estimación económica del desarrollo de software y el plan de trabajo para la implementación, realizar una evaluación económica del proyecto.

209

7. METODOLOGÍA

OBJETIVOS ESPECIFICOS

ACTIVIDADES HERRAMIENTAS ASIGNATURA FUENTES

Identificar los procesos

operativos, su influencia sobre los administrativos y de

esta manera determinar cuáles procesos deben tener prioridad o son susceptibles

para su sistematización

• Reconocimiento de los procesos operativos.

• Hallar la relación de los procesos operativos con los administrativos.

• Determinar el impacto de los procesos operativos sobre los administrativos.

• Priorizar los mas influyentes para su posible sistematización.

• Determinar si los más influyentes son sistematizables.

Mapa de procesos, Herramientas de

mejoramiento administrativo,

diagramación de procesos, análisis de la

modularidad de los procesos, diagrama matriz, diagrama de

afinidad y diagrama de interrelaciones.

Gestión de la calidad,

administración de sistemas de información,

automatización industrial,

integración de procesos con TI,

análisis de operaciones,

estudio del trabajo.

Introducción al estudio del trabajo / Oficina Internacional del Trabajo (OIT); dirección de George Kanawaty, Información del curso gestión de calidad, Sistemas de información gerencial (administración de la empresa digital) Kenneth C. Laudon, Jane P. Laudon, octava edición, http://www. Mitecnologico .com /Main /Especificaciones De Requerimientos, diapositivas asignatura integración de procesos con TI, procesos operativos y administrativos actuales de la organización

Determinar los requerimientos de los usuarios del

software para los procesos que se


• Análisis y negociación de los requisitos de los usuarios, clientes y demás intervinientes del proceso

• A partir de los requisitos determinar y

Check list, análisis de diagramas, diagrama

de interrelaciones, lluvia de ideas,

diagrama matriz, diagrama de afinidad.

Integración de procesos con TI,

automatización de procesos,

administración de sistemas de información,

Estudio del trabajo, Análisis de

operaciones,

Gerencia de procesos, Introducción al estudio del

trabajo / Oficina Internacional del Trabajo

(OIT); dirección de George Kanawaty, Sistemas de información gerencial (administración de la

empresa digital) Kenneth C. Laudon, Jane P.

210

OBJETIVOS ESPECIFICOS

ACTIVIDADES HERRAMIENTAS ASIGNATURA FUENTES

documentar los requerimientos de los usuarios (usando lenguaje natural, representaciones y diagramas intuitivos sencillos.).

• Validación de los requisitos.

Gestión de calidad. Laudon, análisis de los procesos (operativos y

administrativos) actuales.

Definir los requerimientos funcionales del

software.

• Determinar que tipo de sistema se va a desarrollar y los posibles usuarios del mismo.

• Describir los requerimientos funcionales en términos de funciones, entradas, procesos, salidas, etc.

Análisis de actividades y entorno de trabajo,

lluvia de ideas, análisis de procedencia, diagramación de

procesos, Casos de uso.

Estudio del trabajo, diseño salarial (en

esta asignatura nos enseñaron a hacer

manuales de función),

integración de procesos con TI, administración de

sistemas de información.

Situación actual de los puestos de trabajo,

manuales antiguos de trabajo, Sistemas de información gerencial (administración de la

empresa digital) Kenneth C. Laudon, Jane P.

Laudon,

Basados en la Estimación económica

del desarrollo de software y el plan de

trabajo para la implementación,

realizar una evaluación económica

del proyecto.

• Llevar a cabo una proyección de los posibles costos y beneficios del proyecto.

Análisis de precios, evaluación de

proyectos, análisis de Pareto, análisis de

rentabilidad.

Preparación y evaluación de

proyectos, Ingeniería

económica, Contabilidad,

logística.

Posibles costos del desarrollo de un software integrador de procesos,

Ingeniería económica 5a ed. Tarkin, Anthony J,

Fundamentos de ingeniería económica 3a ed. Baca Urbina, Gabriel.

211

8. RESTRICCIONES No hay restricciones.

9. TABLA DE CONTENIDO PROPUESTA DEL TRABAJO FINAL

1. Introducción 2. Objetivos

2.1. Objetivo general 2.2. Objetivos específicos

3. Relación de los procesos operativos y administrativos 3.1. Procesos operativos 3.2. Procesos administrativos 3.3. Relación e impacto

3.3.1. Procesos a sistematizar 4. Requerimientos específicos

4.1. Casos de uso 4.2. Requerimientos de los usuarios 4.3. Requerimientos funcionales

4.3.1. Tipos de sistemas potenciales para las áreas 4.3.2. Usuarios del sistema 4.3.3. Funcionalidad y desempeño del sistema

4.3.3.1. Entradas procesamiento y salidas 4.3.4. Restricciones de diseño 4.3.5. Análisis relacional de la base de datos 4.3.6. Requerimientos funcionales 4.3.7. Diseño gráfico de las pantallas

5. Análisis económico 5.1. Estimación económica del desarrollo de software. 5.2. Plan de trabajo para la implementación. 5.3. Viabilidad económica 5.4. Reducción de costos proyectada 5.5. Rentabilidad proyectada

6. Conclusiones 7. Recomendaciones 8. Bibliografía 9. Anexos

212

10. CRONOGRAMA

No ACTIVIDADES FECHA DE INICIACIÓN FECHA DE FINALIZACIÓN

RESPONSABLE DURACIÓN (días)

1 Procesos a sistematizar 23 de Julio de 2009 2 de Agosto de 2009 Diego Infante 10

2 Requerimientos funcionales 2 de agosto de 2009 12 de agosto de 2009 Diego Infante 10

3 Tipos de sistemas potenciales para las áreas 12 de agosto de 2009 17 de agosto de 2009 Diego Infante 5

4 Usuarios del sistema 17 de agosto de 2009 25 de Agosto de 2009 Diego Infante 8

5 Entradas, procesamientos y salidas 25 de Agosto de 2009 2 de Septiembre de 2009

Diego Infante 8

6 Restricciones de diseño 2 de Septiembre de 2009 12 de Septiembre de 2009

Diego Infante 8

7 Aspectos legales 12 de Septiembre de 2009

15 de Septiembre de 2009

Diego Infante 3

8 Viabilidad económica 15 de Septiembre de 2009

23 de Septiembre de 2009

Diego Infante 8

9 Reducción de costos proyectada 23 de Septiembre de 2009

2 de Octubre de 2009 Diego Infante 8

10 Rentabilidad proyectada 2 de Octubre de 2009 7 de Octubre de 2009 Diego Infante 5

11 Conclusiones 7 de Octubre de 2009 11 Octubre de 2009 Diego Infante 4

12 Recomendaciones 11 Octubre de 2009 14 de octubre de 2009 Diego Infante 3

213

11. RECURSOS

RECURSO TIPO DESCRIPCIÓN COSTO / CANTIDAD

Estudiante Humano Es la persona que va a llevar a cabo el trabajo de grado

$ -

Bibliografía Físico / Digital

Toda la Bibliografía bien sea física o paginas Web que le agregue valor al proyecto

$ -

Herramientas tecnológicos

Técnico Computador y software con los cuales se va a desarrollar el proyecto y además le agregue valor al mismo

$ 1.200.000

Director de proyecto

Humano Persona que asesora al estudiante durante el proyecto

$1.000.000

Empleados de CGC Humano Todos los potenciales usuarios del sistema que brinden información para el proyecto

$ -

Presupuesto Económico Recursos empleados para el levantamiento de la información de los requerimientos.

$ 1’600.000 mensual

(Salario de la persona que

está disponible para levantar

los requerimientos)

para determinar la viabilidad del proyecto, se llevó a

Documents