Как выглядит стандартный подход в выборе инструмента цифровизации бизнес-процесса? Бизнес-заказчик в лице руководителя направления (директор департамента, начальник отдела, руководитель "по ...") формирует требования об идеальном, с его точки зрения программном продукте. Который идеально подойдет именно ему, его отделу, еще и "внедрит сам себя". Далее эти требования подхватывает блок ИТ или цифрово трансформации и начинает "шерстить" рынок на предмет наличия такого идеального продукта. Конечно, предварительно утверждаются критерии оценки, значимость каждого критерия и т.д. Одним из главных критериев, разумеется, становится степень соответствия коробочного программного продукта тем требованиям, который сформировал бизнес-заказчик. И, конечно же, все понимают, что 100% недостижимы, а недостающие 20-30% можно и "подточить под себя", то есть привлечь вендора к доработке своего продукта под наши функционально-технические требования.
На первый взгляд все выглядит очень стройно, системно и профессионально. По результатам анализа получаются красивые отчеты, таблички, графики и заключения. На деле же данный подход несёт в себе крайне опасный риск, а именно риск 100% провала данного проекта по цифровой трансформации. Ведь наличие коробочного продукта, даже на 70% соответствующего вашим требованиям, никак не гарантирует то, что, во-первых, вендор разработает решение нужное вам и удовлетворяющее на 100% вашим требованиям, во-вторых, данная разработка будет быстрее и дешевле, чем разработка "с нуля". Для меня здесь налицо ментальная ловушка, в которую попадают как очень крупные игроки, так и средние компании, не имеющие достаточного опыта цифровизации. Ловушка заключается в том, что нужно различать два подхода к цифровой трансформации: 1) лицензирование "коробочных" программных продуктов, 2) разработка программного продукта "под себя"
Лицензирование коробочных программных продуктов
Коробочный программный продукт ("коробка") - программа для ЭВМ, созданная с целью коммерческого распространения за счет продажи лицензий. Главная особенностью является то, что данная программа создана под конкретный сегмент компаний, в которых автоматизируемый бизнес-процесс протекает примерно одинаково. За счет этого разработчикам удается создать и поддерживать востребованный программный продукт, а компаниям из выбранного сегмента получать коммерческую выгоду и не тратиться на разработку "с нуля".
Исходя из определения, коробочный программный продукт изначально создается с серьезными ограничениями, которые делают его неприменимым или неэффективным в компаниях, для которых он не создавался. А, если даже ваша компания попадает в нужный сегмент пользователей и продукт создан для вас, далеко не факт, что вы будете полностью удовлетворены. Потому что, скорее всего, в вашей работе присутствуют какие-то ноу-хау по процессам, которые сформировались за долгие годы путем проб и ошибок. И, в случае внедрения коробочного программного продукта, вам придется подстроиться под процессы "зашитые в него" и в чем-то отказаться от тех уникальных отхождений от стандартного общепринятого процесса работы, которые были приняты в вашей компании.
Возможно, звучит это как минус, но все не так однозначно, ведь при таком подходе вы получаете и не мало плюсов. Обратная сторона медали заключается в том, что ваши бизнес-процессы подтягиваются до отраслевых стандартов, особенно если вы выбрали программный продукт, который используется в сотнях и тысячах компаний, подобной вашей. Во-вторых, вы экономите очень, очень, ОЧЕНЬ много времени и денег на проект по цифровой трансформации конкретного подразделения или отдела. До сих пор в компаниях не накоплен достаточный опыт в реализации проведении траснформационных изменений, и лучше потратить время и деньги на организационные и административные вопросы, вопросы обучения людей, вопросы методологической поддержки и т.д., чем на вопросы связанные с тем, "какого цвета сделать фон", "на каком языке программирования должна быть написана система", "куда разместить эту кнопочку вправо или влево" и т.п.
Но существуют случаи, когда разработка программного продукта "под себя", действительно, оправдана. Об этом поговорим ниже в пункте о разработке программного продукта "под себя".
Разработка программного продукта "под себя"
И вот мы подошли к классическому пути - аутсорс разработка, инхаус разработка, разработка на базе low-code платформ или ещё какая-то разработка, но все это "разработка". Отличие кроется в подходе к получению ценности от внедряемого программного продукта - если, в случае с коробочным программным продуктом, вы получаете ценность "из коробки", то есть в момент отгрузки. То в случае "разработки", вы должны обязательно пройти серьезный подготовительный этап анализа, сбора требований и проектирования системы, а также последующий за ним этап непосредственной разработки и создания программы. В крупных компаниях часто используется "водопадная модель разработки", в средних практикуют Agile подход с итеративным наращиванием функционала.
По опыту же разницы особо нет, и компании тратят значительные деньги и время, измеряемые в десятках и сотнях миллионов рублей и годах разработки. Но это и есть та цена, которую нужно отдать, если ты хочешь получить программный продукт, который подтсраивается под твои процессы, а не наоборот. В этой статье я не буду говорить о нашем опыте работы с различными крупными структурами, скажу только что там не все так гладко и не каждый проект оказывается успешным. И виной тому далеко не аутсорс-компании или разработчики в штате, многое зависит от подготовленности компании заказчика в виде настроенных процессов и обученных квалифицированных в вопросах цифровой трансформации специалистов.
Разработка программных решений "под себя" подходит зрелым компаниями, которые вышли на определенный уровень организационной структуры, у которых выстроена работа с внедрением изменений и реинжиниринг бизнес-процессов для руководителей обыденность, есть стратегия цифровой трансформации как часть общей стратегии развития компании, есть строгие регламенты, по которым работают сотни и тысячи человек, выделяются и будут выделяться серьезные бюджеты на постоянное повышение эффективности работы и производительности труда.
Выводы
Как вы, наверное, уже поняли, далеко не каждой компании требуется ввязываться в эту долгую игру по собственной разработке, чаще проще взять коробочный продукт и подстроиться под него. Но, если уже стало понятно, что "коробка" вам не подойдет, не пытайтесь усидеть на двух стульях - не получится. Принимайте решение о собственной разработке и вперед! Вперед со всеми вытекающими.
А это значит не нужно сравнивать процент соответствия коробочного программного продукта "хотелкам" бизнес-заказчика. Нужно искать исполнителя, который грамотно подойдет к процессу разработки, кто имеет в этом опыт - опыт именно коммерческой разработки под заказчика. Вендоры же разрабатывают "под себя", то есть заказчиком выступают они сами. А это совсем не то же самое, что внешняя разработка под клиента. Конечно, есть исключения или даже исключения подтверждающие правила, когда вендор ввязывается в доработку своего продукта под заказчика, теряет много времени и, в конечном счете, либо кто-то один остается в минусе, либо оба. Сами такими были, сейча в отдельном направлении компании оказываем услуги по разработке на нашей low-code платформе, которая законно и органично испольует продуктовые наработки для аутсорса :-)
Надеюсь, что со временем крупные компании, которым действительно нужна собственная разработка, перестанут сравнивать функциональные характериситики продуктов и переключаться на анализ компетенций исполнителя именно в разработке, конечно с учетом специфики отрасли и т.д. и т.п., а средние компании перестанут "играться в ИТ" и поймут, что их путь это задействование готовых решений, пусть и с какой-то небольшой подстройкой своих бизнес-процессов под эти программные продукты. Это позволит сэкономить всем участникам много времени и сил и работать максимально эффективно.
