Cómo construir una estrategia de Ciencia de Datos para cualquier tamaño de equipo

Construir estrategia de Ciencia de Datos para cualquier equipo

Crear una cultura y práctica que sea rápida y resistente al cambio

Crear una cultura y práctica que sea rápida y resistente al cambio

Si eres un líder en ciencia de datos a quien se le ha pedido “crear nuestra estrategia de ciencia de datos” con mucha libertad y poca dirección, esta publicación te ayudará. Cubriremos:

• Lo que queremos decir con estrategia: ¿Es solo un plan? ¿Una hoja de ruta? ¿Algo más o menos? En esta sección seremos específicos y adoptaremos una definición de trabajo de lo que estamos construyendo cuando creamos una estrategia.
• ¿Cómo se aplica este concepto a un equipo de ciencia de datos en un contexto organizacional práctico? Aquí examinaremos cómo se aplica nuestro concepto de estrategia a la ciencia de datos y seremos específicos sobre a qué se aplica nuestra estrategia.
• Cómo redactar esa estrategia en realidad.

A lo largo del artículo, nos basaremos en enfoques estratégicos para I+D, que comparten desafíos clave con la ciencia de datos: la misión de innovar y la mayor incertidumbre que conlleva la búsqueda del descubrimiento. Al finalizar, obtendrás una definición clara de estrategia y un proceso útil para redactar una para una organización de cualquier tamaño.

¿Qué es una estrategia?

Si, como yo, no tienes un MBA elegante y nunca has tomado un seminario de estrategia empresarial, es posible que te preguntes qué exactamente quiere alguien cuando te pide que desarrolles una “estrategia de ciencia de datos”. Y es posible que no encuentres búsquedas iniciales muy útiles. Marcos clásicos y poderosos como el modelo de las Tres C (clientes, competidores, empresa) tienen mucho sentido a nivel de una corporación que determina dónde debe competir. Aplicarlo a una función o equipo te hará sentir que estás estirando los conceptos más de lo que pueden soportar.

Si realmente eres como yo, te sumergirás en una madriguera de conejo bastante profunda leyendo libros como “Lords of Strategy” y “The McKinsey Way”. (Enlaces de afiliados.) El primero es un trabajo encantador de historia empresarial y el segundo es una colección útil de técnicas extraídas de la experiencia de consultores exitosos en la prestigiosa firma. Ninguno ofrece una respuesta rápida a la pregunta. Uno de los efectos secundarios muy beneficiosos de leer Lords of Strategy es aprender que los científicos de datos no están solos: “[E]s fácil confundir la estrategia con la planificación estratégica, pero también es peligroso. […] todavía hoy, hay muchas más empresas que tienen un plan que las que tienen una estrategia. Raspa la mayoría de los planes y encontrarás alguna versión de ‘Vamos a seguir haciendo lo que hemos estado haciendo, pero el próximo año haremos más y/o mejor'”. Esta confusión de definiciones ha aparecido en mi experiencia, donde varias veces una solicitud de una estrategia se redujo a “¿Cuál es tu plan para los próximos meses?”

• Dominio de Amazon SageMaker en modo solo VPC para admitir SageMaker Studio con configuración de ciclo de vida de apagado automático y SageMaker Canvas con Terraform
• Matemáticos encuentran 12,000 soluciones para el problema de los tres cuerpos
• ¿Qué tienen en común las neuronas, las luciérnagas y bailar el Nutbush?

Una definición muy útil de estrategia, y la que adoptaremos en el resto de este artículo, se debe a este documento de trabajo sobre estrategia de I+D de Gary Pisano: “Una estrategia no es más que un compromiso con un patrón de comportamiento destinado a ayudar a ganar una competencia”. La belleza de esta definición es que puede aplicarse en todos los niveles y propósitos de una organización. Todos los equipos, de todos los tipos y tamaños, contribuyen a los esfuerzos competitivos de la organización y todos los equipos pueden definir y declarar los patrones de comportamiento que utilizan para enfocar esos esfuerzos.

Una estrategia no es más que un compromiso con un patrón de comportamiento destinado a ayudar a ganar una competencia”.

—Gary Pisano

Pisano ofrece tres requisitos de una buena estrategia: consistencia, coherencia y alineación. Una estrategia debería ayudarnos a tomar decisiones consistentes que contribuyan, acumulativamente, hacia un objetivo deseado; debería ayudar a todas las áreas de una organización a cohesionar sus decisiones tácticas dispersas; y debería alinear las acciones locales con un esfuerzo colectivo más amplio.

