Frente Organización
Frente
Arquitectura Aplicativa
Y CRM Triple Play.
1
©2008 Deloitte Todos los derechos reservados.
Contenido
•
•
•
•
•
2
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
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Introducción
• En virtud de los particularidades
Socio Estratégico sugerido para
aplicaciones objetivo, el cual
aquellos aspectos funcionales
oportunidades de mejora:
detectadas durante el diagnóstico, y el rol de
el área de Sistemas, se elaboró un mapa de
tiene como principal propósito, desarrollar
y técnicos que han evidenciado mayores
• Flexibilidad NO ES CORRECTO
• Esfuerzo para cambios ES DISCUTIBLE
• Funcionalidad para el negocio NO ESTOY DE ACUERDO
• Calidad de la información
• Automatización de la información
• Tiempos de respuesta FALTA ESTE
• Facilidad de uso FALTA ESTE
• A continuación, presentamos las recomendaciones que tienen como objetivo
cubrir la brecha existente entre el nivel de madurez actual y el nivel de madurez
objetivo:
3 3
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Introducción
A continuación se rocorda las principales aplicaciones y plataformas que soportan el actual negocio de
COMENTARIO
Telecentro.
•
CRM Triple Play:
• Planes de Venta
• Productos y Servicios
• Zona Comercial
• Red
• Reclamos
• Clientes
• Contratación
• Visitas técnicas
• Cuentas Corrientes
• Bajas
• Comisiones
•
•
•
•
•
•
•
•
•
•
•
•
4
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.
Frente Arquitectura Aplicativa
Introducción
Para evaluar las aplicaciones con que actualmente Telecentro lleva adelante su
negocio, se utilizaron como marco de referencia los siguientes elementos de foco
para llevar a cabo el análisis:
Cobertura del modelo
TAM
• Modelo TAM
• Cobertura actual del
Modelo
• Listado de Aplicaciones
5
Integración
CRM 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
•
•
•
•
Mapa de Integración
Redundancia
Explotación (acceso)
Automatización de
controles.
• Documentación.
• Estructura.
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura del modelo
TAM
• Modelo TAM
• Cobertura actual del
Modelo
• Listado de Aplicaciones
6
Integración
CRM 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
•
•
•
•
Mapa de Integración
Redundancia
Explotación (acceso)
Automatización de
controles.
• Documentación.
• Estructura.
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Actual del Modelo
Mercado / Ventas
Auxiliar
de Ventas
Gestión de
Campaña
Producto
Resultados &
Compensaciones
Planeación y Alistamiento
Gestión de
Catálogos de
Servicios /
Productos
Gestión de
Desempeño
del Producto
Facturación
Autogestión del Cliente
Gestión del contacto con el cliente, Retención & Lealtad
Gestión de QoS
& SLA del Cliente
Gestión de
Acuerdos
de Servicios
Servicios
Gestión de Pedido
de Servicios
Servicio al Cliente /
Resolución de
problemas de Cuenta
Rating de Productos/
Servicios
Cargo Online
Análisis de Impacto
y
Monitoreo de QoS
Gestión de
Problemas
de Servicio
Gestión de
Desempeño
de Servicios
Gestión de
Cumplimiento
de Recursos
Aplicaciones de
Mediación de
Facturación en
Tiempo Real
Gestión
de Vouchers
Gestión de Recursos de Dominios
Proveedor
Gestión de
Socios
Gestión de Cadena
de Abastecimiento
Aplicaciones de facturación
al por mayor
Business Process Management
Aplicaciones
de Mediación de
Datos de Facturación
Aplicaciones de Gestión de Inventarios de Recursos
Gestión de Pedidos
de Recursos
Facturación
Formato de Facturas
Gestión de Procesos de Recursos (Workflow de Integración)
Gestión de Ciclo de
Vida
de Recursos
Política de
Cuenta
Control de
Facturas
Infraestructura de Integración
Producción de
Documentos
Transaccionales
Recursos
Gestión de
Facturación
Gestión
de Cobro
Indicadores del Servicio al Cliente
Gestión de
Inventarios de
Servicios
Portal de Ventas
Aseguramiento
Gestión de
Pedidos
del Cliente
Gestión de
Información
del Cliente
Gestión de Ventas
Corporativas
Gestión de
Ciclo de Vida
de Producto
Cumplimiento
Clientes
Especificación
de Servicios
Gestión de canales
de Ventas
Bus de integración / MiddleWare /
Estrategia de Producto
/ Gestión de
propuestas
Gestión de
Ventas Masivas
Empresa
Gestión de
Aseguramiento
de Ganancias
7
Módulo cubierto
Gestión de
RRHH
Módulo parcialmente cubierto
Gestión
Financiera
Módulo no cubierto
Gestión de
Activos
Gestión de
Seguridad
Gestión del
Conocimiento
Gestión de
fraude
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura del modelo TAM
A continuación, siguen los diferentes módulos del modelo TAM a cubrir con la criticidad, la
complejidad, el Impacto y el Plazo :
Mejora
Gestión de Campaña
Auxiliar de Ventas
Criticidad
Complejidad
Impacto
Plazo
X
Media
Media
Medio
Largo
Media
Baja
Alto
Mediano
X
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
Alta
Alta
Alto
Corto
Alta
Alta
Medio
Corto
Indicadores del Servicio al Cliente
X
X
Gestión de QoS & SLA del Cliente
Servicio al Cliente / Resolución de problemas de Cuenta
X
Alta
Media
Alto
Corto
Control de Facturas
X
Alta
Media
Alto
Corto
Media
Alta
Alto
Largo
Media
Media
Bajo
Largo
X
Cargo Online
Aplicaciones de Mediación de Facturación en Tiempo
Real
X
Gestión de Socios
X
Baja
Media
Bajo
Largo
Gestión de Aseguramiento de Ganancias
X
Alta
Media
Alto
Mediano
Alta
Media
Alto
Corto
Gestión de Seguridad
8
Adquisición /
Desarrollo
X
Gestión de Fraude
X
Alta
Media
Alto
Corto
Bus de Integración
X
Media
Alta
Alto
Largo
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Mercado / Ventas
El dominio “Mercado / Ventas” contiene las operaciones de contratos y datos para soportar
las actividades de venta o de marketing necesarias para generar negocios con los clientes.
Se considera como parte de ventas todo lo relacionado con los contactos, los posibles
clientes, la fuerza de venta y las estadísticas de venta. Mercado alcanza todo lo que
concierne a la estrategia, los planes, los segmentos de mercado, la competencia y sus
productos, y la formulación de campañas.
Módulos :
• Gestión de Campaña: aplicaciones responsables de manejar el ciclo de vida de las campañas
de marketing.
• Gestión de Ventas Masivas: aplicaciones con funcionalidades de manejo de ventas para
personas o PyMEs.
• Gestión de Ventas Corporativas: aplicaciones con funcionalidades de manejo de venta para las
grandes empresas.
• Portal de Ventas: provee una única entrada a los vendedores para acceder a las herramientas
de venta.
• Auxiliar de Ventas: aplicaciones que proveen acceso a los métodos y procedimientos, como así
también a la información del producto que puede ser utilizado para soportar la venta.
• Resultados & Compensaciones: funcionalidades necesarias para la compensación de los
vendedores, desde la asignación de las cuentas, nuevas ventas, ingresos facturados, hasta el
cálculo de los planes de compensación y el reporte de resultados.
• Gestión de canales de Ventas: aplicaciones para vender a un número específico de canales de
venta.
9
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Productos
El dominio “Productos” es la visión de la organización para el proceso de desarrollo, de
administración y de marketing de su oferta de productos para el cliente.
Módulos :
• Estrategia de Producto / Gestión de propuestas: plan de acción para lograr los objetivos de la
estrategia operativa a través de los productos vendidos en el mercado.
• Gestión de Catálogos de Servicios / Productos: habilidad para crear y mantener los productos
que se han vendido a los clientes en el marcado objetivo (manejo centralizado en un catálogo).
• Gestión de Ciclo de Vida de Producto: parte responsable del manejo del ciclo de vida del
producto y de los componentes asociados, incluyendo todo el proceso requerido para el diseño,
la construcción, el despliegue, el mantenimiento y la eliminación del producto.
• Gestión de Desempeño del Producto: actividades y herramientas que obtienen y analizan los
datos desde el punto de vista de la eficacia de la estrategia del producto, basándose en el
desempeño en el mercado.
10
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Clientes
El dominio “Clientes” trata de los procesos de conocimiento de las necesidades de los
clientes y contiene todas las funcionalidades necesarias para la adquisición, la retención y
la mejora de la relación con el mismo.
Módulos:
• Gestión de Información del Cliente: “corazon” de todo CRM, utilizado por todos los canales de
distribución; sirve para la creación, actualización y búsqueda de la información del cliente.
• Producción de Documentos Transaccionales: actividades para emitir facturas, cartas o
cualquier documentación a los clientes.
• Gestión de Pedidos del Cliente: administra el ciclo de vida de la necesidad de un cliente para
un producto (establecimiento del pedido, publicación del pedido, tratamiento del pedido, etc.).
• Autogestión del Cliente: aplicaciones para proveer una interfaz al cliente para realizar pedidos u
otras funciones a través de Internet.
• Gestión del contacto con el Cliente, Retención & Lealtad: funcionalidades para autorizar a un
operador a crear, actualizar y ver la información del cliente, guardar y ver los interacciones del
mismo con los diferentes canales de comunicación, ver su histórico, sus facturas, etc., con el fin
de retenerlo.
• Indicadores del Servicio al Cliente: tiene un rol crítico en la obtención de la experiencia del
cliente en cuanto a servicio y satisfacción, pero también para detectar oportunidades de venta a
través de interacciones con el cliente (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.
11
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Clientes (Cont.)
Módulos (Cont.) :
• Gestión de Cobro: aplicación para automatizar y manejar el proceso de transacciones
financieras que afectan la cuenta del cliente.
• Gestión de Facturación: módulo con todas las funcionalidades necesarias que permitan
efectuar la facturación del cliente.
• Control de Facturas: aplicaciones utilizadas para manejar preguntas y ajustes en la facturación.
• Formato de Facturas: herramientas para dar formato a la factura, basada en opciones
especificadas y luego lo hace disponible en medios de comunicación apropiados.
• Cargo Online: mecanismo de cobro que es responsable en tiempo real, de cargar y modificar la
información del cliente sin afectar el servicio.
• Rating de Productos/ Servicios: aplicación que calcula los cargos, descuentos y bonificaciones
de un cliente.
• Política de Cuenta: funcionalidades para manejar políticas para las cuentas de los clientes con
saldos (a favor o en contra).
• Facturación: aplicación para calcular una factura única para todos los servicios que se brindan a
los clientes.
12
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Servicios
El dominio “Servicios” soporta y permite los procesos enfocados a la gestión y control de los
servicios (voz, data, servicios de contenidos) que se le brindan a un cliente,
independientemente de la tecnología sobre la cuál se implemente el servicio.
Módulos :
• Especificación de Servicios: aplicación para el almacenaje y recuperación de datos específicos
del servicio.
• Gestión de Inventarios de Servicios: aplicación que comprende :
 El mapeo de las especificaciones del producto a los especificaciones del servicio y de las
instancias del producto a los instancias del servicio;
 El mapeo del servicio a los componentes del servicio;
 La implementación del nivel de servicio del dominio de los recursos
• Gestión de Pedido de Servicios: maneja de punta a punta el ciclo de vida de una demanda de
servicio (validación de la disponibilidad del servicio, alta de demanda de servicio).
• Gestión de Problemas de Servicios: actúa como el puente entre los problemas de recursos y
los problemas que afectan al cliente (resolución de problema de cliente, análisis de causa de
problema, servicio de monitoreo de la calidad).
• Gestión de Desempeño de Servicios: aplicaciones que ayudan a monitorear los servicios
punto a punto, incluyendo la experiencia del cliente (real-time, histórico).
• Gestión de Acuerdos de Servicios: utiliza los “outputs” de la aplicación de Service Quality
Monitoring para proveer una visión del nivel de servicio entregado comparado al pre acordado.
• Análisis de Impacto y Monitoreo de Calidad de Servicios: aplicaciones diseñadas para
autorizar a los operadores a determinar el nivel de servicio están que le están entregando a un
cliente.
13
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Recursos
El dominio “Recursos” administra a todos los componentes (aplicaciones e infraestructura)
utilizados para entregar y soportar el servicio requerido o propuesto al cliente.
Módulos:
• Gestión de Procesos de Recursos: aplicaciones para el workflow de los recursos (Testing,
Cambio, WorkForce).
• Gestión de Ciclo de Vida de Recursos: aplicaciones responsables para agregar, modificar o
suprimir la capacidad de la red o de la infraestructura.
• Gestión de Pedidos de Recursos: funcionalidades que manejan el ciclo de vida de un pedido
de recursos de punta a punta (disponibilidad del recurso).
• Gestión de Cumplimiento de Recursos: grupo de aplicaciones responsable del cumplimiento
de la función de los recursos (SLA , Métricas).
• Aplicaciones de Gestión de Inventarios de Recursos: aplicaciones que manejan la
información de los recursos utilizados para implementar servicios y productos.
• Gestión de Recursos de Dominios: área de aplicación que proporciona los recursos a todos los
servicios expuestos que están disponibles a todas las otras áreas de aplicación.
• Aplicaciones de Mediación de Datos de Facturación: aplicaciones para manejar un gran
número de datos específicos para las funciones de facturación.
• Aplicaciones de Mediación de Facturación en Tiempo Real: aplicaciones para manejar datos
específicos para las funciones de facturación en tiempo real.
• Gestión de Vouchers: aplicaciones que manejan todos los aspectos de recargas de Vouchers
pre pagados.
14
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Proveedor
El dominio “Proveedor” agrupa todos las funcionalidades relacionadas con los datos y
contratos asociados a los socios y proveedores.
Módulos:
• Gestión de Cadena de Abastecimiento: aplicaciones que manejan la cadena de
abastecimiento.
• Gestión de socios: aplicaciones que permiten manejar las relaciones con los socios (operadores
de telecomunicaciones, proveedores de contenido, autoridades de regulación, etc.).
• Aplicaciones de facturación al por mayor: aplicaciones que permiten facturar todas las
capacidades de la cadena de valor con los socios (roaming, resellers, operadores de redes
virtuales de móvil, proveedores de contenido, comercio electrónico, etc.).
15
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Empresa
El dominio “Empresa” cuenta con las aplicaciones para la gestión interna de la
organización.
Módulos:
• Gestión de Aseguramiento de Ganancias: conjunto de métodos para mejorar la calidad de los
datos y los procesos que permiten reducir las pérdidas, aumentar los beneficios y la rentabilidad.
• Gestión de RRHH: aplicaciones que facilitan la gestión de todos los aspectos relacionados con
los recursos humanos.
• Gestión Financiera: aplicaciones para la gestión financiera de la Organización.
• Gestión de Activos: aplicaciones para la gestión de los activos de la Organización
• Gestión de Seguridad: aplicaciones de gestión de seguridad.
• Gestión del Conocimiento: aplicaciones de datawarehousing o BI que permite la Dirección de la
Organización consultar los datos apropiados para la toma de decisiones.
• Gestión de fraude: aplicaciones de gestión de fraude.
16
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura TAM: Integración
El dominio “Infraestructura de Integración” trata de la integración de los aplicaciones con la
infraestructura según 3 principios claves:
• La utilización de un bus común de comunicación .
• La utilización de un workflow de procesos (Business Process Management) .
• La utilización de contratos de interfaces entre las aplicaciones y un modelo común de
información compartido entre todas las aplicaciones.
17
Módulo cubierto
Módulo parcialmente cubierto
Módulo no cubierto
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura del Modelo
Mercado / Ventas
Auxiliar
de Ventas
Gestión de
Campaña
Producto
Resultados &
Compensaciones
Estrategia de Producto
/ Gestión de
propuestas
Gestión de
Catálogos de
Servicios /
Productos
Gestión de
Desempeño
del Producto
Facturación
Autogestión del Cliente
Gestión del contacto con el cliente, Retención & Lealtad
Gestión de QoS
& SLA del Cliente
Gestión de
Acuerdos
de Servicios
Servicios
Servicio al Cliente /
Resolución de
problemas de Cuenta
Rating de Productos/
Servicios
Gestión de
Problemas
de Servicio
Gestión de
Desempeño
de Servicios
Aplicaciones
de Mediación de
Datos de Facturación
Aplicaciones de Gestión de Inventarios de Recursos
Gestión de
Cumplimiento
de Recursos
Gestión de Pedidos
de Recursos
Cargo Online
Análisis de Impacto
y
Monitoreo de QoS
Gestión de Procesos de Recursos (Workflow de Integración)
Gestión de Ciclo de
Vida
de Recursos
Facturación
Formato de Facturas
Aplicaciones de
Mediación de
Facturación en
Tiempo Real
Gestión
de Vouchers
Gestión de Recursos de Dominios
Proveedor
Gestión de
Socios
Gestión de Cadena
de Abastecimiento
Business Process Management
Gestión de Pedido
de Servicios
Política de
Cuenta
Control de
Facturas
Infraestructura de Integración
Producción de
Documentos
Transaccionales
Recursos
Gestión de
Facturación
Gestión
de Cobro
Indicadores del Servicio al Cliente
Gestión de
Inventarios de
Servicios
Portal de Ventas
Aseguramiento
Gestión de
Pedidos
del Cliente
Gestión de
Información
del Cliente
Gestión de Ventas
Corporativas
Gestión de
Ciclo de Vida
de Producto
Cumplimiento
Clientes
Especificación
de Servicios
Gestión de canales
de Ventas
Bus de integración / SID /
Planeación y Alistamiento
Gestión de
Ventas Masivas
Aplicaciones de facturación
al por mayor
Empresa
Gestión de
Aseguramiento
de Ganancias
18
Módulo cubierto
Gestión de
RRHH
Módulo parcialmente cubierto
Gestión
Financiera
Módulo no cubierto
Gestión de
Activos
Gestión de
Seguridad
Gestión del
Conocimiento
Gestión de
fraude
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura Futura del Modelo
A continuación, se ve estadísticamente la cobertura del Modelo TAM Objetiva:
19
Cubierto
48
Cubierto
Parcialmente
5
No Cubierto
3
Total de Módulos
56
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura del modelo
TAM
• Modelo TAM
• Cobertura actual del
Modelo
• Listado de Aplicaciones
20
Integración
CRM 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
•
•
•
•
Mapa de Integración
Redundancia
Explotación (acceso)
Automatización de
controles.
• Documentación.
• Estructura.
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
CRM Triple Play – Aspectos Funcionales
Nivel I
Inicial
Nivel II
Regular
Nivel III
Bueno
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.
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 precompletadas).
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 Adhoc 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 AdHoc 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.
B
Facilidad de
Uso
C
Automatización
de la
Información
D
Funcionalidad
para el actual
negocio
21
Nivel V
Excelente
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.
A
Flexibilidad para
añadir nuevas
Funcionalidades
Nivel IV
Muy Bueno
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
COMENTARIO
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
CRM Triple Play – Aspectos Funcionales
Nivel I
Inicial
E
Uso de
Capacidades
F
Calidad de
Información
G
Confiabilidad
del Sistema
H
Accesibilidad
22
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
Observaciones
COMENTARIO
Hay muchas
funcionalidades que no
tienen uso y hace al
sistema muy engorroso.
Hay algunas
funcionalidades que no
tienen uso y dificultan
en cierto grado el uso
del sistema
Existen algunas
funcionalidades no
utilizadas, alguna de las
cuales dificultan el uso
del sistema
Existen algunas
funcionalidades no
utilizadas, pero no
dificultan el uso del
sistema.
El sistema es utilizado en
forma completa.
La 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 .
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Cambié
este
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Modelo Objetivo
Situación Actual
Situación Objetivo - Recomendaciones
•En varios casos se encontró que la información requerida por un
usuario para completar una tarea muy frecuente, está distribuida
en varias pantallas, lo cual obliga al usuario a tener que navegar
la aplicación para acceder a dicha información.
• Crear para las tareas más frecuentes (por ejemplo búsqueda y
visualización de datos de clientes) pantallas consolidadas que
contengan toda la información requerida por los usuarios de
manera de minimizar el tiempo que estos invierten en navegar y
realizar las tareas más comunes. (APL001)
•Varios de los datos ingresados por los usuarios carecen de
validaciones, lo tiene las siguientes desventajas:
Disminuye la calidad de la información almacenada en
el sistema, lo cual.
Dificulta la realización tareas posteriores.
• Implementar validaciones de longitud y formato. Y cuando sea
posible también implementar los algoritmos de dígito verificador
(por ejemplo para números de tarjeta , CBUs, CUITs). (APL002)
•Se detectó que ante errores la aplicación muestra mensajes
inapropiados al usuario. Asimismo cuan por alguna razón el
sistema colapsa no se el usuario se encuentra con una pantalla
poco amigable que no ofrece ningún tipo de explicación.
• Definir en el archivo de configuración de la aplicación páginas
personalizadas para cuando la aplicación no está disponible.
• Manejar las excepciones no atrapadas dentro del Global.asax,
dejando registro de la excepción y mostrando un mensaje
apropiado para usuario.
• Involucrar a los usuarios clave en la definición de los mensajes.
(APL003)
•Es conocida la falta de reportes de la aplicación
• Se recomienda la implementación de los reportes más
prioritarios. Un punto que puede ayudar a que los reportes se
hagan más rápido y fácilmente es el uso del componente
ReportViewer, incluido en Visual Studio. Este componente está
integrado con el entorno de desarrollo y permite el diseño visual
de los reportes. (APL004)
23
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
CRM Triple Play – Aspectos Técnicos
Nivel I
Inicial
B
Tiempo de
Respuesta
Esfuerzo
para
Cambios
24
Nivel IV
Muy Bueno
Nivel V
Excelente
El sistema es cerrado,
imposible añadir
interfaces.
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
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.
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.
Tiempos off-line o
problemas batch
C
frecuentes y
significativos que
Disponibilidad sobrepasan lo
del Sistema aceptable por el
negocio.
D
Nivel III
Bueno
Permite la extracción de
archivos "batch" con
programación superior a
tres días, pero no permite
interfaces en línea.
A
Facilidad de
Integración
Nivel II
Regular
El esfuerzo de
mantenimiento es alto
Es necesario un
pero se tiene suficiente
esfuerzo significativo de personal con el
desarrollo (construcción conocimiento necesario
y pruebas unitarias)
para cubrirlo, sin embargo
para el mantenimiento. la carga de trabajo hace
que el mismo no este
siempre disponible.
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
CRM Triple Play – Aspectos Técnicos
Nivel I
Inicial
E
Control y
Monitoreo
F
Dependencia
de HW y SW
G
Escalabilidad
H
Robustez
25
Nivel II
Regular
Nivel III
Bueno
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.
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.
El sistema esta
sobrecargado sin
espacio para
incrementar su
capacidad.
El sistema no es
escalable, pero las
proyecciones actuales no
exceden la capacidad
actual.
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.
Nivel de Madurez Actual
Los puntos de falla
claves son monitoreados
y acciones manuales
resuelven las mayoría de
las situaciones de falla.
Nivel IV
Muy Bueno
La mayoría del sistema es
monitoreado con algún
soporte automatizado de
falla/evento.
Nivel V
Excelente
Observaciones
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.
La aplicación es
La aplicación es
Para alcanzar un nivel
La aplicación es
altamente dependiente
dependiente de ciertos
4 en disponibilidad
independiente de la
de los estándares de
estándares fácilmente
habría que
configuración de HW/SW.
HW/SW de la industria.
salvables.
implementar planes
de contingencia. Dado
que no hay pruebas
automatizadas, ni
El sistema tiene suficiente casos de prueba
escalabilidad para cumplir documentados, cada
El sistema es escalable en el corto plazo en una
con las necesidades
cambio implica probar
dimensión (p.e. añadiendo o mejorando el HW).
futuras con una inversión manualmente todo el
de capital mínima.
sistema incurriendo en
un importante
esfuerzo que
La aplicación NO falla al Al encontrarse con
actualmente no se
La aplicación falla al
encontrase con
información faltante o en
realiza en parte por la
encontrase con
información faltante o en formato incorrecto, la
falta de personal.
información faltante o en
formato incorrecto.
aplicación intenta
Creemos que el corto
formato incorrecto,
Muestra al usuario un
corregirla y muestra al
muestra al usuario un
mensaje advirtiendo de la usuario un mensaje para plazo la incorporación
mensaje inapropiado e
imposibilidad de
que este la valide o vuelva de un área de testing
podría ayudar en este
interrumpe el flujo de
completar la operación y a ingresarla y así pueda
trabajo.
permite que el mismo
continuar con la operación punto.
continúe trabajando.
en curso.
Nivel de Madurez Objetivo
(mediano plazo)
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (ViewState)
Hallazgo
Se detectó un exceso en el uso del control ViewState de ASP.NET, el mismo perjudica la renderización de las páginas, incrementando en
gran número el tamaño del HTML enviado al navagador.
Descripción de la Recomendación
• Minimizar el uso del ViewState en las páginas, sobre todo en aquellas que contienen grillas.
Beneficios
• Esto tendrá un impacto positivo en la velocidad de renderización de las páginas, haciendo que el sistema sea mas ágil en su
navegación.
• Ayudara a reducir el tráfico dentro de la red, disminuyendo considerablemente el peso de las páginas.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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/]
2626
26
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (AJAX)
Hallazgo
Fue detectado un uso indebido del Framework AJAX de ASP.NET, sobre todo una práctica en particular que es la colocación del control
UpdatePanel en la MasterPage, reduciendo esto, las ventajas del modelo AJAX, haciendo que la todos los controles en la página sean
actualizados innecesariamente.
Descripción de la Recomendación
• Quitar el UpdatePanel de la MasterPage e identificar individualmente en cada página los sectores que deben ser actualizados de forma
asíncrona, y colocar un UpdatePanel en cada caso, reduciendo así la cantidad de controles a actualizar en las llamadas AJAX.
• Evaluar en algunos casos la necesidad de agregar código Javascript para ayudar al funcionamiento del Framework y hacer más
dinámica la renderización del HTML.
• Evaluar la utilización de otros componentes JavaScript como: Yahoo User Interface, Scriptaculous y JQuery.
Beneficios
• Esto tendrá un impacto positivo en la velocidad de renderización de las páginas, haciendo que la aplicación resulte más ágil para el
usuario.
• Ayudará a reducir el tráfico entre el navegador y el servidor de presentación.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://msdn.microsoft.com/en-us/magazine/cc163413.aspx
2727
27
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (Session)
Hallazgo
Es común la utilización del objeto Session para almacenar información relacionada al caso de uso en curso, pero en ocasiones esta
información no es liberada después de ser utilizada, lo cual genera un gasto innecesario de memoria.
Descripción de la Recomendación
• Limpiar de la sesión la información almacenada temporalmente apenas esta deja de ser útil.
Beneficios
• Mejor uso de los recursos de memoria del servidor de presentación.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://msdn.microsoft.com/en-us/magazine/cc163413.aspx
2828
28
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (cssfriendly)
Hallazgo
Descripción de la Recomendación
• La utilización de los CSS Friendly controls modifica la renderización de los controles ASP.NET, generando HTML más claro y
conveniente para la aplicación de estilos CSS.
Beneficios
• Páginas más livianas.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://www.codeplex.com/cssfriendly
2929
29
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (navegación)
Hallazgo
Se detectó el uso de la instrucción Response.Redirect para manejar el flujo de navegación entre pantallas, lo obliga a realizar un postback
adicional.
Descripción de la Recomendación
• Reemplazar todos las apariciones de Response.Redirect con Server.Transfer.
Beneficios
• Reducción de Round-Trips al servidor
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Response.Redirect vs Server.Transfer[http://haacked.com/archive/2004/10/06/responseredirectverseservertransfer.aspx]
3030
30
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para capa de presentación (async)
Hallazgo
La capa de presentación consume toda la lógica en forma remota de la capa de negocio via web services haciendo invocaciones
sincrónicas, no importa cuan compleja sea la operación a ejecutar.
Descripción de la Recomendación
• Para los casos de operaciones complejas considerar el uso de llamadas asincrónica.
Beneficios
• Mejora en la percepción del usuario.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://www.stardeveloper.com/articles/display.html?article=2001121901&page=1
3131
31
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para la capa de servicios (sin estado)
Hallazgo
La sesión se encuentra activada en la capa de servicios, lo cual es innecesario pues la misma se está utilizando en forma stateless, tal cual
recomiendan las prácticas de SOA.
Descripción de la Recomendación
• Desactivar en ASP.NET la sesión, puesto que los servicios no deberían hacer uso de la misma.
Beneficios
• Disminuirá el consumo de memoria.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Improving .NET Application Performance and Scalability, Capítulo 3, ISBN: 0735618518, http://www.amazon.com/ImprovingApplication-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue
siendo válido.
3232
32
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para la capa de servicios (DataSets)
Hallazgo
Toda la capa de servicios utiliza como transporte DataSets, lo cual dificulta la interoperabilidad y requiere de procesamiento adicional
debido a la forma en que los mismos son serializados.
Descripción de la Recomendación
• Reemplazar el uso de DataSets por objetos planos.
Beneficios
• Permitirá que los servicios sean consumidos desde otras plataformas y mejorará (de manera imperceptible) el desempeño de la
aplicación.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1048679,00.html
3333
33
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para la capa de servicios (WCF)
Hallazgo
Para la implementación de la capa de servicios se utilizó una tecnología actualmente considerada en desuso dentro del ambiente .Net
(asmx), la cual limita solo a Web Services el protocolo de comunicación y formato de mensajes.
Descripción de la Recomendación
• Migrar los servicios a WCF, lo cual obligará a una explícita separación entre interface e implementación.
Beneficios
• La adopción de WCF dará una mayor flexibilidad a la hora de hacer cambios o correciones. El sistema dejará de tener una limitación
tecnológica en el caso de querer migrar a otros protocolos de transporte para mejorar algunos aspectos de la comunicación.
Prerrequisitos
Sacar los DataSets de la capa de
presentación.
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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-yourexisting-asmx-services.aspx]
3434
34
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para la capa de acceso a datos (paginación)
Hallazgo
Detectamos que la aplicación carece de una política de paginación a nivel Acceso a datos. Algunas páginas con grillas paginadas no traen
sólo los datos a mostrar, si no que todo el conjunto de información, y luego muestran la página correspondiente. Esto carga la red de datos
innecesarios y por lo tanto impacta negativamente en la performance de la aplicación.
Descripción de la Recomendación
• Paginar las consultas que devuelven gran cantidad de resultados directamente desde NHibernate.
Beneficios
• Esto tendrá un impacto en la performance de la aplicación. Disminuyendo el tráfico de la misma.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
3535
35
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para la capa de acceso a datos (config)
Hallazgo
Hay algunos seteos en la configuración de Hibernate que podrían optimizarse
Descripción de la Recomendación
• Ajustar la configuración de los siguientes parámetros:
•
ShowSql = false
•
Analizar utilizar Lazy Loading en las asociaciones (archivos de mapeo)
Beneficios
• Esto tendrá un impacto en la performance de la aplicación.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Understanding Lazy Loading Strategies for NHibernate [http://blogs.chayachronicles.com/sonofnun/archive/2007/03/30/230.aspx]
3636
36
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Recomendaciones al nivel general
A continuación, detallamos recomendaciones tratando de los temas de :
Tienen para objetivo de mejorar :
-
Slide a hacer por Snoop el
Lunes
-
3737
37
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones generales (excepciones)
Hallazgo
Como resultado del relevamiento realizado en el código fuente, detectamos un pobre manejo de excepciones, en algunos casos la falta de
logging del error, solo se atrapan excepciones genéricas, en otros se lanza una nueva excepción perdiendo el stack de errores previo, etc.
Descripción de la Recomendación
• Definir una política uniforme para el manejo de excepciones a partir de identificar las zonas más críticas del sistema e ir aplicando
políticas de captura, registro, propagación y notificación de excepciones, creando así, por un lado, una serie de Custom Exceptions que
implementen excepciones a reglas de negocio (heredando de ApplicationException) y por el otro, identificar las posibles excepciones
técnicas que se pueden generar en estas partes del código.
En ambos casos lanzar las excepciones sin perder el stack, con un mensaje más “user friendly” y loggear previamente las mismas.
Beneficios
• Esto tendrá un impacto positivo en la robustez del sistema, teniendo el usuario una percepción mas segura del sistema y un informe de
los errores más amigable.
• Ayudará a facilitar la identificación de las causantes de bugs inesperados, mediante el log de excepciones.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Cam
est
Referencia
• Exception Handling (MSDN) [http://msdn.microsoft.com/en-us/library/ms229005.aspx]
• Throwing Exceptions in C# [http://www.blackwasp.co.uk/CSharpThrowingExceptions.aspx]
3838
38
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones generales (caché)
Hallazgo
Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación.
Descripción de la Recomendación
• Agregar prácticas de Cache, tanto en la capa de presentación, como en la capa de Datos (NHibernate)
• Utilización del Caché de ASP.NET, evaluar el uso de algún Framework de Caché como por ejemplo NCache o CachingApplication
Block.
Beneficios
• Esto tendrá un impacto positivo en la performance del sistema, mejorando los tiempos de respuesta del mismo
• Ayudará a disminuír el tráfico de la red.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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]
3939
39
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones generales (codificación)
Hallazgo
Se detectaron malas prácticas en la codificación, algunas referentes a C sharp y otras a generalidades de .Net.
Descripción de la Recomendación
• Actualizar y respetar las convenciones ya definidas . Utilizar herramientas como StyleCop y FxCop para automatizar la verificación del
cumplimiento de dichas prácticas.
Beneficios
• Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Microsoft FxCop [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx]
• Microsoft StyleCop [http://code.msdn.microsoft.com/sourceanalysis]
4040
40
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones generales (instrumentación)
Hallazgo
Se detectó una pobre instrumentación de la aplicación en todas las capas. Reduciendo la posibilidad de controlar las eventualidades que
puedan ocurrir en el ambiente productivo.
Descripción de la Recomendación
• Instrumentar la aplicación en sus diferentes capas considerando:
•
Instrumentación del Pipeline de ejecución
•
Contadores de performance
•
Escribir en el Event Log
•
uso de librería de logging (Archivos de texto, base de datos)
•
Monitoreo
Beneficios
• Esto tendrá un leve impacto en la robustez de la aplicación. Ayudará a tener un mayor visibilidad del comportamiento de la aplicación
frente a posibles errores en el ambiente de producción y facilitará el diagnostico de problemas.
Prerrequisitos
Ninguno
Beneficio
Plazo
Impacto
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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
4141
41
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones generales (liberación de recursos)
Hallazgo
Se detectaron que varios de los objetos de la solución son volátiles y hacen uso de recursos no manejados, pero a pesar de eso no son
liberados instantáneamente.
Descripción de la Recomendación
• Implementar IDisposable en las clases mencionadas anteriormente.
Beneficios
• Esto permitirá hacer un uso más optimo de la memoria ya que los recursos se liberarán apenas dejen de ser utilizados.
Prerrequisitos
Ninguno
Beneficio
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Bajo
Largo
Baja
Mantenibilidad
Referencia
Impacto
Cambio
esto
• 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]
4242
42
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (PK)
Hallazgo
Se detectó gran cantidad de tablas con PK que no tienen índices asociados.
Descripción de la Recomendación
• Analizar el modelo y en caso que dichas tablas se accedan con alguna consulta identificar las pasibles PK y crearlas
Beneficios
• Los planes de ejecución para dichas tablas pueden mejorar notablemente beneficiando los tiempos de resolucion de dichas consultas.
• Tambien se estaria cumpliendo con la 3ra condicion de la 1NF (1ra forma normal)
Prerrequisitos
Ninguno
Beneficio
Impacto
Cam
es
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Oracle Tunning, Donald Burleson, ISBN: 0-9744486-2-1
• http://es.wikipedia.org/wiki/1NF
4343
43
©2008 Deloitte Todos los derechos reservados.
Esto es relevante en cuanto a performance ya que al mantener las estadisticas
actualizadas el optimizador puede seleccionar el plan de ejecución mas adecuado.
Frente Aplicaciones
Recomendaciones Capa de Datos (indices)
Hallazgo
Se detectó estadísticas de tablas e índices con mas de 3 meses de realizadas.
Descripción de la Recomendación
• En caso de no tener habilitado el job automático de recolección de estadísticas analizar los movimientos de esas tablas y ejecutar la
actualización de manera manual (con un scheduler)
Beneficios
• Esto es relevante en cuanto a performance ya que al mantener las estadisticas actualizadas el optimizador puede seleccionar el plan de
ejecución mas adecuado.
Prerrequisitos
Ninguno
Beneficio
Impacto
Cam
es
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#sthref1068
4444
44
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (extends)
Hallazgo
Se detectaron objetos (tablas e índices) con alta cantidad de extents.
Descripción de la Recomendación
•
•
•
Para segmentos mayores a 5G se recomienda utilizar un tablespace con manejo de extents en UNIFORM SIZE con extents de
64MB o superiores.
Esto aplica tanto para tablas como para índices.
Los pasos serian:
1.
Crear tablespaces de datos e índices con las características mencionadas arriba
2.
Identificar los segmentos candidatos y recrearlos en dichos tablespaces
Beneficios
• Esto beneficia a la velocidad de acceso a los datos para los full scan ya que los bloques estaran en forma contigua.
Cam
es
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Oracle Tunning, Donald Burleson, ISBN: 0-9744486-2-1
4545
45
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (executeparse)
Hallazgo
Se detectó bajo valor de Execute to Parse.
Descripción de la Recomendación
La solución a este problema es la utilización de bind variables en la construcción de los Querys.
Beneficios
• Con esto evitamos la etapa de parseo que es una de las mas costosas al momento de la ejecución de la consulta. Durante esta etapa se
verifican la sintaxis y derecho de acceso a los objetos etc.
Prerrequisitos
Ninguno
Beneficio
Impacto
Cam
es
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://www.oracle.com/technology/deploy/performance/pdf/cursor.pdf
4646
46
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (full scans)
Hallazgo
Alta cantidad de full scan en tablas pequeñas.
Descripción de la Recomendación
Para las tablas de poco tamaño que son accedidas frecuentemente es recomendable configurar la SGA para la utilización del "keep buffer
pool" esta region de memoria se utiliza para mantener objetos en el buffer cache. El parametro a modificar es el
"buffer_pool_keep", se calcula como el total de memoria que necesitan las tablas candidatas para almacenarse en memoria.
Para determinar las tablas mas accedidas se pueden usar varias fuentes.
1) Estadisticas a nivel de AWR
2) Habilitar la auditoria a nivel de base para saber que tablas fueron mas consultadas.
Beneficios
• Con esto evitamos que los segmentos mas accedidos sean leidos continuamente de disco, ya que al estar en el "buffer pool keep" se
mantendran los bloques en la SGA.
Prerrequisitos
Ninguno
Beneficio
Impacto
Cam
es
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref463
• Metalink : Oracle Multiple Buffer Pools Feature Note:135223.1
4747
47
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (cache waits)
Hallazgo
Fue detectado un alto valor de library cache waits.
Descripción de la Recomendación
•
El procedure keep del package dbms_shared_pool hace que el package pasado como parámetro sea cargado en memoria (Shared
Pool) y no sea considerado "viejo" para sacarlo de la memoria.
Beneficios
• Es muy útil para grandes objetos que son usados frecuentemente, puede bajar considerable los tiempos de espera de library cache.
Cam
es
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_shpool.htm#sthref5952
4848
48
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (optimizador)
Hallazgo
Falta de ajuste en el optimizador de costos de indices
Descripción de la Recomendación
• Es aconsejable que se hagan pruebas de performance con los parámetros de optimización de índices con los siguientes valores:
•
optimizer_index_cost_adj=1
•
optimizer_index_caching=100
•
OPTIMIZER_INDEX_COST_ADJ : Es para tunear el comportamiento default del optimizador haciéndolo mas o menos
propenso a la selección de un índice sobre un full scan.
•
OPTIMIZER_INDEX_CACHING : Nos permite ajustar el comportamiento default del CBO favoreciendo los nested loop y las
comparaciones con cláusulas IN.
Gran numero de chained/migrated rows
Beneficios
• Estos parametros modifican el comportamiento del optimizador para que favorezca la utilización de indices sobre los full scan, ,con esto
podemos reducir el costo total de los planes de ejecución, mas precisamente sobre aquellas consultas con full scan.
Prerrequisitos
Ninguno
Beneficio
Impacto
Cam
es
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://www.dba-oracle.com/oracle_tips_cost_adj.htm
4949
49
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones Capa de Datos (chained/migrated)
Hallazgo
Se detectó gran numero de chained/migrated rows
Descripción de la Recomendación
• Esto indica que hay registros que no entran completamente en un bloque (chained row), y por consiguiente el registro esta ditribuido en
dos o mas bloques lo que hace que se deba hacer mas de una lectura fisica para leer dicho registro.
• Tambien puede indicar la existencia de migrated rows (registros que al ser actualizados se tuvieron que mover de bloque).
• Para verificar la existencia de las tablas con chained row se puede ejecutar el siguiente query.
•
select * from dba_tables where chain_cnt > 0;
• En caso de existir tablas con chained rows analizar la creación de tablespaces con blocksize acorde con el tamaño del registro.
• Tambien se sugiere implementar periódicamente las recomendaciones de mantenimiento de segmentos según al Advisor por default de
Oracle, de esta manera reorganizando los segmentos que estan mas fragmentados se puede solucionar los problemas con las migrated
rows.
• Para ver las recomendaciones se puede acceder via el EM web o bien ejecutar el siguiente query:
•
select * from table(dbms_space.asa_recommendations('FALSE', 'FALSE', 'FALSE')) order by reclaimable_space desc
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.
Beneficio
Prerrequisitos
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Ninguno
Cam
es
Referencia
• Metalink : Row Chaining and Row Migration Note:122020.1
5050
50
©2008 Deloitte Todos los derechos reservados.
Esto va en infraestrctura
Frente Infraestructura
Recomendación para IIS (reciclado de proceso)
Hallazgo
Se detectó que la configuración de reciclado de procesos podría ser mejorada a partir de los cambios propuestos a nivel de aplicación.
Si bien el reciclado de proceso no produce la pérdida de la sesión del usuario, si se pierde la información almacenada en la sesión del
usuario, lo cual puede ser la causa de algunos errores reportados por los usuarios.
Descripción de la Recomendación
• El reciclado de procesos está pensado para ser utilizado en el caso de aplicaciones que tienen “memory leaks”, (típicamente
aplicaciones COM). Si bien en .NET estas situaciones son mucho menos frecuentes (ya que la memoria es administrada por el runtime
de .NET a través del recolector de basura) puede que resulte necesario reciclar el proceso esporádicamente.
• Si bien no existe la posibilidad de definir un valor único de los parámetros de reciclado, (pues los mismos dependen de cada
aplicación.), se recomienda realizar pruebas para lograr ajustar dicho parámetro para la aplicación en cuestión.
• Se recomienda probar estableciendo el límite de memoria para cada proceso en un valor inicial de 1,5 GB.
Beneficios
• A partir de esto puede que las situaciones abruptas de finalización de sesión sean mucho más esporádicas.
Cam
es
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Medio
Mediano
Mantenibilidad
Bajo
Largo
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
5151
51
©2008 Deloitte Todos los derechos reservados.
Esto va en infraestrctura
Frente Infraestructura
Recomendación para Asp.Net (sesion)
Hallazgo
A pesar de tener implementado balanceo de carga en la capa física de presentación se está utilizando modo de sesión inprocess. Esto
hace que cuando se recicla el proceso los usuarios pierdan la información de sesión experimentando interrupciones en su trabajo.
Descripción de la Recomendación
• Implementar un modo de sesión independiente del proceso .
Beneficios
• Esto evitará que los usuarios sufran las mencionadas interrupciones.
Cam
es
Prerrequisitos
Dependiendo de la estrategia elegida,
puede ser necesario adquirir hardware
adicional.
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Medio
Mediano
Mantenibilidad
Bajo
Largo
Referencia
• Improving .NET Application Performance and Scalability, ISBN: 0735618518, http://www.amazon.com/Improving-ApplicationPerformance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue siendo válido.
5252
52
©2008 Deloitte Todos los derechos reservados.
Esto va en infraestrctura
Frente Infraestructura
Recomendación para Asp.Net (System.Net)
Hallazgo
Los servidores de aplicaciones tiene la configuración estándar para el máximo valor de conexiones salientes (dicho valor es 2). Este valor
es apropiado para aplicaciones desktop que consumen servicios, pero en el caso de aplicaciones Asp.Net dicho valor extremadamente
bajo.
Descripción de la Recomendación
• Modificar el parámetro en cuestión en la configuración de la
aplicación tal como se muestra a continuación.
<system.net>
<connectionManagement>
<add address="[webservice-ip]" maxconnection="100" />
</connectionManagement>
</system.net>
Beneficios
• Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware.
Cam
es
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Medio
Mediano
Mantenibilidad
Bajo
Largo
Referencia
• Improving .NET Application Performance and Scalability, Capítulo 17, ISBN: 0735618518, http://www.amazon.com/ImprovingApplication-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue
siendo válido.
5353
53
©2008 Deloitte Todos los derechos reservados.
Esto va en infraestrctura
Frente Infraestructura
Recomendación para Asp.Net (process model)
Hallazgo
Los servidores de aplicaciones tiene la configuración estándar del processModel de Asp.Net, ciertos paràmetros no vienen con los valores
más adecuados.
Descripción de la Recomendación
• Ajustar los siguientes parámetros de configuración del
processModel de Asp.Net.
• En particular los últimos dos parámetros es realizar pruebas para
lograr dar con los valores apropiados.
<processModel
memoryLimit="80"
maxWorkerThreads="100"
maxIoThreads="100"
minWorkerThreads="40"
minIoThreads="30" >
Beneficios
• Esto impacta directamente en el desempeño de la aplicación y en el uso que se hace de los recursos de hardware.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Medio
Mediano
Mantenibilidad
Bajo
Largo
Referencia
• Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: 0735618518, http://www.amazon.com/ImprovingApplication-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue
siendo válido.
5454
54
©2008 Deloitte Todos los derechos reservados.
Esto va en infraestrctura
Frente Infraestructura
Recomendación para Asp.Net (pipeline de ejecución)
Hallazgo
Los servidores de aplicaciones tiene la configuración estándar del pipeline de ejecución de Asp.Net. Pero dado que la aplicación no hace
uso de todos los módulos del pipeline, podrían removerlos los módulos no utilizados para así disminuir el costo de procesamiento de
pedidos.
Descripción de la Recomendación
• Removerlos del pipeline de ejecución de Asp.Net los módulos no
utilizados . En principio podrían removerse los módulos de
autenticación Windows y Passport. Esto se hace en el archivo de
configuración de cada aplicación de la forma que se muestra a
continuación. (Web.config).
<httpModules>
<remove name=“nombreDelModulo“/>
<remove name="WindowsAuthentication" />
<remove name="PassportAuthentication" />
</httpModules>
Beneficios
• Esto disminuiría el costo de procesamiento de los pedidos procesados por Asp.Net. Si bien esto es una mejora en la performance de la
aplicación, la misma resulta casi imperceptible para el usuario.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Medio
Mediano
Mantenibilidad
Bajo
Largo
Referencia
• Improving .NET Application Performance and Scalability, Capítulo 6, ISBN: 0735618518, http://www.amazon.com/ImprovingApplication-Performance-Scalability-Practices/dp/0735618518. Si bien esta publicación es del año 2004, este tema en particular sigue
siendo válido.
5555
55
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para proceso de desarrollo (definición)
Hallazgo
El proceso de desarrollo utilizado es particular de Telecentro y es totalmente informal, no existe documentación del mismo y si bien se lo va
ajustando según las necesidades del momento, no existe ninguna formalización del proceso. Esto hace que ante la incorporación de
nuevos recursos deba invertirse tiempo de recursos para informar sobre la forma de trabajo.
Descripción de la Recomendación
• Definir formalmente, aunque sea a alto nivel, el procesos de desarrollo utilizado, documentarlo y comunicarlo a todo el equipo.
• A la hora de ajustar el procesos, plantear los cambios formalmente, ajustar la documentación y comunicar a todo el equipo los ajustes
realizados.
Beneficios
• Menor tiempo de inducción a los recursos.
• Tener un proceso por mínimo que sea permitirá la posterior definición de métricas para poder medir y mejorar tanto el procesos como el
desempeño del equipo.
Prerrequisitos
Ninguno
Referencia
5656
56
Beneficio
Plazo
Impacto
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Ver como ajustar
esto
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para proceso de desarrollo (colaboración)
Hallazgo
Descripción de la Recomendación
Independientemente de la implementación formal de un proceso de desarrollo, se recomienda el uso de herramientas colaborativas
(wiki)que permitan centralizar y dejar por escrito todo el conocimiento de la aplicación, tanto por parte de los usuarios como de equipo de
desarrollo.
Beneficios
• Centralización y distribución de la información.
• Posibilidad de acceso global.
Prerrequisitos
Ninguno
Referencia
5757
57
Beneficio
Plazo
Impacto
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Ver como ajustar
esto
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación para proceso de desarrollo (test)
Hallazgo
Actualmente no hay pruebas automatizadas de la aplicación
Descripción de la Recomendación
Para poder realizar pruebas automatizadas de la aplicación se recomienda el uso de las siguientes herramientas:
•Nunit: pruebas unitarias de clases
•SOAP UI: pruebas unitarias y de stress de web services
•Application Center Test: pruebas de stress de aplicación web
•FIT: pruebas funcionales de aceptación de usuario
Beneficios
• Disminución de los costos de test.
Prerrequisitos
Ninguno
Referencia
5858
58
Beneficio
Plazo
Impacto
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Ver como ajustar
esto
©2008 Deloitte Todos los derechos reservados.
Esta repetida
Frente Aplicaciones
Recomendaciones generales (caché)
Hallazgo
Se detectó una ausencia total del uso de Caché, en todas las capas de la aplicación.
Descripción de la Recomendación
• Agregar prácticas de Cache, tanto en la capa de presentación, como en la capa de Datos (NHibernate)
• Utilización del Caché de ASP.NET, evaluar el uso de algún Framework de Caché como por ejemplo NCache o CachingApplication
Block.
Beneficios
• Esto tendrá un impacto positivo en la performance del sistema, mejorando los tiempos de respuesta del mismo
• Ayudará a disminuír el tráfico de la red.
Prerrequisitos
Analizar las distintas alternativas de
implementación (¿En que capa? y
¿Con que componente?)
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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]
5959
59
©2008 Deloitte Todos los derechos reservados.
Esta repetida
Frente Aplicaciones
Recomendaciones generales (liberación de recursos)
Hallazgo
Se detectaron procesos donde se utilizan recursos del servidor y al terminar no se liberan correctamente.
Descripción de la Recomendación
• Verificar los procesos donde existe mayor utilización de los recursos del servidor.
• Implementar IDisposable en las clases detectadas anteriormente.
Beneficios
Idem a Capa de
Presentación
(Sección)
• Ejecutar esta recomendación impactará en la performance de la aplicación. Optimizando los recursos del IIS, particularmente el manejo
de memoria.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
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]
6060
60
©2008 Deloitte Todos los derechos reservados.
Esta repetida
Frente Aplicaciones
Recomendaciones generales (excepciones)
Hallazgo
Como resultado del relevamiento realizado en el código fuente, detectamos un pobre manejo de excepciones, en algunos casos la falta de
logging del error, solo se atrapan excepciones genéricas, en otros se lanza una nueva excepción perdiendo el stack de errores previo, etc.
Descripción de la Recomendación
• Definir una política uniforme para el manejo de excepciones a partir de identificar las zonas más críticas del sistema e ir aplicando
políticas de captura, registro, propagación y notificación de excepciones, creando así, por un lado, una serie de Custom Exceptions que
implementen excepciones a reglas de negocio (heredando de ApplicationException) y por el otro, identificar las posibles excepciones
técnicas que se pueden generar en estas partes del código.
En ambos casos lanzar las excepciones sin perder el stack, con un mensaje más amigable (user friendly) y loggear previamente las
mismas.
Beneficios
• Esto tendrá un impacto positivo en la robustez del sistema, teniendo el usuario una percepción mas segura del sistema y un informe de
los errores más amigable.
• Ayudará a facilitar la identificación de las causantes de bugs inesperados, mediante el log de excepciones.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Exception Handling (MSDN) [http://msdn.microsoft.com/en-us/library/ms229005.aspx]
• Throwing Exceptions in C# [http://www.blackwasp.co.uk/CSharpThrowingExceptions.aspx]
6161
61
©2008 Deloitte Todos los derechos reservados.
Esta repetida
Frente Aplicaciones
Recomendaciones generales (codificación)
Hallazgo
Se detectaron malas prácticas en la codificación, algunas referentes a C sharp y otras a generalidades de .Net. (Ver mayor detalle en
entregable Fase I)
Descripción de la Recomendación
• Actualizar y respetar las convenciones ya definidas . Utilizar herramientas como StyleCop y FxCop para automatizar la verificación del
cumplimiento de dichas prácticas.
Beneficios
• Ayudará a mejorar las prácticas de programación del equipo y por consiguiente la legibilidad y mantenibilidad del código.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• Microsoft FxCop [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx]
• Microsoft StyleCop [http://code.msdn.microsoft.com/sourceanalysis]
6262
62
©2008 Deloitte Todos los derechos reservados.
Esta repetida
Frente Aplicaciones
Recomendación para proceso de desarrollo (definición)
Hallazgo
El proceso de desarrollo utilizado es particular de Telecentro y es totalmente informal, no existe documentación del mismo y si bien se lo va
ajustando según las necesidades del momento, no existe ninguna formalización del proceso. Esto hace que ante la incorporación de
nuevos recursos deba invertirse tiempo de recursos para informar sobre la forma de trabajo.
Descripción de la Recomendación
• Definir formalmente, aunque sea a alto nivel, el procesos de desarrollo utilizado, documentarlo y comunicarlo a todo el equipo.
• A la hora de ajustar el procesos, plantear los cambios formalmente, ajustar la documentación y comunicar a todo el equipo los ajustes
realizados.
Beneficios
• Menor tiempo de inducción a los recursos.
• Tener un proceso por mínimo que sea permitirá la posterior definición de métricas para poder medir y mejorar tanto el procesos como el
desempeño del equipo.
Prerrequisitos
Ninguno
Volver a verificar
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
6363
63
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Metodologías de Desarrollo
Una metodología de desarrollo debe tener como mínimo
las siguientes grandes actividades:
• Estudio del negocio: Entendiendo las
necesidades del negocio.
• Requerimientos: Trasladando las
necesidades del negocio a un sistema
automatizado.
• Análisis y Diseño: Trasladando los
requerimientos dentro de la arquitectura de
software.
• Implementación: Creando software que se
ajuste a la arquitectura y que tenga el
comportamiento deseado.
• Pruebas: Asegurándose que el
comportamiento requerido es el correcto y
que todo lo solicitado está presente.
También deben incluirse actividades de soporte como
son: Configuración y administración del cambio,
Administrando el proyecto, Administrando el ambiente de
desarrollo, Administración de la salida del proyecto.
En todas las actividades el usuario debe participar y
validar el resultado de cada fase
64
Algunos ejemplos de metodologías que pueden
utilizarse dependiendo del proyecto que se va a iniciar.
Rational Unified
Process (RUP)
Extreme Programing
(XP)
Microsoft Solution
Framework (MSF)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Calidad de Datos - Introducción
Llamamos depuración de datos (data cleansing) al conjunto de acciones realizadas para
asegurar que la información de los sistemas sea correcta y exacta.
Estas acciones pueden ser realizadas por:
• Un equipo de personas que verifiquen los campos y registros de las bases de datos, y
verifiquen su exactitud y coherencia.
• Programas, los cuales verifican los datos a través de una variedad de reglas y
procedimientos configurados por el usuario.
Existe una variedad de errores que se pueden encontrar en un sistema. El siguiente cuadro
ejemplifica alguno de ellos:
Tipo de error
65
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.
Frente Arquitectura Aplicativa
Recomendación XXX
Particularidad
Se evidenció desconfianza por parte de los usuarios en cuanto a la integridad de los datos almacenados en el CRM Triple Play, por lo
tanto muchos de los usuarios continúan utilizando el antiguo Sistema FOX para validar cierta información.
Descripción de la Recomendación
• Realizar un proceso de depuración de datos para eliminar registros erróneos que generen problemas con las aplicaciones.
Beneficios
• Mejorar la calidad de información en los distintos sistemas y evitar la ocurrencia de errores por problemas con la información de las
bases de datos.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
•Ninguno
Largo
Referencia
• http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?tok=1211574194219&nid=33043
• http://www.ibermatica.com/ibermatica/eventos/2004/mtbi
66
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Recomendación Documentación
Recomendación sobre como
hacer una documentación si se
necesita – mande el mail a Snoop
67
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Estándares de Documentación - Lineamientos
Identificar
Enfoques según
Roles
Para cada uno de los roles del área de TI, habrá diferentes necesidades de información, por lo
tanto se requieren distintos enfoques en la documentación:
Gerencia de Sistemas: objetivos de negocio; capacidades y limitaciones en los servicios de TI.
Arquitecto: capacidades y limitaciones en la arquitectura; plan para expandir sus capacidades;
especificaciones de sus estándares; soporte para la decisión.
Programadores: código; comentarios; relación entre módulos.
Diseñar en base a
su Utilidad
Pensar en la utilidad que le va a dar cada rol a la documentación, y diseñar en base a esto. Para
asegurar la calidad del diseño, se pueden plantear pruebas de escenarios con los diferentes roles,
suponiendo diferentes situaciones y necesidades de información.
Un punto importante a tener en cuenta, es la precisión de la información, ya que cuanto mayor es el
volumen, más difícil el diseño y la navegación.
Crear y ejecutar
Plan de
Comunicación
Generar la documentación de TI conlleva un alto costo en tiempo y recursos, y muchas veces este
trabajo no es bien “vendido” al resto de la organización.
Por lo tanto es importante crear y ejecutar un plan de comunicación, ya que el éxito de una
iniciativa de documentación, depende del grado de uso que se le dé a la misma.
Actualizar
documentación
El mantenimiento de la documentación debe ser un proceso continuo, ya que es imperativo que la
misma refleje la situación real y actual del área de TI.
6868
68
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Estándares de Documentación
Como hemos identificado en la evaluación, existe una importante carencia en la documentación de las
aplicaciones y su modelo de datos, con las desventajas y riesgos que esto implica.
Para soportar cualquier iniciativa futura que implique cambios en la arquitectura aplicativa (nuevos
requerimientos, nuevas interfaces, migraciones), será necesario actualizar la documentación existente y
mantenerla de forma periódica.
A continuación, presentamos los elementos claves que debe contener la documentación para que
agregue valor (y no caiga en desuso), y los lineamientos a seguir para lograr este objetivo:
Diseño
Precisión
Enfoque
Comunicación
Elementos Claves
Roles
Actualización
Valor Agregado
6969
69
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura del modelo
TAM
• Modelo TAM
• Cobertura actual del
Modelo
• Listado de Aplicaciones
70
Integración
CRM 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
•
•
•
•
Mapa de Integración
Redundancia
Explotación (acceso)
Automatización de
controles.
• Documentación.
• Estructura.
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Integración- Tendencias
Principales Preocupaciones en TI
La definición de estándares y principios guía (gobierno) de arquitectura aplicativa
aparecen como unas de las principales preocupaciones de los Gerentes de
Sistemas (CIO) en la actualidad:
¿Cuáles son las tres (3) principales preocupaciones de los CIO’s?
Costo
Aplicación
Arquitectura
Des arrollo
4
Operac iones
4
Trans parenc ia
4
Planeac ión es trategic a
4
Renovac ión
3
Complejidad
1
Es tandares
1
G overnanc ia
1
Bas ilea II, Ries go Operac ional
Otros
3
Flujo de Trabajo
Plataforma Window s
2
1
A continuación, desarrollamos algunos de los principios guía de arquitectura
aplicativa anteriormente mencionados:
71 71
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Integración - Introducción
• La integración es un concepto que permite utilizar los activos tecnológicos,
estándares y recursos, con el fin de resolver requerimientos de integración y
crear soluciones efectivas
• Para que esto sea posible, es indispensable contar con una arquitectura flexible
y que permita una ágil integración con sistemas tanto internos como externos de
la Organización.
• La velocidad de cambio llevó a las compañías de telecomunicaciones a cubrir
las necesidades de integración de manera poco planificada, derivando en
arquitecturas de integración complejas, donde no se tiene muy en claro las
relaciones y controles existentes entre las aplicaciones.
• Según lo contemplado en el diagnóstico realizado en la Fase I, Telecentro no
escapa a esta realidad, contando con un mapa de integración complejo
(topología punto a punto), con una cantidad significativa de interfaces manuales
y escasos procesos de control y automatización.
72
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Integración - Introducción
• Los mapas de integración punto a punto son más difíciles de reutilizar, mantener,
controlar y automatizar.
• Las interfaces automatizadas y centralizadas mediante alguna tecnología, resulta en
mapas de integración más eficientes y fáciles de mantener.
Siebel
400
350
SAP
No. de
Interfaces
Topología
Punto a Punto
300
Core
250
200
150
100
50
Internet
0
1
2
3
4
5
6
7
8
People
Soft
App.
B
9 10 11 12 13 14 15 16 17 18 19 20
No. de Aplicaciones
400
App.
C
350
No. de
Interfaces
300
Topología
con Middleware
250
200
150
100
50
App.
A
App.
D
App.
E
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19
No. de Aplicaciones
73
©2008 Deloitte Todos los derechos reservados.
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.
7474
74
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Mapa de Integración (Mediano Plazo – 6 a 18 meses)
A continuación presentamos el mapa de integración de los distintos aplicativos:
•Red de Telefonía
•Red de Telefonía
Nuevo sistema
telefonía post
pago
Agentes
Recaudadores
•Pago Fácil
•RapiPago
•Bapropagos
•Bancos Recaudación
Tarjetas por
DAT/Pago
directo
CDRs
Activaciones /
Desactivaciones/
Pagos
Resultado
Débito/
Cargos
Comisionables
A
Debitar
CPP
•Movistar
•Claro
•Personal
•Nextel
Entes
Externos
Valorizador
Consumos
CPP
CDRs
-Archivos de
Contabilidad
-Consumo de
materiales
-Facturación
Disponibilidad
de Materiales
Clientes
CRM Triple
Play
Estado del
Servicio
Sistema
Clientes
Corporativos
Activaciones /
Desactivaciones
Liquidaciones
Estado del
Servicio
CARENA
Prebilling y
Billing
Información
Facturación
DAC 6000
•Red de CATV
Reporting
Activaciones /
Desactivaciones
INTRAWAY
•Red de Banda Ancha
75
Oracle
Financials
FOX
Altas y
Bajas
IPUNITY
•Casilla de Mensajes
Nuevos
sistemas
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Mapa de Integración (Largo Plazo – > 18 meses)
A continuación presentamos el mapa de integración de los distintos aplicativos:
•Red de Telefonía
Nuevo sistema
telefonía post
pago
Base de
Conocimiento
Valorizador
FOX
Oracle
Financials
Prebilling
y Billing
CRM
Triple
Play
DAC
6000
Sistema
Clientes
Corporativos
BUS DE INTEGRACIÓN
DW
BPM
Reporting
Entes
Externos
76
Agentes
Recaudadores
•Pago Fácil
•RapiPago
•Bapropagos
•Bancos
Tarjetas por
DAT/Pago
directo
CPP
•Movistar
•Claro
•Personal
•Nextel
CARENA
INTRAWAY
IPUNITY
Nuevos
sistemas
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Integración
Nivel I
Inicial
A
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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.
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.
Observaciones
COMENTARIO
Redundancia
B
Explotación
(acceso)
C
Automatización
de controles
D
Documentación
E
Estructura
77
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
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.
Descripción de la Recomendación
• Integración de las aplicaciones por medio de un bus de integración. Dicho bus es el único punto de contacto con las aplicaciones.
• Implementación de un esquema de gobierno de la arquitectura de integración, con roles y procesos específicos para el diseño de
interfaces y servicios.
• Ajuste de interfaces para su integración con el bus de integración.
Beneficios
• Mediante la implementación de una herramienta de integración, se simplifica la integración entre las aplicaciones, permitiendo también
abstraer la lógica de transformación de las aplicaciones y centralizarla en un único repositorio.
• La implementación de un esquema de gobierno orientado a la integración de aplicaciones permite gobernar de manera ordenada y
eficiente la comunicación entre las distintas aplicaciones que conforman la arquitectura y las reglas de negocio que permiten el
intercambio de información entre las mismas.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
Largo
Referencia
• http://www.tmforum.org/browse.aspx?catID=5733
78
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Cobertura del modelo
TAM
• Modelo TAM
• Cobertura actual del
Modelo
• Listado de Aplicaciones
79
Integración
CRM 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
•
•
•
•
Mapa de Integración
Redundancia
Explotación (acceso)
Automatización de
controles.
• Documentación.
• Estructura.
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Oracle Financials – Aspectos Funcionales
Nivel I
Inicial
Nivel II
Regular
Nivel III
Bueno
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.
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 precompletadas).
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 Adhoc 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 AdHoc 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.
B
Facilidad de
Uso
C
Automatización
de la
Información
D
Funcionalidad
para el actual
negocio
80
Nivel V
Excelente
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.
A
Flexibilidad
para añadir
nuevas
Funcionalidad
Nivel IV
Muy Bueno
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
COMENTARIO
Mediante la
implementación de una
herramienta de reporting,
se logra mejorar la
calidad de los reportes
del sistema.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Oracle Financials – Aspectos Funcionales
Nivel I
Inicial
E
Uso de
Capacidades
F
Calidad de
Información
G
Confiabilidad
del Sistema
H
Accesibilidad
81
Nivel II
Regular
Nivel III
Bueno
Hay algunas
funcionalidades que no
tienen uso y dificultan
en cierto grado el uso
del sistema
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 .
Nivel de Madurez Objetivo
(mediano plazo)
Existen algunas
funcionalidades no
utilizadas, pero no
dificultan el uso del
sistema.
Nivel V
Excelente
Hay muchas
funcionalidades que no
tienen uso y hace al
sistema muy engorroso.
Nivel de Madurez Actual
Existen algunas
funcionalidades no
utilizadas, alguna de las
cuales dificultan el uso
del sistema
Nivel IV
Muy Bueno
Observaciones
COMENTARIO
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Oracle Financials – Aspectos Técnicos
Nivel I
Inicial
B
Tiempo de
Respuesta
D
Esfuerzo
para
Cambios
82
Nivel IV
Muy Bueno
Nivel V
Excelente
El sistema es cerrado,
imposible añadir
interfaces.
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
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.
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.
Tiempos off-line o
problemas batch
frecuentes y
Disponibilidad significativos que
del Sistema sobrepasan lo
aceptable por el
negocio.
C
Nivel III
Bueno
Permite la extracción de
archivos "batch" con
programación superior a
tres días, pero no permite
interfaces en línea.
A
Facilidad de
Integración
Nivel II
Regular
El esfuerzo de
mantenimiento es alto
Es necesario un
pero se tiene suficiente
esfuerzo significativo de personal con el
desarrollo (construcción conocimiento necesario
y pruebas unitarias)
para cubrirlo, sin embargo
para el mantenimiento. la carga de trabajo hace
que el mismo no este
siempre disponible.
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Oracle Financials – Aspectos Técnicos
Nivel I
Inicial
E
Control y
Monitoreo
F
Dependencia
de HW y SW
G
Nivel II
Regular
Nivel III
Bueno
Robustez
83
Nivel V
Excelente
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.
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.
El sistema es escalable en el corto plazo en una
dimensión (p.e. añadiendo o mejorando el HW).
Escalabilidad
H
Nivel IV
Muy Bueno
Nivel de Madurez Actual
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.
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
El sistema tiene suficiente
escalabilidad para cumplir
con las necesidades
futuras con una inversión
de capital mínima.
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Sistema tel. post pago + Valorizador – Aspectos Funcionales
Nivel I
Inicial
Nivel II
Regular
Nivel III
Bueno
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.
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 precompletadas).
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 Adhoc 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 AdHoc 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.
B
Facilidad de
Uso
C
Automatización
de la
Información
D
Funcionalidad
para el actual
negocio
84
Nivel V
Excelente
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.
A
Flexibilidad
para añadir
nuevas
Funcionalidad
Nivel IV
Muy Bueno
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
COMENTARIO
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Sistema tel. post pago + Valorizador – Aspectos Funcionales
Nivel I
Inicial
E
Uso de
Capacidades
F
Calidad de
Información
G
Confiabilidad
del Sistema
H
Accesibilidad
85
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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 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 .
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
COMENTARIO
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Sistema tel. post pago + Valorizador – Aspectos Técnicos
Nivel I
Inicial
B
Tiempo de
Respuesta
D
Esfuerzo
para
Cambios
86
Nivel IV
Muy Bueno
Nivel V
Excelente
El sistema es cerrado,
imposible añadir
interfaces.
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.
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.
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.
Tiempos off-line o
problemas batch
frecuentes y
Disponibilidad significativos que
del Sistema sobrepasan lo
aceptable por el
negocio.
C
Nivel III
Bueno
Permite la extracción de
archivos "batch" con
programación superior a
tres días, pero no permite
interfaces en línea.
A
Facilidad de
Integración
Nivel II
Regular
Tiempos off-line o
problemas batch
ocasionales que
sobrepasan los aceptable
por el negocio.
El esfuerzo de
mantenimiento es alto
Es necesario un
pero se tiene suficiente
esfuerzo significativo de personal con el
desarrollo (construcción conocimiento necesario
y pruebas unitarias)
para cubrirlo, sin embargo
para el mantenimiento. la carga de trabajo hace
que el mismo no este
siempre disponible.
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Sistema tel. post pago + Valorizador – Aspectos Técnicos
Nivel I
Inicial
E
Control y
Monitoreo
F
Dependencia
de HW y SW
G
Escalabilidad
H
Robustez
87
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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.
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.
Nivel de Madurez Actual
El sistema es escalable en el corto plazo en una
dimensión (p.e. añadiendo o mejorando el HW).
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.
Nivel de Madurez Objetivo
(mediano plazo)
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.
El sistema tiene suficiente
escalabilidad para cumplir
con las necesidades
futuras con una inversión
de capital mínima.
Observaciones
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.
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Intraway – Aspectos Funcionales
Nivel I
Inicial
Nivel II
Regular
Nivel III
Bueno
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.
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 precompletadas).
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 Adhoc 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 AdHoc 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.
B
Facilidad de
Uso
C
Automatización
de la
Información
D
Funcionalidad
para el actual
negocio
88
Nivel V
Excelente
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.
A
Flexibilidad
para añadir
nuevas
Funcionalidad
Nivel IV
Muy Bueno
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
COMENTARIO
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Intraway – Aspectos Funcionales
Nivel I
Inicial
E
Uso de
Capacidades
F
Calidad de
Información
G
Confiabilidad
del Sistema
H
Accesibilidad
89
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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 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 .
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
COMENTARIO
La realización de un data
cleansing en las bases de
datos mejorará de
manera significativa la
calidad de los datos.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Intraway – Aspectos Técnicos
Nivel I
Inicial
B
Tiempo de
Respuesta
D
Esfuerzo
para
Cambios
90
Nivel IV
Muy Bueno
Nivel V
Excelente
El sistema es cerrado,
imposible añadir
interfaces.
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
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.
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.
Tiempos off-line o
problemas batch
frecuentes y
Disponibilidad significativos que
del Sistema sobrepasan lo
aceptable por el
negocio.
C
Nivel III
Bueno
Permite la extracción de
archivos "batch" con
programación superior a
tres días, pero no permite
interfaces en línea.
A
Facilidad de
Integración
Nivel II
Regular
El esfuerzo de
mantenimiento es alto
Es necesario un
pero se tiene suficiente
esfuerzo significativo de personal con el
desarrollo (construcción conocimiento necesario
y pruebas unitarias)
para cubrirlo, sin embargo
para el mantenimiento. la carga de trabajo hace
que el mismo no este
siempre disponible.
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Intraway – Aspectos Técnicos
Nivel I
Inicial
E
Control y
Monitoreo
F
Dependencia
de HW y SW
G
Escalabilidad
H
Robustez
91
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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.
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.
Nivel de Madurez Actual
El sistema es escalable en el corto plazo en una
dimensión (p.e. añadiendo o mejorando el HW).
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.
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
El sistema tiene suficiente
escalabilidad para cumplir
con las necesidades
futuras con una inversión
de capital mínima.
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Otras Aplicaciones – Aspectos Funcionales
Nivel I
Inicial
Nivel II
Regular
Nivel III
Bueno
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.
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 precompletadas).
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 Adhoc 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 AdHoc 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.
B
Facilidad de
Uso
C
Automatización
de la
Información
D
Funcionalidad
para el actual
negocio
92
Nivel V
Excelente
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.
A
Flexibilidad
para añadir
nuevas
Funcionalidad
Nivel IV
Muy Bueno
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
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.
Observaciones
COMENTARIO
Las principales
aplicaciones evaluadas
en este matriz son el
sistema FOX, CARENA y
DAC 6000.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Otras Aplicaciones – Aspectos Funcionales
Nivel I
Inicial
E
Uso de
Capacidades
F
Calidad de
Información
G
Confiabilidad
del Sistema
H
Accesibilidad
93
Nivel II
Regular
Nivel III
Bueno
Nivel IV
Muy Bueno
Nivel V
Excelente
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 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 .
Nivel de Madurez Actual
Nivel de Madurez Objetivo
(mediano plazo)
Observaciones
COMENTARIO
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Otras Aplicaciones – Aspectos Técnicos
Nivel I
Inicial
B
Tiempo de
Respuesta
Esfuerzo
para
Cambios
94
Nivel IV
Muy Bueno
Nivel V
Excelente
El sistema es cerrado,
imposible añadir
interfaces.
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
C
frecuentes y
significativos que
Disponibilidad sobrepasan lo
del Sistema
aceptable por el
negocio.
D
Nivel III
Bueno
Permite la extracción de
archivos "batch" con
programación superior a
tres días, pero no permite
interfaces en línea.
A
Facilidad de
Integración
Nivel II
Regular
Tiempos off-line o
problemas batch
ocasionales que
sobrepasan los aceptable
por el negocio.
El esfuerzo de
mantenimiento es alto
Es necesario un
pero se tiene suficiente
esfuerzo significativo de personal con el
desarrollo (construcción conocimiento necesario
y pruebas unitarias)
para cubrirlo, sin embargo
para el mantenimiento. la carga de trabajo hace
que el mismo no este
siempre disponible.
Nivel de Madurez Actual
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.
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 de Madurez Objetivo
(mediano plazo)
Observaciones
Las principales
aplicaciones evaluadas
en este matriz son el
sistema FOX, CARENA y
DAC 6000.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Otras Aplicaciones – Aspectos Técnicos
Nivel I
Inicial
E
Control y
Monitoreo
F
Dependencia
de HW y SW
G
Nivel II
Regular
Nivel III
Bueno
Robustez
95
Nivel V
Excelente
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.
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.
El sistema es escalable en el corto plazo en una
dimensión (p.e. añadiendo o mejorando el HW).
Escalabilidad
H
Nivel IV
Muy Bueno
Nivel de Madurez Actual
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.
Nivel de Madurez Objetivo
(mediano plazo)
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.
El sistema tiene suficiente
escalabilidad para cumplir
con las necesidades
futuras con una inversión
de capital mínima.
Observaciones
Las principales
aplicaciones
evaluadas en este
matriz son el sistema
FOX, CARENA y DAC
6000.
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.
Nivel de Madurez Objetivo (largo
plazo)
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Recomendación XXX
Particularidad
El sistema Comarch está pensado como prepago y utilizado como post-pago.
Descripción de la Recomendación
• Implementación de un sistema de telefonía post pago
• Implementación de un sistema de valorización de los CDRs, independiente del sistema de telefonía.
• Desarrollo de las interfaces entre el CRM y estos sistemas con Web Services lo que facilitará la implementación del bus de
comunicación en el largo Plazo.
Beneficios
• Contar con un sistema de telefonía acorde a las necesidades del negocio.
• Independizar el proceso de valorización de las llamadas del sistema de telefonía.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
•Ninguno
Largo
Referencia
• http://www.bitpipe.com/tlist/Telecom-Billing-Systems.html
• http://www.capterra.com/billing-and-provisioning-software
96
©2008 Deloitte Todos los derechos reservados.
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.
Descripción de la Recomendación
• Relevar las necesidades actuales del negocio en relación a Cash Management y ajustar la implementación actual (parametrización y
desarrollo) del módulo para que cumpla con dichos requerimientos.
Beneficios
• Contar con el módulo de Cash Management implementado de acuerdo a las necesidades actuales del negocio.
• Evitar la realización de tareas manuales que pueden ser absorbidas por dicho módulo.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
•Ninguno
Largo
Referencia
• http://www.oracle.com/applications/financials/cash_mgmt.html
97
©2008 Deloitte Todos los derechos reservados.
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.
Descripción de la Recomendación
• Implementar una herramienta de reporting que permita levantar los datos de sistemas externos y realizar distintos reportes (dinámicos y
estáticos) utilizando diversas fuentes.
• Implementación del rol de reporting, incluyendo el relevamiento de las necesidades de reporting del negocio, el diseño y la
implementación de los mismos.
• Desarrollo de una interface con el CRM con Web Services lo que facilitará la implementación del bus de comunicación en el largo Plazo.
• Para el CRM : el uso del componente ReportViewer, incluido en Visual Studio puede ayudar a que los reportes se hagan más rápido y
fácilmente.
Beneficios
• La implementación de un sistema de reporting central permitirá brindar herramientas de análisis certeras para el negocio, lo cuál le
permitirá tomar decisiones comerciales.
• La implementación de los reportes más prioritarios facilitará el trabajo cotidiano de los usuarios.
• El uso del mencionado componente facilitará la creación de los reportes.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
•Implementar el área de Reporting (ORGXXX).
Largo
Referencia
• Herramientas Open Source: http://reporting.pentaho.org/ , http://jasperforge.org/plugins/project/project_home.php?group_id=102
98
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
DW - Introducción
Demanda de
Información
Innovación
Data Mining &
Visualización
 Descubrimientos
 Clasificaciones
 Predicciones
