Del modelo entrenado al impacto real en el negocioFrom the trained model to real business impact
Un modelo con 97% de exactitud que nadie usa vale cero. Este es, quizás, el error más común y más caro en ciencia de datos: confundir un logro técnico con un logro de negocio. PMBOK 8 dedica uno de sus 6 principios exclusivamente a esto — Enfoque en el Valor — y en este módulo lo traducimos directamente al trabajo de un Data Scientist. A model with 97% accuracy that nobody uses is worth zero. This is, perhaps, the most common and most expensive mistake in data science: confusing a technical achievement with a business achievement. PMBOK 8 dedicates one of its 6 principles entirely to this — Focus on Value — and in this module we translate it directly into a Data Scientist's work.
PMBOK 8 es explícito: el valor no es el entregable en sí, y ni siquiera es "usar" el entregable. El valor es el beneficio neto, medido contra lo que costó producirlo, sostenido en el tiempo. Para verlo con claridad, hay que distinguir cuatro escalones: PMBOK 8 is explicit: value is not the deliverable itself, and it isn't even "using" the deliverable. Value is the net benefit, measured against what it cost to produce, sustained over time. To see it clearly, we need to distinguish four rungs:
Lo que el equipo entrega. Un archivo de modelo entrenado (churn_model_v3.pkl) con 89% de exactitud. What the team delivers. A trained model file (churn_model_v3.pkl) with 89% accuracy.
Lo que cambia al usarlo. El equipo de retención contacta proactivamente a los 500 clientes con mayor probabilidad de fuga cada semana. What changes by using it. The retention team proactively contacts the 500 highest-risk customers every week.
La mejora medible. La tasa de churn mensual baja de 5.2% a 3.8%. The measurable improvement. Monthly churn rate drops from 5.2% to 3.8%.
El beneficio neto de costo. $340,000 USD anuales en ingresos retenidos, menos $28,000 USD de costo de nube y equipo — ROI positivo sostenido. The net-of-cost benefit. $340,000 USD/year in retained revenue, minus $28,000 USD in cloud and team cost — sustained positive ROI.
Cuando reportes tu proyecto a un Sponsor, nunca te quedes en la "Salida" (accuracy, F1-score). Sube la escalera hasta "Valor". Un Sponsor no aprueba presupuesto para un mejor F1-score; lo aprueba para dólares retenidos. When you report your project to a Sponsor, never stop at "Output" (accuracy, F1-score). Climb the ladder up to "Value." A Sponsor doesn't approve budget for a better F1-score; they approve it for retained dollars.
El Caso de Negocio es el documento que justifica por qué vale la pena invertir en el proyecto, antes de escribir el Charter. Es la primera prueba del Enfoque de Valor: si no puedes justificarlo aquí, el proyecto no debería aprobarse. The Business Case is the document that justifies why the project is worth investing in, before the Charter is even written. It's the first test of Focus on Value: if you can't justify it here, the project shouldn't be approved.
NovaRetail pierde 5.2% de sus clientes cada mes sin previo aviso.NovaRetail loses 5.2% of its customers every month with no warning.
¿Encuesta manual? ¿Reglas simples de negocio? ¿Modelo predictivo de ML?Manual survey? Simple business rules? Predictive ML model?
Modelo de ML: escalable, más preciso que reglas fijas, con datos ya disponibles.ML model: scalable, more accurate than fixed rules, using already-available data.
Reducir el churn en al menos 1 punto porcentual dentro de 4 meses de operación.Reduce churn by at least 1 percentage point within 4 months of operation.
En el taller del Project Charter (siguiente parada del curso) partirás exactamente de este Caso de Negocio — es el documento que el Sponsor firma antes de autorizar el Charter de Atlas. In the Project Charter workshop (the course's next stop) you'll start exactly from this Business Case — it's the document the Sponsor signs before authorizing the Atlas Charter.
Es muy fácil optimizar la métrica equivocada. Aquí dos pares de ejemplo, lado a lado, del mismo problema de negocio: It's very easy to optimize the wrong metric. Here are two example pairs, side by side, of the same business problem:
El equipo logra 96% de accuracy general prediciendo churn — pero como solo el 5% de los clientes de hecho se van, el modelo simplemente predice "no se va" casi siempre. Nunca detecta a los clientes que realmente importan. The team achieves 96% overall accuracy predicting churn — but since only 5% of customers actually leave, the model simply predicts "won't leave" almost always. It never catches the customers that actually matter.
El equipo optimiza recall sobre la clase de churn (atrapar a la mayor cantidad posible de clientes en riesgo real), aceptando algunos falsos positivos, porque contactar de más a un cliente cuesta mucho menos que perderlo. The team optimizes recall on the churn class (catching as many real at-risk customers as possible), accepting some false positives, because over-contacting a customer costs far less than losing them.
Un modelo de deep learning con 2% más de exactitud que nadie en el equipo de retención entiende ni confía lo suficiente para actuar sobre él. Se queda archivado. A deep-learning model with 2% more accuracy that no one on the retention team understands or trusts enough to act on. It ends up shelved.
Un modelo de regresión logística, algo menos preciso pero interpretable, que el equipo de retención entiende y usa todos los días para priorizar llamadas. A logistic regression model, slightly less accurate but interpretable, that the retention team understands and uses every day to prioritize calls.
Antes de elegir tu métrica de modelo (accuracy, precision, recall, RMSE...), pregunta primero: "¿qué error le cuesta más caro al negocio: un falso positivo o un falso negativo?" Esa respuesta de negocio debe definir tu métrica técnica — nunca al revés. Before choosing your model metric (accuracy, precision, recall, RMSE...), first ask: "which error costs the business more: a false positive or a false negative?" That business answer should define your technical metric — never the other way around.
Usa esta cadena de valor como plantilla mental antes de escribir una sola línea de código: empieza siempre por el objetivo de negocio, y baja hasta la métrica técnica — nunca al revés. Use this value chain as a mental template before writing a single line of code: always start from the business objective, and work your way down to the technical metric — never the other way around.
| Objetivo de NegocioBusiness Objective | Pregunta de DatosData Question | Métrica TécnicaTechnical Metric | Valor RealizadoRealized Value |
|---|---|---|---|
| Reducir fuga de clientesReduce customer churn | ¿Quién se va a ir?Who's going to leave? | Recall en clase de churnRecall on churn class | Ingresos retenidos ($)Retained revenue ($) |
| Detectar fraudeDetect fraud | ¿Qué transacción es sospechosa?Which transaction is suspicious? | Precision en clase de fraudePrecision on fraud class | Pérdidas evitadas ($)Losses avoided ($) |
| Optimizar inventarioOptimize inventory | ¿Cuánto se venderá la próxima semana?How much will sell next week? | MAPE del pronóstico de demandaDemand forecast MAPE | Costo de sobre-stock evitado ($)Avoided overstock cost ($) |
| Aumentar conversiónIncrease conversion | ¿Qué oferta le interesa a este usuario?What offer interests this user? | Click-through rate del modeloModel click-through rate | Ingresos incrementales ($)Incremental revenue ($) |
Practica escribir esta cadena de valor completa, de un extremo al otro, para cualquier idea de proyecto que se te ocurra. Si te atoras en el paso 1 ("¿cuál es el objetivo de negocio?"), probablemente todavía no deberías empezar a programar. Practice writing out this full value chain, end to end, for any project idea you come up with. If you get stuck at step 1 ("what's the business objective?"), you probably shouldn't start coding yet.
Un error común de equipos jóvenes de datos: celebrar cuando el modelo llega a producción, y dejar de medir. PMBOK 8 es claro — el valor se confirma después del cierre del proyecto, a veces meses o años más tarde, y alguien debe ser responsable de medirlo. A common mistake for young data teams: celebrating when the model reaches production, and then stopping measurement. PMBOK 8 is clear — value is confirmed after the project closes, sometimes months or years later, and someone must be accountable for measuring it.
Antes del proyecto: churn de 5.2% (línea base). Durante el proyecto: se construye y valida el modelo (no hay valor todavía, solo costo). Al cierre: el modelo se despliega — esto sigue siendo "Salida", no "Valor". 3 meses después del cierre: el Benefits Owner (el gerente de retención de NovaRetail) confirma que el churn bajó a 3.8% y reporta el ahorro real al Sponsor. Solo entonces se confirma el valor. Before the project: 5.2% churn (baseline). During the project: the model is built and validated (no value yet, only cost). At closing: the model is deployed — this is still "Output," not "Value." 3 months after closing: the Benefits Owner (NovaRetail's retention manager) confirms churn dropped to 3.8% and reports the real savings to the Sponsor. Only then is value confirmed.
Siempre pregunta en tu Charter: "¿quién es el dueño de medir el beneficio después de que mi equipo se vaya?" Si nadie puede responder esa pregunta, el beneficio probablemente nunca se medirá — y el proyecto, por definición de PMBOK 8, no habrá generado valor comprobado. Always ask in your Charter: "who owns measuring the benefit after my team moves on?" If no one can answer that question, the benefit will probably never be measured — and the project, by PMBOK 8's definition, won't have generated proven value.