Peter Weill и Jeanne W. Ross в своей книге IT Governance отметили, что зрелость и эффективность руководства (в смысле - процесса руководства) пропорциональна тому, насколько большое количество сотрудников компании понимают принципы и механизмы принятия решений.
Проблема прозрачности в управлении, на мой взгляд, очень серьезна. Мы грешили закрытостью и кулуарностью принятия решений в советские времена, не на много улучшилась ситуация и в настоящее время, несмотря на наличие огромного количества модных лучших практик и передовых стандартов.
И действительно, если во многих организациях сегодня уже можно сравнительно легко получить ответ на вопрос: "кто имеет полномочия разрешить замену компьютера на более современный?", и для этого даже не нужно спрашивать ИТ директора, то на вопросы: "какова процедура согласования функционального требования Закзачика, кто может принять решение о возможности его реализации?" мы не всегда найдем быстрый ответ. И тут вариантов несколько: будет предложена процедура долгого согласования всего и со всеми, или кто-то возьмет на себя смелость и разрешит на свой страх и риск, или, что часто бывает, отправят в ИТ директору, тот придаст своему лицу выражение значительности, и будет в 1001-ый раз (ТЕСЯЧЕПЕРВЫЙ!!!) будет "решать как решить" эту проблему!
Так что же нужно сделать, чтобы вода перестала быть мутной? Чтобы механизм принятия решений стал прозрачнее и понятнее? Многие поняли куда я клоню? На всякий случай еще одна мысль, которая может быть не совсем очевидна.
Что такое решение? Когда нам требуется принимать решения? На мой взгляд, решение, это развилка в которой мы должны понять, по какому пути идти, делать что-то или нет, а если делать, то как? Причем решения мы чаще всего принимаем, если нам нужно поменять порядок вещей. И действительно, зачем что-то решать, если все идет по накатанным рельсам своим чередом, если не надо что-нибудь изменить? Функциональность, регламент, состояние системы, конфигурацию оборудования, бюджет и так далее, и тому подобное.

Ну вот теперь у нас, похоже, все есть, чтобы ответить на вопрос, как организовать эффективный процесс принятия решений? Я предлагаю для этого использовать механизмы, которые существуют в процессе Управления Изменениями входящего в состав Системы управления ИТ сервисами, определенной стандартом ISO20000 и описанного в ITIL. Заметьте логика принятия решений и согласования изменений очень похожи:
1. Нужно определить типы изменений и решений в зависимости от их влияния, критичности и срочности.
2. Нужно определить, кто обладает необходимыми полномочиями и компетенцией для авторизации.
3. Нужно определить, что делать, если решение или изменение срочное.
4. Нужно определить процедуры.
5. Нужно подумать, а как сделать так, чтобы все это не переросло в бюрократию и окончательно не похоронило все начинания.
6. Хорошо бы иметь возможность посмотреть, как исполнялись решения и проводились изменения.
И еще много чего.

Как мне кажется, да собственно это уже было проверено мной на практике, не нужно изобретать велосипед. Можно воспользоваться самокатом, который у нас уже есть! Можно взять все полезное, что советует ITIL в отношении управления изменениями и организовать формализованный, прозрачный, понятный всем участникам Процесс Принятия Решений.
В результате мы получим:
- Формализованную процедуру инициации принятия решения. Причем, сотрудникам не нужно будет ломать голову над тем, кто принимает решение, достаточно просто правильно оформить запрос и обратиться в существующую Единую точку входа - Service Desk.
- Четко выстроенную категоризацию типов принимаемых решений в зависимости от влияния, критичности, области и т.д.
- Формализованное определение круга сотрудников и руководителей уполномоченных согласовывать и утверждать решения.
- И изменения и решения будут согласовываться в одном потоке, одним органом. Планерку то еженедельную все проводят? Так зачем еще и CABы выдумывать лишние?
- Процедуры принятия различных видов решений: типовых, срочных, стратегических и всяких других, которые Вы определите.
- Стандартные группы сотрудников, способных реализовать решения данного типа, имеющих необходимую компетенцию и полномочия.
- Формализованную процедуру контроля исполнения решений.

А дальше, больше. Почему бы для подготовки и реализации решений не использовать процесс управления внедрением изменений (управление релизами)? Почему не использовать естественный конфликт интересов между этими двумя процессами, процессом управления изменениями и релизами? Почему не задействовать SLM для согласования процедур между различными сторонами, например?

Что в итоге? Принятие Решений станет понятным и управляемым процессом, интегрированным в Систему управления ИТ сервисами. Появится возможность использовать положительный эффект от взаимной работы нескольких процессов в системе. От их взаимного контроля.

Вот такую схему мы уже обкатали в достаточно сложных организациях. Она работает!