proof of concept что это

Proof of Concept: Как проверить, что внедрение ML стоит свеч

Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно «продавать» внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!

Наш вымышленный проект

В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.

Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в 100 х 2.000 х 250 = 50 млн руб в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет. Давайте подумаем, как вообще принимать такие решения.

Как считают ROI

Прежде, чем начинать большой проект, неплохо бы оценить его экономическую целесообразность. Хрестоматийный способ сделать это — посчитать возврат на инвестиции, ROI.

ROI (Return on Investment) — это показатель доходности проекта, равный отношению доходов к затраченным инвестициям. ROI ¯\_(ツ)_/¯ ). Картинка оттуда же — на ней пример прогноза нагрузки.

Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.

По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.

Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.

Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.

Риски, влияющие на экономический эффект

Мы получили положительный эффект за счет сокращения числа сотрудников. Число сотрудников мы смогли сократить за счет сокращения числа смен. Число смен мы смогли сократить за счет перераспределения их по предсказанной нагрузке. Нагрузку мы смогли предсказывать с помощью моделирования на основе исторических данных.

Во-первых, если паттерны пользования продуктами, которые обслуживает наш колл-центр, изменятся, исторические данные потеряют актуальность. Шанс того, что паттерны не изменятся в течение ближайших трех лет, достаточно мал. Нужно заложить расходы на дообучение и коррекцию модели по ходу ее жизни.

Во-вторых, мы предсказали нагрузку достаточно точно, но, тем не менее, в 30% случаев ошибаемся больше, чем на 20%. Может оказаться, что такая ошибка в час пик приводит к недопустимому росту длительности ожидания. Супервайзеры примут решение закладывать резервные смены для покрытия рисков.

В-третьих, при проведении PoC’а мы оперировали только сменами, а в реальности окажется, что на сменах работают вполне конкретные люди. Почему-то людей нельзя просто так увольнять и моментально набирать, а смены для сотрудника нужно ставить с учетом рабочего графика, Трудового Кодекса и личных пожеланий сотрудника. Из-за этих факторов придется держать штат чуть больше, чем того хочет машина.

Итого, нам нужно заложить резервные смены в часы пик и поддерживать немного «балласта» в тихие недели. А кроме того, нам нужно будет заложить расходы на поддержание модели.
Настало время поговорить о расходах и рисках, с ними связанных.

Разработка и сопровождение, их стоимость и риски

По ходу проведения PoC нам стало понятно, что нужно делать для промышленной реализации решения.

Во-первых, нужно выстроить стабильно работающий процесс сбора данных. Оказалось, что мы достаточно легко можем получать данные из CRM. Однако, данные о расписании операторов мы были вынуждены собирать по крупицам. Значит, нам придется сначала сделать автоматизированную систему контроля расписаний операторов. Удачное совпадение, что результаты планирования мы тоже будем выгружать в эту систему. Мы оценили, что на разработку выгрузки из CRM у нас уйдет неделя-две. Разработка системы для управления расписанием потребует месяца два, и есть риск, что мы ошиблись в оценке в разы.

Во-вторых, нам нужно закодить сервис, применяющий модель для прогноза нагрузки, а потом закодить алгоритм, составляющий расписание под эту нагрузку. Саму модель мы уже обучили, как ее применять, примерно понятно — мы сможем упаковать ее в сервис примерно за неделю, максимум две. С алгоритмом составления расписаний сложнее, к тому же, мы можем погрязнуть в реализации ограничений или не смочь обойти комбинаторную сложность. Разработка алгоритма займет у нас от пары недель до двух-трех месяцев — неопределенность высока.

В-третьих, для работы всего этого потребуется инфраструктура — сервера приложений, базы, балансировщики и мониторинг. Как хорошо, что мы делаем это не в первый раз и знаем, что это займет где-то неделю. Если накосячим с оборудованием, то две. Сопровождение инфраструктуры будет занимать у нас от силы один-два человеко-дня в месяц, пфффф. Но за три года набежит до пары полных месяцев, ой. Кроме того, надо заложить дообучение и перевыкладку модели раз в полгода — итого 2-5 раз, каждый раз по 3-5 дней.

Просуммируем расходы в оптимистичном, реалистичном и пессимистичном вариантах.

Пусть средний разработчик обходится компании в 20 тыс. руб. в день.

