Владелец процесса в проекте автоматизации — это сотрудник заказчика, который сам работает в автоматизируемом процессе или руководит теми, кто в нём работает, и отвечает за результат участка в цифрах. Он не куратор, не наблюдатель и не контактное лицо: его работа — принимать решения о том, как должно быть правильно, и делать это быстрее, чем за неделю.
Проекты внедрения встают не там, где не хватает разработчиков. Они встают на решениях: кто закрывает сделку — менеджер или руководитель отдела; что делать с заявкой без телефона; считается ли отгрузка выполненной до подписания накладной. Каждый такой вопрос выглядит мелочью, но без ответа на него нельзя написать ни строчки логики. Тридцать таких вопросов, зависших на две недели каждый, останавливают проект надёжнее любого технического сбоя.
Ниже — три роли, которые постоянно путают, реальная нагрузка владельца в часах и в деньгах, пять наблюдаемых признаков его отсутствия, список полномочий, которые передаются письменно, и два трудных случая: когда единственный возможный владелец — собственник и когда владельцем назначают ИТ-специалиста. Расчёты сделаны на модельном проекте: компания на 140 человек, автоматизация обработки входящих заявок и первичных документов, бюджет 850 000 ₽, срок 16 недель, планируемая экономия 190 000 ₽ в месяц.
Три роли, которые постоянно путают
В проекте есть спонсор, владелец процесса и куратор со стороны ИТ. Это три разных человека с тремя разными зонами решений, и попытка совместить их в одном сотруднике — самая частая организационная ошибка. Совмещение спонсора и владельца допустимо в компании до 50 человек; совмещение владельца и ИТ-куратора не работает никогда.
| Роль | Кто это в компании | Что решает | Что решать не может |
|---|---|---|---|
| Спонсор проекта | собственник или генеральный директор | бюджет, приоритет проекта среди других задач, эскалации, остановка работ | как именно должен идти процесс на участке |
| Владелец процесса | руководитель отдела или направления, чью работу автоматизируют | правила и сценарии, приоритет требований, приёмка этапа, изменения в регламенте отдела | бюджет и сроки договора |
| Куратор от ИТ | системный администратор или ИТ-директор | доступы, среды, безопасность, техническая приёмка, требования к инфраструктуре | как должен идти бизнес-процесс и что считать нормальным результатом |
| Руководитель проекта у подрядчика | сотрудник исполнителя | план работ, ресурсы, риски, формулировка вопросов с вариантами | ничего в вашем регламенте и ни одного правила вашего процесса |
Отдельно про последнюю строку. Подрядчик может предложить, как обычно бывает, и назвать цену каждого варианта — но выбирать должен заказчик. Если решения о правилах вашего процесса принимает исполнитель, вы получаете систему, построенную на его представлениях о вашей работе. Это не злой умысел: он просто закрывает дыру, потому что иначе проект стоит. Порядок ролей и приёмки в наших проектах описан на странице «Как мы работаем», и первый же пункт там — назначенный владелец со стороны заказчика.
Схема из четырёх блоков с подписанными зонами решений. Сверху «Спонсор: бюджет, приоритет, остановка работ». В центре крупно «Владелец процесса: правила, приоритет требований, приёмка этапа, регламент отдела» — к нему сходятся стрелки вопросов от блока справа «Руководитель проекта у подрядчика: план, риски, вопросы с вариантами и ценой». Слева блок «Куратор от ИТ: доступы, среды, безопасность, техническая приёмка» с пометкой «не решает, как идёт бизнес-процесс». Пунктирная рамка вокруг трёх левых блоков подписана «сторона заказчика». Чертёжный стиль, подписи по-русски.
Сколько это часов на самом деле
Главное возражение против назначения владельца — «у нас у всех и так нет времени». Оно снимается цифрами: роль стоит 4–6 часов в неделю, и эти часы предсказуемы. Ниже раскладка по видам работы для проекта в 16 недель.
| Что делает владелец | Часов в неделю | Когда |
|---|---|---|
| Статус-встреча с подрядчиком | 1 | еженедельно, все 16 недель |
| Ответы на вопросы и решения по спорным правилам | 1,5 | все 16 недель |
| Приёмка демонстраций и промежуточных результатов | 1 | с 4-й недели |
| Разговор с командой: объяснения, сбор возражений | 0,5 | с 8-й недели |
| Пиковые недели: обследование, старт пилота, приёмка этапа | до 10 | 3 недели из 16 |
Итого 13 обычных недель по 4 часа и три пиковые по 10 — 82 часа за проект, в среднем 5 часов в неделю. Час из них — статус-встреча, и это единственная позиция, которую нельзя перенести или сжать: именно на ней закрываются зависшие вопросы. Считать эти часы стоит в деньгах, потому что тогда становится видно соотношение с ценой отказа от роли.
Самая крупная строка здесь — не переделки, а недополученная экономия: проект, сдвинутый на 2,5 месяца, на эти же 2,5 месяца отодвигает весь эффект. Это единственный аргумент, который обычно работает на разговоре с собственником: час в неделю руководителя отдела стоит дешевле, чем два с половиной месяца отсрочки результата, ради которого проект и затевался.
Два столбца рядом. Левый низкий — «Участие владельца: 147 600 ₽» с подписью «82 часа за 16 недель». Правый высокий — «Отсутствие владельца: 730 000 ₽», разложенный на три части с подписями: «продление контура 45 000 ₽», «переделки 210 000 ₽», «недополученная экономия 475 000 ₽». Между столбцами подпись «почти в пять раз». Под правым столбцом стрелка «+10 недель к сроку». Единицы — рубли, все числа подписаны, стиль чертёжный.
Повестка часа: что происходит на статус-встрече
Тот самый час в неделю — единственная позиция, которую нельзя пропустить, поэтому у него должна быть жёсткая повестка. Встреча без повестки превращается в обмен статусами «работаем — хорошо», после которого зависшие вопросы остаются зависшими. Ниже раскладка на 60 минут, которой мы придерживаемся сами.
- 1Открытые вопросы, 15 минут. Список с датами постановки, сверху самые старые. По каждому — либо решение, либо имя и срок, к которому решение будет. Вопрос, который третью неделю переносится без срока, поднимается спонсору.
- 2Что сдано за неделю, 10 минут. Демонстрация на боевых данных, а не на подготовленных примерах. Владелец либо принимает результат, либо называет, что именно не так — устно, но с записью в протокол.
- 3Изменения объёма, 10 минут. Что попросили добавить с прошлой встречи, сколько это стоит по времени и деньгам, что снимается взамен. Требование, принятое без размена, отдельно помечается как сдвиг срока.
- 4Данные и доступы, 5 минут. Что подрядчик просил и не получил, кто даёт и когда. Пять минут в неделю здесь экономят те самые недели, которые потом объясняют формулировкой «ждали выгрузку».
- 5Метрики, 10 минут. С начала пилота: доля реального потока через систему, число ручных правок, время цикла. До пилота — готовность замера «до» и состояние справочников в процентах от плана.
- 6Следующая неделя, 10 минут. Что делает подрядчик, что делает заказчик, какие решения понадобятся к следующей встрече. Последний пункт даёт владельцу время подумать заранее, а не отвечать с ходу.
Протокол пишется в день встречи и состоит из трёх колонок: решение, ответственный, срок. Решение без срока решением не считается и остаётся в списке открытых вопросов. Это единственная бюрократия, которая в проекте окупается: журнал решений с датами — то, по чему через два месяца видно, где именно проект начал тормозить, и он же защищает обе стороны при разборе задержек.
Пять признаков, что владельца нет
Формально владелец обычно назначен: в договоре есть фамилия, в переписке есть адрес. Проверять надо не назначение, а поведение проекта. Пять признаков ниже наблюдаемы со стороны и не требуют ничьей оценки.
- 1Решения зависают. Заведите журнал открытых вопросов с датой постановки. Три и больше вопросов старше 10 рабочих дней — владельца нет, есть человек, который передаёт вопросы дальше и ждёт ответа так же, как подрядчик.
- 2Требования приносит каждый желающий. На встрече новые пожелания заявляют три разных человека, и ни один из них не отменяет ничего из ранее принятого. Владелец — это в том числе тот, кто говорит «не в этот проект», и в компании должен быть ровно один такой голос.
- 3Приёмку некому подписать. Этап сдан, работает, замечаний нет, но акт лежит вторую неделю, потому что «надо показать директору». Значит, полномочие приёмки не передано, и проект будет двигаться со скоростью календаря директора.
- 4На встречу ходят сменные заместители. Третья статус-встреча подряд с новым человеком означает, что ответственного нет, есть дежурство. Такие встречи начинаются с пересказа предыдущей и заканчиваются без решений.
- 5На вопрос «как правильно» отвечает подрядчик. Исполнитель предлагает вариант, заказчик соглашается, не проверив его на своей практике. Через месяц выясняется, что так не работают, и переделка оплачивается как изменение объёма.
Если хотя бы три признака из пяти держатся две недели подряд, дальше платить за разработку бессмысленно: логика, написанная на неутверждённых правилах, всё равно будет переписана. Правильное действие — остановить разработку на неделю и закрыть накопившиеся решения одним заходом. Полный набор ранних признаков по всем семи причинам провала собран в опорной статье кластера.
Полномочия, которые передают письменно
Роль владельца не работает на устной договорённости, потому что первое же спорное решение упирается в вопрос «а ты вправе это утверждать». Полномочия передаются письмом или приказом — одной страницей, до старта проекта. Минимальный набор — шесть пунктов.
- утверждать правила и сценарии процесса без повторного согласования с собственником;
- определять приоритет требований и отклонять новые с формулировкой «не в этот проект»;
- подписывать приёмку этапа по заранее записанному критерию;
- предоставлять подрядчику доступ к данным и боевым выгрузкам в согласованном объёме;
- менять регламент отдела и должностные инструкции в границах своего процесса;
- останавливать работы и выносить развилку спонсору, если проект перестал двигаться.
«На время проекта автоматизации обработки заявок владельцем процесса назначается руководитель отдела продаж. Ему передаётся право утверждать правила и сценарии, отклонять требования, подписывать приёмку этапов и изменять регламент отдела в границах процесса. Решения по вопросам проекта принимаются им в срок до 5 рабочих дней». Одна страница, подпись директора — и половина организационных рисков проекта закрыта.
Пятый пункт — про регламент — важнее, чем кажется. Автоматизация почти всегда меняет порядок работы людей: кто-то перестаёт заполнять таблицу, кто-то начинает подтверждать заявку в системе, у кого-то меняется момент передачи документа. Если владелец не вправе изменить регламент, система остаётся дополнительной нагрузкой поверх старого порядка — а это прямая дорога к системе, которой никто не пользуется.
Сравнение в две колонки. Левая — «Контактное лицо»: подписи «передаёт вопросы», «согласовывает с директором», «не подписывает приёмку», «не меняет регламент», внизу серая плашка «решение — 10 рабочих дней и дольше». Правая — «Владелец процесса»: шесть коротких строк полномочий — утверждает правила, отклоняет требования, подписывает приёмку, даёт доступ к данным, меняет регламент отдела, останавливает работы; внизу плашка «решение — до 5 рабочих дней». Чертёжный стиль, подписи по-русски.
Если единственный возможный владелец — собственник
В компаниях до 100 человек это обычная ситуация: правила процесса реально знает и меняет только собственник, а у него нет пяти часов в неделю на проект. Отказываться от проекта из-за этого не нужно — нужно перестроить работу так, чтобы решения от него требовались реже и обходились дешевле по времени.
- 1Собрать решения в один час в неделю
Не переписка по мере поступления, а один блок: подрядчик копит вопросы и приносит их пачкой на фиксированный час. Практика показывает, что 20–30 вопросов проекта закрываются за 6–8 таких часов, если их не растаскивать по дням.
- 2Приносить решения с вариантами и ценой
Не «как поступать с заявкой без телефона», а «вариант А — отклонять автоматически, ноль часов работы; вариант Б — отправлять в ручную очередь, 15 минут работы менеджера в день; рекомендуем Б». Собственнику нужно 30 секунд на такой вопрос вместо десяти минут на восстановление контекста.
- 3Ввести правило умолчания
Если ответа нет 5 рабочих дней, проект идёт по варианту, помеченному как рекомендованный, и это фиксируется в протоколе. Правило страхует от главного риска — молчания, и почти всегда ускоряет ответы: молчаливое согласие на чужой выбор мотивирует лучше напоминаний.
- 4Делегировать всё, кроме трёх вещей
За собственником остаются деньги, приёмка этапов и решения, меняющие правила бизнеса. Приёмка демонстраций, сбор возражений от команды и текущая переписка передаются заместителю — это снимает с него две трети нагрузки и оставляет 1,5–2 часа в неделю вместо пяти.
Почему ИТ-специалист не может быть владельцем бизнес-процесса
Соблазн понятен: ИТ-специалист единственный, кто разговаривает с подрядчиком на одном языке, у него уже есть доступы, он умеет читать техническое задание. Проблема в том, что он отвечает за работоспособность, а не за результат участка, — и это меняет критерий приёмки. Технически исправная система принимается как успешная независимо от того, идёт через неё работа или нет.
Дальше цепочка предсказуемая. ИТ-специалист не может изменить регламент отдела продаж и не может обязать менеджеров вести заявки в системе — у него нет таких полномочий. Он не знает, какое из двух правил обработки заявки соответствует реальной практике, потому что не работает в процессе. На спорных вопросах он выбирает то, что проще поддерживать, и это правильный выбор с его позиции и неправильный с позиции бизнеса. В итоге компания получает систему, которая работает безупречно и никем не используется, — ту самую зомби-систему, разбор которой у нас вынесен в отдельную статью.
Послушайте, как на статус-встрече формулируют результат этапа. «Интеграция работает, ошибок нет, нагрузка в норме» — это отчёт ИТ-куратора. «Через систему прошло 62 % заявок участка, менеджеры перестали дублировать в таблицу» — это отчёт владельца процесса. Если второй формулировки в проекте не звучит ни разу за две недели, владельца в нём нет, кем бы он ни был назначен по договору.
Сравнение двух карточек-отчётов о результате этапа. Левая подписана «Отчёт ИТ-куратора»: строки «интеграция работает», «ошибок нет», «нагрузка в норме», «доступы выданы». Правая подписана «Отчёт владельца процесса»: строки «через систему прошло 62 % заявок участка», «менеджеры перестали дублировать в таблицу». Под карточками общая подпись: «принимается то, что измеряется». Чертёжный стиль, подписи по-русски.
Когда проект лучше отложить
Отсутствие владельца — не повод искать подрядчика, который «сделает всё сам»: такого не бывает, а бывает подрядчик, который примет решения за вас и сдаст систему, построенную на своих догадках. Четыре ситуации, в которых мы советуем перенести проект, а не начинать его.
- Ни у кого в компании нет 4–6 часов в неделю на ближайшие три-четыре месяца. Проверять надо не на словах, а по календарю предполагаемого владельца: если там нет свободного часа в одно и то же время недели, проект встанет на второй-третьей неделе.
- Процесс делят три отдела поровну, и спонсор не готов назначить одного из руководителей главным. Коллективная ответственность за правила означает, что каждое спорное решение поднимается до собственника, и владельцем по факту становится он.
- Руководитель участка меняется в ближайшие два месяца. Новый человек не примет решения предшественника, и половина утверждённых правил будет пересмотрена. Разумнее дождаться смены и начинать с ним.
- Владелец назначен, но у него нет ни одного из шести полномочий. Это худший вариант из всех: формально роль закрыта, отчёты идут, а решения по-прежнему зависают — только теперь их зависание никому не видно.
Перенос проекта на два-три месяца ради появления владельца почти всегда дешевле, чем те же 730 000 ₽ потерь из расчёта выше. И это единственный организационный риск, который закрывается одной страницей текста и одним часом в неделю — все остальные требуют денег.
Подрядчик может собрать ваш процесс, но не может им владеть. Решение о том, как должно быть правильно, не покупается вместе с системой.
