Как выбрать вендора ПО, чтобы не провалить внедрение софта

По словам Владимира Тарасенко, коммерческого директора «Консист Бизнес Групп», важно обратить внимание на опыт использования программного обеспечения в сегменте: «Если на программном продукте вендора партнеры реализовывали аналогичные задачи, то риски снижаются. Наличие успешных проектов внедрения говорит не только о функциональных возможностях, но и том, что продукт справляется с нагрузкой».

Отчуждаемое ПО обладает инструментами, которые позволяют пользователю самостоятельно — с помощью команды или партнера — адаптировать его под себя, заниматься поддержкой и развитием решения, не меняя его программный код. Наличие таких инструментов зависит от архитектуры программного продукта. В идеале решение состоит из независимых слоев: ядра, доступ к которому есть только у вендора; слоя кастомизации с доступом для интегратора и слоя Low-Code, с которым работают сотрудники на стороне клиента. В противном случае любые небольшие изменения, вносимые заказчиком в код продукта для его адаптации под бизнес-потребности компании, могут привести к некорректной работе софта в целом.

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

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

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

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

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

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

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

Это важный показатель того, что вендор уверен в качестве своих продуктов. Например, компании группы ЛАНИТ активно применяют платформу для управления цифровым контентом LDM или ежедневно используют продукт ТУРБО Трекинг как для планирования разработки программных решений, так и для контроля исполнения проектов.

Наличие обучающих курсов для пользователей продукта свидетельствует о его зрелости. Так, у всех мировых вендоров есть центры обучения и сертификации с набором готовых образовательных программ и тестов. Российские производители софта нередко возлагают задачу по обучению заказчика на партнеров в рамках проекта внедрения софта. «Мы тесно работаем с „Сетевой Академией ЛАНИТ“. Это один из старейших учебных центров в России с огромным опытом и штатом профессиональных специалистов. По нашим продуктам ТУРБО мы совместно разработали online-программу обучения, которая доступна для наших партнеров и клиентов», — комментирует Владимир Тарасенко.

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

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

Если партнер берется доработать решение самостоятельно под клиента, то важно четко зафиксировать объем проекта: прописать в договоре требования, которым должно соответствовать ПО, его функциональные возможности, а также этапы реализации.

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

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

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

Быстрая победа (Quick Win) — распространенное понятие в ИТ. Этот подход позволяет проекту идти небольшими шагами, но с понятными промежуточными результатам. Минимизируется риск потери инвестиций, команды втягиваются в проект постепенно, при этом первые победы вдохновляют на будущий глобальный успех.

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

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

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

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

Эти пять шагов действительно могут минимизировать риски выбора неправильного вендора.