Y finalmente, todas se basan en hipótesis fundamentales, apuestas sobre qué proporcionará ventaja en una competencia. El ejemplo útil de Pisano es el de Apple, cuya estrategia “desarrollar productos fáciles de usar y estéticamente atractivos que se integren perfectamente con un sistema más amplio de dispositivos en el mundo digital del consumidor” se basa en una hipótesis fundamental “que los clientes estarán dispuestos a pagar un precio significativamente más alto por productos con estas características”.

En esencia, bajo esta definición todas las estrategias son apuestas que encapsulan la lógica de la toma de decisiones: proporcionan a todas las partes un medio para determinar qué acciones ayudan a un esfuerzo colectivo.

Adoptaremos esta definición de estrategia y nos esforzaremos en definir nuestra propia hipótesis estratégica central sobre cómo la ciencia de datos agregará valor a nuestra organización y los patrones a los que nos comprometeremos en la búsqueda de ese valor. Además, asumiremos que nuestra organización matriz tiene una estrategia desarrollada propia y esta información será crucial cuando apliquemos la tercera prueba de alineación. Habiendo definido la forma que debería tomar nuestra estrategia final, ahora dirigiremos nuestra atención a delimitar su alcance.

¿Qué queremos decir con ciencia de datos y cómo se aplica este concepto de estrategia?

Para recordarles a mis amigos lo divertido que soy, envié varios mensajes de texto iguales que decían: “¿Qué piensas cuando escuchas ‘estrategia de ciencia de datos’?” Las respuestas variaron desde puntos muy reflexivos sobre la infraestructura de datos y MLOps, hasta cierto escepticismo saludable sobre la vaguedad de la pregunta (me siento identificado), o respuestas más coloridas como “Disparate” y “Mi trabajo ideal”.

Una muestra pequeña, pero la variedad de respuestas de este grupo, que incluía experimentados gerentes de producto tanto de startups como de grandes empresas, un líder de ciencia de datos y un consultor, demuestra lo confusas que pueden llegar a ser las definiciones de este término. Peor aún, los científicos de datos sufren una segunda fuente de confusión: lo que se anuncia como “ciencia de datos”, en la práctica, a menudo se deriva de las habilidades que una empresa desea reclutar y se viste con un título de moda.

Para fijar uno de estos grados de libertad en nuestro análisis, primero adoptaremos una definición común de ciencia de datos para el resto de este artículo: la función dedicada a crear valor y ventaja competitiva a partir de la modelización de los datos disponibles en una organización. Esto puede tomar algunas formas típicas:

• Construir modelos de aprendizaje automático que optimicen las decisiones dirigidas al cliente en producción
• Construir modelos que ayuden al personal en todos los niveles a completar su trabajo, tal vez en aplicaciones “human-in-the-loop” orientadas al cliente
• Construir modelos interpretables para inferencias que ayuden en la toma de decisiones empresariales

Observe que excluimos la inteligencia empresarial y el análisis, y lo hacemos únicamente por motivos de enfoque y no porque sean menos valiosos que el trabajo de modelización. Su área de análisis y su área de ciencia de datos deben colaborar sin problemas. (He escrito sobre esto aquí).

Algunos, como mi amiga Carol Skordas Walport, gerente de productos en Google, sugerirían que la estrategia de ciencia de datos incluye “Cómo obtener los datos y la infraestructura en un estado lo suficientemente bueno como para realizar análisis o aprendizaje automático. Yo diría que se trata de cómo permitir que el equipo realice todo el trabajo”. Excluiremos deliberadamente estos elementos de una estrategia de datos más amplia. (Lo siento, Carol). Sin embargo, discutiremos cómo navegar las limitaciones de datos e infraestructura, y cómo desarrollar su estrategia de ciencia de datos puede guiar positivamente su estrategia de datos en general.

Ahora tenemos límites: estamos construyendo un conjunto de hipótesis estratégicas centrales sobre cómo el aprendizaje automático y/o la inteligencia artificial pueden agregar el máximo valor a una organización, con su propia estrategia u objetivos definidos, y un conjunto de patrones a los que un equipo se comprometerá en busca de ese valor. ¿Por dónde empezamos?

Construyendo nuestra hipótesis estratégica central: Comencemos con una mentalidad ganadora de IA