Оптимистичный — 5 дней на CRM, 40 дней на систему управления расписанием, 5 дней на прогнозирование, 10 дней на составление расписаний, 5 дней на инфраструктуру, 3х12х0,5 дней на ее поддержку, и 2х3 дней на редкие дообучения модели. Итого 65 рабочих дня на разработку, 24 дня на поддержку. Итоговая стоимость решения — 1,3 млн руб на разработку + 0,48 млн руб на поддержку за 3 года.

Реалистичный — 10 + 60 + 10 + 20 + 10 + 3х12х1 + 5х3 = 110 разработки и 51 поддержки, 2,2 + 1,02 млн руб.

Пессимистичный — это когда все пошло не так. 20 + 80 + 20 + 40 + 10 + 3х12х2 + 5х5 = 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% за все время жизни, однако, мы будем вынуждены сильно ограничивать себя в резервах. И если мы не уверены в компетенциях собственной разработки, то проект лучше вообще не начинать.

P.S. Делать свое или купить готовое

Живой менеджер изучил бы альтернативные решения еще до внедрения PoC, но у нас же умозрительный проект, да? К тому же, про сторонние закрытые решения статью не напишешь.

Для начала, есть очень важный стоп фактор — каким будет исход разработки, сильно зависит от компетенций компании. Если компания не уверена в своих разработчиках и DS’ах, вероятность пессимистичного исхода слишком велика. В этом случае нужно однозначно использовать решение от вендора. Просто исходя из этого соображения, просто по этому пути идут все нетехнологические компании. Технологические компании отличаются тем, что сила их команды даёт шансы на оптимистичный исход. Вот тут начинается математика.

Решения от вендоров биллятся, исходя из стоимости аренды рабочего места. По нашей «реалистичной» оценке дохода в 7,5%, мы экономим на одном рабочем месте 37,5 тыс. руб в год. Это и есть максимальная стоимость решения. Если решение стоит дешевле — оно принесет положительный ROI. С собственной разработкой все сложнее — окупаемость зависит от числа операторов. За первый год положительный ROI возможен при расходах на операторов в 26,66 млн в год, что достигается при 53 операторах. За три года положительный ROI начинается от 27 операторов.

При выборе стороннего решения кроме простой математики стоит учесть еще два фактора.
Во-первых, это риски. При покупке решения вы получите что-то более-менее работающее. При реализации решения своими силами у вас остается существенный шанс провала.
Во-вторых, это активы. По окончании разработки вы получаете актив, который можете развивать и дорабатывать. При аренде или покупке лицензии собственного актива вы не получаете.

Источник

Proof of concept что это

Перед началом реализации идеи, многие люди по-разному называют предполагаемый результат. Наиболее часто встречающиеся термины в этом случае: MVP ( minimum viable product ), POC ( proof-of-concept ), Prototype.

Давайте попробуем разобраться, в каких случаях наиболее уместно использовать каждое из вышеперечисленных определений, чтобы избежать недопонимания

MVP

Minimum viable product — версия продукта, которая имеет минимальный набор функций исключительно для реализации бизнес-цели, сохраняя при этом жизнеспособность. Другими словами, она не содержит кучи интересных “фич” и красивого интерфейса. Такое решение имеет смысл использовать при работе со стартапами для того, чтобы вывести продукт на рынок и выяснить, будет ли он вообще пользоваться спросом. Таким образом, если спрос появился, то смысл дальнейшей работы есть и можно пробовать получить деньги с первых инвесторов на развитие продукта в будущем. Естественно, в свете того, что MVP отправляется прямиком на рынок, это должна быть стабильно работающая без ошибок версия ПО.

POC

Так называемое подтверждение концепта ( proof of concept ). В отличие от MVP, это маленький проект, созданный для проверки критически важных гипотез перед началом полноценной разработки. Например, POC создается для того, чтобы проверить, можно ли вообще реализовать какую-либо функцию или, если нет уверенности, что идея сработает. Подтверждение концепции охватывает не всю систему, а лишь небольшую её часть, которую пользователи могут и вообще не увидеть, потому что чаще всего POC используются внутри компании для уточнения пути развития продукта. Грубо говоря, POC — это небольшое исследование, которое дает зеленый (или красный) свет для дальнейшей работы, будь то начало нового проекта или развитие существующего. Бывают и случаи, когда POC используется вместо MVP для получения финансирования.

