Представители бизнеса часто спрашивают, какую информационную систему выбрать. И у меня нет ответа на этот вопрос, ведь все компании разные и, не понимая требований к информационной системе, рекомендовать ИТ‑решение нельзя.
Сразу хочу сказать, что выбор ИТ‑решения — это не техническая задача, а бизнес‑решение, и принимать его нужно не на основе данных в маркетинговых презентациях ИТ‑поставщиков, а на основе прозрачной методологии. В этом материале хочу рассказать о подходе к выбору ИТ‑решений. А уже использовать его или нет — решать вам.
Сейчас выбор информационной системы стал стратегическим решением, которое может повлиять на будущее организации. При этом некоторые руководители до сих пор подходят к этому вопросу интуитивно: «давайте купим систему на вырост» или «нам все потребности закроет одна информационная система». Практика показывает, что неправильный выбора ИТ-решения может привести не только к дополнительным затратам и сдвигу сроков, но и к провалу проектов внедрения.
Мифы при выборе ИТ-решений
Можно выделить следующие мифы, которые можно встретить у менеджеров, далеких от ИТ:
Система решит все наши проблемы — нет, система лишь автоматизирует процессы, а не исправляет хаос в них.
Чем больше функционала в системе, тем лучше — однако, статистика показывает, что 60–80% функционала внедренной информационной системы часто не используется.
Давайте выберем систему на вырост — рост компании — это не факт, а гипотеза, при этом в текущей ситуации часто маловероятная. Зачем платить за неё сегодня?
ИТ-подразделение всё решит без нас — практика показывает, что айтишники могут выбрать «самую надёжную», но не всегда «самую подходящую» под требования систему, особенно когда сами требования даже не сформулировали.
Шаг 1. Определяем связанные с проектом бизнес-цели
Определяемся с бизнес-целями, которые должны быть поддержаны проектом внедрения информационной системы. На простом языке нужно понять: а зачем вообще менять или внедрять систему? В идеальном мире в компании должно быть дерево целей, и, например, если есть цель «Создание эффективной системы управления персоналом», то вполне логично задуматься о внедрении системы автоматизации процессов HR, а вот если внедрение ИС не ведёт к поддержке бизнес-целей — стоит подумать, нужен ли вообще этот проект.
Прежде чем выбирать информационную систему, стоит задать себе честный вопрос: а нужна ли она вообще? Часто бизнес приходит с запросом: У нас бардак в продажах — давайте внедрим CRM-систему! Но CRM-система не устранит бардак — просто будет автоматизированный бардак в продажах. Если процессы продаж не будут выстроены, автоматизация может только усугубить проблему.
Шаг 2. Создаем кастомное решение или покупаем готовое с рынка (Buy vs Build)
Жить в «типовой» информационной системе или «строить» систему под себя – это следующая развилка:
Своя разработка — часто дорого, рискованно и требует постоянной поддержки. Оправдано только при уникальных бизнес-процессах в больших организациях.
Покупка типовой системы — быстрее, иногда дешевле, система поддерживается вендором. Рекомендуется в 90 % случаев, особенно для небольших организаций.
Low-code конструкторы или Open Source — компромиссный путь, который требует внутренней экспертизы в организации.
Тут можно использовать правило: если ваш бизнес-процесс типовой — используйте типовое решение, не изобретайте велосипед.
Шаг 3. Сбор и взвешивание требований для выбора и принятия решения
Можно использовать четыре группы требований.
Функциональные— что должна уметь система? Пример: «Поддержка ежемесячного расчёта показателей мотивации по сотрудникам».
Технические — как система должна быть устроена? Пример: «Поддержка интеграции через REST API» или «Возможность работы в облаке».
Стоимостные — во сколько это обойдётся? Пример: «Считаем не только лицензию, но и внедрение, поддержку, обучение — то есть TCO (Total Cost of Ownership)».
Требования к поставщику — кто будет внедрять? Пример: «Опыт внедрения в отрасли», «Локальная команда поддержки», «Финансовая устойчивость».
Не все группы требования равнозначны. Можно применить экспертную оценку в группе экспертов методом попарного сравнения, чтобы определить вес каждой группы требований. Например, в одном из проектов получились следующие веса требований:
Функциональные — 41%
Технические — 25%
Стоимостные — 18%
Поставщик — 16%
Шаг 4. Long-list → Short-list → RFP (Request for Proposal) → Пилот
Long-list — собираем всех потенциальных вендоров (это может быть 10-15 компаний).
Short-list — отбираем 4–6 систем по базовым критериям.
RFP (Request for Proposal) — рассылаем анкеты с требованиями и стандартными ответами.
Демонстрации и пилоты — проверяем заявленные возможности на практике.
Кстати, если есть уже существующая система, которую планируется заменить, то можно и ее включить в сравнение, так же, как и оценки команды, которая берется за собственную разработку, если вдруг такая команда есть, и она может сделать оценку, которой можно доверять.
Пример выбора HR-системы для крупной региональной компании
Компания развивала систему собственной разработки для управления персоналом, но после реформы системы оплаты труда работников у бизнеса возник вопрос: «А не пора ли перейти на типовое решение?»
В рамках проекта было собрано: 228 функциональных требований, 46 технических, 9 стоимостных и 6 требований к поставщику. Требования в анкете была разосланы пяти поставщикам, а шестым игроком была внутренняя команда разработки, развивающая свое решение.
В результате сравнения был определен внешний поставщик, который победил по сумме критериев, при этом внутренняя команда разработки пришла к финишу последней. Победила система, которая не была лидером по функционалу, потому что общая оценка ставилась с учётом стоимости владения системой и надежности поставщика.
Из этого можно сделать вывод, что не всегда самая «крутая» система — лучший выбор для организации. Хорошая система — это не та, у которой больше всего функций, а та, которая решает ваши бизнес-задачи с минимальными затратами на внедрение и владение.
Выученные уроки
Не верьте обещаниям — фиксируйте все ответы поставщика в RFP и привязывайте к договору.
Избегайте «доработок ради доработок»: если в компании 34 закупщика используют 34 разных сценария закупочного процесса — это не повод тащить их все в новую систему.
Проверяйте поставщика: спрашивайте детальный план проекта и проверяйте опыт на референс-визитах. Если приносят план на листе А4 — 100 раз подумайте, возможно для поставщика ваш проект будет первый.
Считайте TCO, а не только стоимость лицензий. Иногда поддержка «бесплатной» open-source системы обходится дороже, чем предложение от вендора.
В качестве заключения, описанный подход активно применяется во многих крупных организациях при выборе информационных систем, его легко воспроизвести на практике, он позволяет защитить принятое решение на внешних аудитах, ну и в целом, снижает риски провала проекта.
А если у вас есть опыт выбора ИС — делитесь в комментариях! Особенно интересны кейсы с неочевидными решениями.
Для CTO и технических руководителей выбор ИС — часть технологической стратегии, а не разовая «покупка софта». На курсе OTUS «CTO / Технический директор» вы разберете архитектуру и портфель систем, научитесь выстраивать процессы выбора ИТ-решений вместе с бизнесом. Курс помогает структурировать опыт и превратить интуитивные решения по ИС в прозрачную, воспроизводимую управленческую практику.
Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные демо-уроки:
26 ноября: «Как обосновать инвестиции в ИТ при урезанном бюджете». Записаться
2 декабря: «Из техлида в CTO: 4 компетенции, которые делают вас незаменимым для бизнеса». Записаться