Los experimentados gerentes de productos de aprendizaje automático, ingenieros y científicos de datos a menudo mencionan que los productos de aprendizaje automático son diferentes del software tradicional. Una organización debe tener en cuenta el riesgo de errores en el modelo, la deriva de los datos, el monitoreo y la reajustación del modelo; de ahí la aparición de MLOps modernos. Y es fácil cometer pecados de ingeniería que sumerjan las aplicaciones de aprendizaje automático en pantanos de deuda técnica. (Véase “Machine Learning: The High Interest Credit Card of Technical Debt” para obtener una excelente lectura sobre este tema). Entonces, con todos estos costos, ¿por qué lo hacemos?

En última instancia, consideramos soluciones de IA porque los modelos sofisticados tienen un historial demostrado de ser capaces de detectar patrones valiosos. Estos pueden ser desde grupos de preferencias de clientes que implican segmentaciones novedosas, hasta las representaciones latentes que una red neuronal encuentra para optimizar las predicciones. Cada construcción de aprendizaje automático se basa en la premisa, o expectativa, de que un modelo puede detectar patrones que pueden mejorar un proceso, descubrir hallazgos accionables o mejorar predicciones valiosas.

Al definir la hipótesis estratégica central para un equipo de ciencia de datos de cualquier tamaño, podemos comenzar con esta descripción de ejemplo de McKinsey sobre cómo las empresas habilitadas por IA piensan de manera diferente. Según “Ganar con IA es una mentalidad”:

Si elegimos los casos de uso correctos y los hacemos de la manera correcta, aprenderemos cada vez más sobre nuestros clientes y sus necesidades, y mejoraremos continuamente la forma en que los servimos.

Este es un lente enormemente útil en el esfuerzo por construir una estrategia de ciencia de datos: nos enfoca en el aprendizaje máximo, y todo lo que tenemos que hacer es llegar a la definición “correcta” de nuestra organización. Pero ¿cuáles son los casos de uso “correctos” para nosotros?

Aquí Pisano es útil nuevamente, definiendo cuatro elementos de una estrategia de I+D que se aplican muy bien a la ciencia de datos:

• Arquitectura: La estructura organizativa (centralizada, distribuida) y geográfica de nuestra función de ciencia de datos.
• Procesos: Las formalidades e informalidades de gestionar nuestro trabajo.
• Personas: Todo, desde qué combinación de habilidades buscamos atraer y nuestra propuesta de valor para nuestro talento.
• Portafolio: Cómo asignamos recursos a través de tipos de proyectos y “los criterios utilizados para ordenar, priorizar y seleccionar proyectos”.

Comenzaremos con el último concepto y centraremos nuestra atención en definir el portafolio ideal de proyectos para nuestra organización, la combinación que podemos convencernos de que generará el mayor valor. Dada la gran variación entre las organizaciones, comenzaremos con un desafío que todas las organizaciones enfrentan: el riesgo.

Defina su portafolio objetivo: determine los niveles de riesgo y la gestión de acuerdo con su estrategia

El trabajo de modelado tiene resultados inciertos. “La IA puede hacerlo mejor” es un argumento que a menudo hacemos basándonos en la historia y la intuición, y a menudo resulta ser cierto. Pero nunca sabemos qué tan bien funcionará al principio, hasta que demostremos a través de la construcción cuán bien puede resolver un problema la IA. Aprender la respuesta a esta pregunta para cualquier caso de uso dado puede requerir diferentes niveles de esfuerzo y, por lo tanto, diferentes niveles de costo. La incertidumbre en cuanto a esta respuesta también puede variar, según cuán ampliamente se hayan aplicado nuestros modelos y cuánto entendamos nuestros datos.

Un amigo y líder de producto de análisis de salud, John Menard, definió el riesgo como parte explícita de la estrategia de ciencia de datos: “¿Cómo mantiene una tubería de apuestas pequeñas y grandes, al tiempo que mantiene expectativas saludables de que eso es todo lo que son? ¿Cuál es su estrategia para abandonar un proyecto cuando los datos no funcionan, o cambiar el resultado si no cumple con los requisitos?”

Es sabio que las organizaciones sean principiadas y específicas sobre el nivel de recursos que pueden permitirse y durante cuánto tiempo. Aquí hay algunas preguntas útiles que debemos hacer acerca de cualquier esfuerzo de modelado individual:

