Как выбрать оптимальное российское ИТ-решение: подходы, модели, этапы. Опыт компании AUXO

Михаил Лобанов руководитель направления LowCode&CRM компании AUXO

Подход к выбору решения

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

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

Эксперты AUXO разработали шкалу оценок в зависимости от степени реализации процессов внутри решения, начиная от 5, где процесс полностью реализован без каких-либо доработок и настроек, до 1 и 0, где решение только планируется к реализации либо не реализовано соответственно.

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

Подходы к сбору и концептуализации информации

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

В таких случаях используются два разных подхода с участниками аудита со стороны заказчика.

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

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

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

Модель С4

С4 — означает последовательность уровней абстракции, название которых начинается с английской буквы С, а именно Context, Container, Component, Code. Посмотрим на процесс определения стратегии с точки зрения переходов на каждый уровень.

Вначале с лицами, принимающими решения, формируем карту возможностей или перечень основных бизнес-драйверов — Context. Затем с техническими и бизнес-стейкхолдерами рассматриваем структуру конкретной бизнес-возможности, на каких процессах она может реализовываться — Container. Далее опускаемся на уровень конкретного бизнес-процесса и в тандеме с архитекторами, владельцами продукта и другими ключевыми участниками прорабатываем схему или customer-journey — Component. В самом конце, как правило, уже на этапе проекта, а не аудита, происходит финальная детализация бизнес-процесса со всеми возможными исключениями и бизнес-правилами — Code.

Подобные переходы от общего к частному актуальны и для внедрения, когда от рассмотрения всего ИТ-ландшафта (Context) переходим вначале к его отдельным элементам (Container), их межсистемному взаимодействию (Component) и в итоге к их структуре по отдельности (Code).

Модель FUSIAOLA

Другая интересная концепция по представлению общей картины необходимых изменений — модель FUSIAOLA.

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

Определить пользователей системы (буква U или Users). Для CRM это, как правило, менеджеры по продажам, их непосредственные руководители, операционный состав, полевые сотрудники, дистрибьюторы, партнеры и т.д.

Определить набор систем, которые взаимодействуют с CRM (буква S или Systems). Например, веб-сайты компании, где есть форма лидов, различные системы с каталогом продуктов, складские системы, с которыми CRM должна уметь взаимодействовать.

Определить набор необходимых интеграционных интерфейсов и интеграционных потоков (буква I или Intergartions).

Определиться со всеми необходимыми способами аутентификации (первая буква A или Autherntications), так как это может серьезно повлиять на скоуп и безопасность финального решения.

Определить структуру данных внутри будущего решения или выявить основные объекты данных (буква O или Objects), то есть названия таблиц, экранных форм, объектов, сущностей.

Если есть предпочтения по выбору вендора у клиента, то можно проработать перечень необходимых лицензий (буква L или Licences).

Обратите внимание, что по ходу взаимодействия с клиентом будет возникать ряд допущений, которые важно учитывать, как при выборе, так и при внедрении конечного решения (вторая буква A или Assumptions).

Этапы выбора ИТ-решения

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

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

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

Но стоит понимать, что несмотря на использование правильных подходов и соблюдение всех этапов, основная сложность при выборе ИТ-решения — изначальные ожидания клиента. Эксперты AUXO нивелируют риски с помощью максимально понятных критериев для сравнения решений, но иногда представления о том, как должен работать тот или иной инструмент у клиента не совпадает с реальностью. Например, когда клиент стремится получить полную копию текущего решения. Поэтому стоит прорабатывать ожидания и смотреть критически на любую реализацию, чтобы не повторять ошибки прошлого, принося с собой legacy из старого решения.