Чем на самом деле занимаются консультанты: реалистичный взгляд

Консультанты SAP настраивают, строят, тестируют и стабилизируют SAP для бизнеса. На практике основная часть их ценности возникает в середине программы. Они проясняют уплывший объём, проводят показы конфигурации, которые никто не провёл, разбирают дефекты UAT и стабилизируют работу после go-live. Функциональные консультанты отвечают за конфигурацию модулей, технические за расширения и интеграции, консультанты по программам и изменениям за поставку и принятие системы. Материал написан для руководителей, которые решают, привлекать ли внешнюю помощь, и для тех, кто рассматривает консалтинг как профессию. Если вы руководитель, таблица сигналов ниже подскажет, когда звонить. Если вы консультант, разделы о ежедневной работе покажут, из чего эта работа состоит на самом деле.

Этот вопрос возникает каждый раз, когда кто-то взвешивает внешнюю поддержку: что именно делает консультант такого, чего не можем сделать мы сами?

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

Это не упрёк внутренним командам. Так обычно и идут программы SAP. Внутренняя команда перегружена. У системного интегратора свои приоритеты. Решения копятся, объём плывёт. На шестом месяце двенадцатимесячной программы кто-то открывает журнал проблем и находит двадцать пунктов со статусом «подлежит решению», которые лежат там с третьей недели.

Обычно именно в этот момент и раздаётся звонок.

Некоторых консультантов привлекают на этапе blueprint или планирования. Многим звонят в середине проекта, нередко после двух-трёх месяцев медленного прогресса или сорванных передач. Статусы в отчётах руководящему комитету горят оранжевым. Команда работает на пределе. Прогресс медленный, и никто не может точно сказать почему.

1. ExploreВоркшопы и разрывыВоркшопы fit-to-standard, документирование разрывов
2. RealizeСборка и показыКонфигурация и расширения. В середине проекта обычно и приходят звонки о спасении
3. DeployРазбор дефектов UAT и cutoverДело в конфигурации, процессе или обучении? Решает разбор
4. HypercareСтабилизацияПервое закрытие месяца и очередь обращений

Типичные точки входа:

1. Объём уплыл. То, что утвердили в Explore, больше не совпадает с тем, над чем работает команда сборки. Требования добавлялись неформально на воркшопах, журнал изменений не вёлся, и ни у кого нет окончательного списка объёма.
2. Ключевой рабочий поток встал. Миграция данных неделями держится на одном и том же уровне ошибок, и плана улучшения нет. В UAT открывается больше дефектов, чем закрывается.
3. Дата go-live зафиксирована, а план её не поддерживает. Дату назначил совет директоров. План не сверен с реальным прогрессом. Руководитель программы знает, что траектория дату не обеспечивает, но пока не эскалировал.

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

Прояснение объёма и процессов

Иногда конфигурация верна, но процесс вокруг неё сломан. Типичная картина: команда настраивала систему по документу fit-to-standard из Explore, а бизнес-пользователи не видели конфигурацию с момента согласования. Им рассказали, что строится, но не показали.

Исправление не техническое. Это разрыв в разговоре. Задача: провести бизнес-пользователей по конфигурации до UAT и подготовить чёткий список изменений до начала тестирования.

Ничего гламурного. Вот так эта работа и выглядит.

Перевод между технической и бизнес-командами

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

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

Поддержка UAT

Приёмочное тестирование (UAT) показывает, выдерживают ли накопленные решения программы или рассыпаются. Здесь всплывают все упрощения в Explore, все неформальные добавления объёма и все тест-кейсы, написанные на уровне резюме.

Хорошая поддержка UAT означает правильный разбор дефектов: отделять пробелы конфигурации от пробелов процесса и пробелов в обучении. Это ещё и управление накалом, когда бизнес-пользователи сталкиваются с серией сбоев, подрывающих их уверенность во всей программе. Без этого каждый дефект в сессии UAT становится поводом усомниться в go-live, обычно потому, что разбор был слабым и никто не определил, что такое «готовность к go-live».

Стабилизация после go-live

Самая негламурная работа в консалтинге SAP: hypercare. Go-live состоялся, поздравительные письма разосланы, команда внедрения начала расходиться. Затем наступает первое закрытие месяца. Проводки не совпадают с форматом сверки. Производственные заказы завершаются, но не рассчитываются. Служба поддержки заполняется пользователями, которых обучили, но не подготовили к нестандартным случаям.

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

Структура работы не изменилась. Изменилось соотношение времени.

Документация в основном пишется сама. SAP Joule for Consultants, общедоступный с 2025 года, отвечает на вопросы по конфигурации из собственной базы знаний SAP, включая SAP Notes, и объясняет код ABAP. Ассистенты на базе Joule в SAP Cloud ALM составляют черновики требований и тест-кейсов по материалам воркшопов. Функциональный консультант меньше печатает документы и больше оспаривает выводы воркшопов.

Код больше проверяют, чем пишут. Ассистенты SAP для разработчиков пишут код, в том числе SAP Build Code для расширений на Java и JavaScript в SAP BTP. Технические консультанты теперь проверяют его, обеспечивают безопасность и тестируют.