• Probabilidad estimada de éxito: ¿Cuáles son las posibilidades de que este caso de uso de modelo sea exitoso?
• Rango esperado de rendimientos: Si tiene éxito, ¿este proyecto proporcionará una pequeña mejora en un proceso que puede generar grandes rendimientos a gran escala? ¿Una innovación diferenciará a su empresa de los competidores?
• Tiempo esperado para descubrir un fallo: ¿Cuánto tiempo tomará aprender si la propuesta de valor hipotetizada del proyecto se materializará? ¿Cuál es la cantidad mínima de recursos que puede gastar antes de descubrir que este proyecto no funcionará?

Con suerte, estos principios son sencillos y todos son cosas buenas consensuadas. El proyecto ideal es probable que funcione, con grandes rendimientos de inversión, y si falla, falla temprano. Esta tríada celestial nunca se materializa. El arte está en hacer compensaciones que se ajusten a su organización.

Una startup en etapa inicial enfocada en interrumpir un dominio en particular con IA podría tener inversores, liderazgo y personal que acepten a la empresa como una única gran apuesta en un enfoque particular. O bien, podría preferir proyectos pequeños que lleguen rápidamente a la producción y permitan giros rápidos. Por otro lado, si estamos en una empresa grande y establecida en una industria bien regulada con interesados escépticos de la IA, podríamos elegir sesgar nuestro portafolio hacia proyectos de bajo esfuerzo que brinden un valor incremental y fracasen rápidamente. Esto puede ayudar a construir confianza inicial, ajustar a los interesados a la incertidumbre inherente en los proyectos de ciencia de datos y alinear a los equipos en torno a proyectos más ambiciosos. Los proyectos pequeños exitosos al comienzo también pueden respaldar el caso para proyectos más grandes en el mismo espacio problemático.

Aquí hay algunos ejemplos de cómo definir su portafolio objetivo en términos de alcance del proyecto, duración y rendimientos esperados:

• “Al estar en una etapa temprana de nuestro viaje colectivo de ciencia de datos, nos enfocamos en casos de uso pequeños, de bajo esfuerzo y con un rápido fracaso que descubrirán oportunidades sin arriesgar grandes cantidades de tiempo del personal”.
• “Hemos identificado un portafolio de tres grandes apuestas de aprendizaje automático, cada una de las cuales podría desbloquear un tremendo valor”.
• “Apuntamos a un equilibrio de proyectos pequeños, VoAGI (Inteligencia General Artificial Variable) y de alto esfuerzo, con niveles correspondientes de rendimiento. Esto nos permite obtener victorias frecuentes mientras perseguimos una posible disrupción con potencial de cambio de juego”.

Como principio final para aplicar en nuestro portafolio completo, apuntemos a una colección de proyectos con éxitos no correlacionados. Es decir, queremos ver nuestro portafolio y percibir que los proyectos tendrán éxito o fracasarán de forma independiente. Si varios proyectos se basan en una suposición común, si percibimos que están tan relacionados que tendrán éxito o fracasarán juntos, entonces debemos revisar la selección.

Terminamos esta etapa cuando tenemos:

• Evaluado nuestras oportunidades de ciencia de datos y aprendizaje automático
• Representado gráficamente estas oportunidades por inversión, retorno y probabilidad de éxito
• Seleccionado una lista de prioridades preliminar que sea coherente con nuestros objetivos y tolerancia al riesgo

Ahora que hemos definido nuestra cartera objetivo, nos centraremos en asegurar que nuestros procesos nos permitan identificar, delimitar y entregar proyectos de valor de manera rápida.

Enfoca tu cartera en lo que tu equipo está especialmente capacitado para resolver

La pregunta sobre si construir o comprar es recurrente y a menudo se adentra en dinámicas organizativas complicadas. No faltan proveedores y startups que ofrecen soluciones de inteligencia artificial. Muchos son productos engañosos, pero también hay muchos que funcionan. Muchos equipos internos de tecnología y ciencia de datos ven a los primeros como una broma, a los segundos como competidores, y consideran que el tiempo invertido en distinguir entre ambos es una gran pérdida de tiempo. Esto tiene mérito, ya que el tiempo dedicado a evaluar a un proveedor no mejora las habilidades de un modelador, y si una organización no recompensa ese esfuerzo, es un costo que el científico de datos paga sin recibir beneficios en su carrera. Y esta complicación interpersonal se suma a un caso empresarial ya complicado: Ninguna de las preocupaciones típicas de una solución de software desaparece. Todavía tienes que preocuparte por cosas como la dependencia de un proveedor y la integración en la nube. Sin embargo, todos deberíamos estar dispuestos a comprar productos de proveedores que ofrezcan un mayor retorno de la inversión, y puedes eliminar las distracciones si consideras las ventajas únicas de tu equipo interno en comparación con las soluciones predefinidas.

