Правильный вендор: что нужно знать при выборе разработчика ПО
18.08.2023
Как выбрать вендора по, чтобы не провалить внедрение софта
Внедряя ПО, бизнес стремится работать эффективнее. Однако результат будет противоположным, если не учесть важные нюансы при выборе софта и партнера по внедрению. Спросили у представителей компаний, входящих в группу ЛАНИТ, которые разрабатывают отечественные программные продукты для бизнеса, на что обратить внимание в этом сложном процессе и как предупредить возможные риски.
Почему важно вдумчиво подойти к выбору вендора
Когда перед ИТ-директором встает задача внедрить в компании новый программный продукт или найти замену старому, на первый взгляд кажется, что выбор ПО можно сделать, сравнив возможности представленных на рынке решений. Только вот любой софт в своем сегменте имеет схожий функционал: все CRM-системы (Customer Relationship Management) так или иначе структурируют знания бизнеса о клиентах и коммуникации с ними, а все ECM-решения (Enterprise Content Management) предназначены для того, чтобы компания смогла отладить работу со всем багажом неструктурированной информации: документами, чертежами, сканами, сообщениями электронной почты и прочим.Значит, при выборе ПО нужно отталкиваться не столько от самого решения, сколько обращать внимание на нюансы. И важность их очень высока, потому что ошибки выбора могут не только повлиять на судьбу проекта, но и отразиться на финансовом результате компании и в целом на устойчивости бизнеса. Вот несколько наиболее распространенных рисков.
Потеря времени и денег — наиболее частое следствие ошибок на этапе выбора продукта и команды внедрения. Риски будут усиливаться, когда проект привязан к основным задачам бизнеса и сезонным циклам.
«Неправильный выбор вендора грозит не только потерянными инвестициями. Давайте разберем на примере ритейла. На период с октября по декабрь приходится пик продаж в этом сегменте. И допустим, компания N хочет запустить софт, чтобы получить максимум выручки в эти месяцы. Задача проекта — повлиять на процесс продаж. Компания заказывает проект, но к сентябрю он так и не запускается. Итог — минус инвестиции в неудавшийся проект, упущенная выгода и демотивация команды. А это уже критично для бизнеса», — рассказывает Максим Рябов, генеральный директор и сооснователь ИТ-вендора Goodt.
Остановка основного бизнес-процесса компании в результате сорванного проекта — еще один риск, по словам эксперта: «Пока будет идти восстановление и наладка, клиенты и партнеры могут начать думать о расторжении контракта».
Снижение конкурентоспособности компании и потеря доли рынка. Среди неочевидных на первый взгляд последствий ошибок, но не менее значимых. «Пока заказчик ПО тратит время на „разборки“ с вендором или некомпетентным интегратором — партнером вендора по внедрению продукта — конкуренты пользуются ситуацией: уводят клиентов и потихоньку завоевывают рынок», — отмечает Рамазан Салпагаров, директор по развитию платформы LDM, ЛАНИТ.
Потеря гибкости. «Необходимо также учитывать, что при выборе платформы для автоматизации бизнес-процессов, по сути, заказчик выбирает правила игры как минимум на ближайшие пять лет», — рассказывает Максим Рябов. И, если компания выбрала решение, которое сегодня ее устраивает, а возможностей развития у него недостаточно, в перспективе ей будет сложно перестроиться и адаптироваться к изменениям.
Важно отметить, что причин неудачи на проекте может быть великое множество. Нередко к провалу приводит сразу целый комплекс недоработок — и на стороне вендора, и на стороне партнера, занимающегося внедрением, и на стороне заказчика, который, согласно своей роли, должен грамотно ставить конкретные цели, управлять рисками и в идеале искать и согласовывать компромиссные варианты. Тем не менее правильный продукт от надежного вендора — основа основ, поэтому эксперты ЛАНИТ приводят ключевые критерии выбора.
На что обратить особенное внимание —
7 элементов, влияющих на выбор
1. Есть ли у вендора референсные кейсы внедрения
По словам Владимира Тарасенко, коммерческого директора «Консист Бизнес Групп», важно обратить внимание на опыт использования программного обеспечения в сегменте: «Если на программном продукте вендора партнеры реализовывали аналогичные задачи, то риски снижаются. Наличие успешных проектов внедрения говорит не только о функциональных возможностях, но и том, что продукт справляется с нагрузкой».
2. Является ли ПО вендора отчуждаемым и легко кастомизируемым
Отчуждаемое ПО обладает инструментами, которые позволяют пользователю самостоятельно — с помощью команды или партнера — адаптировать его под себя, заниматься поддержкой и развитием решения, не меняя его программный код. Наличие таких инструментов зависит от архитектуры программного продукта. В идеале решение состоит из независимых слоев: ядра, доступ к которому есть только у вендора; слоя кастомизации с доступом для интегратора и слоя Low-Code, с которым работают сотрудники на стороне клиента. В противном случае любые небольшие изменения, вносимые заказчиком в код продукта для его адаптации под бизнес-потребности компании, могут привести к некорректной работе софта в целом.
По словам Максима Рябова, возможность большой кастомизации продукта является серьезным конкурентным преимуществом. Однако заказчика должна насторожить готовность вендора буквально полностью переделать свой продукт под его потребности. В этом случае вендор превращается как бы в студию заказной разработки и фокусируется на удовлетворение всех «хотелок» заказчика, а не на запуске проекта: решение создается в моменте, и риск ошибки сильно растет.
3. Обладает ли вендор сетью профессиональных партнеров
Главная задача производителя софта — развитие продукта: расширение функционала, увеличение быстродействия, отказоустойчивости, устойчивости к рискам информационной безопасности, совершенствование интерфейса и т. п. А внедрением софта и его поддержкой у заказчика, как правило, занимаются партнеры. Если у вендора нет партнерской сети или она слабо развита, заказчику придется брать работу по обслуживанию продукта на себя. А это — увеличение штата разработчиков и отвлечение от текущих задач.
У развитой партнерской сети есть и глобальные плюсы — доступ к ресурсам, которые могут потребоваться для развития проекта, и хорошее знание специфических отраслевых потребностей бизнеса. Если вендор работает без партнеров, он черпает информацию только из собственного канала продаж в рамках пресейла и, таким образом, опирается только на собственный опыт.
Развитая партнерская сеть дает доступ к значительно большему числу клиентов. Соответственно, знание о требованиях к системе кратно увеличивается и находит отражение в стратегии развития продукта.
4. Есть ли у вендора стратегия развития продукта
«У западных вендоров всегда была дорожная карта (Roadmap) развития решений на несколько лет вперед. Им можно было восторгаться или не соглашаться, например, как когда все вендоры резко перешли в облака. Но важно признать факт — Roadmap был. Партнеры и клиенты понимали, когда заканчивается поддержка версий, когда появится новый функционал, когда будут изменения в платформе», — комментирует Владимир Тарасенко.
Наличие у вендора стратегии развития продукта — один из ключевых факторов выбора решения. При этом план должен показывать развитие не только функционала, но и «технической начинки». Будет ли меняться интерфейс, появится ли релиз, направленный на ускорение работы, есть ли в планах мобильные решения — ответы на эти вопросы влияют на выбор заказчика и делают жизненный цикл софта в компании более прогнозируемым.
5. Насколько качественную документацию заказчик может получить вместе с продуктом
При внедрении коробочного продукта важно качество сопроводительной документации от вендора. Если продукт требует кастомизации силами партнера, стоит обратить внимание на форматы документов, которые представляют внедренцы. «Итоговое решение должны сопровождать все необходимые документы, которые позволят легко подготовить новых пользователей и развивать функционал, не нарушая логику работы системы», — рассказывает Владимир Тарасенко.
6. Использует ли вендор софт, который продает
Это важный показатель того, что вендор уверен в качестве своих продуктов. Например, компании группы ЛАНИТ активно применяют платформу для управления цифровым контентом LDM или ежедневно используют продукт ТУРБО Трекинг как для планирования разработки программных решений, так и для контроля исполнения проектов.
7. Есть ли у вендора обучающие программы
Наличие обучающих курсов для пользователей продукта свидетельствует о его зрелости. Так, у всех мировых вендоров есть центры обучения и сертификации с набором готовых образовательных программ и тестов. Российские производители софта нередко возлагают задачу по обучению заказчика на партнеров в рамках проекта внедрения софта. «Мы тесно работаем с „Сетевой Академией ЛАНИТ“. Это один из старейших учебных центров в России с огромным опытом и штатом профессиональных специалистов. По нашим продуктам ТУРБО мы совместно разработали online-программу обучения, которая доступна для наших партнеров и клиентов», — комментирует Владимир Тарасенко.
Как предупредить возможные риски на старте работ — 5 шагов
Описанные выше критерии помогут компании минимизировать риски на стадии выбора вендора ПО и партнера по внедрению. Чтобы дальнейшая работа на проекте пошла слаженно, эксперты ЛАНИТ рекомендуют выполнить следующие шаги.
Шаг первый — команда
Реализует ли проект консалтинговое подразделение вендора или же внедрение ложится на плечи партнера — до старта проекта важно познакомиться с будущей командой: запросить проектные резюме, провести интервью, уточнить проектный опыт. Параллельно можно запросить информацию о ранее реализованном проекте. Часто вендор или партнер готовы организовать референсный звонок, чтобы заказчик мог поговорить с клиентами, уже внедрившими систему, обсудить с ними как нюансы работы программного обеспечения, так и ход исполнения проекта.
Шаг второй — фиксация требований
Не всегда то, что требует заказчик, есть в продукте вендора. Нужный клиенту функционал может быть в плане развития, или же вендор вообще не планирует его реализовывать.
Если партнер берется доработать решение самостоятельно под клиента, то важно четко зафиксировать объем проекта: прописать в договоре требования, которым должно соответствовать ПО, его функциональные возможности, а также этапы реализации.
Шаг третий — пилот
Важно попробовать продукт в деле, провести его тест-драйв, чтобы избежать риска одномоментного входа в большой проект с большими инвестициями. На пилоте можно не только ознакомиться с функционалом и интерфейсами системы более глубоко, но и провести выборочные нагрузочные тесты, чтобы оценить производительность решения.
«Отличный способ понять, подходит ли вам вендор, — запустить пилот. Обычно этот этап длится несколько месяцев. За это время заказчик вполне успевает понять, соответствует ли продукт ожиданиям, как он справляется с объемами данных и алгоритмами, выдерживает ли нужный уровень производительности. Плюс за время пилота можно оценить и простоту взаимодействия пользователей с системой. И понять, насколько она соответствует долгосрочной стратегии развития компании и связанным с ней бизнес-задачами», — отмечает Максим Рябов.
Рамазан Салпагаров добавляет, что некоторые заказчики проводят пилотный проект сразу с двумя-тремя вендорами, прежде чем заключить основной договор с одним из них. Каждый такой пилот оплачивается, и может показаться, что деньги тратятся впустую, но такой подход помогает на деле выбрать лучший вариант.
Шаг четвертый — «слона нужно есть по частям»
Быстрая победа (Quick Win) — распространенное понятие в ИТ. Этот подход позволяет проекту идти небольшими шагами, но с понятными промежуточными результатам. Минимизируется риск потери инвестиций, команды втягиваются в проект постепенно, при этом первые победы вдохновляют на будущий глобальный успех.
Минус этого подхода — длительность. Но при правильном планировании сроки внедрения увеличиваются неглобально, а риски значительно уменьшаются.
Шаг пятый — Waterfall или Agile
Вендор программного обеспечения может рекомендовать методологию исполнения проекта. Достаточно часто это вариации классической каскадной модели (Waterfall), которые хорошо применяются для комплексных систем, где этапы внедрения следуют один за другим.
При этом партнер может предложить внедрение по итерационной методологии Agile — она предполагает гибкость в работе с требованиями клиента, но требует масштабного тестирования, чтобы «не отвалился» ранее запущенный в промышленную эксплуатацию функционал, и большего вложения ресурсов заказчика для успешного выполнения проекта.
Наличие у партнера опыта работы с разными методологиями на программном продукте вендора — хороший знак при выборе как вендора, так и партнера.
Эти пять шагов действительно могут минимизировать риски выбора неправильного вендора.
