Когда требуется найти нестандартное решение, важно иметь средства для оперативной проверки гипотез. Использование концепции MVP в сочетании с low-code инструментами значительно упрощает и ускоряет процесс прототипирования.
Анализ данных бывает разным. Может быть тривиальным, когда понятна задача, подходы к еe решению, предсказуемы сложности. Это удобная ситуация: можно использовать известный алгоритм, решать типичные проблемы, получить хороший, предсказуемый результат. Но зачастую задачи анализа данных нетривиальны. Есть множество вариантов, несколько подходов, комплекс противоречивых мнений. Хотелось бы, чтобы решения опирались на данные, но не всегда есть достаточный объем информации для принятия решений.
Допустим, есть крупная страховая компания. Внутри нее — некая система сбора информации и расчета конверсии по страховому продукту. Принцип и скорость обработки данных не устраивают руководство компании и аналитиков. Существует несколько проектов с решениями, которые потенциально могут сработать. Нужно сделать так, чтобы реальные данные собирались из разных источников и корректно обрабатывались. Огромное количество процессов — множество задействованных людей. В таких условиях цена эксперимента и, особенно, цена неудачи очень высока.
Весьма распространeнная ситуация — отсутствие данных по какому-то вопросу. И связанное с этим препятствие для бизнес-процесса. Есть проблема — нет решения, никто этого никогда не делал. Рассмотрим пример из истории проектирования станции и корабля для нее в советской лунной программе. Была сложность в определении свойств грунта Луны (твeрдый\рыхлый) и связанных с ними характеристик аппаратов. Можно решать такие задачи интуитивно, бросать монетку, принимать волевые решения.
Сергей Павлович Королeв как раз принял волевое решение. В справке от 28 октября 1964 года сказано: «Посадку Лунного корабля следует рассчитывать на достаточно твeрдый грунт типа пемзы». Он сделал предположение на основе противоречивых научных источников, которое оказалось жизнеспособным. Не всегда такие предположения оказываются верными. Хорошо иметь возможность проведения серии экспериментов.
Справка С.П. Королева от 28.10.1964
И здесь мы подходим к принципам минимально жизнеспособного продукта(MVP, Minimal Viable Product). Коротко концепцию MVP можно описать следующим образом: продукт должен обладать минимальными, но достаточными для первых потребителей, функциями. Главные задачи минимально жизнеспособного продукта — тестирование гипотезы в реальных условиях, получение обратной связи и оценка перспектив продукта.
Возвращаемся к задаче нетривиального анализа. Что для неe MVP? Это возможность своего рода быстрого прототипирования. Допустим, есть 50 решений. Какие-то из них, очевидно ложные, другие — слишком дорогие. Есть 3-5 решений, из которых нужно выбрать. Можно запустить несколько небольших пилотных проектов, на которых эти решения будут быстро протестированы. Практическим путeм можно выявить неочевидные недостатки и преимущества конкретных решений, отработать их исполнение в реальных условиях.
Есть несколько принципов минимально жизнеспособного продукта для улучшения процессов работы с данными:
Есть ли возможность совершить ошибку в таких условиях? Да, она всегда есть. Но при подходе с минимально жизнеспособным продуктом цена этой ошибки значительно меньше. Кроме того, эксперименты в принципе очень часто заканчиваются неудачей. Можно сказать, что аномалия — это скорее удачный эксперимент. Возникает вопрос: почему столько неудач? Потому что нет готовых, отработанных решений, действовать приходится почти вслепую.
При использовании MVP проводят несколько экспериментов. Смотрят, что работает, что — нет. Более-менее работает, есть какие-то недостатки? Небольшие корректировки, продолжение работы. Видно, что не работает, есть принципиальные проблемы — можно спокойно оставить эту версию развития проекта, пока затраты на еe реализацию не стали слишком большими.
В чем основная проблема полноценных вложений в тестовый продукт? В случае, если модель нежизнеспособна, но в неe вложены значительные ресурсы, от идеи сложно отказаться. Отказаться чисто психологически. Потрачены деньги, время, усилия — возникает эффект невозвратных потерь (sunk cost fallacy). Самый известный случай влияния этого эффекта на проект — длительная эксплуатация сверхзвукового пассажирского самолета Конкорд, которая была экономически неэффективной. Тем не менее, в нее долгое время вкладывали огромные ресурсы.
То есть, в восприятии людей потеря некоторой суммы значительно дороже, чем приобретение на эту же сумму. И этот эффект может становиться причиной сохранения нежизнеспособных решений.
Малокодовые (low-code) решения отлично встраиваются в концепцию минимально жизнеспособного продукта. Они позволяют быстро и относительно дешево получать результат. Важно, что малокодовые решения — это не «черный ящик». Понятно, как работает система, ее можно быстро переключать на решение других задач.
Важнейшее преимущество low-code решений — возможность непосредственного привлечения специалистов к решению конкретных задач. Допустим есть некоторая бизнес-задача, есть возможность решить ее с привлечением технических специалистов и экспертов или с привлечением экспертов и использованием low-code. Инженер, программист — это высокооплачиваемый, высококлассный специалист, который зачастую не ориентируется в предметной области. И при активном участии таких специалистов в тестовых вариантах продукта есть риск пустой траты их усилий.
С другой стороны, предметные эксперты хорошо ориентируются в своих областях, часто могут полагаться на интуицию. Использование малокодовых решений дает им возможность быстро проверять свои предположения, быстро внедрять новые решения. Проще говоря, low-code позволяет привлекать больше предметных экспертов, а не технических специалистов, которые обычно не разбираются в управлении.
Рассмотрим кейсСтрахового Дома ВСК с использованием принципов MVP. В данном примере обозначение изолированной среды «песочница» фактически является синонимом MVP. Перед компанией стояла задача введения в эксплуатацию системы консолидации больших объемов данных. Множество сотрудников собирали данные в таблицы excel, обменивались ими. Сроки расчета некоторых показателей были неприемлемо большими.
Для решения поставленной задачи был организован MVP («песочница»). На локальном сервере была развернута платформа Loginom. Важно, что срок развертывания и отладки не превысил 1 рабочего дня. В такой же срок была согласована с руководством организационная структура нового процесса. Было необходимо обеспечить безопасность данных. Использование платформы на локальном сервере позволило защитить данные, а понятная схема обработки — быстро согласовать доступ сотрудников.
Благодаря использованию малокодового продукта была возможность задействовать сотрудников, не имеющих инженерной квалификации. Среди тех, кто работает с таблицами стандартными средствами, всегда находятся сотрудники, готовые разбираться в логике обработки, автоматизировать этот процесс, отмечает руководитель центра развития аналитических систем ВСК. Система Loginom Skills позволила оперативно обучить сотрудников (они самостоятельно изучают процесс работы в low-code) и выявить тех, кто наиболее заинтересован и подготовлен. В целом, использование малокодового решения позволило уменьшить сроки формирования рабочих групп.
Возможности параллельных расчетов Loginom позволили увеличить скорость обработки данных. Время выполнения расчета конверсии по страховому продукту за один день продаж (на основании примерно 20 ГБ данных) составило 5-8 минут, что удовлетворяет требования аналитиков компании. Сотрудники ВСК отмечают быстроту визуализации в Loginom. В то время как OLAP-куб от Microsoft требует предварительной постройки, OLAP-визуализатор Loginom позволяет оперативно вносить изменения в структуру куба.
За три месяца, кроме расчета конверсии было решено более 20 бизнес-задач. В ВСК использование Loginom в условиях MVP стало основным инструментом для 3-х технических и 4-х бизнес-команд.
Обобщая вышесказанное, когда нужно найти некое нетривиальное решение, необходим инструментарий для быстрого тестирования идей. Если задача тривиальная — обычно есть целый набор готовых решений. Если же задача необычная — нужно исследовать множество вариантов. Значительное число подходов может оказаться нерабочим, не подходящим по самым разным, иногда неожиданным, причинам. Нежизнеспособная идея, недостаток данных, невозможность их получить (в разумное время, за адекватные деньги), и т.д.
И, понимая, как много возможных причин неудач, хочется иметь возможность быстрого создания минимально жизнеспособных продуктов (MVP). Сначала можно создать серию MVP, которые опираются на наиболее привлекательные концепции продуктов. Один MVP даст хороший результат, другие — нет, третьи покажут свою нежизнеспособность. На пути от первых прототипов до готового продукта будет несколько рабочих промежуточных минимальных продуктов и множество отброшенных версий. Но траты на разработку этих версий будут относительно небольшими.
В подход MVP в организации работы с данными отлично вписываются малокодовые системы. Они позволяют быстро готовить и проводить эксперименты с максимальным привлечением предметных экспертов. Т.е., low-code не только облегчает вход специалиста в техническую область, но и уменьшает стоимость эксперимента (речь не только про деньги, но про время и усилия). Это прекрасная возможность делать несколько промежуточных продуктов с максимальным привлечением экспертов. И уже когда в море песка обнаружится продукт-самородок, переходить к его масштабированию на весь бизнес.
Другие материалы по теме:
Использование low-code системы как полноценного бэка. Кейс Кубань Кредит
