Со стороны заказчика в проекте автоматизации нужны пять ролей: спонсор, который принимает решение и держит приоритет; куратор, который следит за календарём и не даёт вопросам зависать; владелец процесса, который утверждает правила; предметный эксперт, который знает, как работа идёт на самом деле; и администратор доступов, который выдаёт права и поднимает тестовые контуры. В компании до 50 человек эти роли обычно закрывают три человека, а не пять — но не любые три.
Второй вопрос, который задают реже, а стоит он дороже: сколько это в часах. В модельном проекте на 12 недель получается 127 часов рабочего времени заказчика — 178 400 ₽ по полным ставкам сотрудников. Эта сумма не входит ни в одну смету подрядчика и почти никогда не попадает в расчёт окупаемости, хотя оплачивается из того же кармана.
Порядок этапов проекта мы разбирали отдельно — восемь этапов от диагностики до поддержки и то, что происходит внутри каждого. Здесь другая ось: не что происходит по неделям, а кто это делает, сколько часов у него уходит и что именно ломается, когда роль не назначена. По нашему опыту срок срывает не работа подрядчика, а недооценённое время заказчика: команда простаивает не потому, что не умеет, а потому что ждёт ответа.
Пять ролей и что ломается без каждой
Роль — это не должность, а набор полномочий. Один и тот же коммерческий директор может быть спонсором в одном проекте и владельцем процесса в другом. Важно не название в приказе, а ответ на вопрос: кто имеет право сказать «делаем так» и после этого не отменить решение через неделю.
| Роль | Кто это обычно | Главное полномочие | Часов за проект | Что ломается без неё |
|---|---|---|---|---|
| Спонсор | Собственник или генеральный директор | Решает, что проект важнее других задач, и разрешает конфликты между подразделениями | 10 | Проект проигрывает конкуренцию за время людей: все «за», никто не выделяет |
| Куратор проекта | Операционный директор, руководитель ИТ, помощник первого лица | Держит календарь и эскалирует зависшие вопросы | 18 | Вопросы висят по 10 рабочих дней, подрядчик молча переключается на другой проект |
| Владелец процесса | Руководитель отдела, который работает в этом процессе | Утверждает правила, отклоняет новые требования, подписывает приёмку этапа | 48 | Правила меняются от встречи к встрече, приёмка растягивается, растут переделки |
| Предметный эксперт | Кладовщик, бухгалтер, оператор, менеджер — тот, кто делает работу руками | Отвечает, как процесс идёт на самом деле, и ловит исключения | 39 на двоих | Система собирается по регламенту, а не по реальности; исключения всплывают после запуска |
| Администратор доступов | Системный администратор или внешний ИТ-подрядчик | Выдаёт права, поднимает тестовый контур, делает выгрузки, отзывает доступы в конце | 12 | 1–3 недели простоя на ожидании ключей API и прав в CRM |
Про владельца процесса у нас есть отдельный разбор: какие три полномочия делают его владельцем и почему ИТ-специалист не может занять эту роль. Про администратора доступов — тоже: как выдать права, ограничить их и забрать обратно без общей учётной записи «integrator» на четырёх человек. Здесь важнее то, как эти роли складываются в один календарь.
Человек, который отвечает за деньги и приоритет, но не за содержание работ. Его вклад измеряется не часами на встречах, а числом снятых блокировок: «склад выделяет вам своего человека на две недели», «до конца проекта требования по этому участку не меняем», «бюджет на второй этап подтверждён». Спонсор, который не может отдать такое распоряжение, — не спонсор, а зритель.
Схема из шести блоков. В центре блок «Проект: 12 недель». Вокруг него пять блоков-ролей со стрелками к центру, на каждой стрелке подписано полномочие и число часов: «Спонсор — приоритет и бюджет, 10 ч», «Куратор — календарь и эскалация, 18 ч», «Владелец процесса — правила и приёмка, 48 ч», «Предметный эксперт (2 чел.) — реальность и исключения, 39 ч», «Администратор доступов — права и контуры, 12 ч». Сбоку отдельный блок «Подрядчик» соединён с центром двусторонней стрелкой с подписью «вопросы — ответ 3 рабочих дня». Внизу итоговая полоса «127 часов заказчика за проект». Чертёжный стиль, подписи по-русски.
Как выбрать этих людей внутри компании
Роли обычно назначают по должностям: раз процесс складской — значит, владелец начальник склада. Иногда совпадает, часто нет. Проверять стоит не должность, а три вещи: полномочие, интерес и знание процесса руками. Ниже — вопросы, которые мы задаём на диагностике, чтобы понять, кого называть в приложении к договору.
- 1Владелец процесса: три вопроса подряд
Может ли он отменить решение своего подчинённого по этому процессу, ни с кем не согласовывая? Зависит ли его собственная оценка от результата процесса? Делал ли он эту работу руками за последние полгода? Три «да» — владелец. Одно «нет» на первом вопросе — передатчик вопросов, и проект будет идти со скоростью его руководителя.
- 2Предметный эксперт: берут среднего, а не лучшего
Лучший сотрудник — плохой источник требований. Он обходит проблемы процесса автоматически, за годы перестал их замечать и на вопрос «а что если накладная пришла без номера» отвечает «ну я тогда просто звоню». Именно это «просто звоню» и есть неописанное правило, ради которого эксперт нужен. Средний исполнитель спотыкается о такие места и рассказывает о них сам.
- 3Экспертов должно быть двое
Один человек всегда описывает свою версию процесса как единственную. Второй эксперт из того же отдела нужен не для объёма, а для расхождений: там, где двое описали одну операцию по-разному, и прячется правило, которого нет ни в одном регламенте. В модельном проекте это те самые 39 часов на двоих.
- 4Куратор: не самый свободный, а самый организованный
Куратора часто выбирают по остаточному принципу — кто меньше загружен. Работает обратный признак: берите того, у кого уже есть привычка вести календарь, протоколы и списки открытых вопросов. Восемнадцать часов за проект — это не работа, а дисциплина; человеку без такой привычки они обойдутся в сорок.
- 5Спонсор: проверяется одним распоряжением
Попросите кандидата в спонсоры сказать смежному отделу: «выделите на две недели одного человека под этот проект». Если после этой фразы человека выделили — спонсор настоящий. Если началось согласование — роль занята формально, и на первом же межотдельном конфликте проект встанет.
Часы по этапам: где на самом деле пик нагрузки
Интуиция подсказывает, что тяжелее всего заказчику в начале — когда пишут ТЗ. На практике пик приходится на пилот. Модельный проект: компания на 90 человек, автоматизируется один участок, бюджет внедрения 900 000 ₽, срок 12 недель от диагностики до запуска. Часы распределяются так.
| Этап | Спонсор | Куратор | Владелец процесса | Эксперты, двое | Администратор | Итого часов |
|---|---|---|---|---|---|---|
| Диагностика и паспорт задачи | 2 | 1 | 3 | 2 | — | 8 |
| Карта процесса и цифры «до» | 1 | 2 | 8 | 8 | 1 | 20 |
| ТЗ, смета, договор | 3 | 3 | 5 | 3 | 2 | 16 |
| Прототип на ваших данных | 2 | 3 | 7 | 4 | 3 | 19 |
| Внедрение и интеграции | — | 5 | 12 | 5 | 4 | 26 |
| Пилот на части потока | 1 | 3 | 9 | 15 | 1 | 29 |
| Запуск и обучение | 1 | 1 | 4 | 2 | 1 | 9 |
| Итого за проект | 10 | 18 | 48 | 39 | 12 | 127 |
Пилот забирает 29 часов из 127 — почти четверть. Причина в двойном контроле: две недели поток идёт и через новую систему, и через старый маршрут, и кто-то должен сверять результат. Это работа предметного эксперта, а не руководителя, поэтому у экспертов на пилоте 15 часов из их 39. Второй по тяжести этап — внедрение и интеграции, 26 часов, и здесь основная нагрузка ложится на владельца процесса: каждую неделю есть демонстрация, а после неё — решения по исключениям.
Прототип проверяет одну гипотезу на обезличенных данных до основной разработки: распознаёт ли система ваши накладные, понимает ли робот ваших клиентов. Пилот запускает уже собранную систему на части живого потока рядом со старым процессом. Слова часто используют как синонимы, и из-за этого в план попадает один этап вместо двух — мы разбирали разницу между прототипом, пилотом и MVP с ценой каждого.
Столбчатая диаграмма с накоплением по семи этапам. Ось X — этапы: диагностика, карта процесса, ТЗ и договор, прототип, внедрение, пилот, запуск. Ось Y — часы от 0 до 30. Высоты столбцов: 8, 20, 16, 19, 26, 29, 9. Внутри каждого столбца сегменты по ролям с подписями цветовой легенды: спонсор, куратор, владелец процесса, эксперты, администратор. Столбец «пилот» выделен и подписан «29 ч, из них 15 — предметные эксперты на двойном контроле». Внизу подпись «итого 127 часов за 12 недель». Чертёжный стиль, подписи по-русски.
Что эти часы стоят в деньгах
Час сотрудника считается по полной ставке, а не по окладу, делённому на 176. В полную ставку входят взносы, надбавка на премии и замещение, рабочее место, и делится всё это на фактически отработанные 146 часов в месяц — методику полного часа мы разбирали отдельно. Для модельного проекта берём 1 500 ₽/час для руководителей среднего звена, 900 ₽/час для линейных сотрудников и 2 630 ₽/час для первого лица.
В разборе этапов мы называли цифру около 125 000 ₽ — это ядро нагрузки: владелец процесса, эксперты и администратор, то есть 72 000 ₽ плюс 35 100 ₽ плюс 18 000 ₽. Полная раскладка добавляет две роли, которые обычно не считают вовсе: спонсора на 26 300 ₽ и куратора на 27 000 ₽. Именно они выглядят необязательными на старте и именно их отсутствие потом объясняют словами «проект как-то заглох».
Сумма чувствительна к ставкам. Если владелец процесса — не начальник участка за 1 500 ₽/час, а коммерческий директор за 2 500 ₽/час, только эта строка вырастает с 72 000 ₽ до 120 000 ₽, и общий счёт уходит к 226 400 ₽. Это не повод ставить владельцем самого дешёвого сотрудника: полномочий у него не будет, и часы всё равно потратит руководитель, только не на решения, а на переспрашивание. Это повод считать часы заранее и класть их в расчёт окупаемости рядом со сметой подрядчика — как мы делаем в методике расчёта окупаемости.
Горизонтальная линейчатая диаграмма из пяти полос, отсортированных по убыванию суммы: владелец процесса 72 000 ₽ (48 ч × 1 500 ₽), эксперты 35 100 ₽ (39 ч × 900 ₽), куратор 27 000 ₽ (18 ч × 1 500 ₽), спонсор 26 300 ₽ (10 ч × 2 630 ₽), администратор доступов 18 000 ₽ (12 ч × 1 500 ₽). Справа итоговая плашка «178 400 ₽ за 127 часов». Под диаграммой узкая шкала сравнения: бюджет внедрения 900 000 ₽ и надстройка 178 400 ₽ с подписью «+20 %». Чертёжный стиль, подписи по-русски.
Граница ответственности: что нельзя отдать наружу
Самая дорогая иллюзия в автоматизации звучит так: «мы отдали процесс на аутсорс, пусть подрядчик разберётся». Подрядчик действительно может разобраться в том, как процесс устроен технически. Но он не может решить, каким процесс должен быть, — не потому, что не хочет, а потому что за последствия отвечает не он.
| Вопрос | Кто отвечает | Почему именно так |
|---|---|---|
| Из каких компонентов собрана система, какие технологии и модели используются | Подрядчик | Это его профессия и его риск: смета этапа фиксирована, ошибка в оценке — его убыток |
| Как связать 1С, CRM и телефонию, где хранить данные, как считать нагрузку | Подрядчик | Архитектурное решение с понятными критериями качества и проверяемым результатом |
| Что считается срочной заявкой, кому положена скидка, когда сделка переходит на следующий этап | Заказчик, делегировать нельзя | Это правила бизнеса. Подрядчик может их записать, но утвердить может только тот, кто отвечает за выручку |
| Какие данные считать достоверными, если склад и бухгалтерия расходятся | Заказчик, делегировать нельзя | Выбор источника истины меняет отчётность и налоговую базу — это управленческое решение |
| Что делать с 10–30 % случаев, которые уходят человеку | Заказчик задаёт правило, подрядчик реализует | Полной автономности не бывает; кто разбирает исключения и в какой срок — решает компания |
| Приоритет доработок, когда бюджета хватает на две из пяти | Заказчик | Подрядчик не знает, какой из участков сейчас важнее для выручки |
| Ответственность перед клиентом и проверяющим за ошибку системы | Заказчик | Оператором персональных данных остаётесь вы, даже если систему построил и обслуживает подрядчик |
Из последней строки следует практический вывод. Подрядчик может писать регламент, готовить инструкции, предлагать формулировки — и хороший подрядчик это делает. Утверждение остаётся внутри: подпись под правилом ставит человек, который будет по нему работать и отвечать. Мы фиксируем эту границу прямо в договоре — что мы гарантируем, чего не гарантируем и что происходит, если стороны разошлись, описано на странице гарантий и рисков.
Когда заказчик просит подрядчика придумать правила процесса, происходит одно из двух. Либо подрядчик отказывается — и вы теряете две недели на возврат к тому же вопросу. Либо соглашается, пишет разумный с виду регламент, и через месяц после запуска выясняется, что в нём не учтён случай, который встречается у вас каждый вторник. Формально система работает по ТЗ, дефекта нет, а процесс сломан. Переделка оформляется допсоглашением и оплачивается заново.
Сравнение в три колонки. Левая «Делает подрядчик»: архитектура и компоненты, интеграции 1С и CRM, качество кода, сроки этапа, фиксированная смета. Центральная «Делает заказчик»: приоритет доработок, выделение людей, приёмка этапов, обучение сотрудников. Правая «Не делегируется никогда» на выделенной заливке: правила процесса, источник достоверных данных, порядок разбора исключений, ответственность перед клиентом и проверяющим. Под колонками общая подпись: «Подрядчик может записать правило. Утвердить — только тот, кто по нему работает». Чертёжный стиль, подписи по-русски.
Проект без выделенного человека: не дешевле, а длиннее
Отказ выделять людей не убирает часы — он их дробит. Те же 127 часов всё равно будут потрачены, но не блоками по два часа с подготовкой, а обрывками по 15–20 минут между другими делами. Разница не в сумме, а в том, что каждый обрывок начинается с восстановления контекста, а каждый вопрос ждёт своей очереди по несколько дней.
Механика простая. Подрядчик задаёт вопрос во вторник, ответ приходит в следующий вторник. За неделю ожидания команда переключилась на другую задачу, и на возврат нужен ещё день. Три таких вопроса подряд на одном этапе — и этап вырос на две недели, хотя ни строчки лишнего кода никто не написал. По нашей практике проект без назначенного владельца удлиняется на 4–6 недель из двенадцати, то есть на треть-половину срока.
Цену одной недели сдвига — 54 000 ₽ — мы считали в разборе сроков проекта автоматизации: это отложенная экономия плюс рабочее время команды на удержание проекта в живом состоянии. Второй круг сбора требований возникает, когда карту процесса рисовали по рассказу руководителя, а не по работе исполнителя: расхождение обнаруживается на демонстрации, и половину интервью приходится проводить заново.
Две горизонтальные ленты времени одна под другой. Верхняя «С выделенным владельцем процесса»: 12 недель, семь этапов подряд без разрывов, отметки часов заказчика блоками. Нижняя «Без выделенного человека»: 16 недель, те же семь этапов, но между ними серые вставки с подписями «ожидание ответа 5 рабочих дней», «возврат в контекст», «второй круг интервью». Справа от лент две плашки с суммами: 178 400 ₽ и 450 400 ₽. Внизу подпись «часы одинаковые — 127; разница только в том, кто их держит». Чертёжный стиль, подписи по-русски.
Совмещение ролей в компании до 50 человек
Пять отдельных людей — это норма для компании на 200–300 сотрудников. В компании на 30–50 человек ролей столько же, а людей меньше, и совмещать приходится. Некоторые пары работают хорошо, некоторые ломают проект тихо и незаметно.
| Пара ролей | Вердикт | Что важно учесть |
|---|---|---|
| Куратор + владелец процесса | Рабочая пара, самая частая | 66 часов за проект, то есть 5,5 ч/нед. Реально при условии, что человека разгрузили от другой работы, а не добавили проект сверху |
| Владелец процесса + предметный эксперт | Можно и полезно | Подходит, когда процесс живёт внутри одного отдела и руководитель сам делает часть операций. Опасно в другом: такой человек описывает процесс как надо, а не как есть |
| Спонсор + куратор | Можно до 30 человек в компании | Работает, если первое лицо действительно ведёт календарь проекта, а не подписывает счета. Иначе календаря нет ни у кого |
| Спонсор + владелец процесса | Рискованно | Первое лицо не работает в процессе руками и не знает исключений. Решения будут приниматься по представлению о процессе, а не по процессу |
| Администратор доступов + владелец процесса | Ломает проект | ИТ-специалист не отвечает за результат бизнес-процесса и не может утверждать его правила. Получается человек с ключами, но без полномочий |
| Собственник тянет все пять ролей | Ломает проект и дорого стоит | 127 часов по ставке первого лица 2 630 ₽/час — это 334 010 ₽ и почти гарантированный сдвиг: у собственника нет 10 часов в неделю подряд |
Практический минимум для компании на 30–50 человек — три человека: первое лицо в роли спонсора на 10 часов, руководитель отдела в связке «куратор плюс владелец процесса» на 66 часов и один линейный сотрудник как предметный эксперт. Доступы в такой конфигурации обычно закрывает внешний ИТ-подрядчик по 12 часам, и это нормально — при условии, что учётные записи именные, а не общая «integrator» на всех.
Матрица-сравнение из шести строк в трёх визуальных группах. Зелёная группа «Работает»: «куратор + владелец процесса — 66 ч, 5,5 ч/нед», «владелец процесса + предметный эксперт», «спонсор + куратор до 30 человек». Жёлтая группа «Рискованно»: «спонсор + владелец процесса». Красная группа «Ломает»: «администратор доступов + владелец процесса», «собственник тянет все пять ролей — 127 ч × 2 630 ₽ = 334 010 ₽». Справа врезка «минимум для 30–50 человек: 3 человека — 10 ч, 66 ч, 39 ч». Чертёжный стиль, подписи по-русски.
Что записать в договор про доступность людей
Договор на разработку обычно подробно описывает обязанности подрядчика и одной строкой — обязанности заказчика: «оказывать содействие». Эта формулировка не работает ни в переговорах, ни в споре. Ниже шесть пунктов, которые превращают содействие в проверяемое обязательство; полный разбор договора мы собрали в статье о том, что должно быть в договоре на разработку.
- 1Поимённый список ролей приложением к договору
ФИО, должность, роль в проекте, контакт и — обязательно — заместитель на случай отпуска или больничного. Роль без фамилии не назначена. Приложение обновляется допсоглашением, а не устной договорённостью на созвоне.
- 2Срок реакции на вопрос подрядчика — 3 рабочих дня
Вопрос, влияющий на ход работ, направляется в согласованный канал и получает ответ за три рабочих дня. Не ответ по существу за три дня — хотя бы дата, к которой ответ будет. Молчание дольше срока автоматически продлевает этап на время ожидания.
- 3Окно приёмки этапа — 5 рабочих дней
Заказчик проверяет результат этапа по заранее согласованным критериям и даёт либо акт, либо мотивированный отказ с перечнем замечаний. Формулировки, сроки и ловушку молчаливой приёмки мы разбирали в поэтапной приёмке в договоре.
- 4Простой по вине заказчика: как считается
Если работы остановлены из-за невыданного доступа или неполученного ответа, срок этапа сдвигается на число дней простоя, а факт фиксируется письмом в тот же день. Это защищает обе стороны: подрядчика — от штрафа за чужую задержку, заказчика — от списывания на него любых опозданий задним числом.
- 5График отпусков и замещение
Проект на 12 недель почти гарантированно накрывает чей-то отпуск. Достаточно посмотреть график до старта и записать в приложение, кто замещает владельца процесса и с какими полномочиями. Замещение без права утверждать правила — это не замещение.
- 6Право подрядчика приостановить этап
Пункт выглядит недружелюбно, но защищает заказчика лучше любого штрафа. Он делает видимой ситуацию, в которой команда работает вхолостую: вместо тихого расползания сроков вы получаете письмо «работы приостановлены, ждём три решения» и можете вмешаться на первой неделе, а не на шестой.
Схема маршрута одного вопроса из шести блоков со стрелками: «Вопрос подрядчика» → «Куратор: регистрирует и адресует, тот же день» → «Владелец процесса: решение за 3 рабочих дня». От блока владельца две ветки: верхняя «Решение принято → работы продолжаются», нижняя «Нет ответа 3 дня → эскалация спонсору». От эскалации ещё одна ветка вниз: «Нет решения 5 дней → приостановка этапа, срок сдвигается на дни простоя». Сбоку пометка «на время отпуска — назначенный заместитель с теми же полномочиями». Чертёжный стиль, подписи по-русски.
Что происходит с ролями после запуска
Проект заканчивается, а система остаётся. Часть ролей закрывается вместе с проектом, часть остаётся навсегда — и это тоже часы, которые лучше посчитать заранее, а не обнаружить через месяц после акта запуска.
| Роль | Что с ней после запуска | Часов в месяц, первые три месяца |
|---|---|---|
| Спонсор | Читает ежемесячный отчёт, решает по развитию и бюджету доработок | 1 |
| Куратор проекта | Роль закрывается вместе с проектом | 0 |
| Владелец процесса | Остаётся насовсем: смотрит метрики, задаёт приоритет доработок, утверждает изменения правил | 2 |
| Предметный эксперт | Становится первой линией: к нему идут вопросы «почему система так сделала» | 3 |
| Администратор доступов | Отзывает доступы подрядчика по чек-листу, дальше работает по заявкам | 1 |
Семь часов в месяц по тем же ставкам — это 9 830 ₽: 2 630 ₽ спонсора, 3 000 ₽ владельца процесса, 2 700 ₽ эксперта и 1 500 ₽ администратора. Через три-четыре месяца нагрузка падает примерно вдвое: вопросы «почему система так сделала» заканчиваются, остаются метрики и приоритеты. Эти часы стоит держать в голове рядом со стоимостью договора поддержки — что в него входит и зачем он нужен, разобрано на странице поддержки и в статье о том, сколько стоит поддержка.
Самая частая причина, по которой рабочая система за год превращается в мёртвую: после акта запуска владельца процесса вернули к его обычным задачам, и теперь никто не смотрит на метрики и не решает, что делать с изменившимися правилами. Через полгода сотрудники обходят систему стороной, а руководство удивляется, почему эффект пропал. Два часа в месяц — это дешевле, чем повторное внедрение.
Когда людей выделить нельзя и проект лучше отложить
Отложить проект на квартал дешевле, чем провести его без людей. В первом случае вы теряете квартал отложенной экономии. Во втором — платите полную смету, получаете систему, собранную по представлению о процессе, и потом ещё платите за переделку. Пять ситуаций, в которых мы сами предлагаем подождать.
- Сезонный пик у тех же людей. Бухгалтерия в январе, склад перед Новым годом, строительная бригада в июле. Владелец процесса физически не даст 4 часа в неделю, и это не вопрос мотивации. Проект переносится на межсезонье целиком, а не «начнём, а активную фазу сдвинем».
- Единственный носитель знания уходит. Если человек, который один знает, как считается себестоимость или почему для этого клиента другая логистика, увольняется через месяц, сначала снимают знание с него — интервью, запись, регламент, — и только потом начинают проект. Иначе вы автоматизируете догадки.
- Реорганизация или смена собственника. Пока не понятно, кто будет владеть процессом через два месяца, некому утверждать правила. Проект в такой момент не встаёт — он расползается: правила меняются вслед за расстановкой сил, и каждое изменение оплачивается.
- У процесса нет общего руководителя. Процесс размазан между тремя отделами, и каждый отвечает за свой кусок. Сначала назначается один владелец с правом решать за все три участка — приказом, а не на словах. Без этого любое спорное решение уходит на согласование к первому лицу и стоит полторы-две недели.
- Суммарно нельзя выделить 9 часов в неделю. Столько выходит в модельном проекте на 12 недель у трёх постоянных ролей: 4 часа владельца процесса, 1,5 часа куратора и 3,5 часа двух экспертов; спонсор и администратор доступов включаются разово. Если столько не набирается ни при какой перестановке, честный вывод — сузить объём до одного участка и вернуться к остальному через квартал.
Есть и шестой случай, менее очевидный: проект, в котором никто не может назвать цифру «до». Если непонятно, сколько сейчас занимает обработка заявки и сколько их в месяц, то и часы заказчика посчитать не на чем, и эффект потом не с чем сравнивать. Тогда первым шагом идёт не внедрение, а измерение процесса до внедрения — две недели работы, после которых становится видно, стоит ли вообще браться.
Подрядчика можно нанять. Владельца процесса нанять нельзя — его можно только назначить и разгрузить.
