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

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

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

Мифы при выборе ИТ-решений

Можно выделить следующие мифы, которые можно встретить у менеджеров, далеких от ИТ:

• Система решит все наши проблемы — нет, система лишь автоматизирует процессы, а не исправляет хаос в них.

• Чем больше функционала в системе, тем лучше — однако, статистика показывает, что 60–80% функционала внедренной информационной системы часто не используется.

• Давайте выберем систему на вырост — рост компании — это не факт, а гипотеза, при этом в текущей ситуации часто маловероятная. Зачем платить за неё сегодня?

• ИТ-подразделение всё решит без нас — практика показывает, что айтишники могут выбрать «самую надёжную», но не всегда «самую подходящую» под требования систему, особенно когда сами требования даже не сформулировали.

Шаг 1. Определяем связанные с проектом бизнес-цели

Определяемся с бизнес-целями, которые должны быть поддержаны проектом внедрения информационной системы. На простом языке нужно понять: а зачем вообще менять или внедрять систему? В идеальном мире в компании должно быть дерево целей, и, например, если есть цель «Создание эффективной системы управления персоналом», то вполне логично задуматься о внедрении системы автоматизации процессов HR, а вот если внедрение ИС не ведёт к поддержке бизнес-целей — стоит подумать, нужен ли вообще этот проект.

Прежде чем выбирать информационную систему, стоит задать себе честный вопрос: а нужна ли она вообще? Часто бизнес приходит с запросом: У нас бардак в продажах — давайте внедрим CRM-систему! Но CRM-система не устранит бардак — просто будет автоматизированный бардак в продажах. Если процессы продаж не будут выстроены, автоматизация может только усугубить проблему.

Шаг 2. Создаем кастомное решение или покупаем готовое с рынка (Buy vs Build)

Жить в «типовой» информационной системе или «строить» систему под себя – это следующая развилка:

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

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

• Low-code конструкторы или Open Source — компромиссный путь, который требует внутренней экспертизы в организации.

Тут можно использовать правило: если ваш бизнес-процесс типовой — используйте типовое решение, не изобретайте велосипед.

Шаг 3. Сбор и взвешивание требований для выбора и принятия решения

Можно использовать четыре группы требований.

1. Функциональные—  что должна уметь система? Пример: «Поддержка ежемесячного расчёта показателей мотивации по сотрудникам».

2. Технические — как система должна быть устроена?  Пример: «Поддержка интеграции через REST API» или «Возможность работы в облаке».

3. Стоимостные — во сколько это обойдётся? Пример: «Считаем не только лицензию, но и внедрение, поддержку, обучение — то есть TCO (Total Cost of Ownership)».

4. Требования к поставщику — кто будет внедрять? Пример: «Опыт внедрения в отрасли», «Локальная команда поддержки», «Финансовая устойчивость».

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

• Функциональные — 41%

• Технические — 25%

• Стоимостные — 18%

• Поставщик — 16%

Шаг 4. Long-list → Short-list → RFP (Request for Proposal) → Пилот

1. Long-list — собираем всех потенциальных вендоров (это может быть 10-15 компаний).

2. Short-list — отбираем 4–6 систем по базовым критериям.

3. RFP (Request for Proposal) — рассылаем анкеты с требованиями и стандартными ответами.

4. Демонстрации и пилоты — проверяем заявленные возможности на практике.

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

Пример выбора HR-системы для крупной региональной компании

Компания развивала систему собственной разработки для управления персоналом, но после реформы системы оплаты труда работников у бизнеса возник вопрос: «А не пора ли перейти на типовое решение?»

В рамках проекта было собрано: 228 функциональных требований, 46 технических, 9 стоимостных и 6 требований к поставщику. Требования в анкете была разосланы пяти поставщикам, а шестым игроком была внутренняя команда разработки, развивающая свое решение.

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

Из этого можно сделать вывод, что не всегда самая «крутая» система — лучший выбор для организации. Хорошая система — это не та, у которой больше всего функций, а та, которая решает ваши бизнес-задачи с минимальными затратами на внедрение и владение.

Выученные уроки

• Не верьте обещаниям — фиксируйте все ответы поставщика в RFP и привязывайте к договору.

• Избегайте «доработок ради доработок»: если в компании 34 закупщика используют 34 разных сценария закупочного процесса — это не повод тащить их все в новую систему.

• Проверяйте поставщика: спрашивайте детальный план проекта и проверяйте опыт на референс-визитах. Если приносят план на листе А4 — 100 раз подумайте, возможно для поставщика ваш проект будет первый.

• Считайте TCO, а не только стоимость лицензий. Иногда поддержка «бесплатной» open-source системы обходится дороже, чем предложение от вендора.

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

А если у вас есть опыт выбора ИС — делитесь в комментариях! Особенно интересны кейсы с неочевидными решениями.

Для CTO и технических руководителей выбор ИС — часть технологической стратегии, а не разовая «покупка софта». На курсе OTUS «CTO / Технический директор» вы разберете архитектуру и портфель систем, научитесь выстраивать процессы выбора ИТ-решений вместе с бизнесом. Курс помогает структурировать опыт и превратить интуитивные решения по ИС в прозрачную, воспроизводимую управленческую практику.

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

• 26 ноября: «Как обосновать инвестиции в ИТ при урезанном бюджете». Записаться

• 2 декабря: «Из техлида в CTO: 4 компетенции, которые делают вас незаменимым для бизнеса». Записаться