©2008 Deloitte Todos los derechos reservados.1
Frente Organización
FrenteArquitectura AplicativaY 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
©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
©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
©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
©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
©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
©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 :
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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)
©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
©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)
©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)
©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)
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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.
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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
©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.
©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
©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.
©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
©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
©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)
©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
©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
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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)
©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
©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
©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
©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.
©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
©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
©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.)
©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
©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
©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
©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
©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.
©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
©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
©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.
©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 :
©2008 Deloitte Todos los derechos reservados.
Anexo I:
- Detalle de las Recomendaciones.
Frente Arquitectura Aplicativa
112
©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
©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
©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
©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
©2008 Deloitte Todos los derechos reservados.
Anexo II:– Describir
Frente Arquitectura Aplicativa
117