В большой и даже не очень большой компании никак без процессов. Консалтинговое подразделение Hewlett Packard Enterprise Software занимается выстраиванием процессов в ИТ-подразделениях своих заказчиков. ITSM/ITIL, управление проектами, управление разработкой и DevOps – все эти слова. В рамках почти каждого проекта так или иначе мы проектируем и рисуем процессы.
В данной заметке мы не будем говорить о теории, поговорим больше о практике с учётом того опыта, который накопился в российском HP, теперь уже в HPE. Чтобы говорить не отвлечённо, возьмём предметную область управления ИТ-услугами – ITSM, и говоря о процессах, будем иметь в виду процессы ITIL, к примеру. На абсолютную правоту не претендуем, будем рады обсудить данную тему.
Зачем нужны процессы
Мы считаем, что процессы нужны, чтобы люди в организации одинаково понимали, что и как они должны делать. Ещё можно говорить «чтобы структурировать деятельность организации» и много других слов.
Здесь важно соблюдать разумный баланс между «структурированием» и практическим использованием людьми в работе. Проектирование (выстраивание) процесса – достаточно трудоёмкая задача, поэтому она должна иметь практический результат. У процессных документов должна быть достаточно широкая аудитория. В идеале – люди должны смотреть непосредственно в процессы и понимать, что и в каком порядке они должны делать в той или иной ситуации.
В ряде заказчиков мы наблюдаем картину, когда процессы по ряду причин (о них – чуть ниже) становятся уделом узкого круга профильных процессных специалистов. Это как раз тот случай, когда «структурирование» (околонаучная задача) преобладает над практическим использованием. А если процесс не является «настольной книгой» людей, которые в рамках этого процесса работают, то пропадает или резко уменьшается поток обратной связи от исполнителей, которые видят, что процесс нуждается в изменении (совершенствовании).
Описание бизнес-процесса в таких организациях становится вещью в себе. Люди им в работе не пользуются, им не интересно, а у профильных процессных людей тоже всё хорошо – на бумаге всё выстроено. В подобных ситуациях сильно возрастает «роль личности в истории», то есть результативность и эффективность, а также обратная связь зависят от человека, который отвечает за данный процесс.
Процессы для людей
Какими же должны быть описания бизнес-процессов, чтобы широкая аудитория могла получать от них пользу? – Достаточно простыми и практичными. Форма не должна преобладать над содержанием. Документ должен содержать информацию, необходимую и достаточную исполнителям процесса для его, собственно, исполнения.
В описании процесса есть процессные диаграммы. Их можно рисовать по-разному, в разных нотациях и с разной степенью детализации. Сравним два варианта (это не один и тот же процесс, мы про нотации сейчас поговорим)
Слева процесс в нотации swimlane (плавательный бассейн с «дорожками» для процессных ролей). Справа – в нотации EPC. У каждого варианта есть свои достоинства и недостатки. Вариант слева – менее формальный, позволяет некоторые вольности в отражении действий в рамках процесса. У варианта справа гораздо более отточенная семантика, но эта «форма» требует дополнительных трудозатрат на её прорисовку. Да, повышается формализация процесса и исключаются возможные ошибки при «структурировании» деятельности. Но диаграмма становится менее читаемой. Разумеется, есть варианты и посередине.
Мы в HPE Software Services – убеждённые сторонники первого варианта, потому как его понимание не требует практически никаких специальных навыков и знаний, всё более или менее очевидно. Это, в том числе, обеспечивает возможность понимания процесса широкой целевой аудиторией. Содержание преобладает над формой, и это, на наш взгляд, неплохо.
Целостность и непротиворечивость
Ещё одна задача – контроль процессного ландшафта в целом. Чтобы все процессы были взаимно согласованы и несильно отставали в своём развитии друг от друга. На каком-то мероприятии приводилась аналогия с домом из кирпича. Какую стену дома строить сначала, а какую потом? – Все сразу. Нельзя, чтобы одна стена была сильно выше другой. Сначала заводим углы, а потом постепенно поднимаем все стены.
Большая формализация требует больших усилий на поддержание консистентности процессных моделей, взаимное соответствие интерфейсов между процессами, единство терминологии, подходов к формированию KPI, ролевой модели и т.д.
Здесь нам тоже кажется, что лучше пожертвовать формой и детализацией, но спроектировать и прорисовать больше процессов. То есть охват важнее детальности.
Среди наших заказчиков были и остаются компании, являющиеся приверженцами как первого, так и второго подхода. Сильно и слабо заботящиеся о форме. У всех разная корпоративная культура и разные стандарты в области процессного управления. У кого-то таких стандартов нет вообще, такое тоже бывает.
Выскажу крамольную мысль, но я правда так думаю – лучше подняться в небо на достаточно простом двухместном самолётике, чем построить красивый и большой авиалайнер и не быть уверенным, взлетит эта штука или нет.
Результат рисования процессов важнее и ценнее процесса рисования процессов, если угодно.
Автор: Hewlett Packard Enterprise
