Proyecto con Datos Reales

Sistema Analítico de
Cartera de Créditos

Pipeline completo de inteligencia de riesgo crediticio — desde los datos crudos hasta modelos en producción, API REST y dashboard interactivo.

124.781 préstamos reales
AUC-ROC 0.9415
3.744 anomalías detectadas
8 módulos de análisis

El problema que resuelve

Toda institución financiera enfrenta estos desafíos con su cartera de créditos

Riesgo no visible

Los préstamos deteriorados se identifican tarde, cuando la mora ya es severa y la recuperación es difícil.

Sin segmentación real

Se aplica la misma gestión a clientes con perfiles muy distintos, desperdiciando recursos de cobranza.

Anomalías sin detectar

Operaciones con condiciones fuera del patrón (montos, plazos, tasas) pasan sin revisión y esconden riesgos ocultos.

Sin visión de cosechas

No se compara cómo evolucionan las distintas generaciones de préstamos, impidiendo mejorar las políticas de otorgamiento.

Este sistema los resuelve todos

Un pipeline de datos reproducible, tres modelos de machine learning entrenados sobre datos reales y un dashboard interactivo que permite actuar antes de que el problema sea irreversible.

Arquitectura del sistema

Del dato crudo al modelo en producción — flujo completo en 8 etapas

1
Datos crudos
CSV original
2
Limpieza
NB 02
3
Análisis
Morosidad
NB 03
4
Segmentación
K-Means
NB 04
5
Modelo
Incumplimiento
NB 05
6
Detección
Anomalías
NB 06
7
Análisis
Cosechas
NB 08
8
API REST +
Dashboard
Producción
Capa de Datos
CSV crudo (124K filas)
cartera_limpia.csv
Capa de Análisis
8 Jupyter Notebooks
pandas + matplotlib
Capa de Modelos
3 modelos ML
sklearn .pkl serializados
Capa de Producción
FastAPI + Streamlit
Dockerizable

Módulos del sistema — paso a paso

Cada módulo tiene un propósito claro, entradas definidas y salidas reproducibles

1

Exploración inicial de la cartera

Notebook 01 — comprensión del dato crudo
PythonJupyter

¿Qué se hace? Se carga el archivo CSV original con los 124.781 préstamos y se examina la calidad del dato: nulos, distribuciones, rangos, valores atípicos y relaciones entre variables.

  • Inspección de las 53 columnas disponibles
  • Distribución de variables numéricas clave (monto, plazo, tasa, DDM)
  • Conteo de nulos por variable para planificar la limpieza
  • Identificación de outliers en ingreso mensual y deuda en sistema
Concepto: El DDM (Días de Mora) es el indicador central de incumplimiento. Un DDM > 0 significa que el titular ya tiene cuotas vencidas.
Lo que revela esta exploración
124.781 filas × 53 columnas 6.148 nulos en ratio_cuota_ingreso Datos al 30.04.2018 63 sucursales distintas 17 tipos de producto 5 áreas de negocio
2

Limpieza y preparación del dato

Notebook 02 — generación de variables derivadas
PythonDatos reales

¿Qué se hace? Se transforma el dato crudo en un dataset limpio y analizable. Se documentan todos los cambios para que el proceso sea reproducible y auditable.

  • Fechas: conversión a datetime, cálculo de edad y antiguedad_meses
  • Ingresos: los ≤ 0 se imputan como nulos (ingreso inválido)
  • DDM: cap en rango [-365, +730] para eliminar errores de sistema
  • Score: nulos → 'SIN_SCORE' + variable binaria tiene_scorin
  • Riesgo: nulos → 'SIN_CLASE' para no perder filas
  • Variables creadas: ratio_cuota_ingreso, tramo_mora, tramo_plazo, en_mora, tramo_antiguedad
ratio
cuota/ingreso

Variable derivada más importante:
cuota ÷ ingreso mensual.
Si supera el 30% → sobreendeudamiento.

Salida de este módulo
cartera_limpia.csv 6 variables nuevas 0 nulos críticos
3

Análisis de morosidad y riesgo

Notebook 03 — dónde está el riesgo
PythonVisualización

