Kürzlich warf das Datum der Satanisten in einem gemütlichen Chatraum die Frage auf, wie interne maschinelle Lernprojekte richtig "verkauft" werden können. Es stellte sich heraus, dass viele von uns sehr zimperlich über die wirtschaftliche Machbarkeit unserer Aktivitäten sind. In der Zwischenzeit ist kein MBA erforderlich, um eine minimale Bewertung der Projektrentabilität durchzuführen. In einem kurzen Artikel (10 Seiten Text, ke-ke-ke) werde ich Ihnen erläutern, was der ROI ist, wie er für ein internes Projekt bewertet wird und welche Rolle er spielt Proof of Concept und warum im wirklichen Leben alles schief gehen kann. Wir werden dies alles um ein fiktives Projekt herum tun, um die Planung für ein Callcenter zu automatisieren. Willkommen bei Katze!
Unser fiktives Projekt
Das Call Center hat 100 Betreiber. Sie arbeiten nach einem schwebenden Zeitplan und arbeiten in Schichten von 8 oder 12 Stunden. Die Schichten beginnen zu unterschiedlichen Zeiten und sind so angeordnet, dass viele Menschen zu Stoßzeiten und eine kleine Anzahl von Menschen zu kalten Zeiten nachts und am Wochenende wachsam sind. Der Zeitplan wird vom Callcenter-Bereitschaftsdienstleiter an dunklen Freitagabenden geplant, indem die Last für die nächste Woche im Auge geplant wird.
Ein 8-Stunden-Tag des Call-Center-Betreibers kostet das Unternehmen 2.000 Rubel. Wenn wir davon ausgehen, dass ein Jahr 250 Arbeitstage hat, kostet das Call Center das Unternehmen 100 2.000 250 = 50 pro Jahr. Wenn wir die Planung automatisieren, können wir die stündliche Belastung vorhersagen und Schichten anordnen, um die Anzahl der Dienstbetreiber in Abhängigkeit von der prognostizierten Belastung zu variieren. Wenn unsere Prognose und Anordnung der Schichten mindestens 10% besser ist als die Prognose und Anordnung des Vorgesetzten, sparen wir bis zu 5 Millionen Rubel. Im Jahr. Wenn es uns wirklich gelingt, eine Verbesserung um 10% zu erreichen, wird sich das Projekt definitiv auszahlen. Oder nicht? .. Überlegen wir uns, wie wir solche Entscheidungen treffen können.
Nach ROI
Bevor Sie ein großes Projekt starten, sollten Sie dessen wirtschaftliche Machbarkeit bewerten. Eine Lehrbuchmethode hierfür ist die Berechnung des Return on Investment (ROI).
Der ROI (Return on Investment) ist ein Indikator für die Projektrentabilität, der dem Verhältnis von Einkommen zu ausgegebenen Investitionen entspricht. ROI <100% bedeutet, dass sich das Projekt nicht auszahlt.
Die ersten Kosten für das Projekt fallen sofort zu Beginn an - für den Kauf von Eisen und Lizenzen, die Entwicklung des Systems und dessen Implementierung. Dies nennt man Investitionsausgaben. Während der Laufzeit des Projekts müssen auch die Kosten getragen werden - für die Anmietung derselben Hardware und Lizenzen, um die Funktionsfähigkeit des Systems und manchmal die Arbeit der Betreiber zu unterstützen. Dies wird als Betriebsaufwand bezeichnet.
ML-Projekte haben in der Regel keine „sofortigen Einnahmen“. Projekteinnahmen sind nur in Betrieb, d.h. rechtzeitig. Im Fall unseres Call Centers wird der Umsatz beispielsweise als Kostenersparnis für die Betreiber gebildet. Wenn die Betriebskosten des Projekts die Einnahmen übersteigen, wird sich das Projekt niemals auszahlen.
Aufgrund der "sofortigen" Investitionen zu Beginn des Projekts hängt der ROI von dem Zeitpunkt ab, zu dem wir die Rentabilität bewerten. In der Regel wird zur Berechnung des ROI entweder das Jahr, der Planungshorizont oder die Lebensdauer des Systems verwendet. Mit dem Jahr ist alles klar - dies ist eine einfache Möglichkeit zu verstehen, ob sich das Projekt in einem Jahr auszahlt oder nicht. Der Planungshorizont ist das Zeitintervall, in dem die Unternehmensstrategie geplant und Budgets erstellt werden. In kleinen und dynamischen Unternehmen überschreitet der Horizont selten ein Jahr, in großen und stabilen kann er drei bis zehn Jahre betragen.
Am äußersten Horizont der Planung können Sie jeden Müll wieder gutmachen, aber das gemeinsame Leben wird durch die Lebensdauer des Systems geschützt. Normalerweise erfüllt das System nach einigen Jahren nicht mehr die Anforderungen des Unternehmens und wird entweder durch ein neues ersetzt, weggeworfen oder (meistens) auf ewiger Unterstützung verrottet. Mit dem schnellen Wachstum des Geschäfts kann das System nicht immer sechs Monate lang leben, in einem stabilen Markt wird das System in 3-5 Jahren ohne Änderungen veraltet und nur eine sehr konservative Box in einem sehr konservativen Umfeld kann mehr als 10 überleben. Abzinsungssätze, Abschreibungen und andere Buchhaltungszauber werden professionellen Finanziers überlassen.
Somit erfolgt die Berechnung des ROI gemäß der folgenden Formel:
Proof of Concept
Wie können wir überhaupt wissen, dass eine neue Implementierung die Zahl um 10% erhöhen wird?
Erstens können wir diese Zahl zufällig auswählen und sie vom nächsten Augur schütteln. Dies funktioniert oft, führt aber nicht seltener zu einer Katastrophe. Ein solches Vanging wird nicht öffentlich gefördert, dennoch erkennen die Ältesten an, dass viele erfolgreiche Entscheidungen tatsächlich „von Hand“ getroffen wurden.
Zweitens können wir uns auf die Erfahrungen früherer Implementierungen verlassen. Zum Beispiel führen wir die Automatisierung in das fünfte Call Center in Folge ein, bevor wir Ergebnisse von 7-10% sahen, wir alle gängigen Probleme kennen und lösen können, und es scheint, dass uns nichts im Stich lassen sollte. Je mehr Implementierungen wir durchgeführt haben, desto genauer ist unsere Prognose und desto besser verstehen wir die Auswirkungen verschiedener Abweichungen vom Ideal auf das Ergebnis.
Selbst mit der Erfahrung einer einzelnen Implementierung kann eine viel aussagekräftigere Prognose erstellt werden als mit dem Chuyka. Eine mutige Folge davon - es scheint, dass selbst eine einzige unvollendete Implementierung uns vor dem Chuyka einen großen Vorsprung verschaffen wird. Wir kommen also zur Idee von Proof of Concept oder PoC.
PoC wird benötigt, um die Leistung einer Hypothese zu bestätigen oder zu widerlegen sowie ihre Wirksamkeit zu bewerten. PoC impliziert keine vollständige Implementierung, was bedeutet, dass es schnell und kostengünstig durchgeführt werden kann. Wie kann in Data Science-Projekten beschleunigt werden?
- Manuelles Verschmutzen von Daten direkt von den Stellen, an denen die Analyse am einfachsten ist. Auch wenn diese Quelle für die Produktion nicht akzeptabel ist, ist dies nicht wichtig.
- Verwenden Sie die dümmsten Heuristiken als Basislinie. Beispielsweise ist die Basislinie für die Vorhersage der Last am nächsten Tag die Last für heute. Noch kühler - die durchschnittliche Belastung in den letzten 5-7-30 Tagen. Sie werden überrascht sein, aber eine solche Heuristik kann nicht immer übertroffen werden.
- Bewerten Sie die Qualität mit Backtesting - führen Sie keine neuen Langzeitversuche durch. Alle Daten sind bereits in der Historie, wir werden die Auswirkungen darauf bewerten.
- Versuchen Sie nicht, wiederverwendbaren Code zu erstellen. Der gesamte Code nach PoC wird in den Bucket geworfen. Wir wiederholen dies jeden Morgen, bevor wir uns zum Code setzen.
- Versuchen Sie nicht, ein cooles Modell zu machen. Setzen Sie sich feste Fristen - ein bis drei bis fünf Tage pro Modell. In solchen Zeiträumen wird es nicht funktionieren, sich in eine komplexe Implementierung zu „vertiefen“, aber es wird sich herausstellen, dass viele einfache Optionen durchlaufen werden. Für diese Optionen wird eine zuverlässige niedrigere Schätzung erhalten.
- Suchen Sie aggressiv nach einem Rechen, treten Sie auf alle lächerlichen Stellen und testen Sie gefährliche Ideen. Je mehr Rechen wir in der PoC-Phase sammeln, desto geringer ist das Risiko während der Produktionsentwicklung.
PoC-Stufen
Die Dauer des PoC variiert normalerweise zwischen einer Woche und einigen Monaten. Die Aufgabe wird von einer Person erledigt, die das Datum des Satanisten leitet. Das Durchführen eines PoC erfordert auch viel Aufmerksamkeit des Geschäftskunden - zu Beginn des PoC zu sprechen und die Ergebnisse am Ende zu verstehen. Insgesamt kostet uns PoC bis zu zwei Monate Arbeit des führenden DS und mehrere Tage Arbeit von Geschäftskunden. Hier ist der erste Indikator: Wenn der Kunde die Zeit für PoC nicht gefunden hat, ist das Ergebnis eines großen Projekts nicht wirklich gefragt.
Also die Schritte.
- Wechseln Sie von Wunschliste und Buzz Words zu bestimmten Geschäftsanforderungen. Dies ist eine traditionelle Business-Analytics-Aufgabe, für DS ist es jedoch sehr ratsam, dies selbst zu tun. So kann er die Bedürfnisse des Kunden genauer verstehen und die zweite Phase abschließen ...
- Formulieren Sie ein Experiment. Der richtige Wortlaut ist der Schlüssel zum Erfolg eines Projekts. DS sollte bestimmen, wo im Geschäftsprozess eine automatisierte Entscheidung getroffen wird, welche Informationen am Eingang verfügbar sind, was am Ausgang erwartet wird, auf welche Art von maschinellem Lernen sie reduziert werden kann, welche Daten während der Schulung und Produktion benötigt werden, für welche technischen und geschäftlichen Metriken sie verwendet werden sollen Einschätzung des Erfolgs.
- Beschäftige dich mit den Daten. DS muss verstehen, welche Daten uns allgemein zur Verfügung stehen. Bewertung ihrer attributiven Zusammensetzung, Vollständigkeit, Tiefe der Geschichte, Konsistenz. Stellen Sie schnell manuell einen Datensatz zusammen, der ausreicht, um ein Modell zu erstellen und eine Hypothese zu testen. Es wäre schön, sofort zu erkennen, ob die Daten in der Produktion von den im Zug verfügbaren Daten und den hier gesammelten Daten abweichen.
- Ingenieur Features und bauen ein Modell. Junge Satanisten aus jungen Nägeln denken nur an Models (EUROPA), daher sind Kommentare überflüssig.
- Bewerten Sie die Qualität des Modells. Führen Sie eine Kreuzvalidierung korrekt durch, berechnen Sie technische und geschäftliche Kennzahlen und bewerten Sie die Grenzen, bis zu denen sie in der Produktion schwanken können. All dies sollte auch DS tun.
- Bewerten Sie den resultierenden ROI - das ist alles, um es zu erreichen. Zur Bewertung können Sie Vertreter des Kunden und jemanden gewinnen, der weiß, wie man Finnen macht. Modelle.
Lassen Sie uns einen fiktiven PoC machen, der auf unserem fiktiven Projekt basiert.
Stufe 1. Übertragen Sie "Wunschliste" auf die Aufgabe
Hier ist der Wortlaut der Wunschliste:
Wenn wir die Planung automatisieren, sparen wir anscheinend nicht nur Zeit bei der Planung, sondern lernen auch, wie Sie die Anzahl der Schichten je nach Belastung variieren können.
Was bedeutet das wirklich?
Es ist erforderlich, ein System zu erstellen, das gemäß der Historie der Schichten und Anrufe die Last für den nächsten Zeitraum vorhersagt und Schichten so anordnet, dass die Last effektiv genutzt wird.
Die Lastprognose-Prognosemetrik ist der Fehler in der Anzahl der Treffer pro Zeitscheibe.
Effizienzmetrik für die Lastauslastung - 95. Perzentil der Wartezeit.
Wirtschaftsmetrik - die Anzahl der Schichten für den Abrechnungszeitraum.
Die Aufgabe gliederte sich in zwei Teile - wie man die Last vorhersagt und wie man Schichten arrangiert.
Zunächst möchten wir die Anzahl der Anrufe zwei Wochen im Voraus vorhersagen, damit die Prognose nicht um mehr als einen bestimmten Prozentsatz unter die tatsächlichen Werte fällt.
Zweitens möchten wir die Anzahl der Schichten pro Periode minimieren, um das 95. Perzentil der Wartezeit innerhalb akzeptabler Grenzen zu halten, während die Last wie vorhergesagt sein wird.
Aufgabe 1. Lastvorhersage
Am Freitag der ersten Woche möchten wir die Anzahl der Anrufe zu jeder Stunde der dritten Woche vorhersagen. Das Ergebnis der Prognose sind 168 Nummern - eine Nummer für jede Stunde der nächsten Woche.
Ein Intervall von einer Woche muss durchgeführt werden, damit die Bediener Zeit haben, sich an den Zeitplan anzupassen.
Wir werden am Freitagnachmittag eine Prognose abgeben - einerseits ist sie so nah wie möglich an den Zieldaten, andererseits bleibt noch ein halber Tag, um den Zeitplan manuell festzulegen. Wir haben Zugriff auf historische Daten zu Anfragen für den gesamten Verlauf sowie auf einen Kalender. Wir werden daraus viele Funktionen erstellen. Es wäre schön, die Last an unsere Veröffentlichungen zu binden, aber wir werden solche Daten in der PoC-Phase nicht haben.
Wir reduzieren das Problem auf Regression. Für jede Stunde in der Geschichte erstellen wir einen Merkmalsvektor und sagen die Belastung zu dieser Stunde voraus. Die Erfolgsmetrik sei MAPE (oder WAPE, wir werden es auf dem Weg herausfinden). Eine Kreuzvalidierung "Stirn" für temporäre Daten ist nicht möglich - wir werden in die Zukunft schauen. Der übliche Ausweg besteht darin, die Geschichte mit einer wöchentlichen Schicht (vier Wochen?) In sich überschneidende Falten zu zerlegen und die letzte Woche als Kontrolle zu betrachten. Das Erfolgskriterium ist, ob unsere WAPE (oder wer sonst?) Innerhalb angemessener Grenzen gehalten werden kann. Denken Sie im Verlauf des Experiments erneut über vernünftige Grenzen nach.
Aufgabe 2. Anordnung der Schichten
Entsprechend der vorhergesagten Belastung möchten wir sie mit Schichten abdecken, damit die Anzahl der Schichten minimal ist und die Qualitätsindikatoren auf einem akzeptablen Niveau bleiben.
Im Moment ordnen wir keine Operatoren im Kalender an, sondern bestimmen nur, wie viele Schichten an welchem Tag und mit welcher Überlappung platziert werden sollen.
Die Berechnung wird unmittelbar nach Abschluss der Lastprognose durchgeführt. Es stellt sich heraus, dass dieselben Daten verfügbar sind, plus eine Prognose für die Last.
Es scheint, dass das Problem auf das umgekehrte Problem eines Rucksacks, den sogenannten, reduziert werden kann Bin Packing Problem . Dies ist ein NP-vollständiges Problem, aber es gibt Algorithmen für seine suboptimale Lösung. Die Aufgabe des Experiments besteht darin, ihre Anwendbarkeit zu bestätigen oder zu widerlegen. Die Zielmetrik ist die Anzahl der Verschiebungen in der Kombination, die Randbedingungen sind die durchschnittliche oder maximale Wartezeit (oder eine Art Perzentil). Wir werden gezwungen sein, die Wartezeit in Abhängigkeit von der Anzahl der Anrufe und der Anzahl der Bediener im Job zu modellieren.
Stufe 3. Wir untersuchen die verfügbaren Daten
Wir gehen zu den Administratoren unseres CRM. Wir werden sie ein wenig treten und sie werden uns eine Liste aller Anrufe an das Callcenter der letzten Jahre entladen. Tatsächlich interessieren uns in erster Linie die Tatsache der Beschwerde und der Zeitpunkt des Eingangs. Mit etwas Glück können wir Daten zur Anrufdauer, Kennungen von Betreibern und Kunden sammeln. In fortgeschritteneren Callcentern gibt es möglicherweise sogar eine Klassifizierung von Anrufen nach Themen und Ergebnissen, die wir jedoch noch nicht benötigen.
Jetzt gehen wir zum Callcenter-Supervisor und bitten darum, alle Zeitpläne der Betreiber für mehrere Jahre zu erhöhen. Der Vorgesetzte wird uns ein paar Mal fragen, blass werden, einen Validolchik trinken - und ein paar Tage später werden Hunderte von Briefen mit angehängten Excel-Dateien an unsere Mailbox weitergeleitet. Wir müssen noch drei Tage verbringen, um all dies mit Schichten an einen großen Tisch zu bringen. Um dies zu ändern, kennen wir Datum, Startzeit, Dauer und Bediener-ID.
Denken Sie sofort, je mehr Kunden wir haben, desto mehr rufen sie uns an. Historische Informationen über die Anzahl der Kunden oder das Produktionsvolumen sind hilfreich, damit wir Makrotrends berücksichtigen können. Wir gehen erneut zu den Administratoren von CRM oder ERP und bitten sie, nach Verkaufsvolumen, Anzahl der Kunden oder ähnlichem zu entladen. Angenommen, Sie haben Abonnementdaten abgerufen. Jetzt können wir eine Tabelle erstellen, in der für jedes Datum die Anzahl der aktiven Clients sichtbar ist.
Insgesamt haben wir drei Einheiten, die bequem in drei Tafeln angeordnet sind:
- Rufen Sie das Callcenter an - Nummer, Datum und Uhrzeit, Dauer, Kunden- und Betreiberkennungen.
- Bedienerschicht - Nummer, Datum, Startzeit, Dauer, Bedienerkennung.
- Makrotrend des Ladedatums, Anzahl der aktiven Clients
Stufe 4. Generieren Sie Zeichen und trainieren Sie das Modell
Wie Sie sich erinnern, fiel die Aufgabe nach der Zersetzung in zwei Teile. Den zweiten Teil über die Anordnung der Schichten werden wir jetzt nicht ansprechen - es besteht keine Notwendigkeit für maschinelles Lernen. Lassen Sie uns über den ersten Teil sprechen - die Lastprognose.
Wir haben das Experiment als Regressionsaufgabe formuliert: "Für jede Stunde in der Geschichte werden wir einen Merkmalsvektor erstellen und die Belastung zu dieser Stunde vorhersagen." Lassen Sie uns das Trainingsmuster sammeln. Die Zeile in der Stichprobe ist die Kalenderstunde. Jede Stunde entspricht einem Ziel - der Anzahl der Treffer für diese Stunde.
Lassen Sie uns nun darüber nachdenken, welche Zeichen wir verwenden können.
- Nutzen wir zunächst den Kalendercharakter unserer Daten. Fügen Sie die Zeichen des Wochentags, der Stunde und des Monats hinzu. Sie können in Ringen eingeschlossen werden .
- Fügen Sie die Anzahl der Anrufe pro Stunde an solchen Tagen und zu solchen Stunden hinzu. Sie können die Anzahl der Treffer in der letzten Woche sowie den Durchschnitt für Monat und Jahr ermitteln.
- In ähnlicher Weise addieren wir die Anzahl der Treffer genau zur gleichen Stunde und am gleichen Wochentag.
- Nehmen Sie das Aggregationsfenster weiter - addieren Sie die durchschnittliche Anzahl der Treffer an diesem Wochentag und zu dieser Tageszeit.
- Versuchen wir, die Anzahl der Aufrufe für den Lasttrend sofort zu normalisieren. Wir werden sowohl auf normalisierten als auch auf Rohwerten testen.
- Saisonalität hinzufügen - die Anzahl der Treffer pro Monat im letzten Jahr, normalisiert auf den Lasttrend.
- Für alle Fälle fügen wir auch Rohdaten über den Trend der Last hinzu. Und wir werden sowohl den Wert im aktuellen Moment als auch die "verschobenen" Werte nehmen - vor einer Woche, vor einem Monat.
Wir werden nicht nur die "normale" RMSE-Fehlerfunktion ausprobieren, sondern auch WAPE - sie ist für den Zweck des Problems besser geeignet. Für die Validierung können wir nicht die übliche K-fache Kreuzvalidierung verwenden - es besteht die Möglichkeit, in die Zukunft zu schauen. Daher werden wir die Partition " Verschachtelte Falten" verwenden und die Größe der Testfalte auf beispielsweise genau 4 Wochen festlegen. Und die Grenzen der Falten werden am Montag genau um Mitternacht festgelegt.
Für PoC werden wir zwei Modelle ausprobieren - ein lineares mit L1-Regularisierung und das beliebteste Stück Holz. Vergessen Sie bei einem linearen Modell nicht, die Vorzeichen zu standardisieren (und gegebenenfalls zu logarithmieren), und schrauben Sie bei einem Stück Holz die Regularisierungsparameter aggressiver ab.
Schritte 5 und 6. Wir werden die Qualität des Modells und die wirtschaftlichen Auswirkungen bewerten.
Damit sind alle Vorbereitungen abgeschlossen, und wir können endlich zum interessantesten Teil von PoC übergehen - Analyse der Ergebnisse und Treffen von Entscheidungen.
Leider war das gesamte Beispiel spekulativ, ohne echte Daten, so dass die Ergebnisse aus dem Finger gesaugt werden. Um mich nicht so zu schämen, habe ich Zahlen in der Reihenfolge aus dem Buch "Call Center Optimization" von Ger Koole genommen (ich habe sie versehentlich beim Schreiben dieses Artikels gefunden ¯\_(ツ)_/¯ ). Das Bild von dort ist ein Beispiel für eine Lastprognose.
Zunächst konnten wir die stündliche Belastung mit WAPE = 14% vorhersagen. Es konnten Fehler von weniger als 10% bei 43% der Stunden und weniger als 20% bei 70% der Stunden erzielt werden.
Im Allgemeinen ist dies sehr gut - wir erfassen recht genau tägliche Schwankungen, wöchentliche Zyklen und mittelfristige Trends. Wir brennen nur bei zufälligen Schwankungen und werden sie höchstwahrscheinlich nicht vermeiden können.
Je nach Belastung können wir leicht die Anzahl der Bediener berechnen, die zu einem bestimmten Zeitpunkt in der Schicht sein sollten. Wir haben einen gierigen, nicht optimalen Schichtplanungsalgorithmus geschrieben und berechnet, dass wir 10% der Schichten bei der prognostizierten Last einsparen konnten. Es stellte sich heraus, dass wir weitere 5% sparen können, wenn wir zusätzlich zu 12-Stunden-Schichten 8-Stunden-Schichten einführen und diese geschickt für Tage arrangieren.
Wir übersetzen Indikatoren in Geld. Die aktuellen Kosten für die jährliche Wartung des Call Centers betragen 50 Millionen Rubel pro Jahr. Unser Experiment hat gezeigt, dass wir diesen Betrag um 15% reduzieren können, was zu Einsparungen von bis zu 7,5 Millionen Rubel pro Jahr und für die gesamte Lebensdauer von bis zu 22,5 Millionen Rubel führt.
Dies ist ein sehr guter Effekt, und ich möchte PoC nur als erfolgreich erkennen. Lassen Sie uns jedoch verweilen und analysieren, was schief gehen kann.
Risiken, die sich auf den wirtschaftlichen Nutzen auswirken
Wir haben uns aufgrund der Reduzierung der Mitarbeiterzahl positiv ausgewirkt. Durch die Reduzierung der Schicht konnten wir die Anzahl der Mitarbeiter reduzieren. Wir konnten die Anzahl der Schichten aufgrund ihrer Umverteilung entsprechend der vorhergesagten Belastung reduzieren. Wir konnten die Belastung mithilfe einer Simulation anhand historischer Daten vorhersagen.
Erstens verlieren historische Daten an Relevanz, wenn sich die Verwendungsmuster unserer Produkte in unserem Call Center ändern. Die Wahrscheinlichkeit, dass sich die Muster in den nächsten drei Jahren nicht ändern, ist gering genug. Es ist notwendig, die Kosten für die Weiterbildung und Korrektur des Modells im Laufe seines Lebens zu legen.
Zweitens haben wir die Belastung ziemlich genau vorhergesagt, aber dennoch machen wir in 30% der Fälle mehr als 20% Fehler. , . .
-, PoC' , , . - , , . - , .
, "" . , .
, .
,
PoC , .
-, . , CRM. , . , . , . , CRM -. , , .
-, , , , . , , — , . , , . - — .
-, — , , . , , - . , . - - , !.. , . , — 2-5 , 3-5 .
, .
20 . . am Tag.
— 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 | Unterstützung | 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 .
.
-, . - - . .
-, . , . .
— .
Schlussfolgerungen
- WFM -. , - . WFM — .
- — .
- , ,
? , PoC'. - PoC' , ?
- — - .