На линии hypercare меньше рутинных вопросов. Joule может отвечать на рутинные вопросы вроде остатков отпуска или статуса расходов прямо в приложениях SAP, и это снимает часть нагрузки с линии hypercare. Время консультантов смещается к пробелам процессов, проблемам с основными данными и случаям, где нужен человек.

Смысл привлечения консультанта не изменился. Консультанты, освоившие эти инструменты, больше времени тратят на суждение, коммуникацию и эскалацию и меньше на работу, которую ИИ теперь делает вполне приемлемо. Описание Joule for Consultants от самой SAP достаточно точно передаёт то, что он охватывает.

Функциональные консультанты специализируются на модулях вроде FI, CO, SD, MM, PP, EWM или SuccessFactors. Они настраивают систему под бизнес-процессы и закрывают разрыв между стандартом SAP и требованиями клиента. Их ценность: глубина по модулю плюс знание бизнес-процессов.

Технические консультанты (разработчики ABAP, специалисты по SAP BTP, архитекторы интеграции, Basis) строят расширения и интеграции, которые конфигурация не покрывает. В современных программах S/4HANA принципы Clean Core переносят новые расширения на SAP BTP или выпущенные API, а для этого нужен иной набор навыков, чем для классической модификации ABAP.

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

Консультанты по управлению изменениями работают с людьми: обучение, коммуникации, вовлечение и правила управления, от которых зависит, будут ли пользователи принимать систему или обходить её.

Большим программам SAP, как правило, нужны все четыре роли. В программах среднего сегмента людей часто меньше, и они покрывают сразу несколько ролей: именно там возникают пробелы. Консалтинговые фреймворки и навыки, важные в консалтинге одинаковы для всех четырёх. Если вы консультант и прокладываете собственный маршрут через эти роли, SAPopedia описывает карьерные пути и курсы, а ERPCV помогает представить этот опыт рекрутёрам.

Самая дорогая ошибка в консалтинге: пригласить кого-то слишком поздно. Проверка рисков за четыре-шесть недель до go-live может найти критические проблемы, пока ещё есть время. Спасательная операция после неудачного cutover стоит намного дороже. К тому же идёт она под операционным давлением, в организации, потерявшей доверие к системе.

В таблице показаны сигналы и помощь, которую каждый из них требует.

Сигнал	Что это обычно значит	Какую помощь привлечь	Что должны выдать за две недели
Пункты журнала проблем открыты больше четырёх недель без даты решения	Проблема управления, а не техники	Независимый консультант по программе	Список решений с владельцами и датами
Go-live меньше чем через 60 дней, а репетиции cutover не было	Не проверенный cutover; сюрпризы на go-live нельзя исправить в реальном времени	Руководитель cutover или программы	Отрепетированный план cutover и критерии go/no-go
Владельцы бизнеса перестали приходить	UAT провалится без целенаправленного вмешательства	Руководитель по изменениям плюс функциональный лидер	Показы для ключевых пользователей и план возвращения вовлечённости
Один рабочий поток неделями держится на одном уровне ошибок	Первопричина не найдена	Специалист по этому потоку	Анализ первопричин и план исправления
Единственный взгляд на состояние программы: отчётность SI	Нет независимой проверки	Консультант на стороне клиента	Честная оценка состояния для спонсора

Чем консультанты SAP на самом деле занимаются в проекте?

Они анализируют бизнес-требования, настраивают SAP под них и закрывают разрыв между умолчаниями SAP и тем, что нужно бизнесу. В Explore они проводят воркшопы fit-to-standard и документируют разрывы. В Realize строят конфигурацию и работают с разработчиками над расширениями. В Deploy поддерживают UAT, управляют дефектами и готовят cutover. В hypercare решают проблемы после go-live. Чего нет в описаниях должностей: разбор разрывов между фазами и сохранение дисциплины поставки под давлением.

Когда организациям на самом деле нужен консультант?

Три ситуации покрывают большинство задач. Выправление программы: когда объём уплыл, рабочий поток встал или под угрозой дата go-live. Специализированная компетенция: когда у команды нет навыка по модулю или технологии, например конфигурации PP-PI или интеграции на SAP BTP. И управление: когда организация хочет независимого надзора над программой, которую ведёт системный интегратор. Ждать, пока всё ухудшится, и только тогда звонить: самая распространённая схема и самая дорогая.

Чем функциональный консультант SAP отличается от технического?

Функциональные консультанты настраивают SAP под бизнес-процессы в модулях вроде FI/CO, SD, MM, PP или EWM и напрямую работают с бизнес-пользователями над требованиями. Технические консультанты строят то, что конфигурация не покрывает: расширения ABAP и BTP, интеграции и системное администрирование через Basis. Принципы Clean Core смещают техническую работу с модификаций ABAP внутри системы в сторону расширений на BTP и выпущенных API.

Как понять, что консультант приносит пользу?

Три признака. Он выносит на поверхность допущения, которые никто не проверял, и отложенные решения, а не подтверждает уже сложившиеся мнения. Решения, которые застряли на недели, начинают приниматься. А журнал проблем сокращается потому, что исправляются первопричины, а не потому, что пункты закрывают без решения. Если журнал не становится короче несмотря на активность, проблемы системные либо исправления не доходят до причины.

В чём самая трудная часть консалтинговой работы?

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

Зачем нанимать независимого консультанта, если у клиента уже есть SI?

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