¿Qué se hace? Se analiza en profundidad cómo se distribuye la mora en todos los ejes del negocio. Es el diagnóstico completo de la salud de la cartera.

  • Distribución por tramos de mora (0–30, 31–60, 61–90, 90+ días)
  • Heatmap mora × categoría regulatoria × calificación interna
  • Mora por producto, área de negocio y ocupación del titular
  • Análisis de ratio cuota/ingreso: ¿los sobreendeudados caen más en mora?
  • Ranking de sucursales críticas por mora + saldo expuesto
  • Curva de vida del préstamo: ¿en qué mes se rompe el pago?
  • Perfil comparativo: cliente sano vs cliente en riesgo alto (califi ≥ 3)
Hallazgo clave: El pico de mora ocurre en el mes 26 de vida del préstamo con 76.5% — los créditos que sobreviven más de 2 años se vuelven muy riesgosos si no se gestionan antes.

Estado de la cartera al corte

28.4%
Mora global
8.9%
Mora > 90 días
10.7%
Califi alta (≥3)
Gs. 552 MM
Saldo expuesto
Salida de este módulo
8 gráficos profesionales Ranking sucursales
4

Segmentación de deudores — K-Means

Notebook 04 — agrupar para gestionar mejor
Machine Learningscikit-learn

¿Qué se hace? El algoritmo K-Means agrupa automáticamente los 124.781 préstamos en segmentos con características similares, sin necesidad de etiquetar los datos manualmente.

¿Por qué K-Means? Es el estándar en segmentación de cartera crediticia: rápido, interpretable y permite actualizar los segmentos cuando ingresan nuevos datos.

  • Variables de segmentación: DDM, calificación, ratio cuota/ingreso, monto, plazo, antigüedad, saldo
  • Escalado con StandardScaler para equilibrar unidades
  • Método del Codo + Silhouette Score para elegir K óptimo
  • Visualización en 2D con PCA (Análisis de Componentes Principales)
  • Asignación de etiquetas de negocio a cada cluster
Concepto: El Silhouette Score mide qué tan bien separados están los grupos (0 a 1). Un valor de 0.93 indica separación casi perfecta.

Los segmentos y sus acciones

🟢
PREMIUM
Sin mora · Cross-sell · Fidelización
🔵
ESTÁNDAR
Mora mínima · Mantenimiento rutinario
🟡
SEGUIMIENTO
Mora moderada · Contacto preventivo
🔴
CRÍTICO
Mora grave · Negociación urgente
Salida de este módulo
cartera_segmentada.csv kmeans_deudores.pkl Silhouette: 0.9292
5

Modelo predictivo de incumplimiento

Notebook 05 — el corazón del sistema
Gradient Boosting scikit-learn AUC 0.9415

¿Qué se hace? Se entrena un modelo de Gradient Boosting para predecir qué préstamos caerán en incumplimiento (calificación ≥ 3) antes de que ocurra. Es el módulo más valioso del sistema.

¿Cómo funciona el Gradient Boosting? Es un ensamble de árboles de decisión donde cada árbol corrige los errores del anterior. Es el algoritmo estándar de la industria para scoring crediticio.

  • Variable objetivo: califi >= 3 (sin data leakage: no usa DDM ni en_mora)
  • Pipeline sklearn: imputa nulos → escala → codifica categorías → modelo
  • Validación cruzada: 5 folds estratificados (AUC media: 0.9409 ± 0.0024)
  • Umbral ajustado: 0.32 (optimizado por costo, no por defecto 0.5)
  • Comparado contra Regresión Logística (AUC base)

Variables más influyentes en el modelo:

Meses desde originación
24.3%
Tasa de interés BCP
18.6%
Saldo capital actual
16.4%
Plazo (meses)
8.4%
Valor de cuota
7.1%

Métricas del modelo en datos de prueba

0.9415
AUC-ROC (test)
0.7567
Avg. Precision
0.9409
CV AUC media
±0.0024
Desv. estándar CV
Train: 99.824 préstamos (80%)  |  Test: 24.957 (20%)
Estratificado por clase para manejar el desbalance
¿Qué significa AUC-ROC 0.9415? Un modelo aleatorio tiene AUC = 0.5. Un modelo perfecto tiene AUC = 1.0. Con 0.9415 el modelo ordena correctamente el 94% de los pares (riesgo alto / riesgo bajo) — rendimiento de calidad industrial.
Salida de este módulo
gb_incumplimiento.pkl meta_incumplimiento.json
6

Detección de anomalías — IsolationForest

