©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa...

117
©2008 Deloitte Todos los derechos reservados. 1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

Transcript of ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa...

Page 1: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.1

Frente Organización

FrenteArquitectura AplicativaY CRM Triple Play.

Page 2: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.22

• 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

Contenido

Page 3: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.3 333

• 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:

Frente Arquitectura Aplicativa Introducción

Page 4: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.4

COMENTARIO

Frente Arquitectura Aplicativa Introducción

A continuación se rocorda las principales aplicaciones y plataformas que soportan el actual negocio de Telecentro.

• 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

Page 5: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

IntegraciónIntegración

• Facilidad de uso• Funcionalidad para el

actual negocio.• Uso de capacidades.• Calidad de información• Confiabilidad del

sistema• Accesibilidad.

• Mapa de Integración• Redundancia• Explotación (acceso)• Automatización de

controles.• Documentación.• Estructura.

Frente Arquitectura AplicativaIntroducció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:

CRM Triple PlayCRM Triple Play

• 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

Cobertura del modelo TAM

Cobertura del modelo TAM

• Modelo TAM• Cobertura actual del

Modelo• Listado de

Aplicaciones

5

Page 6: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura Aplicativa

Cobertura del modelo TAM

Cobertura del modelo TAM

• Modelo TAM• Cobertura actual del

Modelo• Listado de

Aplicaciones

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

IntegraciónIntegración

• Facilidad de uso• Funcionalidad para el

actual negocio.• Uso de capacidades.• Calidad de información• Confiabilidad del

sistema• Accesibilidad.

• Mapa de Integración• Redundancia• Explotación (acceso)• Automatización de

controles.• Documentación.• Estructura.

CRM Triple PlayCRM Triple Play

• 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

6

Page 7: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCobertura Actual del Modelo

ProveedorProveedor

Infra

es

truc

tura

de

Inte

gra

ció

nB

us de integración / MiddleW

are / Business P

rocess Managem

entIn

frae

stru

ctu

ra d

e In

teg

rac

ión

Bus de integración / M

iddleWare / B

usiness Process M

anagement

Mercado / VentasMercado / Ventas

ClientesClientes

ServiciosServicios

RecursosRecursos

EmpresaEmpresa

ProductoProducto

Planeación y AlistamientoPlaneación y Alistamiento CumplimientoCumplimiento AseguramientoAseguramiento FacturaciónFacturación

Gestión de Socios

Gestión de Cadena de Abastecimiento

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

Gestión deCampaña

Resultados & Compensaciones

Gestión de canales de Ventas

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

Gestión de Información del Cliente

Autogestión del Cliente

Gestión del contacto con el cliente, Retención & Lealtad

Gestión de Facturación

Política de Cuenta

Facturación

Especificación de Servicios

Gestión de Ciclo de Vida

de Recursos

Gestión de Pedido de Servicios

Gestión de Desempeño de Servicios

Aplicaciones de Mediación de

Datos de Facturación

Gestión de Vouchers

Aplicaciones de Mediación de

Facturación en Tiempo Real

Gestión de Recursos de Dominios

Gestión de Procesos de Recursos (Workflow de Integración)

Gestión de Pedidos de Recursos

Gestión de Cumplimiento de Recursos

Aplicaciones de Gestión de Inventarios de Recursos

Gestión de Inventarios de

Servicios

Gestión de Problemas de Servicio

Análisis de Impacto y

Monitoreo de QoS

Gestión de Acuerdos

de Servicios

Auxiliar de Ventas

Gestión de Ventas Corporativas

Portal de VentasGestión de

Ventas Masivas

Producción de Documentos

Transaccionales

Gestión de Pedidos

del Cliente

Indicadores del Servicio al Cliente

Gestión de QoS & SLA del Cliente

Servicio al Cliente / Resolución de

problemas de Cuenta

Gestión de Cobro

Cargo OnlineRating de Productos/

Servicios

Control de Facturas

Formato de Facturas

Aplicaciones de facturación al por mayor

Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto7

Page 8: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8

Frente Arquitectura Aplicativa Cobertura Futura del modelo TAM

MejoraAdquisición /

DesarrolloCriticidad Complejidad Impacto Plazo

Gestión de Campaña X Media Media Medio Largo

Auxiliar de Ventas X Media Baja Alto Mediano

Gestión de canales de Ventas X Media Media Medio Largo

Gestión de Desempeño del Producto X Media Media Bajo Largo

Autogestión del Cliente X Alta Media Alto Largo

Indicadores del Servicio al Cliente X Alta Alta Alto Corto

Gestión de QoS & SLA del Cliente X Alta Alta Medio Corto

Servicio al Cliente / Resolución de problemas de Cuenta X Alta Media Alto Corto

Control de Facturas X Alta Media Alto Corto

Cargo Online X Media Alta Alto Largo

Aplicaciones de Mediación de Facturación en Tiempo Real X Media Media Bajo Largo

Gestión de Socios X Baja Media Bajo Largo

Gestión de Aseguramiento de Ganancias X Alta Media Alto Mediano

Gestión de Seguridad X Alta Media Alto Corto

Gestión de Fraude X Alta Media Alto Corto

Bus de Integración X Media Alta Alto Largo

A continuación, siguen los diferentes módulos del modelo TAM a cubrir con la criticidad, la complejidad, el Impacto y el Plazo :

