ИТ-консалтинг: что входит в услугу и какой результат получает бизнес

Компания редко приходит с запросом «нам нужен ИТ-консалтинг». Обычно руководитель говорит: «нужна CRM», «хотим личный кабинет», «нужно внедрить ИИ» или «менеджеры слишком долго считают заказ». Но название системы ещё не описывает проблему и не доказывает, что её нужно решать разработкой.

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

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

Что такое ИТ-консалтинг простыми словами

ИТ-консалтинг — это помощь бизнесу в принятии и внедрении технологических решений. Консультант связывает четыре области:

• цель и экономика бизнеса;
• процессы и работа сотрудников;
• данные и действующие системы;
• технологии, интеграции и эксплуатация.

Результатом не обязательно становится новая программа. Иногда выгоднее изменить правило процесса, настроить существующий сервис, убрать двойной ввод или связать уже работающие системы.

Ценность консалтинга не в количестве схем и рекомендаций, а в согласованном ответе: что менять, зачем, в какой последовательности и как проверить результат.

Чем консалтинг отличается от разработки, аудита и аутсорсинга

Эти услуги могут идти последовательно, но решают разные задачи.

ИТ-консалтинг

Помогает выбрать направление и спроектировать изменение. Отправная точка — бизнес-проблема и решение, которое нужно принять.

Разработка

Создаёт конкретный продукт или функцию по согласованным требованиям. Отправная точка — выбранное решение и границы реализации.

Технический аудит

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

ИТ-аутсорсинг и поддержка

Берёт на себя регулярную эксплуатацию: обработку обращений, мониторинг, обновления, устранение ошибок и развитие.

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

Когда бизнесу нужен ИТ-консалтинг

Предпроектное обследование особенно полезно, когда решение ещё не очевидно или затрагивает несколько подразделений.

Типичные ситуации:

• компания выбирает CRM, ERP или другой основной продукт;
• один процесс проходит через сайт, таблицы, 1С и мессенджеры;
• сотрудники несколько раз вводят одни и те же данные;
• руководство не видит статус заказа или операции;
• готовая система ограничивает важный сценарий;
• планируется личный кабинет, B2B-портал или внутренний сервис;
• несколько подрядчиков дают несопоставимые предложения;
• старую систему нужно заменить без остановки работы;
• бизнес хочет внедрить ИИ, но не выбрал первую задачу;
• накопились разрозненные автоматизации без общей архитектуры;
• проект уже начинали, но требования и приоритеты меняются;
• нужно составить программу цифрового развития на несколько этапов.

Чем больше участников, систем и исключений, тем дороже ошибка раннего выбора.

Когда отдельный консалтинг не нужен

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

Отдельное обследование может быть избыточным, если:

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

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

Хороший консультант умеет сказать, когда консалтинг не нужен и можно сразу перейти к работе.

Начинайте с решения, которое предстоит принять

До интервью сформулируйте управленческий вопрос. Иначе обследование разрастается без границ.

Примеры решений:

• выбрать готовую CRM или развивать собственную;
• определить, какой участок автоматизировать первым;
• понять, нужен ли личный кабинет;
• выбрать способ интеграции сайта и 1С;
• заменить устаревшую систему поэтапно;
• определить первую версию нового сервиса;
• проверить, окупится ли автоматизация расчёта;
• решить, где ИИ даст эффект с допустимым риском.

От вопроса зависят участники, глубина анализа и итоговые материалы. Для выбора CRM важны продажи и данные клиентов; для производственного расчёта — правила, справочники, исключения и документы.

Этап 1. Установочная встреча и границы

На первой встрече команда уточняет:

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

После встречи полезно выпустить короткий паспорт обследования: цель, область, вопросы, участники, план и результат. Он защищает обе стороны от бесконечного расширения.

Этап 2. Интервью и наблюдение за реальной работой

Регламент и фактический процесс часто различаются. Поэтому недостаточно поговорить только с руководителем.

Нужно включить:

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

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

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

Этап 3. Описание процесса AS IS

Модель AS IS фиксирует текущую работу без попытки сразу сделать её красивой.

Для каждого шага описывают:

• событие запуска;
• участника;
• действие;
• данные и документ;
• используемую систему;
• правило решения;
• срок ожидания;
• результат;
• исключения;
• следующего получателя.

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

Если процесс сложный, начинайте с 10–20 реальных кейсов. Практический шаблон есть в статье как описать бизнес-процесс перед автоматизацией.

Этап 4. Карта данных и ИТ-ландшафта

Процесс нельзя автоматизировать отдельно от данных и систем.

Карта показывает:

• где создаётся каждая сущность;
• какая система является владельцем;
• кто может читать и изменять данные;
• как информация передаётся;
• где возникают копии;
• какие идентификаторы используются;
• где хранятся файлы и история;
• какие API и выгрузки доступны;
• от каких поставщиков и тарифов зависит работа;
• какие ограничения есть у текущей архитектуры.

Без этой карты команда может автоматизировать экран и оставить прежний ручной перенос за ним.

Этап 5. Проблемы, причины и цена текущего состояния

Не всякое неудобство стоит разработки. Проблемы ранжируют по влиянию.

Полезно измерить:

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

Важно отделить симптом от причины. «Менеджер долго готовит КП» может быть следствием сложной формулы, неактуального прайса, повторного ввода или пяти согласований. Каждая причина требует другого решения.

Этап 6. Проектирование процесса TO BE

Модель TO BE описывает целевую работу после изменений.

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

В целевом процессе фиксируют:

