TESIS PUCP Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.5/pe/ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA DE TELECOBRANZAS INTEGRADO AL SISTEMA E-GOVERNMENT DE UNA EMPRESA DE RECAUDACIÓN TRIBUTARIA Tesis para optar por el Título de Ingeniero de las Telecomunicaciones, que presenta el bachiller: SALIM ALIAGA PÉREZ ASESOR: Mg. Enrique Larios Vargas Lima, mayo del 2009 Resumen El presente proyecto de tesis consiste en el estudio, diseño e implementación de una Plataforma IVR IP para realizar el pago en línea de los saldos deudores de los contribuyentes, donde estos últimos estarán referidos a los principales tributos de una Empresa de Recaudación Tributaria, mediante el uso de teléfonos móviles o fijos. Para esto se realizará un previo análisis del sistema que tiene implementado la Empresa de Recaudación Tributaria para realizar los cobros de tributos en la actualidad, con lo cual se podrá sentar las bases para la integración de la Plataforma de Telecobranza a sistema mencionado. La Plataforma consistirá en una arquitectura conformada por dos servidores: El primero será una PBX-IP implementada en software libre, el segundo servidor será una Base de Datos que sigue el modelamiento desarrollado en el presente trabajo. Una vez hecha la implementación, ésta será sometida a pruebas de esfuerzo para determinar la cantidad de llamadas y el uso de CPU en el servidor PBX para finalmente dar las conclusiones y recomendaciones del caso. Dedicatoria Esta tesis está dedicada a mis padres Fanny y Salim y a mi abuelita Carmela Atalaya por su constante apoyo, confianza y sobre todo: amor. Agradecimientos Quisiera empezar agradeciendo a Dios por su continuo cuidado y guía; así por la salud que me ha dado para llegar a este punto de mi vida. Quiero agradecer infinitamente a mis padres por su esfuerzo en brindarme la educación que tengo, agradecerles por su cuidado y apoyo, así como su motivación y guía. Quiero agradecerle también a mi abuelita Carmela por su gran ayuda y consejos y gran cariño. Al ingeniero Enrique Larios, mi asesor, por su constante ayuda y consejos en el desarrollo de éste trabajo y sobre todo por su confianza en mí. Al ingeniero Daniel Pizarro, por co-asesorarme y prestarme sus servidores para realizar las pruebas de esfuerzo del presente trabajo. Así también por su buena disposición para ayudarme a generar los resultados finales del proyecto. Al doctor Carlos Silva y al ingeniero David Chávez, por su guía y constante preocupación en el cumplimiento de los objetivos primordiales. A mis profesores, a todos y cada uno de ellos, por haberme brindado las herramientas y conocimientos necesarios para llegar hasta aquí, y finalmente a mis compañeros de promoción y amigos de toda la vida: Sin UDs esta travesía no hubiera sido lo que fue. Gracias por tan buenos momentos y anécdotas. Finalmente, a todos nuevamente…Muchas gracias!!!. Índice Lista de Figuras…………...……..…………………………………………..………….………….......7 Lista de Tablas………..………………..…………………...……….………………….…………..…..9 Introducción…………..………………..…………………...……….……….……………………..….10 Capítulo 1 Marco Teórico……………..…………………...……….……….…………..…………...11 1.1 Sistema e-government………………………….…………………...….……….…..…...…11 1.2 Plataforma de Telecobranza……………….……………………………………..………..14 1.2.1 Call Center…………………………………………………………….……………………18 1.2.2 CTI……………………………………………………………………….….…………...….20 1.2.3 ACD………………………………………………………………………………………....21 1.2.4 IVR……………………………………………………………………….………………….23 1.2.5 VoIP……………………………………………………………….………………...………25 1.2.6 Base de Datos………………..……………………………………………..……………..26 1.3 Integración de la Plataforma de TeleCobranza……….…………………………...……..29 1.3.1 PBX-IP…………………………………………………….…………………...………...…29 Capítulo 2 Análisis del Sistema y Arquitectura de la Solución….………………...…………33 2.1 Análisis de la Problemática…………………………....……………………….………......33 2.1.1 Antecedentes…………………………………….................………….…….……......…33 2.1.2 Problema Central…….……….……………………………………...……………...........34 2.1.3 Objetivos Generales…………….…….……………………………………………...…...34 2.1.4 Objetivos Específicos……………………………….………………………………...…..34 2.1.5 Justificación………………………….………………….……………...……………...…..34 2.2 Descripción de la ERT……………………………………………………………...…….…35 2.2.1 Finalidad y principales funciones de la ERT……………………………………………35 2.2.2 Proceso de cobranza de tributos………………………………………………………...38 2.3 Situación tecnológica actual de la ERT…………………….…………..…………….......39 2.3.1 Tecnologías de automatización de cobranza en la actualidad…………………….…39 2.3.1.1 Servicios de Operaciones en Línea (SOL)…………………………………………...39 2.3.1.2 Central de Consultas………………………………………………...………...............42 2.3.2 Modalidad de interacción e integración de dichas tecnologías……………..….……..50 2.4 Solución al problema....……………………………………….……………………...……..51 2.4.1 Alcances………………….…………………………...……………………………………51 2.4.2 Limitaciones ……………………………….…………………...………………………….51 2.5 Propuesta de la Arquitectura de la Solución……………………………………………...51 2.5.1 Tecnologías de la Solución…………….…………………………………………………53 2.5.1.1 Sistema Operativo…………………………………….………………………………...53 2.5.1.2 PBX-IP…………………………………………………………………...….……………53 2.5.1.3 Lenguaje de Programación………………………………………………………….....54 2.5.1.4 Manejador de Datos…………………………………………………………………….55 2.5.1.5 Asterisk AGI………………………………………………...……………………………55 2.5.1.6 Sincronizador de Bases de Datos……………………………………………………..56 Capítulo 3 Diseño e Implementación de la Solución……………….…………………….……..57 3.1 Diseño de la solución………………………………………………………………………..57 3.1.1 Descripción del servicio…………...……………………………………………………...57 3.1.1.1 Elección del tributo a pagar…………………………………………………………….58 3.1.1.2 Petición de datos……………………………………...………………………………...58 3.1.1.3 Transacción………………………………………………………………………………58 3.1.2 Diagrama de flujo de la solución – Aplicación Telefónica………………...…………..59 3.1.3 Modelo de entidad relación……………………………………………..........................64 3.1.3.1 Diccionario de datos……………...………………………………………………….….65 3.1.4 Diseño de la Aplicación Telefónica………………………………………………………67 3.1.4.1 Identificación……………………………………………………………………………..68 3.1.4.2 Petición de datos….………………………………………………………………...…..69 3.1.4.3 Actualización de datos…………………….……………………………………...…….70 3.1.5 Diccionario de las principales funciones AGI del sistema………………...…………..72 3.1.6 Estimación de tráfico………………………………………………………………………74 3.2 Implementación de la Arquitectura……………………………...…………………………74 3.2.1 Servidor PBX-IP……………………………………………………………………………74 3.2.1.1 Configuración Asterisk…………………………………...……………………………..75 3.2.2 Servidor de Base de Datos……………………………………………………………….76 Capítulo 4 Pruebas de Desempeño…………………………………………………….…………..77 4.1 Introducción…………………………………………………...………………………….…..77 4.2 Resultados…………………………………………………………………………..……..…79 4.2.1 Número de llamadas concurrentes….………………...…………………………….…..79 4.2.2 Uso de CPU……………………………………………...…….…………………………..81 4.3.3 Uso de Memoria …………………………………………………...……………………...82 Conclusiones, Recomendaciones y Trabajos Futuros……………………………………....…83 5.1 Recomendaciones……….…………………………………………...…………………......83 5.2 Trabajos futuros……………………………………………………………………………...84 5.3 Conclusiones………………………………………………………...……………………….84 Bibliografía……………………………..……………………………………………………………….86 Lista de Figuras FIGURA 1-1: AGENCIA GUBERNAMENTAL VIRTUAL………………………....………………...12 FIGURA 1-2: ARQUITECTURA FUNCIONAL DE UN SISTEMA E- GOVERNMENT………………….…………………………………………………………...…………13 FIGURA 1-3: ARQUITECTURA TOPOLÓGICA DE UN SISTEMA E-GOVERNMENT……………………….………………………………………………………...……14 FIGURA 1-4: PROCEDIMIENTO DE COBRANZA PRE COACTIVA……………………………..18 FIGURA 1-5: AQUITECTURA CALL CENTER BASADA EN CTI, ACD y DB………………………………………………………………………….…………...………………...20 FIGURA 1-6: CTI – UNA AQUITECTURA ABIERTA……………………….………………...…….21 FIGURA 1-7: COMUNICACIÓN CON UN CALL CENTER A TRAVÉS DE UN ACD………………………………………………………………………………………………….……22 FIGURA 1-8: FUNCIONAMIENTO LÓGICO DE UN ACD………………………………….………23 FIGURA 1-9: SISTEMA DE DIÁLOGO AUTOMÁTICO…………………………...………………..24 FIGURA 1-10: DIGITALIZACIÓN DE LA SEÑAL DE VOZ…………………………………………25 FIGURA 1-11: ARQUITECTURA ESQUEMÁTICA DE UNA BASE DE DATOS…………………………………………………………………………………………..............27 FIGURA 1-12: ENFOQUE ORIENTADO AL PROCESO………………………………….………..28 FIGURA 1-13: ENFOQUE DE BASE DE DATOS………………………………….………………..28 FIGURA 1-14: INTEGRACIÓN DE LA PLATAFORMA TELECOBRANZA AL SISTEMA E- GOVERNMENT………………………………………………………………...……………………….29 FIGURA 1-15: DIAGRAMA DE BLOQUES DE UNA PBX DIGITAL……………………...….……30 FIGURA 1-16: ARQUITECTURA TOPOLÓGICA BASADA EN PXB IP…………………...……..31 FIGURA 2-1: ESTRUCTURA ORGANIZACIONAL DE LA ERT…………………………………...38 FIGURA 2-2: SESIÓN WEB DE LOS SERVICIOS DE OPERACIONES EN LÍNEA …………………………………………………………………………………………………...………..40 FIGURA 2-3: SESIÓN WEB PARA ADJUNTAR REGISTRO DE DECLARACIÓN …………………………………………………………………………………………………………….41 FIGURA 2-4: PORTADA DEL SOFTWARE PDT…………………………………….…………......42 FIGURA 2-5: OPOCIONES DEL IVR…………………………………………………………………43 FIGURA 2-6: LLAMADAS DEL RUBRO TRIBUTARIO……………………………………….…….45 FIGURA 2-7: LLAMADAS DEL RUBRO INFORMÁTICO…………………………………………..45 FIGURA 2-8: PORCENTAJE DE LLAMADAS TRANSFERIDAS EN AMBOS RUBROS…………………………………………………………………………………………………46 FIGURA 2-9: ÁRBOL DE DECISIÓN DEL IVR…………………………………………...………....47 FIGURA 2-10: PANTALLA DEL AGENTE CON LOS DATOS DEL CONTRIBUYENTE……………………………………………………………………………………...48 FIGURA 2-11: ARQUITECTURA DE LA RED DE LA ERT…………………………………….…..50 FIGURA 2-12: ARQUITECTURA DE LA SOLUCIÓN……………………………………...….……52 FIGURA 2-13: INETRFAZ HUMANA……………………………………………………………….…56 FIGURA 3-1: SESIÓN WEB PARA VALIDACION VISA……………………………………………59 FIGURA 3-2: ÁRBOL DE DECISIÓN DE LA SOLUCIÓN – APLICACIÓN TELEFÓNICA……………………………………………………………………………………………61 FIGURA 3-3: DIAGRAMA DE MODELO DE ENTIDAD RELACIÓN…………………...…….…...64 FIGURA 3-4: ETAPAS DE IDENTIFICACIÓN……………………………………………………….69 FIGURA 3-5: PROCESO DE ACTUALIZACIÓN DE DATOS………………………...….………...71 FIGURA 3-6: TABLAS DEL SISTEMA…………………………………………………….………….76 FIGURA 4-1: ARUITECTURA DE PRUEBAS………………………………………...…….……….78 FIGURA 4-2: LLAMADAS CONCURRENTES……………………………………………………….80 FIGURA 4-3: LOG DEL SIPP………………………………………………………...………….…….80 FIGURA 4-4: LLAMADAS CONCURRENTES – PERIODO TOTAL……………...……...............81 FIGURA 4-5: USO DE CPU……………………………………………………………………………82 FIGURA 4-6: USO DE MEMORIA……………………………………………………...….………….82 Lista de Tablas TABLA 1-1: IDENTIFICACIÓN DE LOS PROCESOS DE NEGOCIO………………………….…17 TABLA 1-2: IDENTIFICACIÓN DE LOS ACTORES DEL ENTORNO DE NEGOCIO……………………………………………..…………………………………………………17 TABLA 3-1 MENSAJES INVOLUCRADOS EN EL ÁRBOL DE DECISIÓN DE LA SOLUCIÓN……………………………….…………………………………………………….…….….62 TABLA 3-2 TABLA CONTRIBUYENTE…..……………………….……..………………….………..65 TABLA 3-3 TABLA IGV_MENSUAL……..……………………………..……….…………….………66 TABLA 3-4 TABLA ISC………………….…………………………………………………….………..66 TABLA 3-5 TABLA RENTA_ANUAL….……………………………………..………………..………67 TABLA 3-6 VARIABLES REQUERIDAS PARA REALIZAR EL PAGO EN LÍNEA ...………………………………………………………………………………………….……………….70 TABLA 3-7 FUNCIÓN IvrMenuGetOption………………………………...…………………….……72 TABLA 3-8 FUNCIÓN IvrMenuGetNumber…………………………………………………….…….73 TABLA 3-9 CONFIGURACIÓN SIP.CONF……………………….……..…………………….……..75 TABLA 3-10 CONFIGURACIÓN EXTENSIONS.CONF……………………………………….……76 TABLA 4-1 COMANDO SIPP EJECUTADO………………………………………..……….…….…79 10 Introducción La explosiva entrada de la tecnología en cada aspecto de la vida del ser humano ha cambiado su manera de vivir, de trabajar y el cómo las compañías hacen negocios (y como el gobierno estatal llega a las personas). Desde la creación de la seguridad social, hay ahora una oportunidad real de ‗reinventar‘ al gobierno desde el punto de vista de cómo este llega al ciudadano para brindarle los diferentes servicios públicos. Con la ayuda de las tecnologías emergentes de telecomunicaciones, los gobiernos se están dando cuenta que aplicando los mismos principios y tecnologías que han potenciado la revolución de los negocios (e-business), ellos pueden llevar a cabo una transformación similar. Ellos han reconocido la necesidad de cambiar la manera de hacer negocios, para proporcionar servicios e información enfocada en el ciudadano. El resultado: el emergente e-government. 11 Capítulo 1 Marco Teórico 1.1 Sistema e-government El e-government o gobierno electrónico está referido al uso de herramientas y sistemas, implementadas en base a tecnologías de la información y comunicaciones (TICs), las cuales en conjunto con los conocimientos de los procesos internos de gobierno pueden atender una amplia variedad de fines: proveer de una mejor entrega de servicios públicos a los ciudadanos, mejorar la interacción con empresas e industrias, otorgar poderes a los ciudadanos a través del acceso a la información, o hacer más eficiente la administración gubernamental. Los beneficios resultantes pueden ser menos corrupción, incremento de la transparencia, mejor convivencia, crecimiento de los ingresos y/o reducción de costos [WOR2008]. Un Sistema e- government efectivo también involucra la reconsideración de los procesos y organizaciones estatales, y un cambio en el comportamiento para que los servicios públicos sean entregados más eficientemente a los ciudadanos cuando estos los necesiten. La figura 1-1 ilustra la interacción entre el ciudadano y las entidades gubernamentales, pero desde un punto de vista virtual por medio de las TICs. 12 FIGURA 1-1: AGENCIA GUBERNAMENTAL VIRTUAL Fuente: ―Una Nueva Relación con el Ciudadano‖ [EUR2008] En la figura 1-2 se aprecia la arquitectura de un sistema e-government donde se destaca la dualidad de éste, es decir la interacción con los diferentes servicios interactivos ofrecidos por la entidad gubernamental a los ciudadanos a través de la utilización de las TICs. Los ciudadanos podrán acceder a estos servicios por medio de canales de múltiple acceso. Y por otro lado está la fase de transacciones donde tienen lugar las solicitudes de atención de los ciudadanos para con las entidades gubernamentales, autoridades locales, departamentos gubernamentales; para lo cual se realizan la autenticación para el acceso a los servicios, se brinda seguridad y circulan las transacciones propiamente dichas en ambos sentidos, etc. El Gateway Gubernamental provee bloques genéricos para la creación de servicios extremo a extremo, un motor de enrolamiento y registración para la autenticación, un motor de transacciones para enrutamiento, motor de pagos relacionados a facturación, un sistema de Mail seguro para comunicaciones entre ciudadano y gobierno. 13 FIGURA 1-2: ARQUITECTURA FUNCIONAL DE UN SISTEMA E-GOVERNMENT Fuente: ―XML: la relevancia para e-gov‖ [BOY2008] En la figura 1-3 se aprecia la arquitectura de un sistema e-government, pero desde un punto de vista de la topología general de red que implementaría este sistema. Vemos que la interacción del contribuyente (organizaciones, agentes, ciudadanos) puede ser a través de tecnologías móviles y también por medio de portales web desde la ubicación de éstos. Los resultados de la interacción circularán por internet y llegarán al Gateway gubernamental en forma de transacciones, donde serán derivadas a las instalaciones del sistema departamental de gobierno. Es en esta etapa donde se brindan los diferentes servicios del gobierno como por ejemplo Telecobranza. 14 FIGURA 1-3: ARQUITECTURA TOPOLÓGICA DE UN SISTEMA E-GOVERNMENT Fuente: ―XML: la relevancia para e-gov‖ [BOY2008] 1.2 Plataforma de Telecobranza. También llamado sistema de recaudación automatizada (Automated Collection System, ACS). El ACS controla el balance del Sistema de Cobro por Datos Integrados (Integrated Data Retrieval System, IDRS) requiriendo contacto telefónico para tal propósito. El sistema facilita la organización del proceso de gestión de cobros y el seguimiento de los adeudos del cliente tanto en empresas financieras como comerciales (productos y servicios) y para garantizarlo permite:  Aplicar distintas estrategias según condiciones del cliente.  Asignar tareas de manera automática a los gestores. 15  Gestionar clientes morosos.  Registrar las respuestas de los clientes después de un contacto.  Conservar la historia de los clientes.  Visualizar e imprimir reportes. Se convertirá en una herramienta para que el deudor reciba un tratamiento personalizado, porque utilizará como principal fuente de información la existente en la Base de Datos de la entidad interesada en el cobro de las deudas, información que deberá ser actualizada diariamente a través de la importación de datos y dará acceso a una buena cantidad de detalles relevantes del cliente y sus cuentas:  Datos del cliente (persona natural o jurídica).  Datos de las deudas del cliente.  Datos de las personas asociadas al cliente (codeudores y contactos).  Datos de las refinanciaciones o convenios de pago solicitados por el cliente.  Datos de los Procesos Jurídicos iniciados al cliente con cierta cantidad de días de atraso.  Historia del cliente. Para el uso del sistema se definen dos tipos de usuarios: el Supervisor y el Operador. El Supervisor como máximo responsable del correcto funcionamiento del sistema deberá asumir las siguientes tareas:  Actualizar los Clasificadores.  Crear y asignar Agendas.  Enviar cartas o correo electrónico a clientes morosos.  Crear de listas de contacto.  Dar seguimiento a los procesos jurídicos iniciados.  Tramitar y responder las solicitudes de refinanciación de los clientes.  Crear el guión para orientar fundamentalmente a los nuevos operadores en su trato con los clientes.  Controlar los gestores que tienen acceso al sistema. 16  Limpiar la historia de los clientes que llevan un año o más tiempo inactivos (no se le hace gestión de cobro).  Evaluar efectividad del trabajo de los Operadores a través de los reportes generados por el sistema. El Operador será el encargado de utilizar las estrategias generadas por el Supervisor para gestionar a los clientes que le hayan sido asignados y lograr que cumplan sus obligaciones de pago apoyándose en toda la información que le proporciona el sistema, que lo guiará en la ejecución las tareas que tiene que realizar en el día. El Operador tendrá acceso a la siguiente información [BOY2008], [BIB2008]:  Detalles del cliente  Detalles de las deudas del cliente.  Detalles de los contactos del cliente.  Historia del cliente. Ahora presentaremos la plataforma de TeleCobranza a ser implementada, la cual habilita la gestión de Saldos Deudores de la Intendencia Regional de una ciudad, Dependencia de Medianos y Pequeños Contribuyentes. Este aplicativo permite la gestión mediante un tercero (por ejemplo una empresa como ATENTO) de un determinado universo de deuda que no era sujeto de ser trabajado por el área de Control de Deuda de dicha dependencia dado el gran volumen de documentos que maneja. De acuerdo con lo mencionado en los párrafos anteriores en la tabla 1-1 se identifica el proceso de negocio, y en la tabla 1-2 se definen las funciones del supervisor (Analista de Control de Deuda) y del operador (Entidad de Gestión de Deuda). 17 TABLA 1-1: IDENTIFICACIÓN DE LOS PROCESOS DE NEGOCIO Número Proceso de Negocio 1 Proceso de Remisión de Deuda a TeleCobranza TABLA 1-2: IDENTIFICACIÓN DE LOS ACTORES DEL ENTORNO DEL NEGOCIO Número Actor Roles/Responsabilidades 1 Analista de Control de Deuda Descarga y Selección de los Documentos con Saldo de Deuda pendiente de pago a ser remitidos a Telecobranza Remisión de Pagos a Documentos remitidos a Telecobranza Cierre del Proceso de Envío 2 Entidad de Gestión de Deuda Recibir la información de los Documentos a ser Gestionados Recibir la información de Pagos asociados a los documentos que se encuentran en fase de Gestión. En la figura 1-4 se muestra el cuadro pictórico del modelamiento del proceso de negocio. 18 FIGURA 1-4: PROCEDIMIENTO DE COBRANZA PRE COACTIVA Fuente: ―Public Sector Data Management in a Developing Economy‖ [HEI2003] 1.2.1 Call Center El call center o centro de llamadas es una oficina centralizada usada para propósitos de transmisión y recepción de grandes volúmenes de consultas por teléfono. Un call center es una herramienta de comunicación y relación con los clientes, operado por una compañía u organización a través de ‗personas humanas‘ ayudadas por automatización computacional; que atiende llamadas entrantes (INBOUND) o salientes (OUTBOUND), que son generadas utilizando el teléfono como medio de comunicación básico. Es una arquitectura que en los últimos años se está convirtiendo en el principal medio de tratar con los clientes y usuarios, lo cual tiene gran impacto en la retención y satisfacción del cliente; ya que capta información importante del contribuyente y lo que éste necesita. Beneficios: Mejora en la eficiencia, incrementa las horas de operación, reduce costos, gran flexibilidad, centralización de recursos, coordinación de teléfono, e-mail y 19 peticiones web. En la administración: reduce los tiempos y costos de entrenamiento para el nuevo staff, mejora el manejo de llamadas y tiempos de respuesta, gran consistencia y precisión de información dad a los clientes [GOR1999]. Los avances y cambios en la tecnología han contribuido a la disponibilidad de diversas y nuevas características que se refleja en la operación de los call center cuando se las integra a este servicio, las cuales incrementan su eficiencia y mejoran las oportunidades para servir a los clientes y potencian a los representantes de servicio de los clientes (Customer Service Representatives, CSR) con la capacidad de mejorar la gestión de la interacción con el cliente. La mayoría de los call centers usan varias aplicaciones y sistemas con funciones especializadas. En paralelo con estos avances en tecnología que son internos al call center, los servicios ‗inteligentes‘ de red ofrecidos por los ISPs hacen posible el enrutamiento de llamadas basados en un amplio rango de criterios como prefijos o códigos de área, servicio de identificación de número discado (Dialed Number Identification Service, DNIS), día de la semana y otros parámetros que están bajo el control de la administración del call center. Entre las tecnologías tradicionales que se ocupan en un call-center están: la infraestructura telefónica (conmutador, teléfonos, diademas o cintillos), la infraestructura de datos (computadoras, bases de datos, CRM), el distribuidor automático de llamadas entrantes (ACD), un sistema de respuesta interactiva de voz (IVR), un grabador de llamadas (que muchas veces también graba las pantallas de los agentes), y si el call-center es de salida, un marcador o discador, asistido, progresivo o automático y predictivo. Pero básicamente las tecnologías que son requeridas para soportar una efectiva y alta productividad en la operación del call center son las siguientes [DUA2003]:  Computer telephony integration (CTI)  Call distribution technology (ACD)  Database software (BD) La figura 1-5 muestra una arquitectura Call Center basada en tecnología CTI, ACD y una base de datos. En esta arquitectura cualquier llamada al sistema es enviada al distribuidor automático de llamadas (Automatic Call Distribution, ACD). Antes que el ACD distribuya la llamada, el IVR puede interactuar con el llamante para pre-procesar 20 la llamada, y así recuperar los registros del cliente de una base de datos. Entonces el ACD distribuirá la llamada a un agente disponible y al mismo tiempo que timbra el teléfono se mostrará la información del cliente en la pantalla del agente (característica ‗screen pop‘ de CTI). Si la llamada se transfiere a otro agente, los registros del cliente son también transferidos a la pantalla del nuevo agente. FIGURA 1-5: AQUITECTURA CALL CENTER BASADA EN CTI, ACD Y DB Fuente: ―Computer Telephony Integration and its Applications‖ [SHE1998] 1.2.2 CTI CTI (Computer Telephony Intergration) es la tecnología que permite la integración y gestión de los diferentes canales de comunicación entre cliente y empresa, principalmente mediante la combinación de la computadora y el teléfono, el cual transformará a la computadora personal de un dispositivo de procesamiento de información a una poderosa plataforma de comunicaciones. CTI es el ―arte‖ de inteligentemente enlazar y combinar estas herramientas para crear sistemas que nos permitan usar la tecnología para nuestra ventaja. El punto fuerte de esta tecnología es el vertiginoso incremento del acceso a la información que necesitemos, cuando la necesitemos. En la figura 1-6 se aprecia que el rápido desarrollo de los sistemas de red y el incremento de la demanda del ancho de banda han realzado la importancia de CTI. El 21 impacto de los sistemas abiertos, nuevas tecnologías tales como internet, VoIP y computación inalámbrica están alterando los modelos fundamentales de negocios. FIGURA 1-6: CTI – UNA AQUITECTURA ABIERTA Fuente: ―Call Center Operation: Design, Operation, and Maintenance‖ [SHA2003] Enlazando las telecomunicaciones a la capacidad de procesamiento e interfaz gráfica de usuario (GUI, Graphic User Interface) de las computadoras, permitirá nuevas formas de comunicaciones y accesos más robustos para los tipos de comunicaciones existentes (voz, datos asíncronos, fax, acceso remoto a LANs, acceso a internet y servicios en línea). Las principales funciones de CTI son control de llamadas, procesamiento del medio y administración de la información del cliente [BAT2002]. 1.2.3 ACD ACD (Automatic Call Distribution) o distribución automática de llamadas es una función llevada a cabo por muchos componentes –software y hardware—en un call center. ACD esencialmente involucra tomar las llamadas entrantes y derivarlas al destino correcto –al escritorio de cómputo del CSR. En otras palabras es un servicio que 22 permite que una llamada sea ubicada en cola de espera hasta que un empleado esté disponible para tomar la llamada. Detrás de esta simple descripción de la función de un ACD están un número de procesos y tecnologías subyacentes, las cuales incluyen:  Sistemas de voz, mail y Auto-attendant routing  IVR  Redes públicas y Software de administración. En la figura 1-7 se aprecia como es la secuencia de la comunicación con un call center a través de un ACD. FIGURA 1-7: COMUNICACIÓN CON UN CALL CENTER A TRAVÉS DE UN ACD Fuente: ―Call Center Operation: Design, Operation, and Maintenance‖ [SHA2003] En la figura 1-8 se muestra el funcionamiento lógico de un ACD a momento de recibir una llamada. 23 FIGURA 1-8: FUNCIONAMIENTO LÓGICO DE UN ACD Fuente: ―ACD User Guide‖ [FUL2008] 1.2.4 IVR Sirviendo como un puente entre las personas y las bases de datos computacionales, los sistemas de respuesta interactiva (Interactive Voice Response, IVR) conectan a los El llamante marca el número piloto ACD El programa ACD verifica si hay algún agente disponible Al menos un agente en lista está disponible Todos los agentes en lista están ocupados Transfiere la llamada al agente disponible Reproduce un audio indicando que la llamada será puesta en espera hasta que haya algún agente disponible, transfiere la llamada a cola El programa ACD verifica cada x segundos la disponibilidad de los agentes, y si tiene éxito transfiere la llamada al agente El agente responde la llamada Si el agente no responde la llamada, el agente es quitado de la lista y la llamada es ruteada a la cola para esperar por un nuevo agente disponible 24 usuarios telefónicos con la información que ellos necesitan, desde donde estén y en cualquier momento. Los sistemas de IVR permiten a los clientes obtener y manipular información en una base de datos computacional, tal como recuperar el balance de una cuenta o transferencia de fondos de una cuenta a otra. Están principalmente basados en el mismo tipo de tecnología que un buzón de voz [BAT2002]. Consiste en un sistema telefónico que es capaz de recibir una llamada e interactuar con el humano a través de grabaciones de voz que, el cual está orientado a entregar y/o capturar información automatizada a través del teléfono permitiendo el acceso a los servicios de información y operaciones autorizadas. Para brindar mejores servicios los sistemas IVR emplean:  DTMF (Dual Tone Multi Frequency): Interfaz de usuario propia de la telefonía, es la tecnología de tonos utilizada para el marcado.  TTS (Text To Speech): Le da capacidad de transformar texto a audio que escucha el operador.  ASR (Automated Speech Recognition): Le da la capacidad de reconocer las palabras del contribuyente y aceptarlas como órdenes en lugar de entradas DTMF. En la figura 1-9 se muestra el esquema de un sistema de diálogo automático. FIGURA 1-9: SISTEMA DE DIÁLOGO AUTOMÁTICO Fuente: ―Síntesis de Voz y Sistemas de Dialogo Automático‖ [FLO2007] 25 1.2.5 VoIP VoIP (Voice over Internet Protocol) es el acrónico en inglés para denotar voz sobre el protocolo de internet (IP), o en términos más comunes el transporte de servicios telefónicos soportados por redes de datos. Para lograr esto, la señal de voz proveniente de una fuente acústica hay que convertirla en una señal eléctrica (voltaje o corriente) por medio de un transductor. Luego hay que digitalizar esta señal para poderla transmitir en tramas/paquetes. El proceso de digitalización consiste en el acondicionamiento (filtraje), muestreo y retención (S&H), cuantización y codificación. Esto se aprecia en la figura 1-10. En la transmisión habrá que aplicar algún algoritmo de compresión (codecs) para utilizar eficientemente el ancho de banda del canal de transmisión, encriptar (seguridad) y finalmente empaquetar. Adicionalmente mencionaremos que la mayoría de las aplicaciones VoIP van sobre UDP, ya que al ser estas aplicaciones de tiempo real, se necesitan menos retransmisiones para evitar el retardo. FIGURA 1-10: DIGITALIZACIÓN DE LA SEÑAL DE VOZ Fuente: ―PCM‖ [HUA2007] 100101011 f>2fm FPB fm fK x v Timer ADC - TX PCM t f(t) PCM S&H Cuantizador fq Codificador v Conversor //-Serie 26 1.2.6 Base de Datos Una base de datos es una colección o conjunto de datos integrados y relacionados entre sí, almacenados en un soporte informático de acceso directo, con redundancia controlada y una estructura con la que puede accederse a ellos automáticamente e independientemente de los programas que gestionan esos datos. Las principales características de una base de datos son: la independencia de los datos, es decir los datos no dependen del programa que los gestiona y por lo tanto cualquier aplicación puede recurrir para consultas o manipulación de ellos; la reducción de la redundancia, que no es otra cosa que la existencia de duplicación de datos, donde una vez disminuido esto conseguiremos un mayor aprovechamiento del espacio de almacenamiento y además se evita que exista las inconsistencia entre los datos, que se presentan cuando se encuentran datos contradictorios; y por último la seguridad, que es básico se implemente en los sistemas de bases de datos para proteger la integridad y confidencialidad del conjunto de datos. Los recursos de una base de datos la componen las personas, que administran y consultan la información almacenada en estos sistemas; el hardware, que sirve de almacén de los datos y al mismo tiempo permite presentar estos; el software, nos permite manejar lógicamente los datos y son conocidos en términos generales como sistemas gestores de bases de datos SGBD o DBMS (Data Base Management System); y por último los datos que viene a ser la esencia de estos sistemas. Una base de datos tiene distintos niveles que componen lo que conocemos como arquitectura de Base de Datos: El Nivel de físico, que es el nivel real de los datos almacenados; es decir cómo se almacenan estos, que puede ser en forma de registros u otras variantes como lo son las tablas. Dado la complejidad de gestión de los datos a este nivel, es usado por muy pocas personas que deben estar calificadas. Este nivel se menciona al esquema físico que está asociada a la representación de los datos. El Nivel Conceptual, a este nivel se ve a la base de datos desde el punto de vista del mundo real, es decir se trata a la entidad u objeto representado, sin importar como está representado o almacenado, por lo que se dice que este nivel está asociado al Esquema Conceptual. Por último el Nivel Visión, está relacionado con lo que los usuarios deben ver, es decir tienen acceso a pequeñas partes de toda los datos, a 27 diferencia del nivel Conceptual que presenta toda la base de datos. Al igual que los dos niveles anteriores este nivel está asociado al Esquema Visión. En la figura 1-11 se presenta un esquema de la arquitectura a tres niveles: FIGURA 1-11: ARQUITECTURA ESQUEMÁTICA DE UNA BASE DE DATOS Fuente: ―Introducción a Base de Datos‖ [LAR2007] Desde el punto de vista de la organización lógica las bases de datos se clasifican en: Jerárquicas, Relacionales (Oracle, MySQL, DB2, etc). Desde el punto de vista de número de usuarios como Mono-usuarios y Multi-usuarios [UTA2007], [LAR2007]. Por último diremos que antes de las bases de datos, los datos e información tenían un enfoque orientado al proceso de estos, lo que hacía tedioso y complicado la consulta o manipulación de estos, esto se representa en la figura 1-12. Pero desde la aparición de las bases de datos el enfoque cambia radicalmente en cuanto a la gestión, manipulación y acceso a los datos. Esta evolución se presenta en la figura 1-13, donde se aprecia que el proceso interno (es decir el que no aprecia el contribuyente y se da entre los datos en sí y los resultados), es más estructurado y ordenado, lo que conlleva una alta eficiencia. 28 FIGURA 1-12: ENFOQUE ORIENTADO AL PROCESO Fuente: ―Fundamentos‖ [ADO1985] FIGURA 1-13: ENFOQUE DE BASE DE DATOS Fuente: ―Fundamentos‖ [ADO1985] 29 1.3 Integración de la Plataforma de TeleCobranza Como mencionamos en el subcapítulo 1.1, la Plataforma de TeleCobranza será integrada al sistema e-government, más específicamente al sistema departamental gubernamental de gobierno de la Entidad de Recaudación Tributaria (ERT). Las transacciones que lleguen y sean aceptados por el Gateway Gubernamental serán luego derivadas por el servidor PBX-IP, de acuerdo al tipo de servicio que requieran, a los diferentes módulos implementados en todo el sistema e-government, como lo es la Plataforma de Telecobranza. Esto se aprecia en la figura 1-14. FIGURA 1-14: INTEGRACIÓN DE LA PLATAFORMA TELECOBRANZA AL SISTEMA E-GOVERNMENT Fuente: [GRE2002] 1.3.1 PBX-IP Como preámbulo explicaremos lo que es una PBX (Private Branch eXchange) , la cual es un sistema de conmutación propietario que permite a los usuarios comunicarse internamente y compartir troncales hacia la PSTN y a otras PBXs. Una troncal es 30 simplemente un medio físico (generalmente cobre) que es capaz de soportar una conversación. Los sistemas de conmutación de circuitos mantienen troncales comunes para su uso compartido. Una PBX proporciona a los usuarios una variedad de características como buzón de voz, ACD, así como también características en el manejo de llamadas. Como antecedente a la definición de IP-PBX clarificaré con un poco más de detalle la arquitectura de una PBX digital convencional, la cual se muestra en la figura 1-15. Esta tiene por un lado conexiones para teléfonos propietarios digitales y analógicos, y en algunos sistemas, interfaces BRI (Basic Rate Interface) RSDI y dispositivos IP, los cuales están contenidos en tarjetas circuitales que se ensamblan en slots y conectan en la parte posterior de la PBX, es decir es un sistema modular. El procesador, el equipamiento común, y las tarjetas de líneas y troncales están conectadas a través de buses, los cuales controlan las tarjetas y pasan la información binaria de línea en línea y de línea a troncal por medio de la implementación de conmutación de fábrica basado en multiplexación por división de tiempo (TDM). Una PBX digital se conecta a la PSTN a través de varios tipos de troncales, los cuales pueden incluir a los análogos de doble via, marcado interno analógico directo, T1/E1 e interfaces PRI (Primary Rate Interface) ISDN. Esta también se puede conectar con otras PBXs y periféricos y en algunos sistemas a través de troncales IP o ATM. FIGURA 1-15: DIAGRAMA DE BLOQUES DE UNA PBX DIGITAL Fuente: [GRE2002] 31 Una PBX-IP opera en un servidor usando la arquitectura de bus estándar. Este no tiene la necesidad de implementar conmutación por fábrica, ya que toda la conmutación de datos se lleva a cabo en la red, usualmente a través de switches Ethernet. Como se muestra en la figura 1-16, la PBX IP puede fácilmente ser distribuida sobre una red de área amplia (WAN, Wide Area Network) con la condición de que la red tenga suficiente ancho de banda y funcionalidades de calidad de servicio (QoS, Quality of Service) para soportar telefonía IP. Como se mencionó anteriormente con la PBX digital tradicional opera sobre dos redes: una para voz y otra para datos. En lugar de dos redes separadas, solamente una red es necesitada si la voz es paquetizada (VoIP) y es enviada sobre la red de datos. Bueno una IP PBX, entre otras funcionalidades, lleva a cabo esto último al comportarse como híbrido entre un switch/router y una PBX que maneja voz sobre IP. FIGURA 1-16: ARQUITECTURA TOPOLÓGICA BASADA EN PXB IP Fuente: [GRE2002] Como se mencionó anteriormente las PBX tradicionales trabajan con redes por separado: una para voz y otra para datos. En cambio las PBX IP, en lugar de dos redes separadas, solamente necesitaran de una dado que paquetizan la voz (VoIP) 32 para luego enviarla sobre la red de datos; esto es posible ya que la PBX IP son un híbrido de un switch/router y una PBX tradicional que maneja voz sobre IP [SIL2008]. En suma cumple las mismas funciones que una PBX tradicional pero difiere de esta en muchos aspectos:  Es probable que una IP PBX corra sobre una plataforma servidor con una arquitectura bus abierta comparada a una PBX tradicional, la cual tiene una arquitectura de bus propietaria.  Es probable que una IP PBX corra un sistema operativo comercial tal como Windows NT, Linux o Unix en lugar de un sistema operativo embebido propietario para PBX.  Es probable que una IP PBX tenga una simple conexión Ethernet hacia los teléfonos IP, reemplazando de esta manera la estructura de interfaces de líneas de una PBX tradicional.  Es probable que una IP PBX esté conectada a otros switches a través de una conexión troncal IP [ABR2003]. 33 Capítulo 2 Análisis del Sistema y Arquitectura de la Solución En este capítulo se describirá el giro de la ERT en cuanto a sus servicios de automatización que brinda y se hará una propuesta de la arquitectura de la solución sobre la cual se hará un diseño e implementación posterior. Además se describirá las tecnologías implicadas en esta. 2.1 Análisis de la Problemática 2.1.1 Antecedentes  Tradicionalmente, la interacción entre los ciudadanos o empresas y una agencia del gobierno (en este caso una Empresa de Recaudación Tributaria, ERT), se lleva a cabo en una oficina gubernamental. Lo cual lleva un prolongado tiempo en la gestión y procesamiento de los trámites y servicios afines al campo de la administración tributaria y aduanera. Apreciados tanto en el lado del Contribuyente, cuando éste los solicita o requiere, como en el ámbito del Analista de Control de los servicios y trámites a ser brindarlos.  La crisis económica en la sociedad moderna, ha producido en las entidades de recaudación de tributos y empresas comerciales y financieras en general, un aumento en la morosidad de los pagos de sus clientes.  El gran número de consultas informáticas que son derivados a agentes tributarios, lo que refleja las dificultades que tiene el contribuyente para el 34 manejo del PDT, el cual es indispensable para utilizar los Servicios de Operaciones en Línea (SOL). 2.1.2 Problema Central De lo mencionado anteriormente se infiere que el problema central son las limitadas opciones que tiene el contribuyente para realizar los pagos de sus tributos, sin tener la necesidad de acudir a la sucursal de la ERT para realizar el pago de los mismos. 2.1.3 Objetivos Generales El objetivo principal es el desarrollo de una plataforma de TeleCobranza que permita de manera interactiva y en línea la gestión de Saldos Deudores, sirviendo de medio para los pagos que efectúen los contribuyentes. 2.1.4 Objetivos Específicos  Automatizar el (los) servicio(s) utilizando tecnologías de CTI, a través del uso de IVRs.  Integrar la Plataforma de TeleCobranza al Sistema e-government de la ERT para atender los servicios propuestos.  Hacer que la Plataforma de TeleCobranzas logre una gestión satisfactoria tanto para la ERT como para el tributante a través de técnicas de interacción telefónica. 2.1.5 Justificación  Con la disponibilidad y desarrollo de las TICs, es posible localizar los centros de servicios más cerca de los clientes. Tales centros pueden consistir de una agencia desatendida del gobierno accesible a los clientes a través de tecnologías móviles como el celular, la computadora personal, PDAs, etc. En este caso en particular brindar el servicio de pago de tributos utilizando TICs, más específicamente a través de telefonía móvil o fija. 35  Disminuir el excesivo tiempo dedicado normalmente a los trámites gestionados o servicios utilizados por el tributante, el cual es consecuencia de los abusos burocráticos que se presentan en el transcurso del trámite o servicio requerido.  Hacer más eficiente la labor de la ERT al brindarle herramientas dinámicas para la administración, fiscalización y recaudación de tributos.  Como consecuencia de los párrafos anteriores se ve claramente los roles de las Telecomunicaciones, en el sentido que provea de recursos y brinde servicios a la población, mientras al estado le permita adecuarse a la tendencia actual de entregar productos y servicios afines a este tanto a los ciudadanos como a la industria.  La idea de crear un sistema computacional que permita organizar estratégicamente la gestión de cobros, proveyendo una buena cantidad de detalles relevantes del cliente y sus cuentas, para asegurar un trato personalizado y aumentar la efectividad de los cobros. 2.2 Descripción de la ERT Este subcapítulo presenta la finalidad y principales funciones y atribuciones de la ERT hipotética, desde el punto de vista institucional. Así como también la descripción general de las principales actividades relacionadas a la recaudación tributos que esta administra, y finalmente se verá como se compone la estructura organizacional de la ERT [SUN2009]. 2.2.1 Finalidad y principales funciones de la ERT La Entidad de Recaudación Tributaria con las facultades y prerrogativas que le son propias en su calidad de administración tributaria, tiene por finalidad:  Administrar, fiscalizar y recaudar los tributos internos, con excepción de los municipales, y desarrollar las mismas funciones respecto de las aportaciones al Seguro Social de Salud (ESSALUD) y a la Oficina de Normalización Previsional (ONP), a las que hace referencia la norma II del Título Preliminar del Texto Único Ordenado del Código Tributario y, facultativamente, respecto también de obligaciones no tributarias de ESSALUD y de la ONP, de acuerdo a lo que por convenios interinstitucionales se establezca. 36  Proponer la reglamentación de las normas tributarias y participar en la elaboración de las mismas.  Proveer servicios a los contribuyentes y responsables, a fin de promover y facilitar el cumplimiento de sus obligaciones tributarias.  Las demás que señale la ley. En cuanto a sus funciones y atribuciones le compete a la ERT:  Proponer al Poder Ejecutivo los lineamientos tributarios para la celebración de acuerdos y convenios internacionales, así como emitir opinión cuando ésta le sea requerida.  Celebrar acuerdos y convenios de cooperación técnica y administrativa en materia de su competencia.  Promover, coordinar y ejecutar actividades de cooperación técnica, de investigación, de capacitación y perfeccionamiento en materia tributaria, en el país o en el extranjero.  Otorgar el aplazamiento y/o fraccionamiento para el pago de la deuda tributaria, de acuerdo con la Ley.  Solicitar, y de ser el caso ejecutar, medidas destinadas a cautelar la percepción de los tributos que administra y disponer la suspensión de las mismas cuando corresponda.  Resolver asuntos contenciosos y no contenciosos y, en este sentido, resolver en vía administrativa los recursos interpuestos por los contribuyentes o responsables; conceder los recursos de apelación y dar cumplimiento a las Resoluciones del Tribunal Fiscal, y en su caso a las del Poder Judicial.  Sancionar a quienes contravengan las disposiciones legales y administrativas de carácter tributario, con arreglo a Ley.  Desarrollar programas de información, divulgación y capacitación en materia tributaria y aduanera.  Ejercer las demás funciones que sean compatibles con la finalidad de la ERT. La ERT cuenta con la siguiente estructura orgánica: 37  ALTA DIRECCIÓN:  Superintendencia Nacional de Administración Tributaria  Superintendencia Nacional Adjunta de Tributos Internos  COMITÉ DE ALTA DIRECCIÓN  ÓRGANO DE CONTROL:  Oficina de Control Interno  ÓRGANOS DE APOYO:  Secretaría General  Instituto de Administración Tributaria  ÓRGANOS DE LÍNEA: DEPENDIENTES DE LA SUPERINTENDENCIA NACIONAL ADJUNTA DE TRIBUTOS INTERNOS  Intendencia de Principales Contribuyentes Nacionales  Intendencia Regional Lima  Intendencias Regionales (desconcentradas)  Oficinas Zonales (desconcentradas)  ÓRGANOS DE SOPORTE  Intendencia Nacional de Administración  Intendencia Nacional de Cumplimiento Tributario  Intendencia Nacional de Estudios Tributarios y Planeamiento  Intendencia Nacional de Recursos Humanos  Intendencia Nacional de Servicios al Contribuyente  Intendencia Nacional de Sistemas de Información  Intendencia Nacional Jurídica Un esquema tipo árbol de esta estructura orgánica se muestra en la figua 2.1. 38 FIGURA 2-1: ESTRUCTURA ORGANIZACIONAL DE LA ERT Fuente: [SUN2009] 2.2.2 Proceso de cobranza de tributos Este se lleva a cabo a través de varias modalidades. Está la manera tradicional, en la que el contribuyente tiene que acercarse a una sucursal de la ERT, para que sea atendido y guiado personalmente en la gestión de los trámites que necesite realizar. Es decir tendrá que llenar padrones, formularios, etc. dependiendo del trámite que desee realizar. 39 Por otro lado el sistema e-government de la ERT brinda Servicios de Operaciones en Línea (SOL) integrados en su portal web, así como también una Central de Consultas de Atención Telefónica Personalizada; los cuales facilitan a los contribuyentes el cumplimiento de sus obligaciones tributarias. Los Servicios de Operaciones en Línea (SOL), se basan en el uso de un software informático desarrollado por la ERT llamado Programa de Declaración Telemática (PDT) que genera Registros de Declaraciones en base a un tributo especificado, luego se adjunta esta declaración en la sesión web de pago en línea. Por otro lado la ERT cuenta con una Central de Consultas que brinda una atención telefónica personalizada, para así automatizar la consulta e invocación a los sistemas existentes para las llamadas más frecuentes, de manera que su atención sea en la mayoría de casos sin intervención de los agentes (IVR). Y en aquellos casos en que sea necesaria la participación del agente, también se automatice la consulta de los datos más frecuentes (CTI). Esto da como resultado la disminución de los tiempos de atención, así como una mejora en la calidad de la misma. 2.3 Situación tecnológica actual de la ERT En este subcapítulo se describe con más detalle las modalidades de automatización que actualmente se llevan a cabo para la recaudación de tributos, las cuales facilitan el cumplimiento tributario. 2.3.1 Tecnologías de automatización de cobranza en la actualidad Como se mencionó en el subcapítulo anterior, actualmente hay dos innovaciones tecnológicas en cuanto a los procesos internos, los cuales implementan aplicaciones de auto servicio (self-service) para que el ciudadano pueda realizar trámites completos en línea. 2.3.1.1 Servicios de Operaciones en Línea (SOL) Esta funcionalidad se brinda través de sesiones web, las cuales están disponibles en el portal web de la ERT. En la figura 2-2 se muestra la página de inicio de sesión, para 40 lo cual el contribuyente debe haber proporcionado su RUC y contraseña SOL, y elegir la opción ―Declarar y pagar con PDT‖. FIGURA 2-2: SESIÓN WEB DE LOS SERVICIOS DE OPERACIONES EN LÍNEA Fuente: [SUN2009] Previamente con ayuda del software PDT se debió generar los diferentes Registros de Declaraciones dependiendo del tributo que el contribuyente seleccione, para así poder ajuntar la Declaración al momento de realizar el pago en línea, esto se aprecia en la figura 2-3. 41 FIGURA 2-3: SESIÓN WEB PARA ADJUNTAR REGISTRO DE DECLARACIÓN Fuente: [SUN2009] Este software consta de un Módulo Integrador que es el módulo que maneja las opciones de uso común de todas las declaraciones generadas por PDT como son, entre otras, el registro de declarantes, el generador de envíos, el administrador de usuarios, reportes y copias de seguridad y el actualizador de parámetros; y de los Módulos Independientes, donde cada uno de estos contiene a las distintas declaraciones determinativas e informativas que la administración tributaria pone a disposición de los contribuyentes para el cumplimiento de sus obligaciones tributarias, más específicamente los Módulos Independientes son los diferentes tributos internos del Gobierno Nacional, como lo son por ejemplo:  PDT 0610 - Seguro Complementario de Trabajo de Riesgo  PDT 0615 - Impuesto Selectivo al Consumo  PDT 0618 – Fondos y Fideicomisos  PDT 0621 - IGV Renta mensual  PDT 0634 – Impuesto Extraordinario para la Promoción y Desarrollo Turístico Nacional.  PDT 0648 – Impuesto Temporal a los Activos Netos 42  PDT 0695- Impuesto a las Transacciones Financieras  PDT 0697- Percepciones a las Ventas Internas En la figura 2-4 se muestra la portada del programa en mención. FIGURA 2-4: PORTADA DEL SOFTWARE PDT Fuente: [SUN2009] 2.3.1.2 Central de Consultas Actualmente la ERT cuenta con 2 números telefónicos con los cuales se tiene acceso a la central de consultas:  El numero 080112100, el cual proporciona el mensaje de bienvenida de la central e indica todas las opciones disponibles.  El numero 3150730, el cual ingresa directamente a la cola de espera de atención de consultas tributarias. Básicamente la Central de Consultas automatiza la atención de consultas (IVR) cuando no es necesaria la presencia de un agente o asistente y en aquellos casos en que esta es precisa, se automatice también los datos más frecuentes (CTI), cuyas funcionalidades y prestaciones serán descritas a continuación. Las opciones que proporcionara el nuevo IVR se muestran en la figura 2-5. 43 FIGURA 2-5: OPOCIONES DEL IVR Fuente: [SUN2009] Línea 0801 (actualmente 0801-12100) Línea fija (actualmente 3150730) Consultas tributarias Estado de número de RUC y condición domicilio fiscal Digita RUC (no obligatorio) Atención por agente tributario Atención por agente informático OPCIONES DEL IVR Consultas informáticas Tipo de cambio Digita RUC (no obligatorio) Digita RUC (obligatorio) Acceso a información automática BUC, Agente de Retención, Percepción Digita RUC (obligatorio) Acceso a información automática Acceso a información automática Tipo de cambio, Estado RUC, condición de domicilio fiscal, BUC, Agente de Retención, Agente de Percepción 44 La situación actual de la central de consultas es:  La Central de Consultas ofrece orientación tributaria e informática, a través de 64 y 10 agentes, respectivamente.  Durante el año 2007, ingresaron 1,765,786 llamadas de las que se atendieron 1,502,052, lo que da una tasa de abandono de 14.94 %.  La configuración de la central permite un tiempo de espera de hasta 1,000 segundos, luego de lo cual la llamada se corta, sin previamente emitir ningún mensaje.  La orientación informática es brindada por los agentes, ejecutando las aplicaciones consultadas (generalmente PDT) y tratando de reproducir la situación descrita por el contribuyente.  La orientación tributaria es brindada por los agentes, dependiendo del tipo de consulta. Si esta es de tipo legal, consultando bases legales; mientras que si es para averiguar la situación o estado de algún trámite, se resuelve consultando los sistemas existentes.  Se cuenta con 22 After Call Codes (ACC)1 para las consultas de tipo tributario y con 25 ACC para las informáticas (ver anexo 1).  Los tiempos de atención por tema tributario en diciembre de 2007, llegaron hasta 7 minutos, sin embargo en general demoran entre 2 y 3 minutos (ver anexo 2).  Las llamadas de índole tributario durante diciembre de 2007 fueron 102,080, se muestran los temas más consultados en la figura 2-6 (ver anexo 2, para mayor detalle): 1 After Call Code: Código que sirve para registrar y clasificar el tipo de llamada atendida 45 FIGURA 2-6: LLAMADAS DEL RUBRO TRIBUTARIO Fuente: [SUN2009]  Los tiempos de atención por tema informático en diciembre de 2007, pueden llegar hasta 9 minutos, sin embargo en general demoran entre 2 y 3 minutos (ver anexo 3).  Las llamadas en el rubro informático durante diciembre de 2007 fueron 12,281, se muestran los temas más consultados en la figura 2-7 (ver anexo 3, para mayor detalle): FIGURA 2-7: LLAMADAS DEL RUBRO INFORMÁTICO Fuente: [SUN2009] 46  Tanto en las Consultas Tributarias como Informáticas, existe una cantidad de llamadas que son transferidas, lo que significa que son consultas tributarias que son derivadas a agentes informáticos (4,369 de 102,080) y consultas informáticas que son transferidas a agentes tributarios (3,803 de 12,281), para mayor detalle ver anexo 4: FIGURA 2-8: PORCENTAJE DE LLAMADAS TRANSFERIDAS EN AMBOS RUBROS Fuente: [SUN2009] A continuación se muestra el diagrama de decisión del IVR de la Central de Consultas y los mensajes involucrados. 47 FIGURA 2-9: ÁRBOL DE DECISIÓN DEL IVR Fuente: [SUN2009] (2) Bienvenida: Bienvenidos a la Central de Consultas de la SUNAT, para realizar consultas informáticas marque 1, para realizar consultas tributarias marque 2, para obtener información sobre el tipo de cambio promedio ponderado del día, para conocer el estado de un número de RUC y su condición de domicilio, para saber si un número de RUC es buen contribuyente o es agente de retención o agente de percepción marque 3, Espera excesiva (1) Mensaje 1: Gracias por llamar a la Central de Consultas de la SUNAT, en estos momentos nuestros asistentes de servicios están ocupados, por favor vuelva llamar en unos minutos. (17) Ingresa opción 1 (18) Mensaje 7: El tipo de cambio promedio ponderado del día de hoy dd/mm/aa es: Compra xx.xxx y venta yy.yyy. o El día de hoy no se ha publicado tipo de cambio promedio ponderado del día, por lo que se usará el tipo de cambio publicado el día dd/ mm/aa, el cual fue: Compra xx.xxx y Venta yy.yyy. Para volver al menú de bienvenida marque 9, para terminar la llamada marque 0 (19) Ingresa opción 2 (22) Mensaje 8: El RUC 99999999999 se encuentra con estado xx/yy/zz y con condición de domicilio aaa/bbb. Para consultar otro número de RUC marque 1, para volver al menú de bienvenida marque 9, para terminar la llamada marque 0 (24) Ingresa opción 3 (21) Número de RUC válido (27) Mensaje 10: El RUC 99999999999, SI/NO es Buen Contribuyente (desde:dd/mm/aa), SI/ NO es agente de retención (desde:dd/ mm/aa), SI/NO es agente de percepción (desde:dd/mm/aa). Para consultar otro número de RUC marque 1, volver al menú de bienvenida marque 9, para terminar la llamada marque 0 (26) Número de RUC válido SI SI ARBOL DE DECISIÓN DEL IVR DE LA NUEVA CENTRAL DE CONSULTAS SI NO NO NO 0801-12100 3150730 Todas las líneas ocupadas Contabilizar llamada como no ingresada por desborde de líneas SI (6) Ingresa RUC (3) Ingresa opción 1 (4) Mensaje 2: Digite su número de RUC, en caso contrario espere que un asistente informático lo atenderá en breves momentos. (8) Mensaje 3: Su llamada está siendo transferida a un agente informático, por favor espere un momento (7) Número de RUC válido (12) Ingresa RUC (9) Ingresa opción 2 (10) Mensaje 4: Digite su número de RUC, en caso contrario espere que un asistente tributario lo atenderá en breves momentos. (14) Mensaje 5: Su llamada está siendo transferida a un agente tributario, por favor espere un momento (13) Número de RUC válido SI SI NO (15) Ingresa opción 3 (5) Llamada con RUC (11) Llamada con RUCNO SI SI NO (16) Mensaje 6: Para consultas sobre el tipo de cambio marque 1, para consultas sobre el estado de un número de RUC o su condición de domicilio marque 2, para consultas sobre Buenos Contribuyentes, Agentes de Retención o Agentes de Percepción marque 3. Mensaje de repetición de opciones: Para volver a escuchar las opciones marque asterisco. (8.1 y 14.1) Mensajes 3.1 y 5.1: El número de RUC digitado es inválido por favor espere en línea que su llamada será transferida a un agente informático/ tributario. (20) Mensaje 7.1: Digite el número de RUC (25) Mensaje 9.1: Digite el número de RUC (6.1) Mensaje 2.1: Número de RUC inválido, por favor verifique el número y digite otra vez. (6.1) Mensaje 2.1: Número de RUC inválido, por favor verifique el número y digite otra vez. Llamada dentro del horario de atención (23) Mensaje 9: Su llamada está siendo tranferida a un agente tributario, por favor espere un momento. SI NO (20.1) y (25.1) Mensajes 7.2 y 9.2: En estos momentos no podemos atender su consulta, el horario de atención de los agentes tributarios/informáticos es de Lunes a Viernes de 8:00 am a 6:00 pm y Sábados de 8:00 am a 2:00 pm. FIN FIN Mensaje de espera: En breves momentos uno de nuestros asistentes de servicios lo atenderá. Mensaje sobre número de RUC: Recuerde que para ser atendido con mayor celeridad debe ingresar su número de RUC. Mensaje de despedida: Gracias por llamar a la central de consultas de la SUNAT 48 Como se explicó en el capítulo 1, la función de la tecnología CTI es mostrar la información del cliente, en este caso en particular sería la del contribuyente, en el terminal del agente al mismo tiempo que la llamada es transferida a éste (screen pop up). En la Central de Consultas de la ERT, de elegirse la opción: 01 Con RUC, se captura este dato (previamente el contribuyente debió confirmar que el número digitado es el correcto), y se muestra en la interface del agente información relevante del contribuyente. Una vista preliminar de esta pantalla se muestra en la figura 2-10. FIGURA 2-10: PANTALLA DEL AGENTE CON LOS DATOS DEL CONTRIBUYENTE Fuente: [SUN2009] Como se puede apreciar la información que se les proporciona a los agentes está referida básicamente a:  RUC (digitado por el contribuyente)  Nombre o razón social del contribuyente 49  Dependencia del contribuyente  Estado de contribuyente  Padrón especial: BUC, Agente de Retención, Agente de Percepción, Imprenta SOL  Condición de Domicilio (habido / no habido)  Tipo de Contribuyente  Representantes Legales  Régimen Tributario  Domicilio fiscal  Valores emitidos (pendientes de pago) - Mostrar la misma información del RSIRAT  Deuda en Cobranza Coactiva (con medida trabada) - Mostrar la misma información del RSIRAT  Fraccionamientos vigentes - Tipo de fraccionamiento - Estado (pendiente, aprobado o en pérdida) - Número de R.I  Devoluciones - Mostrar la misma información del RSIRAT  Fiscalización - Mostrar si el contribuyente se encuentra en fiscalización.  Medida Inductiva - Mostrar si el contribuyente ha sido objeto de alguna notificación o llamada preventiva durante los últimos 2 meses.  PDT 600 con error de Identificación en trabajadores - Mostrar períodos con errores. Así el desarrollo de una interface del agente en la que se muestra automáticamente la información que con mayor frecuencia se consulta, evita la invocación de los sistemas actualmente existentes, limitando su uso a casos específicos y por lo mismo, poco frecuentes. 50 2.3.2 Modalidad de interacción e integración de dichas tecnologías En la figura 2-11 se aprecia la topología de la red de voz y datos de la ERT, donde la Central de Consultas (Call Center) se encuentra en un nodo distinto al nodo de la sede principal y al nodo de la sede redundante. Por lo tanto es en el nodo principal donde se alojan los equipos que proveen los servicios de Operaciones en Línea, es decir servidor web, base de datos, etc. Es en este nodo en donde también se lleva a cabo el enrutamiento de las llamadas que requieran de la asistencia de un agente, ya que el servidor principal PBX-IP es el que tiene acceso directo a la PSTN o RTB. Así que cuando la consulta sea referida a temas informáticos o tributarios, ésta se deriva hacia el nodo del Call Center (Lima) mediante una VPN, donde por medio de webServices el Sistema de la ERT podrá recoger la información del contribuyente y mostrarla en el terminal del agente (Agent Desktop), si es que éste previamente proporcionó su RUC. Por otro lado si esta consulta está referida a temas puntuales, que pueden ser absueltos mediante procesos automatizados (IVR), la llamada será atendida por los servidores de voz y bases de datos de la sede principal o redundante si es el caso. FIGURA 2-11: ARQUITECTURA DE LA RED DE LA ERT Fuente: [SUN2009] 51 2.4 Solución al problema 2.4.1 Alcances  Permitir realizar pagos en línea mediante enlaces telefónicos, sean estos fijos o móviles.  Integrarse a las tecnologías de automatización existentes en el sistema e- government de la ERT.  Brindar una interacción con el contribuyente lo más sencilla y práctica posible.  El sistema automatizará solo los pagos de los tributos que más consultados fueron durante el último periodo 2007 (anexo 2), estos son: Impuesto Selectivo al Consumo (ISC), IGV Renta de Tercera categoría e IGV-Renta Mensual. 2.4.2 Limitaciones  El sistema de cobranza que valida VISA será transparente al presente proyecto de tesis, ya que se asume como proceso interno de la ERT. 2.5 Propuesta de la Arquitectura de la Solución La arquitectura propuesta contará con dos elementos:  La PBX-IP  La base de datos La PBX-IP será una solución de software libre con la configuración de las respectivas interfaces; además se encargará de hacer las consultas a la base de datos y de recibir la información de entrada que proporcionará el contribuyente al sistema IVR, así como también procesar la información para brindar una respuesta adecuada albergando el script del IVR que se desarrollará en base a un lenguaje de programación. Finalmente la base de datos guardará las tablas necesarias para el sistema así como la información de los contribuyentes y los pagos de los principales tributos de éste. 52 En la figura 2-12 se muestra el diseño de la arquitectura de la solución, la cual se compone de la arquitectura de mi solución integrada a la arquitectura de la ERT, ésta última básicamente es una solución que usa la plataforma de Call y Contact Center de Genesys. Dado que en los alcances de esta tesis está la implementación, optamos por soluciones libres de licencia. FIGURA 2-12: ARQUITECTURA DE LA SOLUCIÓN Fuente: [SUN2009] Se optó por un servidor de Base de Datos aparte al servidor PBX-IP debido a que la información de los contribuyentes que almacenará es crítica y cuantiosa, además porque este servidor correrá en Windows XP Professional dado que además albergará un programa (DBSync for MS Access & MySQL) para sincronizar la Base de Datos Principal de la ERT que es MS Access con la Base de Datos de la solución que es MySQL. 53 2.5.1 Tecnologías de la Solución 2.5.1.1 Sistema Operativo El servidor PBX estará basado en el sistema operativo Linux (CentOS 5). Esta distribución está basada en Red Hat Enterprise Linux (RHEL), aunque no es mantenido por Red Hat. Soporta casi todas las mismas arquitecturas de procesador que el original RHEL, como los son Intel x86-compatible (32 bits), Intel Itanium (64 bits), AMD64 e Intel 64, PowerPC/32, DEC Alpha, SPARC [CEN2008]. 2.5.1.2 PBX-IP Asterisk, que es una aplicación de software libre que simula una central telefónica (Private Branch eXchange, PBX). Como cualquier PBX, se puede conectar un número determinado de teléfonos para hacer llamadas entre sí e incluso conectar a un proveedor de VoIP o bien a una RDSI tanto básicos como primarios. Entre algunas de las características de Asterisk tenemos:  Un switch (PBX): Asterisk puede ser configurado como el núcleo de una PBX IP o híbrida, conmutando llamadas, dirigiendo rutas, activando funcionalidades, y conectando a los llamantes con el mundo exterior sobre conexiones IP, analógicas(POTS) y digitales (T1/E1).  Un Gateway: Sirve de pasarela entre la red PSTN y la telefonía IP.  Un ACD, el cual es detallado en el capítulo 1.  Un buzón de voz, sistema IVR y otras. La arquitectura de Asterisk está diseñada para soportar una amplia gama de protocolos VoIP para el manejo y transmisión de la voz sobre interfaces telefónicas tradicionales los cuales incluyen a H.323, Session Initiation Protocol (SIP), Inter- Asterisk eXchange (IAX™), Media Gateway Control Protocol (MGCP), and Skinny Client Control Protocol (SCCP). Usando el protocolo VoIP IAX se puede unir voz y tráfico de datos a través de redes disparejas. Asterisk corre sobre una amplia variedad 54 de sistemas operativos los cuales incluyen a Linux, OpenBSD, FreeBSD y Sun Solaris. [AST2008]. 2.5.1.3 Lenguaje de Programación El lenguaje de programación elegido es PHP 5.0, el cual es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos y dada su característica de propósito general lo usaremos como el lenguaje base para programar el IVR. Además es un programa que no impone el uso de muchos recursos al servidor (p.e. procesamiento), lo que lo hace una alternativa interesante para este tema de Tesis y en la elección frente a otros lenguajes como Java. PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como software libre. Los principales usos del PHP son los siguientes:  Programación de propósito general, habitualmente en combinación con el motor de base de datos MySQL.  Programación en consola, al estilo de Perl o Shell scripting.  Creación de aplicaciones gráficas independientes del navegador, por medio de la combinación de PHP y Qt/GTK+, lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado [PHP2008]. Algunas de las ventajas son:  Es un lenguaje multiplataforma, sin licencia y maneja excepciones.  Capacidad de conexión con la mayoría de los manejadores de base de datos actuales, destaca su conectividad con MySQL.  Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).  Posee una amplia documentación en su página oficial.  Permite las técnicas de Programación Orientada a Objetos. 55  Biblioteca nativa de funciones sumamente amplia e incluida.  No requiere definición de tipos de variables. 2.5.1.4 Manejador de Datos MySQL es un sistema de gestión de base de datos relacional, multihilo. MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En la presente tesis los datos de las transacciones de los contribuyentes no se modificarán continuamente, debido a que estos dependen de los pagos que realicen, lo que hace a MySQL ser tomada como alternativa para este tipo de aplicaciones. Dentro de sus principales características de la versión 4.0 se destaca [MYS2008]:  Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente.  Soporte a multiplataforma.  Disponibilidad en gran cantidad de plataformas y sistemas.  Diferentes opciones de almacenamiento según si se desea velocidad en las operaciones o el mayor número de operaciones disponibles.  Transacciones y claves foráneas.  Conectividad segura y replicación.  Búsqueda e indexación de campos de texto. 2.5.1.5 Asterisk AGI La Interface Gateway Asterisk (Asterisk Gateway Interface, AGI) es una interface con la cual se puede adicionar funcionalidades a Asterisk al permitirle correr programas externos escritos en cualquier lenguaje para controlar un canal telefónico, reproducir audio, leer tonos DTMF, etc. comunicándose con el protocolo AGI en stdin y stdout. La presente tesis usará AGI que permite controlar el plan de discado, referidos en extensions.conf y DeadAGI que permite el acceso a un canal muerto, es decir después del colgado [VOI2008]. 56 2.5.1.6 Sincronizador de Bases de Datos Como se mencionó al principio de este capítulo la arquitectura de la solución propuesta utilizará una base de datos aparte a la base de datos principal que existe en la red interna de la sede la ERT. Dado que esta última es MS Access, y entre los elementos de la arquitectura integrada para brindar la solución consta una base de datos MySQL, nos vimos en la necesidad de buscar un software que sincronice estas. Para lo cual se eligió DBSync for MS Access & MySQL que es propietario de DB Convert. Este software nos ofrece la posibilidad de actualizar y sincronizar bases de datos de una manera rápida y confiable. Puede operar con la base de datos completa o con tablas seleccionadas, el cual será nuestro caso [DBC2008]. En la figura 2-13 se muestra la interface de usuario de este software FIGURA 2-13: INETRFAZ HUMANA Fuente: [DBC2008] 57 Capítulo 3 Diseño e Implementación de la Solución En este capítulo se describe el diseño del proyecto presentando los flujos del mismo para luego detallar la configuración especial de los elementos del sistema necesarios para el funcionamiento del mismo. 3.1 Diseño de la solución 3.1.1 Descripción del servicio El servicio ofrecido a los contribuyentes de la ERT les permitirá realizar los pagos de los saldos deudores de los tributos más consultados en el Call Center de la ERT (ver Anexo 2), mediante la interacción con un IVR; en el cual el contribuyente elegirá el tributo a pagar y brindando los datos requeridos para el pago con tarjeta de crédito y débito, se efectuará la transacción tributaria en línea. Cuando el contribuyente llame a la central de consultas de la ERT a los números telefónicos 0801-12100 y/o 315-0730 y si todas las líneas no están ocupadas ni la espera es excesiva; se brindará 4 opciones de interacción, donde las tres primeras ya se describieron en el diagrama de decisión del IVR de la Central de Consultas que se especifica en el capítulo 2. Nuestra solución busca integrarse a ese diagrama como la “opción 4”. 58 Así que si la opción elegida es esta última, este servicio se dividirá en tres partes funcionales. 3.1.1.1 Elección del tributo a pagar Como se mencionó al principio de este capítulo solo se considerará los tributos mas consultados, es decir el IGV-Renta Mensual, el Impuesto Selectivo al Consumo y la Renta Anual de 3era Categoría. Se reproducirán audios que describan estos tributos respectivamente. Previamente se le pedirá que ingrese el número de su RUC para la validación respectiva. Es conveniente mencionar que los saldos deudores de estos tributos estarán previamente calculados y actualizados por el sistema interno de la ERT. Así que mediante la sincronización de las bases de datos dispondremos de ellos solo para su lectura y actualización del indicador del estado de pago. 3.1.1.2 Petición de datos Una vez elegido el tributo a pagarse, se informará al cliente el monto del saldo deudor y si este asiente su pago, el sistema IVR pedirá al tributante proporcione los datos requeridos para realizar el pago mediante tarjetas de crédito o débito VISA (para ambos casos la tarjeta del tributante debe estar afiliada a Verified by VISA) los cuales serán capturados por el sistema mediante tonos DTMF. Estos datos pedidos constarán de la fecha de expiración de la tarjeta, la clave de la tarjeta y la clave de compras por internet para realizar la verificación requerida por VISA. 3.1.1.3 Transacción Una vez proporcionado los datos requeridos se hará uso del sistema de transacción web que tiene implementado la ERT. El sistema IVR internamente pasará los datos capturados que se pidió al contribuyente, para así realizar la transacción en línea. En la figura se muestra la aplicación web que la ERT tiene implementada. 59 FIGURA 3-1: SESIÓN WEB PARA VALIDACION VISA Fuente: [SUN2009] 3.1.2 Diagrama de flujo de la solución – Aplicación Telefónica A continuación, en la figura 3-2, se presentará el árbol de decisión o diagrama de flujo diseñado para el sistema IVR prototipo. Además en la tabla 3-1 se muestran los mensajes y acciones involucradas en la interacción del sistema IVR con el contribuyente para realizar los pagos de los tributos antes mencionados. 60 (1) Mensaje 1 Todas las líneas ocupadas Con espera excesiva 0801-12100 315-0730 SI NO Contabilizar llamada como no ingresada por desborde de líneas SI (2) Bienvenida NO Ingresa opción 2 Ingresa opción 1 Ingresa opción 3 (3) Ingresa opción 4 (7) Mensaje 3 (8) Ingresa opción 1 (9) Ingresa opción 2 (10) Ingresa opción 3 (4) Ingresa RUC (6) Número de RUC válido F SI NO (11) Mensaje 4 Respuesta afirmativa F NO A (12) Ingresa mes de expiración (13) Mensaje 5 (5) Mensaje 2 B SI 61 A B (14) Mes es correcto (16) Mensaje 6 (15) Ingresa año de expiración (17) Año es correcto (19) Mensaje 7 (18) Ingresa número de TC NO SI SI NO (20) Tamaño correcto NO (24) Mensaje 9 (23) Ingresa clave de compras en línea SI SI (22) Mensaje 8 (21) Usuario corrobora clave Respueta afirmativa NO (25) Tamaño correcto NO FIN (26) Proporciona datos para pago en línea (27) Mensaje 10 SI F FIGURA 3-2: ÁRBOL DE DECISIÓN DE LA SOLUCIÓN – APLICACIÓN TELEFÓNICA 62 TABLA 3-1 MENSAJES INVOLUCRADOS EN EL ÁRBOL DE DECISIÓN DE LA SOLUCIÓN Bloque Descripción de Locución Acción (1) Mensaje 1: Gracias por llamar a la Central de Consultas de la ERT, en estos momentos nuestros asistentes de servicios están ocupados, por favor vuelva a llamar en unos minutos. Si es por Espera Excesiva: Grabar número que llamó, contabilizar la llamada como No Ingresada por espera excesiva y cortarla. Si es por Líneas Ocupadas: Grabar número que llamó, contabilizar la llamada como No Ingresada por desborde de líneas y cortarla. (2) Mensaje Bienvenida: Bienvenidos a la Central de Consultas de la ERT, para realizar consultas informáticas marque 1, para realizar consultas tributarias marque 2, para obtener información sobre el tipo de cambio promedio ponderado del día, para conocer el estado de un número de RUC y su condición de domicilio, para saber si un número de RUC es buen contribuyente o es agente de retención o agente de percepción marque 3, para realizar los pagos de tributos en línea marque 4. Se espera para que El contribuyente marque la opción. (3) Ingresa opción 4 Pasa a 4 (4) Ingresa RUC Pasa a 5 (5) Mensaje 2: Digite su número de RUC. Se recibe el RUC del contribuyente mediante los tonos DTMF que este presione. Se consultará la base de datos donde se encuentra la información del RUC. (6) Verifica validez del RUC Si RUC es no válido se pasa a 23, de lo contrario pasa a 7. (7) Mensaje 3: Para realizar el pago mediante tarjetas de crédito o débito VISA del tributo IGV-Renta Mensual marque 1, para el pago del Impuesto Selectivo al Consumo marque 2, y para el pago de la Renta Anual de 3era Categoría marque 3. Se espera para que El contribuyente marque la opción. (8) , (9) o (10) Ingresa opción 1,2 o 3 Pasa a 11 (11) Mensaje 4: El saldo deudor del tributo que usted eligió es XXX. Está de acuerdo con tal monto y desea pagarlo ahora mismo. Si está de acuerdo marque 1, de lo contrario marque 2. Se espera para que El contribuyente marque la opción. Si escoge la opción 2 se pasa a 23, de lo contrario pasa a 12. 63 (12) Ingresa mes de expiración Pasa a 13 (13) Mensaje 5: Por favor ingrese el mes en que su tarjeta de crédito o débito VISA expira. Se espera para que El contribuyente ingrese el mes de expiración de la tarjeta de crédito. (14) Verifica validez del mes Si es correcta se pasa a 15, caso contrario vuelve a 12 (15) Ingresa año de expiración Pasa a 16 (16) Mensaje 6: Por favor ingrese el año en que su tarjeta de crédito o débito VISA expira. Se espera para que El contribuyente ingrese el año de expiración de la tarjeta de crédito. (17) Verifica validez del año Si es correcta se pasa a 18, caso contrario vuelve a 15 (18) Ingresa número de cuenta de la tarjeta de crédito Pasa a 19 (19) Mensaje 7: Por favor ingrese cuidadosamente el número de la cuenta de su tarjeta de crédito o débito VISA, para realizar la transacción bancaria en línea. Se almacena dicho número de la tarjeta de crédito o débito VISA en una variable temporal. (20) Verifica el tamaño correcto del número de la cuenta de la tarjeta de crédito o débito VISA. Si el tamaño de la cuenta es correcto se pasa a 21, de lo contrario vuelve a 18. (21) El contribuyente corrobora cuenta de la tarjeta de crédito que acaba de ingresar mediante tonos DTMF. Pasa a 22 (22) Mensaje 8: La cuenta de la tarjeta de crédito o débito VISA que usted acaba de ingresar es XXX. Está de acuerdo con tal número de cuenta. Si está de acuerdo marque 1, de lo contrario marque 2. Se espera para que El contribuyente marque la opción. Si escoge la opción 2 vuelve a 18, de lo contrario pasa a 23. (23) Ingresa clave de compras en línea (Verified by VISA) Pasa a 24 (24) Mensaje 9: Por favor ingrese cuidadosamente la clave de compras en línea para la validación requerida por VISA (Verified by VISA). Se almacena dicha clave de compras en línea en una variable temporal. (25) Verifica el tamaño correcto de la clave de compras en línea. Si el tamaño de la cuenta es correcto se pasa a 26, de lo contrario vuelve a 23. (26) Proporciona datos para el pago en línea. En este proceso se proporcionan los datos capturados por el sistema al sistema interno de la ERT, por lo que este proceso escapa de los alcances de esta tesis. (27) Mensaje 10: Gracias estimado contribuyente por utilizar nuestros servicios de operaciones en línea para el pago de sus tributos. Lo esperamos pronto. Terminado de reproducirse este audio se termina la conexión. 64 3.1.3 Modelo de entidad relación El modelo de datos fue definido según se muestra en la figura 3-3. FIGURA 3-3: DIAGRAMA DE MODELO DE ENTIDAD RELACIÓN 65 3.1.3.1 Diccionario de datos A continuación se presentará la descripción de cada uno de los datos de las tablas del modelo antes mostrado. Tabla Contribuyente: TABLA 3-2 TABLA CONTRIBUYENTE Nombre Tipo de Dato Descripción RUC VARCHAR2 Llave primaria. Este es el Registro Único de Contribuyente, el cual tiene un tamaño de once caracteres y será el identificador del contribuyente en nuestro sistema IVR. NOMBRE_RS VARCHAR2 Este campo describe el nombre del contribuyente si es que éste es persona natural, o describirá la Razón Social en caso sea persona jurídica. DOMICILIO VARCHAR2 Este campo describe la dirección domiciliaria del contribuyente. DEPENDENCIA VARCHAR2 Tipo de Trabajador (independiente o dependiente) ESTADO BOOLEAN Este campo describe si el contribuyente está vigente o no TIPO SHORT Este campo diferencia si el contribuyente es una persona natural o persona jurídica. 66 Tabla IGV_Mensual: TABLA 3-3 TABLA IGV_MENSUAL Nombre Tipo de Dato Descripción ID SHORT Llave primaria. Este campo identificará al tipo de tributo en este caso será uno (1) RUC VARCHAR2 Llave primaria. Relación fuerte. Este es el Registro Único de Contribuyente, el cual tiene un tamaño de once caracteres y será el identificador del contribuyente en nuestro sistema IVR. MONTO LONG Este campo describe el monto del saldo deudor del contribuyente para este tributo. ESTADO BOOLEAN Este campo describe si saldo deudor correspondiente a este tributo ya se encuentra cancelado o no. Tabla ISC: TABLA 3-4 TABLA ISC Nombre Tipo de Dato Descripción ID SHORT Llave primaria. Este campo identificará al tipo de tributo en este caso será uno (2) RUC VARCHAR2 Llave primaria. Relación fuerte. Este es el Registro Único de Contribuyente, el cual tiene un tamaño de once caracteres y será el identificador del contribuyente en nuestro sistema IVR. MONTO LONG Este campo describe el monto del saldo deudor del contribuyente para este tributo. ESTADO BOOLEAN Este campo describe si saldo deudor correspondiente a este tributo ya se encuentra cancelado o no. 67 Tabla Renta_Anual: TABLA 3-5 TABLA RENTA_ANUAL Nombre Tipo de Dato Descripción ID SHORT Llave primaria. Este campo identificará al tipo de tributo en este caso será uno (3) RUC VARCHAR2 Llave primaria. Relación fuerte. Este es el Registro Único de Contribuyente, el cual tiene un tamaño de once caracteres y será el identificador del contribuyente en nuestro sistema IVR. MONTO LONG Este campo describe el monto del saldo deudor del contribuyente para este tributo. ESTADO BOOLEAN Este campo describe si saldo deudor correspondiente a este tributo ya se encuentra cancelado o no. 3.1.4 Diseño de la Aplicación Telefónica La arquitectura en general funcionará de la siguiente forma:  La funcionalidad de las tecnologías AGI y DeadAGI residirán en el mismo servidor PBX-IP donde también correrá la plataforma Asterisk, la que a su vez soporta la aplicación IVR.  El servidor de Base de Datos escuchará requerimientos a través del puerto 1521. Para un mejor entendimiento del diseño de la aplicación telefónica, esta ha sido dividida en tres procesos: Identificación y Petición de datos y Actualización de datos. 68 Además es oportuno mencionar que los dos primeros procesos se engloban por el programa de funcionalidad AGI, llamado IVR_Pagos.php (refiérase al anexo 5 para más detalle), el cual será invocado cuando el contribuyente llame a uno de los números telefónicos proporcionados y seleccione la ―opción 4‖, como se mencionó al principio de este capítulo. 3.1.4.1 Identificación Esta parte está referida a la identificación del contribuyente y del tributo a pagar, con lo cual se validará la identidad del contribuyente mediante su RUC, el cual será capturado mediante tonos DTMF por la función IvrMenuGetNumber() y almacenado temporalmente en la variable $get_ruc, para luego hacer la validación respectiva con el servidor de base de datos. Además esta función reproducirá el audio menu-ert.gsm (Mensaje 2) para este propósito. Una vez hecha la identificación del contribuyente se procederá a elegir el tributo a cancelar, para lo cual se capturará la opción elegida por el contribuyente mediante tonos DTMF por la función IvrMenuGetOption() y será almacenada en la variable temporal $Opciones_tributos. En esta función se reproducirá el audio para_pagar.gsm (Mensaje 3). Después se hará una consulta al servidor de base de datos para ver si el contribuyente está habilitado y si el tributo elegido está vigente de pago, así como también si el tributo se encuentra cancelado o no a la fecha. De estar el tributo cancelado, el sistema le dará al contribuyente la opción de volver a repetir las opciones de los tributos a pagar. De lo contrario (de no estar cancelado) el sistema leerá el monto de la deuda mediante la función MediaSayNumber(), y preguntará al contribuyente si está de acuerdo con el monto reproducido. Para esto la función IvrMenuGetOption() reproducirá el audio usuario_de_acuerdo.gsm (Mensaje 4) para capturar la opción del contribuyente. De tener su asentimiento se proseguirá con la lógica del sistema. En la figura 3-4 se muestra la interacción del servidor PBX-IP y la base de datos en el proceso de identificación. Para efectos de un mejor entendimiento, el esquema comprende la tecnología AGI como un servidor independiente del servidor PBX-IP; pero en realidad está integrado a éste último. 69 FIGURA 3-4: ETAPAS DE IDENTIFICACIÓN 3.1.4.2 Petición de datos Este proceso está referido a la obtención, por parte del sistema, de los datos que harán posible en pago en línea mediante Tarjeta de Crédito o débito VISA. Por lo que al haberse obtenido el asentimiento del contribuyente para el pago del tributo que eligió, se le pedirá el mes en que la Tarjeta de Crédito expira, la cual será capturada por la función IvrMenuGetNumber()y almacenada en la variable temporal $mes. Para esto dicha función reproducirá el audio digite_mes.gsm (Mensaje 5). Del mismo modo lo hará con el año de expiración de la tarjeta de crédito, cuyo valor será almacenado temporalmente en la variable $anhio y capturado por función IvrMenuGetNumber()la que a su vez reproducirá el audio digite_anhio.gsm (Mensaje 6). Luego de esto se pedirán el número de cuenta de la tarjeta de crédito y la clave de compras en línea (verificación VISA), las que serán almacenadas en la variables temporales $cuenta y $clave respectivamente cuando ambas sean capturadas por la función IvrMenuGetNumber(). Se reproducirán los audios digite_cuenta.gsm (Mensaje 7) y digite_clave.gsm (Mensaje 9) respectivamente. Además para ambos casos se reproducirán los dígitos marcados mediante la función MediaSayDigits(), para así tener la certeza de que los dígitos que el contribuyente proporcionó mediante tonos DTMF son correctos. De no obtener el asentimiento del contribuyente, se le permitirá ingresar nuevamente los dígitos. 70 En la tabla 3-6 se presenta la descripción de las principales variables que serán requeridas por el sistema para realizar el pago de los tributos en línea. TABLA 3-6 VARIABLES REQUERIDAS PARA REALIZAR EL PAGO EN LÍNEA Variable Tipo Descripción $mes String. Este dato está referido a mes en la tarjeta de crédito expira, se usará para efectos del pago en línea $anhio String. Este dato está referido a año en la tarjeta de crédito expira, se usará para efectos del pago en línea $cuenta String. Número de la cuenta de la tarjeta de crédito y de una tamaño de 11 dígitos. $clave String. Número de la clave para los pagos en línea, dato requerido para la verificación requerida por VISA (Verified by VISA). Tamaño de 6 dígitos. 3.1.4.3 Actualización de datos Este proceso está referido a la actualización de la base de datos cuando el contribuyente termine su interacción de tributación virtual con el sistema IVR. Es decir este proceso se llevará a cabo cuando el contribuyente cuelgue o libere el canal, por lo que es en este proceso donde entrará a tallar la un programa de funcionalidad DeadAGI, llamado UpdateDB.php. 71 La lógica de este programa está centrada en analizar el campo ―Estado‖ de la tabla respectiva del tributo, el cual el contribuyente acaba de realizar el pago. Si este está en ‗1‘, es decir el tributo fue pagado correctamente, se procederá a enviar un mensaje HTTP (POST) a la dirección del servidor principal de base de datos (ResponsePostAddress) de la ERT, para que haga la actualización correspondiente; ya que como se explicó en el capítulo 2, el servidor de base de datos que estamos considerando en nuestra arquitectura es independiente del servidor principal de base de datos de la ERT. En caso la el campo ―Estado‖ sea ‗0‘, no se hará ninguna actualización debido a que se toma como un llamada fallida. En la figura 3-5 se muestra el diagrama de este proceso. FIGURA 3-5: PROCESO DE ACTUALIZACIÓN DE DATOS 72 3.1.5 Diccionario de las principales funciones AGI del sistema TABLA 3-7 FUNCIÓN IvrMenuGetOption Función Descripción Parámetros Retorno IvrMenuGetOption Reproduce un menú para capturar una opción numérica. $ndigits: Número de dígitos que aceptará como opción Valor Digitado: en caso de éxito sin interrupción $valid: Dígitos validos que aceptará $minvalue: Mínimo valor permitido $maxvalue: Máximo valor permitido $errloop: Número de veces a repetir el mensaje ante de dar error (-1): en caso de error $workdir: Directorio donde se encuentran los audios a reproducir $f_ask: Nombre del audio principal a ser reproducido $f_noresponse: Nombre del audio a reproducirse en caso no haya respuesta $f_novalid: Nombre del audio a reproducirse en caso haya error en los dígitos 73 TABLA 3-8 FUNCIÓN IvrMenuGetNumber Función Descripción Parámetros Retorno IvrMenuGetNumber Reproduce un menú para capturar un número con n dígitos. $app: Prefijo de la aplicación Valor Digitado: en caso de éxito sin interrupción $ndigitsmin: Número mínimo de dígitos que aceptará $ndigitsmax: Número máximo de dígitos que aceptará $valid: Dígitos validos que aceptará $escChar: Carácter de escape de la función $errloop: Número de veces a repetir el mensaje ante de dar error esChar: carácter de escape $workdir: Directorio donde se encuentran los audios a reproducir $b_conf: Booleano para número de confirmación $f_ask: Nombre del audio principal a ser reproducido $f_repeat: Nombre del audio que pide repetición si fuera el caso (-1): en caso de error $f_confirm: Audio que pide confirmación $f_noresponse: Nombre del audio a reproducirse en caso no haya respuesta $f_novalid: Nombre del audio a reproducirse en caso haya error en los digitos 74 3.1.6 Estimación de tráfico De de los datos presentados en el capítulo 2, se conoce que un promedio mensual de 40,386 llamadas están referidas a consultas tributarias de los principales impuestos que estamos considerando. A continuación se hará una estimación de tráfico para el sistema suponiendo que la ERT deseará implementar esta plataforma en su sistema de cobranzas. Con un flujo promedio de 40,386 llamadas mensuales (este valor se obtiene del anexo 2), se estima que por día un total de 1,346 llamadas lleguen a la plataforma de Telecobranza. Por lo que este escenario es el más idóneo para los intereses de la ERT; pero al mismo tiempo el más difícil para el sistema IVR. Usando la fórmula de tráfico y asumiendo una duración promedio de 4 minutos: Tráfico = [(Número de Llamadas) x (Duración por llamada)]/ 1 hora Obtenemos un total de 89.7 Erlangs, que remplazados en la tabla de Erlang B con una probabilidad de pérdida de 1% se obtienen 106 líneas o llamadas concurrentes. En [QUI2006] se realizaron pruebas sobre un servidor de 1GB de memoria RAM que arrojaron resultados de hasta 199 llamadas concurrentes, por lo que un servidor con esta configuración podrá soportar el tráfico estimado sin problemas. 3.2 Implementación de la Arquitectura 3.2.1 Servidor PBX-IP El servidor PBX-IP se encuentra implementado en una PC de procesador Intel Core 2 Duo 2.16GHz, 1Gb de memoria RAM, donde correrá el sistema operativo CentOS 5 con kernel 2.6.9-67.0.7.EL-i686. Además este se conectará a la LAN del de la ERT a través de una interface FastEthernet 100/1000Mbps para recibir las llamadas destinadas hacia este anexo por el Gateway principal de la ERT y para hacer consultas la base de datos local. 75 3.2.1.1 Configuración Asterisk La versión más reciente de Asterisk puede ser descargada de [AST2008] y detalles de su instalación se encuentran en [VOI2008]. Ahora se procederá a la creación de un usuario [SIPERT] en el archivo de configuración /etc/asterisk/sip.conf, el cual además tendrá un contexto que será usado para enrutar una llamada desde el ámbito de un terminal hasta el destino requerido. En la tabla 3-9 se muestra esta configuración. TABLA 3-9 CONFIGURACIÓN SIP.CONF [sipert] type=friend host=dynamic username=sipert dtmfmode=inband qualify=yes context=ert-ivr disallow=all allow=ulaw language=es El archivo de configuración ―extensions.conf‖, se encuentra en el directorio /etc/asterisk/. Este archivo es relevante en nuestro sistema ya que contiene el plan de discado (dial plan) de Asterisk, el plan maestro del flujo de ejecución o control para todas sus operaciones. Además controla como las llamadas entrantes y salientes son manejadas y enrutadas, por lo que en este archivo es donde se configura el comportamiento de todas las conexiones a través de la PBX-IP. El plan de discado del contexto que se definió en el archivo de configuración ―sip.conf‖, es decir [SIPERT], consta en este archivo y contiene las referencia a las funcionalidades AGI y DeadAGI. Adicionalmente se definirán dos extensiones llamadas ―contribuyente0‖ y ―contribuyente1‖, las cuales serán configuradas en los archivos de configuración ―sip.conf‖ e ―iax2.conf‖ respectivamente, para efecto de pruebas iniciales en el mismo 76 contexto. Además se asignará un número al sistema IVR, el cual será la extensión ‗4‘. En la tabla 3-10 se aprecia la configuración referida. TABLA 3-10 CONFIGURACIÓN EXTENSIONS.CONF [ert-ivr] exten => 1234,1,Dial(SIP/contribuyente0) exten => 1234,2,Hangup() exten => 1235,1, Dial(IAX2/contribuyente1) exten => 1235,2,Hangup() exten => 4,1,Answer exten => 4,n,NoOp(Contesto ${CallQueueID}) exten => 4,n,AGI(IVR_Pagos.php) exten => h,1,NoOp(Colgo ${CallQueueID}) exten => h,n,DeadAGI(UpdateDB.php) 3.2.2 Servidor de Base de Datos El servidor de base de datos fue implementado en una PC de procesador Intel Pentium 4, 512 MB de RAM, y corriendo en el sistema operativo Microsoft Windows XP con el Sistema MySQL 5 instalado. En la figura 3-6 se muestra las tablas creadas. FIGURA 3-6: TABLAS DEL SISTEMA 77 Capítulo 4 Pruebas de Desempeño En este capítulo se describirá el proceso de pruebas realizado así como los elementos usados para los fines de evaluación y se mostrarán los resultados obtenidos para el Sistema IVR. 4.1 Introducción Con el fin de evaluar el sistema IVR y definir su desempeño en la arquitectura implementada se utilizará el software SIPP. SIPP es un sistema de pruebas de código abierto desarrollado por Hewlett Packard (HP). Se aprovecharán las capacidades de generación de tráfico de Sipp para emular a muchos usuarios SIP llamando al sistema IVR y realizando requerimientos a la base de datos. Sipp cuenta con configuraciones por defecto llamadas escenarios, los cuales son:  UAC – User Agent Client  UAS – User Agent Server En la figura 4-1 se muestra la arquitectura de pruebas. 78 FIGURA 4-1: ARUITECTURA DE PRUEBAS Si bien pueden usarse estas configuraciones, SIPp también da la capacidad de crear escenarios personalizados en archivos XML, para la prueba específica de aplicaciones que requieran intercambiar datos más allá de un simple intercambio RTP, es decir una simulación de llamadas. En las pruebas realizadas se configuró la arquitectura para ser cargada. Las llamadas harán un requerimiento automático a base de datos, para luego mantener la llamada mediante la reproducción de un archivo de audio de 80 minutos de duración, con el fin de poder obtener la cantidad de llamadas que el servidor PBX puede soportar en un determinado instante. A su vez se analizará el uso de CPU y memoria total a fin de que nos permita emitir recomendaciones adecuadas. Estos monitoreos fueron realizados mediante el uso del software Cacti. Para la realización de las pruebas en primer lugar se configuró el sistema del servidor PBX IP; para lo cual creamos el usuario [SIPERT] en el archivo de configuración /etc/asterisk/sip.conf, cuya configuración se detalló en el subcapítulo 3.2 del capítulo anterior. Este procedimiento es necesario para que el sistema genere las llamadas a la PBX, con lo cual se producirá tráfico. Así también Asterisk fue configurado para que interactúe con Cacti, tal como se especifica en [DIA2006]. 79 Luego siguiendo una configuración similar a la aparecida en la parte de pruebas [QUI2007] se configuró el SIPP en un modo UAC, con llamadas de una duración de 15000 segundos, recibiendo todo el tráfico por el puerto 10001 y con una tasa de creación de 4 llamadas por minuto. TABLA 4-1 COMANDO SIPP EJECUTADO 4.2 Resultados Las pruebas empezaron el día sábado 15 de noviembre a las 16:50:00 y finalizaron el mismo día a las 18:45:00. Este periodo comprendió 2 pruebas de aproximadamente 48 minutos cada una dando un tiempo de 20 minutos de descanso a los sistemas para que estabilicen el uso de CPU y memoria. Se analizó el número de llamadas concurrentes, el uso de CPU, la memoria utilizada y el tráfico. 4.2.1 Número de llamadas concurrentes El número de llamadas concurrentes máximo obtenidos fue 154. La figura 4-2 nos muestra el incremento de llamadas según la tasa de 4 llamadas por minuto. Cuando la llamada 155 ingresa el servidor no puede continuar con el servicio dado que es incapaz de alzar una canal SIP, no atendiendo por este motivo las llamadas siguientes. 80 FIGURA 4-2: LLAMADAS CONCURRENTES La figura 4-3 nos muestra el log del SIPP tras la finalización de las pruebas: FIGURA 4-3: LOG DEL SIPP 81 La figura 4-4 nos muestra las llamadas concurrentes en todo el periodo de pruebas. Podemos observar que en ambos casos el número de llamadas concurrentes es el mismo, dado que SIPP hace uso de G.711; el cual casi no utiliza recursos de CPU según se estudió en [QUI2006]. Así el número de llamadas depende principalmente de la memoria del servidor. FIGURA 4-4: LLAMADAS CONCURRENTES – PERIODO TOTAL 4.3.2 Uso de CPU Durante las pruebas se midió el uso de CPU para determinar la influencia en el uso del servidor PBX IP cuando hay llamadas concurrentes. El gráfico muestra que en casi dos horas de pruebas el uso del CPU del servidor tuvo un valor máximo de 24.48% para funciones netamente de la plataforma que se ha implementado (User). Por lo que viendo el porcentaje de CPU que requiere el servidor para funciones netamente del sistema (System) llega a un valor máximo de 28.96%. De ahí que ambas funcionalidades en conjunto no exigirán la capacidad completa de CPU. Esto se aprecia en la figura 4-5. 82 FIGURA 4-5: USO DE CPU 4.3.3 Uso de Memoria En la figura 4-6 se aprecia que en comparación con los tiempos de ocurrencia de llamadas de la figura 4-4, se puede observar que las llamadas se inician alrededor de la hora 17:00 y hasta que finalicen a las 17:40, es un intervalo en el cual la memoria libre fue decreciendo linealmente debido al establecimiento paulatino de las llamadas. Desde las 17:40 hasta la 18:00 existe un comportamiento constante dado que el servidor se encontraba en un periodo de estabilización para luego empezar nuevamente un comportamiento similar en la segunda prueba. FIGURA 4-6: USO DE MEMORIA 83 Conclusiones, Recomendaciones y Trabajos Futuros En este capítulo se presentarán las recomendaciones, conclusiones del proyecto de tesis y los trabajos futuros que pudieran estar derivados de este. 5.1 Recomendaciones  Protocolo: Se recomienda el uso del protocolo SIP, como fue utilizado en el presente proyecto; sin embargo también sería una opción a considerar el uso del protocolo IAX2 que consume menor ancho de banda y es más robusto.  Hardware: Se recomienda que para la puesta en producción del proyecto o de un servicio similar basado en la misma arquitectura se utilicen servidores de gran poder, especialmente para el servidor PBX-IP, ya que la capacidad de mantener conexiones está directamente relacionada a la cantidad de memoria RAM y robustez de este servidor tanto para mantener llamadas concurrentes como para realizar las consultas respectivas al servidor de base de datos. En el caso de este proyecto se utilizó para el servidor PBX-IP con 1GB de memoria RAM, por lo que se recomienda que todos los servidores tengan memoria igual o superior a 1GB.  En las pruebas realizadas se verificó que la cantidad de memoria utilizada (1GB) era más que suficiente para soportar el tráfico esperado del sistema, sin embargo se recomienda la ampliación a 2GB, para garantizar el correcto desempeño del servidor PBX en un escenario real. 84  Códec: Dada la importancia del ancho de banda sin dejar de lado la calidad, se recomienda el uso del códec GSM que sobresale por su simpleza y calidad.  Si bien se utilizó CentOS 5 para la PBX, se recomienda también el uso de Fedora Core 5. 5.2 Trabajos futuros Diferentes trabajos pueden ser derivados del presente proyecto, entre ellos:  Implementar un servicio IVR similar o mucho más avanzado usando la tecnología Fast AGI, la cual permite la interacción del servidor PBX-IP con otro servidor dedicado exclusivamente para atender requerimientos de procesamiento de consultas VoIP. Pero esta las librerías para implementar esta tecnología deben estar escritas en lenguajes de programación como Python, Perl o Java, aunque este último no es remendable debido al alto nivel de exigencia de procesamiento que requiere.  Desarrollar otros proyectos CTI como lo son centros de contactos o sistemas de entrenamiento de llamadas según habilidades, para los cuales un IVR es la primera etapa de interacción con el usuario, pero con reconocimiento de voz (Voice Recognition). 5.3 Conclusiones Al terminar el presente proyecto de tesis se puede concluir lo siguiente:  Se realizó el análisis de las tecnologías CTI involucradas en el sistema de cobranza de una ERT, y se justificó el uso la tecnología IVR para la optimización de dicho sistema; ya que reduce costos de operación y mantenimiento, así como también disminuir el tiempo que genera realizar estas transacciones.  Se estudió cada uno de los componentes de la arquitectura del sistema, comprobándose la exitosa interacción entre tecnologías libres y propietarias.  Se comprobó la flexibilidad que nos brinda el hecho de implementar el sistema IVR en base a un lenguaje de programación como PHP 5.0, en 85 tanto que nos permite modularidad y simplicidad en la lógica de interacción del sistema con el usuario.  Se comprobó la capacidad y aprovechó la potencialidad de la tecnología AGI, para darle mayor control al servidor PBX cuando capturaba los datos que proporcionaba el contribuyente.  Se implementó exitosamente el sistema IVR-IP piloto usando una arquitectura de dos servidores ta descrita a lo largo del presente trabajo, demostrando su viabilidad y su enorme potencial de aplicación en empresas de diversos ámbitos que requieran brindar una interfaz telefónica simple y amigable a sus clientes.  Se midió la capacidad real del sistema en los servidores implementados por medio de pruebas de desempeño observando que las capacidades del sistema satisfacían el tráfico estimado en el punto 3.1.6. Se comprobó la capacidad del servidor PBX al soportar 154 llamadas concurrentes y se midió el uso de CPU del mismo. 86 Bibliografía [ABR2003] ABRAHAMS, JOHN. ―Centrex or PBX: The Impact of IP‖ Ed. Artech House INC., USA. 2003. [BIB2008] Bibliociencias. URL: http://www.bibliociencias.cu/gsdl/collect/ [ref. de 16 de Junio 2008]. [BOY2008] Boynings. URL: http://boynings.co.uk/papers/kable2001.pdf [ref. de 17 de setiembre 2008]. [CEN2008] CentOS. URL: http://www.centos.org/ [ref. de 28 de setiembre 2008]. [DBC2008]. DBConvert URL: http://dbconvert.com/ [ref. de 24 de noviembre 2008]. [DIA2006] DIAZ ARTURO. ―Diseño e implementación del Centro de operaciones y Gestión de la Red Académica en Software Libre ‖. PUCP. 2006. [EUR2008] Europa. URL: http://ec.europa.eu/information_society/activities/egovernment/index_en.htm [ref. de 10 de junio 2008]. [FUL2008] Fullerton. URL: http://www.fullerton.edu/it/services/Telecom/FAQ/acdguide.asp [ref. de 12 de agosto 2008]. [GOR1999] GORALSKI, WALTER ―IP-Telephony‖ Ed. McGraw-Hill Professional, USA. 1999. [GRE2002] GREEN, JAMES HARRY. ―Voice and Video Over IP‖ Ed. McGraw-Hill Professional, USA. 2002. [HEI2003] HEIMANN, D.L. ―Public Sector Data Management in a Developing Economy‖. Ed. Idea Group Inc., USA. 2003. [HUA2007] HUAPAYA, JUAN. Presentación: ―PCM‖. Perú 2007. 87 [LAR2007] LARIOS, ENRIQUE. Presentación: ―Introducción a Base de Datos‖. Perú. 2007. [EUR2008] MySQL. URL: http://www.mysql.com/ [ref. de 10 de noviembre 2008]. [PHP2008] PHP. URL: http://www.php.net [ref. de 10 de noviembre 2008]. [QUI2006] QUINTANA DIEGO. ―Diseño e Implementación de una Red de Telefonía IP con Software Libre en la RAAP‖. PUCP. 2006. [SHA2003] SHARP, DUANE. ―Call Center Operation: Design, Operation, and Maintenance‖ Ed. Digital Press © 2003 [SHE1998] SHENG, LIN CHOU. ―Sistemas Expertos y Modelos de Redes Probabilísticas‖. USA. 1998. [SIL2008] Silicon-press. URL: http://www.silicon- press.com/briefs/brief.ippbx/brief.pdf [ref. de 5 de mayo 2008]. [STE2008] Steptwo. URL: http://www.steptwo.com.au/news/ppt/IIM2002.ppt [ref. de 10 de setiembre 2008]. [SUN2009] SUNAT. URL: http://www.sunat.gob.pe [ref. de 7 de noviembre 2008]. [UTA2008] UTA. URL: http://academias.uta.cl/file.php/33/M7_-_Bases_de_datos.pdf [ref. de 22 de agosto 2008]. [VOI2008] VoIP-Info. URL: http://www.voip-info.org/ [ref. de 11 de noviembre 2008]. [WOR2008] WorldBank. URL: http://web.worldbank.org/ [ref. de 15 de mayo 2008].