Notebook 06 — operaciones fuera del patrón
No supervisado IsolationForest

¿Qué se hace? Se entrena un detector no supervisado para identificar préstamos cuyas condiciones financieras (monto, tasa, plazo, ingreso) se alejan del patrón habitual de la cartera.

¿Cómo funciona el IsolationForest? Construye árboles aleatorios que "aíslan" cada punto. Las anomalías se aíslan con menos cortes porque son raras y extremas. No necesita datos etiquetados.

  • 10 variables financieras sin información de mora (para evitar circular reasoning)
  • 300 árboles, contaminación calibrada al 3%
  • Validación cruzada: las anomalías coinciden con calificaciones altas
  • Score exportado por préstamo para revisión humana
Uso típico: Detectar préstamos con tasa anormalmente alta para el cliente, o montos que no corresponden al perfil de ingreso — posibles errores de originación o situaciones de riesgo oculto.

Resultado de la calibración

Préstamos analizados 124.781
Anomalías detectadas 3.744 (3.0%)
Score mínimo (más anómalo) -0.8118
Score máximo (más normal) -0.3427
Salida de este módulo
isoforest_anomalias.pkl anomalias_para_revision.csv
7

Análisis de cosechas (Vintage Analysis)

Notebook 08 — ¿mejora o empeora la calidad de originación?
Pythonscipy

¿Qué se hace? Se agrupa cada préstamo por su año/trimestre de originación (cosecha) y se analiza cómo evoluciona la mora a lo largo de su vida. Es la técnica estándar en banca para evaluar la calidad de las políticas de crédito a lo largo del tiempo.

  • Curvas vintage por año y trimestre de originación
  • Indicador de mora a 12 meses (ventana comparable entre cosechas)
  • Heatmap cosecha × mes de vida
  • Detección automática de tendencia (DETERIORO / MEJORA / ESTABLE) con regresión lineal
Interpretación: Las cosechas 2015–2016 tienen mora del 60.7% y 55.4% — las más riesgosas. Las de 2017–2018 parecen sanas pero están inmaduras (los préstamos son jóvenes al corte).

Cosechas por año de originación

Cosecha Préstamos % Mora Estado
20149942.4%CRÍTICA
201562160.7%CRÍTICA
20168.33855.4%CRÍTICA
201774.90134.3%VIGILAR
201840.69911.5%INMADURA
8

API REST + Dashboard interactivo

Producción — scoring en tiempo real y análisis visual
FastAPI Streamlit Docker

API REST — FastAPI

Los modelos entrenados se sirven como endpoints HTTP. Cualquier sistema externo (core bancario, CRM, Excel) puede consultar el riesgo de un préstamo en tiempo real.

POST /predecir/incumplimiento
POST /alertas/cartera
POST /evaluar/prestamo
GET   /cartera/resumen
GET   /modelos/info
{"probabilidad_incumplimiento": 0.2094,
 "nivel_riesgo": "bajo",
 "accion_recomendada": "...",
 "umbral_usado": 0.45}

Dashboard Streamlit — 3 páginas

Portada — KPIs globales

Métricas de la cartera en tiempo real + métricas de los modelos entrenados. Estado del sistema de un vistazo.

Cartera — análisis completo

Filtros por área, riesgo y calificación. Tabs: morosidad, sucursales, segmentos. Descargas CSV.

Predictor — evaluación en tiempo real

Formulario interactivo: ingresás los datos de un préstamo y obtenés la probabilidad de incumplimiento, detección de anomalía y alerta global — sin necesitar la API.

Resultados obtenidos con datos reales

Métricas verificables — no son simulaciones ni datos sintéticos

0.9415
AUC-ROC del modelo
Rendimiento industrial en scoring crediticio. La industria considera ≥ 0.80 como "bueno".
3.744
Anomalías detectadas
Préstamos con condiciones financieras fuera del patrón histórico de la cartera.
0.9409
AUC validación cruzada
±0.0024 en 5 folds. El modelo generaliza bien — no es overfitting.
124.781
Préstamos procesados
Cartera real completa. Corte 30.04.2018 — 63 sucursales, 17 productos, 5 áreas.

Lo que el sistema detectó

