Выбор информационной системы: алгоритм прост

Число различных трехбуквенных аббревиатур, обозначающих новые классы информационных систем, растет на глазах - ERP, CRM, SCM, WMS, BPM, ESB, BPA, PLM, MDM, SRM и пр. Одновременно с этим в каждом классе увеличивается количество решений, предлагаемых на российском рынке. Как не ошибиться в таком многообразии предложений и сделать правильный выбор?

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

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

Собираем требования

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

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

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

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

Формируем запросы

После определения требований и понимания их приоритетности все становится предельно просто. На базе требований формируется запрос информации поставщикам (RFI – request for information). При этом перечень компаний для рассылки может также формироваться по тем или иным критериям через анализ внешних источников, всевозможных рейтингов или по рекомендации экспертов. Фактически составляется длинный список (Long list), в рамках которого и рассылается запрос. В этом запросе поставщикам предлагается ответить на сформулированные требования и дается определенное время для подготовки.

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

После того как определился короткий список поставщиков (Short list), им рассылается запрос предложений (RFP – request for proposal). Тут поставщик должен ответить более детально: он не только проясняет потенциальную возможность реализации того или иного требования штатной функциональностью своей системы или возможностью доработок, но и формирует стоимость данных работ. После анализа представленных от поставщиков данных производится окончательный выбор информационной системы и ее поставщика. При этом как у покупателя, так и у продавца возникает четкое понимание трудозатрат и цены внедрения, и чем глубже были проработаны запросы клиента в части организационного объема проекта и требуемой функциональности, тем больше вероятность того, что поставщик корректно оценит свои затраты и даст в предложении правильную цену.

Проверяем в реальности

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

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

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

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

Источник: CNews