Prototype

И последнее, но не менее важное определение в нашем обзоре — прототип (Prototype). Основная цель создания прототипа — помочь принять решение о разработке продукта и уменьшить количество ошибок в нем. Прототип — это рабочая модель нескольких аспектов продукта (в отличие от POC, где чаще реализовывается одна функция). Чаще всего прототипирование используется для демонстрации какой-либо части системы, обнаружения ошибок в ней, опроса пользователей. С помощью прототипа, команда проверяет дизайн продукта, удобство использования, а зачастую и функциональность, чего никак не сделаешь, используя POC. Если говорить проще, прототип больше похож на драфт — т.е. своего рода черновой набросок, который еще требует много доработок, но при этом показывается конечным пользователям для того, чтобы услышать их мнение в целом о полученном результате. Важно отметить, что прототипы часто используются для реализации каких-то свежих идей и впоследствии вполне могут перерасти в MVP.

Подводя итоги к вышесказанному, предлагаю для наглядности сравнить описанные термины в небольшой таблице:

В итоге хочется отметить, что хотя MVP, POC и Prototype имеют много общего, но все же у них разные цели. А также то, что в ходе работы POC может перерасти в прототип или MVP или наоборот. В итоге только вам решать, каким именно путем идти.

В своей работе со стартапами мы чаще всего имели дело с MVP, которому могли предшествовать POC и/или Prototype.

Источник

Как бизнесу проверять новую идею при помощи Proof of Concept

Инновационному проекту на старте сопутствует неопределенность. Прежде чем как вкладываться в новую технологию, идею или метод, хочется получить доказательство, что они действительно будут работать – и при этом не потратить все имеющиеся ресурсы. Это справедливо для любой сферы. Например, дорогостоящие клинические исследования лекарственных препаратов стартуют не раньше, чем будут получены результаты ранних, менее строгих проверок, когда лекарство принимается однократно или в течение короткого срока. Хотя полученные результаты не заменяют масштабного исследования, принимать решение на их основе надежнее, чем руководствуясь только предположениями.

IT-проекты – не исключение. Любая новаторская идея сопряжена с рисками, и потому требует проверки не в процессе разработки, а еще на этапе предевелопмента и привлечения инвестиций.

В предыдущих статьях мы уже рассказывали, как Discovery-фаза помогает подсветить “узкие места” будущего продукта, которые нуждаются в проверке. Таким местом может стать самая сложная или инновационная функция IT-продукта. Если на этапе планирования возникают такие вопросы: реализуемо ли решение, которое мы предлагаем? каких затрат потребует разработка? какие есть ограничения и можно ли их обойти? – то худшее, что можно сделать, это положиться на интуицию и отложить проверку на потом. Ведь когда в проект уже вложено много усилий, времени и денег, внести изменения в концепцию гораздо сложнее, чем на этапе предевелопмента.

Разбираемся, как снизить риски на старте инновационного IT-проекта при помощи Proof of Concept.

1. Что такое Proof of concept?

Проверка концепции (англ. Proof of concept, PoC) – это демонстрация практической осуществимости какого-либо метода, идеи, технологии, с целью доказательства факта, что метод, идея или технология работает.

Существуют разные подходы к определению Proof of Concept. Часто в него включают и разработку прототипов, и создание MVP – работающего продукта с минимальной функциональностью. Однако мы в Umbrella IT разграничиваем эти методы проверки идеи, так как они преследуют разные цели и на выходе дают разный результат. Также ошибочно принимать PoC за некий “черновик” проекта, который в дальнейшем необходимо лишь немного доработать. Сам формат Proof of Concept гораздо ближе к исследованию, чем к разработке работающего продукта. Тестируется лишь небольшая часть системы – критически важные функции, а полученный результат может не использоваться в дальнейшей разработке. Так как цель PoC – в сжатые сроки убедиться в том, что концепция работает, могут быть опущены второстепенные аспекты, важные для продакшн версии продукта. В таких случаях, получив зеленый свет на этапе PoC, команда может начать писать проект с нуля.

2. PoC vs MVP vs прототип

Чтобы наглядно продемонстрировать, для каких целей подходит тот или иной метод проверки новых идей, мы составили сравнительную таблицу:

