Стоит ли тратиться на «белого слона»? Или что делать с избыточным корпоративным ПО

Когда компания внедряет громоздкую ИТ-систему, в которой реально востребовано едва ли 10% функций и стоит которая как Boeing — это не случайность, а системная проблема. И да, это и есть тот самый «белый слон».

Действительно, корпоративное ПО легко может оказаться тем еще «белым слоном». VMware, например, предлагает настолько сложный продукт, что для 90% пользователей актуальны только 5% из заявленного функционала, перегруженность MS Dynamics CRM или Битрикс 24 уже стала легендарной, а Slak, при очевидной его пользе как корпоративного мессенджера, частенько клеймят убийцей продуктивности — в том числе из-за избыточного функционала.

Было бы полбеды, если бы возможности и инструменты просто лежали мертвым грузом (да, плохо, да, перегружен интерфейс, но если выполнять инструкции «туда — ходи, а туда — ходи», то вполне терпимо). Но ведь за то, что никак не используется, приходится платить: и не только на этапе внедрения, но и на за поддержку. Все ведь помнят банкротство славного города Бирмингем в Великобритании?

Напомним: в сентябре 2023 года городской совет Бирмингема (Великобритания) объявил о банкротстве. Одним из ключевых факторов бюджетного дефицита стал провальный переход с ERP-системы SAP на Oracle Fusion. Проект затянулся на годы, его стоимость выросла с 20 млн до 100 млн фунтов стерлингов, а новая система оказалась не адаптирована к нуждам муниципалитета. Система Oracle Fusion, в которой есть, кажется, все для автоматизации любых управленческих процессов, подорожала для городского совета в пять раз — избыточность решения для специфических задач городского управления очевидна.

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

· Гонка фич — и как основа для маркетинговой стратегии, и как результат «подглядывания» в замочную скважину за процессами разработки у конкурентов. С одной стороны гонка фич подогревается желанием, вполне искренним, конечно же, сделать продукт как можно более привлекательным. Причем, привлекательным для пользователя — но только по мнению разработчика. С другой — разработка новых возможностей становится идеей фикс, по мере того как разработчик изучает продукты конкурентов. И вот появление «киллер-фич» превращается в самоцель: при разработке акцент делается на фичи как конкурентные преимущества. Мнение пользователей при этом не то чтобы игнорируется, но его учитывают далеко не в первую очередь.

Небольшой пример: разработчики электронных торговых площадок стараются включить в «коробки» как можно больше вариантов закупочных процедур. На практике корпоративные закупщики и снабженцы используют едва ли два-три вида тендеров: аукционы на понижение да запросы цен, которые дополняют переторжками. Конкурсы, запросы предложений, двойные встречные аукционы, японские аукционы (тысячи их) просто висят мертвым грузом в ЭТП — и они нужны от силы 5-10% пользователей.

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

· Инерция в развитии продукта — нежелание отказываться от фич и возможностей, которые были когда-то разработаны, но оказались невостребованными или утратили актуальность по объективным причинам. Редкий разработчик готов удалить старую фичу — ведь на нее потрачено N часов. Часто причина неудаления — фича нужна, но для одного-единственного клиента, под которого она и разрабатывалась. Затем она кочует из релиза в релиз — и попадает в версии для других клиентов, которым до нее нет никакого дела.

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

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

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

Избыточный функционал равно сложный интерфейс, непонятная навигация и логика работы с системой, далекая от формальной. Даже если использовать только 10% функций, сотрудникам всё равно приходится тратить время на освоение избыточного интерфейса. И вместо трех-четырех часов на обучение после внедрения ПО — 30-40 часов. Новые пользователи с трудом вовлекаются в работу с системой. К тому же это провоцирует (как будто самого факта внедрения нового ПО недостаточно!) саботаж со стороны сотрудников по отношению к работе в новой программе. На поддержку пользователей, как минимум — на первых порах — тоже приходится закладывать бюджет. «Глупые» вопросы, непонимание принципов работы ПО, ошибки и необходимость разъяснять пользу от системы — все это выливается в новые расходы, размеры которых сложно даже прогнозировать.

Чем сложнее информационная система, тем выше вероятность того, что ваш штатный «программист» не справится с ее настройкой, а пользователи никогда не разберутся, как же работать с системой. Об интеграции с другим корпоративным ПО, адаптации системы к регламентам компании, настройке прав пользователей речи тоже не идет. В результате компания становится зависимой от подрядчика по внедрению или вендора — и, едва закончится время бесплатной техподдержки (если она вообще есть), за каждый чих и каждую настройку придется платить.

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

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

Обилие функций и возможностей может создать иллюзию, что уж теперь-то автоматизация заданного бизнес-процесса (или процессов) есть. Руководство радостно изучает автоматические отчёты и графики, а вот сотрудники — продолжают работать «вручную», как раньше: ведь использовать систему неудобно, хотя и приходится что-то «забивать» в нее, чтобы продемонстрировать активность. В результате, ни ПО не решает свои задачи, ни сотрудники не вовлекаются в работу. Из-за саботажа и откровенно недостоверных отчетов руководство компании просто не может

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

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

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

Решения «на все случаи жизни» редко работают эффективно без тонкой настройки. А вот нишевые продукты, созданные для конкретной отрасли или вида бизнеса, часто лучше поддерживают бизнес-процессы. Например:

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

Вариант с выбором системы такого типа подойдет как для «попробовать», т.е. для тестирования, так и для автоматизации работы отдельных направлений или проектов. Часто гибкие тарифы идут рука об руку с облачными системами. Если говорить об автоматизации корпоративных закупок, то примерами систем с гибкими тарифами будут B2B Altis и «Умные закупки»:

Если бюджет на внедрение совсем невелик, собственных ИТ-специалистов нет, а процессы, которые нужно автоматизировать, предельно простые (или уникальные), можно выбрать либо бесплатные open-source решения, либо low- или no-code системы.

В первом случае стоимость владения системой будет определяться только зарплатой или гонораром специалиста, который возьмется настраивать и поддерживать систему. Во втором — вы сэкономите, как минимум, на поддержке системы: в большинстве случаев low- или no-code решения настраиваются без участия разработчиков — достаточно подключить к работе технически грамотного сотрудника. Однако отметка «low-code» в описании системы вовсе не означает, что внедрение и покупка лицензии обойдутся дешевле, чем ПО, лишенного этого модного тега. Экономить получится только на сопровождении со стороны вендора.

Как совсем недавно броская надпись «Реклама» сменилась в поисковой выдаче Яндекса сначала скромным ₽, а потом нейтральным «Промо», так и массивные, с сотнями функций, корпоративные решения все чаще отходят от модели «дать все и сразу» и меняются — или разрабатывают новые продукты, которые ориентированы на компании с простыми бизнес-процессами, небольшим бюджетом и без разработчиков в штате.

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

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

Как видно, тренды в развитии корпоративного ПО вполне отвечают запросам малого и среднего бизнеса — получить за «мало денег» строго те возможности, которые нужны. Это позволяет надеяться, что содержание корпоративного «белого слона» совсем скоро станет необязательным, а сугубо добровольным.