28.4% de mora global
35.471 préstamos con algún grado de incumplimiento al corte
Mes 26 — pico de riesgo
76.5% de mora en préstamos con 26 meses de vida. Alerta temprana antes del mes 20.
Cosechas 2015-2016 críticas
60.7% y 55.4% de mora — reflejan una política de originación que debió revisarse.
Ratio cuota/ingreso > 30% = más mora
El sobreendeudamiento del titular es el principal predictor de incumplimiento.

Lo que el sistema permite hacer

Alerta temprana automática
Identificar préstamos de alto riesgo antes del mes 15 — cuando aún se puede reestructurar.
Scoring de nuevas solicitudes
La API devuelve la probabilidad de incumplimiento en < 200ms para integrar en el proceso de aprobación.
Priorización de gestión de cobranza
Los segmentos K-Means guían qué clientes necesitan llamada urgente, preventiva o solo monitoreo.
Revisión de anomalías
Lista de 3.744 préstamos para auditoría interna — posibles errores de originación o irregularidades.

Stack tecnológico

Herramientas de código abierto, estándar de la industria, sin costos de licencia

Python 3.11+
Lenguaje base del sistema
pandas + numpy
Manipulación de datos
scikit-learn
Pipeline ML completo
FastAPI
API REST de producción
Streamlit
Dashboard interactivo
Jupyter Lab
Pipeline reproducible
matplotlib + seaborn
Visualizaciones
scipy
Estadística y tendencias
Docker
Empaquetado y deploy
Pydantic
Validación de datos API

¿Para quién es este sistema?

Tres perfiles de cliente que se benefician directamente

🏦

Banco o financiera

Scoring automático de nuevas solicitudes integrado en el proceso de aprobación. Alertas tempranas que disparan gestión preventiva antes de la mora severa.

Reducción de mora Scoring automático API integrable
🤝

Cooperativa de crédito

Segmentación inteligente de socios para gestión diferenciada. Dashboard simple que no requiere conocimientos técnicos del equipo operativo.

Segmentación socios Dashboard simple Sin IT complejo
📊

Área de Riesgos

Reporte ejecutivo automatizado con 29 gráficos. Análisis de cosechas para evaluar la calidad histórica de las políticas de otorgamiento.

Reporte automático Análisis cosechas Detección anomalías

Lo que puedo implementar para tu institución

Servicio de consultoría — adaptado a tus datos y procesos

Diagnóstico de cartera

Análisis completo de tu portafolio: distribución de mora, segmentos de riesgo, sucursales críticas y calidad de datos. Entregable: reporte HTML ejecutivo.

  • Exploración y limpieza de datos
  • 8 análisis de morosidad
  • Reporte ejecutivo PDF/HTML
  • Presentación de hallazgos

Modelo de scoring

Desarrollo del modelo predictivo calibrado sobre tus datos históricos. Incluye pipeline completo, validación y documentación del umbral óptimo.

  • Pipeline sklearn reproducible
  • Modelo GradientBoosting
  • Validación cruzada rigurosa
  • Documentación técnica

Sistema en producción

API REST + dashboard interactivo desplegado en tu infraestructura. Integrable con core bancario, CRM o cualquier sistema que haga peticiones HTTP.

  • FastAPI dockerizada
  • Dashboard Streamlit
  • Documentación Swagger
  • Capacitación al equipo

¿Tenés los datos, yo tengo la metodología

Esta solución fue desarrollada y validada sobre 124.781 préstamos reales. El mismo pipeline se adapta a cualquier cartera crediticia — bancaria, cooperativa o fintech.

¿Cómo se entrega al cliente?

Tres opciones según el perfil técnico del cliente — de la más simple a la más robusta

A

ZIP del proyecto — cliente con Docker instalado

La más simple · Un solo comando · 15 minutos de instalación
Recomendada para IT interna

¿Qué recibe el cliente? Una carpeta comprimida con todo el proyecto listo para correr. Los modelos ya están entrenados — no necesita datos históricos para empezar.

Contenido del ZIP entregado
cartera_analitica_v1.zip
 ├── api/               ← API REST lista
 ├── dashboard/         ← Dashboard Streamlit
 ├── modelos/entrenados/  ← .pkl ya entrenados
 ├── data/procesada/     ← CSVs procesados
 ├── Dockerfile
 ├── docker-compose.yml
 └── README.md
Clave: Los modelos .pkl ya están entrenados y dentro del ZIP. El cliente no necesita datos históricos para arrancar. Puede evaluar préstamos nuevos desde el primer minuto.

