最近，在一个舒适的聊天室中，撒旦主义者的约会提出了一个问题，即如何正确地“出售”内部机器学习项目。 事实证明，我们许多人对我们的活动的经济可行性感到非常惊讶。 同时，为了对项目的获利能力进行最低限度的评估，不需要MBA-在简短的文章（10页文字，ke-ke-ke）中，我将告诉您ROI是什么，如何为内部项目评估ROI，它起什么作用概念验证，以及在现实生活中为什么一切都会出错。 我们将围绕一个虚拟项目来完成所有这些工作，以自动安排呼叫中心的调度。 欢迎来到猫！
我们的虚构项目
呼叫中心有100名接线员。 他们按浮动时间表工作，每8或12个小时轮班工作。 轮班在不同的时间开始，并且安排的方式可以确保许多人在高峰时段保持警惕，而在寒冷的夜晚和周末则保持少数人的注意。 该计划是由呼叫中心值班主管在黑暗的星期五晚上计划的，目的是计划下周的工作量。
呼叫中心接线员每天工作8小时，公司需为此支付2,000卢布。 如果我们假设一年中有250个工作日，则呼叫中心每年将花费公司100 2.000 250 = 50 。 如果我们使调度自动化，我们可以预测小时负荷并安排班次以根据预测负荷改变值班人员的数量。 如果我们的班次预测和安排比主管的预测和安排至少好10％，我们将节省多达500万卢布。 每年。 如果我们真的设法实现10％的改进，那么该项目肯定会取得回报。 是否？..让我们考虑如何做出这样的决定。
根据投资回报率
在开始大型项目之前，最好评估一下其经济可行性。 一种实现这一目标的教科书方法是计算投资回报率ROI。
ROI（投资回报率）是项目获利能力的指标，等于收入与投资支出的比率。 ROI <100％意味着该项目将无法获得回报。
该项目的第一笔费用从一开始就立即发生-购买铁和许可证，系统开发及其实施。 这称为资本支出。 在项目的整个生命周期中，它还必须承担费用-租用相同的硬件和许可证，以支持系统的可操作性，有时还需要操作员的工作。 这称为运营支出。
ML项目通常没有“瞬时收入”。 项目收入仅在运营，即 及时。 例如，在我们的呼叫中心中，收入是为运营商节省成本而形成的。 如果项目的运营成本超过收入，则该项目将永远无法获得回报。
由于项目开始时的“即时”资本支出，ROI取决于我们评估获利能力的时间。 通常，可以使用年份，计划范围或系统寿命来计算ROI。 一年中一切都清楚了–这是了解该项目是否会在一年内获得回报的简便方法。 计划范围是计划公司战略和制定预算的时间间隔。 在小型且充满活力的公司中，期限很少超过一年，而在大型而稳定的公司中，期限可能会从三到十年。
在规划的远景中，您可以收回任何垃圾，但是共同的生命受到系统生命周期的保护。 通常，几年后，该系统将无法满足业务需求，并且将其替换为新的系统，将其丢弃，或者（通常）留给永久支持。 随着业务的快速增长，该系统无法始终保持六个月的使用寿命，在稳定的市场中，该系统在3-5年内不做任何改动就已过时，只有在非常保守的环境中使用非常保守的设备才能生存超过10个。 贴现率，折旧和其他会计魔术将留给专业金融家。
因此，ROI的计算是根据以下公式进行的：
概念证明
我们什至不知道新的实施将使这一数字增加10％？
首先，我们可以随机选择此数字，然后从最近的预兆中摇动它。 这通常是可行的，但同样会导致灾难。 公众不鼓励这种冒昧的举动；但是，长者们意识到，许多成功的决定实际上是“手工”做出的。
其次，我们可以依靠过去实现的经验。 例如，我们将自动化连续引入第五个呼叫中心，在此之前，我们看到7-10％的结果，我们知道并可以解决所有常见问题，而且似乎没有什么可以让我们失望的。 我们执行的实施次数越多，我们的预测就越准确，并且我们就可以更好地理解各种偏离理想状况对结果的影响。
即使只有一次实施的经验，也可以做出比Chuyka更有意义的预测。 这是一个大胆的结果-似乎即使是一个未完成的实现也将使我们在Chuika面前拥有巨大的领先优势。 因此，我们提出了概念证明或PoC的想法。
需要PoC来确认或否定假设的性能以及评估其有效性。 PoC并不意味着完整的实现，这意味着可以快速，廉价地执行它。 数据科学项目中有哪些加速方法？
- 直接从最容易分析的地方手动获取肮脏的数据。 即使该来源不能用于生产，这也不重要。
- 使用最愚蠢的启发法作为基线。 例如，预测第二天负荷的基准线是今天的负荷。 更凉爽-过去5-7-30天的平均负载。 您会感到惊讶，但不能总是超越这种启发式。
- 通过回溯测试评估质量-不要进行新的长期试验。 所有数据已经在历史记录中，我们将评估其影响。
- 不要尝试制作可重用的代码。 PoC之后的所有代码都将丢入存储桶中。 我们每天早晨重复此步骤，然后再坐下来编写代码。
- 不要试图做一个很酷的模型。 为自己设定严格的期限-每个模型一到三到五天。 在这样的时期内，“挖掘”成一个复杂的实现是行不通的，但是事实证明，它会经历许多简单的选择。 对于这些选项，可以获得可靠的较低估计。
- 积极寻找耙子，踩在所有荒谬的地方，测试危险的想法。 我们在PoC阶段收集的佣金越多，生产开发期间的风险就越小。
PoC阶段
PoC的持续时间通常从一周到几个月不等。 这项工作将由一名领导撒旦主义者约会的人来完成。 进行PoC还需要业务客户的大量关注-在PoC开始时进行交谈并在结束时了解结果。 总而言之，PoC将使我们花费领先的DS最多两个月的时间，以及业务客户几天的时间。 这是第一个指标-如果客户没有找到PoC的时间，那么将不会真正需要大型项目的结果。
所以，步骤。
- 从愿望清单和流行语到特定的业务需求。 这是一项传统的业务分析任务，但建议DS自己完成。 这样他就可以更准确地了解客户的需求并完成第二阶段...
- 制定实验。 正确的措辞是项目成功的关键。 DS应该确定在业务流程中的何处做出自动决策，在输入处可获得什么信息，在输出处期望得到什么，可以将其减少为什么样的机器学习任务，在培训和生产期间将需要哪些数据，要使用哪些技术和业务指标成功评估。
- 处理数据。 DS必须了解我们通常可以使用哪些数据。 评估其归因组成，完整性，历史深度，一致性。 快速手动组装足以建立模型和检验假设的数据集。 立即了解生产中的数据是否会与火车中可用的数据以及我们在此处收集的数据有所不同，这将是很好的。
- 工程师功能并建立模型。 年轻的撒旦主义者从年轻的指甲开始就只考虑模特（EUROPE），因此多余的评论。
- 评价模型的质量。 正确进行交叉验证，计算技术和业务指标，以及评估它们在生产中可能波动的极限。 所有这一切也应该做DS。
- 评估最终的投资回报率-仅此而已。 为了进行评估，您可以吸引客户代表和知道如何找到自己的人。 型号。
让我们根据虚构的项目进行虚构的PoC。
阶段1.将“愿望清单”转移到任务
这是愿望清单的措辞：
看来，如果我们使计划自动化，我们不仅可以节省计划时间，还可以学习如何根据负荷来改变班次数量。
这到底是什么意思？
有必要创建一个系统，该系统根据班次和通话的历史记录来预测下一个时段的负载，并以有效利用负载的方式安排班次。
负载预测预测指标是每个时间段的点击次数中的误差。
负载利用率效率指标-等待时间的95％。
经济指标-会计期间的班次数量。
任务分为两部分-如何预测负荷以及如何安排班次。
首先，我们要提前两周预测通话次数，以使预测不会低于实际值超过一定百分比。
其次，我们希望最小化每个周期的班次数量，以将等待时间的95％保持在可接受的范围内，而负载将如预期的那样。
任务1.负荷预测
在第1周的星期五，我们要预测在第3周的每个小时的呼叫数量。预测结果将是168个号码-下周的每个小时一个号码。
必须间隔一周，以便操作员有时间调整时间表。
我们将在星期五下午进行预测-一方面，该日期尽可能接近目标日期，另一方面，还有半天的时间来手动安排时间表。 我们将可以访问有关整个历史记录的历史数据以及日历。 我们将由此构建许多功能。 将负载与我们的发行版绑定会很好，但是在PoC阶段我们将没有此类数据。
我们将问题简化为回归。 对于历史上的每个小时，我们将构建一个特征向量并预测该小时的负载。 假设成功指标为MAPE（或WAPE，我们会一路找出来）。 无法对临时数据进行交叉验证“前额”-我们将展望未来。 通常的解决方法是按每周轮换（四个星期？）的方式将故事分解为相交的褶皱，然后将最后一周作为对照。 成功的标准是我们的WAPE（或其他人）是否可以保持在合理范围内。 再次，随着实验的进行，考虑合理的界限。
任务2.轮班安排
根据预测的负载，我们希望用班次覆盖它，以使班次数量最少，并且质量指标保持在可接受的水平。
目前，我们还没有安排日历上的运算符，我们只确定在哪一天放什么班次以及哪些重叠。
负荷预测完成后，将立即执行计算。 事实证明，所有相同的数据都是可用的，再加上负载的预测。
似乎可以将问题简化为背包的反问题，即所谓的背包 装箱问题 。 这是一个NP完全问题，但是有一些算法不能解决该问题。 实验的任务是确认或驳斥其适用性。 目标度量将是组合中的移位数，边界条件是等待的平均或最大持续时间（或某种百分比）。 我们将不得不根据呼叫次数和作业中操作员的数量对等待时间进行建模。
第三阶段。我们研究可用数据
我们去找CRM的管理员。 我们将对他们稍加踢一下，然后他们将为我们卸载过去几年来呼叫中心的所有呼叫清单。 实际上，我们主要对上诉的事实和收到时间感兴趣。 运气好的话，我们将能够收集有关通话时间，话务员和客户标识符的数据。 在更高级的呼叫中心中，甚至可以按主题和结果对呼叫进行某种分类，但是我们还不需要。
现在，我们去呼叫中心主管，要求提高所有运营商几年的时间表。 主管会问我们几次，变苍白，喝一口Validolchik，然后在几天之内将数百封带有卓越表现的信件转发给我们的邮箱。 我们将不得不再花三天的时间将所有这些转变成一张大桌子。 要进行更改，我们将知道日期，开始时间，持续时间和操作员ID。
立即认为我们拥有的客户越多，他们给我们打电话的次数就越多。 有关客户数量或产量的历史信息将派上用场-因此我们可以考虑宏观趋势。 我们再次去找CRM或ERP的管理员，要求他们按销量，客户数量或类似的东西卸载。 假设您设法获取订阅数据。 现在我们可以建立一个表格，其中每个日期都可以看到活动客户端的数量。
总共，我们可以方便地将三个实体布置在三个平板电脑中：
- 呼叫呼叫中心-号码，日期和时间，持续时间，客户和话务员标识符。
- 操作员班次-数字，日期，开始时间，持续时间，操作员标识符。
- 负载的宏观趋势-日期，活动客户数
阶段4.生成符号并训练模型
您还记得，分解后的任务分为两个。 第二部分，关于班次的安排，我们现在将不涉及-无需机器学习。 让我们谈谈第一部分-负载预测。
我们将实验公式化为一个回归任务-“在历史记录中的每个小时，我们都会构建一个特征向量并预测此时的负荷”。 让我们收集训练样本。 样本中的行将为日历小时。 每小时对应一个目标-该小时的点击次数。
现在，让我们考虑一下可以使用的标志。
- 首先，让我们利用数据的日历性质。 添加星期几，小时，每月的符号。 他们可以锁在戒指里 。
- 在这样的日子和这样的时间加上每小时的呼叫数量。 您可以获取上周的点击次数，以及月份和年份的平均值。
- 我们以类似的方式添加一周中同一小时和同一天的点击数。
- 扩大汇总窗口-在一周的这一天和一天中的这个时间添加平均点击数。
- 让我们尝试立即标准化对负载趋势的调用次数。 我们将同时测试标准化值和原始值。
- 添加季节性-去年每月的点击次数，已根据负载趋势标准化。
- 以防万一，我们还添加了有关负载趋势的原始数据。 我们将同时获取当前时间的值和一周前，一个月前的“转移”值。
我们将不仅尝试“常规” RMSE错误功能，而且还将尝试WAPE-它更适合解决问题的目的。 为了进行验证，我们将无法使用常规的K折交叉验证-有机会展望未来。 因此，我们将使用嵌套折页分区，并将测试折页的大小固定为恰好等于4周。 折痕的边界将精确设置在星期一的午夜。
对于PoC，我们将尝试两种模型-具有L1正则化的线性模型和最受欢迎的木料。 对于线性模型，不要忘了对符号进行标准化（必要时加上对数），对于一块木头，更积极地松开正则化参数。
步骤5和6。我们将评估模型的质量和经济效果。
至此，所有准备工作已经完成，我们终于可以继续进行PoC最有趣的部分-分析结果并制定决策。
不幸的是，整个示例都是投机性的，没有真实的数据，因此结果将被淘汰。 为了避免感到羞耻，我从Ger Koole的《呼叫中心优化》一书中按顺序取了一些数字（我在写这篇文章¯\_(ツ)_/¯偶然发现了它）。 此处的图片是负载预测的示例。
首先，我们能够预测WAPE = 14％的小时负载。 在43％的小时数下可以实现小于10％的误差，在70％的小时数下可以实现小于20％的误差。
总的来说，这非常好-我们可以准确地捕捉到每天的波动，每周的周期以及中期趋势。 我们仅在随机波动时燃烧，最有可能的是，我们将无法避免它们。
根据负载，我们可以轻松地计算出在给定时间应该轮班的操作员数量。 我们编写了一个贪婪的非最佳班次调度算法，并计算出能够节省10％的班次负担。 事实证明，如果除了12个小时的班次外，我们还引入8个小时的班次并每天进行巧妙地安排，我们可以再节省5％。
我们将指标转化为金钱。 呼叫中心每年的维护费用为每年5000万卢布。 我们的实验表明，我们可以减少15％的费用，这每年可节省750万卢布，在整个生命周期中最多可节省2250万卢布。
这是非常好的效果，我只想承认PoC是成功的。 但是，让我们徘徊并分析可能出问题的地方。
影响经济效益的风险
由于员工人数的减少，我们取得了积极的效果。 我们能够通过减少轮班数量来减少员工数量。 由于能够根据预测的负荷重新分配班次，因此我们能够减少班次的数量。 我们能够使用基于历史数据的模拟来预测负载。
首先，如果我们的呼叫中心使用产品的使用方式发生变化，则历史数据将失去相关性。 模式在未来三年内不会改变的机会非常小。 有必要在模型的整个生命周期中承担进一步培训和校正模型的费用。
其次，我们非常准确地预测了负载，但是，在30％的情况下，我们犯了超过20％的错误。 , . .
-, 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 | 开发人员 | Support | ROI 1 | ROI 3 |
|---|
| 最佳 | 最佳 | 7,5 | 1,3 | 0,5 | +4x | +11x |
| 最佳 | Real | 7,5 | 2,2 | 1,0 | +2x | +6x |
| 最佳 | Pessim | 7,5 | 3,4 | 1,9 | +85% | +3x |
| Real | 最佳 | 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 | 最佳 | 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 .
.
-, . - - . .
-, . , . .
— .
结论
- WFM -. , - . WFM — .
- — .
- , ,
? , PoC'. - PoC' , ?
- — - .