Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.

Библиотека материалов

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

Предыдущая Следующая
Просмотров 2247 Комментариев 0

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

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

  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. В них достаточно подробно прописаны все результаты и есть примеры документов. Советую вам поступить так же, как поступил я, когда учился проджект-менеджменту – прочтите внимательно, что должно быть сделано. Каждый раз, когда вы отказываетесь от какого-то результата, от какой-то процедуры, вы должны отдавать себе отчет в том, что этот результат или процедура где-то потом используется. Поэтому решение об отказе от каких-либо регламентов, процедур, которые предусмотрены методологией, должно приниматься с открытыми глазами: вы должны ясно понимать, что это вам, действительно, не нужно. Но, как правило, это все-таки нужно потом оказывается.

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

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


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

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

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

На втором предприятии уже отдали обучение «на откуп» проектной команде. Ипроектная команда сама провела обучение ключевых пользователей прямо на рабочих местах. А обученные пользователи потом помогли провести более расширенное обучение за две недели до старта. Здесь старт прошел более гладко. Эта практика были принята программой, и дальше успешно использовалась на других предприятиях.

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

У вас есть три способа:

  1. вы можете создать документ, который будет обязательным для всех проектов, без всяких изменений.
  2. вы можете создать документ, который проекты могут расширять, если им чего-то не хватает.
  3. вы делаете всеобъемлющий документ, на все случаи жизни, а проекты выбирают из него то, что им нужно, и получают более компактный и практически применимый документ.

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

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

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

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

Рассмотрим также подход к тестированию. Он тоже формируется на уровне программы. Логика здесь та же самая. Отчеты о статусе, таким образом, готовятся совместно разными командами. На уровне проекта рапортуют группы функциональные - допустим, проект рапортует программе, программа рапортует управляющему комитету.

Рекомендация
Каждый отчет о статусе (на любом уровне) должен укладываться в один лист. Если отчет о статусе нужно листать, то нужно его корректировать и делать более лаконичным.

Хочу обратить внимание на то, с чем я столкнулся в качестве архитектора программы. За тестирование отвечает программа. Функциональное тестирование, а также компонентное, первичное тестирование разработок, конечно, делается на уровне проекта. Но интеграционное тестирование, управление этим процессом, делается на уровне программы. Особенно когда часть функциональности уже внедрена, а часть еще нет, и вы встраиваете очередную функциональность в общее решение.

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

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

На фазе продуктивного старта и первоначальной поддержки продуктивной системы обязательный важный момент: передача всей проектной документации с уровня проекта на уровень программы. Должна быть процедура приемки результатов, потому что потом они будут использованы. Идеально, если все это будет делаться через Solution Manager – так проектная документация превращается в решение.

Примеры и выводы

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

Рекомендация
С точки зрения программных процедур и политик все должны быть равны. Должны быть какие-то очень веские основания для того, что бы делались исключения. Они должны быть ясно и четко определены, эти основания, если вы делаете какие-то исключения.

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

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

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

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

Не допускайте, чтобы в контрактах у вас было написано, что результат – обученные пользователи. Это невозможно проверить, обученные они или нет. Обучение было проведено - а они говорят: «А мы не обучены. Мы уже все забыли». И вы никак не сможете при этом привлечь к ответственности вашего подрядчика. Так как, действительно, обучение проведено, но качество обучения нельзя проверить. Как поступить правильно? Должен быть сертификат об обучении – официально выданный документ.

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

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

Это вообще хороший подход к тому, что такое «открытый вопрос». «Открытый вопрос» – это просто невыполненный пункт плана. У него может быть множество причин, и под это нужно еще свои планы составлять.

Ну, и последняя тема, к которой я обещал вернуться – это договор с консалтинговой компанией или с системным интегратором. Договор должен четко специфицировать все результаты, которые вы получаете. В нем должны быть перечислены все документы, которые вы получите от вашего консультанта, описаны все результаты, причем с приложением в виде шаблонов или образцов документов. Такой договор можно считать проработанным. Если хорошо подготовленный договор – это основа успеха, то верно и обратное: плохо подготовленный договор – это основа провала.

Я убедился в этом, когда управлял портфелем порядка 40 проектов в течение двух с лишним лет. И мы анализировали, почему часть проектов у нас «красные» - то есть неуспешные. А на тот момент у нас был массовый переход на проекты с фиксированной ценой. Мы раньше работали на условиях «time and materials», а теперь переходили на проект с фиксированной ценой, и ещ не было устоявшегося шаблона договора – все договора были разные. И вот там, где договор был подготовлен плохо, в проекте были проблемы.

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

Рекомендация
Если вы используете форму договора с фиксированной ценой, обязательно включите в договор процедуру изменения объема. Это облегчит согласование внутри компании, и к тому же эта процедура будет сразу прописана.

Если у вас нет опыта в подобных проектах и договорах, то довольно сложно работать с опытной консалтинговой компанией, которая может замечательно обосновать запрос на изменение параметров исходного договора. И так называемый договор с фиксированной ценой – это вовсе не спасение бюджета. У нас был большой опыт работы в модели, очень популярной на Западе – time and materials. На мой взгляд, это действительно хорошая модель. Если у вас в команде есть хорошие проджект-менеджеры, я бы рекомендовал использовать эту форму работы с консалтинговыми компаниями. Во-первых, она гибкая. Во-вторых, вы сразу снижаете цену на величину рисков, которые закладывают консультанты. Конечно, вы теперь несете ответственность за риски сами. Но вы можете ими легко управлять. Например, вы заключили договор, но работа консультанта вам не нравится, – вы можете в любой момент отказаться от его услуг и пригласить другого. А если у вас договор с фиксированной ценой, то будьте добры, выполняйте, его расторгнуть гораздо сложнее. Еще раз хочу подчеркнуть: хороший договор – это основа успеха.

Об авторе

Сергей Виноградов – работает в SAP с 1995 года. Сергей начал карьеру в качестве консультанта по контроллингу, затем специализировался на архитектуре решений и индустриальной экспертизе для промышленных предприятий. Сергей обладает весомым знанием особенностей бизнес процессов и решений SAP в ряде отраслей: нефтедобыча и нефтепереработка, горнодобыча, металлургия, машиностроение, энергетика, ж/д транспорт. Будучи руководителем департамента внедрения, Сергей накопил уникальный опыт руководства большими проектами, был менеджером по поддержке клиентов.

Опыт работы

  • Консультант по контроллингу – участие в более чем 20 проектах, референт семинаров AC010, AC040, AC200, AC410, AC412, AC505, AC510, AC515
  • Руководитель проектов - 5 клиентов, в том числе 3 истории успеха
  • Менеджер по поддержке клиентов – 60 клиентов
  • Консалтинг менеджер по направлению “Управленческий учет”
  • Директор по проектам, заместитель директора промышленного сектора
  • Руководитель отдела отраслевой экспертизы
  • Руководитель департамента внедрения
  • Эксперт -архитектор решений
  • Инженер на предприятии оборонной промышленности
  • Разработчик САПР печатных плат
  • Научный сотрудник МРТИ РАН
  • Главный экономист управления коммерческого банка
  • Член «Объединения контроллеров»