• новый порядок шагов;
• роли и владельцев;
• единый источник данных;
• автоматические правила;
• точки решения человеком;
• обработку исключений;
• контрольные события;
• показатели результата;
• работу при недоступности системы;
• переход со старой схемы.

TO BE должен пройти проверку на реальных примерах. Если типовой случай работает, а возврат, отмена или изменение заказа не описаны, модель ещё не готова.

Этап 7. Сравнение вариантов решения

ИТ-консалтинг не должен автоматически приводить к заказной разработке. Для каждой критической части сравнивают как минимум:

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

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

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

Этап 8. Экономика и полная стоимость владения

Смета первого запуска не показывает экономику решения. Полная стоимость владения включает:

• лицензии;
• настройку и внедрение;
• разработку;
• миграцию и очистку данных;
• интеграции;
• инфраструктуру;
• обучение;
• ручные обходы;
• поддержку и мониторинг;
• обновления;
• рост объёма;
• выход из продукта или передачу проекта.

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

Если эффект нельзя подтвердить заранее, проектируют ограниченный пилот с метриками.

Этап 9. Требования и границы первой версии

Требования строят от сценариев и правил, а не от списка экранов.

Для первой версии определяют:

• пользователей и роли;
• сквозные сценарии;
• обязательные данные;
• бизнес-правила;
• интеграции;
• миграцию;
• нефункциональные требования;
• безопасность;
• журналирование;
• резервное восстановление;
• критерии приёмки;
• функции, которые сознательно отложены.

Критерий приёмки должен быть наблюдаемым. «Удобная карточка» субъективна; «менеджер создаёт расчёт, меняет состав и получает актуальное КП без повторного ввода» проверяется.

Этап 10. Дорожная карта внедрения

Дорожная карта связывает инициативы с зависимостями и результатом.

Для каждого этапа фиксируют:

• цель;
• состав работ;
• владельца;
• входные условия;
• результат;
• критерии приёмки;
• риски;
• оценку срока и бюджета;
• решение о продолжении.

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

Дорожная карта должна допускать остановку или изменение курса после пилота. Это инструмент управления, а не обещание реализовать весь список независимо от результатов.

Какие документы получает заказчик

Состав зависит от вопроса, но полезный комплект обычно включает:

1. Резюме управленческого решения.
2. Границы и допущения обследования.
3. Схему процесса AS IS.
4. Схему целевого процесса TO BE.
5. Карту систем, данных и интеграций.
6. Перечень проблем с доказательствами.
7. Сравнение вариантов решения.
8. Экономические допущения и полную стоимость владения.
9. Требования к первой версии.
10. Целевую архитектуру на необходимом уровне.
11. Реестр рисков.
12. Дорожную карту.
13. Критерии приёмки и метрики.

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

Если материалы работают только вместе с устными пояснениями автора, результат слишком зависим от консультанта.

Пример: TBI Group и расчёт групповых туров

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

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

В результате данные вводятся один раз и используются в программе тура, смете, заявках поставщикам, коммерческом предложении и Excel-выгрузке. Это пример, где консалтинг и разработка идут вместе: понимание процесса определяет архитектуру продукта, а реализация проверяет модель на практике.

Как избежать конфликта интересов

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

Заказчику стоит проверить:

• рассмотрены ли варианты без разработки;
• перечислены ли ограничения каждого подхода;
• отделены ли факты от допущений;
• понятна ли экономика;
• можно ли использовать материалы с другой командой;
• описана ли минимальная первая версия;
• есть ли критерии остановки;
• получает ли клиент доступ к схемам и требованиям;
• зафиксированы ли права на результат.

Мы считаем нормальным вывод «достаточно готового сервиса» или «сначала измените процесс». Цель консультации — принять решение, а не любой ценой загрузить разработку.

Как выбрать ИТ-консультанта

Смотрите не только на отраслевой список клиентов.

Полезные признаки:

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

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

Что требуется от клиента

Консалтинг нельзя полностью делегировать внешней команде. Клиент предоставляет контекст и принимает решения.

Нужны:

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

Если ключевые участники не доступны, консультант построит красивую, но неполную модель.

Типичные ошибки ИТ-консалтинга

Собирать пожелания вместо процессов

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

Описывать всё предприятие без решения

Обследование должно иметь границы и управленческий вопрос.

Проектировать идеальный TO BE без перехода

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

Игнорировать данные

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

Считать первый релиз всем проектом

После запуска нужны поддержка, метрики и развитие.

Не проверять результат

Без критериев приёмки стороны по-разному понимают слово «готово».

Частые вопросы

Нужен ли готовый технический запрос?

Нет. Консалтинг как раз нужен, когда бизнес-задача есть, а решение и требования ещё не определены. Достаточно описать проблему, ограничения и ожидаемое изменение.

Сколько длится ИТ-консалтинг?

Зависит от границ, числа процессов, систем и участников. Локальное обследование занимает меньше времени, чем программа изменений нескольких подразделений. Срок согласуют после установочной встречи.

Может ли результатом быть отказ от разработки?

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

Чем дорожная карта отличается от сметы?

Смета оценивает выбранный объём работ. Дорожная карта объясняет последовательность инициатив, зависимости, результаты и точки принятия решения.

Можно ли заказать только обследование?

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

Что делать дальше

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

KorDevTeam проводит обследование и реализует автоматизацию бизнес-процессов — от AS IS и TO BE до интеграций и разработки. Мы показываем альтернативы, фиксируем требования и собираем дорожную карту, по которой можно принимать решения поэтапно.

Первоначальная версия материала опубликована в Telegram-канале Геннадия Короткова. Здесь она расширена до практического руководства по ИТ-консалтингу для бизнеса.