Lo que hace el cliente (una sola vez):

Paso 1 — Instalar Docker Desktop

Descarga gratuita de docker.com. Disponible para Windows, Mac y Linux. Instalación de 5 minutos.

Paso 2 — Descomprimir el ZIP

Extraer en cualquier carpeta del servidor o computadora donde vaya a correr.

Paso 3 — Un solo comando

docker-compose up --build

Resultado en 3–5 minutos

API disponible en http://localhost:8000/docs
Dashboard en http://localhost:8501

B

Imagen Docker pre-construida — cliente sin conocimientos técnicos

Enchufar y correr · El cliente solo carga el archivo · Sin instalación de Python
Sin IT requerido

¿Qué es una imagen Docker? Es como un appliance — una caja sellada que contiene el sistema operativo, Python, todas las librerías y el código, todo junto. El cliente solo necesita Docker instalado.

No importa si el servidor del cliente tiene Windows Server, Ubuntu o cualquier otro sistema — la imagen corre igual en todos.

Analogía: Es como entregarle un pendrive con el sistema ya instalado. El cliente lo conecta y ya funciona, sin saber nada de Python ni de librerías.
TAMAÑO DEL ARCHIVO A ENTREGAR
~800 MB
imagen comprimida
USB / Drive
medio de entrega

Proceso completo — vos hacés en tu máquina:

# 1. Construir la imagen (una vez, ~5 min)
docker build -t cartera-analitica:v1 .

# 2. Exportar como archivo .tar.gz
docker save cartera-analitica:v1 | gzip \
  > cartera-analitica-v1.tar.gz

# 3. Entregar por USB, Google Drive o servidor FTP

El cliente hace en su máquina:

# 1. Cargar la imagen (una vez)
docker load < cartera-analitica-v1.tar.gz

# 2. Correr el sistema
docker run -p 8000:8000 -p 8501:8501 \
  cartera-analitica:v1
C

Despliegue en la nube — acceso remoto desde el navegador

El cliente no instala nada · Accede con una URL · Siempre actualizado
Máxima comodidad

¿Cómo funciona? El sistema se despliega en un servidor en la nube. El cliente accede al dashboard desde su navegador con una URL, sin instalar absolutamente nada.

Ideal para instituciones sin área de IT o que quieren acceso desde múltiples dispositivos y ubicaciones.

🚂
Railway
~5 USD/mes · Deploy con un click desde GitHub · El más sencillo
🔷
Render
Gratis con límites · Ideal para demos y evaluaciones
☁️
Azure / AWS / GCP
Infraestructura del banco · Máxima seguridad y control

Ventajas del despliegue en nube

El cliente accede desde cualquier dispositivo
No depende de una PC específica encendida
Actualizaciones transparentes — sin reinstalar
Múltiples usuarios simultáneos
URL personalizada del cliente
Para el pitch: "Ningún empleado instala nada. Solo abren el navegador, van a riesgo.tuinstitucion.com y ya tienen el dashboard. Como un Netflix del análisis de cartera."
Criterio A — ZIP B — Imagen Docker C — Nube
Requiere IT del cliente Sí (básico) Solo Docker No
Costo mensual $0 $0 $5–50 USD
Acceso remoto / móvil No No
Datos quedan en el cliente Configurable
Tiempo de puesta en marcha 15 min 30 min 2 min

¿Cómo se actualiza con datos nuevos?

El sistema acepta datos reales del cliente desde el día uno — tres formas de conectarlo

Ciclo mensual de actualización

Core bancario
Topaz / Olympic /
SQL Server
Extracción
CSV mensual o
conexión SQL
Limpieza
Notebook 02
automático
Análisis
NB 03-08
re-ejecutados
Dashboard
Actualizado
automáticamente
Todo el proceso toma menos de 10 minutos · Se puede automatizar con una tarea programada
📄

Fuente 1 — CSV del core bancario

El core bancario genera un reporte de cartera en Excel o CSV. El cliente lo exporta una vez al mes y lo copia en la carpeta del sistema.

# Reemplazar el archivo
data/raw/carteracsv.csv

# Correr el pipeline
python actualizar_cartera.py
Sin programación Costo $0 Lo más común
🗄️

Fuente 2 — Base de datos SQL directa

