Рус 
Қаз В предыдущей части серии я напомнил о четырёх ключевых столпах, которыми управляет продакт-менеджер высшего уровня:
- Policy (Политика) – корпоративные и регуляторные правила, которым должна соответствовать бизнес-система
- People (Люди) – навыки и знания, необходимые для функционирования бизнес-системы
- Process (Процессы) – человеческие действия с технологией и без неё
- Technology (Технологии) – автоматизация, обеспечивающая работу бизнес-системы
Прошлая статья была посвящена согласованию должностных инструкций с новой бизнес-системой и роли продакт-менеджера в управлении изменениями. Теперь — о столпе «Процессы».
Что я понимаю под «процессом»?
Для выравнивания терминологии выделю три основных компонента:
- Ручные процессы (Manual processes) – выполняются полностью людьми без технологической поддержки
- Технологически поддерживаемые процессы (Technology-assisted processes) – выполняются людьми с поддержкой технологий
- Технологически автономные процессы (Technology-exclusive processes) – выполняются полностью технологиями без участия человека
При внедрении бизнес-систем технология часто оказывается в центре внимания, из-за чего другие столпы, включая процессы, получают меньше внимания.
В конечном итоге технология нужна для того, чтобы делать что-то лучше, быстрее и/или дешевле. Это инструмент для оптимизации цепочки процессов.
Чтобы бизнес-система действительно достигла заявленных выгод, все три компонента процессов должны быть учтены при анализе, проектировании и разработке.
Продакт-менеджер высшего уровня гарантирует, что ручные, поддерживаемые технологией и полностью автоматизированные процессы включены в объём работ.
На что должен обращать внимание продакт-менеджер?
- Инвентаризация процессов и их исполнителей
На этапе планирования инициативы необходимо определить существующие процессы всех трёх типов и решить, входят ли они в объём проекта.
Это следует делать совместно с определением затронутых ролей — так вы перепроверяете и список процессов, и список вовлечённых людей.
- Требования учитывают все три типа процессов
Будущее состояние начинается с требований.
Риск заключается в том, что внимание сосредотачивается исключительно на технологических требованиях. Но важно проектировать не только технологии, а и ручные процессы.
Не игнорируйте ручные требования.
- Процессы проектируются на этапе Solution Design
Если требования — это отправная точка, то проектирование процессов — это их логическое завершение.
Проект будущего состояния должен включать:
- ручные процессы
- технологически поддерживаемые процессы
- полностью автоматизированные процессы
Интеграция всех трёх компонентов в требования и дизайн повышает вероятность того, что они будут разработаны, протестированы, включены в обучение и корректно внедрены.
- Чёткое понимание перехода от текущего состояния к будущему
Существует риск механически перенести процессы из текущего состояния в будущее без анализа их целесообразности.
При работе с процессами необходимо постоянно задавать вопрос:
- переносим ли процесс без изменений?
- меняем ли его?
- или он больше не нужен?
- Разработка процессов — такая же задача, как разработка технологий
Во время разработки основное внимание обычно уделяется технологии — и это логично.
Однако если бизнес-система — это не только технология, то и разработка процессов должна быть включена в план проекта.
Продакт-менеджер совместно с проектным менеджером должен обеспечить включение разработки процессов в график проекта и управление ими так же, как технологическими задачами.
- Процессы тестируются и включаются в обучение
Пользовательское тестирование и обучение должны охватывать все столпы системы.
Пользователи должны быть уверены, что новые или изменённые процессы работают корректно и что они понимают, как выполнять свои задачи в будущем состоянии.
Даже если продакт-менеджер не проводит обучение лично, он должен обеспечить полноту и качество этого этапа.
- Обновление реестра процессов
На этапе планирования был сформирован перечень процессов в зоне проекта. Почти наверняка они изменились.
Обновление реестра процессов не должно выполняться в спешке «на выходе из проекта».
Продакт-менеджер должен обеспечить:
- документирование добавленных/изменённых/удалённых процессов
- размещение их в соответствующих хранилищах
- доступность для пользователей
- лёгкую извлекаемость для будущих проектов
Заключение
Как и в случае со столпами «Политика» и «Люди», тестирование и обучение могут формально не входить в обязанности продакт-менеджера в вашей организации.
Однако продакт-менеджер высшего уровня:
- понимает, какие работы должны быть выполнены
- контролирует качество их выполнения
- следит за тем, чтобы ничего не «выпало» из поля зрения
Именно продакт-менеджер обладает наилучшей целостной картиной бизнес-системы и способен обеспечить согласованность всех компонентов процессов.
Автор: Лонни Пачелли (Lonnie Pacelli) — эксперт с 40-летним опытом работы в Accenture и Microsoft. Признанный лидер в вопросах управления проектами и стратегического планирования.