Блог

Цифровая трансформация: риски "коробочных решений"

Двигаясь по пути цифровой трансформации бизнеса можно мыслить о "цифре" как минимум двумя способами:
  1. Мышление "коробочными решениями"
  2. Мышление конструктором "собери решение под себя"

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



Спрос рождает предложение. Так возникает пестрый рынок ИТ "коробочных решений". Многие из них различаются только нюансами, но при этом позиционируются как отдельные продукты. Например :"Учет электронной очереди в аптеке", "Учет очереди покупателей в автосалоне" или "Организация электронной очереди в детском парке". Так работает стратегия продаж на ИТ рынке. Потому что как правило менеджер, принимающий решение о покупке, не сильно вникает в детали ИТ. Он выбирает по названию и насколько название совпадает с той проблемой, которую ему надо решить. У нас же сеть аптек и нужно организовать электронную очередь? Значит продукт "Учет электронной очереди в аптеке" для нас, а вот "Учет очереди покупателей в автосалоне" не для нас. У нас же не автосалон.



Такова логика выбора коробки. Но эта скорее логика "эффективного менеджера", который не хочет погружаться в задачу и хочет минимизировать собственные риски. Если что-то пойдет не так, то какой с него спрос? Мы провели маркетинговое исследование рынка в нужной нам нише продуктов и выбрали оптимальный.



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



Время внедрения растягивается, цена растет. Там где было ожидание, что купим и за месяц внедрим (все ж готовое!) преваращается в "уже прошло полгода, а света в конце тоннеля не видать".



Если заказчик проявил упорство и не бросил процесс внедрения на полпути (а такое происходит в более чем 50% случаев), то на выходе получается странный продукт. В основе которого лежит некая узконишевая "коробка", а поверх нее "самописные" конструкции различных "костылей". "Костыли" неизбежно возникают в процессе впиливания готовой "коробки" в живую ткань существующего бизнеса. Там подрезать, тут подпилить, тут скотчом примотать и пр.



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



Такими рисками и превышением бюджетов обычно заканчивается первоначальное желание сэкономить и не изобретать велосипед.



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



По аналогии первый вариант "коробки" можно рассмотреть как впиливание готового цельного шкафа, который к вам в квартиру доставили на лебедках с помощью подъемного крана через окно (потому что ни в лифт, ни по лестнице он не проходил). Дальше специалисты будут долбить стены, расширяя нишу. Стесывать стенки шкафа. Творчески пытаться впихнуть новую покупку, ломая привычный порядок вещей.



В варианте конструктора для сборки решения под себя не так много элементов, как может показаться эффективному менеджеру. Это всего лишь веб приложения. Нужно спроектировать базу данных и описать бизнес процессы - кто и когда какие кнопки будет нажимать и что будет при этом происходить. Собственно это и есть аналог замеров габаритов для шкафа. Затем пишется код (выпиливаются нужные детали) и веб приложение (шкаф) собирается в ИТ инфраструктуре заказчика. Четко и быстро.



Цифровая трансформация - это гармония процветания и фэншуй денежных потоков в ваших бизнес-процессах

Читайте далее - цифровая трансформация и выбивание долгов