Коробочные решения в ПО для бизнеса: как скрытые ограничения крадут ваше будущее?

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

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

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

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

Оказывается, последние два года компания не просто пользовалась удобным инструментом, а постепенно загоняла себя в коридор, из которого теперь не видно выходов. Самое неприятное здесь то, что на этапе выбора список функций выглядел внушительно, цена радовала, отзывы других пользователей обнадёживали. Никто не обманывал – просто показывали то, что система умеет, и умалчивали о том, чего она не умеет и не будет уметь никогда.

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

Кому подходят коробочные решения?

Готовые решения появились на рынке не чтобы кому-то навредить. У них есть своя логика, своя задача и своя аудитория, для которой они подходят действительно хорошо. И прежде чем разбирать скрытые ограничения, стоит понять, а для чего вообще эти продукты создавались изначально. Тогда станет яснее, где проходит граница между «работает как часы» и «начинает душить».

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

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

Отсюда и привлекательная цена: затраты на создание распределяются на всех покупателей, а не ложатся на плечи одного.

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

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

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

Берут коробку, быстро внедряют, закрывают горящую потребность, а параллельно закладывают бюджет и время на будущую заказную разработку. Это осознанная стратегия, и она тоже работает, если не забывать, что это именно промежуточный этап, а не финал.

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

Интересно, что момент перерастания почти никогда не наступает резко. Это медленный процесс, который легко пропустить: сначала приходится чуть-чуть подстраивать свой процесс под логику системы, потом ещё чуть-чуть, потом руководитель ловит себя на мысли, что новую услугу клиентам не запускают не потому, что нет спроса, а потому, что система её не потянет.

Скрытые ограничения, которые работают против вас

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

Потолок настройки

На презентации это звучит примерно так: «У нас очень гибкая система, вы сможете настроить практически всё под свои задачи». Звучит отлично, и поначалу так и кажется. Вы заходите в раздел настроек, а там действительно много ползунков, переключателей и вариантов.

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

Когда ваш бизнес начинает жить своей жизнью и требует чего-то четвёртого или пятого, вы подходите к стене. Хотите начислять скидку в зависимости от погоды в регионе доставки? Хотите маршрут курьера строить с учётом пробок в реальном времени?

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

Закрытый код и зависимость от поставщика

Большинство коробочных продуктов распространяются по принципу «пользуйтесь, но не трогайте». Исходный код закрыт, база данных часто хранится в формате, который нельзя просто взять и прочитать сторонними средствами. На старте это вообще не воспринимается как проблема: работает же, и ладно, но со временем выясняется, что вы не владеете программой, а арендуете её.

Разница примерно как между собственной квартирой и съёмной: в первой можно перепланировку сделать, а во второй даже гвоздь лишний раз не вобьёшь без разрешения хозяина.

Зависимость от поставщика проявляется не сразу, а в тот момент, когда вам что-то нужно изменить, а поставщик говорит: «Нет». Или когда поставщик поднимает цену на обслуживание, а вы понимаете, что деваться некуда, потому что переход на другую систему стоит совершенно невменяемых денег. Или, что ещё хуже, когда поставщик вообще закрывает продукт или перестаёт его обновлять, а вы сидите с системой, которая медленно, но верно устаревает, и не можете ничего с этим сделать.

Обновления по чужому расписанию

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

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

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

Платная достройка того, что должно быть в основе

Многие коробочные продукты продаются по принципу «базовая версия дёшево, а дальше смотрите сами». Звучит справедливо: платишь только за то, что нужно. Но на практике часто выясняется, что без дополнительных модулей система не делает ровно то, ради чего её покупали.

Интеграция с бухгалтерией – отдельный модуль, выгрузка для маркетплейсов – отдельный модуль, нормальная аналитика – будьте добры, ещё денег. И вот уже цена, которая так радовала на старте, начинает незаметно, но неуклонно ползти вверх.

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

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

Архитектура, не рассчитанная на рост

На демонстрации система летает: отчёты строятся за секунды, данные грузятся моментально, всё отзывчивое и плавное. Никто не говорит, что это происходит на тестовой базе с сотней записей, а у вас через год работы база раздуется до миллионов записей.

Проблема в том, что архитектура коробочного продукта закладывается под усреднённые нагрузки. Разработчик не знает, вырастете вы в десять раз за год или останетесь на том же уровне, и он не может закладываться на рекорды – иначе продукт получится слишком дорогим для массового рынка. Он выбирает золотую середину, и для большинства клиентов она работает нормально, но если ваш бизнес начинает расти быстрее среднего, вы первыми упрётесь в технический потолок.

Система начнёт тормозить, зависать, а в пиковые моменты и вовсе падать. Самое обидное, что вы к этому рывку готовились, вкладывались в маркетинг, нанимали людей, а фундамент под всей этой конструкцией оказался фанерным.

Ловушка миграции

На входе всё легко и быстро, а вот выход из системы – это отдельная история, чаще всего печальная. Данные хранятся в закрытом формате, нормальной выгрузки нет, часть истории при переносе теряется. Сделано это не обязательно со злым умыслом, но объективно получается так, что уйти из системы в разы сложнее и дороже, чем войти.

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

Многие выбирают остаться – не потому что система хороша, а потому что уйти слишком больно. А это уже не осознанный выбор, а самая настоящая зависимость, в которую компания сама себя загнала, не подозревая об этом на старте.

Как распознать ограничения до внедрения?

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

Начните с прямого вопроса не о том, что система умеет, а о том, чего она не умеет и не будет уметь. Спросите, где заканчиваются настройки и начинается код, который трогать нельзя, какие пожелания клиентов лежат в очереди на доработку дольше года, какие запросы были отклонены с формулировкой «мы не планируем это делать».

