Arquitectura Aplicativa Y CRM Triple Play.

Arquitectura Aplicativa Y CRM Triple Play.
Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

Contenido Introducción Cobertura del Modelo TAM
Evaluación del CRM Triple Play Evaluación de la Arquitectura de Integración Evaluación General de la Arquitectura Aplicativa 2 2

Frente Arquitectura Aplicativa Introducción
En virtud de los particularidades detectadas durante el diagnóstico, y el rol de Socio Estratégico sugerido para el área de Sistemas, se elaboró un mapa de aplicaciones objetivo, el cual tiene como principal propósito, desarrollar aquellos aspectos funcionales y técnicos que han evidenciado mayores oportunidades de mejora: Flexibilidad NO ES CORRECTO Esfuerzo para cambios ES DISCUTIBLE Funcionalidad para el negocio NO ESTOY DE ACUERDO Calidad de la información Automatización de la información Tiempos de respuesta FALTA ESTE Facilidad de uso FALTA ESTE A continuación, presentamos las recomendaciones que tienen como objetivo cubrir la brecha existente entre el nivel de madurez actual y el nivel de madurez objetivo: 3 3 3 3 3 3

Frente Arquitectura Aplicativa Introducción
A continuación se rocorda las principales aplicaciones y plataformas que soportan el actual negocio de Telecentro. COMENTARIO CRM Triple Play: Planes de Venta Productos y Servicios Zona Comercial Red Reclamos Clientes Contratación Visitas técnicas Cuentas Corrientes Bajas Comisiones PreBilling y Billing Sistema FOX Comarch Oracle Financials (ERP) (*) Aplicación de valorización de locutorios CARENA (*) DAC 6000 IPUnity Intraway CPP (+) Tarjetas por DAT / Pago directo (+) Agentes Recaudadores (+) (*) Estas aplicaciones son corporativas y soportan a otras Organizaciones del Grupo (+) Entes externos, sólo se evalúa la interfaz 4 4 4 4

Cobertura del modelo TAM
Frente Arquitectura Aplicativa Introducción Para evaluar las aplicaciones con que actualmente Telecentro lleva adelante su negocio, se utilizaron como marco de referencia los siguientes elementos de foco para llevar a cabo el análisis: Cobertura del modelo TAM CRM Triple Play Integración Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones) Modelo TAM Cobertura actual del Modelo Listado de Aplicaciones Arquitectura Lógica Aspectos Funcionales: Flexibilidad, Facilidad de uso, calidad de la información, etc. Aspectos Técnicos: Tiempo de Respuesta, Disponibilidad del sistema, esfuerzo para cambios, etc. Proceso de Desarrollo actual Código Fuente Acceso a Datos Utilización de los Recursos Físicos Documentación Mapa de Integración Redundancia Explotación (acceso) Automatización de controles. Documentación. Estructura. Facilidad de uso Funcionalidad para el actual negocio. Uso de capacidades. Calidad de información Confiabilidad del sistema Accesibilidad. 5

Frente Arquitectura Aplicativa Cobertura del modelo TAM CRM Triple Play Integración Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones) Modelo TAM Cobertura actual del Modelo Listado de Aplicaciones Arquitectura Lógica Aspectos Funcionales: Flexibilidad, Facilidad de uso, calidad de la información, etc. Aspectos Técnicos: Tiempo de Respuesta, Disponibilidad del sistema, esfuerzo para cambios, etc. Proceso de Desarrollo actual Código Fuente Acceso a Datos Utilización de los Recursos Físicos Documentación Mapa de Integración Redundancia Explotación (acceso) Automatización de controles. Documentación. Estructura. Facilidad de uso Funcionalidad para el actual negocio. Uso de capacidades. Calidad de información Confiabilidad del sistema Accesibilidad. 6

Infraestructura de Integración
INIT Frente Arquitectura Aplicativa Cobertura Actual del Modelo Mercado / Ventas Bus de integración / MiddleWare / Business Process Management Infraestructura de Integración Auxiliar de Ventas Resultados & Compensaciones Gestión de Ventas Masivas Gestión de canales de Ventas Gestión de Ventas Corporativas Portal de Ventas Gestión de Campaña Producto Estrategia de Producto / Gestión de propuestas Gestión de Catálogos de Servicios / Productos Gestión de Ciclo de Vida de Producto Gestión de Desempeño del Producto Planeación y Alistamiento Cumplimiento Aseguramiento Facturación Clientes Autogestión del Cliente Gestión de Cobro Gestión de Facturación Gestión de Pedidos del Cliente Gestión de Información del Cliente Gestión del contacto con el cliente, Retención & Lealtad Control de Facturas Política de Cuenta Indicadores del Servicio al Cliente Facturación Producción de Documentos Transaccionales Gestión de QoS & SLA del Cliente Servicio al Cliente / Resolución de problemas de Cuenta Formato de Facturas Rating de Productos/ Servicios Cargo Online Servicios Gestión de Acuerdos de Servicios Análisis de Impacto y Monitoreo de QoS Especificación de Servicios Gestión de Inventarios de Servicios Gestión de Pedido de Servicios Gestión de Problemas de Servicio Gestión de Desempeño de Servicios Recursos Gestión de Procesos de Recursos (Workflow de Integración) Aplicaciones de Mediación de Datos de Facturación Aplicaciones de Gestión de Inventarios de Recursos Gestión de Ciclo de Vida de Recursos Gestión de Pedidos de Recursos Gestión de Cumplimiento de Recursos Gestión de Vouchers Aplicaciones de Mediación de Facturación en Tiempo Real Gestión de Recursos de Dominios Proveedor Gestión de Socios Gestión de Cadena de Abastecimiento Aplicaciones de facturación al por mayor Empresa Gestión de Aseguramiento de Ganancias Gestión de RRHH Gestión Financiera Gestión de Activos Gestión de Seguridad Gestión del Conocimiento Gestión de fraude 7 Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto

Frente Arquitectura Aplicativa Cobertura Futura del modelo TAM
A continuación, siguen los diferentes módulos del modelo TAM a cubrir con la criticidad, la complejidad, el Impacto y el Plazo : Mejora Adquisición / Desarrollo Criticidad Complejidad Impacto Plazo Gestión de Campaña X Media Medio Largo Auxiliar de Ventas Baja Alto Mediano Gestión de canales de Ventas Gestión de Desempeño del Producto Bajo Autogestión del Cliente Alta Indicadores del Servicio al Cliente Corto Gestión de QoS & SLA del Cliente Servicio al Cliente / Resolución de problemas de Cuenta Control de Facturas Cargo Online Aplicaciones de Mediación de Facturación en Tiempo Real Gestión de Socios Gestión de Aseguramiento de Ganancias Gestión de Seguridad Gestión de Fraude Bus de Integración

Frente Arquitectura Aplicativa Cobertura Futura TAM: Mercado / Ventas
El dominio “Mercado / Ventas” contiene las operaciones de contratos y datos para soportar las actividades de venta o de marketing necesarias para generar negocios con los clientes. Se considera como parte de ventas todo lo relacionado con los contactos, los posibles clientes, la fuerza de venta y las estadísticas de venta. Mercado alcanza todo lo que concierne a la estrategia, los planes, los segmentos de mercado, la competencia y sus productos, y la formulación de campañas. Módulos : Gestión de Campaña: aplicaciones responsables de manejar el ciclo de vida de las campañas de marketing. Gestión de Ventas Masivas: aplicaciones con funcionalidades de manejo de ventas para personas o PyMEs. Gestión de Ventas Corporativas: aplicaciones con funcionalidades de manejo de venta para las grandes empresas. Portal de Ventas: provee una única entrada a los vendedores para acceder a las herramientas de venta. Auxiliar de Ventas: aplicaciones que proveen acceso a los métodos y procedimientos, como así también a la información del producto que puede ser utilizado para soportar la venta. Resultados & Compensaciones: funcionalidades necesarias para la compensación de los vendedores, desde la asignación de las cuentas, nuevas ventas, ingresos facturados, hasta el cálculo de los planes de compensación y el reporte de resultados. Gestión de canales de Ventas: aplicaciones para vender a un número específico de canales de venta. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 9 9 9

Frente Arquitectura Aplicativa Cobertura Futura TAM: Productos
El dominio “Productos” es la visión de la organización para el proceso de desarrollo, de administración y de marketing de su oferta de productos para el cliente. Módulos : Estrategia de Producto / Gestión de propuestas: plan de acción para lograr los objetivos de la estrategia operativa a través de los productos vendidos en el mercado. Gestión de Catálogos de Servicios / Productos: habilidad para crear y mantener los productos que se han vendido a los clientes en el marcado objetivo (manejo centralizado en un catálogo). Gestión de Ciclo de Vida de Producto: parte responsable del manejo del ciclo de vida del producto y de los componentes asociados, incluyendo todo el proceso requerido para el diseño, la construcción, el despliegue, el mantenimiento y la eliminación del producto. Gestión de Desempeño del Producto: actividades y herramientas que obtienen y analizan los datos desde el punto de vista de la eficacia de la estrategia del producto, basándose en el desempeño en el mercado. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 10 10 10 10

Frente Arquitectura Aplicativa Cobertura Futura TAM: Clientes
El dominio “Clientes” trata de los procesos de conocimiento de las necesidades de los clientes y contiene todas las funcionalidades necesarias para la adquisición, la retención y la mejora de la relación con el mismo. Módulos: Gestión de Información del Cliente: “corazon” de todo CRM, utilizado por todos los canales de distribución; sirve para la creación, actualización y búsqueda de la información del cliente. Producción de Documentos Transaccionales: actividades para emitir facturas, cartas o cualquier documentación a los clientes. Gestión de Pedidos del Cliente: administra el ciclo de vida de la necesidad de un cliente para un producto (establecimiento del pedido, publicación del pedido, tratamiento del pedido, etc.). Autogestión del Cliente: aplicaciones para proveer una interfaz al cliente para realizar pedidos u otras funciones a través de Internet. Gestión del contacto con el Cliente, Retención & Lealtad: funcionalidades para autorizar a un operador a crear, actualizar y ver la información del cliente, guardar y ver los interacciones del mismo con los diferentes canales de comunicación, ver su histórico, sus facturas, etc., con el fin de retenerlo. Indicadores del Servicio al Cliente: tiene un rol crítico en la obtención de la experiencia del cliente en cuanto a servicio y satisfacción, pero también para detectar oportunidades de venta a través de interacciones con el cliente ( , web chat, teléfono, etc.). Servicio al Cliente / Resolución de problemas de Cuenta: aplicaciones para administrar los clientes afectados por un problema con el servicio o con las facturas. Gestión de QoS & SLA del Cliente: grupo de funcionalidades que ayudan al operador a asegurar que el cliente tiene el nivel de servicio por el cual esta pagando. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 11 11 11

Frente Arquitectura Aplicativa Cobertura Futura TAM: Clientes (Cont.)
Módulos (Cont.) : Gestión de Cobro: aplicación para automatizar y manejar el proceso de transacciones financieras que afectan la cuenta del cliente. Gestión de Facturación: módulo con todas las funcionalidades necesarias que permitan efectuar la facturación del cliente. Control de Facturas: aplicaciones utilizadas para manejar preguntas y ajustes en la facturación. Formato de Facturas: herramientas para dar formato a la factura, basada en opciones especificadas y luego lo hace disponible en medios de comunicación apropiados. Cargo Online: mecanismo de cobro que es responsable en tiempo real, de cargar y modificar la información del cliente sin afectar el servicio. Rating de Productos/ Servicios: aplicación que calcula los cargos, descuentos y bonificaciones de un cliente. Política de Cuenta: funcionalidades para manejar políticas para las cuentas de los clientes con saldos (a favor o en contra). Facturación: aplicación para calcular una factura única para todos los servicios que se brindan a los clientes. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 12 12 12

Frente Arquitectura Aplicativa Cobertura Futura TAM: Servicios
El dominio “Servicios” soporta y permite los procesos enfocados a la gestión y control de los servicios (voz, data, servicios de contenidos) que se le brindan a un cliente, independientemente de la tecnología sobre la cuál se implemente el servicio. Módulos : Especificación de Servicios: aplicación para el almacenaje y recuperación de datos específicos del servicio. Gestión de Inventarios de Servicios: aplicación que comprende : El mapeo de las especificaciones del producto a los especificaciones del servicio y de las instancias del producto a los instancias del servicio; El mapeo del servicio a los componentes del servicio; La implementación del nivel de servicio del dominio de los recursos Gestión de Pedido de Servicios: maneja de punta a punta el ciclo de vida de una demanda de servicio (validación de la disponibilidad del servicio, alta de demanda de servicio). Gestión de Problemas de Servicios: actúa como el puente entre los problemas de recursos y los problemas que afectan al cliente (resolución de problema de cliente, análisis de causa de problema, servicio de monitoreo de la calidad). Gestión de Desempeño de Servicios: aplicaciones que ayudan a monitorear los servicios punto a punto, incluyendo la experiencia del cliente (real-time, histórico). Gestión de Acuerdos de Servicios: utiliza los “outputs” de la aplicación de Service Quality Monitoring para proveer una visión del nivel de servicio entregado comparado al pre acordado. Análisis de Impacto y Monitoreo de Calidad de Servicios: aplicaciones diseñadas para autorizar a los operadores a determinar el nivel de servicio están que le están entregando a un cliente. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 13 13 13

Frente Arquitectura Aplicativa Cobertura Futura TAM: Recursos
El dominio “Recursos” administra a todos los componentes (aplicaciones e infraestructura) utilizados para entregar y soportar el servicio requerido o propuesto al cliente. Módulos: Gestión de Procesos de Recursos: aplicaciones para el workflow de los recursos (Testing, Cambio, WorkForce). Gestión de Ciclo de Vida de Recursos: aplicaciones responsables para agregar, modificar o suprimir la capacidad de la red o de la infraestructura. Gestión de Pedidos de Recursos: funcionalidades que manejan el ciclo de vida de un pedido de recursos de punta a punta (disponibilidad del recurso). Gestión de Cumplimiento de Recursos: grupo de aplicaciones responsable del cumplimiento de la función de los recursos (SLA , Métricas). Aplicaciones de Gestión de Inventarios de Recursos: aplicaciones que manejan la información de los recursos utilizados para implementar servicios y productos. Gestión de Recursos de Dominios: área de aplicación que proporciona los recursos a todos los servicios expuestos que están disponibles a todas las otras áreas de aplicación. Aplicaciones de Mediación de Datos de Facturación: aplicaciones para manejar un gran número de datos específicos para las funciones de facturación. Aplicaciones de Mediación de Facturación en Tiempo Real: aplicaciones para manejar datos específicos para las funciones de facturación en tiempo real. Gestión de Vouchers: aplicaciones que manejan todos los aspectos de recargas de Vouchers pre pagados. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 14 14 14

Frente Arquitectura Aplicativa Cobertura Futura TAM: Proveedor
El dominio “Proveedor” agrupa todos las funcionalidades relacionadas con los datos y contratos asociados a los socios y proveedores. Módulos: Gestión de Cadena de Abastecimiento: aplicaciones que manejan la cadena de abastecimiento. Gestión de socios: aplicaciones que permiten manejar las relaciones con los socios (operadores de telecomunicaciones, proveedores de contenido, autoridades de regulación, etc.). Aplicaciones de facturación al por mayor: aplicaciones que permiten facturar todas las capacidades de la cadena de valor con los socios (roaming, resellers, operadores de redes virtuales de móvil, proveedores de contenido, comercio electrónico, etc.). Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 15 15 15

