Unidad 2 - El proceso analítico: de la pregunta a la decisión
Analítica para los negocios · Semana 5 · 06327-ECO
@emartigo
Eduard F. Martínez G.
eduard-martinez
eduard-martinez.github.io1 Cómo estudiar esta semana
Esta semana la fundamentación teórica llega en formato podcast: El proceso analítico: de la pregunta a la decisión.
Este documento es la versión escrita del podcast
Puedes escuchar el episodio, leer este documento, o hacer ambas cosas: cubren el mismo contenido. Este documento no es una transcripción literal; es una versión organizada para facilitar el estudio, con glosario, resúmenes por bloque y un caso real que atraviesa todas las etapas.
- 🎧 Podcast: escúchalo en Spotify.
- 📝 Quiz de teoría: en Intu, antes de la sesión de clase.
- 🧑💻 En clase: recorreremos el proceso completo sobre una pregunta de negocio real y cada grupo esbozará la suya.
⚠️ Atención, esta semana el trabajo previo tiene cola: al final de este documento hay una instrucción que no es opcional — traer a clase una pregunta de negocio propia. La sesión se construye sobre esa pregunta, y lo que salga de ahí es el insumo directo de la Entrega 1 del proyecto final. Llegar sin ella es llegar sin materia prima.
1.1 Lo que aprenderemos esta semana
1. Qué es Business Analytics, en serio
- Las cuatro patas que sostienen la mesa: estadística, programación, ciencia de datos y enfoque de negocio.
- Por qué la cuarta pata es la que más proyectos tumba.
2. El proceso analítico: siete etapas y un ciclo
- De la pregunta a la decisión, con un caso real de principio a fin.
- Dónde se va realmente el tiempo (spoiler: no es en el modelo).
3. Tipos de tareas analíticas
- Clasificación, predicción, segmentación, anomalías y optimización.
- La pregunta que te dice cuál usar, antes de escribir una línea de código.
4. Roles: nadie hace esto solo
- Quién lidera qué fase, y por qué el mejor modelo no salva un proyecto mal preguntado.
¿Y esto qué tiene que ver con lo que ya sabemos?
Todo lo anterior fueron herramientas: R (semana 3), dplyr y ggplot2 (semana 4). Sabes transformar datos y hacer gráficos. Esta semana damos un paso atrás y preguntamos: ¿para qué? El proceso analítico es el mapa donde esas herramientas encajan — vas a descubrir que la semana 4 completa era apenas una de siete etapas. Y a partir de la semana 6, cada semana del curso será una etapa de este mapa.
2 Glosario de la semana
Diez términos que aparecerán una y otra vez, en este curso y en cualquier entrevista de trabajo en analítica. Vuelve a esta tabla cada vez que un concepto se te escape: para eso está.
3 El 87% que nunca llegó
Empecemos por el dato incómodo:
Ochenta y siete de cada cien proyectos de datos mueren antes de ser usados. No porque el modelo estuviera malo. Las razones que más se repiten son cuatro, y fíjate bien en cuál de ellas es un problema técnico:
- ✗ La pregunta estaba mal definida.
- ✗ Los datos estaban sucios o incompletos.
- ✗ El modelo no generalizaba (funcionaba en el laboratorio, no en la calle).
- ✗ No había ninguna decisión clara esperando la respuesta.
Solo la tercera es un problema de modelado. Las otras tres son problemas de proceso: de no saber qué se pregunta, de no cuidar los datos, o de analizar algo que a nadie le iba a servir. Ese es el tema de esta semana, y es la razón por la que un curso de Business Analytics no arranca enseñando modelos.
La idea más importante de toda la semana
Un proyecto de analítica no es exitoso porque el modelo acierte. Es exitoso cuando cambia una decisión y genera valor medible. El modelo es un medio; la decisión es el fin. Todo lo demás de este documento sale de esa frase.
4 Qué es Business Analytics
4.1 Cuatro patas de la misma mesa
Business Analytics no es una técnica: es un proceso que transforma datos en conocimiento accionable para mejorar decisiones. Y ese proceso se sostiene sobre cuatro patas. Quítale una y la mesa se cae:
1. Estadística aplicada. Encontrar patrones, medir relaciones, distinguir lo que es señal de lo que es ruido. Es lo que te permite decir “esto no es casualidad” con algún fundamento.
2. Programación y tecnología. Automatizar, escalar y hacer el análisis reproducible. Un análisis que solo existe en tu cabeza, o en un Excel que nadie más entiende, no es un activo de la organización. (Esto es exactamente por qué en la semana 3 insistimos tanto con los scripts y las rutas relativas.)
3. Ciencia de datos. Los modelos predictivos y prescriptivos: la maquinaria que aprende de los datos. Es la pata más famosa y, como veremos, la que menos tiempo consume.
4. Enfoque de negocio. La analítica está al servicio de una decisión. Esta pata es la que decide si el proyecto vive o muere, y es justo la que suelen olvidar los equipos técnicos.
La pata que más proyectos tumba
Las tres primeras patas son habilidades que se aprenden con práctica. La cuarta es un criterio: saber para qué sirve lo que estás haciendo. Un analista con estadística, código y modelos pero sin enfoque de negocio produce trabajo impecable que nadie usa — y ese es buena parte del 87%.
5 El proceso analítico: siete etapas y un ciclo
5.1 La consulta médica
Piensa en un buen médico. Llegas al consultorio y no te manda de entrada a una resonancia magnética. Primero pregunta: ¿qué le duele, desde cuándo, cómo es el dolor? Con eso pide unos exámenes puntuales. Cuando llegan, lo primero que hace es mirar si tienen sentido (¿este resultado es tuyo?, ¿el laboratorio no se equivocó?). Los lee, forma un diagnóstico, te lo explica en palabras que entiendes y te receta un tratamiento. Y te cita en 30 días para ver si funcionó.
Un médico que hace la resonancia más sofisticada del mundo, diagnostica brillantemente y nunca receta nada no le sirvió de nada al paciente. Un médico que receta sin preguntar qué te duele es peligroso.
Eso es el proceso analítico. Siete etapas, y la última vuelve a la primera:
No es una línea recta: es un ciclo
La decisión genera nuevos datos (“¿quién respondió a la campaña?”), y esos datos generan nuevas preguntas (“¿cómo mejoramos la oferta?”). Además se itera hacia atrás todo el tiempo: la EDA te hace reformular la pregunta, el modelo te manda a buscar más datos. Si tu proceso fue una línea recta perfecta, probablemente no miraste con suficiente cuidado.
5.2 El caso que vamos a seguir
Para no hablar en abstracto, seguiremos un caso real por las siete etapas:
Una empresa de telecomunicaciones pierde el 25% de sus clientes al año. La gerencia quiere saber si se puede hacer algo antes de que se vayan.
Fíjate en algo: antes de mirar un solo dato ya tenemos números de negocio. Sabemos qué cuesta equivocarse. Ese es el enfoque de negocio de la cuarta pata, y es lo que va a determinar todas las decisiones técnicas que vienen.
5.3 Etapa 1: formular la pregunta
Una buena pregunta de negocio cumple tres condiciones:
- Específica: ¿qué, quién, cuándo?
- Accionable: ¿qué decisión cambia con la respuesta?
- Medible: ¿existen datos para responderla?
Míralo en el caso churn:
- ✗ “¿Por qué se van los clientes?” — Interesante, pero no específica (¿cuáles?, ¿cuándo?), y no dice qué haríamos mañana con la respuesta.
- ✓ “¿Qué clientes abandonarán en los próximos 30 días?” — Específica (quiénes, en qué ventana), accionable (a esos los llamamos) y medible (tenemos historial).
El test de la pregunta
Si te doy la respuesta ahora mismo, ¿sabes qué vas a hacer diferente mañana?
Si la respuesta es “no”, todavía no tienes una pregunta de negocio. Tienes un tema. Aplícale este test a la pregunta que vas a traer a clase — y a la de tu proyecto final.
Entregable de la etapa: la pregunta escrita, la decisión que va a cambiar, y el costo de equivocarse.
5.4 Etapa 2: conseguir los datos
Ya sabemos qué preguntar. ¿Qué exámenes pedimos?
- Datos internos: historial de facturación, consumo, reclamos, pagos.
- Datos externos: competencia, zona geográfica, nivel socioeconómico.
- El target: ¿el cliente se fue? (sí/no). Sin esta columna no hay problema supervisado que valga.
Los desafíos son casi siempre los mismos tres, y ninguno es estadístico: los datos viven en silos distintos (el CRM por un lado, la facturación por otro, soporte por otro), en formatos incompatibles, y con permisos y privacidad de por medio.
Entregable de la etapa: el dataset raw (sin procesar), un diccionario de variables y las fuentes documentadas.
5.5 Etapa 3: limpiar y preparar (el 80% del tiempo)
Aquí viene el dato que sorprende a todo el mundo que llega a este campo:
Cuatro de cada cinco horas del proyecto se van en dejar los datos utilizables. En el caso churn, esto significó:
- Valores faltantes en
antigüedad→ imputar con la mediana. - Duplicados por una migración de sistema → eliminar.
- Fechas imposibles (en el futuro) → corregir o descartar.
"plan A"vs."Plan_A"vs."PLAN A"→ estandarizar (para el computador son tres planes distintos).- Crear variables derivadas:
meses_desde_reclamo,ratio_pago_factura.
Esta etapa es la semana 6 completa
Todo lo que acabas de leer en cinco viñetas es el contenido de la próxima semana: diagnóstico, valores faltantes, duplicados, outliers y el flujo raw → clean → analysis-ready. Si esta lista te pareció trivial, la semana 6 te va a hacer cambiar de opinión.
Entregable de la etapa: dataset limpio + reporte de calidad de datos.
5.6 Etapa 4: explorar (EDA)
Objetivo: conocer los datos antes de modelar. Las preguntas típicas: ¿cómo se distribuyen las variables?, ¿hay outliers?, ¿qué está correlacionado con qué?, ¿están balanceadas las clases?, ¿hay patrones por segmento?
Hallazgos reales del caso churn:
- El 25% de los clientes hace churn → las clases están desbalanceadas (dato que va a cambiar la métrica que usemos).
- Clientes con más de 3 reclamos: 60% de churn → los reclamos son una señal potente.
- Los clientes de plan prepago hacen el doble de churn que los de pospago.
La regla de oro de la EDA
Si no lo graficas, no lo entiendes.
Y aquí es donde dplyr y ggplot2 de la semana 4 dejan de ser un ejercicio de sintaxis y se vuelven la herramienta de trabajo real.
Entregable de la etapa: 3-5 hallazgos clave + los gráficos que los sustentan + los riesgos detectados.
5.7 Etapa 5: construir y validar el modelo
Solo ahora — en la etapa 5 de 7 — aparece el modelo. En el caso churn es un problema de clasificación: ¿se va o no se va?
La idea central (que veremos a fondo en la semana 10) es que no se evalúa un modelo con los mismos datos con los que se entrenó: se separa train (70%) para que aprenda y test (30%) para validarlo fuera de muestra. Es la diferencia entre un examen con las respuestas a la vista y un examen de verdad.
La métrica elegida fue recall (sensibilidad), y la razón es puro negocio: queremos atrapar la mayor cantidad posible de clientes que se van, porque un falso negativo cuesta más que un falso positivo. Dejar ir a un cliente que sí se iba cuesta $500; llamar por si acaso a uno que no se iba cuesta $100. La asimetría del costo decide la métrica.
Contra un baseline del 50%, el modelo aporta. Sin ese baseline, el 75% no significaría nada.
Entregable de la etapa: modelo + métricas + validación + código reproducible.
5.8 Etapa 6: comunicar los resultados
Tienes el modelo. No basta. Hay que traducirlo a decisión, y ese es un problema de idioma.
- ✗ “El modelo tiene 80% de accuracy.” — ¿Y eso qué significa para el negocio? El gerente no sabe qué hacer con esa frase.
- ✓ “Identificamos 2.500 clientes con 75% de probabilidad de irse. Si los contactamos con una oferta de retención de $100, recuperamos el 60% y ahorramos $750.000 frente a dejarlos ir.”
La segunda frase tiene los tres elementos que necesita un stakeholder: números, no jerga técnica; costo-beneficio claro; y una acción recomendada.
El error más común de los analistas jóvenes
Presentar la métrica en vez de la consecuencia. Nadie fuera del equipo técnico sabe si 80% de accuracy es bueno o malo — de hecho, si el 80% de tus clientes se queda, un modelo que diga “nadie se va” también tiene 80% de accuracy y es completamente inútil. Traduce siempre a plata, riesgo o tiempo.
5.9 Etapa 7: decidir y actuar (y volver a empezar)
La decisión: contactar a los 2.500 clientes de alto riesgo.
El plan de acción: segmentar por valor (los VIP primero), asignar al call center, hacer la oferta personalizada y medir el resultado a 30 días.
El monitoreo (los KPIs que ahora sabes construir): % de contactados que aceptan, % de contactados que finalmente no hicieron churn, ROI de la campaña (ahorro vs. costo), y actualizar el modelo cada trimestre.
Y aquí se cierra el ciclo: la campaña genera nuevos datos (¿quién respondió?, ¿qué oferta funcionó mejor?) que producen una nueva pregunta (¿cómo mejoramos la oferta?) y el proceso arranca otra vez. Es el control a los 30 días del médico.
Resumen del bloque
Siete etapas: pregunta → datos → limpieza → EDA → modelo → comunicación → decisión, y de vuelta a la pregunta. El modelo es una de ellas y consume el 20% del tiempo. Las etapas 1, 6 y 7 — preguntar, traducir y decidir — no requieren una sola línea de código, y son donde se pierde la mayoría de los proyectos.
6 Tipos de tareas analíticas: el mapa del territorio
No todo análisis es igual. Según la pregunta, cambia la tarea — y cambian los datos que necesitas, el modelo, la métrica y el entregable. Elegir mal la tarea al principio es un error que ninguna sofisticación posterior arregla.
6.1 Clasificación (supervisada)
Pregunta: ¿a qué categoría pertenece? ¿Sí o no?
- ¿Este email es spam?
- ¿Este cliente hará churn?
- ¿Este crédito es de riesgo alto, medio o bajo?
Output: una etiqueta o una probabilidad. Decisión que habilita: filtrar, priorizar, bloquear, activar. Métricas típicas: accuracy, precision, recall, F1.
Caso churn: cliente 12345 → probabilidad de fuga 85% → acción: llamar hoy.
6.2 Predicción (supervisada)
Pregunta: ¿cuánto? ¿cuándo?
- ¿Cuánto venderé el próximo mes?
- ¿Cuál será la demanda de este producto?
- ¿En cuántos días llegará el paquete?
Output: un número continuo. Decisión que habilita: planear inventario, capacidad, presupuesto. Métricas típicas: RMSE, MAE, MAPE.
Ejemplo retail: producto XYZ → demanda estimada 1.250 unidades → acción: comprar stock.
6.3 Segmentación (no supervisada)
Pregunta: ¿qué grupos naturales existen aquí?
- ¿Qué perfiles de clientes tengo?
- ¿Qué zonas geográficas se parecen entre sí?
Output: grupos (clusters). Decisión que habilita: personalizar la oferta, diseñar campañas por segmento.
Ejemplo: 10.000 clientes → 4 segmentos (VIP, Frecuente, Ocasional, Inactivo) → acción: una campaña distinta para cada uno.
La diferencia clave con clasificación
En segmentación no hay target: nadie etiquetó previamente quién es “VIP”. El algoritmo descubre los grupos, y luego un humano los interpreta y les pone nombre. En clasificación, en cambio, tienes ejemplos históricos que ya traen la respuesta correcta.
6.4 Detección de anomalías (mixta)
Pregunta: ¿qué es raro aquí?
- ¿Esta transacción es fraudulenta?
- ¿Este sensor está fallando?
Output: una lista de observaciones atípicas priorizadas. Decisión que habilita: investigar, bloquear, alertar. Es mixta porque a veces tienes fraudes históricos etiquetados (supervisada) y a veces solo tienes lo que se sale de lo normal (no supervisada).
6.5 Optimización (prescriptiva)
Pregunta: dadas mis restricciones, ¿cuál es la mejor decisión posible?
- ¿Cómo asigno mi presupuesto de pauta entre canales para maximizar ventas?
- ¿Cuál es la ruta de despacho más barata que cumple todas las entregas?
Output: una decisión recomendada, no solo una predicción. Es el nivel más ambicioso: la analítica descriptiva dice qué pasó, la predictiva qué va a pasar, y la prescriptiva qué deberías hacer al respecto.
6.6 La pregunta que decide la tarea
| Tarea | ¿Hay target? | Output | Ejemplo |
|---|---|---|---|
| Clasificación | Sí | Categoría | Churn sí/no |
| Predicción | Sí | Número | Ventas $1.250 |
| Segmentación | No | Grupos | 4 perfiles de cliente |
| Anomalías | Mixto | Lista de outliers | 5 transacciones sospechosas |
| Optimización | — | Decisión | Cómo repartir el presupuesto |
La pregunta que lo resuelve casi siempre
¿Tengo ejemplos históricos que ya traen la respuesta correcta?
- Sí → supervisado (clasificación si la respuesta es una categoría; predicción si es un número).
- No → no supervisado (segmentación).
Resumen del bloque
Cinco tareas: clasificación (¿qué categoría?), predicción (¿cuánto?), segmentación (¿qué grupos?), anomalías (¿qué es raro?) y optimización (¿qué hago?). La pregunta de negocio determina la tarea; la tarea determina el modelo y la métrica. En tu proyecto final trabajarás una de las tres primeras.
7 Roles: nadie hace esto solo
El proceso completo exige habilidades que rara vez viven en una sola cabeza. Por eso existen cuatro roles:
🔧 Data Engineer. Construye los pipelines, integra las fuentes, limpia y garantiza la calidad. Es quien hace posible que los demás tengan datos con los que trabajar.
📊 Data Analyst. Explora los datos, construye dashboards, interpreta y comunica hallazgos descriptivos. Es el dueño de la EDA.
🤖 Data Scientist. Construye modelos, los valida, experimenta. Es el rol más famoso y el que menos etapas lidera.
💼 Business Analyst / Data Translator. Traduce en las dos direcciones: convierte el problema de negocio en pregunta analítica, y los resultados técnicos en recomendaciones. Es el puente.
En equipos pequeños, una persona cumple varios roles — probablemente tú, en tu primer trabajo, seas los cuatro a la vez. En equipos grandes, se especializan. Pero los cuatro trabajos se hacen siempre, tenga la empresa cuatro personas o cuarenta.
7.1 ¿Quién hace qué?
| Rol | Pregunta | Datos | Limpieza | EDA | Modelo | Decisión |
|---|---|---|---|---|---|---|
| Data Engineer | Apoya | Lidera | Lidera | Apoya | Apoya | — |
| Data Analyst | Colabora | Apoya | Apoya | Lidera | Apoya | Colabora |
| Data Scientist | Colabora | Apoya | Apoya | Colabora | Lidera | Apoya |
| Business Analyst | Lidera | Apoya | — | Colabora | Apoya | Lidera |
Lee la tabla de nuevo, mirando las filas
El Data Scientist, el rol estrella, lidera una sola de las seis fases. El Business Analyst, que no toca un modelo, lidera las dos que deciden si el proyecto sirve o no. El valor no está solo en el modelo: sin una pregunta clara (BA) y sin datos limpios (DE), el mejor modelo del mundo (DS) no sirve para nada.
7.2 El caso churn: cómo trabajaron los cuatro
- Business Analyst definió la pregunta (“¿quiénes harán churn?”), el costo del error ($500 vs. $100) y el umbral de decisión (probabilidad > 70%).
- Data Engineer integró CRM + facturación + soporte, eliminó duplicados, estandarizó formatos y creó las variables derivadas.
- Data Analyst exploró los patrones (reclamos → churn), detectó el desbalanceo de clases y propuso segmentar por valor.
- Data Scientist entrenó el modelo, validó con train/test, eligió la métrica (recall), comparó contra el baseline y dejó el código documentado.
- Business Analyst, otra vez al final, comunicó la recomendación ($750.000 de ahorro potencial), diseñó el plan de acción y definió los KPIs de seguimiento.
El proyecto funcionó porque cada uno aportó lo suyo — y porque alguien se ocupó del principio y del final, no solo de la mitad.
Resumen del bloque
Cuatro roles: Data Engineer (datos y limpieza), Data Analyst (EDA), Data Scientist (modelo) y Business Analyst (pregunta y decisión). En tu proyecto final, tu grupo va a cumplir los cuatro. Que quede claro quién hace qué y que nadie abandone las etapas 1, 6 y 7.
8 Para pensar: ¿qué define el éxito?
Un proyecto no es exitoso porque el modelo tenga 95% de accuracy. Es exitoso cuando cambia una decisión y genera valor medible.
Cuatro preguntas para llevarle a tu propio proyecto — y para hacerte en cualquier trabajo de analítica que tengas en la vida:
- ¿Qué decisión específica va a cambiar con mi análisis?
- ¿Cuánto cuesta equivocarse? (¿y cuesta lo mismo un falso positivo que un falso negativo?)
- ¿Qué métrica se alinea con esa decisión?
- ¿Cómo voy a medir el impacto real de lo que recomendé?
Si no puedes responder la primera, las otras tres sobran. 🎤
9 Para la clase presencial: trae 1 pregunta de negocio
Esto no es opcional: es la materia prima de la sesión
Piensa en una pregunta de negocio real que te gustaría resolver con datos. Puede ser de cualquier industria: retail, fintech, salud, educación, entretenimiento, deporte, lo que te interese.
Criterios (los mismos tres de la etapa 1):
- ✅ Específica — no “mejorar las ventas”.
- ✅ Accionable — debe implicar una decisión clara.
- ✅ Medible — con datos que podrían existir.
Ejemplo del tipo de pregunta (no lo copies): “¿Qué productos debería promocionar en Black Friday para maximizar el margen?” → Decisión: cuáles promocionar y cuánto descontar.
En clase discutiremos en grupos qué tarea analítica es cada pregunta, qué fases requiere y qué roles participan. Y saldrás con el borrador de la pregunta de tu proyecto: es el insumo directo de la Entrega 1.
10 Checklist de salida
Al terminar el podcast (o este documento), debes ser capaz de:
11 Preguntas de comprensión
Del estilo de las que encontrarás en el quiz. Intenta responderlas antes de abrir la respuesta.
1. El modelo impecable
Un equipo presenta con orgullo un modelo con 94% de accuracy para predecir qué clientes cancelarán su suscripción. El gerente pregunta: “¿y ahora qué hacemos?” y nadie sabe responder. ¿En qué etapa falló el proyecto y por qué el 94% no lo salva?
Ver respuesta
Falló en la etapa 1: nunca hubo una decisión esperando la respuesta. Es una de las cuatro razones del 87%. Un modelo que no cambia ninguna decisión no genera valor, por bueno que sea — el proyecto era técnicamente correcto y estratégicamente inútil. Además, con 94% de accuracy conviene sospechar del desbalanceo: si solo el 6% cancela, decir "nadie cancela" da 94% y no sirve para nada.
2. La métrica y el costo
En el caso churn, un falso negativo (dejar ir a alguien que sí se iba) cuesta $500 y un falso positivo (llamar a alguien que no se iba) cuesta $100. ¿Por qué se eligió recall y no accuracy? ¿Cambiaría tu elección si el incentivo costara $2.000?
Ver respuesta
Se eligió recall porque mide qué proporción de los que sí se van logramos atrapar, y el error caro es justamente dejarlos escapar ($500 > $100). Con el costo del error asimétrico, conviene equivocarse "de más" llamando gente de sobra. Si el incentivo costara $2.000, la asimetría se invierte: cada falso positivo costaría más que el cliente perdido, y pasaríamos a priorizar precision. La lección: la métrica sale del negocio, no del código.
3. La tarea correcta
Clasifica cada pregunta según su tarea analítica y di si es supervisada o no: (a) “¿Cuántas unidades venderemos en diciembre?” (b) “¿Qué tipos de clientes tenemos?” (c) “¿Esta transacción con tarjeta es fraudulenta?”
Ver respuesta
(a) Predicción, supervisada — el output es un número continuo y tenemos historial de ventas con la respuesta correcta. (b) Segmentación, no supervisada — nadie etiquetó previamente los "tipos": el algoritmo los descubre. (c) Detección de anomalías / clasificación — si tenemos fraudes históricos etiquetados es clasificación supervisada; si solo tenemos "lo que se sale de lo normal", es detección de anomalías no supervisada. El atajo en los tres casos: ¿tengo la respuesta correcta en los datos históricos?
4. El reparto de culpas
Un proyecto se cae porque, después de tres meses, se descubre que la variable clave estaba mal capturada en el CRM desde hacía dos años. El equipo culpa al Data Scientist. ¿Es justo? ¿Qué etapa y qué rol fallaron?
Ver respuesta
No es justo. Falló la etapa 3 (limpieza y validación), que lidera el Data Engineer, con apoyo del Data Analyst en la etapa 4 (EDA), donde ese problema de calidad debió aparecer. El Data Scientist apoya ambas etapas pero no las lidera. Y hay una lección de proceso más grande: el problema se detectó a los tres meses, cuando la EDA existe justamente para encontrarlo en la primera semana. Es el argumento entero de la semana 6.
11.1 Material adicional (opcional)
Si quieres profundizar por tu cuenta:
- El dato del 87%: VentureBeat (2019), Why do 87% of data science projects never make it into production?
- El libro de referencia del proceso analítico: Provost, F., & Fawcett, T. (2013). Data Science for Business: What You Need to Know about Data Mining and Data-Analytic Thinking. O’Reilly Media. — El capítulo 2 es exactamente el tema de esta semana.
- La mirada estratégica: Davenport, T. H., & Harris, J. G. (2007). Competing on Analytics: The New Science of Winning. Harvard Business Press.
- Sobre los roles: Harris, H., Murphy, S., & Vaisman, M. (2013). Analyzing the Analyzers: An Introspective Survey of Data Scientists and Their Work. O’Reilly Media.
- El caso churn, en versión académica: Verbeke, W., Dejaeger, K., Martens, D., Hur, J., & Baesens, B. (2012). New insights into churn prediction in the telecommunication sector: A profit driven data mining approach. European Journal of Operational Research, 218(1), 211–229.
Para esta semana, el podcast (o este documento) es suficiente. Nos vemos en clase — y recuerda traer tu pregunta de negocio. 🚀
Los recursos de esta semana → esta teoría continúa en la práctica guiada en clase y cierra con el taller evaluable.