Page 9: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.9

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.

Frente Arquitectura AplicativaCobertura Futura TAM: Mercado / Ventas

Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto

Page 10: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

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.

Frente Arquitectura AplicativaCobertura Futura TAM: Productos

Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto10

Page 11: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.11

Frente Arquitectura AplicativaCobertura 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 (e-mail, 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

Page 12: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.12

Frente Arquitectura AplicativaCobertura 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

Page 13: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.13

Frente Arquitectura AplicativaCobertura 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

Page 14: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.14

Frente Arquitectura AplicativaCobertura 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

Page 15: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.15

Frente Arquitectura AplicativaCobertura 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

Page 16: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.16

Frente Arquitectura AplicativaCobertura 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

Page 17: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.17

Frente Arquitectura AplicativaCobertura 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

Page 18: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCobertura Futura del Modelo

ProveedorProveedor

Infra

es

truc

tura

de

Inte

gra

ció

nB

us de integración / SID

/ Business P

rocess Managem

entIn

frae

stru

ctu

ra d

e In

teg

rac

ión

Bus de integración / S

ID / B

usiness Process M

anagement

Mercado / VentasMercado / Ventas

ClientesClientes

ServiciosServicios

RecursosRecursos

EmpresaEmpresa

ProductoProducto

Planeación y AlistamientoPlaneación y Alistamiento CumplimientoCumplimiento AseguramientoAseguramiento FacturaciónFacturación

Gestión de Socios

Gestión de Cadena de Abastecimiento

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

Gestión deCampaña

Resultados & Compensaciones

Gestión de canales de Ventas

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

Gestión de Información del Cliente

Autogestión del Cliente

Gestión del contacto con el cliente, Retención & Lealtad

Gestión de Facturación

Política de Cuenta

Facturación

Especificación de Servicios

Gestión de Ciclo de Vida

de Recursos

Gestión de Pedido de Servicios

Gestión de Desempeño de Servicios

Aplicaciones de Mediación de

Datos de Facturación

Gestión de Vouchers

Aplicaciones de Mediación de

Facturación en Tiempo Real

Gestión de Recursos de Dominios

Gestión de Procesos de Recursos (Workflow de Integración)

Gestión de Pedidos de Recursos

Gestión de Cumplimiento de Recursos

Aplicaciones de Gestión de Inventarios de Recursos

Gestión de Inventarios de

Servicios

Gestión de Problemas de Servicio

Análisis de Impacto y

Monitoreo de QoS

Gestión de Acuerdos

de Servicios

Auxiliar de Ventas

Gestión de Ventas Corporativas

Portal de VentasGestión de

Ventas Masivas

Producción de Documentos

Transaccionales

Gestión de Pedidos

del Cliente

Indicadores del Servicio al Cliente

Gestión de QoS & SLA del Cliente

Servicio al Cliente / Resolución de

problemas de Cuenta

Gestión de Cobro

Cargo OnlineRating de Productos/

Servicios

Control de Facturas

Formato de Facturas

Aplicaciones de facturación al por mayor

Módulo cubierto Módulo parcialmente cubierto Módulo no cubierto18

Page 19: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCobertura 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

Page 20: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura Aplicativa

CRM Triple PlayCRM Triple Play

• 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

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

IntegraciónIntegración

• Facilidad de uso• Funcionalidad para el

actual negocio.• Uso de capacidades.• Calidad de información• Confiabilidad del

sistema• Accesibilidad.

• Mapa de Integración• Redundancia• Explotación (acceso)• Automatización de

controles.• Documentación.• Estructura.

Cobertura del modelo TAM

Cobertura del modelo TAM

• Modelo TAM• Cobertura actual del

Modelo• Listado de

Aplicaciones

20

Page 21: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.2121

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Flexibilidad para añadir nuevas

Funcionalidades

Funcionalidad para el

actual negocio

Facilidad de Uso

Automatización de la

Información

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.

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 22: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.2222

Frente Arquitectura Aplicativa CRM Triple Play – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

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 .

FFFF

Calidad de Información

GGGG

Confiabilidad del Sistema

HHHH

Accesibilidad

EEEE

Uso de Capacidades

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Cambié este

Cambié este

Page 23: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.23

Frente Arquitectura Aplicativa Modelo Objetivo

Situación Objetivo - RecomendacionesSituación Actual

•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)

Page 24: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCRM Triple Play – Aspectos Técnicos

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Facilidad de Integración

Esfuerzo para

Cambios

Tiempo de Respuesta

Disponibilidad del Sistema

24Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 25: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCRM Triple Play – Aspectos Técnicos

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

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.

FFFF

GGGG

Escalabilidad

EEEE

Control y Monitoreo

Dependencia de HW y SW

HHHH

Robustez

25Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 26: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.262626

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.

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.

Descripción de la Recomendación

• Minimizar el uso del ViewState en las páginas, sobre todo en aquellas que contienen grillas.

Referencia