Frente Arquitectura Aplicativa Cobertura Futura TAM: Empresa
El dominio “Empresa” cuenta con las aplicaciones para la gestión interna de la organización. Módulos: Gestión de Aseguramiento de Ganancias: conjunto de métodos para mejorar la calidad de los datos y los procesos que permiten reducir las pérdidas, aumentar los beneficios y la rentabilidad. Gestión de RRHH: aplicaciones que facilitan la gestión de todos los aspectos relacionados con los recursos humanos. Gestión Financiera: aplicaciones para la gestión financiera de la Organización. Gestión de Activos: aplicaciones para la gestión de los activos de la Organización Gestión de Seguridad: aplicaciones de gestión de seguridad. Gestión del Conocimiento: aplicaciones de datawarehousing o BI que permite la Dirección de la Organización consultar los datos apropiados para la toma de decisiones. Gestión de fraude: aplicaciones de gestión de fraude. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 16 16 16

Frente Arquitectura Aplicativa Cobertura Futura TAM: Integración
El dominio “Infraestructura de Integración” trata de la integración de los aplicaciones con la infraestructura según 3 principios claves: La utilización de un bus común de comunicación . La utilización de un workflow de procesos (Business Process Management) . La utilización de contratos de interfaces entre las aplicaciones y un modelo común de información compartido entre todas las aplicaciones. Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto 17 17 17

Infraestructura de Integración
INIT Frente Arquitectura Aplicativa Cobertura Futura del Modelo Mercado / Ventas Bus de integración / SID / Business Process Management Infraestructura de Integración Auxiliar de Ventas Resultados & Compensaciones Gestión de Ventas Masivas Gestión de canales de Ventas Gestión de Ventas Corporativas Portal de Ventas Gestión de Campaña Producto Estrategia de Producto / Gestión de propuestas Gestión de Catálogos de Servicios / Productos Gestión de Ciclo de Vida de Producto Gestión de Desempeño del Producto Planeación y Alistamiento Cumplimiento Aseguramiento Facturación Clientes Autogestión del Cliente Gestión de Cobro Gestión de Facturación Gestión de Pedidos del Cliente Gestión de Información del Cliente Gestión del contacto con el cliente, Retención & Lealtad Control de Facturas Política de Cuenta Indicadores del Servicio al Cliente Facturación Producción de Documentos Transaccionales Gestión de QoS & SLA del Cliente Servicio al Cliente / Resolución de problemas de Cuenta Formato de Facturas Rating de Productos/ Servicios Cargo Online Servicios Gestión de Acuerdos de Servicios Análisis de Impacto y Monitoreo de QoS Especificación de Servicios Gestión de Inventarios de Servicios Gestión de Pedido de Servicios Gestión de Problemas de Servicio Gestión de Desempeño de Servicios Recursos Gestión de Procesos de Recursos (Workflow de Integración) Aplicaciones de Mediación de Datos de Facturación Aplicaciones de Gestión de Inventarios de Recursos Gestión de Ciclo de Vida de Recursos Gestión de Pedidos de Recursos Gestión de Cumplimiento de Recursos Gestión de Vouchers Aplicaciones de Mediación de Facturación en Tiempo Real Gestión de Recursos de Dominios Proveedor Gestión de Socios Gestión de Cadena de Abastecimiento Aplicaciones de facturación al por mayor Empresa Gestión de Aseguramiento de Ganancias Gestión de RRHH Gestión Financiera Gestión de Activos Gestión de Seguridad Gestión del Conocimiento Gestión de fraude 18 Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto

Frente Arquitectura Aplicativa Cobertura Futura del Modelo
INIT Frente Arquitectura Aplicativa Cobertura Futura del Modelo A continuación, se ve estadísticamente la cobertura del Modelo TAM Objetiva: Cubierto 48 Cubierto Parcialmente 5 No Cubierto 3 Total de Módulos 56 19

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO El sistema solo puede ser modificado incurriendo en un costo elevado en tiempo y recursos. El sistema puede ser modificado, en corto tiempo o con esfuerzo razonable. El sistema es flexible pero tiene algunas limitaciones de crecimiento para alcanzar requerimientos futuros. Las variaciones de negocio requieren modificación de código fuente. El sistema es flexible y generalmente una modificación en la lógica de negocio no requiere de modificación de código fuente. Requerimientos funcionales futuros e interfases ya están disponibles. La calificación de cada uno de los aspectos se definió en base a la información relevada durante las entrevistas con los responsables de las distintas áreas, las encuestas realizadas y nuestro conocimiento de las mejores prácticas de la industria. No hay un manual de Usuario desarrollado por Sistemas (algunos sectores hicieron un manual propio). Todos los workflows han sido implementados en código, sin utilizar un motor de workflow. La disposición de la información en las pantallas no es acorde a las necesidades de los usuarios, lo que obliga a los usuarios a iniciar varias sesiones. No hay Instrucciones, no hay una validación automatizada. Muchos pasos desunidos por actividad. Controles excesivos o demasiados abiertos Todas las entradas al sistema son vía teclado (no hay escaneo o pantallas pre-completadas). Jerarquía de procesos rígidas. No hay facilidad para corrección de errores Existen algunas instrucciones de control. La validación en el ingreso de información esta parcialmente automatizada. Las actividades siguen un flujo lógico. Algunas capturas de datos están automatizadas. Fácil corrección de errores. Procesos altamente automatizados. Flujos de procesos flexibles se acomodan a las necesidades del negocio. Validación automatizada. Poca información necesaria para los procesos del negocio es entregada al ser solicitada. Se generan muchos reportes Ad-hoc y/o son necesarios muchos "queries" para generar información. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar la mayoría de las solicitudes. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar a ciertas solicitudes. Se puede entregar la información necesaria para los procesos del negocio. El sistema cuenta con un generador de reportes que permite solucionar la falta de información. Toda la información es entregada al ser solicitada sin necesidad de generar reportes Ad-Hoc o "queries" en el proceso. El aplicativo soporta parcialmente los requerimientos del negocio. Requiere de ajustes para que lo haga de forma adecuada. El aplicativo soporta parcialmente los requerimientos de negocio, pero los soporta de forma adecuada. El aplicativo soporta ciertos requerimientos de negocio, pero no soporta la totalidad de los prioritarios . La aplicación soporta los requerimientos prioritarios de negocio en tiempo y forma. La aplicación soporta en su totalidad los requerimientos del negocio. A Flexibilidad para añadir nuevas Funcionalidades B Facilidad de Uso C Automatización de la Información Flexibilidad del sistema: es sistema efectivamente es flexible, pero considerando la problemática que resuelve, la mejores prácticas de mercado proponen el uso de un workflow o al menos un motor de reglas, de manera de permitir la modificación “declarativa” de los flujos de trabajo/reglas de negocio. El hecho de no utilizar un componente de este tipo hace que la calificación se encuentre en nivel 3. Facilidad de uso: la información se encuentra MUY dispersa, hay falta de validaciones, el usuario no está cómodo y su trabajo es ineficiente. Automaticación de la información: faltan reportes Funcionalidad: hay funcionalidad como por ejemplo Filtros de búsqueda y validaciones que la aplicación no realiza en la actualidad. D Funcionalidad para el actual negocio Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 21 21

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO Hay muchas funcionalidades que no tienen uso y hace al sistema muy engorroso. Hay algunas funcionalidades que no tienen uso y dificultan en cierto grado el uso del sistema Existen algunas funcionalidades no utilizadas, alguna de las cuales dificultan el uso del sistema Existen algunas funcionalidades no utilizadas, pero no dificultan el uso del sistema. El sistema es utilizado en forma completa. Los usuarios de negocio definieron datos como el CBUs, tarjetas y teléfonos como críticos y por ello dicha información debe estar asegurada. La información es poco confiable y requiere de controles adicionales. Hay información que es confiable, pero no es toda y aún se depende de controles adicionales sobre información crítica. La información crítica esta asegurada . Hay cierta información que requiere controles adicionales, pero no es crítica. No hay duda en la precisión y certeza de la información . El sistema un poco o nada confiable, sufre de caídas y/o errores en una frecuencia que impide el normal desarrollo de actividades. La frecuencia de caídas / errores provoca acciones manuales simples que resuelven el problema. Hay caídas / errores que dependiendo del momento en que se produzcan entorpecen el negocio. Hay aun algunas caídas del sistema pero son esporádicas y no afectan el negocio. El sistema es totalmente confiable. El acceso es muy dificultoso y/o los equipos disponibles son inadecuados provocando poca disponibilidad del sistema. La accesibilidad y/o los equipos dificultan el normal desenvolvimiento, pero se dispone adecuadamente del sistema. Los accesos son relativamente aceptables y la utilización del sistema se ve afectada ocasionalmente. Existen algunas dificultades de acceso, pero no son críticas. El acceso y los equipos son adecuados y no causan problemas . E Uso de Capacidades F Calidad de Información Cambié este G Confiabilidad del Sistema H Accesibilidad Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 22 22

Frente Arquitectura Aplicativa Modelo Objetivo
Situación Actual Situación Objetivo - Recomendaciones En varios casos se encontró que la información requerida por un usuario para completar una tarea muy frecuente, está distribuida en varias pantallas, lo cual obliga al usuario a tener que navegar la aplicación para acceder a dicha información. Crear para las tareas más frecuentes (por ejemplo búsqueda y visualización de datos de clientes) pantallas consolidadas que contengan toda la información requerida por los usuarios de manera de minimizar el tiempo que estos invierten en navegar y realizar las tareas más comunes. (APL001) Varios de los datos ingresados por los usuarios carecen de validaciones, lo tiene las siguientes desventajas: Disminuye la calidad de la información almacenada en el sistema, lo cual. Dificulta la realización tareas posteriores. Implementar validaciones de longitud y formato. Y cuando sea posible también implementar los algoritmos de dígito verificador (por ejemplo para números de tarjeta , CBUs, CUITs). (APL002) Se detectó que ante errores la aplicación muestra mensajes inapropiados al usuario. Asimismo cuan por alguna razón el sistema colapsa no se el usuario se encuentra con una pantalla poco amigable que no ofrece ningún tipo de explicación. Definir en el archivo de configuración de la aplicación páginas personalizadas para cuando la aplicación no está disponible. Manejar las excepciones no atrapadas dentro del Global.asax, dejando registro de la excepción y mostrando un mensaje apropiado para usuario. Involucrar a los usuarios clave en la definición de los mensajes. (APL003) Es conocida la falta de reportes de la aplicación Se recomienda la implementación de los reportes más prioritarios. Un punto que puede ayudar a que los reportes se hagan más rápido y fácilmente es el uso del componente ReportViewer, incluido en Visual Studio. Este componente está integrado con el entorno de desarrollo y permite el diseño visual de los reportes. (APL004) 23

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones El sistema es cerrado, imposible añadir interfaces. Permite la extracción de archivos "batch" con programación superior a tres días, pero no permite interfaces en línea. Permite la extracción de archivos "batch" con programación inferior a tres días, pero no permite interfaces en línea. Se pueden crear interfaces "on-line" y "batch" pero requieren de una programación inferior a tres días. Arquitectura abierta, interfases API o EAI disponibles y bien soportadas para todos los datos y funciones. Los tiempos de respuesta son mucho mas lentos que los requeridos. Los tiempos de respuesta exceden por poco los niveles aceptables. Los tiempos de respuesta exceden por poco los niveles aceptables, pero en horarios no críticos. Los tiempos de respuesta son aceptables. Los tiempos de respuesta están por debajo de los requeridos, al información está disponible cuando se necesita. Tiempos off-line o problemas batch frecuentes y significativos que sobrepasan lo aceptable por el negocio. Tiempos off-line o problemas batch ocasionales que sobrepasan los aceptable por el negocio. Ocurren cortes no planeados, pero que no ocasionan un impacto en el negocio. En la mayoría de los casos alcanza los requerimientos de disponibilidad, con sistemas/planes de contingencia. 100% de disponibilidad. Es necesario un esfuerzo significativo de desarrollo (construcción y pruebas unitarias) para el mantenimiento. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo, sin embargo la carga de trabajo hace que el mismo no este siempre disponible. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo. El esfuerzo de mantenimiento es bajo, pero se necesita de habilidades especiales para su desarrollo. El mantenimiento es directo y las habilidades necesarias están completamente disponibles en el mercado. A Facilidad de Integración B Tiempo de Respuesta C Disponibilidad del Sistema D Esfuerzo para Cambios Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 24 24

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones No hay monitoreo proactivo del sistema. Las fallas son reconocidas debido a eventos en cascada. El monitoreo proactivo del sistema es mínimo, hay un ejercicio manual significativo para localizar fallas. Los puntos de falla claves son monitoreados y acciones manuales resuelven las mayoría de las situaciones de falla. La mayoría del sistema es monitoreado con algún soporte automatizado de falla/evento. El sistema es completamente monitoreado en busca de fallas o eventos y son programadas respuestas automatizadas para faltas comunes. Se cree que los cambios propuestos en programación y configuración permitirán alcanzar un nivel 4 en tiempo de respuesta. Para alcanzar un nivel 4 en disponibilidad habría que implementar planes de contingencia. Dado que no hay pruebas automatizadas, ni casos de prueba documentados, cada cambio implica probar manualmente todo el sistema incurriendo en un importante esfuerzo que actualmente no se realiza en parte por la falta de personal. Creemos que el corto plazo la incorporación de un área de testing podría ayudar en este punto. La aplicación es dependiente de versiones de HW/SO especializado que requieren a su vez de habilidades especiales para mantenerlos. La aplicación no depende del HW, pero sí de versiones de SO. La aplicación es altamente dependiente de los estándares de HW/SW de la industria. La aplicación es dependiente de ciertos estándares fácilmente salvables. La aplicación es independiente de la configuración de HW/SW. El sistema esta sobrecargado sin espacio para incrementar su capacidad. El sistema no es escalable, pero las proyecciones actuales no exceden la capacidad actual. El sistema es escalable en el corto plazo en una dimensión (p.e. añadiendo o mejorando el HW). El sistema tiene suficiente escalabilidad para cumplir con las necesidades futuras con una inversión de capital mínima. La aplicación falla al encontrarse con información faltante o en formato incorrecto y finaliza la sesión del usuario. La aplicación falla al encontrase con información faltante o en formato incorrecto, NO muestra mensaje alguno al usuario e interrumpe el flujo de trabajo pero sin finalización de sesión. La aplicación falla al encontrase con información faltante o en formato incorrecto, muestra al usuario un mensaje inapropiado e interrumpe el flujo de trabajo. La aplicación NO falla al encontrase con información faltante o en formato incorrecto. Muestra al usuario un mensaje advirtiendo de la imposibilidad de completar la operación y permite que el mismo continúe trabajando. Al encontrarse con información faltante o en formato incorrecto, la aplicación intenta corregirla y muestra al usuario un mensaje para que este la valide o vuelva a ingresarla y así pueda continuar con la operación en curso. E Control y Monitoreo F Dependencia de HW y SW G Escalabilidad La robustez es la capacidad del software de reaccionar apropiadamente ante condiciones excepcionales. La aplicación hace verificaciones de ningún tipo de los parámetros recibidos, no hay aserciones de código. En ocasiones hay páginas que esperan ciertos parámetros que si por alguna razón no llegan, la aplicación lanza mensaje de error no apropiados. H Robustez Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 25 25

