Почему ошибки при выборе ПО обходятся компаниям дороже самого внедрения

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

 

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

Чаще всего причиной становится вовсе не качество выбранной системы и не работа интегратора.

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

Самые дорогие работы на проекте — вовсе не внедрение

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

На самом деле самые дорогие работы появляются уже после начала проекта. Речь идет о доработках. Важно понимать разницу между настройкой и доработкой. Настройка использует возможности, которые уже предусмотрел разработчик системы. Доработка — это создание нового функционала, которого в продукте никогда не существовало. Фактически заказчик финансирует разработку программного обеспечения внутри типового продукта. Каждая подобная доработка увеличивает стоимость проекта не один раз. Она требует проектирования, разработки, тестирования, документирования, последующего сопровождения и зачастую усложняет переход на новые версии системы.

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

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

Именно этот вопрос должен решаться еще до подписания договора на внедрение.

Почему заказчики выбирают не ту систему

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

Чаще всего заказчик приходит уже с готовым решением. «Нужно перейти на новую версию.» «Нужно внедрить ERP.» «Нужно заменить существующую систему.»

Но очень редко звучит вопрос:

А действительно ли именно эта система нужна компании через три-пять лет?

В этом и заключается основная проблема.

Компания формулирует решение, хотя сначала необходимо определить саму задачу.

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

И это не означало ошибку заказчика.

Это означало, что бизнес успел измениться быстрее, чем его информационные системы.

Что на самом деле нужно обследовать

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

На практике это не совсем так.

На этапе выбора программного продукта гораздо важнее понять требования не к программе, а к бизнесу.

Мы всегда разделяем два разных понятия.

Первое — требования к бизнес-процессам.

Второе — требования к функциям конкретной информационной системы.

До выбора программного обеспечения невозможно корректно сформулировать требования ко всем экранам, отчетам или кнопкам.

Но можно определить, как должен работать бизнес.

Именно эти требования становятся основой для выбора будущей архитектуры.

Поэтому обследование обычно проводится на верхнем уровне.

Анализируются процессы компании, планы развития, стратегия масштабирования, организационная структура, взаимодействие подразделений и будущие изменения бизнеса.

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

Главная задача заключается не в поиске идеального продукта.

Идеальных систем не существует.

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

Как принимается решение

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

Мы используем подход, который напоминает принятие инвестиционных решений.

Сначала определяются архитектурные развилки — ключевые вопросы, влияющие на будущую ИТ-архитектуру компании.

Например:

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

После этого формируется матрица оценки.

В нее включаются критерии, действительно влияющие на эффективность будущего проекта:

• покрытие бизнес-процессов;
• объем необходимых доработок;
• стоимость владения;
• возможности масштабирования;
• зрелость платформы;
• сложность интеграций;
• риски внедрения;
• стоимость дальнейшего развития.

Каждый критерий получает свой вес.

Каждая система оценивается по единой методике.

И только после этого принимается решение.

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

От выбора системы — к проектированию архитектуры

Вопреки распространенному мнению, результатом обследования становится не рекомендация купить определенную систему.

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

По итогам обследования разрабатывается целевой ИТ-ландшафт.

Он показывает:

• какие системы остаются;
• какие заменяются;
• какие появляются впервые;
• как между ними будут передаваться данные;
• какие интеграции необходимо реализовать;
• в какой последовательности должны запускаться проекты.

Именно эта схема становится основой дорожной карты цифровой трансформации.

Практический пример: когда проект по обновлению системы превратился в проект цифровой трансформации

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

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

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

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

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

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

Даже после обновления значительная часть новых бизнес-процессов не покрывалась бы типовым функционалом. Это означало бы необходимость большого объема дорогостоящих доработок, а в дальнейшем — сложностей с сопровождением, обновлением и развитием системы.

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

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

 

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

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

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

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

Предварительное обследование — это не расходы, а страхование инвестиций

Компании среднего бизнеса сегодня растут значительно быстрее, чем десять лет назад.

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

Информационные системы должны развиваться вместе с бизнесом.

Поэтому цена ошибки при выборе программного обеспечения становится все выше.

Стоимость качественного обследования обычно составляет лишь небольшую долю бюджета будущего проекта.

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

По сути, предпроектное обследование — это не консалтинговая услуга.

Это инструмент управления инвестиционными и проектными рисками.

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

 

ссылка на публикацию companies.rbc.ru