El sistema se conecta directamente al SQL Server, PostgreSQL o MySQL del cliente. Descarga los datos frescos automáticamente sin intervención manual.

# Configurar en .env (una sola vez)
DATABASE_URL=mssql://user:pass
            @servidor/cartera

# Correr cada mes
python data/extraccion/extraer_cartera.py
Totalmente automático Sin exportar nada Requiere DBA

Fuente 3 — Ejecución automática programada

Se configura una tarea que corre automáticamente el primer día hábil de cada mes. El cliente no hace nada — el dashboard se actualiza solo.

# Windows — Tareas programadas
# Correr el 1ro de cada mes a las 6AM
python actualizar_cartera.py

# Linux — cron
0 6 1 * * python actualizar_cartera.py
Manos libres Sin intervención Ideal producción

¿Cuándo re-entrenar los modelos?

Los modelos no se re-entrenan con cada actualización de datos — solo en estos casos

El pipeline de análisis (notebooks 02–03–08) corre con cada nuevo corte de datos. Los modelos de machine learning (notebooks 05–06) se re-entrenan solo cuando hay razón para hacerlo.

Situación Análisis (NB02-03) Modelos ML (NB05-06)
Nuevo corte mensual Correr No necesario
6–12 meses de datos nuevos Correr Re-entrenar
Nueva política de crédito Correr Re-entrenar
AUC cae por debajo de 0.85 Correr Urgente
Cambio de sistema bancario Adaptar Re-entrenar

Qué pasa cuando llegan datos del cliente

Semana 1 — Mapeo de columnas
Se comparan las columnas del cliente con el esquema del sistema. Tiempo: 2–4 horas con el DBA del cliente.
Semana 1–2 — Primer análisis
Correr notebooks 02–03. El cliente ve su primera distribución de mora real en el dashboard.
Semana 2–3 — Modelo calibrado
Re-entrenar notebooks 05–06 con los datos propios del cliente. El modelo queda calibrado para su cartera específica.
Semana 3–4 — En producción
API y dashboard corriendo con datos reales del cliente. Capacitación al equipo operativo.
Script de actualización mensual — actualizar_cartera.py
# 1. Extraer datos frescos del core bancario
python data/extraccion/extraer_cartera.py

# 2. Limpiar y preparar
jupyter nbconvert --execute notebooks/02_limpieza_cartera.ipynb

# 3. Análisis de morosidad
jupyter nbconvert --execute notebooks/03_analisis_morosidad.ipynb

# 4. Actualizar segmentación con nuevos datos
jupyter nbconvert --execute notebooks/04_segmentacion_deudores.ipynb

# 5. Análisis de cosechas
jupyter nbconvert --execute notebooks/08_analisis_cosechas.ipynb

# 6. Regenerar reporte ejecutivo HTML
jupyter nbconvert --execute notebooks/07_reporte_ejecutivo.ipynb

echo "Dashboard actualizado - abrir http://localhost:8501"
Para el pitch: "Una vez configurado, actualizar el sistema el primer día de cada mes toma exactamente lo que tarda en correr ese script — unos 8 minutos. Sin intervención manual, sin exportar nada, sin llamar a un técnico."

¿Qué pasa si el cliente tiene columnas con nombres distintos?

El mapeo de columnas — paso 1 con cualquier cliente nuevo

Es normal que cada institución llame "DIAS_MORA" a lo que en el sistema es "ddm", o "FECHA_APERTURA" a lo que acá es "fec_operacion". La solución es un mapeo de columnas — una tabla de correspondencias que se configura una sola vez.

Ejemplo de mapeo en extraer_cartera.py
MAPA_COLUMNAS = {
    "DIAS_MORA":       "ddm",
    "FECHA_APERTURA":  "fec_operacion",
    "SALDO_CAPITAL":   "saldo_capital_cuota",
    "TASA_INTERES":    "tivbcp",
    "COD_AGENCIA":     "cod_su",
    "CATEGORIA_BCP":   "riesgo",
}

Columnas mínimas que debe tener la fuente:

nro_operacion fec_operacion monto_original plan valor_cuota tivbcp ddm saldo_capital_cuota ingreso_mensual riesgo califi cod_su
Tiempo típico de adaptación: 2 a 4 horas trabajando con el DBA del cliente para identificar las columnas equivalentes en su sistema.