En particular, tu equipo interno puede tener acceso supervisado a gran parte (o incluso a la totalidad) de los datos propietarios de tu organización. Esto significa que es probable que un equipo interno pueda comprenderlo en mayor profundidad y enriquecerlo con otras fuentes de manera más fácil que una solución de un proveedor especializado. Si se le brinda suficiente tiempo y recursos informáticos, es probable que un equipo interno capaz pueda superar a una solución de un proveedor especializado. (Hay algún chiste sobre la teoría del PAC en esto en algún lugar). Pero, ¿vale la pena?

Aquí es clave realizar un análisis estándar del retorno de la inversión y las alternativas, centrándote en el tiempo que lleva llegar al mercado interno. Digamos que estamos optimizando la ubicación de anuncios en un sitio de comercio electrónico. Hemos reducido una lista de proveedores a uno que utiliza un algoritmo de elección multinomial, un método común entre los principales proveedores de optimización de marketing al momento de escribir esto. Estimamos que llevará un mes integrar el proveedor. O podríamos construir nuestro propio algoritmo, y estimamos que llevará seis meses. ¿Esperaríamos que un algoritmo que construyamos supere al que ofrece el proveedor, y lo suficientemente como para justificar el retraso?

Depende. El uso del muestreo de Thompson para un algoritmo de elección multinomial te brinda límites logarítmicos en el arrepentimiento esperado, una jerga que significa que explora opciones sin dejar mucho valor en la mesa. Esa afirmación sigue siendo probadamente cierta, ya sea que se implemente por tu equipo interno o por un proveedor. Por otro lado, tu equipo interno está más cerca de tus datos, y llevar un caso de uso como este al equipo interno implica apostar a que encontrarás señales lo suficientemente valiosas en esos datos como para superar un producto de un proveedor. Y tal vez que tu equipo pueda aportar conocimientos del dominio que una solución predefinida no tiene, lo que proporciona una ventaja valiosa. Por último, considera el costo de oportunidad de tu equipo interno: ¿Hay otro elemento de alto valor en el que podrían trabajar? Si es así, una opción es probar al proveedor, trabajar en el otro elemento y reevaluar después de obtener resultados medibles del proveedor.

Terminamos esta etapa cuando tenemos:

• Revisado nuestras oportunidades de la etapa anterior y respondido para cada una de ellas: “¿Podríamos comprar esto?”
• Para cada solución que se pueda comprar, respondido si tenemos una ventaja única conocida o hipotética internamente
• Para cada área con verdaderos compromisos a tener en cuenta, realizado un análisis de compensación

Una vez definidas las ventajas competitivas estratégicas de nuestro equipo interno, ahora tendremos en cuenta nuestros procesos internos, herramientas y capacidades de datos.

Construye procesos alrededor de tu fábrica de conocimiento, herramientas y cadena de suministro de datos

He discutido el tema del tiempo dedicado a las tareas con muchos científicos de datos experimentados, y todos citan el descubrimiento, procesamiento, limpieza y movimiento (a un entorno de cómputo adecuado) de los datos como la mayor parte de su tiempo dedicado al trabajo. Como escriben otros autores de McKinsey sobre AutoML y estrategia de talento en IA, “Muchas organizaciones han descubierto que el 60 al 80 por ciento del tiempo de un científico de datos se dedica a preparar los datos para el modelado. Una vez que se construye el modelo inicial, solo una fracción de su tiempo, según algunos análisis, se dedica a probar y ajustar el código”. Esto no es lo que nos atrae a la profesión. En la mayoría de los casos, es el costo que pagamos por la satisfacción de construir modelos con impacto. Por esta razón, a menudo hablamos de las “bases” que los científicos de datos necesitan para tener éxito. En mi experiencia, esta forma de pensar puede obstaculizarnos rápidamente, y voy a desafiarnos a pensar en nosotros mismos como una fábrica de modelos, sujeta a las limitaciones de las herramientas y una cadena de suministro de datos compleja y a menudo problemática.

