Сергей Виноградов

Слово «бюрократия» не вызывает позитивных эмоций, но, на самом деле, в разумных пределах она необходима. Ни один проект не может состояться, быть успешным, без некоторой доли бюрократии – а именно, без задокументированных политик ипроцедур. Однако тут возникают три вопроса:

1. Почему политики и процедуры в программах так важны?
2. Какие бывают виды политик и процедур, и как это реализовано в методологии и маршрутных картах SAP?
3. Как найти правильный баланс ответственности между программой и проектами, и какие примеры есть?

Важность политик и процедур

Итак, почему политики и процедуры так важны? Начнем с определений. Что такое «политики» и «процедуры»? Они могут принимать самые разные формы. В качестве примеров документов, определяющих ту или иную политику в организации, можно привести «политику закупок», «стратегию тестирования», «концепцию обучения», «стандарты проектной документации», – то есть те документы, в которых зафиксированы правила. Они отвечают на вопрос: что надо делать? Следующий уровень документов – это процедуры. Они объясняют, как выполнять то, что написано в политиках. Это второй уровень. Они необязательно будут называться «процедурами» – это могут быть «регламенты», «инструкции», «методики» и так далее. Но важно то, что они все описывают: как выполнять то, что написано в политиках.

Итак, еще раз: почему важны процедуры и политики? Дело в том, что, когда вы приступаете к внедрению SAP, у вас никаких таких процедур нет - им неоткуда взяться. Ведь компании не занимаются внедрением SAP, они занимаются своим бизнесом. И под это у них есть свои политики и процедуры, регламентирующие документы. Может быть, даже есть системы менеджмента качества. Но, тем не менее, вам в процессе управления программой придется организовывать работу множества людей: сотен, тысяч людей. И обойтись при этом без регламентирующих документов невозможно. Нельзя управлять, как на митинге. Вы не можете митинговать несколько лет. Вам нужно работать. Для этого нужны процедуры - и документы, на основании которых они выполняются.

Вот здесь перечислены в соответствующем стандарте процессы управления программой. Они разбиты по областям знаний и по группам процессов.

Разберем, например, управление содержанием – или, как иногда называют, корпоративным контентом. Конечно, на предприятии не может заранее быть уже разработанных процедур, как описывать содержание программы SAP. Все, что у вас есть перед началом проекта – это набор процессов. Конечно, у вас есть политика закупок, есть процедуры закупок, есть, например, политика и регламенты, которые управляют инвестиционной деятельностью. Их можно использовать, потому что, в принципе, процессы похожие. Но их нельзя использовать, не адаптируя.

Если вы будете использовать готовые политики закупок, которые предлагают наши консалтинг-партнеры по внедрению SAP, скорее всего, у вас получится «немножко неправильная» закупка. Потому что, скорее всего, вы такими закупками не занимались, и у вас процедуры настроены под закупку других вещей и других услуг. Тем не менее, очень важно посмотреть, как эти новые политики и процедуры, эти стандарты, которые вы создаете, вписываются в общую структуру документов предприятия. Нельзя приходить на предприятие со своим готовым уставом проекта – получится как по поговорке «в чужой монастырь со своим уставом» - так как в организации может быть совершенно другая культура.

С другой стороны, если программа требует что-то поменять, то, значит, нужно изменить соответствующие регламентирующие документы на предприятии. И это нужно включить в план работ. Это требует времени, согласования, утверждения.

Рассмотрим теперь, какие политики и процедуры бывают. Есть два основных вида: политики и процедуры, которые помогают двигаться, и политики и процедуры, которые запрещают. Как правило, эти два вида тесно пересекаются. Например – шаблон в Excel. Вроде бы он помогает - но, с другой стороны, вы поставили в определенном поле ограничение значений, то есть туда нельзя вводить все, что угодно, можно только определенные значения ввести. Конечно, перевес должен быть в пользу помогающих процедур – ведь запреты, как правило, не объясняют, куда же идти. Вот когда Илья Муромец подходил к камню и видел: «Налево пойдешь – суму потеряешь, направо пойдешь – коня потеряешь, прямо – смерть найдешь» – такие процедуры не дают ответа, куда же все-таки идти.

Второй важный момент: процедуры и политики должны быть краткими и понятными. Меня, например, охватывают неприятные чувства, когда ф вижу регламент, объемом в толстую книгу – понятно, что на его изучение нужен как минимум день. И при этом в нем очень сложно найти что-то конкретное, нужное. Как правило, оно находится на нескольких последних страницах.

И, наконец, очень важно понимать ключевые цели – чего планируется достигнуть с помощью преобразований. Я однозначно определяю, что внедрение SAP – это бизнес-проект и бизнес-программа. Это не IT-программа, это программа преобразования бизнеса. Система SAP служит инструментом для этого преобразования. И поэтому цель регламентов, политик и процедур, которые мы формируем в программе – обеспечить выполнение этих преобразований, установить эффективное взаимодействие всех людей, которые в них участвуют, и снизить неопределенность преобразований.