По тому, как продавец отвечает на эти вопросы, можно понять очень многое. Уклончивость, общие фразы про «индивидуальный подход» и попытки перевести разговор обратно на сильные стороны продукта – тревожный сигнал. Честный поставщик скажет прямо: «Вот тут у нас ограничения, это мы не делаем, это пока не умеем, а это делаем только через партнёров за отдельные деньги».

Стоит также провести демонстрацию на ваших сценариях. Типовой пример от продавца – это как тест-драйв автомобиля по идеально ровной дороге: всё гладко, но вы не узнаете, как машина поведёт себя на просёлке. Ваши реальные процессы – это и есть тот просёлок, на котором многое становится видно.

Возьмите пару нестандартных ситуаций из своей практики и попросите показать, как система с ними справится. Если справляется – хорошо, если продавец начинает объяснять, что так никто не делает и вам это не нужно, – это повод насторожиться. Вам нужно, а значит, это важно.

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

Расспросите про то, как живёт продукт после покупки:

• Как часто выходят обновления?
• Кто принимает решение о том, что в них войдёт?
• Есть ли публичная дорожная карта развития на год-два вперёд?
• Как учитываются пожелания клиентов и можно ли посмотреть очередь этих пожеланий?

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

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

Параллельно с расспросами поставщика стоит провести небольшой внутренний аудит. Он не требует специальных знаний или консультантов, достаточно сесть и трезво ответить себе на несколько вопросов.

Где вы планируете оказаться через два-три года? Если планов на рост нет, если текущие объёмы вас устраивают и рынок не заставляет расширяться – коробочное решение может быть отличным выбором.

Если же вы рассчитываете вырасти в несколько раз, выходить в новые регионы или запускать смежные направления – спросите поставщика прямо: выдержит ли система такие объёмы? И попросите показать примеры клиентов, которые уже выросли с этим продуктом в схожих масштабах. Если таких примеров нет, это не значит, что их не может быть в принципе, но это значит, что вы будете первопроходцем со всеми вытекающими рисками.

Оглядитесь вокруг и честно спросите себя: вы работаете так же, как все в вашей отрасли, или у вас есть собственные наработки, которые дают преимущество?

• Если процессы типовые – коробка для вас.
• Если уникальные – готовьтесь к тому, что либо процессы придётся подгонять под систему, либо система начнёт вас ограничивать.

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

Посчитайте не стоимость входа, а примерную стоимость владения на три года вперёд:

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

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

Что делать если коробка не подходит, а бюджет ограничен?

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

Модульная заказная разработка

Самый очевидный компромисс – не пытаться автоматизировать всё сразу, а начать с самого критичного участка. Обычно в любом бизнесе есть одно-два места, где неудобство стоит дороже всего: приём заказов, работа с клиентской базой, складской учёт. Именно там ручной труд съедает больше всего времени или именно там теряются деньги из-за ошибок.

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

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

Готовые платформы с возможностью глубокой достройки

Системы, у которых есть готовая база – стандартные справочники, типовые операции, базовые отчёты – но при этом открытый код или развитые средства для программирования дополнительной логики.

Идея в том, что вы не пишете всё с нуля, а берёте заготовку и дописываете к ней то, что отличает вас от других. Стандартная часть – склад, финансы, контрагенты – работает из коробки, а уникальная часть – особая логика расчёта стоимости услуги, нестандартная интеграция с оборудованием, специфическая отчётность – дописывается под вас.

Это быстрее и дешевле, чем полный заказ, и при этом вы не зажаты в тиски заранее предусмотренных сценариев. Минус в том, что такие платформы нужно уметь выбирать: не каждая система с гордой надписью «открытый код» действительно даёт свободу доработки. Нужно проверять, насколько глубоко можно залезть во внутренности, кто владеет правами на доработки и можно ли их будет перенести в будущем на другую платформу.

Совместная разработка с подрядчиком на условиях поэтапной приёмки

Одна из главных проблем большого заказа – риск остаться ни с чем после года ожидания, когда подрядчик не справился или сделал не то. Поэтапная приёмка этот риск заметно снижает.

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

Если на каком-то этапе что-то пошло не так, вы не теряете всё, а только этот кусок, и можете спокойно менять подрядчика или пересматривать планы на следующий этап. Заодно такой подход даёт возможность раньше начать пользоваться системой и раньше начать получать от неё отдачу, что немаловажно для бюджета. Ну и главное — вы с самого начала владеете тем, за что заплатили. Это не аренда, не лицензия на год, это ваш актив.

Коробка как временное решение с осознанным планом выхода

Бывает и так, что прямо сейчас ресурсов нет ни на какой заказ, а работать без системы невозможно. В этом нет ничего стыдного, и коробка в такой ситуации – вполне разумный выбор. Но с одной важной оговоркой: вы заходите в неё не навсегда, а с заранее составленным планом выхода.

Что должно быть в этом плане: примерный срок жизни коробки в вашей компании – год, два, три, а также бюджет, который вы за это время отложите на будущую разработку, и понимание того, какие данные вы будете мигрировать и в каком виде они должны сохраниться.

Если такой план есть и он не лежит в ящике, а периодически пересматривается – коробка из ловушки превращается в полезный инструмент переходного периода. Она честно отработает своё, а вы за это время подготовите почву для чего-то более серьёзного.

Разработка ПО от 66 Бит

Всего за 10 минут мы разобрали коробку на части и выяснили какие из них могут убить будущее вашего бизнеса. А если вы обнаружили, что выросли из коробочных решений, советуем обратиться в 66 Бит!

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