Confesión: Nunca he creído en estos puntos de discusión sobre “fundamentos” cuando se habla de plataformas.

“Las plataformas de datos y ML son los cimientos sobre los cuales se basa el éxito del aprendizaje automático”, dice una declaración en negrita en innumerables presentaciones y documentos técnicos. “Y sin una base sólida”, concluye algún consultor de manera paternalista, “todo se desmorona”.

Aquí está el problema, sin embargo: muy pocas cosas “se desmoronan” sin el aprendizaje automático. Si construyes tu casa sobre una base defectuosa, tu garaje podría colapsar sobre sí mismo y sobre ti. Si inicias un proyecto de aprendizaje automático sin el beneficio de plataformas desarrolladas de datos y ML, la construcción de tu modelo… llevará más tiempo. Y sin ese nuevo y elegante modelo de aprendizaje automático, es probable que tu negocio continúe de la misma manera en la que ha estado, aunque sin alguna ventaja competitiva que el ML pretendía proporcionar. Pero persistir en la mediocridad no es el fin del mundo.

Es ahí donde este cliché me pierde. Busca asustar a los ejecutivos para financiar los esfuerzos en plataformas, que son valiosos, vale la pena enfatizarlo, como si el mundo se acabara sin ellas, y no es así. Gritamos que el cielo se está cayendo, y luego, cuando los interesados se encuentran con la misma vieja lluvia a la que están acostumbrados, perdemos credibilidad.

Sin embargo, apuesto a que las empresas con sólidas capacidades de ML superarán a los competidores que no las tienen, no se me escapa que mi carrera como líder de modelado es exactamente esa apuesta, y las capacidades modernas de datos y MLOps pueden reducir en gran medida el tiempo de comercialización de las capacidades de IA. Considera este extracto del documento de McKinsey “Scaling AI like a tech native: The CEO’s role”, énfasis mío:

Frecuentemente escuchamos de los ejecutivos que mover soluciones de IA desde la idea hasta la implementación lleva de nueve meses a más de un año, lo que dificulta mantenerse al día con las dinámicas cambiantes del mercado. Incluso después de años de inversión, los líderes a menudo nos dicen que sus organizaciones no se están moviendo más rápido. En contraste, las empresas que aplican MLOps pueden pasar de la idea a una solución en vivo en solo dos a 12 semanas sin aumentar la cantidad de personal o la deuda técnica, lo que reduce el tiempo para obtener valor y permite a los equipos escalar la IA más rápido.

Tu estrategia de ciencia de datos debe tener en cuenta las limitaciones organizativas y de herramientas, y adoptar patrones que produzcan modelos o unidades de conocimiento que sean accionables dentro de esas limitaciones. Es decir, los proyectos de modelado siempre deben tener:

1. Una vista clara de los datos mínimos viables para el modelado. Tu equipo de ciencia de datos debe saber dónde están los datos fuente y tener un bosquejo aproximado de cómo se deberán transformar.
2. Un camino directo y realista hacia el valor realizado. ¿Cómo obtendrás un modelo suficientemente eficiente en funcionamiento o cómo aplicarás los resultados del modelo?

Las empresas en etapa inicial o los equipos con completa libertad para la arquitectura y las herramientas están en una buena posición para adoptar una práctica moderna de MLOps, lo que facilitará prototipar, implementar y monitorear modelos para evaluar su impacto en el mundo real. Los equipos que trabajan junto a tecnología heredada de larga data podrían descubrir que no se creó teniendo en cuenta la integración de ML y que la implementación es un ejercicio pesado y complejo. Es probable que las empresas en industrias fuertemente reguladas descubran que muchas aplicaciones requieren altos niveles de explicabilidad y control de riesgos.

Ninguno de estos desafíos es insuperable. Solo tenemos que ser prudentes y astutos acerca de las implicaciones de los plazos y tener esto en cuenta al tomar decisiones.

Terminamos esta etapa cuando tenemos:

• Examinado nuestros casos de uso planificados para determinar el camino hacia los datos necesarios para comenzar
• Determinado el camino de cada caso de uso hacia el valor realizado en caso de éxito
• Tenemos esto en cuenta al calcular nuestra inversión esperada y ajustarla desde el primer paso
• Refinado nuestra priorización a la luz de cualquier cambio que hayamos descubierto

Habiendo refinado nuestras ideas sobre dónde implementar la ciencia de datos, consideraremos trabajar en modelos de trabajo para asegurar la alineación.