Impacto Estratégico
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.
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.
Percepción
Analítica
Consultas / Exploración
Ad Hoc
Reportes
Datos
Retrospectiva
Información
Contexto y
Relevancia
 Análisis
 KPI’s
 “Slice and Dice”
Conocimiento
Inversión en Business Intelligence
Percepción y
Previsión
Prospectiva
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”.
Mayor entendimiento del
negocio
99
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
DW - Definición
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.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
DW - Componentes
Arquitectura técnica de BI
Fuente
de Datos
Servicios de
Integración
Almacenamiento de
Datos
Servicios
Analíticos
Servicios
de Delivery
Extracción
Reportes de
Producción
Empresa
Transformación
Reportes de
usuario final
Web Browser
Desestructurada
Carga
Data Mining
Portal
Informacional
Sincronización
Tableros de
Comando
Dispositivos
Externa
Transporte /
Mensaje
Análisis
Embebido
Web Services
Mantenimiento de
Integridad
Datos
Operativos
Data
Marts
OLAP
Flujo de Datos
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
DW – Componentes (Cont.)
Arquitectura técnica del BI
Fuentes de Datos
Servicios de
Integración
Almacenamiento
de Datos
Servicios
Analíticos
Servicios de
Delivery
• Son los sistemas que proveen la información al BI.
• Son las tecnologías que permiten el flujo de datos entre los distintos
sistemas.
• Se refiere a los sistemas que consolidan y guardan la información
que será utilizada para análisis.
• Soluciones que analizan los datos a extraer para construir la
información y reportes del BI para los usuarios.
• Son los sistemas que permiten a los usuarios acceder a la
información y reportes del BI.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
DW – Factores de Éxito
Factores Críticos de Éxito
Alineamiento del
negocio y enfoque
hacia los
beneficios
• Se debe basar en el valor que se da al negocio a través de brindar información en
tiempo y forma para la toma de decisiones. La estrategia debe estar orientada al
negocio y no a la tecnología.
Experiencia en BI
y DW
• Trabajar con un conjunto de metodologías, enfoques y herramientas específicas
de BI permitirá hacer una mejor implementación de forma más rápida y menos
costosa.
Efectividad de la
Gobernabilidad y el
Manejo del Cambio
• Esto se logra ayudando a comprender al negocio sobre los beneficios brindados
por esta nueva capacidad de análisis y ayudando a la Dirección de Sistemas a
establecer la organización y gobernabilidad para el logro de objetivos ext
El equipo adecuado
• Un equipo experimentado en la implementación de BI, que conozca la industria de
las telecomunicaciones, la empresa, su tecnología y el negocio.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Recomendación XXX
Particularidad
No hay un datawarehouse implementado que permita hacer análisis complejos de distintas variables de negocio.
Descripción de la Recomendación
• Implementación un repositorio común de datos de negocio.
• Implementación de herramientas de inteligencia de negocio.
Beneficios
• La implementación de un datawarehouse, acompañado de herramientas de inteligencia de negocio permitirá, no solo cubrir las
necesidades de reporting actuales, sino también utilizar distintas variables que permitan analizar el comportamiento del negocio en
función de distintos contextos.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
Largo
Referencia
• http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?tok=1211574194219&nid=33043
• http://www.ibermatica.com/ibermatica/eventos/2004/mtbi
104
©2008 Deloitte Todos los derechos reservados.
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.
Descripción de la Recomendación
• Definir la estrategia de gestión de conocimiento (incluye roles, herramientas, templates y procedimientos).
• Implementar un repositorio de información para la gestión del conocimiento, incluyendo la definición de la metodología de incorporación
y actualización de la documentación del mismo.
Beneficios
• Contar con una herramienta que permita desarrollar las habilidades internas y compartir experiencias que ayuden a resolver problemas
recurrentes.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
Largo
Referencia
• http://it.toolbox.com/vendors/topics/knowledge-management
105
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
BPM - Introducción
BPM – Business Process Management
• Es la convergencia de un conjunto de tecnologías y enfoques
existentes en una única plataforma que maneje el ciclo de vida
de un proceso, incluyendo definición, implementación, ejecución,
medición, cambio y reimplementación.
• Promueve la visión de la tecnología desde los procesos
asociados a ella, en donde la administración de punta a punta de
los procesos es separada de las aplicaciones, sus
interconexiones y los datos subyacentes.
• Involucra la creación de una capa de procesos independiente y
explícita, la cual contiene el flujo, los servicios y las reglas para
reflejar las capas implícitas de aplicaciones y servicios.
• Promueve el tratamiento de los procesos como activos de la
organización, de la misma forma que son tratados los datos y la
información.
Pero no…
• Es una tecnología para automatizar los procesos existentes; por
el contrario, brinda un entorno efectivo para administrar y mejorar
constantemente los procesos en sí.
• Representa la segunda ola de reingeniería de procesos de
negocio. La principal diferencia es que existen herramientas
subyacentes y tecnologías de soporte utilizadas en BPM que
ayudan a descubrir el verdadero valor de la ingeniería de
procesos.
106
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
BPM - Valor
La Administración de los Procesos del Negocio (BPM, Business Process Management) se refiere al
diseño, implementación y optimización de los procesos de negocio que se ejecutan mediante una
combinación de gente, secuencia de procesos e interacciones entre sistemas.
¿Qué valor tiene para la organización?
Eficiencia de los procesos y efectividad en el Servicio
107
Foco en el desarrollo de ventajas competitivas a través de un balance
del tipo costos/servicio. Lo obtiene eliminando actividades sin agregado
de valor, reduciendo los ciclos de proceso y minimizando los costos
asociados a la ejecución de procesos de negocio.
Flexibilidad 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 Mercado
Promueve la reducción del tiempo de colocación de productos en el
mercado, maximizando la capacidad de la organización para responder
a los cambios del mercado y competir efectivamente.
Relacionamiento con el Cliente
Las herramientas BPM permiten manejar de manera flexible diversos
métodos y canales de interacción con el cliente, y gestionar de manera
integral estas interacciones.
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
BPM - Eficiencia Operacional
A la hora de llevar a cabo la implementación de BPM, hay un ciclo de vida que consiste en varias fases
interconectadas que funcionan como ciclo cerrado que aseguran la obtención de resultados y objetivos
deseados.
Definición
Definición
Creación
En esta fase se documentarán las diversas tareas que deben negociarse para
completar el proceso. BPM tiene la habilidad de traducir gráficos de modelado de
procesos en un lenguaje estándar de definición de procesos; A su vez, también
provee acceso directo a Reglas de negocio con el fin de asistir en la definición
exacta de procesos existentes.
Creación
Aquí es donde la definición de procesos es traducida a un código ejecutable que
pueda ser entendido por los sistemas de la computadora.
Ejecución
Optimización
Se encapsula la ejecución de todo el proceso, usando una combinación de
Integración, workflow, automatización y reglas de negocios.
Ejecución
Monitoreo
A través de los gráficos que representan a los procesos, se monitorea el estado
de ejecución de dichos procesos. Esto permite responder rápidamente cuando se
detectan cuellos de botella que limitan el rendimiento de los procesos.
Monitoreo
Ejecución
Esta fase final, provee la oportunidad de realizar Simulaciones sobre los
procesos existentes, a través de gráficos, reportes y análisis que permiten
optimizar el objetivo de los procesos.
108
©2008 Deloitte Todos los derechos reservados.
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.
Descripción de la Recomendación
• Implementar una herramienta de BPM, incluyendo los roles necesarias para la gestión centralizada de los mismos.
• Relevar los procesos de negocio, analizar aquellos que se beneficien de ser implementados mediante la herramienta de BPM , diseñar
los procesos para su implementación, definir los controles y las métricas a analizar, implementarlos, monitorearlos y medirlos y
ajustarlos.
Beneficios
• Contar con herramientas que permitan eficientizar los procesos de negocio, brindar mayor flexibilidad y responder de manera más ágil a
las necesidades del negocio.
Criticidad
Impacto
Complejidad
Plazo
Alta
Alto
Alto
Corto
Media
Medio
Mediano
Baja
Bajo
Medio
Bajo
Prerrequisitos
Largo
Referencia
• http://www.bpm.com/
109
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Conclusión
La evolución hacia el mapa de aplicaciones objetivo, la puesta en práctica de los
principios guía de arquitectura aplicativa, y las recomendaciones propuestas en
este entregable, permitirán mejorar el nivel de madurez de las aplicaciones y
obtener los siguientes beneficios:
110
110
•
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.
Frente Arquitectura Aplicativa
Conclusiones
A continuación los puntos más críticos de mejora de los 4 focos de análisis :
Cobertura del
modelo TAM
• Mejora y automatización de los módulos existente y adquisición de Herramientas o
desarrollo de funcionalidades para cumplir con los módulos faltante y cubrir el modelo y
aumentar el control de los flujos de datos de la compañía.
CRM Triple Play
Integración
• Automatización de los controles de los datos que circulen entre el CRM y las diferentes
plataformas para asegurar que la calidad de las mismas.
• Integración con un bus de Datos para facilitar la integración de nuevas aplicaciones.
Arquitectura
Aplicativa (todas
las aplicaciones
menos el CRM)
• Adquisición de un nuevo Sistema de Valorización, un sistema de telefonía post pago y una
herramienta para gestionar los clientes corporativos para cubrir los requerimientos de
negocio actuales.
• Adquisición de herramientas de DW y de reporting para falicitar el conocimento en la
empresa.
111
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Anexo I:
- Detalle de las Recomendaciones.
112
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación APL001 (pantallas consolidadas)
Hallazgo
En varios casos se encontró que la información requerida por un usuario para completar una tarea muy frecuente, está distribuida en varias
pantallas, lo cual obliga al usuario a tener que navegar la aplicación para acceder a dicha información.
Descripción de la Recomendación
• Crear para las tareas más frecuentes (por ejemplo búsqueda y visualización de datos de clientes) pantallas consolidadas que contengan
toda la información requerida por los usuarios de manera de minimizar el tiempo que estos invierten en navegar y realizar las tareas
más comunes.
Beneficios
• Optimización de los tiempo de trabajo.
Prerrequisitos
Trabajar con los usuarios clave para
detectar la pantallas más prioritarias
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• No aplica
113
113
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendación APL002 (validaciones)
Hallazgo
Varios de los datos ingresados por los usuarios carecen de validaciones, lo tiene las siguientes desventajas:
•Disminuye la calidad de la información almacenada en el sistema, lo cual.
•Dificulta la realización tareas posteriores.
Descripción de la Recomendación
• Implementar validaciones de longitud y formato. Y cuando sea posible también implementar los algoritmos de dígito verificador (por
ejemplo para números de tarjeta , CBUs, CUITs).
Beneficios
• Esto mejorará la calidad de la información del sistema y facilitará la ejecución de cierta tareas posteriores.
Prerrequisitos
Validar con los usuarios clave cuales
son los campos considerados clave
desde la visión de negocio
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• No aplica
114
114
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones APL003 (mensajes claros)
Hallazgo
Se detectó que ante errores la aplicación muestra mensajes inapropiados al usuario. Asimismo cuan por alguna razón el sistema colapsa
no se el usuario se encuentra con una pantalla poco amigable que no ofrece ningún tipo de explicación.
Descripción de la Recomendación
• Definir en el archivo de configuración de la aplicación páginas personalizadas para cuando la aplicación no está disponible.
• Manejar las excepciones no atrapadas dentro del Global.asax, dejando registro de la excepción y mostrando un mensaje apropiado para
usuario.
• Involucrar a los usuarios clave en la definición de los mensajes.
Beneficios
• Esto mejorará la percepción que los usuarios tienen del sistema.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Alto
Corto
Usabilidad
Media
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://aspnetresources.com/articles/CustomErrorPages.aspx
115
115
©2008 Deloitte Todos los derechos reservados.
Frente Aplicaciones
Recomendaciones APL004 (reportes)
Hallazgo
Es conocida la falta de reportes de la aplicación.
Descripción de la Recomendación
• Se recomienda la implementación de los reportes más prioritarios. Un punto que puede ayudar a que los reportes se hagan más rápido
y fácilmente es el uso del componente ReportViewer, incluido en Visual Studio. Este componente está integrado con el entorno de
desarrollo y permite el diseño visual de los reportes.
Beneficios
• La implementación de los reportes más prioritarios facilitará el trabajo cotidiano de los usuarios.
• El uso del mencionado componente facilitará la creación de los reportes.
Prerrequisitos
Ninguno
Beneficio
Impacto
Plazo
Performance
Usabilidad
Media
Alto
Corto
Medio
Mediano
Baja
Mantenibilidad
Bajo
Largo
Referencia
• http://www.gotreportviewer.com/
116
116
©2008 Deloitte Todos los derechos reservados.
Frente Arquitectura Aplicativa
Anexo II:
– Describir
117
©2008 Deloitte Todos los derechos reservados.