менеджер по управлению заказами

Когда слышишь ?менеджер по управлению заказами?, многие представляют себе человека, который просто передает заявки из точки А в точку Б. Банальный координатор. На деле же — это нервный узел, где сходятся логистика, финансы, производственные мощности и, что самое сложное, человеческие ожидания. Особенно остро это чувствуешь в сфере, где за цифровой трансформацией стоят реальные сроки и материалы, как в нашей компании ООО Хэнань Цзюйхэ Текнолоджи. Ведущий поставщик услуг — это не только про технологии, но и про умение эти технологии ?упаковать? в четкий, исполнимый и предсказуемый для клиента заказ.

Где начинается реальная работа: принятие заказа — это уже анализ

Первое и самое большое заблуждение — что работа начинается с получения подписанного договора. Нет. Она начинается гораздо раньше, на этапе обсуждения ТЗ. Клиент с сайта https://www.hnjhkjjt.ru приходит с запросом на автоматизацию бизнес-процессов. И моя задача как менеджера по управлению заказами — сразу же начать мысленную ?разверстку?: какие отделы компании будут задействованы, какие ресурсы, есть ли подходящие ?окна? в графике разработчиков.

Был случай: клиент просил внедрить CRM-модуль ?как можно быстрее?. Стандартный срок — 8 недель. Но в процессе обсуждения выяснилось, что ему критично провести первый тест через 3 недели к началу квартала. Если бы я просто принял заказ в работу по стандартной схеме, был бы провал. Пришлось на ходу созваниваться с тимлидом, буквально ?выкраивать? куски готовых решений из другого, почти завершенного проекта, чтобы собрать прототип. Это не прописано ни в одной инструкции, это именно та самая ?прослойка? между формальным процессом и реальностью.

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

Провалы, которые учат лучше любых курсов

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

В итоге этап проверки безопасности данных встал на неделю. Клиенту пришлось переносить запуск, что било по репутации. Вины специалиста не было — он был перегружен. Вина была в системе управления и, отчасти, в моем недопросе. Я не уточнил: ?А вы будете физически доступны на этой неделе для глубокого погружения?? С тех пор в план-график я всегда вношу не просто фамилии, а явные отметки о подтверждении доступности от самого специалиста. Это кажется мелочью, но в управлении заказами мелочей нет.

Еще один урок — опасность ?зеркального? общения. Клиент говорит на языке бизнес-задач (?нам нужно ускорить обработку заявок?), а разработчик — на языке технических спецификаций (?нужно апгрейдить API и увеличить пропускную способность?). Менеджер по управлению заказами, который дословно передает информацию, создает вакуум. Мне пришлось научиться делать ?двойной перевод?, а иногда — визуализировать процессы на простых схемах, чтобы обе стороны увидели одно и то же. Иногда для этого даже использую скриншоты интерфейсов нашего ПО с пометками — это наглядно и снимает 80% вопросов.

Инструменты vs. здравый смысл: что важнее?

Конечно, мы используем и Jira, и Битрикс24, и сложные CRM. Для ООО Хэнань Цзюйхэ Текнолоджи как IT-компании это must have. Все заказы висят там, статусы обновляются, дедлайны горят красным. Но я давно перестал верить этим системам слепо. Они показывают идеальную картинку, а жизнь — нет.

Например, система может показывать, что этап ?тестирование? идет по плану, все тикеты закрываются. Но если я не позвоню тестировщику и не спрошу: ?Как ощущения? Есть ли какие-то “затыки”, которые пока не оформил в баг-репорт??, — можно пропустить критическую проблему. Часто самые большие риски прячутся не в открытых проблемах, а в молчаливом недовольстве или усталости команды. Поэтому мой главный инструмент — не только софт, а регулярные пятиминутки в неформальной обстановке, где люди могут сказать: ?Знаешь, тут есть один нюанс…?.

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

Связь с клиентом: обещать меньше, делать больше

Золотое правило, которое я вынес — никогда не давать клиенту идеально ровный, красивый график без ?воздуха?. В начале карьеры я старался угодить, сжимая сроки. В итоге при малейшем сбое (а они всегда есть) приходилось извиняться и просить отсрочку. Это убивало доверие.

Теперь я действую иначе. Беру реалистичный срок от команды, добавляю к нему буфер (скажем, 15-20%) на непредвиденное и озвучиваю клиенту именно этот, с запасом, срок. Если мы укладываемся в изначальный реалистичный план — клиент в восторге, что все готово ?досрочно?. Если случаются проблемы — буфер спасает, и срок сдачи не страдает. Честность в оценках для менеджера по управлению заказами — это не слабость, а основной капитал.

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

Профессия в развитии: что будет дальше?

Сфера digital не стоит на месте, и роль менеджера по управлению заказами тоже меняется. Раньше достаточно было хорошо знать Excel и иметь крепкие нервы. Сейчас нужны базовые знания в IT-архитектуре, чтобы понимать, почему интеграция с Legacy-системой займет не неделю, а месяц. Нужно разбираться в основах agile, чтобы говорить на одном языке с командами разработки.

В нашей компании, например, все чаще идут проекты, где заказ — это не конкретный продукт, а непрерывный процесс улучшения. Клиент покупает не ?коробку?, а сервис. И управление таким заказом превращается в циклическую работу: собрать обратную связь, сформировать бэклог улучшений, согласовать приоритеты на следующий спринт. Это уже ближе к продукт-менеджменту.

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