CARTA DE AUTORIZACIÓN DE LOS AUTORES PARA LA CONSULTA, LA REPRODUCCIÓN PARCIAL O TOTAL, Y PUBLICACIÓN ELECTRÓNICA DEL TEXTO COMPLETO. Bogotá, D.C., Enero 21 de 2010 Marque con una X Señores BIBLIOTECA GENERAL Ciudad Tesis doctoral Trabajo de Grado X Estimados Señores: Los suscritos Diego Alejandro Infante Pinzón, con C.C. No. 80.875.601 autor de la tesis doctoral y/o trabajo de grado titulado DETERMINACIÓN DE LOS REQUERIMIENTOS FUNCIONALES PARA UN SOFTWARE QUE INTEGRE LOS PROCESOS OPERATIVOS DEL DISTRIBUIDOR CGC DE COMCEL presentado y aprobado en el año 2009 como requisito para optar al título de Ingeniero Industrial; autorizo a la Biblioteca General de la Universidad Javeriana para que con fines académicos, muestre al mundo la producción intelectual de la Universidad Javeriana, a través de la visibilidad de su contenido de la siguiente manera: Los usuarios puedan consultar el contenido de este trabajo de grado en Biblos, en los sitios web que administra la Universidad, en Bases de Datos, en otros Catálogos y en otros sitios web, Redes y Sistemas de Información nacionales e internacionales Open Access y en las redes de información del país y del exterior, con las cuales tenga convenio la Universidad Javeriana. Permita la consulta, la reproducción, a los usuarios interesados en el contenido de este trabajo, para todos los usos que tengan finalidad académica, ya sea en formato CD-ROM o digital desde Internet, Intranet, etc., y en general para cualquier formato conocido o por conocer. Continúo conservando los correspondientes derechos sin modificación o restricción alguna; puesto que de acuerdo con la legislación colombiana aplicable, el presente es un acuerdo jurídico que en ningún caso conlleva la enajenación del derecho de autor y sus conexos. De conformidad con lo establecido en el artículo 30 de la Ley 23 de 1982 y el artículo 11 de la Decisión Andina 351 de 1993, Los derechos morales sobre el trabajo son propiedad de los autores, los cuales son irrenunciables, imprescriptibles, inembargables e inalienables. Diego Alejandro Infante Pinzón C.C. 80.875.601 NOTA IMPORTANTE: El autor y o autores certifican que conocen las derivadas jurídicas que se generan en aplicación de los principios del derecho de autor. CC FACULTAD DE INGENIERIA, PROGRAMA ACADÉMICO DE INGENIERIA INDUSTRIAL.
FORMULARIO DE LA DESCRIPCIÓN DE LA TESIS DOCTORAL O DEL TRABAJO DE GRADO TÍTULO COMPLETO DE LA TESIS DOCTORAL O TRABAJO DE GRADO: DETERMINACIÓN DE LOS REQUERIMIENTOS FUNCIONALES PARA UN SOFTWARE QUE INTEGRE LOS PROCESOS OPERATIVOS DEL DISTRIBUIDOR CGC DE COMCEL. AUTOR O AUTORES Apellidos Completos Infante Pinzón Diego Alejandro Nombres Completos DIRECTOR (ES) TESIS DOCTORAL O DEL TRABAJO DE GRADO Apellidos Completos Nombres Completos Juan Bernardo Merino Zuleta ASESOR (ES) O CODIRECTOR Apellidos Completos Nombres Completos TRABAJO PARA OPTAR AL TÍTULO DE: Ingeniero Industrial FACULTAD: Ingeniería PROGRAMA: Carrera X Licenciatura Especialización Maestría Doctorado NOMBRE DEL PROGRAMA: Ingeniería Industrial NOMBRES Y APELLIDOS DEL DIRECTOR DEL PROGRAMA: Jorge Alberto Silva Rueda CIUDAD: BOGOTA AÑO DE PRESENTACIÓN DEL TRABAJO DE GRADO: 2009 NÚMERO DE PÁGINAS: 213 TIPO DE ILUSTRACIONES: Ilustraciones Tablas, gráficos y diagramas SOFTWARE requerido y/o especializado para la lectura del documento: NO
MATERIAL ANEXO (Vídeo, audio, multimedia o producción electrónica): NO Duración del audiovisual: minutos. Número de casetes de vídeo: Formato: VHS Beta Max ¾ Beta Cam Mini DV DV Cam DVC Pro Vídeo 8 Hi 8 Otro. Cual? Sistema: Americano NTSC Europeo PAL SECAM Número de casetes de audio: Número de archivos dentro del CD (En caso de incluirse un CD-ROM diferente al trabajo de grado): PREMIO O DISTINCIÓN (En caso de ser LAUREADAS o tener una mención especial): DESCRIPTORES O PALABRAS CLAVES EN ESPAÑOL E INGLÉS: Son los términos que definen los temas que identifican el contenido. (En caso de duda para designar estos descriptores, se recomienda consultar con la Unidad de Procesos Técnicos de la Biblioteca General en el correo biblioteca@javeriana.edu.co, donde se les orientará. ESPAÑOL Proceso racional unificado (RUP) Lenguaje de modelado unificado (UML) Casos de uso Diagramación de procesos Caracterización de procesos Requerimientos funcionales Requerimientos del usuario INGLÉS Rational Unified Process (RUP) Unified Modeling Language (UML) Use cases Process mapping Process characterization Functional requirements User requirements RESUMEN DEL CONTENIDO EN ESPAÑOL E INGLÉS: Español Como su nombre lo dice, el objetivo general de este trabajo de grado 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 trabaja la compañía. El análisis en este trabajo consta de la determinación del mapa de procesos y la definición de los procesos actuales dentro de los macro-procesos. A partir de esta situación inicial se planteó una situación propuesta de los procesos y sobre estos se llevó a cabo el estudio de los casos de uso del software (Herramienta de descripción y diagramación incluida en el Unified Modeling Language UML). Por último se determinaron los requerimientos funcionales del mismo.
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).
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 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 Director: JUAN BERNARDO MERINO ZULETA Ingeniero Industrial PONTIFICIA UNVIERSIDAD JAVERIANA FACULTAD DE INGENIERIA INDUSTRIAL BOGOTA, D.C. 2009 2
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 3
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 4
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 5
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 6
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 7
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 8
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. 9
Gráfico 1. Secuencia de pensamiento Fuente: Autor del presente trabajo 10
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. 11
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 12
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. 13
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. 14
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 NECESIDADES DE LOS CLIENTES PRODUCTOS CLIENTES SATISFECHOS Fuente: Autor del presente trabajo 15
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 MACRO PROCESO PROCESOS DE DIRECCIÓN PRESTACIÓN DEL SERVICIO GENERACIÓN DE VALOR CAMBIOS 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". 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 16
MACRO PROCESO CAMBIOS PROCESOS SOPORTE 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. 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. Fuente: Autor del presente trabajo 17
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). MACRO PROCESO Gestión estratégica PROCESOS Definición o reevaluación de los lineamientos estratégicos Definición de objetivos a corto plazo Control de objetivos a corto plazo Tabla 2. Descripción del mapa de procesos final DIAGRAMACIÓN Este proceso seria corto y no es parte del alcance del estudio Este proceso seria corto y no es parte del alcance del estudio 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) 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. Gestión Compra de equipos Anexo 7 (Diagramas de procesos) administrativa Compra de recargas o Sim Card Anexo 9 (Diagramas de procesos) 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 Control de inventarios 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 Gestión financiera Soporte al servicio Capacitaciones para vendedores antiguos y Anexo 13 y 15 (Diagramas de procesos) nuevos 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 Tesorería 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. 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 Contabilidad diagramar estos procesos sería inútil para el estudio. No se diagrama este proceso por no estar dentro del alcance del estudio. Los procesos de un revisor fiscal son relativamente estándar para cualquier Revisoría fiscal empresa e inútiles para el estudio, ya que prácticamente se trata de una auditoría. Servicio al cliente Anexo 17 (Diagramas de procesos) Reposición Servicio al cliente Anexo 19 (Diagramas de procesos) Recargas Pago de facturas Anexo 21 (Diagramas de procesos) Fuente: Autor del presente trabajo 18
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. 19
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. 20
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 Definición de objetivos a corto plazo Administrativo Administrativo Control de objetivos a corto plazo Administrativo Ventas Ventas Operativo Activaciones Activación Operativo Gestión administrativa Nomina Compra de equipos Compra de recargas o Sim Card Control de inventarios Administrativo Operativo Operativo Operativo Gestión comercial Capacitaciones para asesores antiguos y nuevos Operativo Gestión financiera Soporte al servicio Contabilidad Revisoría fiscal Servicio al cliente Reposición Servicio al cliente Recargas Pago de facturas Fuente: Autor del presente trabajo Administrativo Administrativo Operativo Operativo Operativo 21
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 matriz 1. 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ón 0 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. La información no fiable generada en el proceso operativo causa dificultades en el flujo normal del proceso 2 administrativo. La información no fiable generada en el proceso operativo impide que el proceso administrativo se lleve a cabo 3 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 22
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. 23