В процедурах написано, что делать. Думать не надо, беспокоиться не надо, если вы видите краткую и понятную процедуру. При этом, если необходимо какой-то процесс рассматривать детально – можно создать более подробную, детализированную процедуру, но к ней нужна краткая инструкция. Если у вас длинный документ, обязательно к нему должно быть резюме. Чтобы можно было сразу понять – что это за документ, из чего он состоит, для чего нужен. Для чего это нужно? Например, у вас в ходе программы меняется какое-то количество людей в проекте. Нужно как-то вовлечь новых людей, чтобы они сразу начинали работать по принятым в проекте правилам. Должна быть процедура приема новых членов, которая предусматривает обязательное ознакомление людей с действующими правилами, с действующими документами. И если эти документы все будут такие объемные, это процедура будет невозможна. Вместо ознакомления с большим объемом регламентов вам нужно человеку дать обзор - какие есть правила и так далее, а также ссылки на хранилище документов, куда человек может обратиться, когда ему реально потребуется та или иная процедура.

Поскольку основная цель программы – выполнить преобразование бизнеса в компании, чтобы повысить его эффективность, то политики и процедуры компании должны быть обязательно связаны с таким потоком, который называется «организационные изменения». То есть они должны рассматриваться совместно. По сути уже само формирование органов управления программой – это уже часть организационных изменений в компании.

Итак, о запрещающих и помогающих методах. Политики и процедуры должны помогать предотвращать нарушения, а не служить для наказания.

У нас в SAP-е есть богатый набор методологий и маршрутных карт, которые помогают реализовать программу. На самом деле сверху – я бы сказал так – есть методология проектирования управления корпоративной архитектурой, с чего все начинается. Собственно говоря, вот из этой архитектуры и должна вытекать программа. Вы рисуете целевую архитектуру бизнес-процессов приложений инфраструктуры, рисуете промежуточные. И потом, согласно методу проектирования корпоративной архитектуры, у вас вырисовывается программа достижения этого целевого состояния. Поэтому я вам рекомендую начинать именно с этого - с определения верхнего уровня архитектуры вашего целевого решения. Определить это надо как с точки зрения бизнеса, так и с точки зрения приложений, которые его реализуют.

Таким образом, мы переходим к внедрению. Для этого у нас есть Global ASAP - методология, которая позволяет создавать типовое решение и его развертывать. Я не буду расшифровывать сейчас фазы этих методологий. Вы сможете с ними ознакомиться, как и с маршрутными картами, используя Solution Manager. В Global ASAP мы опираемся на ASAP – сейчас эта методология модернизирована, в нее входят моделирование бизнес-процессов, методология управления бизнес-процессами и проектами PMI.

Я считаю, что это очень прогрессивный факт, и потом покажу, как с точки зрения ASAP распределяются теперь результаты. За разработку и сопровождение политик и процедур программы внедрения SAP отвечает офис управления программы SAP. Политики не находятся в зоне его прямой ответственности – их все-таки разрабатывает руководство. Но офис упралвения программы SAP должен стимулировать их появление, добиваться того, чтобы они были. Ну, и, конечно, все эти политики должны быть утверждены руководством, и в обязательном порядке все проекты должны подчиняться этим политикам и требованиям.

Задача офиса управления программой – следить за тем, чтобы они выполнялись, доводить все происходящие в них изменения до проектов и обеспечивать качество проектной документации.

Вот некоторые примеры политик и процедур:

Я хочу еще раз обратиться к нашим маршрутным картам SAP. В них достаточно подробно прописаны все результаты и есть примеры документов. Советую вам поступить так же, как поступил я, когда учился проджект-менеджменту – прочтите внимательно, что должно быть сделано. Каждый раз, когда вы отказываетесь от какого-то результата, от какой-то процедуры, вы должны отдавать себе отчет в том, что этот результат или процедура где-то потом используется. Поэтому решение об отказе от каких-либо регламентов, процедур, которые предусмотрены методологией, должно приниматься с открытыми глазами: вы должны ясно понимать, что это вам, действительно, не нужно. Но, как правило, это все-таки нужно потом оказывается.

Программа и проекты: разумный баланс

Как я уже сказал, объединение и структурирование проектов в рамках программы внедрения меняет центр ответственности. Многие вещи, которые раньше делались в единичном проекте, делаются теперь на уровне программы. В принципе, если говорить об общем распределении, то управление политиками и процедурами должно теперь осуществляться на программном уровне, а задача проектов – адаптировать эти политики и процедуры и исполнять их. Могут быть исключения, когда есть какие-то специфические проекты, которые изначально не были предусмотрены в программе, – тогда вы расширяете существующие процедуры.

Возможен другой подход: вы запускаете плотный проект, в ходе его формируете необходимые процедуры, а потом принимаете это уже как регламенты и процедуры всей программы и дальше их используете. В принципе, возможно и так. Приведу два примера.

Итак, две международные компании. В одном случае удача состояла в том, что было найдено правильное решение для стратегии обучения. Первый подход был выбран неудачно: сделали все жестко, по порядку, выделили специальных людей для обучения, подготовили материалы, за два месяца всех обучили, и так далее. К сожалению, это не сработало, потому что люди забыли к моменту старта, к моменту начала работы в системе, чему их учили. Центр жестко

Материалы для скачивания

Сергей Виноградов. Управление ИТ программами: политики и процедуры (RUS)vinogradov_academy_rus.pdf788.53 KB