Proof of ConceptMVPЧто проверяем?Техническая возможность реализации функцииВостребованность продукта у пользователейКакую часть функциональности охватываем?Одна ключевая функция будущего продукта/один из сценариев использования
Ключевые функции продукта, достаточные для решения главной проблемы пользователя
Для кого предназначается?Стейкхолдеры, инвесторыСтейкхолдеры, пользователи, инвесторыКакой результат?Наработки с заключением экспертовРаботающий продукт

Подробнее о бизнес-задачах, которые решаются при помощи MVP, читайте в статье “4 причины, почему вашему проекту нужен MVP”.

Proof of Concept подразумевает под собой одну ключевую функцию, которая не обязательно будет доведена до совершенства. В отличие от PoC, прототип лишь визуально воспроизводит будущее приложение, которое содержит в себе вышеуказанную функцию. Например, если на этапе PoC нам нужно проверить техническую возможность вычисления производных первого порядка, то при создании прототипа мы продемонстрируем, где будут располагаться поле ввода, куда пользователь может ввести функцию, а также кнопка “Вычислить“.

3. Когда проекту нужен Proof of Concept?

Из-за разнообразия опций проверки идей бывает сложно понять, на какой из них стоит выделить ресурсы сейчас, чтобы сэкономить месяцы разработки в перспективе. Предлагаем разобраться, когда проект по разработке ПО нуждается в Proof of Concept.

Проверка концепции – необязательный этап проекта, и в большинстве случаев он не требуется. Если вы хотите создать приложение с механикой Uber – неопределенность на проекте будет минимальна: идея проверена, каждый этап разработки детально описан, доступно много готовых решений. А, например, использование VR/AR-технологий, алгоритмов машинного обучения (ML-алгоритмов) или анализа больших данных кратно увеличивает неопределенность на проекте. Так, по данным Microsoft около трети проектов IoT не проходят этап Proof of Concept.

Новые возможности сопряжены с определенными рисками, среди которых угроза безопасности, высокая сложность проектов, дефицит квалифицированных кадров. Значит перед запуском проекта необходимо убедиться не только в работоспособности решения, но и в соразмерности затрат и рисков бизнес-результату.

Даже когда технологический стек привычен, Proof of Concept помогает сравнить результативность нескольких решений и выбрать оптимальное.

Наша команда разработала тестовый стенд для проверки нескольких картографических сервисов. Это позволило наглядно сравнить маршруты, которые построили Google Maps, HERE.maps и Яндекс.Карт с учетом соответствующих ограничений для грузового транспорта. Результаты ранжировали по количеству нарушений ПДД в построенном маршруте. Подготовив заключение о стоимости каждого решения, мы рекомендовали сервис, который лучше всего решает поставленную задачу.

PoC помогает проверить идею на наличие “узких мест”. К примеру, в последние годы маркетологи возлагали большие надежды на технологии персонализации рекламы. Однако ажиотаж и поспешное внедрение инноваций привели к сложностям со сбором, интеграцией и защитой данных. В конце 2019 года Gartner заключил: потребительское доверие снизилось, персонализированные предложения стали менее эффективными, что привело к снижению ROI. Кроме того, неаккуратное обращение с персональными данными привлекло внимание регулирующих органов. Всего этого можно было бы избежать, если бы проблемы были выявлены на этапе проверки гипотезы. На данный момент прогнозы неутешительны: к 2025 году 80% маркетологов откажутся от персонализации. Тем, кто все еще планирует инвестировать в эти технологии, аналитики Gartner рекомендуют принимать решение только после демонстрации Proof of Concept.

Опыт Umbrella IT показывает, что использование подхода Proof of Concept дает бизнесу ряд преимуществ. Нежизнеспособные и нецелесообразные идеи отсеиваются на раннем этапе, а сэкономленные время и ресурсы задействуются для реализации проверенных идей. Процент успешных и эффективных проектов увеличивается, появляются прорывные продукты, позволяющие обогнать конкурентов.

Когда проверка концепции инновационных идей становится обычной практикой в компании, скорость развития бизнеса возрастает в 2-3 раза.

Хотите запустить новый продукт и снизить риски? Напишите нам, и мы подберем решение, которое подойдет именно вам

Источник