Arquitectura y organización: Estructura tu organización para el éxito sostenible

Pisano define la arquitectura como “el conjunto de decisiones sobre cómo se estructura la I+D tanto organizativamente como geográficamente”. Diseñar esto incluye decisiones conscientes sobre cómo integrar a nuestros científicos de datos con una unidad de negocio. ¿Están completamente centralizados con un proceso formal de incorporación? ¿Reportando a diferentes unidades de negocio? ¿Centralizados e integrados? Las estructuras de informe y las autoridades de toma de decisiones pueden no estar bajo tu control, especialmente si te han asignado la tarea de construir una estrategia para una unidad con líneas de reporte definidas. Pero si estos puntos se están discutiendo, aquí tienes algunas cosas que considerar para maximizar el valor de los resultados de DS.

¿Tus científicos de datos recibirán el apoyo adecuado y serán medidos de manera apropiada? Considera el flujo de talento junior en ciencia de datos. Los científicos de datos ingresan al campo desde una variedad de antecedentes cuantitativos, generalmente con una combinación de habilidades teóricas y prácticas. Un egresado típico de maestría pasa estos años formativos desarrollando habilidades y comprensión, y demostrando esa comprensión a expertos en su campo. Esto generalmente no incluye una abundancia de capacitación en comunicar hallazgos técnicos a no expertos.

Contrasta esto con la experiencia que tendrán en un entorno empresarial, donde probablemente tendrán menos conocimiento del dominio y serán unos de los pocos con conocimiento de métodos. Se les pedirá que apliquen técnicas que pocos fuera de su función comprenden. Sus proyectos necesariamente incluirán más incertidumbre que las compilaciones de software estándar. Su éxito dependerá de muchos más factores, muchos fuera del control del científico de datos, y tendrán muy poca experiencia en articular los requisitos para maximizar las posibilidades de éxito. Si juntamos todo esto, empezamos a ver una situación de lanzamiento al agua profunda.

Esto puede generar desafíos para otros líderes funcionales durante su primera experiencia liderando equipos de ciencia de datos. Esta lección de la estrategia de I+D de McKinsey “Building an R&D strategy for modern times” también se aplica a nuestro campo:

Las organizaciones tienden a favorecer proyectos “seguros” con rendimientos a corto plazo, como aquellos que surgen de las solicitudes de los clientes, que en muchos casos no hacen mucho más que mantener la cuota de mercado existente. Una empresa de bienes de consumo, por ejemplo, dividió el presupuesto de I+D entre sus unidades de negocio, cuyos líderes luego utilizaron el dinero para alcanzar sus objetivos a corto plazo en lugar de los objetivos de diferenciación y crecimiento a largo plazo de la empresa.

En nuestro campo, esto tiende a manifestarse con científicos de datos junior a quienes sus supervisores no técnicos les piden que escriban cualquier consulta SQL que responda a las preguntas del día. Esto suele ser útil, pero generalmente no es el tipo de valor que una empresa busca al reclutar modeladores expertos.

Este problema se resuelve mucho más fácilmente cuando tienes líderes que han gestionado proyectos de ciencia de datos o aprendizaje automático antes. Independientemente de la función, el éxito depende de contar con personas que puedan escuchar un problema y definir enfoques analíticos y de modelado para resolverlo, y gestionar los riesgos y la ambigüedad. Muchos científicos de datos al comienzo de su carrera prosperan en estas situaciones. En mi experiencia, son casos atípicos con habilidades tanto en comunicación como en el manejo de la ambigüedad. He tenido la suerte de contratar a algunos por accidente, ¡hola Zhiyu! Apuesta por tu capacidad para evaluar y competir por estos talentos por tu cuenta y riesgo.

Todo esto parecería argumentar a favor de centralizar tu función de ciencia de datos. Esa es una opción, y nos lleva a nuestra siguiente pregunta importante.

¿Estarán tus científicos de datos lo suficientemente cerca del negocio como para centrarse en los problemas correctos? Un grupo funcional centralizado de ciencia de datos probablemente tendrá menos exposición a los problemas empresariales que te gustaría resolver, en comparación con equipos hiperlocales que informan directamente a un equipo de negocio. Los equipos grandes, monolíticos y funcionales con procesos formales pueden tener dificultades para obtener la información empresarial que necesitan, en gran parte porque muchas partes interesadas no están seguras de qué pedir. Si has escuchado una o dos historias de horror sobre equipos de ciencia de datos que desarrollan “proyectos científicos que nadie solicitó”, esta es a menudo una de las causas fundamentales. Y nuevamente, resiste la tentación de estereotipar: esto rara vez se debe a que el equipo de ciencia de datos tiene una mentalidad demasiado académica, y con mucha más frecuencia se debe a que dos funciones diferentes no saben cómo conversar en un lenguaje común.

