Gestión de datos y Quentin Tarantino Vol. I

De la misma manera que los hermanos Weinstein consideraron que cuatro horas de sangre y venganza eran demasiado duras para concentrarlo en una sola película y obligaron a Tarantino a dividir Kill Bill en dos volúmenes yo voy a dividir mis posts sobre la gestión de los datos en varios volúmenes (aunque en este caso no haré flashbacks ni jugaré con la línea temporal narrativa como Quentin)

Cada vez concedemos más importancia al manejo de los datos dentro de nuestras compañías para obtener ventajas competitivas. La ley de Moore y los avances en paralelización y escalado horizontal hacen que la tecnología sea cada vez más accesible para todos, los algoritmos evolucionan a velocidad de vértigo y lo que hoy es nuestro preciado secreto mañana es un API de Google (TensoFlow anyone?)… Pero nuestros datos siempre serán propiedad nuestra, y si realmente son diferenciales, nos proporcionarán una ventaja sostenible y muy difícil de copiar o adquirir sin contar con nuestra aprobación (definición estricta de ventaja competitiva).

Por estas razones en K Fund nos gustan tanto las compañías que cuidan y dan la importancia debida a los datos. Por eso apostamos por compañías que digitalizan partes de nuestra vida (la digitalización nos permite construir un dataset que antes no existía) como Salupro o Hooks, que están revolucionando la cadena logística dental o las conversaciones sobre nuestros intereses.

La digitalización es una de las vías para la obtención de ventajas competitivas basadas en datos, pero tampoco hay que olvidar aquellas compañías que hacen uso de los datos para la optimización de nuestras vidas (y que cada día aprenden y lo hacen mejor reutilizando los datos generados), como Lucera con el consumo eléctrico o aquellas plataformas que permiten la explotación de un canal como es el influencer marketing a escala.

En 2016 yo creo que no existe duda alguna sobre la importancia de los datos en los modelos de negocio basados en la tecnología pero… ¿cómo organizamos nuestra compañía para poder explotarlos eficientemente?

Históricamente, los temas relacionados a la explotación de datos han sido asignados a IT/desarrollo/ingeniería, dado que se asociaba esta materia a un tema eminentemente técnico.

Es cierto que la explotación de datos tiene un componente técnico (hace falta una infraestructura para poder capturarlos, almacenarlos y ponerlos a disposición del usuario en tiempo y forma), pero si la parte técnica es la encargada de su explotación ¿cómo compaginar la agenda del departamento (seguridad, uptime, etc…) con las necesidades respecto al análisis de datos?, ¿quién decide qué investigar? , ¿quién analiza los resultados?

Si cada uno de los experimentos necesita involucración de desarrollo, puede que sea peor el remedio que la necesidad, pues el cuello de botella de desarrollo nos podría llevar a que cada iteración dure varias semanas.

Una alternativa a esta estructura es la asignación de las labores de explotación de los datos a las unidades de negocio (marketing, ventas, desarrollo de negocio), con IT proporcionando la infraestructura para el consumo de datos (Tableau, Chart.io o herramientas similares). Estas herramientas prometen resolver una de las cuestiones que nos impiden dormir, y es que las propias unidades de negocio puedan consumir sus datos directamente, sin tener que cursar peticiones a IT… qué felices seríamos todos si SQL se enseñase en las escuelas, pero desgraciadamente muchas veces se instala la herramienta pero no se le puede extraer la funcionalidad adecuada porque se carece de las habilidades para su explotación por parte de las unidades de negocio.

Hay consultas SQL de algunos usuarios más peligrosas que la katana de Hattori Hanzo

En las startups muchas veces este hecho se produce en la transición entre cuatro amigos que lo hacen todo entre todos y una compañía de 20–30 empleados donde no todos los perfiles son tan polivalentes y necesitan tener la formación adecuada.

Como solución a este problema una alternativa es incorporar un perfil para la explotación de datos dentro de cada departamento para sea esa la persona que se ocupe de los análisis de su departamento. Con esta medida solucionamos el gap de habilidades en cada departamento a medida que escalamos pero nos enfrentamos a otros problemas como son la falta de comunicación entre los analistas de cada departamento y la dificultad para reclutar y dar desarrollo profesional a estos perfiles (siempre serán “el de datos de marketing” y así nos va a costar reclutar talento).

¿Como cuadrar el círculo y conseguir aunar capacidad de análisis con centralización y eficiencia?…Para poder lidiar con estos problemas, últimamente en la mayoría de startups con las que interactúo veo que se ha impuesto una estructura híbrida con un equipo de BI/Data que se encarga del análisis menos estructurado (modelaje predictivo, experimentos, etc…) y de realizar de puente entre la infraestructura y las unidades. La creación de un departamento de data permite que exista alguien dentro de la compañía que se ocupa exclusivamente de cómo extraer el máximo valor de los datos existentes, así como acercar y difundir las bondades del análisis de datos dentro de la compañía.

Esta estructura, por ejemplo en Typeform, cuenta con un equipo dedicado de 12 personas entre data scientists (para experimentos y consultas no recurrentes) y personal de BI (para reporting y peticiones recurrentes). Esta estructura, junto a un sistema propio de BI, permite que las unidades se ocupen directamente de las peticiones más comunes y recurrentes y disponer de recursos para peticiones más especializadas.

A modo de resumen incluyo una tabla con los pros y cons de cada una de las maneras de organizar el análisis de datos:

¿Se os ocurren otras maneras de organizar la extracción de valor mediante datos? ¿Conoces alguna startup que esté digitalizando nuevas áreas? En K siempre estamos ojo al dato!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.