✅ 1. SOP BDS – Data Intake & Profiling (texto listo para Word)

Propietario: Oficina de Entrega BDS Aplicación: Todos los proyectos CRISP-DM

⁠

I. Objetivo

Estandarizar la recepción, validación, perfilamiento y diagnóstico de calidad de datos provenientes de clientes, sin importar el formato (Excel, CSV, TXT, JSON, JSONL, Parquet, Feather o ZIP), garantizando:

Velocidad en el entendimiento inicial.

Eliminación de retrabajos y ciclos de corrección.

Trazabilidad y reproducibilidad de análisis.

Alineación con prácticas de fábrica analítica en BDS.

⁠

II. Alcance

Este procedimiento se utiliza desde la entrega del primer archivo hasta su validación formal para continuar a la fase de Data Understanding de CRISP-DM.

Cubre:

Intake de datos en múltiples formatos.

Validación estructural y semántica.

Perfilamiento automático.

Generación de reportes HTML y hallazgos.

Comunicación con cliente.

⁠

III. Roles involucrados

Data Intake Owner (DIO): ejecuta pipeline, documenta hallazgos.

Data Engineer: confirma integridad, schemas y normalización.

Data Scientist: revisa descripciones y riesgos para modelado.

Project Manager: comunica hallazgos al cliente (<2 horas).

Cliente: corrige archivos y valida el data contract.

⁠

IV. Proceso estándar

1. Handshake previo

Definir tipos de archivo permitidos: .xlsx, .xls, .csv, .tsv, .txt, .json, .jsonl, .parquet, .feather, .zip.

Solicitar delimitador estándar para archivos planos o indicación explícita si no es estándar.

Acordar codificación esperada: UTF-8, Latin-1, CP1252 (crítico para bancos).

Compartir ejemplo mínimo (200 filas) por cada formato.

Documentar schema esperado, incluso si el archivo no tiene encabezado.

Definir naming convention homogénea sin importar el formato.

Alinear diccionario de datos y revalidar llaves, granularidad y lógica de negocio.

⁠

2. Recepción del archivo (detector de formato automático)

El pipeline debe:

Detectar tipo de archivo.

Seleccionar el lector adecuado.

Unificar encabezados y codificación.

Perfilar y validar en menos de 1 minuto.

⁠

3. Exploración estructural para cualquier formato

¿Los encabezados y metadatos (incluyendo BOM) son detectables y están correctamente formados?

¿El delimitador y las reglas de separación (comillas, escapes) son consistentes en todas las filas?

¿Todas las filas mantienen la misma cantidad de columnas sin rupturas por saltos o comillas mal balanceadas?

¿Las estructuras jerárquicas o anidadas (JSON/JSONL) están completas y son normalizables?

¿El schema declarado o inferido (tipos, nombres, orden) coincide con lo esperado para el archivo?

¿Los formatos binarios (parquet/feather) presentan un schema íntegro, compatible y libre de columnas inesperadas?

Si el archivo es un ZIP, ¿contiene únicamente los archivos tabulares esperados y está claramente identificado el archivo principal?

⁠

4. Perfilamiento automático

Descriptivas numéricas

count

mean, std

min, 25%, 50%, 75%, max

número de ceros

% de nulos

coeficiente de variación

outliers (IQR y Z-score)

Descriptivas categóricas

Cardinalidad

Top 20 categorías y su frecuencia

Categorías con menos de 5 registros (riesgo ML)

Texto libre con distribución de longitud

Detección de valores atípicos (“NA”, “.”, “?”, “null”, “n/a”)

Validación de fechas y rangos

Rango de fechas

Huecos y saltos inesperados

Registros fuera de ventana de negocio

Estacionalidad rápida (conteo por día/semana/mes)

Detectar saltos, baja calidad y ruido

⁠

5. Reportes entregables

El sistema genera automáticamente:

Reporte HTML (reporte_bds_universal.html)

Log de problemas (quality_log.json)

Diccionario inferido (schema_detected.json)

⁠

6. Comunicación con cliente (< 2 horas)

Enviar:

Lista de errores detectados.

Recomendaciones de corrección.

Confirmación de si el archivo “pasa/no pasa” para modelado.

⁠

7. Cierre de Intake

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Standard Operating Procedure (SOP) – Data Intake & Profiling