Recomendación para capa de presentación (ViewState)
Frente Aplicaciones Recomendación para capa de presentación (ViewState) Hallazgo Se detectó un exceso en el uso del control ViewState de ASP.NET, el mismo perjudica la renderización de las páginas, incrementando en gran número el tamaño del HTML enviado al navagador. Descripción de la Recomendación Minimizar el uso del ViewState en las páginas, sobre todo en aquellas que contienen grillas. Beneficios Esto tendrá un impacto positivo en la velocidad de renderización de las páginas, haciendo que el sistema sea mas ágil en su navegación. Ayudara a reducir el tráfico dentro de la red, disminuyendo considerablemente el peso de las páginas. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Understanding ASP.NET View State (MSDN) [ ASP.NET Life Cycle and Best Practices [ 26 26 26 26 26 26

Recomendación para capa de presentación (AJAX)
Frente Aplicaciones Recomendación para capa de presentación (AJAX) Hallazgo Fue detectado un uso indebido del Framework AJAX de ASP.NET, sobre todo una práctica en particular que es la colocación del control UpdatePanel en la MasterPage, reduciendo esto, las ventajas del modelo AJAX, haciendo que la todos los controles en la página sean actualizados innecesariamente. Descripción de la Recomendación Quitar el UpdatePanel de la MasterPage e identificar individualmente en cada página los sectores que deben ser actualizados de forma asíncrona, y colocar un UpdatePanel en cada caso, reduciendo así la cantidad de controles a actualizar en las llamadas AJAX. Evaluar en algunos casos la necesidad de agregar código Javascript para ayudar al funcionamiento del Framework y hacer más dinámica la renderización del HTML. Evaluar la utilización de otros componentes JavaScript como: Yahoo User Interface, Scriptaculous y JQuery. Beneficios Esto tendrá un impacto positivo en la velocidad de renderización de las páginas, haciendo que la aplicación resulte más ágil para el usuario. Ayudará a reducir el tráfico entre el navegador y el servidor de presentación. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 27 27 27 27 27 27

Recomendación para capa de presentación (Session)
Frente Aplicaciones Recomendación para capa de presentación (Session) Hallazgo Es común la utilización del objeto Session para almacenar información relacionada al caso de uso en curso, pero en ocasiones esta información no es liberada después de ser utilizada, lo cual genera un gasto innecesario de memoria. Descripción de la Recomendación Limpiar de la sesión la información almacenada temporalmente apenas esta deja de ser útil. Beneficios Mejor uso de los recursos de memoria del servidor de presentación. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 28 28 28 28 28 28

Recomendación para capa de presentación (cssfriendly)
Frente Aplicaciones Recomendación para capa de presentación (cssfriendly) Hallazgo Descripción de la Recomendación La utilización de los CSS Friendly controls modifica la renderización de los controles ASP.NET, generando HTML más claro y conveniente para la aplicación de estilos CSS. Beneficios Páginas más livianas. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 29 29 29 29 29 29

Recomendación para capa de presentación (navegación)
Frente Aplicaciones Recomendación para capa de presentación (navegación) Hallazgo Se detectó el uso de la instrucción Response.Redirect para manejar el flujo de navegación entre pantallas, lo obliga a realizar un postback adicional. Descripción de la Recomendación Reemplazar todos las apariciones de Response.Redirect con Server.Transfer. Beneficios Reducción de Round-Trips al servidor Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Response.Redirect vs Server.Transfer[ 30 30 30 30 30 30

Recomendación para capa de presentación (async)
Frente Aplicaciones Recomendación para capa de presentación (async) Hallazgo La capa de presentación consume toda la lógica en forma remota de la capa de negocio via web services haciendo invocaciones sincrónicas, no importa cuan compleja sea la operación a ejecutar. Descripción de la Recomendación Para los casos de operaciones complejas considerar el uso de llamadas asincrónica. Beneficios Mejora en la percepción del usuario. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 31 31 31 31 31 31

Recomendación para la capa de servicios (sin estado)
Frente Aplicaciones Recomendación para la capa de servicios (sin estado) Hallazgo La sesión se encuentra activada en la capa de servicios, lo cual es innecesario pues la misma se está utilizando en forma stateless, tal cual recomiendan las prácticas de SOA. Descripción de la Recomendación Desactivar en ASP.NET la sesión, puesto que los servicios no deberían hacer uso de la misma. Beneficios Disminuirá el consumo de memoria. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Improving .NET Application Performance and Scalability, Capítulo 3, ISBN: , Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido. 32 32 32 32 32 32

Recomendación para la capa de servicios (DataSets)
Frente Aplicaciones Recomendación para la capa de servicios (DataSets) Hallazgo Toda la capa de servicios utiliza como transporte DataSets, lo cual dificulta la interoperabilidad y requiere de procesamiento adicional debido a la forma en que los mismos son serializados. Descripción de la Recomendación Reemplazar el uso de DataSets por objetos planos. Beneficios Permitirá que los servicios sean consumidos desde otras plataformas y mejorará (de manera imperceptible) el desempeño de la aplicación. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 33 33 33 33 33 33

Recomendación para la capa de servicios (WCF)
Frente Aplicaciones Recomendación para la capa de servicios (WCF) Hallazgo Para la implementación de la capa de servicios se utilizó una tecnología actualmente considerada en desuso dentro del ambiente .Net (asmx), la cual limita solo a Web Services el protocolo de comunicación y formato de mensajes. Descripción de la Recomendación Migrar los servicios a WCF, lo cual obligará a una explícita separación entre interface e implementación. Beneficios La adopción de WCF dará una mayor flexibilidad a la hora de hacer cambios o correciones. El sistema dejará de tener una limitación tecnológica en el caso de querer migrar a otros protocolos de transporte para mejorar algunos aspectos de la comunicación. Prerrequisitos Beneficio Impacto Plazo Sacar los DataSets de la capa de presentación. Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia WCF Tips [ Integrating WCF with your existing ASMX Services [ 34 34 34 34 34 34

Recomendación para la capa de acceso a datos (paginación)
Frente Aplicaciones Recomendación para la capa de acceso a datos (paginación) Hallazgo Detectamos que la aplicación carece de una política de paginación a nivel Acceso a datos. Algunas páginas con grillas paginadas no traen sólo los datos a mostrar, si no que todo el conjunto de información, y luego muestran la página correspondiente. Esto carga la red de datos innecesarios y por lo tanto impacta negativamente en la performance de la aplicación. Descripción de la Recomendación Paginar las consultas que devuelven gran cantidad de resultados directamente desde NHibernate. Beneficios Esto tendrá un impacto en la performance de la aplicación. Disminuyendo el tráfico de la misma. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 35 35 35 35 35 35

Recomendación para la capa de acceso a datos (config)
Frente Aplicaciones Recomendación para la capa de acceso a datos (config) Hallazgo Hay algunos seteos en la configuración de Hibernate que podrían optimizarse Descripción de la Recomendación Ajustar la configuración de los siguientes parámetros: ShowSql = false Analizar utilizar Lazy Loading en las asociaciones (archivos de mapeo) Beneficios Esto tendrá un impacto en la performance de la aplicación. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Understanding Lazy Loading Strategies for NHibernate [ 36 36 36 36 36 36

Slide a hacer por Snoop el Lunes
Frente Arquitectura Aplicativa Recomendaciones al nivel general A continuación, detallamos recomendaciones tratando de los temas de : - Tienen para objetivo de mejorar : Slide a hacer por Snoop el Lunes 37 37 37

Recomendaciones generales (excepciones)
Frente Aplicaciones Recomendaciones generales (excepciones) Hallazgo Como resultado del relevamiento realizado en el código fuente, detectamos un pobre manejo de excepciones, en algunos casos la falta de logging del error, solo se atrapan excepciones genéricas, en otros se lanza una nueva excepción perdiendo el stack de errores previo, etc. Descripción de la Recomendación Definir una política uniforme para el manejo de excepciones a partir de identificar las zonas más críticas del sistema e ir aplicando políticas de captura, registro, propagación y notificación de excepciones, creando así, por un lado, una serie de Custom Exceptions que implementen excepciones a reglas de negocio (heredando de ApplicationException) y por el otro, identificar las posibles excepciones técnicas que se pueden generar en estas partes del código. En ambos casos lanzar las excepciones sin perder el stack, con un mensaje más “user friendly” y loggear previamente las mismas. Beneficios Esto tendrá un impacto positivo en la robustez del sistema, teniendo el usuario una percepción mas segura del sistema y un informe de los errores más amigable. Ayudará a facilitar la identificación de las causantes de bugs inesperados, mediante el log de excepciones. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Cambio esto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Exception Handling (MSDN) [ Throwing Exceptions in C# [ 38 38 38 38 38 38

Recomendaciones generales (caché)
Frente Aplicaciones Recomendaciones generales (caché) Hallazgo Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación. Descripción de la Recomendación Agregar prácticas de Cache, tanto en la capa de presentación, como en la capa de Datos (NHibernate) Utilización del Caché de ASP.NET, evaluar el uso de algún Framework de Caché como por ejemplo NCache o CachingApplication Block. Beneficios Esto tendrá un impacto positivo en la performance del sistema, mejorando los tiempos de respuesta del mismo Ayudará a disminuír el tráfico de la red. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Caching with ASP.NET [ Caching Application Block (MSDN) [ NHibernate.Caches [ 39 39 39 39 39 39

Recomendaciones generales (codificación)
Frente Aplicaciones Recomendaciones generales (codificación) Hallazgo Se detectaron malas prácticas en la codificación, algunas referentes a C sharp y otras a generalidades de .Net. Descripción de la Recomendación Actualizar y respetar las convenciones ya definidas . Utilizar herramientas como StyleCop y FxCop para automatizar la verificación del cumplimiento de dichas prácticas. Beneficios Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Microsoft FxCop [ Microsoft StyleCop [ 40 40 40 40 40 40

Recomendaciones generales (instrumentación)
Frente Aplicaciones Recomendaciones generales (instrumentación) Hallazgo Se detectó una pobre instrumentación de la aplicación en todas las capas. Reduciendo la posibilidad de controlar las eventualidades que puedan ocurrir en el ambiente productivo. Descripción de la Recomendación Instrumentar la aplicación en sus diferentes capas considerando: Instrumentación del Pipeline de ejecución Contadores de performance Escribir en el Event Log uso de librería de logging (Archivos de texto, base de datos) Monitoreo Beneficios Esto tendrá un leve impacto en la robustez de la aplicación. Ayudará a tener un mayor visibilidad del comportamiento de la aplicación frente a posibles errores en el ambiente de producción y facilitará el diagnostico de problemas. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Introduction to Instrumentation and Tracing [ 41 41 41 41 41 41

Recomendaciones generales (liberación de recursos)
Frente Aplicaciones Recomendaciones generales (liberación de recursos) Hallazgo Se detectaron que varios de los objetos de la solución son volátiles y hacen uso de recursos no manejados, pero a pesar de eso no son liberados instantáneamente. Descripción de la Recomendación Implementar IDisposable en las clases mencionadas anteriormente. Beneficios Esto permitirá hacer un uso más optimo de la memoria ya que los recursos se liberarán apenas dejen de ser utilizados. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Cambio esto Bajo Largo Referencia CLR Inside Out [ Objetos desechables con la interfaz IDisposable [ 42 42 42 42 42 42

Recomendaciones Capa de Datos (PK)
Frente Aplicaciones Recomendaciones Capa de Datos (PK) Hallazgo Se detectó gran cantidad de tablas con PK que no tienen índices asociados. Descripción de la Recomendación Analizar el modelo y en caso que dichas tablas se accedan con alguna consulta identificar las pasibles PK y crearlas Beneficios Los planes de ejecución para dichas tablas pueden mejorar notablemente beneficiando los tiempos de resolucion de dichas consultas. Tambien se estaria cumpliendo con la 3ra condicion de la 1NF (1ra forma normal) Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Oracle Tunning, Donald Burleson, ISBN: 43 43 43 43 43 43

Recomendaciones Capa de Datos (indices)
Esto es relevante en cuanto a performance ya que al mantener las estadisticas actualizadas el optimizador puede seleccionar el plan de ejecución mas adecuado. Frente Aplicaciones Recomendaciones Capa de Datos (indices) Hallazgo Se detectó estadísticas de tablas e índices con mas de 3 meses de realizadas. Descripción de la Recomendación En caso de no tener habilitado el job automático de recolección de estadísticas analizar los movimientos de esas tablas y ejecutar la actualización de manera manual (con un scheduler) Beneficios Esto es relevante en cuanto a performance ya que al mantener las estadisticas actualizadas el optimizador puede seleccionar el plan de ejecución mas adecuado. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 44 44 44 44 44 44

Recomendaciones Capa de Datos (extends)
Frente Aplicaciones Recomendaciones Capa de Datos (extends) Hallazgo Se detectaron objetos (tablas e índices) con alta cantidad de extents. Descripción de la Recomendación Para segmentos mayores a 5G se recomienda utilizar un tablespace con manejo de extents en UNIFORM SIZE con extents de 64MB o superiores. Esto aplica tanto para tablas como para índices. Los pasos serian: Crear tablespaces de datos e índices con las características mencionadas arriba Identificar los segmentos candidatos y recrearlos en dichos tablespaces Beneficios Esto beneficia a la velocidad de acceso a los datos para los full scan ya que los bloques estaran en forma contigua. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Oracle Tunning, Donald Burleson, ISBN: 45 45 45 45 45 45

Recomendaciones Capa de Datos (executeparse)
Frente Aplicaciones Recomendaciones Capa de Datos (executeparse) Hallazgo Se detectó bajo valor de Execute to Parse. Descripción de la Recomendación La solución a este problema es la utilización de bind variables en la construcción de los Querys. Beneficios Con esto evitamos la etapa de parseo que es una de las mas costosas al momento de la ejecución de la consulta. Durante esta etapa se verifican la sintaxis y derecho de acceso a los objetos etc. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 46 46 46 46 46 46

Recomendaciones Capa de Datos (full scans)
Frente Aplicaciones Recomendaciones Capa de Datos (full scans) Hallazgo Alta cantidad de full scan en tablas pequeñas. Descripción de la Recomendación Para las tablas de poco tamaño que son accedidas frecuentemente es recomendable configurar la SGA para la utilización del "keep buffer pool" esta region de memoria se utiliza para mantener objetos en el buffer cache. El parametro a modificar es el "buffer_pool_keep", se calcula como el total de memoria que necesitan las tablas candidatas para almacenarse en memoria. Para determinar las tablas mas accedidas se pueden usar varias fuentes. 1) Estadisticas a nivel de AWR 2) Habilitar la auditoria a nivel de base para saber que tablas fueron mas consultadas. Beneficios Con esto evitamos que los segmentos mas accedidos sean leidos continuamente de disco, ya que al estar en el "buffer pool keep" se mantendran los bloques en la SGA. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Metalink : Oracle Multiple Buffer Pools Feature Note: 47 47 47 47 47 47

Recomendaciones Capa de Datos (cache waits)
Frente Aplicaciones Recomendaciones Capa de Datos (cache waits) Hallazgo Fue detectado un alto valor de library cache waits. Descripción de la Recomendación El procedure keep del package dbms_shared_pool hace que el package pasado como parámetro sea cargado en memoria (Shared Pool) y no sea considerado "viejo" para sacarlo de la memoria. Beneficios Es muy útil para grandes objetos que son usados frecuentemente, puede bajar considerable los tiempos de espera de library cache. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 48 48 48 48 48 48

Gran numero de chained/migrated rows
Frente Aplicaciones Recomendaciones Capa de Datos (optimizador) Hallazgo Falta de ajuste en el optimizador de costos de indices Descripción de la Recomendación Es aconsejable que se hagan pruebas de performance con los parámetros de optimización de índices con los siguientes valores: optimizer_index_cost_adj=1 optimizer_index_caching=100 OPTIMIZER_INDEX_COST_ADJ : Es para tunear el comportamiento default del optimizador haciéndolo mas o menos propenso a la selección de un índice sobre un full scan. OPTIMIZER_INDEX_CACHING : Nos permite ajustar el comportamiento default del CBO favoreciendo los nested loop y las comparaciones con cláusulas IN. Gran numero de chained/migrated rows Beneficios Cambio esto Estos parametros modifican el comportamiento del optimizador para que favorezca la utilización de indices sobre los full scan, ,con esto podemos reducir el costo total de los planes de ejecución, mas precisamente sobre aquellas consultas con full scan. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 49 49 49 49 49 49

Recomendaciones Capa de Datos (chained/migrated)
Frente Aplicaciones Recomendaciones Capa de Datos (chained/migrated) Hallazgo Se detectó gran numero de chained/migrated rows Descripción de la Recomendación Esto indica que hay registros que no entran completamente en un bloque (chained row), y por consiguiente el registro esta ditribuido en dos o mas bloques lo que hace que se deba hacer mas de una lectura fisica para leer dicho registro. Tambien puede indicar la existencia de migrated rows (registros que al ser actualizados se tuvieron que mover de bloque). Para verificar la existencia de las tablas con chained row se puede ejecutar el siguiente query. select * from dba_tables where chain_cnt > 0; En caso de existir tablas con chained rows analizar la creación de tablespaces con blocksize acorde con el tamaño del registro. Tambien se sugiere implementar periódicamente las recomendaciones de mantenimiento de segmentos según al Advisor por default de Oracle, de esta manera reorganizando los segmentos que estan mas fragmentados se puede solucionar los problemas con las migrated rows. Para ver las recomendaciones se puede acceder via el EM web o bien ejecutar el siguiente query: select * from table(dbms_space.asa_recommendations('FALSE', 'FALSE', 'FALSE')) order by reclaimable_space desc Cambio esto Beneficios Con las recomendaciones sugeridas por el Segment Advisor podemos defragmentar las tablas mas fragmentadas reduciendo espacio en disco e incrementando la velocidad de acceso. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Metalink : Row Chaining and Row Migration Note: 50 50 50 50 50 50

Esto va en infraestrctura
Frente Infraestructura Recomendación para IIS (reciclado de proceso) Hallazgo Se detectó que la configuración de reciclado de procesos podría ser mejorada a partir de los cambios propuestos a nivel de aplicación. Si bien el reciclado de proceso no produce la pérdida de la sesión del usuario, si se pierde la información almacenada en la sesión del usuario, lo cual puede ser la causa de algunos errores reportados por los usuarios. Descripción de la Recomendación El reciclado de procesos está pensado para ser utilizado en el caso de aplicaciones que tienen “memory leaks”, (típicamente aplicaciones COM). Si bien en .NET estas situaciones son mucho menos frecuentes (ya que la memoria es administrada por el runtime de .NET a través del recolector de basura) puede que resulte necesario reciclar el proceso esporádicamente. Si bien no existe la posibilidad de definir un valor único de los parámetros de reciclado, (pues los mismos dependen de cada aplicación.), se recomienda realizar pruebas para lograr ajustar dicho parámetro para la aplicación en cuestión. Se recomienda probar estableciendo el límite de memoria para cada proceso en un valor inicial de 1,5 GB. Beneficios A partir de esto puede que las situaciones abruptas de finalización de sesión sean mucho más esporádicas. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Medio Mediano Mantenibilidad Bajo Largo Referencia 51 51 51 51 51 51

Frente Infraestructura Recomendación para Asp.Net (sesion) Hallazgo A pesar de tener implementado balanceo de carga en la capa física de presentación se está utilizando modo de sesión inprocess. Esto hace que cuando se recicla el proceso los usuarios pierdan la información de sesión experimentando interrupciones en su trabajo. Descripción de la Recomendación Implementar un modo de sesión independiente del proceso . Beneficios Esto evitará que los usuarios sufran las mencionadas interrupciones. Cambio esto Prerrequisitos Beneficio Impacto Plazo Dependiendo de la estrategia elegida, puede ser necesario adquirir hardware adicional. Performance Alto Corto Usabilidad Medio Mediano Mantenibilidad Bajo Largo Referencia Improving .NET Application Performance and Scalability, ISBN: , Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido. 52 52 52 52 52 52

Frente Infraestructura Recomendación para Asp.Net (System.Net) Hallazgo Los servidores de aplicaciones tiene la configuración estándar para el máximo valor de conexiones salientes (dicho valor es 2). Este valor es apropiado para aplicaciones desktop que consumen servicios, pero en el caso de aplicaciones Asp.Net dicho valor extremadamente bajo. Descripción de la Recomendación Modificar el parámetro en cuestión en la configuración de la aplicación tal como se muestra a continuación. <system.net> <connectionManagement> <add address="[webservice-ip]" maxconnection="100" /> </connectionManagement> </system.net> Beneficios Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware. Cambio esto Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Medio Mediano Mantenibilidad Bajo Largo Referencia Improving .NET Application Performance and Scalability, Capítulo 17, ISBN: , Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido. 53 53 53 53 53 53

Frente Infraestructura Recomendación para Asp.Net (process model) Hallazgo Los servidores de aplicaciones tiene la configuración estándar del processModel de Asp.Net, ciertos paràmetros no vienen con los valores más adecuados. Descripción de la Recomendación Ajustar los siguientes parámetros de configuración del processModel de Asp.Net. En particular los últimos dos parámetros es realizar pruebas para lograr dar con los valores apropiados. <processModel memoryLimit="80" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="40" minIoThreads="30" > Beneficios Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Medio Mediano Mantenibilidad Bajo Largo Referencia Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: , Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido. 54 54 54 54 54 54

Frente Infraestructura Recomendación para Asp.Net (pipeline de ejecución) Hallazgo Los servidores de aplicaciones tiene la configuración estándar del pipeline de ejecución de Asp.Net. Pero dado que la aplicación no hace uso de todos los módulos del pipeline, podrían removerlos los módulos no utilizados para así disminuir el costo de procesamiento de pedidos. Descripción de la Recomendación Removerlos del pipeline de ejecución de Asp.Net los módulos no utilizados . En principio podrían removerse los módulos de autenticación Windows y Passport. Esto se hace en el archivo de configuración de cada aplicación de la forma que se muestra a continuación. (Web.config). <httpModules> <remove name=“nombreDelModulo“/> <remove name="WindowsAuthentication" /> <remove name="PassportAuthentication" /> </httpModules> Beneficios Esto disminuiría el costo de procesamiento de los pedidos procesados por Asp.Net. Si bien esto es una mejora en la performance de la aplicación, la misma resulta casi imperceptible para el usuario. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Medio Mediano Mantenibilidad Bajo Largo Referencia Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: , Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido. 55 55 55 55 55 55

Recomendación para proceso de desarrollo (definición)
Frente Aplicaciones Recomendación para proceso de desarrollo (definición) Hallazgo El proceso de desarrollo utilizado es particular de Telecentro y es totalmente informal, no existe documentación del mismo y si bien se lo va ajustando según las necesidades del momento, no existe ninguna formalización del proceso. Esto hace que ante la incorporación de nuevos recursos deba invertirse tiempo de recursos para informar sobre la forma de trabajo. Descripción de la Recomendación Definir formalmente, aunque sea a alto nivel, el procesos de desarrollo utilizado, documentarlo y comunicarlo a todo el equipo. A la hora de ajustar el procesos, plantear los cambios formalmente, ajustar la documentación y comunicar a todo el equipo los ajustes realizados. Beneficios Menor tiempo de inducción a los recursos. Tener un proceso por mínimo que sea permitirá la posterior definición de métricas para poder medir y mejorar tanto el procesos como el desempeño del equipo. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Ver como ajustar esto Referencia 56 56 56 56 56 56

Recomendación para proceso de desarrollo (colaboración)
Frente Aplicaciones Recomendación para proceso de desarrollo (colaboración) Hallazgo Descripción de la Recomendación Independientemente de la implementación formal de un proceso de desarrollo, se recomienda el uso de herramientas colaborativas (wiki)que permitan centralizar y dejar por escrito todo el conocimiento de la aplicación, tanto por parte de los usuarios como de equipo de desarrollo. Beneficios Centralización y distribución de la información. Posibilidad de acceso global. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Ver como ajustar esto Referencia 57 57 57 57 57 57

Recomendación para proceso de desarrollo (test)
Frente Aplicaciones Recomendación para proceso de desarrollo (test) Hallazgo Actualmente no hay pruebas automatizadas de la aplicación Descripción de la Recomendación Para poder realizar pruebas automatizadas de la aplicación se recomienda el uso de las siguientes herramientas: Nunit: pruebas unitarias de clases SOAP UI: pruebas unitarias y de stress de web services Application Center Test: pruebas de stress de aplicación web FIT: pruebas funcionales de aceptación de usuario Beneficios Disminución de los costos de test. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Ver como ajustar esto Referencia 58 58 58 58 58 58

Recomendaciones generales (caché)
Esta repetida Frente Aplicaciones Recomendaciones generales (caché) Hallazgo Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación. Descripción de la Recomendación Agregar prácticas de Cache, tanto en la capa de presentación, como en la capa de Datos (NHibernate) Utilización del Caché de ASP.NET, evaluar el uso de algún Framework de Caché como por ejemplo NCache o CachingApplication Block. Beneficios Esto tendrá un impacto positivo en la performance del sistema, mejorando los tiempos de respuesta del mismo Ayudará a disminuír el tráfico de la red. Prerrequisitos Beneficio Impacto Plazo Analizar las distintas alternativas de implementación (¿En que capa? y ¿Con que componente?) Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Caching with ASP.NET [ Caching Application Block (MSDN) [ 59 59 59 59 59 59

Idem a Capa de Presentación (Sección)
Esta repetida Frente Aplicaciones Recomendaciones generales (liberación de recursos) Hallazgo Se detectaron procesos donde se utilizan recursos del servidor y al terminar no se liberan correctamente. Descripción de la Recomendación Verificar los procesos donde existe mayor utilización de los recursos del servidor. Implementar IDisposable en las clases detectadas anteriormente. Idem a Capa de Presentación (Sección) Beneficios Ejecutar esta recomendación impactará en la performance de la aplicación. Optimizando los recursos del IIS, particularmente el manejo de memoria. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia CLR Inside Out [ Objetos desechables con la interfaz IDisposable [ 60 60 60 60 60 60

Recomendaciones generales (excepciones)
Esta repetida Frente Aplicaciones Recomendaciones generales (excepciones) Hallazgo Como resultado del relevamiento realizado en el código fuente, detectamos un pobre manejo de excepciones, en algunos casos la falta de logging del error, solo se atrapan excepciones genéricas, en otros se lanza una nueva excepción perdiendo el stack de errores previo, etc. Descripción de la Recomendación Definir una política uniforme para el manejo de excepciones a partir de identificar las zonas más críticas del sistema e ir aplicando políticas de captura, registro, propagación y notificación de excepciones, creando así, por un lado, una serie de Custom Exceptions que implementen excepciones a reglas de negocio (heredando de ApplicationException) y por el otro, identificar las posibles excepciones técnicas que se pueden generar en estas partes del código. En ambos casos lanzar las excepciones sin perder el stack, con un mensaje más amigable (user friendly) y loggear previamente las mismas. Beneficios Esto tendrá un impacto positivo en la robustez del sistema, teniendo el usuario una percepción mas segura del sistema y un informe de los errores más amigable. Ayudará a facilitar la identificación de las causantes de bugs inesperados, mediante el log de excepciones. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Exception Handling (MSDN) [ Throwing Exceptions in C# [ 61 61 61 61 61 61

Recomendaciones generales (codificación)
Esta repetida Frente Aplicaciones Recomendaciones generales (codificación) Hallazgo Se detectaron malas prácticas en la codificación, algunas referentes a C sharp y otras a generalidades de .Net. (Ver mayor detalle en entregable Fase I) Descripción de la Recomendación Actualizar y respetar las convenciones ya definidas . Utilizar herramientas como StyleCop y FxCop para automatizar la verificación del cumplimiento de dichas prácticas. Beneficios Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia Microsoft FxCop [ Microsoft StyleCop [ 62 62 62 62 62 62

Recomendación para proceso de desarrollo (definición)
Esta repetida Frente Aplicaciones Recomendación para proceso de desarrollo (definición) Hallazgo El proceso de desarrollo utilizado es particular de Telecentro y es totalmente informal, no existe documentación del mismo y si bien se lo va ajustando según las necesidades del momento, no existe ninguna formalización del proceso. Esto hace que ante la incorporación de nuevos recursos deba invertirse tiempo de recursos para informar sobre la forma de trabajo. Descripción de la Recomendación Definir formalmente, aunque sea a alto nivel, el procesos de desarrollo utilizado, documentarlo y comunicarlo a todo el equipo. A la hora de ajustar el procesos, plantear los cambios formalmente, ajustar la documentación y comunicar a todo el equipo los ajustes realizados. Beneficios Menor tiempo de inducción a los recursos. Tener un proceso por mínimo que sea permitirá la posterior definición de métricas para poder medir y mejorar tanto el procesos como el desempeño del equipo. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Volver a verificar Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 63 63 63 63 63 63

Frente Arquitectura Aplicativa Metodologías de Desarrollo
Una metodología de desarrollo debe tener como mínimo las siguientes grandes actividades: Estudio del negocio: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software. Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo lo solicitado está presente. También deben incluirse actividades de soporte como son: Configuración y administración del cambio, Administrando el proyecto, Administrando el ambiente de desarrollo, Administración de la salida del proyecto. En todas las actividades el usuario debe participar y validar el resultado de cada fase Algunos ejemplos de metodologías que pueden utilizarse dependiendo del proyecto que se va a iniciar. Rational Unified Process (RUP) Extreme Programing (XP) La Metodología RUP es mas adaptable para proyectos de largo plazo. La Metodología XP en cambio, se recomienda para proyectos de corto plazo. La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología. Podemos concluir además, que lo más importante antes de elegir la metodología que usarás para la implementación de tu software, es determinar el alcance que tendrá y luego de ahí ver cual es la que más se acomoda en tu aplicación. Microsoft Solution Framework (MSF) 64

Frente Arquitectura Aplicativa Calidad de Datos - Introducción
INIT Frente Arquitectura Aplicativa Calidad de Datos - Introducción Llamamos depuración de datos (data cleansing) al conjunto de acciones realizadas para asegurar que la información de los sistemas sea correcta y exacta. Estas acciones pueden ser realizadas por: Un equipo de personas que verifiquen los campos y registros de las bases de datos, y verifiquen su exactitud y coherencia. Programas, los cuales verifican los datos a través de una variedad de reglas y procedimientos configurados por el usuario. Existe una variedad de errores que se pueden encontrar en un sistema. El siguiente cuadro ejemplifica alguno de ellos: Tipo de error Ejemplo Datos inconsistentes a través de distintas unidades operativas Número de cliente Duplicación de registros Cliente Datos incompletos Dirección del cliente Registros con valores inconsistentes Fecha de alta de cliente Datos desactualizados Bajas de cliente 65

Frente Arquitectura Aplicativa Recomendación XXX
Particularidad Se evidenció desconfianza por parte de los usuarios en cuanto a la integridad de los datos almacenados en el CRM Triple Play, por lo tanto muchos de los usuarios continúan utilizando el antiguo Sistema FOX para validar cierta información. Descripción de la Recomendación Realizar un proceso de depuración de datos para eliminar registros erróneos que generen problemas con las aplicaciones. Beneficios Mejorar la calidad de información en los distintos sistemas y evitar la ocurrencia de errores por problemas con la información de las bases de datos. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Ninguno Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 66 66 66 66 66 66

Frente Arquitectura Aplicativa Recomendación Documentación
Recomendación sobre como hacer una documentación si se necesita – mande el mail a Snoop La Metodología RUP es mas adaptable para proyectos de largo plazo. La Metodología XP en cambio, se recomienda para proyectos de corto plazo. La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología. Podemos concluir además, que lo más importante antes de elegir la metodología que usarás para la implementación de tu software, es determinar el alcance que tendrá y luego de ahí ver cual es la que más se acomoda en tu aplicación. 67

Frente Arquitectura Aplicativa
Estándares de Documentación - Lineamientos Identificar Enfoques según Roles Para cada uno de los roles del área de TI, habrá diferentes necesidades de información, por lo tanto se requieren distintos enfoques en la documentación: Gerencia de Sistemas: objetivos de negocio; capacidades y limitaciones en los servicios de TI. Arquitecto: capacidades y limitaciones en la arquitectura; plan para expandir sus capacidades; especificaciones de sus estándares; soporte para la decisión. Programadores: código; comentarios; relación entre módulos. Diseñar en base a su Utilidad Pensar en la utilidad que le va a dar cada rol a la documentación, y diseñar en base a esto. Para asegurar la calidad del diseño, se pueden plantear pruebas de escenarios con los diferentes roles, suponiendo diferentes situaciones y necesidades de información. Un punto importante a tener en cuenta, es la precisión de la información, ya que cuanto mayor es el volumen, más difícil el diseño y la navegación. Crear y ejecutar Plan de Comunicación Generar la documentación de TI conlleva un alto costo en tiempo y recursos, y muchas veces este trabajo no es bien “vendido” al resto de la organización. Por lo tanto es importante crear y ejecutar un plan de comunicación, ya que el éxito de una iniciativa de documentación, depende del grado de uso que se le dé a la misma. Actualizar documentación El mantenimiento de la documentación debe ser un proceso continuo, ya que es imperativo que la misma refleje la situación real y actual del área de TI. 68 68 68

Frente Arquitectura Aplicativa Estándares de Documentación
Como hemos identificado en la evaluación, existe una importante carencia en la documentación de las aplicaciones y su modelo de datos, con las desventajas y riesgos que esto implica. Para soportar cualquier iniciativa futura que implique cambios en la arquitectura aplicativa (nuevos requerimientos, nuevas interfaces, migraciones), será necesario actualizar la documentación existente y mantenerla de forma periódica. A continuación, presentamos los elementos claves que debe contener la documentación para que agregue valor (y no caiga en desuso), y los lineamientos a seguir para lograr este objetivo: Diseño Precisión Enfoque Elementos Claves Comunicación Roles Actualización Valor Agregado 69 69 69

Frente Arquitectura Aplicativa Integración- Tendencias
Principales Preocupaciones en TI La definición de estándares y principios guía (gobierno) de arquitectura aplicativa aparecen como unas de las principales preocupaciones de los Gerentes de Sistemas (CIO) en la actualidad: ¿Cuáles son las tres (3) principales preocupaciones de los CIO’s? Costo Aplicación Arquitectura Otros A continuación, desarrollamos algunos de los principios guía de arquitectura aplicativa anteriormente mencionados: 71 71 71 71 71

Frente Arquitectura Aplicativa Integración - Introducción
INIT Frente Arquitectura Aplicativa Integración - Introducción La integración es un concepto que permite utilizar los activos tecnológicos, estándares y recursos, con el fin de resolver requerimientos de integración y crear soluciones efectivas Para que esto sea posible, es indispensable contar con una arquitectura flexible y que permita una ágil integración con sistemas tanto internos como externos de la Organización. La velocidad de cambio llevó a las compañías de telecomunicaciones a cubrir las necesidades de integración de manera poco planificada, derivando en arquitecturas de integración complejas, donde no se tiene muy en claro las relaciones y controles existentes entre las aplicaciones. Según lo contemplado en el diagnóstico realizado en la Fase I, Telecentro no escapa a esta realidad, contando con un mapa de integración complejo (topología punto a punto), con una cantidad significativa de interfaces manuales y escasos procesos de control y automatización. 72

Frente Arquitectura Aplicativa Integración - Introducción
INIT Frente Arquitectura Aplicativa Integración - Introducción Los mapas de integración punto a punto son más difíciles de reutilizar, mantener, controlar y automatizar. Las interfaces automatizadas y centralizadas mediante alguna tecnología, resulta en mapas de integración más eficientes y fáciles de mantener. Core Siebel SAP Internet People Soft No. de Aplicaciones No. de Interfaces Topología Punto a Punto No. de Aplicaciones No. de Interfaces App. B App. C App. A App. D App. E Topología con Middleware 73

Frente Arquitectura Aplicativa Integración - Evolución
El roadmap de integración es a largo plazo y se debe encarar de manera planificada. De esta forma se puede evolucionar hacia aplicaciones más complejas con el fin de brindar un mayor valor al negocio: El desafío de la integración no es la tecnología, sino los procesos y la organización, siendo estos aspectos los que permiten un verdadero alineamiento de Sistemas con el negocio. 74 74 74 74 74 74

INIT Frente Arquitectura Aplicativa Mapa de Integración (Mediano Plazo – 6 a 18 meses) A continuación presentamos el mapa de integración de los distintos aplicativos: Red de Telefonía Red de Telefonía Agentes Recaudadores Nuevo sistema telefonía post pago Valorizador FOX Oracle Financials Pago Fácil RapiPago Bapropagos Bancos Archivos de Contabilidad CDRs Consumo de materiales Facturación Activaciones / Desactivaciones/ Pagos Recaudación CDRs Prebilling y Billing Resultado Débito/ Cargos Comisionables Disponibilidad de Materiales Clientes Tarjetas por DAT/Pago directo CRM Triple Play Información Facturación A Debitar Estado del Servicio DAC 6000 Sistema Clientes Corporativos CPP Consumos CPP Activaciones / Desactivaciones Red de CATV Movistar Claro Personal Nextel Reporting Liquidaciones Estado del Servicio Activaciones / Desactivaciones CARENA INTRAWAY IPUNITY Altas y Bajas Entes Externos Nuevos sistemas Red de Banda Ancha Casilla de Mensajes 75

INIT Frente Arquitectura Aplicativa Mapa de Integración (Largo Plazo – > 18 meses) A continuación presentamos el mapa de integración de los distintos aplicativos: Red de Telefonía Nuevo sistema telefonía post pago Valorizador Base de Conocimiento FOX Oracle Financials Prebilling y Billing CRM Triple Play DAC 6000 Sistema Clientes Corporativos BUS DE INTEGRACIÓN DW BPM Reporting Agentes Recaudadores Tarjetas por DAT/Pago directo CPP CARENA INTRAWAY IPUNITY Pago Fácil RapiPago Bapropagos Bancos Movistar Claro Personal Nextel Entes Externos Nuevos sistemas 76

Automatización de controles
Frente Arquitectura Aplicativa Integración Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO La redundancia es excesiva y esta presenta en todos las aplicaciones. Ya hay algunas interfaces únicas y se reutilizan. El 80/20 de las interfaces críticas ya son únicas. Las principales interfaces son únicas. Las interfaces son únicas y sirven a todas las aplicaciones. La implementación de un bus de integración simplificará la arquitectura aplicativa, permitiendo concentrar la lógica del negocio (transformación) en un único repositorio (bus). Con esto se logra contar con una arquitectura mucha más flexible para adaptarse a nuevos requerimientos del negocio. Las interfaces son accedidas por programas individuales de cada aplicación. Algunas interfaces ya cuentan con servicios reutilizables. El 80/20 de las interfaces críticas ya utilizan servicios reutilizables. Las aplicaciones críticas ya utilizan servicios reutilizables. Las interfaces son explotadas a través de servicios reutilizables. No existe información de control en las interfaces. Algunas interfaces ya cuentan con controles. El 80/20 de las interfaces críticas ya se encuentran con controles. Las principales interfaces están desarrolladas con controles automáticos. Todas las interfaces contienen autocontroles. No hay documentación disponible de soporte o desarrollo. Documentación para acciones comunes (p.e. manual de mantenimiento de datos) esta disponible y en uso. La mayoría de la documentación de soporte y desarrollo esta disponible pero es difícil de encontrar e interpretar. La mayoría de la documentación de soporte y desarrollo esta disponible pero es desactualizada. La interfaz esta documentada completamente para soporte y mantenimiento. Hay una referencia rápida disponible. Cada nuevo requerimiento necesita modificar al menos una interfaz. Algunas interfaces ya están desarrolladas de forma "ancha“. Todavía hay interfaces que deben ser modificadas para satisfacer las necesidades del negocio de manera adecuada. Los requerimientos actuales están asegurados, no así posibles necesidades futuras. Los requerimientos de negocio están asegurados. A Redundancia B Explotación (acceso) C Automatización de controles D Documentación E Estructura Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 77

Particularidad No se utiliza ninguna herramienta de integración (middleware) para poder realizar un mayor control sobre el intercambio de información. Descripción de la Recomendación Integración de las aplicaciones por medio de un bus de integración. Dicho bus es el único punto de contacto con las aplicaciones. Implementación de un esquema de gobierno de la arquitectura de integración, con roles y procesos específicos para el diseño de interfaces y servicios. Ajuste de interfaces para su integración con el bus de integración. Beneficios Mediante la implementación de una herramienta de integración, se simplifica la integración entre las aplicaciones, permitiendo también abstraer la lógica de transformación de las aplicaciones y centralizarla en un único repositorio. La implementación de un esquema de gobierno orientado a la integración de aplicaciones permite gobernar de manera ordenada y eficiente la comunicación entre las distintas aplicaciones que conforman la arquitectura y las reglas de negocio que permiten el intercambio de información entre las mismas. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 78 78 78 78 78 78

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO El sistema solo puede ser modificado incurriendo en un costo elevado en tiempo y recursos. El sistema puede ser modificado, en corto tiempo o con esfuerzo razonable. El sistema es flexible pero tiene algunas limitaciones de crecimiento para alcanzar requerimientos futuros. Las variaciones de negocio requieren modificación de código fuente. El sistema es flexible y generalmente una modificación en la lógica de negocio no requiere de modificación de código fuente. Requerimientos funcionales futuros e interfases ya están disponibles. Mediante la implementación de una herramienta de reporting, se logra mejorar la calidad de los reportes del sistema. No hay Instrucciones, no hay una validación automatizada. Muchos pasos desunidos por actividad. Controles excesivos o demasiados abiertos Todas las entradas al sistema son vía teclado (no hay escaneo o pantallas pre-completadas). Jerarquía de procesos rígidas. No hay facilidad para corrección de errores Existen algunas instrucciones de control. La validación en el ingreso de información esta parcialmente automatizada. Las actividades siguen un flujo lógico. Algunas capturas de datos están automatizadas. Fácil corrección de errores. Procesos altamente automatizados. Flujos de procesos flexibles se acomodan a las necesidades del negocio. Validación automatizada. Poca información necesaria para los procesos del negocio es entregada al ser solicitada. Se generan muchos reportes Ad-hoc y/o son necesarios muchos "queries" para generar información. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar la mayoría de las solicitudes. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar a ciertas solicitudes. Se puede entregar la información necesaria para los procesos del negocio. El sistema cuenta con un generador de reportes que permite solucionar la falta de información. Toda la información es entregada al ser solicitada sin necesidad de generar reportes Ad-Hoc o "queries" en el proceso. El aplicativo soporta parcialmente los requerimientos del negocio. Requiere de ajustes para que lo haga de forma adecuada. El aplicativo soporta parcialmente los requerimientos de negocio, pero los soporta de forma adecuada. El aplicativo soporta ciertos requerimientos de negocio, pero no soporta la totalidad de los prioritarios . La aplicación soporta los requerimientos prioritarios de negocio. La aplicación soporta en su totalidad los requerimientos del negocio. A Flexibilidad para añadir nuevas Funcionalidad B Facilidad de Uso C Automatización de la Información D Funcionalidad para el actual negocio Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 80 80

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO Hay muchas funcionalidades que no tienen uso y hace al sistema muy engorroso. Hay algunas funcionalidades que no tienen uso y dificultan en cierto grado el uso del sistema Existen algunas funcionalidades no utilizadas, alguna de las cuales dificultan el uso del sistema Existen algunas funcionalidades no utilizadas, pero no dificultan el uso del sistema. El sistema es utilizado en forma completa. La reimplementación del módulo de Cash management permitirá aumentar las capacidades de uso actuales del sistema, automatizando procesos que actualmente se deben hacer en forma manual por la mala implementación de dicho módulo. La realización de un data cleansing en las bases de datos mejorará de manera significativa la calidad de los datos. La información es poco confiable y requiere de controles adicionales. Hay información que es confiable, pero no es toda y aun se depende de controles adicionales sobre información crítica. La información crítica esta asegurada . Hay cierta información que requiere controles adicionales, pero no es crítica. No hay duda en la precisión y certeza de la información . El sistema un poco o nada confiable, sufre de caídas y/o errores en una frecuencia que impide el normal desarrollo de actividades. La frecuencia de caídas / errores provoca acciones manuales simples que resuelven el problema. Hay caídas / errores que dependiendo del momento en que se produzcan entorpecen el negocio. Hay aun algunas caídas del sistema pero son esporádicas y no afectan el negocio. El sistema es totalmente confiable. El acceso es muy dificultoso y/o los equipos disponibles son inadecuados provocando poca disponibilidad del sistema. La accesibilidad y/o los equipos dificultan el normal desenvolvimiento, pero se dispone adecuadamente del sistema. Los accesos son relativamente aceptables y la utilización del sistema se ve afectada ocasionalmente. Existen algunas dificultades de acceso, pero no son críticas. El acceso y los equipos son adecuados y no causan problemas . E Uso de Capacidades F Calidad de Información G Confiabilidad del Sistema H Accesibilidad Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 81 81

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones El sistema es cerrado, imposible añadir interfaces. Permite la extracción de archivos "batch" con programación superior a tres días, pero no permite interfaces en línea. Permite la extracción de archivos "batch" con programación inferior a tres días, pero no permite interfaces en línea. Se pueden crear interfaces "on-line" y "batch" pero requieren de una programación inferior a tres días. Arquitectura abierta, interfases API o EAI disponibles y bien soportadas para todos los datos y funciones. Los tiempos de respuesta son mucho mas lentos que los requeridos . Los tiempos de respuesta exceden por poco los niveles aceptables. Los tiempos de respuesta exceden por poco los niveles aceptables, pero en horarios no críticos. Los tiempos de respuesta son aceptables. Los tiempos de respuesta están por debajo de los requeridos, la información está disponible cuando se necesita. Tiempos off-line o problemas batch frecuentes y significativos que sobrepasan lo aceptable por el negocio. Tiempos off-line o problemas batch ocasionales que sobrepasan los aceptable por el negocio. Ocurren cortes no planeados, pero que no ocasionan un impacto en el negocio. En la mayoría de los casos alcanza los requerimientos de disponibilidad, con sistemas/planes de contingencia. 100% de disponibilidad. Es necesario un esfuerzo significativo de desarrollo (construcción y pruebas unitarias) para el mantenimiento. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo, sin embargo la carga de trabajo hace que el mismo no este siempre disponible. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo. El esfuerzo de mantenimiento es bajo, pero se necesita de habilidades especiales para su desarrollo. El mantenimiento es directo y las habilidades necesarias están completamente disponibles en el mercado. A Facilidad de Integración B Tiempo de Respuesta C Disponibilidad del Sistema D Esfuerzo para Cambios Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 82 82

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones No hay monitoreo proactivo del sistema. Las fallas son reconocidas debido a eventos en cascada. El monitoreo proactivo del sistema es mínimo, hay un ejercicio manual significativo para localizar fallas. Los puntos de falla claves son monitoreados y acciones manuales resuelven las mayoría de las situaciones de falla. La mayoría del sistema es monitoreado con algún soporte automatizado de falla/evento. El sistema es completamente monitoreado en busca de fallas o eventos y son programadas respuestas automatizadas para fallas comunes. La aplicación es dependiente de versiones de HW/SO especializado que requieren a su vez de habilidades especiales para mantenerlos. La aplicación no depende del HW, pero sí de versiones de SO. La aplicación es altamente dependiente de los estándares de HW/SW de la industria. La aplicación es dependiente de ciertos estándares fácilmente salvables. La aplicación es independiente de la configuración de HW/SW. El sistema esta sobrecargado sin espacio para incrementar su capacidad . El sistema no es escalable, pero las proyecciones actuales no exceden la capacidad actual. El sistema es escalable en el corto plazo en una dimensión (p.e. añadiendo o mejorando el HW). El sistema tiene suficiente escalabilidad para cumplir con las necesidades futuras con una inversión de capital mínima. La aplicación falla al encontrarse con información faltante o en formato incorrecto y finaliza la sesión del usuario. La aplicación falla al encontrase con información faltante o en formato incorrecto, no muestra mensaje alguno al usuario e interrumpe el flujo de trabajo pero sin finalización de sesión. La aplicación falla al encontrase con información faltante o en formato incorrecto, muestra al usuario un mensaje inapropiado e interrumpe el flujo de trabajo. La aplicación no falla al encontrase con información faltante o en formato incorrecto. Muestra al usuario un mensaje advirtiendo de la imposibilidad de completar la operación y permite que el mismo continúe trabajando. Al encontrarse con información faltante o en formato incorrecto, la aplicación intenta corregirla y muestra al usuario un mensaje para que este la valide o vuelva a ingresarla y así pueda continuar con la operación en curso. E Control y Monitoreo F Dependencia de HW y SW G Escalabilidad H Robustez Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 83 83

Frente Arquitectura Aplicativa Sistema tel
Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Funcionales Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO El sistema solo puede ser modificado incurriendo en un costo elevado en tiempo y recursos. El sistema puede ser modificado, en corto tiempo o con esfuerzo razonable. El sistema es flexible pero tiene algunas limitaciones de crecimiento para alcanzar requerimientos futuros. Las variaciones de negocio requieren modificación de código fuente. El sistema es flexible y generalmente una modificación en la lógica de negocio no requiere de modificación de código fuente. Requerimientos funcionales futuros e interfases ya están disponibles. La implementación de un sistema de telefonía y un valorizador acordes a las necesidades del negocio, permiten mejorar sustancialmente todos los aspectos funcionales y técnicos del sistema. Mediante la implementación de una herramienta de reporting, se logra mejorar la calidad de los reportes del sistema. No hay Instrucciones, no hay una validación automatizada. Muchos pasos desunidos por actividad. Controles excesivos o demasiados abiertos Todas las entradas al sistema son vía teclado (no hay escaneo o pantallas pre-completadas). Jerarquía de procesos rígidas. No hay facilidad para corrección de errores Existen algunas instrucciones de control. La validación en el ingreso de información esta parcialmente automatizada. Las actividades siguen un flujo lógico. Algunas capturas de datos están automatizadas. Fácil corrección de errores. Procesos altamente automatizados. Flujos de procesos flexibles se acomodan a las necesidades del negocio. Validación automatizada. Poca información necesaria para los procesos del negocio es entregada al ser solicitada. Se generan muchos reportes Ad-hoc y/o son necesarios muchos "queries" para generar información. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar la mayoría de las solicitudes. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar a ciertas solicitudes. Se puede entregar la información necesaria para los procesos del negocio. El sistema cuenta con un generador de reportes que permite solucionar la falta de información. Toda la información es entregada al ser solicitada sin necesidad de generar reportes Ad-Hoc o "queries" en el proceso. El aplicativo soporta parcialmente los requerimientos del negocio. Requiere de ajustes para que lo haga de forma adecuada. El aplicativo soporta parcialmente los requerimientos de negocio, pero los soporte de forma adecuada. El aplicativo soporta ciertos requerimientos de negocio, pero no soporta la totalidad de los prioritarios . La aplicación soporta los requerimientos prioritarios de negocio. La aplicación soporta en su totalidad los requerimientos del negocio. A Flexibilidad para añadir nuevas Funcionalidad B Facilidad de Uso C Automatización de la Información D Funcionalidad para el actual negocio Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 84 84

Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Funcionales Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO Hay muchas funcionalidades que no tienen uso y hace al sistema muy engorroso. Hay algunas funcionalidades que no tienen uso y dificultan en cierto grado el uso del sistema Existen algunas funcionalidades no utilizadas, alguna de las cuales dificultan el uso del sistema Existen algunas funcionalidades no utilizadas, pero no dificultan el uso del sistema. El sistema es utilizado en forma completa. La implementación de un sistema de telefonía y un valorizador acordes a las necesidades del negocio, permiten mejorar sustancialmente todos los aspectos funcionales y técnicos del sistema. La realización de un data cleansing en las bases de datos mejorará de manera significativa la calidad de los datos. La información es poco confiable y requiere de controles adicionales. Hay información que es confiable, pero no es toda y aun se depende de controles adicionales sobre información crítica. La información crítica esta asegurada . Hay cierta información que requiere controles adicionales, pero no es crítica. No hay duda en la precisión y certeza de la información . El sistema un poco o nada confiable, sufre de caídas y/o errores en una frecuencia que impide el normal desarrollo de actividades. La frecuencia de caídas / errores provoca acciones manuales simples que resuelven el problema. Hay caídas / errores que dependiendo del momento en que se produzcan entorpecen el negocio. Hay aun algunas caídas del sistema pero son esporádicas y no afectan el negocio. El sistema es totalmente confiable. El acceso es muy dificultoso y/o los equipos disponibles son inadecuados provocando poca disponibilidad del sistema. La accesibilidad y/o los equipos dificultan el normal desenvolvimiento, pero se dispone adecuadamente del sistema. Los accesos son relativamente aceptables y la utilización del sistema se ve afectada ocasionalmente. Existen algunas dificultades de acceso, pero no son críticas. El acceso y los equipos son adecuados y no causan problemas . E Uso de Capacidades F Calidad de Información G Confiabilidad del Sistema H Accesibilidad Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 85 85

Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Técnicos Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones El sistema es cerrado, imposible añadir interfaces. Permite la extracción de archivos "batch" con programación superior a tres días, pero no permite interfaces en línea. Permite la extracción de archivos "batch" con programación inferior a tres días, pero no permite interfaces en línea. Se pueden crear interfaces "on-line" y "batch" pero requieren de una programación inferior a tres días. Arquitectura abierta, interfases API o EAI disponibles y bien soportadas para todos los datos y funciones. La implementación de un sistema de telefonía y un valorizador acordes a las necesidades del negocio, permiten mejorar sustancialmente todos los aspectos funcionales y técnicos del sistema. Los tiempos de respuesta son mucho mas lentos que los requeridos . Los tiempos de respuesta exceden por poco los niveles aceptables. Los tiempos de respuesta exceden por poco los niveles aceptables, pero en horarios no críticos. Los tiempos de respuesta son aceptables. Los tiempos de respuesta están por debajo de los requeridos, la información está disponible cuando se necesita. Tiempos off-line o problemas batch frecuentes y significativos que sobrepasan lo aceptable por el negocio. Tiempos off-line o problemas batch ocasionales que sobrepasan los aceptable por el negocio. Ocurren cortes no planeados, pero que no ocasionan un impacto en el negocio. En la mayoría de los casos alcanza los requerimientos de disponibilidad, con sistemas/planes de contingencia. 100% de disponibilidad. Es necesario un esfuerzo significativo de desarrollo (construcción y pruebas unitarias) para el mantenimiento. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo, sin embargo la carga de trabajo hace que el mismo no este siempre disponible. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo. El esfuerzo de mantenimiento es bajo, pero se necesita de habilidades especiales para su desarrollo. El mantenimiento es directo y las habilidades necesarias están completamente disponibles en el mercado. A Facilidad de Integración B Tiempo de Respuesta C Disponibilidad del Sistema D Esfuerzo para Cambios Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 86 86

Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Técnicos Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones No hay monitoreo proactivo del sistema. Las fallas son reconocidas debido a eventos en cascada. El monitoreo proactivo del sistema es mínimo, hay un ejercicio manual significativo para localizar fallas. Los puntos de falla claves son monitoreados y acciones manuales resuelven las mayoría de las situaciones de falla. La mayoría del sistema es monitoreado con algún soporte automatizado de falla/evento. El sistema es completamente monitoreado en busca de fallas o eventos y son programadas respuestas automatizadas para fallas comunes. La implementación de un sistema de telefonía y un valorizador acordes a las necesidades del negocio, permiten mejorar sustancialmente todos los aspectos funcionales y técnicos del sistema. La aplicación es dependiente de versiones de HW/SO especializado que requieren a su vez de habilidades especiales para mantenerlos. La aplicación no depende del HW, pero sí de versiones de SO. La aplicación es altamente dependiente de los estándares de HW/SW de la industria. La aplicación es dependiente de ciertos estándares fácilmente salvables. La aplicación es independiente de la configuración de HW/SW. El sistema esta sobrecargado sin espacio para incrementar su capacidad . El sistema no es escalable, pero las proyecciones actuales no exceden la capacidad actual. El sistema es escalable en el corto plazo en una dimensión (p.e. añadiendo o mejorando el HW). El sistema tiene suficiente escalabilidad para cumplir con las necesidades futuras con una inversión de capital mínima. La aplicación falla al encontrarse con información faltante o en formato incorrecto y finaliza la sesión del usuario. La aplicación falla al encontrase con información faltante o en formato incorrecto, no muestra mensaje alguno al usuario e interrumpe el flujo de trabajo pero sin finalización de sesión. La aplicación falla al encontrase con información faltante o en formato incorrecto, muestra al usuario un mensaje inapropiado e interrumpe el flujo de trabajo. La aplicación no falla al encontrase con información faltante o en formato incorrecto. Muestra al usuario un mensaje advirtiendo de la imposibilidad de completar la operación y permite que el mismo continúe trabajando. Al encontrarse con información faltante o en formato incorrecto, la aplicación intenta corregirla y muestra al usuario un mensaje para que este la valide o vuelva a ingresarla y así pueda continuar con la operación en curso. E Control y Monitoreo F Dependencia de HW y SW G Escalabilidad H Robustez Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 87 87

Frente Arquitectura Aplicativa Intraway – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO El sistema solo puede ser modificado incurriendo en un costo elevado en tiempo y recursos. El sistema puede ser modificado, en corto tiempo o con esfuerzo razonable. El sistema es flexible pero tiene algunas limitaciones de crecimiento para alcanzar requerimientos futuros. Las variaciones de negocio requieren modificación de código fuente. El sistema es flexible y generalmente una modificación en la lógica de negocio no requiere de modificación de código fuente. Requerimientos funcionales futuros e interfases ya están disponibles. No hay Instrucciones, no hay una validación automatizada. Muchos pasos desunidos por actividad. Controles excesivos o demasiados abiertos Todas las entradas al sistema son vía teclado (no hay escaneo o pantallas pre-completadas). Jerarquía de procesos rígidas. No hay facilidad para corrección de errores Existen algunas instrucciones de control. La validación en el ingreso de información esta parcialmente automatizada. Las actividades siguen un flujo lógico. Algunas capturas de datos están automatizadas. Fácil corrección de errores. Procesos altamente automatizados. Flujos de procesos flexibles se acomodan a las necesidades del negocio. Validación automatizada. Poca información necesaria para los procesos del negocio es entregada al ser solicitada. Se generan muchos reportes Ad-hoc y/o son necesarios muchos "queries" para generar información. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar la mayoría de las solicitudes. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar a ciertas solicitudes. Se puede entregar la información necesaria para los procesos del negocio. El sistema cuenta con un generador de reportes que permite solucionar la falta de información. Toda la información es entregada al ser solicitada sin necesidad de generar reportes Ad-Hoc o "queries" en el proceso. El aplicativo soporta parcialmente los requerimientos del negocio. Requiere de ajustes para que lo haga de forma adecuada. El aplicativo soporta parcialmente los requerimientos de negocio, pero los soporte de forma adecuada. El aplicativo soporta ciertos requerimientos de negocio, pero no soporta la totalidad de los prioritarios . La aplicación soporta los requerimientos prioritarios de negocio. La aplicación soporta en su totalidad los requerimientos del negocio. A Flexibilidad para añadir nuevas Funcionalidad B Facilidad de Uso C Automatización de la Información D Funcionalidad para el actual negocio Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 88 88

Frente Arquitectura Aplicativa Intraway – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO Hay muchas funcionalidades que no tienen uso y hace al sistema muy engorroso. Hay algunas funcionalidades que no tienen uso y dificultan en cierto grado el uso del sistema Existen algunas funcionalidades no utilizadas, alguna de las cuales dificultan el uso del sistema Existen algunas funcionalidades no utilizadas, pero no dificultan el uso del sistema. El sistema es utilizado en forma completa. La realización de un data cleansing en las bases de datos mejorará de manera significativa la calidad de los datos. La información es poco confiable y requiere de controles adicionales. Hay información que es confiable, pero no es toda y aun se depende de controles adicionales sobre información crítica. La información crítica esta asegurada . Hay cierta información que requiere controles adicionales, pero no es crítica. No hay duda en la precisión y certeza de la información . El sistema un poco o nada confiable, sufre de caídas y/o errores en una frecuencia que impide el normal desarrollo de actividades. La frecuencia de caídas / errores provoca acciones manuales simples que resuelven el problema. Hay caídas / errores que dependiendo del momento en que se produzcan entorpecen el negocio. Hay aun algunas caídas del sistema pero son esporádicas y no afectan el negocio. El sistema es totalmente confiable. El acceso es muy dificultoso y/o los equipos disponibles son inadecuados provocando poca disponibilidad del sistema. La accesibilidad y/o los equipos dificultan el normal desenvolvimiento, pero se dispone adecuadamente del sistema. Los accesos son relativamente aceptables y la utilización del sistema se ve afectada ocasionalmente. Existen algunas dificultades de acceso, pero no son críticas. El acceso y los equipos son adecuados y no causan problemas . E Uso de Capacidades F Calidad de Información G Confiabilidad del Sistema H Accesibilidad Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 89 89

Frente Arquitectura Aplicativa Intraway – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones El sistema es cerrado, imposible añadir interfaces. Permite la extracción de archivos "batch" con programación superior a tres días, pero no permite interfaces en línea. Permite la extracción de archivos "batch" con programación inferior a tres días, pero no permite interfaces en línea. Se pueden crear interfaces "on-line" y "batch" pero requieren de una programación inferior a tres días. Arquitectura abierta, interfases API o EAI disponibles y bien soportadas para todos los datos y funciones. Los tiempos de respuesta son mucho mas lentos que los requeridos . Los tiempos de respuesta exceden por poco los niveles aceptables. Los tiempos de respuesta exceden por poco los niveles aceptables, pero en horarios no críticos. Los tiempos de respuesta son aceptables. Los tiempos de respuesta están por debajo de los requeridos, la información está disponible cuando se necesita. Tiempos off-line o problemas batch frecuentes y significativos que sobrepasan lo aceptable por el negocio. Tiempos off-line o problemas batch ocasionales que sobrepasan los aceptable por el negocio. Ocurren cortes no planeados, pero que no ocasionan un impacto en el negocio. En la mayoría de los casos alcanza los requerimientos de disponibilidad, con sistemas/planes de contingencia. 100% de disponibilidad. Es necesario un esfuerzo significativo de desarrollo (construcción y pruebas unitarias) para el mantenimiento. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo, sin embargo la carga de trabajo hace que el mismo no este siempre disponible. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo. El esfuerzo de mantenimiento es bajo, pero se necesita de habilidades especiales para su desarrollo. El mantenimiento es directo y las habilidades necesarias están completamente disponibles en el mercado. A Facilidad de Integración B Tiempo de Respuesta C Disponibilidad del Sistema D Esfuerzo para Cambios Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 90 90

Frente Arquitectura Aplicativa Intraway – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones No hay monitoreo proactivo del sistema. Las fallas son reconocidas debido a eventos en cascada. El monitoreo proactivo del sistema es mínimo, hay un ejercicio manual significativo para localizar fallas. Los puntos de falla claves son monitoreados y acciones manuales resuelven las mayoría de las situaciones de falla. La mayoría del sistema es monitoreado con algún soporte automatizado de falla/evento. El sistema es completamente monitoreado en busca de fallas o eventos y son programadas respuestas automatizadas para fallas comunes. La aplicación es dependiente de versiones de HW/SO especializado que requieren a su vez de habilidades especiales para mantenerlos. La aplicación no depende del HW, pero sí de versiones de SO. La aplicación es altamente dependiente de los estándares de HW/SW de la industria. La aplicación es dependiente de ciertos estándares fácilmente salvables. La aplicación es independiente de la configuración de HW/SW. El sistema esta sobrecargado sin espacio para incrementar su capacidad . El sistema no es escalable, pero las proyecciones actuales no exceden la capacidad actual. El sistema es escalable en el corto plazo en una dimensión (p.e. añadiendo o mejorando el HW). El sistema tiene suficiente escalabilidad para cumplir con las necesidades futuras con una inversión de capital mínima. La aplicación falla al encontrarse con información faltante o en formato incorrecto y finaliza la sesión del usuario. La aplicación falla al encontrase con información faltante o en formato incorrecto, no muestra mensaje alguno al usuario e interrumpe el flujo de trabajo pero sin finalización de sesión. La aplicación falla al encontrase con información faltante o en formato incorrecto, muestra al usuario un mensaje inapropiado e interrumpe el flujo de trabajo. La aplicación no falla al encontrase con información faltante o en formato incorrecto. Muestra al usuario un mensaje advirtiendo de la imposibilidad de completar la operación y permite que el mismo continúe trabajando. Al encontrarse con información faltante o en formato incorrecto, la aplicación intenta corregirla y muestra al usuario un mensaje para que este la valide o vuelva a ingresarla y así pueda continuar con la operación en curso. E Control y Monitoreo F Dependencia de HW y SW G Escalabilidad H Robustez Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 91 91

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO El sistema solo puede ser modificado incurriendo en un costo elevado en tiempo y recursos. El sistema puede ser modificado, en corto tiempo o con esfuerzo razonable. El sistema es flexible pero tiene algunas limitaciones de crecimiento para alcanzar requerimientos futuros. Las variaciones de negocio requieren modificación de código fuente. El sistema es flexible y generalmente una modificación en la lógica de negocio no requiere de modificación de código fuente. Requerimientos funcionales futuros e interfaces ya están disponibles. Las principales aplicaciones evaluadas en este matriz son el sistema FOX, CARENA y DAC 6000. No hay Instrucciones, no hay una validación automatizada. Muchos pasos desunidos por actividad. Controles excesivos o demasiados abiertos Todas las entradas al sistema son vía teclado (no hay escaneo o pantallas pre-completadas). Jerarquía de procesos rígidas. No hay facilidad para corrección de errores Existen algunas instrucciones de control. La validación en el ingreso de información esta parcialmente automatizada. Las actividades siguen un flujo lógico. Algunas capturas de datos están automatizadas. Fácil corrección de errores. Procesos altamente automatizados. Flujos de procesos flexibles se acomodan a las necesidades del negocio. Validación automatizada. Poca información necesaria para los procesos del negocio es entregada al ser solicitada. Se generan muchos reportes Ad-hoc y/o son necesarios muchos "queries" para generar información. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar la mayoría de las solicitudes. Se puede entregar la información necesaria para los procesos del negocio, sin embargo se necesitan generar reportes Ad-hoc y/o "queries" para entregar a ciertas solicitudes. Se puede entregar la información necesaria para los procesos del negocio. El sistema cuenta con un generador de reportes que permite solucionar la falta de información. Toda la información es entregada al ser solicitada sin necesidad de generar reportes Ad-Hoc o "queries" en el proceso. El aplicativo soporta parcialmente los requerimientos del negocio. Requiere de ajustes para que lo haga de forma adecuada. El aplicativo soporta parcialmente los requerimientos de negocio, pero los soporte de forma adecuada. El aplicativo soporta ciertos requerimientos de negocio, pero no soporta la totalidad de los prioritarios . La aplicación soporta los requerimientos prioritarios de negocio. La aplicación soporta en su totalidad los requerimientos del negocio. A Flexibilidad para añadir nuevas Funcionalidad B Facilidad de Uso C Automatización de la Información D Funcionalidad para el actual negocio Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 92 92

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Funcionales
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones COMENTARIO Hay muchas funcionalidades que no tienen uso y hace al sistema muy engorroso. Hay algunas funcionalidades que no tienen uso y dificultan en cierto grado el uso del sistema Existen algunas funcionalidades no utilizadas, alguna de las cuales dificultan el uso del sistema Existen algunas funcionalidades no utilizadas, pero no dificultan el uso del sistema. El sistema es utilizado en forma completa. Las principales aplicaciones evaluadas en este matriz son el sistema FOX, CARENA y DAC 6000. La realización de un data cleansing en las bases de datos mejorará de manera significativa la calidad de los datos. La información es poco confiable y requiere de controles adicionales. Hay información que es confiable, pero no es toda y aun se depende de controles adicionales sobre información crítica. La información crítica esta asegurada . Hay cierta información que requiere controles adicionales, pero no es crítica. No hay duda en la precisión y certeza de la información . El sistema un poco o nada confiable, sufre de caídas y/o errores en una frecuencia que impide el normal desarrollo de actividades. La frecuencia de caídas / errores provoca acciones manuales simples que resuelven el problema. Hay caídas / errores que dependiendo del momento en que se produzcan entorpecen el negocio. Hay aun algunas caídas del sistema pero son esporádicas y no afectan el negocio. El sistema es totalmente confiable. El acceso es muy dificultoso y/o los equipos disponibles son inadecuados provocando poca disponibilidad del sistema. La accesibilidad y/o los equipos dificultan el normal desenvolvimiento, pero se dispone adecuadamente del sistema. Los accesos son relativamente aceptables y la utilización del sistema se ve afectada ocasionalmente. Existen algunas dificultades de acceso, pero no son críticas. El acceso y los equipos son adecuados y no causan problemas . E Uso de Capacidades F Calidad de Información G Confiabilidad del Sistema H Accesibilidad Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 93 93

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones El sistema es cerrado, imposible añadir interfaces. Permite la extracción de archivos "batch" con programación superior a tres días, pero no permite interfaces en línea. Permite la extracción de archivos "batch" con programación inferior a tres días, pero no permite interfaces en línea. Se pueden crear interfaces "on-line" y "batch" pero requieren de una programación inferior a tres días. Arquitectura abierta, interfases API o EAI disponibles y bien soportadas para todos los datos y funciones. Las principales aplicaciones evaluadas en este matriz son el sistema FOX, CARENA y DAC 6000. Los tiempos de respuesta son mucho mas lentos que los requeridos . Los tiempos de respuesta exceden por poco los niveles aceptables. Los tiempos de respuesta exceden por poco los niveles aceptables, pero en horarios no críticos. Los tiempos de respuesta son aceptables. Los tiempos de respuesta están por debajo de los requeridos, la información está disponible cuando se necesita. Tiempos off-line o problemas batch frecuentes y significativos que sobrepasan lo aceptable por el negocio. Tiempos off-line o problemas batch ocasionales que sobrepasan los aceptable por el negocio. Ocurren cortes no planeados, pero que no ocasionan un impacto en el negocio. En la mayoría de los casos alcanza los requerimientos de disponibilidad, con sistemas/planes de contingencia. 100% de disponibilidad. Es necesario un esfuerzo significativo de desarrollo (construcción y pruebas unitarias) para el mantenimiento. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo, sin embargo la carga de trabajo hace que el mismo no este siempre disponible. El esfuerzo de mantenimiento es alto pero se tiene suficiente personal con el conocimiento necesario para cubrirlo. El esfuerzo de mantenimiento es bajo, pero se necesita de habilidades especiales para su desarrollo. El mantenimiento es directo y las habilidades necesarias están completamente disponibles en el mercado. A Facilidad de Integración B Tiempo de Respuesta C Disponibilidad del Sistema D Esfuerzo para Cambios Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 94 94

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Técnicos
Nivel I Inicial Nivel II Regular Nivel III Bueno Nivel IV Muy Bueno Nivel V Excelente Observaciones No hay monitoreo proactivo del sistema. Las fallas son reconocidas debido a eventos en cascada. El monitoreo proactivo del sistema es mínimo, hay un ejercicio manual significativo para localizar fallas. Los puntos de falla claves son monitoreados y acciones manuales resuelven las mayoría de las situaciones de falla. La mayoría del sistema es monitoreado con algún soporte automatizado de falla/evento. El sistema es completamente monitoreado en busca de fallas o eventos y son programadas respuestas automatizadas para fallas comunes. Las principales aplicaciones evaluadas en este matriz son el sistema FOX, CARENA y DAC 6000. La aplicación es dependiente de versiones de HW/SO especializado que requieren a su vez de habilidades especiales para mantenerlos. La aplicación no depende del HW, pero sí de versiones de SO. La aplicación es altamente dependiente de los estándares de HW/SW de la industria. La aplicación es dependiente de ciertos estándares fácilmente salvables. La aplicación es independiente de la configuración de HW/SW. El sistema esta sobrecargado sin espacio para incrementar su capacidad . El sistema no es escalable, pero las proyecciones actuales no exceden la capacidad actual. El sistema es escalable en el corto plazo en una dimensión (p.e. añadiendo o mejorando el HW). El sistema tiene suficiente escalabilidad para cumplir con las necesidades futuras con una inversión de capital mínima. La aplicación falla al encontrarse con información faltante o en formato incorrecto y finaliza la sesión del usuario. La aplicación falla al encontrase con información faltante o en formato incorrecto, no muestra mensaje alguno al usuario e interrumpe el flujo de trabajo pero sin finalización de sesión. La aplicación falla al encontrase con información faltante o en formato incorrecto, muestra al usuario un mensaje inapropiado e interrumpe el flujo de trabajo. La aplicación no falla al encontrase con información faltante o en formato incorrecto. Muestra al usuario un mensaje advirtiendo de la imposibilidad de completar la operación y permite que el mismo continúe trabajando. Al encontrarse con información faltante o en formato incorrecto, la aplicación intenta corregirla y muestra al usuario un mensaje para que este la valide o vuelva a ingresarla y así pueda continuar con la operación en curso. E Control y Monitoreo F Dependencia de HW y SW G Escalabilidad H Robustez Nivel de Madurez Objetivo (mediano plazo) Nivel de Madurez Objetivo (largo plazo) Nivel de Madurez Actual 95 95

Particularidad El sistema Comarch está pensado como prepago y utilizado como post-pago. Descripción de la Recomendación Implementación de un sistema de telefonía post pago Implementación de un sistema de valorización de los CDRs, independiente del sistema de telefonía. Desarrollo de las interfaces entre el CRM y estos sistemas con Web Services lo que facilitará la implementación del bus de comunicación en el largo Plazo. Beneficios Contar con un sistema de telefonía acorde a las necesidades del negocio. Independizar el proceso de valorización de las llamadas del sistema de telefonía. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Ninguno Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 96 96 96 96 96 96

Particularidad El módulo Cash Management del sistema Oracle Financials no se implementó según los especificado, lo que genera que se tengan que realizar actividades por fuera del sistema de manera manual. Descripción de la Recomendación Relevar las necesidades actuales del negocio en relación a Cash Management y ajustar la implementación actual (parametrización y desarrollo) del módulo para que cumpla con dichos requerimientos. Beneficios Contar con el módulo de Cash Management implementado de acuerdo a las necesidades actuales del negocio. Evitar la realización de tareas manuales que pueden ser absorbidas por dicho módulo. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Ninguno Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 97 97 97 97 97 97

Particularidad En la mayoría de los sistemas se detectaron carencias de capacidades de reporting para las diferentes plataformas que se comunican con el CRM Triple Play. Descripción de la Recomendación Implementar una herramienta de reporting que permita levantar los datos de sistemas externos y realizar distintos reportes (dinámicos y estáticos) utilizando diversas fuentes. Implementación del rol de reporting, incluyendo el relevamiento de las necesidades de reporting del negocio, el diseño y la implementación de los mismos. Desarrollo de una interface con el CRM con Web Services lo que facilitará la implementación del bus de comunicación en el largo Plazo. Para el CRM : el uso del componente ReportViewer, incluido en Visual Studio puede ayudar a que los reportes se hagan más rápido y fácilmente. Beneficios La implementación de un sistema de reporting central permitirá brindar herramientas de análisis certeras para el negocio, lo cuál le permitirá tomar decisiones comerciales. La implementación de los reportes más prioritarios facilitará el trabajo cotidiano de los usuarios. El uso del mencionado componente facilitará la creación de los reportes. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Implementar el área de Reporting (ORGXXX). Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia Herramientas Open Source: , 98 98 98 98 98 98

Demanda de Información
INIT Frente Arquitectura Aplicativa DW - Introducción Demanda de Información Las presiones que ejercen el mercado y los clientes, el directorio y las gerencias, los accionistas y los entes reguladores, exigen y conducen a las entidades hacia a la mejora en el acceso a la información. Ante esta situación, la disponibilidad y la oportunidad de la información siguen siendo un problema presente en la agenda de la alta dirección. Realizar inversiones en Business Intelligence favorece a los bancos a entender el negocio, llegar al mercado y enfrentar la competencia. También mejora el conocimiento de los clientes y sus preferencias, permitiendo la segmentación que habilita el camino al desarrollo de campañas “1 a 1”. Mediante la aplicación de tecnología los datos se transforman en información. Pero la información se transforma en real inteligencia, cuando la misma es utilizada para soportar la estrategia y los negocios de la entidad. Mayor entendimiento del negocio 99

Definiciones generales
Frente Arquitectura Aplicativa DW - Definición Business Intelligence (BI): es un conjunto de aplicaciones y tecnologías utilizadas para obtener, almacenar, analizar y dar acceso a información utilizada para toma de decisiones del negocio. Data Warehouse (DW): es una imagen (snapshot) de los datos extraídos de fuentes operativas que luego son integrados, depurados y cargados en un formato que facilite la toma de decisiones estratégicas. Enterprise Data Warehouse (EDW): integra información de fuentes de datos múltiples y heterogéneas para que puedan ser accedidas con un conjunto de herramientas comunes. Atomic Level Data: se refiere al nivel más bajo de información almacenado en el DW. Esta información está estructurada para cumplir con los requerimientos de información de la empresa. Operational Data Store (ODS): es un conjunto de datos operativos utilizados para realizar análisis de la empresa y toma de decisiones. Son mínimos los datos históricos. Data Marts: son subconjuntos del EDW. Son alimentados directamente del EDW que aseguran la sincronización de las reglas de negocio y los snapshots. Las estructuras de los data marts son definidas por requerimientos particulares de usuarios de negocio. On Line Analytical Processing (OLAP): brinda información multidimensional y sumarizada para realizar reportes, análisis, modelado y planeación para optimizar el negocio. Definiciones generales

Frente Arquitectura Aplicativa DW - Componentes
Arquitectura técnica de BI Fuente de Datos Servicios de Integración Almacenamiento de Datos Servicios Analíticos Servicios de Delivery Extracción Reportes de Producción Empresa Transforma-ción Reportes de usuario final Web Browser Desestructu- rada Carga Datos Operativos Data Mining Portal Informacional Sincroniza-ción Tableros de Comando Dispositivos Externa Transporte / Mensaje Data Marts Análisis Embebido Web Services Mantenimien-to de Integridad OLAP Flujo de Datos

Servicios de Integración Almacenamiento de Datos
Frente Arquitectura Aplicativa DW – Componentes (Cont.) Arquitectura técnica del BI Fuentes de Datos Son los sistemas que proveen la información al BI. Servicios de Integración Son las tecnologías que permiten el flujo de datos entre los distintos sistemas. Almacenamiento de Datos Se refiere a los sistemas que consolidan y guardan la información que será utilizada para análisis. Servicios Analíticos Soluciones que analizan los datos a extraer para construir la información y reportes del BI para los usuarios. Servicios de Delivery Son los sistemas que permiten a los usuarios acceder a la información y reportes del BI.

Frente Arquitectura Aplicativa DW – Factores de Éxito
Factores Críticos de Éxito Alineamiento del negocio y enfoque hacia los beneficios Se debe basar en el valor que se da al negocio a través de brindar información en tiempo y forma para la toma de decisiones. La estrategia debe estar orientada al negocio y no a la tecnología. Experiencia en BI y DW Trabajar con un conjunto de metodologías, enfoques y herramientas específicas de BI permitirá hacer una mejor implementación de forma más rápida y menos costosa. Efectividad de la Gobernabilidad y el Manejo del Cambio Esto se logra ayudando a comprender al negocio sobre los beneficios brindados por esta nueva capacidad de análisis y ayudando a la Dirección de Sistemas a establecer la organización y gobernabilidad para el logro de objetivos ext El equipo adecuado Un equipo experimentado en la implementación de BI, que conozca la industria de las telecomunicaciones, la empresa, su tecnología y el negocio.

Particularidad No hay un datawarehouse implementado que permita hacer análisis complejos de distintas variables de negocio. Descripción de la Recomendación Implementación un repositorio común de datos de negocio. Implementación de herramientas de inteligencia de negocio. Beneficios La implementación de un datawarehouse, acompañado de herramientas de inteligencia de negocio permitirá, no solo cubrir las necesidades de reporting actuales, sino también utilizar distintas variables que permitan analizar el comportamiento del negocio en función de distintos contextos. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 104 104 104 104 104 104

Particularidad No existe una aplicación para el manejo del conocimiento. La falta de documentación técnica, estándares de desarrollo y arquitectura entre otros, tienen un impacto directo “negativo” en la flexibilidad del sistema para adaptarse a cambios. Descripción de la Recomendación Definir la estrategia de gestión de conocimiento (incluye roles, herramientas, templates y procedimientos). Implementar un repositorio de información para la gestión del conocimiento, incluyendo la definición de la metodología de incorporación y actualización de la documentación del mismo. Beneficios Contar con una herramienta que permita desarrollar las habilidades internas y compartir experiencias que ayuden a resolver problemas recurrentes. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 105 105 105 105 105 105

Frente Arquitectura Aplicativa BPM - Introducción
BPM – Business Process Management Es la convergencia de un conjunto de tecnologías y enfoques existentes en una única plataforma que maneje el ciclo de vida de un proceso, incluyendo definición, implementación, ejecución, medición, cambio y reimplementación. Promueve la visión de la tecnología desde los procesos asociados a ella, en donde la administración de punta a punta de los procesos es separada de las aplicaciones, sus interconexiones y los datos subyacentes. Involucra la creación de una capa de procesos independiente y explícita, la cual contiene el flujo, los servicios y las reglas para reflejar las capas implícitas de aplicaciones y servicios. Promueve el tratamiento de los procesos como activos de la organización, de la misma forma que son tratados los datos y la información. Pero no… Es una tecnología para automatizar los procesos existentes; por el contrario, brinda un entorno efectivo para administrar y mejorar constantemente los procesos en sí. Representa la segunda ola de reingeniería de procesos de negocio. La principal diferencia es que existen herramientas subyacentes y tecnologías de soporte utilizadas en BPM que ayudan a descubrir el verdadero valor de la ingeniería de procesos.

¿Qué valor tiene para la organización?
Frente Arquitectura Aplicativa BPM - Valor La Administración de los Procesos del Negocio (BPM, Business Process Management) se refiere al diseño, implementación y optimización de los procesos de negocio que se ejecutan mediante una combinación de gente, secuencia de procesos e interacciones entre sistemas. ¿Qué valor tiene para la organización? Foco en el desarrollo de ventajas competitivas a través de un balance del tipo costos/servicio. Lo obtiene eliminando actividades sin agregado de valor, reduciendo los ciclos de proceso y minimizando los costos asociados a la ejecución de procesos de negocio. Eficiencia de los procesos y efectividad en el Servicio Se basa en la premisa que todos los procesos de negocio sufrirán cambios de manera permanente para acompañar la dinámica del negocio. Un componente para obtener éxito a largo plazo es brindar a la organización herramientas, métodos y capacidades que permitan monitorear, administrar y adaptarse ágilmente a los cambios de los procesos. Flexibilidad Organizacional Promueve la reducción del tiempo de colocación de productos en el mercado, maximizando la capacidad de la organización para responder a los cambios del mercado y competir efectivamente. Respuesta Ágil al Mercado Las herramientas BPM permiten manejar de manera flexible diversos métodos y canales de interacción con el cliente, y gestionar de manera integral estas interacciones. Relacionamiento con el Cliente

Frente Arquitectura Aplicativa BPM - Eficiencia Operacional
A la hora de llevar a cabo la implementación de BPM, hay un ciclo de vida que consiste en varias fases interconectadas que funcionan como ciclo cerrado que aseguran la obtención de resultados y objetivos deseados. Optimización Definición Creación Ejecución Monitoreo Definición En esta fase se documentarán las diversas tareas que deben negociarse para completar el proceso. BPM tiene la habilidad de traducir gráficos de modelado de procesos en un lenguaje estándar de definición de procesos; A su vez, también provee acceso directo a Reglas de negocio con el fin de asistir en la definición exacta de procesos existentes. Creación Aquí es donde la definición de procesos es traducida a un código ejecutable que pueda ser entendido por los sistemas de la computadora. Ejecución Se encapsula la ejecución de todo el proceso, usando una combinación de Integración, workflow, automatización y reglas de negocios. Monitoreo A través de los gráficos que representan a los procesos, se monitorea el estado de ejecución de dichos procesos. Esto permite responder rápidamente cuando se detectan cuellos de botella que limitan el rendimiento de los procesos. Ejecución Esta fase final, provee la oportunidad de realizar Simulaciones sobre los procesos existentes, a través de gráficos, reportes y análisis que permiten optimizar el objetivo de los procesos.

Particularidad Algunos procesos de negocio se encuentran distribuidos en varias aplicaciones. El sistema es flexible, pero considerando la problemática que resuelve, las buenas prácticas de mercado recomiendan el uso de motores de workflows / reglas. Descripción de la Recomendación Implementar una herramienta de BPM, incluyendo los roles necesarias para la gestión centralizada de los mismos. Relevar los procesos de negocio, analizar aquellos que se beneficien de ser implementados mediante la herramienta de BPM , diseñar los procesos para su implementación, definir los controles y las métricas a analizar, implementarlos, monitorearlos y medirlos y ajustarlos. Beneficios Contar con herramientas que permitan eficientizar los procesos de negocio, brindar mayor flexibilidad y responder de manera más ágil a las necesidades del negocio. Criticidad Impacto Complejidad Plazo Prerrequisitos Alta Alto Alto Corto Media Medio Medio Mediano Baja Bajo Bajo Largo Referencia 109 109 109 109 109 109

Frente Arquitectura Aplicativa Conclusión
La evolución hacia el mapa de aplicaciones objetivo, la puesta en práctica de los principios guía de arquitectura aplicativa, y las recomendaciones propuestas en este entregable, permitirán mejorar el nivel de madurez de las aplicaciones y obtener los siguientes beneficios: Mejora en la integración de los sistemas. Mayor flexibilidad para agregar nuevas funcionalidades. Mayor escalabilidad. Aplicaciones mas fáciles de utilizar. Automatización de interfaces. Mejora en la calidad de la información. Mayor confiabilidad del sistema. Disminución del esfuerzo ante cambios. 110 110 110 110 110

Frente Arquitectura Aplicativa Conclusiones
A continuación los puntos más críticos de mejora de los 4 focos de análisis : Cobertura del modelo TAM Mejora y automatización de los módulos existente y adquisición de Herramientas o desarrollo de funcionalidades para cumplir con los módulos faltante y cubrir el modelo y aumentar el control de los flujos de datos de la compañía. CRM Triple Play Integración Automatización de los controles de los datos que circulen entre el CRM y las diferentes plataformas para asegurar que la calidad de las mismas. Integración con un bus de Datos para facilitar la integración de nuevas aplicaciones. Arquitectura Aplicativa (todas las aplicaciones menos el CRM) Adquisición de un nuevo Sistema de Valorización, un sistema de telefonía post pago y una herramienta para gestionar los clientes corporativos para cubrir los requerimientos de negocio actuales. Adquisición de herramientas de DW y de reporting para falicitar el conocimento en la empresa. 111

Anexo I: - Detalle de las Recomendaciones. 112 112

Recomendación APL001 (pantallas consolidadas)
Frente Aplicaciones Recomendación APL001 (pantallas consolidadas) Hallazgo En varios casos se encontró que la información requerida por un usuario para completar una tarea muy frecuente, está distribuida en varias pantallas, lo cual obliga al usuario a tener que navegar la aplicación para acceder a dicha información. Descripción de la Recomendación Crear para las tareas más frecuentes (por ejemplo búsqueda y visualización de datos de clientes) pantallas consolidadas que contengan toda la información requerida por los usuarios de manera de minimizar el tiempo que estos invierten en navegar y realizar las tareas más comunes. Beneficios Optimización de los tiempo de trabajo. Prerrequisitos Beneficio Impacto Plazo Trabajar con los usuarios clave para detectar la pantallas más prioritarias Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia No aplica 113 113 113 113 113 113

Recomendación APL002 (validaciones)
Frente Aplicaciones Recomendación APL002 (validaciones) Hallazgo Varios de los datos ingresados por los usuarios carecen de validaciones, lo tiene las siguientes desventajas: Disminuye la calidad de la información almacenada en el sistema, lo cual. Dificulta la realización tareas posteriores. Descripción de la Recomendación Implementar validaciones de longitud y formato. Y cuando sea posible también implementar los algoritmos de dígito verificador (por ejemplo para números de tarjeta , CBUs, CUITs). Beneficios Esto mejorará la calidad de la información del sistema y facilitará la ejecución de cierta tareas posteriores. Prerrequisitos Beneficio Impacto Plazo Validar con los usuarios clave cuales son los campos considerados clave desde la visión de negocio Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia No aplica 114 114 114 114 114 114

Recomendaciones APL003 (mensajes claros)
Frente Aplicaciones Recomendaciones APL003 (mensajes claros) Hallazgo Se detectó que ante errores la aplicación muestra mensajes inapropiados al usuario. Asimismo cuan por alguna razón el sistema colapsa no se el usuario se encuentra con una pantalla poco amigable que no ofrece ningún tipo de explicación. Descripción de la Recomendación Definir en el archivo de configuración de la aplicación páginas personalizadas para cuando la aplicación no está disponible. Manejar las excepciones no atrapadas dentro del Global.asax, dejando registro de la excepción y mostrando un mensaje apropiado para usuario. Involucrar a los usuarios clave en la definición de los mensajes. Beneficios Esto mejorará la percepción que los usuarios tienen del sistema. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 115 115 115 115 115 115

Recomendaciones APL004 (reportes)
Frente Aplicaciones Recomendaciones APL004 (reportes) Hallazgo Es conocida la falta de reportes de la aplicación. Descripción de la Recomendación Se recomienda la implementación de los reportes más prioritarios. Un punto que puede ayudar a que los reportes se hagan más rápido y fácilmente es el uso del componente ReportViewer, incluido en Visual Studio. Este componente está integrado con el entorno de desarrollo y permite el diseño visual de los reportes. Beneficios La implementación de los reportes más prioritarios facilitará el trabajo cotidiano de los usuarios. El uso del mencionado componente facilitará la creación de los reportes. Prerrequisitos Beneficio Impacto Plazo Ninguno Performance Performance Alto Corto Usabilidad Media Medio Mediano Mantenibilidad Baja Bajo Largo Referencia 116 116 116 116 116 116

Anexo II: Describir 117 117

Arquitectura Aplicativa Y CRM Triple Play.

Presentaciones similares

Presentación del tema: "Arquitectura Aplicativa Y CRM Triple Play."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Arquitectura Aplicativa Y CRM Triple Play.

Presentaciones similares

Presentación del tema: "Arquitectura Aplicativa Y CRM Triple Play."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback