Математикам тоже не чужды плюсы agile-разработки и создания MVP. О разумном пилотировании проектов по математической оптимизации рассказывает руководитель направления систем бизнес-аналитики BIA Technologies Станислав Воронин.
На волне Четвертой промышленной революции практически на всех крупных предприятиях страны созданы центры по цифровизации производства, а в компаниях появилась должность директора по цифровой трансформации бизнеса. Такого рода «цифровизаторы» ходят по заводу, анализируют бизнес-процессы на тех или иных участках, общаются с сотрудниками и генерируют идеи по повышению производственной эффективности, оптимизации, увеличению прибыли и сокращению издержек.
С такими идеями предприятия обращаются в компании по разработке и внедрению математических оптимизационных моделей. Поскольку все предприятия так или иначе отличаются друг от друга, решение «под ключ» здесь заведомо не сработает. Разработчики не приносят заказчику готовую математическую модель, под которую затем пытаются «причесать» его бизнес, а подходят к задаче с определенным багажом наработок, алгоритмов и пониманием, как решать ту или иную проблему, и реализуют модель с учетом специфики бизнес-процессов заказчика.
При этом, на стадии идеи ни у заказчика, ни у подрядчика нет четкого понимания, что нужно для реализации проекта, как будет выглядеть финальный продукт и выполнима ли задача в принципе. Что может пойти не так? Примерно всё. Вот три ключевых риска:
1. Нехватка данных
Прежде чем создавать оптимизационную модель, необходимо убедиться, что у нас есть для нее исходные данные, что эти данные приемлемого качества, и что их можно получать автоматизированным путем. Приведу пример с программой производственного планирования: одним из существенных параметров для оперативного перепланирования является информация о том, как была отработана предыдущая смена (какие заказы выполнены, какое сырье осталось на складе, какие станки доступны, а какие сломались и т. д.). Чтобы APS-система жила и функционировала, фактическая информация должна поступать в нее из учетных систем автоматически. Если для сбора актуальных данных придется ежедневно обзванивать всех менеджеров завода и вбивать полученную информацию вручную — времени на оперативное перепланирование рабочей смены уже не останется, да и возможные ошибки ручного ввода только добавят проблем с формированием выполнимого плана.
2. Неясность метрик
Не менее важно заранее определить, как мы будем оценивать результат внедрения системы. Сказать «процесс будет оптимизирован» недостаточно — нам нужно понимать, какие именно показатели улучшатся и на сколько. Все участники улучшаемого бизнес-процесса от исполнителей до руководителей должны четко себе представлять, какие новые показатели необходимо будет контролировать в работе. Если первый критерий по наличию данных говорит об осуществимости проекта, метрики качества улучшаемого бизнес-процесса связаны с оценкой окупаемости инвестиций. Предприятию важно знать, сколько денег стоит выделить на проект по оптимизации, а также на какую отдачу и когда можно будет рассчитывать. Нужно понимать, что пока одни математические модели окупаются уже через 3–6 месяцев, другим на это требуется — сюрприз! — не менее 2–3 лет.
3. Незаинтересованность персонала
Идеи по цифровизации и внедрению передовых IT-систем рождаются в головах топ-менеджеров, но пользоваться этими системами в конечном итоге будут сотрудники того функционального подразделения, на улучшение деятельности которого они были направлены. Пользователи должны доверять команде внедрения и понимать, как модель будет работать, зачем она им нужна и почему ее рекомендациям можно и нужно верить. Если же сотрудникам просто молча «спустят» готовую систему сверху, велик риск, что они останутся верны старой-доброй табличке Excel. Как я уже писал, люди в принципе не любят изменения и сопротивляются любым, даже положительным нововведениям. В связи с этим очень важно обеспечить вовлеченность сотрудников на всех этапах проекта, а также правильно установить KPI, поддерживающие процесс внедрения новой системы в деятельность предприятия.
Чтобы снизить упомянутые зоны риска, мы в своей компании выработали практику проведения предпроектных консалтинговых работ, целью которых является помочь заказчику более четко сформулировать требования к системе, оценить наличие и состояние данных для решения задачи, зафиксировать ожидаемые метрики, рассчитать фактическое и прогнозное значение, сформировать первый прототип будущей оптимизационной модели, а также обозначить возможные условия для улучшения качества оптимизации.
Этап предпроектной аналитики занимает порядка 1–1,5 месяцев, а инвестиции в него не превышают 5–10% от стоимости основного проекта. Результаты прототипирования — в случае получения положительного заключения о дальнейшем тиражировании — могут быть использованы при дальнейшей реализации проекта. Таким образом, заказчик может проверить десяток гипотез, выбрать 2–3 лучшие из них и соглашаться на разработку и внедрение, будучи уверенным в успехе проекта на 100%.
Состав работ:
1. Вместе с заказчиком формулируем текущее описание данных, которые потребуются для модели, процессов, которые задействованы и которые мы хотим оптимизировать, и метрик качества, которые характеризуют оптимизируемые процессы.
2. Используя алгоритмы анализа данных, мы определяем достоверность данных, их объем и гетерогенность (если данные поступают из разных учетных систем) и проверяем наличие автоматизированных процессов по их сбору.
3. Создаем прототип модели на основании описаний «как есть» и «как хотелось бы» и анализируем вместе с заказчиком, что получилось на выходе. Как правило, на этом этапе становятся заметны неучтенные ранее критичные ограничения в системе, проявляются огрехи в описаниях бизнес-процессов, а также дополнительные проблемы в качестве исходных данных. Например, при прототипировании программы-планировщика поставок нефтепродуктов на АЗС, заказчик сказал, что на некоторых заправках существует жесткое ограничение по величине бензовоза. Практика же показала, что бензовозы большой емкости всё равно иногда заезжают на малые АЗС, поэтому данное ограничение было сделано в итоговой модели мягким.
4. На основе прототипа можно пересчитать фактические метрики качества и те, что мы можем уверенно ожидать на выходе. Бывает, на этом этапе приходит понимание, что ключевой фактор оптимизации должен быть другим, и нужно переориентировать модель и считать экономический эффект от улучшения другого фактора.
5. Дорабатываем прототип модели и получаем «проект в миниатюре». Заказчик получает на руки подробное описание математической задачи, которую нужно будет решить в будущем проекте. В отчете по задаче сформулированы основные направления для улучшения и критерии целевой функции, указано, какие данные необходимы, как их собирать, как обеспечить более точный сбор данных и без решения каких стоп-факторов лучше даже не браться за проект.
6. В завершение мы описываем, каким образом использование будущей системы ляжет в организацию процесса: какие роли пользователя предусмотрены в системе, кто будет запускать расчет, а кто — проводить анализ. Это поможет заказчику бесшовно встроить модель в свою организационную структуру и принять решения по найму новых сотрудников или перераспределении рабочих задач.
Строго говоря, все эти шаги будут так или иначе сделаны и при работе над «большим» проектом. Но если не выделить их в этап предварительного доказательного консалтинга, основанного на математической модели, велика опасность потерпеть неудачу или не достичь заявленных на берегу целевых показателей эффективности. Когда основной проект запущен, параллельно с оценкой данных и процессов прорабатываются нефункциональные требования, требования к интерфейсам программы и т. п. Это значит, что понимание того, что каких-то условий и данных не хватает, может прийти слишком поздно, когда на проект затрачено уже немало денег и сил. Прерывать основной проект будет дорого и нецелесообразно.
Таким образом, для повышения вероятности успешности проекта, этап предварительной проработки гипотезы и проектирования основной функциональности необходим. Звучит знакомо? Неудивительно. Внедрение оптимизационной модели в производственную деятельность того или иного предприятия — это IT-проект, и к нему применимы все риски, подходы и специфика IT-индустрии. По сути, мы говорим о гибкой (agile) методологии разработки и создании MVP будущей математической системы — пока без красивого интерфейса, но с математическим ядром — который позволяет оценить результат и качество расчетов и проверить жизнеспособность бизнес-идеи при минимальных вложениях.