Récemment, dans une salle de discussion confortable, la date des satanistes a soulevé la question de savoir comment "vendre" correctement les projets d'apprentissage automatique internes. Il s'est avéré que beaucoup d'entre nous sont très mal à l'aise quant à la faisabilité économique de nos activités. Pendant ce temps, pour effectuer une évaluation minimale de la rentabilité d'un projet, aucun MBA n'est nécessaire - dans un court article (10 pages de texte, ke-ke-ke) je vais vous dire ce qu'est le ROI, comment l'évaluer pour un projet interne, quel rôle joue-t-il Preuve de concept et pourquoi, dans la vraie vie, tout peut mal tourner. Nous ferons tout cela autour d'un projet fictif pour automatiser la planification d'un centre d'appels. Bienvenue au chat!
Notre projet fictif
Le centre d'appels compte 100 opérateurs. Ils travaillent selon un horaire flottant, en travaillant par équipes de 8 ou 12 heures. Les quarts de travail commencent à des moments différents et sont organisés de manière à assurer la vigilance de nombreuses personnes aux heures de pointe et d'un petit nombre de personnes aux heures froides la nuit et le week-end. L'horaire est planifié par le superviseur de garde du centre d'appels les sombres vendredis soirs, en planifiant la charge pour la semaine prochaine.
Une journée de 8 heures de l'opérateur du centre d'appels coûte à l'entreprise 2 000 roubles. Si nous supposons qu'il y a 250 jours ouvrables dans une année, le centre d'appels coûte à l'entreprise 100 2.000 250 = 50 par an. Si nous automatisons la planification, nous pouvons prédire la charge horaire et organiser des équipes pour faire varier le nombre d'opérateurs de service en fonction de la charge prévue. Si nos prévisions et dispositions de changements sont au moins 10% meilleures que les prévisions et dispositions du superviseur, nous économiserons jusqu'à 5 millions de roubles. par an. Si nous parvenons vraiment à obtenir une amélioration de 10%, le projet sera certainement payant. Ou pas? .. Voyons comment prendre de telles décisions.
Selon ROI
Avant de démarrer un grand projet, il serait bon d'évaluer sa faisabilité économique. Pour ce faire, une méthode classique consiste à calculer le retour sur investissement, le retour sur investissement.
Le ROI (Return on Investment) est un indicateur de rentabilité du projet égal au ratio revenu / investissement dépensé. Un ROI <100% signifie que le projet ne sera pas rentable.
Les premières dépenses du projet surviennent immédiatement, au début - pour l'achat de fer et de licences, le développement du système et sa mise en œuvre. C'est ce qu'on appelle les dépenses en capital. Pendant la durée de vie du projet, il doit également supporter les coûts - pour la location du même matériel et des mêmes licences, pour soutenir l’opérabilité du système et, parfois, le travail des opérateurs. C'est ce qu'on appelle les dépenses d'exploitation.
En règle générale, les projets de BC n'ont pas de «revenus instantanés». Les revenus du projet ne fonctionnent que, c'est-à-dire à temps. Par exemple, dans le cas de notre centre d'appels, les revenus sont constitués comme une économie de coûts pour les opérateurs. Si les coûts d'exploitation du projet dépassent les revenus, le projet ne sera jamais rentable.
En raison des dépenses en immobilisations «instantanées» au début du projet, le retour sur investissement dépendra du moment où nous évaluons la rentabilité. Généralement, l'année, l'horizon de planification ou la durée de vie du système sont utilisés pour calculer le retour sur investissement. Tout est clair avec l'année - c'est un moyen facile de comprendre si le projet sera rentable dans un an ou non. L'horizon de planification est l'intervalle de temps sur lequel la stratégie de l'entreprise est planifiée et les budgets sont établis. Dans les petites entreprises dynamiques, l'horizon dépasse rarement un an, dans les grandes et stables, il peut aller de trois à dix ans.
À l'horizon lointain de la planification, vous pouvez récupérer n'importe quelle ordure, mais la vie commune est gardée par la durée de vie du système. Habituellement, après quelques années, le système cesse de répondre aux exigences de l'entreprise et il est soit remplacé par un nouveau, jeté, soit (le plus souvent) laissé pourrir sur un support éternel. Avec la croissance rapide de l'entreprise, le système ne peut pas toujours vivre pendant six mois, dans un marché stable, le système devient obsolète en 3-5 ans sans modifications, et seule une boîte très conservatrice dans un environnement très conservateur peut survivre plus de 10. Les taux d'actualisation, l'amortissement et toute autre magie comptable seront laissés aux financiers professionnels.
Ainsi, le calcul du ROI se fait selon la formule suivante:
Preuve de concept
Comment pouvons-nous même savoir qu'une nouvelle implémentation augmentera le chiffre de 10%?
Tout d'abord, nous pouvons choisir ce nombre au hasard, le secouer de l'augure le plus proche. Cela fonctionne souvent, mais conduit moins souvent au désastre. Une telle mise en avant n'est pas encouragée publiquement, mais les anciens reconnaissent que de nombreuses décisions réussies ont en fait été prises «à la main».
Deuxièmement, nous pouvons nous appuyer sur l'expérience des implémentations passées. Par exemple, nous introduisons l'automatisation dans le cinquième centre d'appels d'affilée, avant de voir des résultats de 7 à 10%, nous connaissons et pouvons résoudre tous les problèmes courants, et il semble que rien ne devrait nous décevoir. Plus nous avons effectué d'implémentations, plus nos prévisions sont précises et mieux nous comprenons l'effet de divers écarts par rapport à l'idéal sur le résultat.
Même avec l'expérience d'une seule mise en œuvre, une prévision beaucoup plus significative peut être faite qu'avec le Chuyka. Une conséquence audacieuse de cela - il semble que même une seule mise en œuvre inachevée nous donnera une énorme longueur d'avance devant le Chuyka. Nous arrivons donc à l'idée de Proof of Concept, ou PoC.
Le PoC est nécessaire pour confirmer ou infirmer la performance d'une hypothèse, ainsi que pour évaluer son efficacité. PoC n'implique pas une implémentation complète, ce qui signifie qu'elle peut être réalisée rapidement et à moindre coût. Quels sont les moyens d'accélérer dans les projets de Data Science?
- Prendre des données manuellement, sales, directement aux endroits où elles sont les plus faciles à analyser. Même si cette source n'est pas acceptable pour la production, ce n'est pas important.
- Utilisez l'heuristique la plus stupide comme ligne de base. Par exemple, la ligne de base pour prévoir la charge du lendemain est la charge d'aujourd'hui. Encore plus frais - la charge moyenne au cours des 5-7-30 derniers jours. Vous serez surpris, mais une telle heuristique ne peut pas toujours être dépassée.
- Évaluez la qualité à l'aide de tests rétrospectifs - ne réalisez pas de nouvelles expériences de longue durée Toutes les données sont déjà dans l'historique, nous en évaluerons l'effet.
- N'essayez pas de créer du code réutilisable. Tout le code après PoC sera jeté dans le compartiment. Nous répétons cela tous les matins avant de nous asseoir pour coder.
- N'essayez pas de faire un modèle cool. Fixez-vous des délais stricts - un à trois à cinq jours par modèle. Pour de telles périodes, il ne fonctionnera pas de «creuser» dans une implémentation complexe, mais il s'avérera passer par de nombreuses options simples. Pour ces options, une estimation inférieure fiable est obtenue.
- Recherchez agressivement un râteau, marchez sur tous les endroits ridicules, testez des idées dangereuses. Plus nous collectons de râteau au stade du PoC, moins il y aura de risques pendant le développement de la production.
Étapes PoC
La durée du PoC varie généralement d'une semaine à quelques mois. La tâche sera exécutée par une personne menant la date du sataniste. La réalisation d'un PoC nécessite également beaucoup d'attention de la part du client professionnel - parler au début du PoC et comprendre les résultats à la fin. Au total, PoC nous coûtera jusqu'à deux mois de travail des principaux DS et plusieurs jours de travail de clients commerciaux. Voici le premier indicateur - si le client n'a pas trouvé le temps de PoC, alors le résultat d'un grand projet ne sera pas vraiment en demande.
Donc, les étapes.
- Passez de la liste de souhaits et des mots à la mode aux exigences commerciales spécifiques. Il s'agit d'une tâche d'analyse commerciale traditionnelle, mais il est fortement conseillé à DS de le faire lui-même. Il peut ainsi mieux comprendre les besoins du client et terminer la deuxième étape ...
- Formulez une expérience. Une formulation correcte est la clé du succès d'un projet. DS doit déterminer où dans le processus métier une décision automatisée est prise, quelles informations sont disponibles à l'entrée, ce qui est attendu à la sortie, à quel type de tâche d'apprentissage machine il peut être réduit, quelles données seront nécessaires pendant la formation et la production, quelles mesures techniques et commerciales utiliser pour évaluation du succès.
- Traitez les données. DS doit comprendre quelles données sont généralement à notre disposition. Évaluer leur composition attributive, leur exhaustivité, la profondeur de leur histoire, leur cohérence. Assemblez rapidement et manuellement un ensemble de données suffisant pour construire un modèle et tester une hypothèse. Ce serait bien de réaliser immédiatement si les données en production différeront de ce qui est disponible dans le train et de ce que nous avons collecté ici.
- Ingénieur propose et construit un modèle. Les jeunes satanistes des jeunes ongles ne pensent qu'aux modèles (EUROPE), les commentaires sont donc superflus.
- Évaluez la qualité du modèle. Effectuez correctement la validation croisée, calculez les mesures techniques et commerciales, ainsi qu'évaluez les limites auxquelles elles peuvent fluctuer en production. Tout cela devrait aussi faire DS.
- Évaluez le retour sur investissement résultant - c'est tout pour le plaisir. Pour l'évaluation, vous pouvez attirer des représentants du client et quelqu'un qui sait comment se mettre à nageoire. modèles.
Faisons un PoC fictif basé sur notre projet fictif.
Étape 1. Transférer la "liste de souhaits" à la tâche
Voici le libellé de la liste de souhaits:
Il semble que si nous automatisons la planification, nous gagnerons non seulement du temps sur la planification, mais nous apprendrons également à faire varier le nombre de quarts en fonction de la charge.
Qu'est-ce que cela signifie vraiment?
Il est nécessaire de créer un système qui, selon l'historique des quarts et des appels, prédira la charge pour la période suivante, ainsi que des quarts de travail afin que la charge soit utilisée efficacement.
La mesure de prévision de charge est l'erreur dans le nombre de hits par tranche de temps.
Mesure de l'efficacité d'utilisation de la charge - 95e centile du temps d'attente.
Mesure économique - le nombre de quarts pour la période comptable.
La tâche s'est divisée en deux: comment prévoir la charge et comment organiser les quarts de travail.
Premièrement, nous voulons prévoir le nombre d'appels deux semaines à l'avance afin que les prévisions ne tombent pas en dessous des valeurs réelles de plus d'un certain pourcentage.
Deuxièmement, nous voulons minimiser le nombre de quarts par période afin de maintenir le 95e centile du temps d'attente dans des limites acceptables, malgré le fait que la charge sera conforme aux prévisions.
Tâche 1. Prévision de la charge
Vendredi de la semaine 1, nous voulons prédire le nombre d'appels à chaque heure de la semaine 3. Le résultat de la prévision sera de 168 numéros - un numéro pour chaque heure de la semaine suivante.
Un intervalle d'une semaine devra être fait afin que les opérateurs aient le temps de s'adapter à l'horaire.
Nous ferons une prévision vendredi après-midi - d'une part, elle se rapproche le plus possible des dates cibles, d'autre part, il reste encore une demi-journée pour régler le planning manuellement. Nous aurons accès à des données historiques sur les demandes de l'historique complet, ainsi qu'à un calendrier. Nous allons construire de nombreuses fonctionnalités à partir de cela. Ce serait bien de lier la charge à nos versions, mais nous n'aurons pas de telles données au stade PoC.
Nous réduisons le problème à la régression. Pour chaque heure de l'histoire, nous allons créer un vecteur d'entités et prédire la charge à cette heure. Que la mesure de réussite soit MAPE (ou WAPE, nous allons le découvrir en cours de route). La validation croisée "front" sur les données temporaires n'est pas possible - nous nous pencherons sur l'avenir. La sortie habituelle est de diviser l'histoire en plis croisés avec un décalage hebdomadaire (quatre semaines?), Et considérer la dernière semaine comme un contrôle. Le critère de succès est de savoir si notre WAPE (ou qui d'autre?) Peut être maintenu dans des limites raisonnables. Encore une fois, réfléchissez à des limites raisonnables à mesure que l'expérience progresse.
Tâche 2. Disposition des équipes
En fonction de la charge prédite, nous voulons la couvrir de décalages afin que le nombre de décalages soit minimal, et que les indicateurs de qualité restent à un niveau acceptable.
Pour le moment, nous n'organisons pas d'opérateurs sur le calendrier, nous déterminons uniquement le nombre de quarts de travail à mettre et avec quel chevauchement.
Le calcul sera effectué immédiatement après l'achèvement de la prévision de charge. Il s'avère que toutes les mêmes données sont disponibles, plus une prévision de la charge.
Il semble que le problème puisse être réduit au problème inverse d'un sac à dos, le soi-disant Problème d'emballage de bac . C'est un problème NP-complet, mais il existe des algorithmes pour sa solution sous-optimale. La tâche de l'expérience est de confirmer ou de réfuter leur applicabilité. La métrique cible sera le nombre de changements dans la combinaison, les conditions aux limites sont la durée moyenne ou maximale de l'attente (ou une sorte de centile). Nous serons obligés de modéliser la durée de l'attente en fonction du nombre d'appels et du nombre d'opérateurs de la tâche.
Étape 3. Nous étudions les données disponibles
Nous nous adressons aux administrateurs de notre CRM. Nous allons leur donner un petit coup de pied, et ils nous déchargeront une liste de tous les appels au centre d'appels au cours des dernières années. En fait, nous nous intéressons principalement au fait de l'appel et au moment de la réception. Avec un peu de chance, nous pourrons collecter des données sur la durée des appels, les identifiants des opérateurs et des clients. Dans les centres d'appels plus avancés, il peut même y avoir une sorte de classification des appels par thèmes et résultats, mais nous n'en avons pas encore besoin.
Maintenant, nous allons au superviseur du centre d'appels et demandons d'augmenter tous les horaires des opérateurs pendant plusieurs années. Le superviseur nous demandera une ou deux fois, pâlira, buvera un validolchik - et dans quelques jours, des centaines de lettres avec des excels joints seront envoyées à notre boîte aux lettres. Nous devrons passer encore trois jours pour mettre tout cela dans une grande table avec des équipes. Pour changer, nous connaîtrons la date, l'heure de début, la durée et l'identifiant de l'opérateur.
Pensez immédiatement que plus nous avons de clients, plus ils nous appellent. Les informations historiques sur le nombre de clients ou le volume de production seront utiles - afin que nous puissions prendre en compte les tendances macro. Nous revenons aux administrateurs de CRM ou d'ERP et leur demandons de décharger par volume de ventes, nombre de clients, ou quelque chose comme ça. Disons que vous avez réussi à obtenir des données d'abonnement. Nous pouvons maintenant construire une table où pour chaque date le nombre de clients actifs est visible.
Au total, nous avons trois entités disposées de manière pratique sur trois tablettes:
- Appel au centre d'appels - numéro, date et heure, durée, identifiants client et opérateur.
- Changement d'opérateur - nombre, date, heure de début, durée, identifiant d'opérateur.
- Tendance macro de la charge - date, nombre de clients actifs
Étape 4. Générer des panneaux et former le modèle
Comme vous vous en souvenez, la tâche après la décomposition est tombée en deux. La deuxième partie, sur l'agencement des quarts, nous n'aborderons pas maintenant - il n'y a pas besoin d'apprentissage automatique. Parlons de la première partie - la prévision de charge.
Nous avons formulé l'expérience comme une tâche de régression - "pour chaque heure de l'histoire, nous allons construire un vecteur d'entités et prédire la charge à cette heure." Prenons l'échantillon de formation. La ligne dans l'exemple sera l'heure du calendrier. Chaque heure correspond à un objectif - le nombre de visites pour cette heure.
Réfléchissons maintenant aux signes que nous pouvons utiliser.
- Pour commencer, profitons de la nature calendaire de nos données. Ajoutez les signes du jour de la semaine, de l'heure, du jour du mois. Ils peuvent être enfermés dans des anneaux .
- Ajoutez le nombre d'appels par heure ces jours-là et à ces heures. Vous pouvez prendre le nombre de visites de la dernière semaine, ainsi que la moyenne du mois et de l'année.
- Nous ajoutons de manière similaire le nombre de hits exactement à la même heure et au même jour de la semaine.
- Élargissez la fenêtre d'agrégation - ajoutez le nombre moyen de visites ce jour de la semaine et à cette heure de la journée.
- Essayons de normaliser immédiatement le nombre d'appels à la tendance de charge. Nous allons tester à la fois sur des valeurs normalisées et sur des valeurs brutes.
- Ajoutez la saisonnalité - le nombre de visites par mois l'année dernière, normalisé à la tendance de la charge.
- Au cas où, nous ajoutons également des données brutes sur la tendance de la charge. Et nous prendrons à la fois la valeur au moment actuel et les valeurs "décalées" - il y a une semaine, il y a un mois.
Nous essaierons non seulement la fonction d'erreur RMSE «normale», mais aussi WAPE - elle est plus adaptée à l'objectif du problème. Pour la validation, nous ne pourrons pas utiliser la validation croisée K-fold habituelle - il y aura une chance de regarder vers l'avenir. Par conséquent, nous utiliserons la partition des plis imbriqués et fixerons la taille du pli de test à, disons, exactement 4 semaines. Et les limites des plis seront définies exactement à minuit lundi.
Pour PoC, nous allons essayer deux modèles - un modèle linéaire avec régularisation L1 et le morceau de bois le plus apprécié. Pour un modèle linéaire, n'oubliez pas de standardiser (et logarithme le cas échéant) les signes, et pour un morceau de bois, dévissez plus agressivement les paramètres de régularisation.
Étapes 5 et 6. Nous évaluerons la qualité du modèle et l'effet économique.
Ainsi, tous les préparatifs sont terminés et nous pouvons enfin passer à la partie la plus intéressante du PoC - analyser les résultats et prendre des décisions.
Malheureusement, tout l'exemple était spéculatif, sans données réelles, donc les résultats seront aspirés du doigt. Pour ne pas avoir honte, j'ai pris des chiffres dans l'ordre du livre "Call Center Optimization" de Ger Koole (je l'ai accidentellement trouvé en écrivant cet article ¯\_(ツ)_/¯ ). L'image à partir de là est un exemple de prévision de charge.
Pour commencer, nous avons pu prédire la charge horaire avec WAPE = 14%. Il a été possible d'obtenir des erreurs inférieures à 10% à 43% des heures, inférieures à 20% à 70% des heures.
En général, c'est très bien - nous saisissons assez précisément les fluctuations quotidiennes, les cycles hebdomadaires et les tendances à moyen terme. Nous ne brûlons que sur des fluctuations aléatoires et, très probablement, nous ne pourrons pas les éviter.
Selon la charge, nous pouvons facilement calculer le nombre d'opérateurs qui devraient être dans le quart de travail à un moment donné. Nous avons écrit un algorithme gourmand de planification de décalage non optimal et calculé que nous étions en mesure d'économiser 10% des changements sur la charge prévue. Il s'est avéré que si, en plus des quarts de 12 heures, nous introduisons des quarts de 8 heures et les organisons intelligemment quotidiennement, nous pouvons économiser encore 5%.
Nous traduisons les indicateurs en argent. Le coût actuel de la maintenance annuelle du centre d'appels est de 50 millions de roubles par an. Notre expérience a montré que nous pouvons réduire ce montant de 15%, ce qui entraînera des économies allant jusqu'à 7,5 millions de roubles par an, et pour toute la durée de vie - jusqu'à 22,5 millions de roubles.
C'est un très bon effet, et je veux juste reconnaître le PoC comme un succès. Attardons-nous cependant et analysons ce qui peut mal tourner.
Risques affectant les avantages économiques
Nous avons eu un effet positif en raison de la réduction du nombre d'employés. Nous avons pu réduire le nombre d'employés en réduisant le nombre de quarts de travail. Nous avons pu réduire le nombre de quarts de travail grâce à leur redistribution en fonction de la charge prévue. Nous avons pu prédire la charge en utilisant une simulation basée sur des données historiques.
Premièrement, si les modèles d'utilisation des produits que notre centre d'appels sert changent, les données historiques perdront leur pertinence. La probabilité que les tendances ne changent pas au cours des trois prochaines années est suffisamment faible. Il est nécessaire de fixer les coûts de la formation continue et de la correction du modèle au cours de sa vie.
Deuxièmement, nous avons prédit la charge assez précisément, mais, néanmoins, dans 30% des cas, nous commettons plus de 20% d'erreurs. , . .
-, PoC' , , . - , , . - , .
, "" . , .
, .
,
PoC , .
-, . , CRM. , . , . , . , CRM -. , , .
-, , , , . , , — , . , , . - — .
-, — , , . , , - . , . - - , !.. , . , — 2-5 , 3-5 .
, .
20 . . .
— 5 CRM, 40 , 5 , 10 , 5 , 3120,5 , 23 . 65 , 24 . — 1,3 + 0,48 3 .
— 10 + 60 + 10 + 20 + 10 + 3121 + 53 = 110 51 , 2,2 + 1,02 .
— . 20 + 80 + 20 + 40 + 10 + 3122 + 55 = 170 97 , 3,4 + 1,94 .
, 40% , .
ROI
15% , 22,5 , 7,5 . 1,3 + 0,48 , +6,2 (+377% ROI) +21 (+1160% ROI) . .
, , . , 50% , 10%- , 5% . 2,5% — 7,5% 15% . 3,75 , 11,25 . .
— 2,2 1,02 . +55% ROI , +252% . , .
20%- . 5% , 2,5% , 1,25 , 3,75 . , . , 3 +17% ROI. , . , 20%- .
3,4 . ROI +121% . 3 +108% ROI "" .
, , ROI +55% +252% , , . , .
| | Income | Dev | Support | ROI 1 | ROI 3 |
|---|
| Optim | Optim | 7,5 | 1,3 | 0,5 | +4x | +11x |
| Optim | Real | 7,5 | 2,2 | 1,0 | +2x | +6x |
| Optim | Pessim | 7,5 | 3,4 | 1,9 | +85% | +3x |
| Real | Optim | 3,75 | 1,3 | 0,5 | +155% | +5 |
| Real | Real | 3,75 | 2,2 | 1,0 | +48% | +2,5 |
| Real | Pessim | 3,75 | 3,4 | 1,9 | -7% | +112% |
| Pessim | Optim | 1,25 | 1,3 | 0,5 | -14% | +108% |
| Pessim | Real | 1,25 | 2,2 | 1,0 | -50% | +17% |
| Pessim | Pessim | 1,25 | 3,4 | 1,9 | -69% | -29% |
PS
PoC, , ? , ...
-, , WFM, WorkForce Management. , — , . - , , . $1000 $2500. WFM , . , WFM -. , ?
, — , . DS', . . , . , . .
, . "" 7,5%, 37,5 . . . — ROI. — . ROI 26,66 , 53 . ROI 27 .
.
-, . - - . .
-, . , . .
— .
Conclusions
- WFM -. , - . WFM — .
- — .
- , ,
? , PoC'. - PoC' , ?
- — - .