Uno de los trabajos de Ciencia de Datos (o Data Science) que más satisfacción me ha dado en este año 2018 que nos acaba de dejar, ha sido la creación de un modelo del comportamiento de clientes para una empresa distribuidora de material deportivo. No sólo por el hecho de crear el modelo, sino por haberme permitido presentarlo en el WGML 2018. No voy a repetir cómo fue mi experiencia en el Congreso Gallego de Machine Learning, porque ya hablé sobre ella en otra entrada, sino que mi intención es desgranar el trabajo con la idea de demostrar que para beneficiarse de las técnicas de la ciencia de datos y el aprendizaje automático, no se necesita disponer de un enorme conjunto de datos.
Es curioso, pero aunque no hay ninguna razón objetiva para ello, muchos directivos de empresas, sobre todo de PYMEs, entienden que los modelos predictivos creados con técnicas de aprendizaje automático, sólo son posibles cuando se cuenta con un volumen de datos enorme. Lamentablemente, les ha llegado la “cantinela” del big data y sólo se han quedado con lo de “big”. Y lo más triste de todo esto es que nuestras propias instituciones públicas son unas de las encargadas de difundir el bulo, en publicaciones como esta de la ONTSI, el Observatorio Nacional de las Telecomunicaciones y de la SI, en donde se habla de big data cuando se quiere hacer referencia al análisis de datos y no a la complejidad técnica de su almacenamiento y tratamiento debido a su volumen.
Bueno, pues con estos mimbres y partiendo del hecho de que el trabajo se realizó en una PYME con un volumen de facturación de unos pocos millones de euros y un volumen de datos que cabe en un lápiz USB, veremos que no siempre es necesario disponer de esos “datos enormes” para conseguir resultados interesantes.
Muy bien, comencemos, pero aviso que el desarrollo no será corto, por lo que esta será la primera entrega de una “serie en fascículos”.
Motivación
Como en muchos otros casos, todo esto surgió de casualidad y a raíz de una conversación con los responsables de la empresa en donde se formuló una pregunta aparentemente sencilla e inocua:
“¿Qué clientes están dejando de comprar alguno de nuestros productos?”.
En realidad, esta pregunta planteaba unos cuantos desafíos:
- En primer lugar, aclaro que los datos analizados fueron los comprendidos entre el año 2011 y el 2017. Durante este período, la empresa contaba con 4.062 clientes y 24.565 productos en catálogo, lo cual implica la existencia de unas 100 millones de combinaciones cliente / producto distintas. Así que, por si alguien se lo preguntaba, la posibilidad de que una persona analice manualmente los datos quedaba completamente descartada.
- Para determinar si un cliente deja de comprar algún producto, primero tenemos que entender a qué nos estamos refiriendo: ¿queremos decir si está dejando de comprar algunas referencias o, en realidad, lo que queremos es saber si han cambiado sus hábitos de compra de alguna tipología de producto? En este caso, lo que pretendemos es saber si el cliente compra más o menos productos de algún tipo (por ejemplo “camisetas”) pues, como veremos, hacerlo por producto individual no sería muy útil, teniendo en cuenta que entre las referencias muchos productos pueden ser sustitutivos unos de otros o ser muy similares (por ejemplo, un balón de fútbol de una marca o de otra).
- Adicionalmente a lo comentado en el punto anterior, buena parte de las referencias de la empresa tienen una duración temporal limitada. Por ejemplo, las zapatillas deportivas, las camisetas o las sudaderas (entre otros) suelen ser productos de temporada que se dan de alta en un año concreto para liquidarse unos meses después. Así, no queda más remedio que agrupar productos en base a su tipo.
- Otro problema adicional y específico de este caso, fue que buena parte de los productos incluyen combinaciones de los mismos; esto es, que una misma referencia puede dividirse en diferentes combinaciones de dos atributos: talla y color. Sin embargo, inicialmente el ERP no soportaba la gestión de combinaciones de productos, por lo que muchos de ellos fueron dados de alta sin agruparlos bajo un modelo. Por ejemplo, unas aletas de buceo que pueden venderse en varias tallas (S, M o L), lo cual daría lugar a tres códigos de productos distintos.
- Por último, pero no menos importante, no existía una clasificación de productos que los hiciese comparables. En concreto, la empresa contaba con una clasificación en dos niveles (algo así como una categoría y una subcategoría), pero este método no permitía distinguir, por ejemplo, una “camiseta” de una “zapatilla”, pues ambas podrían asignarse a la misma categoría y subcategoría si su marca fuese la misma.
Extracción y Transformación de Datos
Los datos se extrajeron desde el ERP de la empresa que, en este caso, era SAP Business One. Para ello, al tratarse de una aplicación con la habitual arquitectura clientes servidor en dos capas, necesité acceder a la base de datos del servidor. Como tal, SAP usa MS SQL Server aunque en sus últimas versiones ya utiliza SAP Hana, aunque no en esta instalación. De todos modos, la extracción consistió en la preparación de una consulta SQL que usando las tablas de pedidos, nos devuelva las columnas relevantes.
Como vemos en la imagen, utilizaremos las tablas siguientes:
- ORDR: Cabecera de pedidos de venta. Nos proporciona información que nos permite descartar aquellos pedidos cancelados, así como el cliente y el importe total de los mismos.
- RDR1: Línea de pedidos de venta; tabla que nos informa sobre el producto, el número de unidades pedidas, así como su precio.
- OITM: Maestro de artículos. Contiene la información básica de los productos y de ella extraemos su nombre y marca.
- OMRD: Maestro de marcas. Nos informa sobre el nombre de la marca del producto.
Hasta aquí todo ha sido fácil pues, como resultado de la consulta, obtengo un CSV con toda la información relevante en formato tabular. Es el turno de realizar la carga de datos en R, algo muy sencillo pues se trata sólo de leer correctamente el CSV.
Puesto que no tenemos categorías que sirvan para clasificar los productos, decidí usar la descripción como base para clasificar. Claro que esto implica el uso de técnicas de NLP (o procesado de lenguaje natural), por lo que los errores o problemas en las descripciones afectarán a la calidad del resultado. Así, es en el momento de examinar los datos cuando comienza la parte “interesante” pues aparecen cosas como:
- Hay productos que, como ya indiqué antes, deberían ser uno solo y, sin embargo, nos aparece cada combinación como un producto individual. Tocará agruparlos.
- Otros incluyen colores o unidades de medida en su descripción que son irrelevantes para su agrupación en una categoría común. Lo mismo ocurre con la marca que, a pesar de disponer de un campo específico para ello, en ocasiones se repite en la descripción.
- TODO ESTÁ EN MAYÚSCULAS. Sí, igual que si estuvieran gritando…
- Y luego están las faltas de ortografía: que si fútbol a veces es “FÚTBOL” y otras veces es “FUTBOL”, que si las bes y las uves se confunden de cuando en vez…
La solución que se me ocurrió fue escribir una función que realizara una corrección ortográfica, al menos para aquellas palabras más comunes, por lo que, después de investigar un poco, descubrí que la Real Academia Española dispone de un Corpus de Referencia del Español Actual (CREA) que, visto así, parece que debería ser una buena herramienta en la búsqueda de similitudes entre palabras para la detección de faltas o errores. CREA dispone de un apartado con las frecuencias de las palabras, pudiendo descargar un fichero de texto con 1.000, 5.000, 10.000 o el total de palabras y su frecuencia. Al grano, el problema es que nadie se ha molestado en limpiar las fuentes de este supuesto “corpus”, por lo que nos encontramos de nuevo con que “fútbol” y “futbol” son dos palabras casi igual de frecuentes por lo que ambas aparecen en el fichero (y ya no digo nada de otras faltas de ortografía más horrendas, pues también aparecen). Así que este fue un camino a ninguna parte. ¡Gracias RAE!
Al final, terminé escribiendo una función ad hoc que elimina las tallas, las marcas, las unidades de medida, los colores y alguna cosa más. Ahora, por fin, ya era posible pasar a la fase siguiente: la lematización.
¿Qué es la lematización? Pues es un proceso que consiste en extraer el lema o raíz de las palabras, así como conocer su género, número y su función. ¿Que para qué lo necesitaba? Pues para que “balón” y “balones” fueran, en realidad, el mismo término y no dos diferentes. Además, al conocer el rol de cada palabra, puedo quedarme con aquellas que me interesen más para agrupar los productos. Por ejemplo, si un producto fuese “balón de fútbol grande” (por ejemplo), me interesa quedarme con las palabras que sean nombres comunes y descartar el resto. En este caso, “balón” y “fútbol” esclusivamente. En cuanto a la herramienta escogida, hay que tener en cuenta que debe trabajar con el idioma español, lo cual limita el conjunto de posibilidades. Finalmente, me decanté por el uso de LinguaKit, una herramienta desarrollada por el grupo ProLNat@GE del CiTIUS de la Universidad de Santiago de Compostela (USC) y que puede consultarse on-line o descargarse para utilizarla en local. Su funcionamiento es el siguiente: cuando le pasamos una descripción como “SET 4 PELOTAS PARA PALA MADERA COMPETICIÓN”, nos devuelve:
set set NCMS000
4 4 Z
pelotas pelota NCFP000
para para SPS00 parar VMIP3S0 parar VMM02S0 parir VMM03S0 parir VMSP1S0 parir VMSP3S0
pala pala NCFS000
madera madera NCFS000 maderar VMIP3S0 maderar VMM02S0
competición competición NCFS000Como veis, la primera columna se corresponde con la palabra que está analizando, la segunda indica la palabra sin flexionar (si es un nombre, pues sin plural y si es un verbo, pues en infinitivo), aunque esto puede repetirse varias veces si el mismo lema puede tener distintas posibilidades (como en el caso de “para”). Después, nos indica si se trata de un nombre común (NC) y si es masculino (M), femenino (F), singular (S) o plural (P). Nosotros nos quedamos sólo con aquellas que sean NC, por lo que tendríamos la siguiente lista de palabras: set, pelota, pala, madera, competición.
Ahora ya podemos cargar estas descripciones y formar con ellas un modelo de espacio vectorial (MEV), pero esto, amiguitos, quedará para el próximo capítulo.