¿Qué opciones nos quedan? Esta es una de las razones por las que los modelos integrados han funcionado en mi experiencia. En este modelo, tu equipo de ciencia de datos tiene acceso a todos los foros en los que rutinariamente se discuten los problemas empresariales. Son responsables de aprovechar esta oportunidad para comprender los problemas que un equipo de negocio quiere resolver y proponer enfoques que puedan agregar valor. Informan a líderes de ciencia de datos, quienes se aseguran de que estén realizando un trabajo metodológicamente sólido, los apoyan para obtener lo que necesitan para el éxito de sus proyectos y los orientan y entrenan en su crecimiento.

A veces, los proyectos de ciencia de datos fallan debido a una metodología deficiente; a menudo fallan porque las características predictivas no son adecuadamente útiles. Distinguir la diferencia puede ser muy difícil para alguien fuera de una función cuantitativa.

Hemos terminado esta etapa cuando hemos:

• Definido formas claras de comunicar el alcance de los científicos de datos o equipos
• Definido patrones de participación

Como en todas las decisiones prácticas, hay compensaciones en todas partes y no hay soluciones milagrosas. Los equipos locales completamente autónomos maximizarán el enfoque en resultados diferentes y locales. Una función centralizada minimizará la duplicación con un mayor riesgo de desviarse de resultados prácticos e impactantes.

Dar un paso atrás, comunicar e iterar de manera holística

Repasemos lo que hemos logrado hasta ahora:

1. Hemos definido una hipótesis estratégica, la gran apuesta sobre cómo agregaremos valor con la ciencia de datos y el aprendizaje automático.
2. Hemos definido una cartera objetivo que se alinea con el apetito de riesgo de nuestra organización, tiene en cuenta tus restricciones de procesos y tecnología, y enfoca nuestro equipo en los problemas que no se pueden resolver simplemente comprando la solución.
3. Hemos filtrado nuestros casos de uso en función del acceso a los datos y de cómo generarán valor.
4. Posiblemente, hemos desarrollado estructuras de informes y métodos de búsqueda de proyectos que apoyan a tus científicos de datos y enfocan sus talentos en sus ventajas únicas.

Más claramente, hemos establecido los criterios para encontrar nuestros casos de uso adecuados y filtrado nuestras oportunidades de casos de uso para encontrar el primer conjunto adecuado.

Los siguientes pasos a seguir son:

1. Retroceder y mirarlo todo en conjunto. ¿Visto como un todo holístico, tiene sentido?
2. Comunicar esta estrategia y el plan inicial que surgió de ella.
3. Comunicar cómo los interesados potenciales pueden interactuar con su equipo funcional.
4. Iterar: Revisar su estrategia siempre que cambien las suposiciones o circunstancias que la motivaron y comprometerse a una frecuencia para revisar cómo han cambiado las circunstancias.

En conclusión, este proceso requiere una cantidad considerable de esfuerzo. Sin embargo, conlleva una gran recompensa. Esta estrategia ofrecerá una clara articulación de los riesgos que desea asumir, cómo los gestionará y cómo respaldarán sus resultados objetivo si tienen éxito. Una alineación clara de propósito, y la facilidad de mantener las actividades consistentes con ese propósito, es algo increíblemente empoderador para un equipo funcional. Proporcione eso y los resultados llegarán.

Referencias

• Brenna et al, “Construyendo una estrategia de I+D para los tiempos modernos”
• Corbo et al, “Escalando la IA como un nativo tecnológico: El rol del CEO”
• Kiechel, Walter. The Lords of Strategy: The Secret Intellectual History of the New Corporate World (Enlace de afiliado)
• Meakin, et al, “Ganar con la IA es un estado mental”
• Pisano, Gary P. “Creando una estrategia de I+D”
• Rasiel, Ethan. The McKinsey Way (Enlace de afiliado)
• Scully et al, “Machine Learning: La tarjeta de crédito de alto interés de la deuda técnica”

We will continue to update Zepes; if you have any questions or suggestions, please contact us!