• Understanding ASP.NET View State (MSDN) [http://msdn.microsoft.com/en-us/library/ms972976.aspx]• ASP.NET Life Cycle and Best Practices [http://www.aspfree.com/c/a/ASP.NET/ASP.NET-Life-Cycle-and-Best-Practices/]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 27: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.272727

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.

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.

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.

Referencia

• http://msdn.microsoft.com/en-us/magazine/cc163413.aspx

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 28: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.282828

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.

Beneficios

• Mejor uso de los recursos de memoria del servidor de presentación.

Descripción de la Recomendación

• Limpiar de la sesión la información almacenada temporalmente apenas esta deja de ser útil.

Referencia

• http://msdn.microsoft.com/en-us/magazine/cc163413.aspx

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 29: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.292929

Frente Aplicaciones Recomendación para capa de presentación (cssfriendly)

Hallazgo

Beneficios

• Páginas más livianas.

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.

Referencia

• http://www.codeplex.com/cssfriendly

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 30: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.303030

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.

Beneficios

• Reducción de Round-Trips al servidor

Descripción de la Recomendación

• Reemplazar todos las apariciones de Response.Redirect con Server.Transfer.

Referencia

• Response.Redirect vs Server.Transfer[http://haacked.com/archive/2004/10/06/responseredirectverseservertransfer.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 31: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.313131

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.

Beneficios

• Mejora en la percepción del usuario.

Descripción de la Recomendación

• Para los casos de operaciones complejas considerar el uso de llamadas asincrónica.

Referencia

• http://www.stardeveloper.com/articles/display.html?article=2001121901&page=1

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 32: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.323232

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.

Beneficios

• Disminuirá el consumo de memoria.

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.

Referencia

• Improving .NET Application Performance and Scalability, Capítulo 3, ISBN: 0735618518, http://www.amazon.com/Improving-Application-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 33: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.333333

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.

Beneficios

• Permitirá que los servicios sean consumidos desde otras plataformas y mejorará (de manera imperceptible) el desempeño de la aplicación.

Descripción de la Recomendación

• Reemplazar el uso de DataSets por objetos planos.

Referencia

• http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1048679,00.html

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 34: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.343434

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.

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.

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.

Referencia

• WCF Tips [http://www.infoq.com/news/2007/09/wcf-tips]• Integrating WCF with your existing ASMX Services [http://blogs.msdn.com/trobbins/archive/2006/12/02/integrating-wcf-with-your-

existing-asmx-services.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Sacar los DataSets de la capa de presentación.

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 35: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.353535

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.

Beneficios

• Esto tendrá un impacto en la performance de la aplicación. Disminuyendo el tráfico de la misma.

Descripción de la Recomendación

• Paginar las consultas que devuelven gran cantidad de resultados directamente desde NHibernate.

Referencia

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 36: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.363636

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

Beneficios

• Esto tendrá un impacto en la performance de la aplicación.

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)

Referencia

• Understanding Lazy Loading Strategies for NHibernate [http://blogs.chayachronicles.com/sonofnun/archive/2007/03/30/230.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 37: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.37373737

A continuación, detallamos recomendaciones tratando de los temas de :

-

-

-

Tienen para objetivo de mejorar :

-

-

-

Frente Arquitectura AplicativaRecomendaciones al nivel general

Slide a hacer por Snoop el Lunes

Slide a hacer por Snoop el Lunes

Page 38: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.383838

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.

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.

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.

Referencia

• Exception Handling (MSDN) [http://msdn.microsoft.com/en-us/library/ms229005.aspx]• Throwing Exceptions in C# [http://www.blackwasp.co.uk/CSharpThrowingExceptions.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 39: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.393939

Frente Aplicaciones Recomendaciones generales (caché)

Hallazgo

Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación.

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.

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.

Referencia

• Caching with ASP.NET [http://aspnet.4guysfromrolla.com/articles/022802-1.aspx]• Caching Application Block (MSDN) [http://msdn.microsoft.com/en-us/library/cc309502.aspx]• NHibernate.Caches [http://www.hibernate.org/hib_docs/nhibernate/html/caches.html]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 40: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.404040

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.

Beneficios

• Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código.

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.

Referencia

• Microsoft FxCop [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx]• Microsoft StyleCop [http://code.msdn.microsoft.com/sourceanalysis]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 41: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.414141

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.

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.

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

Referencia

• Introduction to Instrumentation and Tracing [http://msdn.microsoft.com/en-us/library/aa983649(VS.71).aspx]• http://msdn.microsoft.com/en-us/library/5e3s61wf.aspx

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 42: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.424242

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.

Beneficios

• Esto permitirá hacer un uso más optimo de la memoria ya que los recursos se liberarán apenas dejen de ser utilizados.

Descripción de la Recomendación

• Implementar IDisposable en las clases mencionadas anteriormente.

Referencia

• CLR Inside Out [http://msdn.microsoft.com/es-ar/magazine/cc163392.aspx]• Objetos desechables con la interfaz IDisposable [http://www.vtortola.net/post/Objetos-desechables-con-la-interfaz-IDisposable.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

MantenibilidadCambio

estoCambio

esto

Page 43: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.434343

Frente Aplicaciones Recomendaciones Capa de Datos (PK)

Hallazgo

Se detectó gran cantidad de tablas con PK que no tienen índices asociados.

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)

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

Referencia

• Oracle Tunning, Donald Burleson, ISBN: 0-9744486-2-1• http://es.wikipedia.org/wiki/1NF

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 44: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.444444

Frente Aplicaciones Recomendaciones Capa de Datos (indices)

Hallazgo

Se detectó estadísticas de tablas e índices con mas de 3 meses de realizadas.

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.

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)

Referencia

• http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#sthref1068

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

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. 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.

Page 45: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.454545

Frente Aplicaciones Recomendaciones Capa de Datos (extends)

Hallazgo

Se detectaron objetos (tablas e índices) con alta cantidad de extents.

Beneficios

• Esto beneficia a la velocidad de acceso a los datos para los full scan ya que los bloques estaran en forma contigua.

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:

1. Crear tablespaces de datos e índices con las características mencionadas arriba2. Identificar los segmentos candidatos y recrearlos en dichos tablespaces

Referencia

• Oracle Tunning, Donald Burleson, ISBN: 0-9744486-2-1

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 46: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.464646

Frente Aplicaciones Recomendaciones Capa de Datos (executeparse)

Hallazgo

Se detectó bajo valor de Execute to Parse.

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.

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.

Referencia

• http://www.oracle.com/technology/deploy/performance/pdf/cursor.pdf

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 47: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.474747

Frente Aplicaciones Recomendaciones Capa de Datos (full scans)

Hallazgo

Alta cantidad de full scan en tablas pequeñas.

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.

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.

Referencia

• http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref463• Metalink : Oracle Multiple Buffer Pools Feature Note:135223.1

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 48: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.484848

Frente Aplicaciones Recomendaciones Capa de Datos (cache waits)

Hallazgo

Fue detectado un alto valor de library cache waits.

Beneficios

• Es muy útil para grandes objetos que son usados frecuentemente, puede bajar considerable los tiempos de espera de library cache.

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.

Referencia

• http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_shpool.htm#sthref5952

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 49: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.494949

Frente Aplicaciones Recomendaciones Capa de Datos (optimizador)

Hallazgo

Falta de ajuste en el optimizador de costos de indices

Beneficios

• 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.

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.

Referencia

• http://www.dba-oracle.com/oracle_tips_cost_adj.htm

Gran numero de chained/migrated rows Gran numero de chained/migrated rows

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 50: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.505050

Frente Aplicaciones Recomendaciones Capa de Datos (chained/migrated)

Hallazgo

Se detectó gran numero de chained/migrated rows

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.

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

Referencia

• Metalink : Row Chaining and Row Migration Note:122020.1

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Cambio esto

Cambio esto

Page 51: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.515151

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.

Beneficio

Performance

Usabilidad

Mantenibilidad

Prerrequisitos Impacto

Alto

Medio

Bajo

Beneficios• A partir de esto puede que las situaciones abruptas de finalización de sesión sean mucho más esporádicas.

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.

Plazo

Referencia

• http://blogs.msdn.com/david.wang/archive/2006/01/26/Thoughts-on-Application-Pool-Recycling-and-Application-Availability.aspx• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1eee28e2-b319-4b4e-8267-a8c0aa0dcf36.mspx?mfr=true

Corto

Mediano

Largo

Ninguno

Esto va en infraestrcturaEsto va en infraestrctura

Cambio esto

Cambio esto

Page 52: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.525252

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.

Beneficios

• Esto evitará que los usuarios sufran las mencionadas interrupciones.

Descripción de la Recomendación

• Implementar un modo de sesión independiente del proceso .

Referencia

• Improving .NET Application Performance and Scalability, ISBN: 0735618518, http://www.amazon.com/Improving-Application-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.

Beneficio

Performance

Usabilidad

Mantenibilidad

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Dependiendo de la estrategia elegida, puede ser necesario adquirir hardware adicional.

Esto va en infraestrcturaEsto va en infraestrctura

Cambio esto

Cambio esto

Page 53: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.535353

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.

Beneficios

• Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware.

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.

Referencia

• Improving .NET Application Performance and Scalability, Capítulo 17, ISBN: 0735618518, http://www.amazon.com/Improving-Application-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.

<system.net> <connectionManagement> <add address="[webservice-ip]" maxconnection="100" /> </connectionManagement></system.net>

Beneficio

Performance

Usabilidad

Mantenibilidad

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Esto va en infraestrcturaEsto va en infraestrctura

Cambio esto

Cambio esto

Page 54: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.545454

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.

Beneficios

• Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware.

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.

Referencia

• Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: 0735618518, http://www.amazon.com/Improving-Application-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.

<processModelmemoryLimit="80" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="40" minIoThreads="30" >

Beneficio

Performance

Usabilidad

Mantenibilidad

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Esto va en infraestrcturaEsto va en infraestrctura

Page 55: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.555555

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.

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.

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).

Referencia

• Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: 0735618518, http://www.amazon.com/Improving-Application-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.

<httpModules><remove name=“nombreDelModulo“/><remove name="WindowsAuthentication" /><remove name="PassportAuthentication" />

</httpModules>

Beneficio

Performance

Usabilidad

Mantenibilidad

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Esto va en infraestrcturaEsto va en infraestrctura

Page 56: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.565656

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.

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.

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.

Referencia

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Ver como ajustar esto

Ver como ajustar esto

Page 57: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.575757

Frente Aplicaciones Recomendación para proceso de desarrollo (colaboración)

Hallazgo

Beneficios

• Centralización y distribución de la información.• Posibilidad de acceso global.

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.

Referencia

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Ver como ajustar esto

Ver como ajustar esto

Page 58: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.585858

Frente Aplicaciones Recomendación para proceso de desarrollo (test)

Hallazgo

Actualmente no hay pruebas automatizadas de la aplicación

Beneficios

• Disminución de los costos de test.

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

Referencia

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Ver como ajustar esto

Ver como ajustar esto

Page 59: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.595959

Frente Aplicaciones Recomendaciones generales (caché)

Hallazgo

Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación.

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.

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.

Referencia

• Caching with ASP.NET [http://aspnet.4guysfromrolla.com/articles/022802-1.aspx]• Caching Application Block (MSDN) [http://msdn.microsoft.com/en-us/library/cc309502.aspx]

Esta repetidaEsta repetida

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Analizar las distintas alternativas de implementación (¿En que capa? y ¿Con que componente?)

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 60: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.606060

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.

Beneficios

• Ejecutar esta recomendación impactará en la performance de la aplicación. Optimizando los recursos del IIS, particularmente el manejo de memoria.

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.

Referencia

• CLR Inside Out [http://msdn.microsoft.com/es-ar/magazine/cc163392.aspx]• Objetos desechables con la interfaz IDisposable [http://www.vtortola.net/post/Objetos-desechables-con-la-interfaz-IDisposable.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Idem a Capa de Presentación

(Sección)

Idem a Capa de Presentación

(Sección)

Esta repetidaEsta repetida

Page 61: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.616161

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.

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.

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.

Referencia

• Exception Handling (MSDN) [http://msdn.microsoft.com/en-us/library/ms229005.aspx]• Throwing Exceptions in C# [http://www.blackwasp.co.uk/CSharpThrowingExceptions.aspx]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Esta repetidaEsta repetida

Page 62: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.626262

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)

Beneficios

• Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código.

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.

Referencia

• Microsoft FxCop [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx]• Microsoft StyleCop [http://code.msdn.microsoft.com/sourceanalysis]

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Esta repetidaEsta repetida

Page 63: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.636363

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.

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.

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.

Referencia

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Volver a verificarVolver a verificar

Esta repetidaEsta repetida

Page 64: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.64

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

Microsoft Solution Framework (MSF)

Extreme Programing (XP)

Rational Unified Process (RUP)

Algunos ejemplos de metodologías que pueden utilizarse dependiendo del proyecto que se va a iniciar.

Frente Arquitectura Aplicativa Metodologías de Desarrollo

Page 65: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaCalidad de Datos - Introducción

65

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

Page 66: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.666666

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.

Criticidad

Alta

Media

Baja

•Ninguno

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?tok=1211574194219&nid=33043• http://www.ibermatica.com/ibermatica/eventos/2004/mtbi

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 67: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.67

Frente Arquitectura Aplicativa Recomendación Documentación

Recomendación sobre como hacer una documentación si se

necesita – mande el mail a Snoop

Recomendación sobre como hacer una documentación si se

necesita – mande el mail a Snoop

Page 68: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.68686868

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.

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.

Identificar Enfoques según

Roles

Identificar Enfoques según

Roles

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.

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.

Diseñar en base a su Utilidad

Diseñar en base a su Utilidad

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.

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.

Crear y ejecutar Plan de

Comunicación

Crear y ejecutar Plan de

Comunicació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.

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.

Actualizar documentación

Actualizar documentación

Frente Arquitectura Aplicativa Estándares de Documentación - Lineamientos

Page 69: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.69696969

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:

Elementos ClavesRolesRoles

EnfoqueEnfoque

DiseñoDiseño

ActualizaciónActualización

ComunicaciónComunicación

PrecisiónPrecisión

Valor AgregadoValor Agregado

Frente Arquitectura Aplicativa Estándares de Documentación

Page 70: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

IntegraciónIntegración

• Mapa de Integración• Redundancia• Explotación (acceso)• Automatización de

controles.• Documentación.• Estructura.

Frente Arquitectura Aplicativa

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

• Facilidad de uso• Funcionalidad para el

actual negocio.• Uso de capacidades.• Calidad de información• Confiabilidad del

sistema• Accesibilidad.

CRM Triple PlayCRM Triple Play

• 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

Cobertura del modelo TAM

Cobertura del modelo TAM

• Modelo TAM• Cobertura actual del

Modelo• Listado de

Aplicaciones

70

Page 71: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.71

1

2

3

1

1

1

3

4

4

4

4

Plataforma Window s

Flujo de Trabajo

Bas ilea II, Ries go Operacional

G overnancia

Es tandares

Complejidad

Renovación

Planeación es trategica

Trans parencia

Operaciones

Des arrollo

7171

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:

Principales Preocupaciones en TIPrincipales Preocupaciones en TI

Frente Arquitectura Aplicativa Integración- Tendencias

¿Cuáles son las tres (3) principales preocupaciones de los CIO’s?

A continuación, desarrollamos algunos de los principios guía de arquitectura aplicativa anteriormente mencionados:

Costo

Aplicación

Arquitectura

Otros

Page 72: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaIntegración - Introducción

72

• 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.

Page 73: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaIntegración - Introducción

73

• 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.

No. de Aplicaciones

No.

de

Inte

rfac

es

Topologíacon Middleware

App. B

App. C

App. A

App. D

App. E

Topología Punto a Punto

No. de Aplicaciones

No.

de

Inte

rfac

es

Core

Siebel

SAP

Internet

PeopleSoft

Page 74: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.74747474

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.

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.

Page 75: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

A continuación presentamos el mapa de integración de los distintos aplicativos:

Frente Arquitectura AplicativaMapa de Integración (Mediano Plazo – 6 a 18 meses)

75

•Red de Telefonía

Nuevo sistema telefonía post

pago

Sistema Clientes

Corporativos

Nuevos sistemas

Valorizador

•Pago Fácil•RapiPago

•Bapropagos•Bancos

•Movistar•Claro

•Personal•Nextel

ADebitar

ResultadoDébito/Cargos

Comisionables

CDRs

Activaciones /Desactivaciones/

Pagos

Consumos CPP

-Consumo de materiales

-Facturación

Disponibilidad de Materiales

•Red de CATV

•Red de Telefonía

Activaciones /Desactivaciones

Activaciones /Desactivaciones

Recaudación

Tarjetas por DAT/Pago

directo

Agentes Recaudadores

DAC 6000

INTRAWAY IPUNITY

CPP

CRM Triple Play

•Red de Banda Ancha

Estado del Servicio

Estado del Servicio

FOX

Prebilling y Billing

•Casilla de Mensajes

Información Facturación

Altas y Bajas Entes

ExternosCARENA

Liquidaciones

-Archivos de Contabilidad

OracleFinancials

CDRs

Clientes

Reporting

Page 76: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

A continuación presentamos el mapa de integración de los distintos aplicativos:

Frente Arquitectura AplicativaMapa de Integración (Largo Plazo – > 18 meses)

76

•Pago Fácil•RapiPago

•Bapropagos•Bancos

•Movistar•Claro

•Personal•Nextel

•Red de Telefonía

Tarjetas por DAT/Pago

directo

Agentes Recaudadores

DAC 6000

INTRAWAY IPUNITYCPP

Nuevo sistema telefonía post

pago

CRM Triple Play

FOXPrebilling y Billing

Entes Externos

CARENA

OracleFinancials

Sistema Clientes

Corporativos

BUS DE INTEGRACIÓNBUS DE INTEGRACIÓN

Nuevos sistemas

DW

Valorizador

BPM Reporting

Base de Conocimiento

Page 77: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.7777

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

Frente Arquitectura Aplicativa Integración

DD

Documentación

EE

Estructura

AA

BB

CC

Explotación (acceso)

Redundancia

Automatización de controles

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 78: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.787878

Frente Arquitectura Aplicativa Recomendación XXX

Particularidad

No se utiliza ninguna herramienta de integración (middleware) para poder realizar un mayor control sobre el intercambio de información.

Criticidad

Alta

Media

Baja

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• http://www.tmforum.org/browse.aspx?catID=5733

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 79: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

Arquitectura Aplicativa (ERP, Comarch, Intraway, FOX y Otras aplicaciones)

• Facilidad de uso• Funcionalidad para el

actual negocio.• Uso de capacidades.• Calidad de información• Confiabilidad del

sistema• Accesibilidad.

Frente Arquitectura Aplicativa

IntegraciónIntegración

• Mapa de Integración• Redundancia• Explotación (acceso)• Automatización de

controles.• Documentación.• Estructura.

CRM Triple PlayCRM Triple Play

• 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

Cobertura del modelo TAM

Cobertura del modelo TAM

• Modelo TAM• Cobertura actual del

Modelo• Listado de

Aplicaciones

79

Page 80: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8080

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Flexibilidad para añadir

nuevas Funcionalida

d

Funcionalidad para el

actual negocio

Facilidad de Uso

Automatización de la

Información

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.

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 81: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8181

Frente Arquitectura Aplicativa Oracle Financials – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

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 .

FFFF

Calidad de Información

GGGG

Confiabilidad del Sistema

HHHH

Accesibilidad

EEEE

Uso de Capacidades

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 82: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaOracle Financials – Aspectos Técnicos

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Facilidad de Integración

Esfuerzo para

Cambios

Tiempo de Respuesta

Disponibilidad del Sistema

82Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 83: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaOracle Financials – Aspectos Técnicos

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

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.

FFFF

GGGG

Escalabilidad

EEEE

Control y Monitoreo

Dependencia de HW y SW

83

HHHH

Robustez

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 84: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8484

Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Flexibilidad para añadir

nuevas Funcionalida

d

Funcionalidad para el

actual negocio

Facilidad de Uso

Automatización de la

Información

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.

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 85: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8585

Frente Arquitectura Aplicativa Sistema tel. post pago + Valorizador – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

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 .

FFFF

Calidad de Información

GGGG

Confiabilidad del Sistema

HHHH

Accesibilidad

EEEE

Uso de Capacidades

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 86: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaSistema tel. post pago + Valorizador – Aspectos Técnicos

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Facilidad de Integración

Esfuerzo para

Cambios

Tiempo de Respuesta

Disponibilidad del Sistema

86Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 87: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaSistema tel. post pago + Valorizador – Aspectos Técnicos

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

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.

FFFF

GGGG

Escalabilidad

EEEE

Control y Monitoreo

Dependencia de HW y SW

87

HHHH

Robustez

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 88: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8888

Frente Arquitectura Aplicativa Intraway – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Flexibilidad para añadir

nuevas Funcionalida

d

Funcionalidad para el

actual negocio

Facilidad de Uso

Automatización de la

Información

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.

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 89: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.8989

Frente Arquitectura Aplicativa Intraway – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

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 .

FFFF

Calidad de Información

GGGG

Confiabilidad del Sistema

HHHH

Accesibilidad

EEEE

Uso de Capacidades

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 90: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaIntraway – Aspectos Técnicos

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Facilidad de Integración

Esfuerzo para

Cambios

Tiempo de Respuesta

Disponibilidad del Sistema

90Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 91: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaIntraway – Aspectos Técnicos

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

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.

FFFF

GGGG

Escalabilidad

EEEE

Control y Monitoreo

Dependencia de HW y SW

91

HHHH

Robustez

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 92: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.9292

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Flexibilidad para añadir

nuevas Funcionalida

d

Funcionalidad para el

actual negocio

Facilidad de Uso

Automatización de la

Información

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.

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 93: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.9393

Frente Arquitectura Aplicativa Otras Aplicaciones – Aspectos Funcionales

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente COMENTARIOObservacionesObservacionesObservacionesObservaciones

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 .

FFFF

Calidad de Información

GGGG

Confiabilidad del Sistema

HHHH

Accesibilidad

EEEE

Uso de Capacidades

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 94: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaOtras Aplicaciones – Aspectos Técnicos

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.

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

AA

BB

CCCC

DDDD

Facilidad de Integración

Esfuerzo para

Cambios

Tiempo de Respuesta

Disponibilidad del Sistema

94Nivel de Madurez Actual

Nivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 95: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Frente Arquitectura AplicativaOtras Aplicaciones – Aspectos Técnicos

Nivel INivel IInicialNivel INivel IInicial

Nivel IINivel IIRegularNivel IINivel IIRegular

Nivel IIINivel IIIBueno

Nivel IIINivel IIIBueno

Nivel IVNivel IVMuy Bueno

Nivel IVNivel IVMuy Bueno

Nivel VNivel VExcelenteNivel VNivel V

Excelente ObservacionesObservacionesObservacionesObservaciones

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.

FFFF

GGGG

Escalabilidad

EEEE

Control y Monitoreo

Dependencia de HW y SW

95

HHHH

Robustez

Nivel de Madurez ActualNivel de Madurez Objetivo (mediano plazo)

Nivel de Madurez Objetivo (largo plazo)

Page 96: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.969696

Frente Arquitectura Aplicativa Recomendación XXX

Particularidad

El sistema Comarch está pensado como prepago y utilizado como post-pago.

Criticidad

Alta

Media

Baja

•Ninguno

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• http://www.bitpipe.com/tlist/Telecom-Billing-Systems.html• http://www.capterra.com/billing-and-provisioning-software

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 97: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.979797

Frente Arquitectura Aplicativa Recomendación XXX

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.

Criticidad

Alta

Media

Baja

•Ninguno

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• http://www.oracle.com/applications/financials/cash_mgmt.html

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 98: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.989898

Frente Arquitectura Aplicativa Recomendación XXX

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.

Criticidad

Alta

Media

Baja

•Implementar el área de Reporting (ORGXXX).

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• Herramientas Open Source: http://reporting.pentaho.org/ , http://jasperforge.org/plugins/project/project_home.php?group_id=102

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 99: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Retrospectiva

Datos

Reportes

Información

Consultas / Exploración Ad Hoc

Conocimiento

Percepción Analítica

Percepción y Previsión

Innovación

Prospectiva

Impa

cto

Est

rat

égic

o

Inversión en Business Intelligence

Contexto y Relevancia

Análisis KPI’s “Slice and Dice”

Data Mining & Visualización

Descubrimientos Clasificaciones Predicciones

Frente Arquitectura AplicativaDW - Introducción

99

Demanda de Información

Mayor entendimiento del negocio

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.

Page 100: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Definiciones generales

• 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.

Frente Arquitectura AplicativaDW - Definición

Page 101: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Arquitectura técnica de BI

Empresa

Desestructu- rada

Informacional

Externa

Fuente de Datos

Extracción

Transforma-ción

Carga

Sincroniza-ción

Transporte / Mensaje

Mantenimien-to de

Integridad

Servicios de Integración

Web Browser

Portal

Dispositivos

Web Services

Servicios de Delivery

Data Marts

Datos Operativos

Reportes de Producción

Data Mining

Tableros de Comando

Análisis Embebido

Reportes de usuario final

Servicios Analíticos

OLAP

Almacenamiento de Datos

Frente Arquitectura AplicativaDW - Componentes

Page 102: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

• Son los sistemas que proveen la información al BI.Fuentes de Datos

• Son las tecnologías que permiten el flujo de datos entre los distintos sistemas.

Servicios de Integración

• Soluciones que analizan los datos a extraer para construir la información y reportes del BI para los usuarios.

Servicios Analíticos

• Se refiere a los sistemas que consolidan y guardan la información que será utilizada para análisis.

Almacenamiento de Datos

• Son los sistemas que permiten a los usuarios acceder a la información y reportes del BI.

Servicios de Delivery

Arquitectura técnica del BI

Frente Arquitectura AplicativaDW – Componentes (Cont.)

Page 103: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Factores Críticos de Éxito

Frente Arquitectura AplicativaDW – Factores de Éxito

• 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.

Alineamiento del negocio y enfoque hacia los beneficios

• 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.

Experiencia en BI

y DW

• Un equipo experimentado en la implementación de BI, que conozca la industria de las telecomunicaciones, la empresa, su tecnología y el negocio.

El equipo adecuado

• 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

Efectividad de la Gobernabilidad y el Manejo del Cambio

Page 104: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.104104104

Frente Arquitectura Aplicativa Recomendación XXX

Particularidad

No hay un datawarehouse implementado que permita hacer análisis complejos de distintas variables de negocio.

Criticidad

Alta

Media

Baja

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

Descripción de la Recomendación

• Implementación un repositorio común de datos de negocio.• Implementación de herramientas de inteligencia de negocio.

Plazo

Referencia

• http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?tok=1211574194219&nid=33043• http://www.ibermatica.com/ibermatica/eventos/2004/mtbi

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 105: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.105105105

Frente Arquitectura Aplicativa Recomendación XXX

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.

Criticidad

Alta

Media

Baja

PrerrequisitosImpacto

Alto

Medio

Bajo

Beneficios• Contar con una herramienta que permita desarrollar las habilidades internas y compartir experiencias que ayuden a resolver problemas

recurrentes.

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.

Plazo

Referencia

• http://it.toolbox.com/vendors/topics/knowledge-management

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 106: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.106

• 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.

• 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.

BPM – Business Process ManagementBPM – Business Process ManagementBPM – Business Process ManagementBPM – Business Process Management

Pero no…Pero no…Pero no…Pero no…

Frente Arquitectura AplicativaBPM - Introducción

Page 107: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.107

Frente Arquitectura AplicativaBPM - 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?

Eficiencia de los procesos y efectividad en el ServicioEficiencia de los procesos y efectividad en el ServicioEficiencia de los procesos y efectividad en el ServicioEficiencia de los procesos y efectividad en el ServicioFoco 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.

Flexibilidad OrganizacionalFlexibilidad OrganizacionalFlexibilidad OrganizacionalFlexibilidad Organizacional

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.

Respuesta Ágil al MercadoRespuesta Ágil al MercadoRespuesta Ágil al MercadoRespuesta Ágil al MercadoPromueve 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.

Relacionamiento con el ClienteRelacionamiento con el ClienteRelacionamiento con el ClienteRelacionamiento con el ClienteLas 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.

Page 108: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.108

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ónOptimización

DefiniciónDefinición

CreaciónCreación

EjecuciónEjecución

MonitoreoMonitoreo

DefiniciónDefiniciónDefiniciónDefinición

CreaciónCreaciónCreaciónCreación

EjecuciónEjecuciónEjecuciónEjecución

MonitoreoMonitoreoMonitoreoMonitoreo

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.

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.

Se encapsula la ejecución de todo el proceso, usando una combinación de Integración, workflow, automatización y reglas de negocios.

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ónEjecuciónEjecuciónEjecució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.

Frente Arquitectura Aplicativa BPM - Eficiencia Operacional

Page 109: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.109109109

Frente Arquitectura Aplicativa Recomendación XXX

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.

Criticidad

Alta

Media

Baja

PrerrequisitosImpacto

Alto

Medio

Bajo

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.

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.

Plazo

Referencia

• http://www.bpm.com/

Corto

Mediano

Largo

Complejidad

Alto

Medio

Bajo

Page 110: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.110110110

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:

Frente Arquitectura Aplicativa Conclusión

• 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.

• 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.

Page 111: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.111111

Frente Arquitectura Aplicativa Conclusiones

• 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.

Cobertura del modelo TAM

CRM Triple Play

• 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.

Arquitectura Aplicativa (todas las aplicaciones menos el CRM)

• 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. Integración

A continuación los puntos más críticos de mejora de los 4 focos de análisis :

Page 112: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Anexo I:

- Detalle de las Recomendaciones.

Frente Arquitectura Aplicativa

112

Page 113: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.113113113

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.

Beneficios

• Optimización de los tiempo de trabajo.

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.

Referencia

• No aplica

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Trabajar con los usuarios clave para detectar la pantallas más prioritarias

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 114: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.114114114

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.

Beneficios

• Esto mejorará la calidad de la información del sistema y facilitará la ejecución de cierta 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).

Referencia

• No aplica

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Validar con los usuarios clave cuales son los campos considerados clave desde la visión de negocio

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 115: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.115115115

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.

Beneficios

• Esto mejorará la percepción que los usuarios tienen del sistema.

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.

Referencia

• http://aspnetresources.com/articles/CustomErrorPages.aspx

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Page 116: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.116116116

Frente Aplicaciones Recomendaciones APL004 (reportes)

Hallazgo

Es conocida la falta de reportes de la aplicación.

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.

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.

Referencia

• http://www.gotreportviewer.com/

Media

Baja

Prerrequisitos Impacto

Alto

Medio

Bajo

Plazo

Corto

Mediano

Largo

Ninguno

Beneficio

Performance

Usabilidad

Mantenibilidad

Performance

Page 117: ©2008 Deloitte Todos los derechos reservados.1 Frente Organización Frente Arquitectura Aplicativa Y CRM Triple Play.

©2008 Deloitte Todos los derechos reservados.

Anexo II:– Describir

Frente Arquitectura Aplicativa

117