Со стороны заказчика в проекте внедрения обязаны быть четыре роли: заказчик проекта, владелец процесса, ключевой пользователь и ответственный за доступы и данные. Это минимум, ниже которого проект не собирается, — не потому, что так принято в методологиях, а потому что каждая из четырёх принимает решения, которые подрядчик принять за компанию физически не может.
Роли — не должности. В компании из 40 человек их обычно закрывают три сотрудника, в компании из 250 — пять или шесть, и почти никогда это не выделенные люди со свободным графиком. Поэтому единственный честный способ обсуждать участие команды — не в словах «нам нужна ваша вовлечённость», а в часах и рублях: сколько времени и чьего именно уйдёт на проект и что произойдёт с графиком, если этого времени не найдётся.
Ниже — разбор на модельном проекте: 10 недель, бюджет 900 000 ₽, четыре этапа. Считаем часы по каждой роли и по каждому этапу, переводим их в деньги, показываем цену пустой роли и даём три признака, по которым формальное участие видно ещё до первой сдачи. Общую канву этапов мы разбирали отдельно в материале о том, как устроен проект внедрения — здесь смотрим на тот же проект глазами заказчика.
Четыре роли, без которых проект не собирается
Роли различаются не важностью, а типом решений. Заказчик проекта решает зачем, владелец процесса — как правильно, ключевой пользователь — как на самом деле, ответственный за доступы — откуда брать данные и кому их можно показывать. Подменить одно другим нельзя: директор не знает, как менеджер обходит поле «источник заявки», а менеджер не может решить, стоит ли ради этого поля менять регламент.
- 1Заказчик проекта — тот, кто платит и отвечает за цель
Обычно собственник или директор. Формулирует, какую задачу проект закрывает и по какому числу будет считаться успешным, утверждает бюджет и объём, разрешает конфликты между подразделениями и подписывает приёмку. Ключевое: он единственный, кто может сказать «этого делать не будем» и не получить за это возражений. Вовлечение редкое, но обязательное в точках развилки.
- 2Владелец процесса — тот, кто решает, как правильно
Руководитель подразделения, чей процесс автоматизируют. Отвечает на спорные случаи («а если клиент просит отгрузку без предоплаты?»), расставляет приоритет правок, принимает изменения и отвечает за метрику процесса после запуска. Самая нагруженная роль на проекте: без неё подрядчик каждую неделю упирается в вопрос, на который никто не отвечает. Разбор этой роли отдельно — в статье о том, кто такой владелец процесса.
- 3Ключевой пользователь — тот, кто знает, как на самом деле
Один-два практика из тех, кто работает в процессе руками: менеджер, кладовщик, оператор. Показывает реальный маршрут работы вместе с обходными путями, тестирует прототип на своих задачах, ловит несоответствия между регламентом и практикой. Его вклад не в мнении, а в фактуре: именно он говорит «а вот эти 15 % заявок приходят голосом, и их вообще нет в CRM».
- 4Ответственный за доступы и данные — тот, кто открывает двери
Чаще всего главный бухгалтер, администратор учётной системы или приходящий ИТ-специалист. Выдаёт учётные записи и права в 1С, CRM, почте и телефонии, готовит выгрузки, отвечает за то, какие поля можно передавать наружу и в каком виде. Роль кажется технической, но именно на ней проекты стоят чаще всего: доступ, который «дадут завтра», в среднем даётся через полторы недели.
Схема из пяти блоков. В центре блок «Подрядчик». Вокруг — четыре блока ролей заказчика со стрелками к центру, у каждой стрелки подпись типа решения: «Заказчик проекта → зачем и на какие деньги», «Владелец процесса → как правильно», «Ключевой пользователь → как на самом деле», «Ответственный за доступы и данные → откуда брать и кому показывать». Под каждым блоком роли мелкой подписью число часов за проект: 20, 52, 40, 28. Внизу общая подпись «Итого 140 часов за 10 недель». Чертёжный стиль, подписи по-русски.
Сколько часов это стоит на самом деле
Модель: проект на 10 недель, разбитый на четыре этапа — обследование (2 недели), проектирование и согласование (2 недели), разработка и настройка (4 недели), запуск и опытная эксплуатация (2 недели). Часы ниже — не норматив, а порядок величины по проектам такого размера. Важнее абсолютных чисел форма кривой: нагрузка на команду заказчика не равномерная, а двугорбая — пик на обследовании и второй, более высокий, на запуске.
| Роль | Обследование, 2 нед | Проектирование, 2 нед | Разработка, 4 нед | Запуск, 2 нед | Всего часов |
|---|---|---|---|---|---|
| Заказчик проекта | 3 ч/нед | 2 ч/нед | 1 ч/нед | 3 ч/нед | 20 |
| Владелец процесса | 6 ч/нед | 6 ч/нед | 3 ч/нед | 8 ч/нед | 52 |
| Ключевой пользователь | 5 ч/нед | 3 ч/нед | 2 ч/нед | 8 ч/нед | 40 |
| Ответственный за доступы и данные | 4 ч/нед | 2 ч/нед | 3 ч/нед | 2 ч/нед | 28 |
| Итого по команде | 18 ч/нед | 13 ч/нед | 9 ч/нед | 21 ч/нед | 140 |
140 часов за 10 недель — это в среднем 14 часов в неделю на всю команду заказчика. Звучит немного ровно до тех пор, пока не посмотреть, кто эти часы отдаёт. Половина приходится на людей, чей час стоит дороже всего в компании, и почти все они распределены по календарю неудобными кусками: полтора часа на разбор исключения, сорок минут на согласование формулировки, три часа на приёмку.
Ставки здесь — полная стоимость часа сотрудника для компании: оклад со взносами, отпуск и рабочее место, делённые на реально доступные часы. Час ключевого пользователя посчитан по ставке менеджера по продажам, час ответственного за доступы — по ставке бухгалтера, потому что в компаниях 20–300 человек доступы к учётной системе чаще всего держит именно он. Если у вас эти роли занимают другие люди, подставьте свои числа: арифметика не изменится, изменится только итог.
Смысл расчёта не в том, чтобы напугать. Смысл в том, что 203 232 ₽ — это реальная часть стоимости проекта, и она существует независимо от того, посчитали вы её или нет. Компании, которые её не посчитали, обычно и есть те, у кого проект «затянулся»: часы никто не выделил, люди отдавали их из остатков дня, и график поехал. Как эти вложения складываются с остальными в общую окупаемость — в отдельном разборе про расчёт окупаемости автоматизации.
Горизонтальная столбчатая диаграмма, четыре столбца с подписями часов: «Владелец процесса — 52 ч», «Ключевой пользователь — 40 ч», «Ответственный за доступы и данные — 28 ч», «Заказчик проекта — 20 ч». Справа от каждого столбца — сумма в рублях: 93 600 ₽, 36 000 ₽, 23 632 ₽, 50 000 ₽. Под диаграммой итоговая строка: «140 часов, 203 232 ₽ — 22,6 % бюджета проекта 900 000 ₽». Ось подписана «часы за 10 недель». Чертёжный стиль, подписи по-русски.
Почему заказчик и владелец процесса — не один человек
Самое частое предложение со стороны компании: «Давайте я буду и заказчиком, и владельцем процесса, я же всё знаю». В компании до 15 человек это иногда работает. Дальше — почти никогда, и ломается это по двум причинам сразу.
Первая — разная частота. Заказчику проекта нужно 1–3 часа в неделю, и он может отдать их одним куском в пятницу. Владельцу процесса нужно 6–8 часов, разбросанных по неделе мелкими решениями: подрядчик наткнулся на исключение во вторник, и ответ нужен во вторник, а не в пятницу. Совмещённая роль всегда обслуживает более редкий график, поэтому первым отваливается именно владелец процесса — а он на проекте нужен чаще всех.
Вторая — конфликт горизонта. Заказчик смотрит на проект сверху и склонен упрощать: «ну сделайте как-нибудь, потом донастроим». Владелец процесса смотрит изнутри и знает, что «как-нибудь» через месяц вернётся к нему же в виде тридцати ручных исправлений. Когда обе позиции живут в одной голове, побеждает та, которая ближе к текущему дню, — и решения принимаются в пользу скорости сдачи, а не в пользу работоспособности.
Рабочая пара для небольшой компании — заказчик проекта плюс ответственный за доступы в одном человеке (обе роли редкие и обе про разрешения) и отдельный владелец процесса. Нерабочая пара — заказчик проекта плюс владелец процесса. Если второго человека действительно нет, честнее сузить объём проекта до одного участка, чем растягивать сроки на роль, которую некому занять.
Что ломается, когда роль пустая
Пустая роль — это не «чуть медленнее». У каждой из четырёх свой характерный отказ, и по симптому обычно понятно, какая именно роль не занята.
| Пустая роль | Как это выглядит на проекте | Чем заканчивается |
|---|---|---|
| Заказчик проекта | Объём растёт: каждое подразделение добавляет «ещё маленькую доработку», отказать некому | Смета вырастает на треть, срок — вдвое, приёмку никто не подписывает |
| Владелец процесса | Спорные случаи копятся в списке вопросов, подрядчик выбирает вариант сам | Переделки после демонстрации, задержка на 3–5 недель |
| Ключевой пользователь | Систему проектируют по регламенту, а не по реальному маршруту работы | На запуске выясняется, что 15–20 % случаев в неё не помещаются |
| Ответственный за доступы и данные | Учётные записи и выгрузки приходят по одной, с задержкой в 1–2 недели каждая | Разработка идёт на выдуманных данных, ошибки всплывают на боевых |
Дороже всего обходится пустая роль владельца процесса — и парадокс в том, что именно её чаще всего оставляют незанятой, потому что «руководитель отдела и так загружен». Посчитаем на том же модельном проекте, во что обходится эта экономия.
Здесь стоит остановиться на слове «переделка». Подрядчик, не получив ответа на спорный случай, не встаёт — он принимает решение сам, потому что иначе встанет весь график. Решение это будет разумным и почти всегда неправильным, потому что инженер не знает контекста, который знает владелец процесса. Обнаруживается это на демонстрации, а исправляется уже поверх написанного кода — вот откуда берутся 36 часов на три случая.
Сравнение в две колонки. Левая «Роль занята»: 52 часа владельца процесса, 93 600 ₽, спорные случаи закрываются за 1–2 дня, срок проекта 10 недель. Правая «Роль пустая»: вопросы копятся, решения принимает подрядчик, три переделки на 108 000 ₽, повторное обучение 21 600 ₽, задержка 4 недели и 95 000 ₽ недополученной экономии, итог 224 600 ₽, срок проекта 14 недель. Внизу подпись: «Пустая роль дороже занятой в 2,4 раза». Чертёжный стиль, все подписи по-русски.
Три симптома формальной роли — видно на первой неделе
Хуже пустой роли только формально занятая: в плане работ фамилия есть, на встречах человек присутствует, а решений нет. Такое участие маскирует проблему до середины проекта, когда чинить её уже дорого. Три признака проявляются на первом же этапе.
- 1Человек пропустил две встречи подряд и не прислал замену. Один пропуск — жизнь, два подряд — сигнал, что роль не приоритетна ни для него, ни для того, кто его назначил. Обсуждать надо не с ним, а с заказчиком проекта, и обсуждать не дисциплину, а разгрузку.
- 2На вопрос об исключении звучит «как решите, так и сделаем». Это вежливая форма отказа от ответственности. Владелец процесса, который действительно владеет процессом, отвечает либо решением, либо «дайте два дня, проверю на практике» — но не передаёт выбор обратно подрядчику.
- 3Роль не может назвать метрику своего процесса. Если на вопрос «по какому числу мы поймём, что стало лучше» человек называет ощущение, а не показатель, значит, за процесс он до сих пор не отвечал. Это чинится, но чинить надо до старта разработки, а не после. Как выбирать такие метрики и как потом проверять, что системой действительно пользуются, — в материале про измерение использования системы.
Сотрудник, которого назначили в проект поверх полной загрузки и не сняли с него ни одной текущей задачи, ведёт себя ровно так, как описано выше, — и он прав. У него нет ни часов, ни полномочий что-то менять. Прежде чем менять человека, проверьте, что роль вообще была обеспечена: строка в плане, освобождённое время, право принимать решения без похода наверх.
Как оформить участие, чтобы оно случилось
Разница между «мы выделили людей» и «люди действительно работают в проекте» — в четырёх документах, ни один из которых не занимает больше страницы. Формальность здесь не бюрократия, а способ сделать часы видимыми: то, что не занесено в график, в компании из 100 человек не существует.
- 1Строка в плане работ с фамилиями. Не «команда заказчика», а четыре конкретных человека с указанием роли и часов по этапам. План работ — часть договора, и это тот случай, когда бумага защищает обе стороны: подрядчик не сможет объяснить срыв срока вашей занятостью, а вы будете видеть, где именно проект ждёт вас. Что ещё имеет смысл зафиксировать письменно, разобрано в статье о том, что должно быть в договоре на разработку.
- 2Освобождение от части текущих задач. Владельцу процесса на пиковых этапах нужно 6–8 часов в неделю — это почти рабочий день. Если его не снять с чего-то другого, он возьмёт эти часы из вечеров, а через три недели перестанет их брать. Практичный вариант: на две недели обследования и две недели запуска передать часть его текущей рутины заместителю.
- 3Право принимать решения без похода наверх. Владелец процесса должен иметь возможность сказать «делаем так» по вопросам внутри своего процесса и не согласовывать каждый ответ с директором. Границу полномочий проще всего задать суммой и сроком: решения, которые не меняют бюджет и не сдвигают срок, принимает он.
- 4Один канал и одна точка сбора вопросов. Не почта, не личные сообщения четверым, а общий список открытых вопросов с датой и ответственным. Средний проект в 10 недель порождает 40–60 таких вопросов; без общего списка половина из них задаётся дважды, а треть теряется.
Лента времени на 10 недель, разделённая на четыре этапа с подписями: «Обследование, 2 недели — 18 ч/нед», «Проектирование, 2 недели — 13 ч/нед», «Разработка и настройка, 4 недели — 9 ч/нед», «Запуск и опытная эксплуатация, 2 недели — 21 ч/нед». Над лентой — кривая суммарной недельной нагрузки команды заказчика с двумя горбами, вершины подписаны 18 и 21 час. Под каждым этапом мелко указана роль на критическом пути: обследование — ключевой пользователь, проектирование — владелец процесса, разработка — ответственный за доступы, запуск — владелец процесса. Чертёжный стиль, подписи по-русски.
Когда четырёх ролей слишком много
Схема выше рассчитана на проект, который меняет рабочий процесс людей. Есть задачи, где разворачивать полноценную команду заказчика не нужно, и настаивать на этом было бы нечестно.
- Проект короче двух недель и не трогает чужую работу. Подключение выгрузки, настройка уведомлений, разбор почты в одну папку — здесь достаточно одного человека, который отвечает и за цель, и за доступы. Четыре роли на такой задаче создадут больше согласований, чем работы.
- Компания до 15 человек. Здесь роли реально сходятся в двух людях: собственник закрывает заказчика проекта и доступы, руководитель направления — владельца процесса и ключевого пользователя. Это работает, пока собственник действительно знает практику руками, а не по отчётам.
- Замена системы без изменения процесса. Переезд с одной учётной программы на другую при сохранении маршрута работы требует ответственного за данные и одного практика на приёмку; владелец процесса нужен эпизодически, потому что правила не меняются. Порядок в данных при таком переезде важнее ролей — про это отдельный разбор о том, что делать с данными до внедрения.
- Пилот на одном участке с обратимым результатом. Если запуск можно откатить за час и он касается трёх человек, полноценная приёмка избыточна. Но как только пилот становится боевым контуром, роли надо назначать заново — и это отдельное решение, а не автоматическое продолжение.
И главное, что стоит сказать вслух до начала проекта. Если четыре роли занять некем — это не повод отказываться от автоматизации, но это повод изменить объём. Проект на один участок с одним владельцем процесса даёт результат. Проект на пять подразделений с формально назначенными людьми не даёт ничего, кроме потраченных 203 232 ₽ вашего же рабочего времени и ощущения, что автоматизация не работает.
Подрядчик может принести систему. Решения о том, как в компании должно быть правильно, он принести не может — их принимают четыре человека с вашей стороны.
