А.С. Головин

Между молотом и наковальней. Практика ведения проектов в сфере информационных технологий собственными силами в сложных условиях

2

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

Данная книга - это взгляд с позиции руководителя службы ИТ крупного предприятия, кото-рому ничего не остается, как взять руководство процессом внедрения на себя, потому что в отличие от консультантов, которые закончат проект и уйдут, он останется на предприятии и будет нести ответственность за работоспособность системы. Прошли те времена, когда все неудачи можно было свалить на консультантов, пользователей, обстоятельства. В чем сложность управления проектами по преимуществу собственными силами? Во-первых, скудость собственных человеческих ресурсов, отсутствие возможности нанять дос-таточное количество консультантов. Во-вторых – проект часто не называется проектом, счи-тается, что это обычная работа службы ИТ, поэтому нет необходимости в создании каких либо органов управления проектом. В третьих – невозможность разорвать «контракт» при невыполнении его условий заказчиком (собственным руководством). Это относится как к службам ИТ предприятий, так и к обычно создаваемым холдинговыми структурами внут-ренним («инсорсинговым») фирмам. Сложность условий состоит еще и в том, что в отличие от «внешних внедренцев», «внутрен-ние внедренцы» испытывают на себе влияние большого количества внеэкономических, лич-ностных и других факторов. В случае конфликта они же не станут подавать на заказчика (свое же руководство) в суд! В данных условиях нужно обеспечить выполнение необходимо-го и достаточного количества процедур, чтобы сохранить управляемость проектом и не по-лучить обвинений в затягивании проекта и бюрократизме.

Данная книга содержит рекомендации по ведению ИТ-проектов в условиях достаточно круп-ных предприятий в период преобразований и не устоявшихся бизнес-процессов, что считает-ся крайне нежелательным и рискованным делом. Особенность данных рекомендаций состоит в том, что изменить что либо к моменту начала проекта уже невозможно. Нужно принять эти условия как данность, а разъяснять и убеждать (руководство, пользователей) нужно было раньше, вне проекта. А сейчас, главная задача - завершить проект успешно. До сегодняшнего дня данный подход к ведению проектов не давал серьезных сбоев, несмотря на то, что не все рекомендации, имеющиеся в данной книге, применялись на всех проектах. Проекты продол-жаются, и каждый год книга пополняется новым материалом, возникают новые проблемы и находятся новые решения.

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

Книга предназначена в первую очередь для тех, кто берется (или вынужден взяться) за вне-дрение автоматизированной системы собственными силами или тех консультантов, которые не связаны при реализации проекта утвержденной (фирменной) методикой. Безусловно, про-

3

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

В содержание книги (главы 5,6,7 и приложение 7) значительный вклад внесла Н.Н. Пазухина. Я очень благодарен за ценные замечания А.С. Царькову, заместителю директора по научной работе Высшей школы экономики (Нижний Новгород), после которых книга претерпела зна-чительные изменения.

Мои благодарности и тем авторам, которых я не упомянул в ссылках. Данный материал на-капливался много лет и сейчас уже невозможно вспомнить, чьи слова и мысли оказались в тексте. Я также благодарен всем своим коллегам на себе испытывавшим те или иные методы ведения проектов. Без них данная книга не состоялась бы.

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

А.Головин, 2008, 2009 a_golovin@inbox.ru

4

Оглавление Введение........................................................................................................................................ 6 Глава 1. Определение проекта................................................................................................. 8 Глава 2. Условия ведения проектов ...................................................................................... 11 Глава 3. Механизм управления проектами........................................................................... 17 Подходы к управлению проектами ...................................................................................... 17 Организационные структуры управления проектами .......................................................... 19 Механизм управления проектами и принципы TPS ............................................................. 23

Глава 4. Психологические аспекты ведения проектов ......................................................... 27 Команда проекта .................................................................................................................... 27 Подбор команды проекта....................................................................................................... 29 Преодоление сопротивления ................................................................................................. 33 Мотивация .............................................................................................................................. 36 Материальная мотивация .................................................................................................. 37 Нематериальная мотивация............................................................................................... 39

Глава 5. Организация управления проектом ........................................................................ 40 Инициирование проекта......................................................................................................... 40 Устав проекта..................................................................................................................... 40 Команда проекта ................................................................................................................ 40

Органы управления проектом................................................................................................ 41 Управляющий Совет.......................................................................................................... 41 Методический совет .......................................................................................................... 41 Руководитель проекта........................................................................................................ 42 Координатор проекта......................................................................................................... 43 Рабочие группы.................................................................................................................. 43 Процессные рабочие группы............................................................................................. 43 Рабочая группа программно-технической поддержки ..................................................... 44 Координатор от подразделения......................................................................................... 46 Секретарь проекта ............................................................................................................. 46

Глава 6. Оперативное управление работами по проекту ..................................................... 47 Планирование работ, распределение ресурсов ..................................................................... 47 Укрупненный план проекта............................................................................................... 47 План-график этапа проекта ............................................................................................... 47 Детальный план-график .................................................................................................... 47 Организация планирования в сужбах ИТ ......................................................................... 48

Контроль хода проекта.......................................................................................................... 48 Управление изменениями ...................................................................................................... 49 Управление проблемами........................................................................................................ 49 Документирование хода проекта ........................................................................................... 49 Проектная база данных .......................................................................................................... 49

Глава 7. Стадии и этапы проекта .......................................................................................... 52 Предпроектное обследование ................................................................................................ 53 Обследование предприятия............................................................................................... 54 Описание БП «как есть».................................................................................................... 54 Выбор системы .................................................................................................................. 56 Рабочая документация этапа обследования...................................................................... 58

Техническое проектирование ................................................................................................ 58 Обучение проектной команды .......................................................................................... 59 Техническое проектирование (макетирование)................................................................ 59

Информационно-справочное обеспечение............................................................................ 60 Организация НСИ.............................................................................................................. 60 Первоначальное наполнение и выверка справочников.................................................... 60

5

Участники процесса управления справочниками ............................................................ 60 Идентификация объектов справочников .......................................................................... 62 Рабочая документация этапа проектирования.................................................................. 62

Ввод в действие ...................................................................................................................... 63 Обучение пользователей ................................................................................................... 63 Опытная эксплуатация ...................................................................................................... 63 Управление опытной эксплуатацией системы ................................................................. 65 Завершение проекта........................................................................................................... 65

Глава 8. Управление рисками................................................................................................ 66 Глава 9. Управление качеством............................................................................................. 71 Глава 10. Бизнес-процессы предприятия................................................................................ 72 Заключение ................................................................................................................................. 74 Приложения ................................................................................................................................ 76 Приложение 1. Термины и определения ............................................................................... 76 Приложение 2. Причинно-следственная диаграмма для неудачного проекта..................... 77 Приложение 3а. Состав работ и их трудоемкость в проектах по автоматизации управления финансово-хозяйственной деятельностью. ........................................................................... 87 Приложение 3б. Состав работ и их трудоемкость в проектах по автоматизации управления персоналом (включая табельный учет и расчет зарплаты)................................................... 89 Приложение 3в. Состав работ и их трудоемкость в проектах по автоматизации управления производством. ....................................................................................................................... 91 Приложение 3г. Состав работ и их трудоемкость в проектах по автоматизации управления технологической подготовкой производства. ....................................................................... 93 Приложение 4а. Процессы жизненного цикла продукции ................................................... 95 Приложение 4б. Процессы менеджмента ресурсов .............................................................. 97 Приложение 4в. Процессы ответственности руководства ................................................. 100 Приложение 5. Инструкция по обследованию предприятия.............................................. 102 Приложение 6. Пример табличной формы регламента ...................................................... 106 Приложение 7. Типовой устав проекта ............................................................................... 107

Литература ................................................................................................................................ 122

6

Введение Инвестиции в информационные технологии (ИТ) являются достаточно рискованными и на-выки ведения проектов очень важны для снижения рисков. ИТ-проекты, как правило, связа-ны с изменением системы управления, т.е. с перераспределением функций и полномочий. В таких условиях всегда есть выигравшие и проигравшие, поэтому любые перемены всегда вы-зывают как положительное, так и отрицательное отношение (до полного неприятия перемен), но безразличными не бывают никогда. Данные рекомендации не отрицают классическую теорию управления проектами (в том чис-ле и фирменные методики, например SAP/ASAP или Oracle/PJM/AIM либо стандарты ANSI PMI PMBOK®). Более того, в некоторой части, особенно в разбиении на этапы имеются сов-падения, как впрочем, и с давно известными ГОСТами. Упомянутые методики нужно рас-сматривать как некий «канон», который в необходимых случаях нужно не бояться изменять и развивать. Классическая теория управления проектами и большинство известных методик базируются на том, что для успеха проекта нужно создать определенные (благоприятные) условия. Если их создать нельзя, то согласно им лучше от проекта отказаться. И это легко сделать, если ис-полнитель – внешняя фирма. А если это внутренняя («инсорсинговая») фирма или служба АСУ предприятия и у нее нет такой возможности? В таких условиях часто не допускается превышение сроков или бюджета, мотивация не предусматривается (ведь это дело службы АСУ, а она получает за это зарплату). Именно для таких условий и предназначены данные рекомендации. Термины и определения, используемые в тексте, приведены в приложении 1.

В главе 1 приводится определение проекта и управления проектом. Даются отличия проекта от операционной деятельности.

В Главе 2 проводится анализ ситуации «когда все плохо» и даются рекомендации, как в этих условиях вести проект.

В Главе 3 описывается общий механизм управления проектами и функции его отдельных элементов в увязке с принципами «Производственной системы Тойота1»

В Главе 4 описывается психологическая атмосфера, которая создается вокруг любого проек-та, связанного с изменениями и как можно на нее повлиять. Даются рекомендации по подбо-ру команды проекта Глава 5 предлагает принципы организации ведения проектов

Глава 6 описывает оперативный уровень ведения проектов по циклу PDCA Глава 7 описывает типичный состав работ по этапам проекта. В приложении 3 приводятся типичные нормы времени на их выполнение для проектов в некоторых сферах автоматиза-ции. В приложении 5 имеется инструкция по обследованию предприятия, а в приложении 6 - возможный вариант компактной (табличной) формы регламента процесса. Глава 8 идентифицирует риски проекта на разных стадиях и предлагает меры по их сдержи-ванию. Глава 9 определяет, как достигается качество результата проекта, устанавливает минималь-ный объем выполняемых работ по управлению качеством Глава 10 предлагает типовой перечень бизнес-процессов производственного предприятия. Он может быть полезен в условиях сильного расхождения с системой менеджмента качества (СМК). Из названия процесса не всегда понятно, о чем конкретно идет речь. Поэтому в при-ложении 4 дается ориентировочный состав функций упомянутых бизнес-процессов.

1 TPS – Toyota Production System

7

Я надеюсь, что прочитав данную книгу, вы сможете:

1) Начать проект, утвердив приказом по предприятию Устав проекта (типовой Устав в приложении 7);

2) Корректно и обосновано, исключив волюнтаристский подход, выбрать систему авто-матизации (глава 7);

3) Сформировать команду проекта из не самых лучших сотрудников, избежав попадания в них деструктивных элементов, или в значительной мере нейтрализовав их (глава 4);

4) Быстро и без ошибок обследовать предприятие, не пропустив важных моментов (при-ложение 5);

5) Разработать график выполнения проекта, не пропустив важных работ (приложение 3); 6) Разработать регламенты исполнения новых процессов в компактной, но достаточной

для исполнения форме, не затратив на это слишком много времени (приложение 6); 7) Организовать поддержание баз данных системы в актуальном состоянии (глава 7)

8) Избежать многих рисков проекта, не ожидая наступления рисков, а предупреждая их (глава 8);

9) Обеспечить качество проекта минимальными средствами (глава 9).

8

Глава 1. Определение проекта Существует достаточно много определений проектов. Мы придерживается следующего: Проект – это деятельность по созданию (изменению) уникального продукта или услуги с четко определенными целями, в течение заданного периода времени при установленном бюджете. Существует другой вид деятельности - текущая (операционная) деятельность. Отличия про-ектной деятельности от текущей [4] приведены в таблице 1.

Таблица 1.Отличия управления проектной деятельностью и текущей деятельностью: Управление текущей деятельностью Управление проектом

Повторяющийся процесс или продукция Новый процесс или продукция

Воспроизводящийся процесс Однократный процесс

Несколько целей Одна цель

Однородность персонала Разнородность персонала

Имеются организационные и мотивационные системы для объединения усилий

Необходимо сформировать нужную систему взаимоотношений на период проекта

Относительная определенность результата, сро-ков, затрат

Относительная неопределенность результата, сроков, затрат

Подразделение входит в административную структуру

Подразделение (команда проекта) не входит в административную структуру

Применяются стандартные правила Отвергаются стандартные правила

Поддерживает статус-кво Разрушает статус-кво

Операционная деятельность осуществляется по известному циклу PDCA. Проектная дея-тельность осуществляется иначе. В нее добавляются еще два элемента (фазы): Инициирова-ние и Завершение проекта. Иллюстрация сказанного приведена на рис. 1.

Рис.1

Жизненный цикл проекта

Планирование

Исполнение и учет

Принятие управленче-ских решений

Контроль и анализ

A P C D

Инициирова-ние Завершение

P D C A

9

Из рисунка следует, что жизненный цикл проекта – это развернутый в линию цикл PDCA, к которому добавлены две дополнительные фазы. В PMBOK® этот цикл изображен несколько иначе, поскольку внутри жизненного цикла проекта цикл PDCA может повторяться, т.к. про-ект обычно выполняется в несколько этапов. Более того, фазы цикла расположены не после-довательно, а последовательно-параллельно. Схема на рис. 1 не воспроизводит этих нюан-сов. Она описывает принципиальные отличия проектной деятельности от операционной, а цикличность и запараллеливание работ поясняются далее в тексте.

Объединив схемы проектной и операционной деятельности, мы получим схему взаимодейст-вия этих двух процессов (рис.2). Описание элементов данной схемы приведено в таблице 2.

Рис. 2

Существует несколько определений управления проектом (менеджмента проектов). Мы при-держиваемся следующего: Управление проектом – это применение определенной методоло-гии (технологии) осуществления проекта при известных ограничениях в обеспечении ресур-сами и заданных параметрах продукта проекта. Это определение полностью соответствует схеме на рис.2. Из схемы также следует, что проект всегда уникален, поскольку даже при одной и той же решаемой задаче состав ресурсов будет всегда разный и придется подстроить методику под эти условия. Менеджмент проектов – это профессиональная деятельность (Project Management – PM), ко-торой обучают в институтах и на курсах, есть объединения и клубы профессионалов по управлению проектами, существуют органы сертификации PM. По утверждению Дж. Фил-липса [5] менеджер ИТ-проекта должен обладать качествами кинорежиссера, тренера спор-тивной команды и командира космического корабля. Как режиссеру ему придется работать со звездами, как тренеру - руководить командой, как командиру корабля – знать обо всем происходящем на борту.

Все дальнейшее изложение призвано помочь менеджеру проекта (даже если он так не назы-вается) в осуществлении своей непростой работы, находясь между «молотом» руководства, которое всегда недовольно ходом проекта и «наковальней» конечных пользователей, кото-рых заставляют делать новую и непривычную работу.

Процесс реализации проекта

Процесс операционной деятельности

Опыт и знания

Изъятие прибыли

Управление процессом

Р

М

И К

Т

Ф

В

Обеспечение ресурсами

З П

Задание на создание продукта проекта

Э

Продукт проекта

Регламенты, инструкции

АС

10

Таблица 2.Элементы процесса управления проектом. Обозна-чение

Наименова-ние

Описание

Задание на создание про-дукта проек-та.

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

Продукт про-екта

Продукт проекта – это новый продукт или услуга. Применение ин-формационных технологий чаще всего связано с изменением (совер-шенствованием) процесса управления операционной деятельностью (что можно назвать новой услугой по управлению процессом). Про-дукт проекта – это не обязательно вход другого проекта (как это изо-бражено на рис. 2). Он может быть и набором регламентов управления новым (усовершенствованным) операционным процессом (изобража-ется стрелкой сверху) или новым ресурсом, например, автоматизиро-ванной системой (изображается стрелкой снизу). Определение АС см. прил. 1

Регламент управления проектом

Это документ, определяющий методологию (технологию) осуществ-ления проекта при известных ограничениях в обеспечении ресурсами и заданных входных данных. Модифицируется для каждого проекта в виде Устава проекта. Устав определяет, каким способом мы произве-дем продукт проекта.

Научно-методические ресурсы

Это знания о том, как осуществляется автоматизируемый операцион-ный процесс, используемые при этом методические рекомендации, применяемые в данной области стандарты управления (референтные модели, лучшие практики), публикации.

Информаци-онные ресур-сы

Это информационные материалы на любом носителе: документы, ба-зы данных, стандарты предприятия, ограничительные перечни, ката-логи, справочники, Интернет.

Финансовые ресурсы

Финансы – это универсальный ресурс, который нужен для осуществ-ления самого процесса, но может быть использован и для возмещения недостатка в других ресурсах (на рис. 2 данная связь показана пункти-ром).

Временные ресурсы

Время – это единственный ресурс, который нельзя купить. Он должен быть выделен в необходимом количестве. Его отсутствие частично может быть компенсировано другими ресурсами (например, увеличе-нием численности команды проекта), но до определенного предела. Наступает момент, когда добавление ресурсов перестает себя оправ-дывать (см. также гл.6).

Кадровые ре-сурсы

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

Материально – технические ресурсы

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

Экономиче-ский эффект

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

В

К

З

П

Р

М

И

Ф

Т

Э

11

Глава 2. Условия ведения проектов В процессе изучения литературы и многочисленных публикаций по управлению проектами была составлена таблица условий, при которых авторы гарантируют успех проекта. Однако, опыт участия в различных проектах, связанных с внедрением информационных технологий, показывает, что такие условия в большинстве случаев, полностью или частично не достижи-мы. Для того, чтобы описать эти реальные ситуации и показать их отличия от идеальных мы составили таблицу 3. В ней перечислены условия, которые согласно классическим теориям управления проектами необходимы для его успеха, и к каждому их них добавлено условие – антипод. Таким образом и получились таблица 3, у которой две колонки – «Идеальные усло-вия» ведения проекта и «Экстремальные условия».

Таблица 3. Условия ведения проектов Идеальные условия Экстремальные условия

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

Необходимость изменений большинством уча-стников проекта не осознается. Подразумевает-ся, что ИТ должны быть подстроены под биз-нес, а значит - это дело службы ИТ.

У участников проекта имеется желание совершить изменения.

Желания совершить изменения у большинства участников проекта не наблюдается

Участники проекта знают, как можно реа-лизовать изменения

У персонала функциональных подразделений отсутствуют знания того, как можно реализо-вать изменения

Существуют средства закрепления изме-нений (в виде новых правил – регламен-тов, стандартов, инструкций).

Способность закрепить изменения (соблюдать новые правила – регламенты, стандарты, инст-рукции) отсутствует

Персонал готов к приобретению новых знаний и навыков, изменению стиля рабо-ты

Персонал в целом не готов (не способен) к при-обретению новых знаний и навыков, изменению стиля работы

Заказчик и консультант одинаково пони-мают цели и задачи проекта

Неоднозначное понимание заказчиком и кон-сультантом целей и задач проекта

Существует системный поход к проекту Подразделения компании пытаются решить свои частные задачи вне связи с общим процес-сом

В рабочих группах проекта присутствует командный дух

Сотрудники не готовы объединиться в команду

Применяются современные методы пла-нирования проекта, имеются специалисты по управлению проектами

Имеются серьезные ошибки планирования и не-эффективная координация работ, специалисты по управлению проектами отсутствуют

Сроки проекта строго выполняются, по окончании этапа происходит переплани-рование оставшейся части

Сроки выполнения работ могут быть сорваны, механизм корректировки сроков отсутствует, практикуется наказание участников проекта за срыв сроков

Бюджет соблюдается, своевременно про-водится изменение параметров бюджета

Бюджет превышается, механизм корректировки бюджета отсутствует, практикуется наказание участников проекта за превышение бюджета

Рабочая группа сформирована из самых способных и энергичных руководителей и ведущих специалистов подразделений

В рабочую группу вошли те, кого руководите-лям подразделений не жалко было отдать и от кого мало что зависит

Цели проекта и автоматизируемых под-разделений совпадают

Цели проекта и автоматизируемых подразделе-ний не совпадают

Проектные руководители и руководители функциональных подразделений находят взаимопонимание и действуют сообща

Директивы от двух начальников - функцио-нального и проектного не соответсвуют друг другу

12

Идеальные условия Экстремальные условия Высшее руководство одобряет и реально поддерживает проект

Высшее руководство в принципе понимает не-обходимость реализации проекта, но реально не оказывает ему поддержки и не интересуется хо-дом проекта

Руководитель проекта заинтересован в ре-зультате и лично активно участвует в про-екте

Руководитель назначен формально (по должно-сти) и лично не заинтересован в результате, ог-раничивается редкими совещаниями и сбором отчетов

Проект идет на стабильном предприятии, где бизнес-процессы устоялись

Бизнес-процессы на предприятии не устоялись, возможна смена руководства, которое иначе понимает цели и задачи проекта

Требования к ИТ-системе обдуманы, ста-бильны, зафиксированы и от них не от-ступают

Требования к ИТ-системе постоянно меняются, зафиксированные требования мало что значат

Коммуникации в проекте отлажены, идет заинтересованное общение, информация по проекту доступна

Коммуникации в проекте затруднены, общение эпизодическое, информация по проекту разроз-нена и находится у отдельных лиц

Имеется сильная мотивация на успешное выполнение проекта

Слабая мотивация участников проекта (матери-альная и нематериальная)

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

Для того, чтобы попытаться найти решения означенных проблем, таблица 3 была проанали-зирована с помощью метода «Пять почему» из арсенала TPS. Этот метод предусматривает задание последовательных вопросов «Почему?», чтобы добраться до истинных причин, а не причин, лежащих на поверхности, которые часто являются не причиной, а следствием. И действительно одни из условий впоследствии оказались следствием других. Окончательная причинно-следственная диаграмма получилась очень большой и очень запутанной, поэтому для целей публикации ее пришлось разбить на части, опустив «слабые» связи и соединив ра-зорванные связи «соединителями».

Для демонстрации упомянутого метода на рис. 3 приведены причины первых трех уровней. Полностью, со всеми промежуточными «почему», диаграмма приведена в приложении 2. Что можно сказать о диаграмме? Сначала она резко расширяется (отношения «один ко многим»), но к пятому уровню стабилизируется и даже сужается (отношения «многие к одному»). Это означает, что мы приблизились к действительным причинам. Теперь нужно постараться дать рекомендации по их устранению или ослаблению. Эти рекомендации приведены на рис. «Ж» – «К» приложения 2.Часть из этих рекомендаций не является новостью и, вероятно, многими применяется. Но их все равно нужно указать, поскольку теперь понятны их корни.

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

13

Рис. 3

Проект внедре-ния АС потер-пит неудачу

Руководство в прин-ципе понимает необ-ходимость реализа-ции проекта, но реально не оказывает ему поддержки

1

Руководитель проекта лично не заинтересован в результате

Отсутствует системный подход к проекту. Проект рассматривается вне связи с общей концепцией автоматизации.

Руководство не связывает проект с оптимиза-цией системы управления и считает, что ин-форматизация - это дело службы ИТ

Руководство не доверяет решениям, предла-гаемым собственными службами ИТ

Руководство не считает задачу сложной, не видит проблем ее формализации и реализации

2

3

Цели руководства и автоматизируемых подраз-делений не совпадают

Желания совершить изменения при реа-лизации проекта у большинства участ-ников проекта не наблюдается

6

Сотрудники не готовы объединиться в команду

Сроки выполнения работ не выдерживаются. Бюджет проекта превышается

Проект продвигает-ся, но с большими трудностями

Директивы от двух начальников - функ-ционального и про-ектного противоречат друг другу

Заказчики и консультанты неоднозначно пони-мают цели и задачи проекта

Имеет место неэффективная координация работ по проекту

Персонал в целом не готов (не способен) к приобретению новых знаний и навыков, изме-нению стиля работы

Способность закре-пить изменения (соблюдать новые правила) отсутствует

Люди не считают, что информация является ценнейшим ресурсом, они его владельцы, и у них есть обязательства по отношению к ней

Низкая исполнительская дисциплина - разрабо-танные регламенты не выполняются в связи с отсутствием контроля.

У заказчика существуют технические сложно-сти (сеть, рабочие места)

3

6

I II III

Руководство недовольно неспособностью службы ИТ оперативно решать насущные задачи

Заказчик не оплачивает выполненные работы

14

Таблица 4. Рекомендации по воздействию на причины проблем Этап Содержание работ Рекомендации

Создание условий для автоматизации

1. Разработать и утвердить концепцию автоматизации предприятия (холдинга)

2. Если, по какой либо причине разработка концепции невозможна (разногласия среди руководства, лоббирование каких либо систем или фирм) - подготовить ряд взаимоувязанных документов, утвер-див их у отдельных руководителей

3. При отсутствии лидера и дееспособного коллектива службы ИТ - вывести функцию ИТ на аутсорсинг или предложить услуги неза-висимого консультанта

4. Улучшить управляемость, упростив структуру, укрупнить подраз-деления (появляется кадровый маневр), сократить численность

5. Организовать процесс таким образом, чтобы задействовать специа-листов разной квалификации

6. Использовать обучение, как нематериальный стимул, включать за-траты на обучение в проекты

7. Изучать и использовать методы нематериальной мотивации 8. Находить и воспитывать лидеров (постоянно), решая для них во-

прос оплаты индивидуально 9. Разрабатывать понятные документы в терминах бизнеса, писать

«красивые» отчеты 10. Начальнику службы ИТ необходимо выступать на совещаниях,

конференциях, публиковаться в прессе, много лично общаться с менеджерами всех уровней (в т.ч. неформально)

Внепроект-ный

Выбор АС 11. При выборе системы обратить внимание на возможность быстрого и удобного изменения функционала, настроек

12. Разработать механизм отбора систем, исключающий волюнтарист-ские решения (см. Гл.5)

Подготовка приказа и назначение руко-водителя, разработка укрупненного плана- графика, установле-ние KPI

13. В приказе на реализацию проекта указать процент занятости членов рабочих групп в проекте (от рабочего времени), вести подробный учет работ участников проекта, использовать его при стимулирова-нии

14. Сделать ставку на персонал со 100% занятостью в проекте (как пра-вило, ИТ-специалисты)

15. Взять руководство проектом на себя. Нанимать консультантов на принципах «аутстаффинга»

16. При полном отсутствии кандидатуры на роль руководителя проекта - привлечь внешнего независимого управляющего проектом (руко-водителя проекта)

17. Запланировать временные резервы (например, введением дополни-тельного этапа)

18. Запланировать финансовый резерв (например, введением дополни-тельного этапа)

19. Планировать этап сопровождения и мониторинга результатов 20. Этапы планировать на короткие сроки (месяц), четко оговаривать

результат, закрывать этапы актами Подготовка устава (описания) проекта

21. Четко определить распределение обязанностей заказчика и испол-нителя (Устав проекта). Разработать матрицы ответственности по проекту

22. Оговорить правила делегирования полномочий (в том числе и под-писания документов) при отсутствии руководителя

23. Назначить заместителя руководителя проекта, передать ему (офи-циально) часть полномочий

24. При формально назначенном руководителе - предоставить (офици-ально) больше полномочий координатору проекта (ГИПу)

25. Создать коллегиальный орган управления проектом - Управляю-щий Совет, утвердить регламент его работы

26. Создать коллегиальный орган взаимодействия - Методический Со-вет, утвердить регламент его работы

27. Регламентировать периодичность проведения рабочих совещаний

Иницииро-вание про-екта

Формирование рабо-чих групп

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

15

Этап Содержание работ Рекомендации ных работников

29. Выявить функциональных (неформальных) лидеров, обеспечить им материальную и моральную поддержку. Способов много!

30. При отсутствии поддержки со стороны функциональных подразде-лений - заменить ключевых специалистов подразделений специали-стами службы ИТ или консультанта (с соответствующей корректи-ровкой сроков и затрат)

31. Функциональные группы сделать небольшими, руководителя (ли-дера) группы назначить из работников службы ИТ

32. Вошедшим в группу специалистам подразделений поручается тех-ническая работа, разбитая на мелкие части

33. Издать «Блокнот участника проекта». Состав: Приказ о реализации проекта, график реализации проекта (этапы, сроки, отв. исполните-ли, результаты этапа), устав (описание) проекта, состав рабочих групп с контактными данными, система мотивации

Заключение догово-ра (ов)

34. Подробно все документировать, результаты фиксировать для того, чтобы иметь возможность прервать проект на любом этапе

35. Тщательно проработать форс-мажорные обстоятельства в договоре 36. Прописать в договоре санкции за неисполнение условий договора.

Прекращать работы после первого случая невыполнения условий. 37. Все изменения оформлять письменно

Организация управ-ления проектом

38. Автоматизировать ведение проекта (электронные коммуникации, база данных проекта, контроль исполнения поручений)

39. Применить автоматизацию управления проектами, начиная с пла-нирования и до оперативного уровня

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

41. Организовать проектную комнату (круглый стол, проектор, флип-чарт)

42. Организовать жесткое административное давление со стороны высшего руководства (через приказы, контроль исполнения, реше-ния руководящих органов проекта)

43. Обеспечить эскалацию проблемы по вертикали Координатор –> Руководитель проекта –> Управляющий совет (несмотря на воз-можность испортить отношения с функциональным руководите-лем)

44. Протоколировать все решения 45. Выдавать персональные наряды на работу (ежедневно, еженедель-

но) 46. Своевременно вносить изменения в планы работ по проекту 47. Упреждать нежелательные действия заказчика (письменно инфор-

мировать высшее руководство о ходе проекта) 48. Сделать проект гласным (через прессу). Пресса – тоже власть!

Обучение рабочих групп методике об-следования и описа-ния БП

49. Обучить специалистов по ИТ методике описания процессов с ис-пользованием специального ПО

Обследование объ-екта

50. Провести предпроектное обследование, разработать подробное ТЗ 51. Применить спиральную (стадиями) модель развития проекта. На

первом этапе предложить минимальные изменения или «пилотный» проект

52. Предложить для реализации референтную модель (где уже пропи-саны необходимые изменения)

53. Определить руководителей, нуждающихся в информации 54. Выяснить информационные потребности руководства и удобно их

реализовать 55. Предусмотреть оснащение рабочих мест топ-менеджеров компью-

терами 56. Предусмотреть выдачу информацию для топ-менеджеров на бу-

мажных носителях Описание процесса "как есть"

57. Сделать описание процесса «как есть», чтобы осознать решаемую задачу, как часть процесса и именно так ее реализовывать

58. Выявить способных к обучению на ранних стадиях проекта

Предпро-ектное об-следование

Подготовка деталь- 59. Применить иерархическое планирование проекта, определить кри-

16

Этап Содержание работ Рекомендации ного плана реализа-ции проекта

тический путь 60. Применить типовую модель внедрения, имея в виду типовой гра-

фик, перечень работ и нормативы времени на их выполнение Обучение системе команды проекта и ключевых пользова-телей

61. Обучить ключевых пользователей функционалу АС с целью озна-комления с возможными вариантами исполнения бизнес-процессов

Макетирование (проектирование системы "как будет")

62. Раздробить функции на мелкие роли 63. Написать подробные инструкции 64. Блокировать неправильные действия пользователей (программно,

организационно) 65. Автоматизировать ввод данных (штихкод, RFID-метки, данные

MES и SCADA-систем) 66. Создать операторские группы (для временной замены неспособных

к обучению) 67. Применить Web – интерфейс для руководителей (чтобы не изучать

интерфейс АС)

Техниче-ское проек-тирование

Разработка регла-мента ведения НСИ

68. Отказаться о кодирования вообще (современные системы это по-зволяют)

69. Разработать регламент идентификации и кодирования объектов учета

Опытная эксплуата-ция

70. На стадии реализации проекта разрабатывать временные регламен-ты, которые затем преобразовывать в СТП

71. Привлекать СК участию в проекте, особенно на стадии опытной эксплуатации, когда отрабатываются новые правила

72. Создать многоуровневую систему непрерывного обучения 73. Провести деловую игру (в учебном классе) чтобы показать взаимо-

зависимость всех участников процесса

Ввод в дей-ствие

Опытно-промышленная экс-плуатация

74. Не допускать длительной параллельной эксплуатации новой и ста-рой систем. Сделать интерфейс от новой к старой системе, запре-тить ввод в старую систему

Сопровож-дение

Устранение замеча-ний в период гаран-тийного срока

75. Обеспечить мониторинг результатов, совместно со службой качест-ва контролировать выполнение регламентов (стандартов)

17

Глава 3. Механизм управления проектами Подходы к управлению проектами Прежде всего, давайте поговорим об изменении подходов к управлению проектом. На рис. 4а представлена схема типичной организации управления проектом [2].. Согласно этой схеме со стороны заказчика ключевые роли в управлении проектом играют спонсор проекта и менед-жер проекта:

• Спонсор проекта — роль, в ведении которой находится бюджет проекта (это мо-жет быть отдельный человек или целый комитет). Спонсор проекта обеспечивает организационную сторону проекта и подтверждает правильность целей проекта.

• Менеджер проекта со стороны заказчика назначается в том случае, если осуще-ствление проекта организацией-заказчиком требует ежедневного управления. В круг обязанностей данной роли входит предоставление ресурсов заказчика, разре-шение проблем и отслеживание состояния проекта.

Со стороны исполнителя ключевые роли в управлении проектом играют бизнес-менеджер и менеджер проекта:

• Бизнес-менеджер несет ответственность за успешное выполнение проекта. Кроме того, бизнес-менеджер представляет исполнителя в его договорных отношениях с заказчиком.

• Менеджер проекта — это роль, на которой, в конечном счете, лежит ответствен-ность за успех или неудачу проекта. Менеджер проекта обязан управлять такими аспектами проекта, как сроки, стоимость, область применения и качество работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполни-теля.

Эта схема управления проектом предполагает активное участие в проекте внешней компа-нии-исполнителя и разделение им ответственности за успех/неудачу проекта. В условиях, когда ответственность за внедрение берет на себя заказчик, предложенная схема должна из-мениться. Прежде всего - заказчик и исполнитель должны поменяться местами. У заказчика, как пра-вило, нет достаточного количества людей, чтобы выделить для них отдельные роли. Поэто-му, роли в команде поддержки управления проектом концентрируются, а функции перерас-пределяются (на рис 4а пунктирными линиями изображена передача функций и полномо-чий). Кроме того, несколько изменяется понимание ключевых ролей в управлении проектом.

В нашем понимании «менеджер проекта» это не роль, а специальность - project manager, т.е. – специалист по управлению проектами (см. гл.1). В России существует приблизительный аналог – главный инженер проектов (ГИП). Гораздо шире становятся функции координатора проекта (наименование роли остается тем же) – это специалист по управлению проектами. В дальнейшем изложении координатор и менеджер проектов имеют одинаковое значение.

Менеджер проекта (со стороны исполнителя) в нашем понимании – это руководитель группы внешних консультантов.

В дальнейшем изложении не используется термин «спонсор проекта». Спонсор проекта – это один из топ-менеджеров заказчика (как правило, генеральный директор) или на допроектной стадии – инвестиционный комитет, а на проектной стадии – Управляющий совет. Иногда спонсора проекта называют куратором проекта.

Роль бизнес-менеджера для нас не представляет большого интереса и далее не рассматрива-ется.

Таким образом, далее рассматривается развитие схемы на рис. 4б с изменением терминов. Более подробно роли участников проекта рассматриваются в главе 5.

18

Рис. 4а Схема организации управления проектом силами исполнителя

Рис. 4б Схема организации управления проектом силами заказчика В крупных проектах предлагается создавать коллективные органы управления [2], например:

• Комитет по управлению. Цель деятельности данного комитета — определение стратегии, рассмотрение спорных вопросов, утверждение изменений в договоре;

• Комитет по контролю за изменениями. Этот комитет создается в рамках проекта с целью анализа и рассмотрения запросов на изменение. Как правило, изменения, касающиеся области определения проекта, передаются в комитет по управлению;

• Комитет по анализу спорных вопросов. Этот комитет организуется для разреше-ния спорных вопросов и регулярного управления рисками.

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

• Управляющий совет – это по функциям Комитет по управлению;

Руководитель группы

Менеджер проекта со стороны исполнителя

Менеджер проекта со стороны заказ-чика

Спонсор проекта

Менеджер по качеству

Координатор проекта

Администратор проекта

Менеджер по конфигурации проекта

Команда поддержки управления проектом Руководитель группы

Руководитель группы

Бизнес-менеджер исполнителя

Спонсор проекта

Руководитель группы

Менеджер проекта со стороны заказчика

Координатор проекта

Секретарь про-екта

Команда поддержки управления проектом Руководитель группы

Руководитель группы

Менеджер проекта со стороны исполнителя

Бизнес-менеджер исполнителя

19

• Методический совет – это по функциям Комитет по контролю за изменениями + Комитет по анализу спорных вопросов;

• Координационный комитет – это Управляющий совет + Методический совет.

Организационные структуры управления проектами Согласно PMBOK® [1] выделяются следующие виды организационных структур управления проектами:

• линейно-функциональная; • проектная; • матричная;

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

Таблица 5. Организационные структуры проекта Факторы, влияющие на выбор структуры

Линейно-функциональ-

ная

Слабая матрица Сильная (жесткая) матрица

Проектная

Неопреде-ленность

При рутинном характере про-екта

При средней неопределен-ности

При сильной неопре-деленности

При сильной не-определенности

Технология При известной стандартной технологии

При известной стандартной технологии

При сложной техноло-гии

При новых техно-логиях

Длитель-ность

Для коротких проектов

Для проектов средней дли-тельности

Для проектов средней длительности

Для длительных проектов

Число уча-стников

Для проектов с небольшим чис-лом участников

Для проектов с небольшим числом участников

Для среднего числа участников

Для проектов с большим числом участников

Важность Для проектов малой важности

Для проектов средней важ-ности

Для проектов средней важности

Для важных про-ектов

Взаимосвязи Охватывает од-но функцио-нальное подраз-деление

В проекте задействовано несколько подразделений

В проекте задейство-вано несколько под-разделений

Для проектов с сильными взаимо-связями

Сроки Сроки не кри-тичны

Критичность средняя Критичность средняя При критичных сроках

Примеры про-ектов

Внесение измене-ний в действую-щую систему

ü Автоматизация бухгал-терского учета;

ü Автоматизация ТОиР; ü Автоматизация конст-рукторской подготовки производства;

ü Автоматизация докумен-тооборота;

ü Автоматизация управле-ния сервисом, взаимоот-ношениями с клиентами;

ü Автоматизация управле-ния транспортом

ü Инфраструктурные про-екты (сети, коммуника-ции)

ü Комплексная авто-матизация снабже-ния, сбыта, управле-ния финансами (вкл. бухчет);

ü Автоматизация управления персо-налом и расчета зар-платы;

ü Автоматизация управления произ-водством;

ü Автоматизация тех-нологической подго-товки производства

Разработка новых систем

20

На рис. 5а, 5б, 5в изображены схемы матричных оргструктур.

Рис. 5а Слабая матрица со «слабым» руководителем проекта

Рис. 5б Слабая матрица с «сильным» руководителем проекта

Рис. 5в Сильная матрица

Руководство Руководитель проекта

Функциональный руководитель

Функциональный руководитель

Руководитель ме-неджеров проектов

Персонал Персонал

Секретарь

Менеджер проекта

Менеджер проекта Персонал Персонал

Руководство Руководитель проекта

Функциональный руководитель

Функциональный руководитель

Функциональный руководитель

Персонал

Персонал

Персонал

Персонал Персонал

Персонал

Секретарь

Руководство Руководитель проекта

Функциональный руководитель

Функциональный руководитель

Функциональный руководитель

Персонал

Персонал

Персонал

Персонал

Персонал

Персонал

Секретарь

21

Матричная структура отражает закрепление в механизме управления проектом двух направ-лений руководства:

• Вертикальное направление — управление функциональными и линейными струк-турными подразделениями компании.

• Горизонтальное направление — управление отдельными проектами, программами, для реализации которых привлекаются человеческие и иные ресурсы различных подразделений компании.

В зависимости от типа взаимосвязей различают слабую и сильную матрицы. Существуют две формы управления слабой матрицей. В первом случае (рис. 5а) управление членами команды проекта осуществляется не напрямую, а через функциональных руководи-телей. В качестве руководителя проекта обычно выступает руководитель одного из функ-циональных подразделений или главный специалист. Во втором случае (рис. 5б) руководи-тель проекта имеет право давать задания сотрудникам функциональных подразделений на-прямую. Обычно, в этом случае руководитель проекта имеет высокий статус в организаци-онной иерархии (либо первое лицо, либо его заместитель).

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

Сильная матрица (рис 5в) предполагает наличие координатора (менеджера) проекта, наде-ленного полномочиями напрямую отдавать распоряжения и требовать отчетности от сотруд-ников функциональных подразделений, входящих в состав команды управления проектом. Члены команды управления проектом не выводятся из состава своих функциональных под-разделений, но «откомандировываются» в команду проекта на полную или частичную заня-тость. Секретарь проекта может отсутствовать, тогда его функции выполняет координатор проекта. Кроме того, для структурирования типов управления проектами на наш взгляд необходимо ввести понятие сильного и слабого руководителя проекта. Надо сказать, что в PMBOK есть понятие «полномочия менеджера проекта» но они недостаточно конкретны. По моему опыту в реальной жизни наблюдается два ярко выраженных случая, которые мы и называем «силь-ным» и «слабым» руководителем проекта.

Наименования «слабый» и «сильный» руководитель не относятся к личным качествам руко-водителя, а определяют уровень его полномочий. У сильного руководителя есть мощный ад-министративный ресурс, а у слабого – его нет. Кроме того, особенностью сильного руково-дителя является, как правило, заинтересованность в результатах проекта (проект находится в сфере его деятельности), а также возможность влиять на финансирование проекта. Соответ-ственно у слабого руководителя эти возможности отсутствуют. Типичным представителем слабого руководителя является руководитель службы ИТ или высокопоставленный, но неза-интересованный руководитель. Таким образом, для слабого руководителя должны быть соз-даны дополнительные механизмы реализации проекта, компенсирующие отсутствие админи-стративного ресурса либо возможности (желания) активно участвовать в проекте. Этот «ме-ханизм» приведен на рис.6. Из рисунка видно, что «крутить ручку» механизма могут только два человека – Руководи-тель проекта или Координатор проекта (подробнее об их функциях – в Главе 4). Без этого «привода» механизм не работает, и проект обречен на неуспех. Редко случается, когда и Ру-ководитель и Координатор проекта прилагают одинаковые усилия. Очень часто Руководи-тель проекта назначен формально и тогда, крутить механизм придется Координатору. Для этого он должен быть наделен соответствующими полномочиями (в приказе или Уставе про-екта).

22

При сильном руководителе данный механизм может быть упрощен. Например, может быть предложена схема, в которой отсутствуют такие органы управления как Управляющий Совет и Методический Совет. Их работа заменяется проведением технических совещаний при ру-ководителе проекта или его единоличными решениями. Эта схема характеризуется гораздо более оперативным способом решения проблем, но в силу быстроты - решения могут быть не оптимальными. Иногда в этой схеме создается Координационный комитет, куда входят представители и Заказчика и Исполнителя («промежуточная» схема).

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

Таблица 6. Состав органов управления проектом в зависимости от условий Слабая матрица Сильная матрица

Слабый руково-дитель

ü Руководитель проекта ü Управляющий совет ü Методический совет ü Процессные группы ü Группа внешних консультантов ü Группа прогр.-тех. поддержки ü Секретарь проекта

ü Руководитель проекта ü Координатор (менеджер) проекта ü Управляющий совет ü Методический совет ü Процессные группы ü Группа внешних консультантов ü Группа прогр.-тех. поддержки ü Координатор от подразделения ü Секретарь проекта*

Сильный руково-дитель

ü Руководитель проекта ü Координационный комитет* ü Процессные группы ü Группа внешних консультантов

ü Руководитель проекта ü Координатор (менеджер) проекта ü Координационный комитет* ü Процессные группы

Управляющий Совет

Методический Совет

Руководитель проекта

Координатор (менеджер) проекта

Группа внеш-них консуль-

тантов

Процессные рабочие груп-

пы

Группа прогр.-технической поддержки

Координа-тор от под-разделения

23

ü Группа прогр.-тех. поддержки ü Секретарь проекта

ü Группа внешних консультантов ü Группа прогр.-тех. поддержки ü Координатор от подразделения ü Секретарь проекта*

Примечание: * - может отсутствовать

Механизм управления проектами и принципы TPS Поскольку большинство проблем внедрения (как было показано выше) лежит в сфере чело-веческих отношений, наиболее близки нам по духу идеи и механизмы производственной системы «Toyota» [6,7], опыт использования которой имеется не только в производстве, но и в сфере проектирования [8]. Четырнадцать основных принципов TPS приведены в таблице 7. Оценивая принципы ТPS можно предположить, что их можно применять в различных сферах деятельности человека, в том числе и при ведении проектов внедрения информационных технологий. Наибольшее значение для нас имеют принципы, объединенные под общим на-званием «Правильный процесс дает правильные результаты». Иными словами, зная все «подводные камни» внедрения ИТ мы можем так построить процесс, чтобы максимально снизить риск неуспешного внедрения.

Таблица 7. Принципы TPS I. ФИЛОСОФИЯ, как основа

1. Принимай управленческие решения с учетом долгосрочной перспективы, даже если это на-носит ущерб краткосрочным финансовым це-лям

II. ПРАВИЛЬНЫЙ ПРОЦЕСС ДАЕТ ПРАВИЛЬНЫЕ РЕЗУЛЬТАТЫ

2. Процесс в виде непрерывного потока способствует вы-явлению проблем

3. Используй систему вытягивания (канбан), чтобы избе-жать перепроизводства

4. Распределяй объем работ равномерно (хейдзунка): ра-ботай как черепаха, а не как заяц

5.Сделай остановку производства с целью решения про-блем (дзидока) частью производственной культуры, если этого требует качество

6. Стандартные задачи – основа непрерывного совершен-ствования и делегирования полномочий сотрудникам

7. Используй визуальный контроль (андон), чтобы ни од-на проблема не осталась незамеченной

8. Используй только надежную, испытанную технологию

III. Добавляй ценность организации, РАЗВИ-ВАЯ СВОИХ СОТРУДНИКОВ И ПАРТНЕ-РОВ

9. Воспитывай лидеров, которые досконально знают свое дело, исповедуют философию компании и могут научить этому других (сен-сей)

10. Воспитывай незаурядных людей и формируй команды, исповедующие философию компа-нии

11. Уважай своих партнеров и поставщиков, ставь перед ними трудные задачи и помогай им совершенствоваться

IV. Постоянное решение фундаментальных проблем сти-мулирует НЕПРЕРЫВНОЕ ОБУЧЕНИЕ

12. Чтобы разобраться в ситуации, надо увидеть все свои-ми глазами (генти генбуцу)

13. Принимай решение не торопясь, на основе консенсуса, взвесив все возможные варианты (немаваси); внедряя его не медли

14. Станьте обучающейся структурой за счет неустанного самоанализа (хансей) и непрерывного совершенство-вания (кайдзен)

Механизм управления представленный на рис. 6 спроектирован также из условий примене-ния принципов TPS. Связь элементов механизма с принципами TPS приведена на рис.7.

24

Рис.7

Эта связь достаточно очевидна, тем не менее, к схеме на рис. 8 необходимо дать не-сколько комментариев (в соответствии с нумерацией на рисунке):

1) Только топ-менеджеры (члены Управляющего совета) могут знать точно долго-срочную перспективу развития предприятия и соотносить желания среднего ме-неджмента (подразделений) со стратегией, пресечь нежелательное развитие со-бытий

2) В TPS принято, что все руководители, включая топ-менджеров, должны лично участвовать в процессе, видеть все собственными глазами (генти генбуцу). Ис-ключение делается только для высшего руководства, которые могут использо-вать информацию доверенных лиц (хоренсо).

3) Важнейшее значение придается процессу совместного обсуждения проблем и по-тенциальных решений (немаваси). В Toyota подавляющее количество решений принимается консенсусом. Для улучшения обмена информацией и оперативного принятия решений рекомендуется использовать большое помещение (обея) – в нашем понимании «проектная комната».

4) Очень большое значение придается роли координатора (менеджера) проекта (в Toyota эта должность называется – главный инженер, в России – главный инже-нер проекта). В сферу его ответственности входит организация процесса по цик-лу PDCA, управление разработкой стандартов автоматизируемой деятельности (роли, регламенты, инструкции).

5) В процессе проекта для рабочих групп создается «База данных проекта», в кото-рой фиксируются все возникающие проблемы и их решения. В базе накаплива-ются знания по проектам, которые представляют значительную ценность для по-следующих проектов. В Toyota они полежат бессрочному хранению и изучению. Учет опыта аналогичных проектов - это один из самых эффективных способов избежать ошибок планирования и неверных технических решений.

Управляю-щий Совет

Руководитель проекта

Координатор проекта

Методический Совет

Группа внеш-них консуль-

тантов

Группа прогр.-технической поддержки

Процессные рабочие группы

Координатор от подразде-

ления

1) Принимай управ-ленческие решения с учетом долгосроч-ной перспективы

3) Принимай решения не торо-пясь, на основе консенсуса

2) Чтобы разо-браться в ситуа-ции, надо увидеть все своими глаза-

ми

4) Распределяй объем работ равномерно. Сделай остановку про-екта, если этого требу-ет качество

5) Стандартные задачи – основа непрерывного совершенствова-

ния

7) Уважай своих партнеров и постав-щиков, ставь перед ними трудные зада-чи и помогай им

совершенствоваться

6) Используй визуальный кон-троль, чтобы ни одна проблема не осталась незаме-

ченной

8) Используй только надежную, испытанную тех-нологию, встраи-вай качество в

процесс

9) Воспитывай лидеров, которые досконально зна-ют свое дело, могут научить этому других

25

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

7) Знания и опыт консультантов заслуживают уважения, но не стоит его переоцени-вать. Для них проект – тоже способ совершенствоваться и развиваться. В Toyota стремятся к долгосрочным отношениям с поставщиками, что дает уверенность в стабильном качестве и разумной цене товаров и услуг.

8) В технологиях проектирования, программирования, хранения данных лучше быть на шаг назад, чем на шаг вперед. Это снижает риск срыва проекта и обычно дешевле. Новые технологии нужно испытывать вне проекта. Встраивание каче-ства в процесс – это возможность остановки процесса в случае его нарушения (дзидока) и защита от ошибочных действий работника (пока ёке).

9) С самых ранних этапов проекта необходимо обучать ключевых пользователей, которые понесут знания в подразделения, будут способствовать бесконфликтно-му внедрению систем.

Ниже, в таблице 8 приводится интерпретация принципов TPS по отношению к ИТ. Примене-ние данных принципов дает механизмы реализации многих рекомендаций из таблицы 4.

26

Таблица 8. Интерпретация принципов TPS по отношению к ИТ Принципы TPS Интерпретация принципов TPS по отношению к ИТ

1. Принимай управленческие решения с учетом долгосрочной перспективы, даже если это на-носит ущерб краткосрочным фи-нансовым целям

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

2. Процесс в виде непрерывного потока способствует выявлению проблем

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

3. Используй систему вытягива-ния (канбан), чтобы избежать перепроизводства

Как можно раньше следует начинать использовать нормативную информа-цию. Не следует увлекаться выверкой (перепроизводством) информации. Достаточный уровень – 80% точности. Когда у информации есть потреби-тель - она начинает выверяться сама собой.

4. Распределяй объем работ рав-номерно (хейдзунка): работай как черепаха, а не как заяц

Создайте нужное количество рабочих групп. Разработайте сетевой график. Не забывайте вовремя перепланировать.

5. Сделай остановку производст-ва с целью решения проблем, если этого требует качество

Если проект (или его этап) зашел в тупик из-за неправильно выбранных решений или планирования нужно иметь смелость остановить проект и внести в него необходимые изменения.

6. Стандартные задачи – основа непрерывного совершенствова-ния и делегирования полномочий сотрудникам

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

7. Используй визуальный кон-троль (андон), чтобы ни одна проблема не осталась незамечен-ной

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

8. Используй только надежную, испытанную технологию

В технологиях лучше быть на шаг назад, чем на шаг вперед. Это снижает риск срыва проекта и обычно дешевле. Новые технологии нужно испыты-вать вне проекта.

9. Воспитывай лидеров, которые досконально знают свое дело, исповедуют философию компа-нии и могут научить этому дру-гих (сенсей)

В контексте проекта речь идет о координаторах (менеджерах) проектов и лидерах по функциональным направлениям (экспертам). Нужно различать лидеров и начальников. Эффективность лидеров существенно выше.

10. Воспитывай незаурядных людей и формируй команды, исповедующие философию ком-пании

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

11. Уважай своих партнеров и поставщиков, ставь перед ними трудные задачи и помогай им совершенствоваться

В данном контексте речь идет как о консультантах, которые тоже учатся на ваших проектах, так и о конечных пользователях, о которых нужно позабо-титься и поддерживать после внедрения. Необходимо начальное обучение, а затем постоянная поддержка (дообучение, переобучение)

12. Чтобы разобраться в ситуа-ции, надо увидеть все своими глазами (генти генбуцу)

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

13. Принимай решение не торо-пясь, на основе консенсуса, взве-сив все возможные варианты (немаваси); внедряя его не медли

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

14. Станьте обучающейся струк-турой за счет неустанного само-анализа (хансей) и непрерывного совершенствования (кайдзен)

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

27

Глава 4. Психологические аспекты ведения проектов Многие авторы отмечают весьма типичный ход проекта, отображенный на рис.8. Кривые очень похожи и отражают разную эмоциональную реакцию людей на разных стадиях проек-та. Эмоциональное напряжение во время проекта может быть очень высоким и варьировать-ся от злости до депрессии. Несмотря на отличающееся именование фаз развития проекта – общим для них является наличие кризисов (самые низкие точки графика). Наиболее серьез-ным является кризис на завершающем этапе проекта (вторая, правая «яма»). Это последняя возможность «похоронить» проект. И тут требуются значительные усилия, особенно со сто-роны руководства, для того, чтобы обеспечить продолжение и успешное завершение проек-та. Помочь в ведении проекта преобразований и преодолении эмоциональных проблем мо-жет отчасти описанная выше матричная структура управления проектом, где сочетается вер-тикаль власти и горизонтали сотрудничества и взаимодействия на разных уровнях. Но глав-ное - собрать работоспособную и мотивированную команду проекта.

Команда проекта Одним из «золотых правил» управления проектами считается правильный подбор команды. Команда в отличие от группы обладает гораздо большей эффективностью, и позволяет ре-шать сложные задачи. Соответственно для простых и некритичных по времени задач можно ограничиться группой.

Команда от группы отличается рядом признаков [4]: • Члены команды участвуют в меру своей компетентности в совместном достиже-

нии целей в соответствии с отведенной им ролью; • Команда имеет свое лицо, не совпадающее с индивидуальными качествами ее чле-

нов; • Для команды характерны сложившиеся связи как внутри, так и вне ее с другими

командами и группами; • Команда имеет ясную упорядоченную и экономную структуру, ориентированную

на достижение поставленных целей; • Команда периодически оценивает свою эффективность.

Признаки эффективной команды приведены в таблице 9. Таблица 9. Признаки эффективной команды

Признаки эффек-тивной команды

Стадии создания команды Стиль и образ действий руководителя

Ясные цели и задачи Формирование Группа выясняет цели, структуру и способы организации работы, требова-ния руководства.

Инструктивный Организовывать и направлять работу со-трудников. Составить укрупненный (черновой) план проекта

Понимание всеми взаимозависимости

Столкновение Притирка — конфликт начальной ста-дии, проявляются различие интересов, обнаруживается скрытый план дейст-вий.

Поддержка Устанавливать высокие требования, ре-шать проблемы взаимодействия. Совме-стно разработать графики и рабочие ори-ентиры проекта.

Сплоченность и дове-рие

Выработка норм и правил Группа принимает нормы и правила команды, устанавливает высокую сте-пень открытости и доверия (часто это не является ценностью для руково-дства).

Привлечение Позволять сотрудникам самим организо-вывать свою работу. Подать пример.

Работоспособность Слаженная работа Команда достигла зрелости и способна решать сложные задачи. Развертыва-ется работа над проектом.

Делегирование: Распределять ответственность за задания. Позволить другим сотрудникам выпол-нить их.

28

Источник:. Джини Дак «Монстр перемен. Причины успеха и провала организационных преобразований», Альпина Пабли-шер. — Москва, 2002.

Источник: "Managenement Magazine", Джей Маршалл, Дерилл Р. Коннэр, «Как и почему компании сопротивляются переме-нам»

© Copyright by Integrated Control Systems, Inc. Date August 22, 2005. All right Reserved IMPAC Reg. T.M.

Рис. 8

Остановка - перемены могут казаться настолько нереальными, что человек даже не может полностью

осознать их.

Отрицание - Человек надеется, что проект перемен осуществить нереально ("Если я про-игнорирую перемены, то

их не будет").

Злость - Эта фаза харак-теризуется чувством разочарования, которое часто разрастается и направляется на других

служащих

Уныние - Увидев, что переговоры ни к чему не привели, человек часто впадает в уныние, созна-вая, что перемены вполне реальны и постоянны.

Изучение - человек уже принимает

перемены и пытается выяснить, как до-биться успеха в новых условиях.

Стабильность - пред-шествует объявлению о переменах и отража-ет существующее положение вещей.

Время

Эмоциональная

реакция

Переговоры - люди начинают вести перего-воры, желая максимально уменьшить влияние

перемен. Они стремятся затянуть выполнение

проекта, просят изменить или остановить его

Принятие перемен

В Р Е М Я

Э М

О Ц

И И

Осознание

Шок

Фрустрация (депрессия)

Отторжение

Осведом-ленность

Рациональ-ное принятие

Принятие / Адаптация

Полная инте-грация. Использование преимуществ

29

Подбор команды проекта Считается, что при подборе людей необходимо руководствоваться их профессиональными качествами, умением быстро адаптироваться к новым условиям, умением работать в коман-де. Имеются методики отбора людей в команды путем тестирования. Можно упомянуть тест Белбин и тест Майерс-Бриггс [2]. Оба теста предполагают сбор большого количества инфор-мации путем опроса и заполнения таблиц (по Белбин – 56 вопросов, по Майерс-Бриггс – 64 вопроса). Наверное, в каких то крайне ответственных проектах подбор команды таким спо-собом возможен, но в наших условиях даже собрать первичные данные не удается – люди просто проигнорируют анкету. Мы знаем, что в рабочие группы проекта функциональные руководители отдадут тех, кого не жалко отдать и от кого мало что зависит. Поэтому пас-сивные, сомневающиеся, даже не очень компетентные люди – это наш контингент.

Таким образом, задача формирования команды в наших условиях состоит в том, чтобы сформировать костяк команды из ИТ-специалистов и чтобы в команду не попали те, кто мо-жет разрушить проект, а если это случилось, принять меры по их нейтрализации. Помочь в этом может описание некоторых типажей, с которыми приходилось сталкиваться и частично заимствованных у Дж. Филипса [5]. Они приведены в таблице 10, там же даются рекомендации по методам противодействия им.

Таблица 10. Отрицательные типажи Типаж Описание Противодействие

«Скандалист» Это энергетический вампир. Его задача – спровоцировать скандал, вызвать гнев, взрыв эмоций. От этого он «заряжается» и получает удовольствие. В его арсенале – грубость, оскорбления, язвительность, не-ожиданные «подставы». Чаще всего, это руководитель среднего уровня, считающий себя незаменимым, и что ему все сойдет с рук (как сходило и раньше).

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

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

Назначить руководителем проекта. Иногда помогает, иногда - нет. Можно организовать встречный поток информации руководству, в прессу (отчеты, докладные о ходе проекта), чтобы дезавуировать не-гативную информацию. На завер-шающем этапе можно привлечь к выполнению проекта.

«Говорун» Настоящий оратор. Любое совещание для него - это повод выступить, показать себя. Повестка дня существенного значения не имеет. Он может серьезно заблокировать работу любого коллективного органа и рез-ко увеличить риски срыва проектов.

Если такой человек попал в рабо-чую группу, нужно как можно ре-же приглашать его на совещания, практиковать общение «один-на-один» (лишить аудитории), пере-вести общение на письменный уро-вень.

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

Опасность в том, что эксперимен-тировать на проекте нельзя. Мож-но сорвать проект. Возможно, лучшим будет назначить его коор-динатором от подразделения или ключевым пользователем.

«Отрицатель» Этому человеку все равно, что отрицать. Это достаточно пассивная позиция

30

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

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

«Звезда» Захваленная и переоцененная персона (как правило, на фоне серости и беспомощности других сотрудников), которую всем ставят в пример. Часто – это прошлые заслуги, которые в новых условиях не представляют интереса, а новых заслуг еще нет. Иногда, человек в глубине души понимает, что он далеко не «звезда», но расстаться с этим приятным ощущением ему трудно. Минус «звезды» в том, что с ней трудно общаться и требуется приложить много сил, чтобы «звезда» снизошла до проекта. Может раз-рушить проект, убедив руководство, что проект далеко не так сложен, как его пред-ставляют ИТ-специалисты.

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

«Балагур» Душа компании, заводила. Всегда шутит, рассказывает анекдоты, истории. Люди это-го типа приносят много радости, но еще больше впустую тратят свое и чужое рабо-чее время. Очень часто такие люди загру-жены не полностью и поэтому думают, что и коллеги бездельничают. С одной стороны – человек приносит пользу команде, улуч-шая психологический климат, с другой мо-жет тормозить проект.

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

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

Большого вреда проекту от него нет, но и пользы тоже. Брать в ко-манду его практически бессмыс-ленно, разве что на работы тре-бующие терпения и спокойствия (например, документирования, контроля).

«Ковбой» Склонен к авантюризму. Часто не думает о последствиях. Например, может начать пе-резагрузку сервера перед началом работы или запустить многочасовую переиндекса-цию искренне считая, что это нужно сде-лать именно сейчас. Может быть профес-сионалом своего дела, но бесшабашность, граничащая с безответственностью может приводить к конфликтам и негативно ска-зываться на проекте.

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

«Оппозиционер» Он в оппозиции ко всему и ко всем. Это Скорее всего он никогда не станет

31

жизненная позиция. Считает, что только он один знает все и вся (в этом он похож на «звезду»). Может обладать сильной отри-цательной энергией, иметь авторитет у час-ти коллектива. Отказывается признавать очевидные вещи. Может иметь несколько необычный (отличающийся от остальных) внешний вид.

членом команды, а значит – «вой-на»2. Нужно сделать вид, что вы принимаете его точку зрения, что-бы он подумал, что вы сдались. Это позволит выиграть время и довести проект до стадии, когда его влияние уже не будет так силь-но.

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

Есть еще одна категория людей, которая может отрицательно повлиять на проект, но на нее воздействовать сложнее, поскольку это руководители. Вот некоторые типажи руководителей (табл. 11).

Таблица 11. Отрицательные типажи руководителей Типаж Описание Противодействие

«Самодур» Начальник, не желающий слушать или вникать в доклады. Часто кричит, оскорб-ляет подчиненных. Считает, что все про-блемы в отсутствии дисциплины. В боль-шинстве случаев такие руководители мо-гут реагировать только на документы. Это может задержать проект, поскольку не позволит оперативно решать проблемы.

Перевести общение на письмен-ный уровень. Регулярно информи-ровать о продвижении проекта. Постараться не доводить разно-гласия до открытого конфликта, действовать через заместителей, секретаря.

«Уклонист» Руководитель, не принимающий никаких решений. Причина обычно в боязни при-нять неправильное решение (за которым может последовать наказание), поэтому лучше не принимать их совсем. Люди та-кого типа требуют дополнительной ин-формации, разъяснений, совещаний, что серьезно тормозит реализацию проекта.

Фиксировать даты принятия ре-шений в документе. Утверждать их на высшем уровне, ставить до-кументы на контроль.

«Недоверчивый» Обычно, это педантичные люди, которые считают, что только они могут успешно выполнить любую работу и не доверяют ее никому, пытаясь разобраться во всем сами. Они не умеют делегировать полно-мочия и поэтому хватаются за все, но не успевают ни одного, ни второго. Не уме-ют ранжировать задачи по значимости и поэтому упускают главное. Может счи-тать, что его обманывают, не информи-руют, обходят, он не в курсе. Это вызыва-ет перегрузку и сказывается на их харак-тере не в лучшую сторону. Склонен к срывам.

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

«Отсутствующий» Обычно, такие люди активно участвуют на начальных стадиях проекта, но затем часто и надолго пропадают. Если такой руководитель выполняет важную роль в проекте (например, назначен руководите-лем проекта) это грозит срывом проекта

Постараться распределить его обя-занности среди других участников проекта, информировать руково-дителя о ходе проекта с помощью электронных средств.

2 «Война основывается на применении обмана… Поэтому сильный притворяется слабым, использование одного средства выдается за использование совершенно другого, близкое представляется как далекое, а далекое как близкое»[12.1].

32

или как минимум, значительной пере-грузкой команды на последнем этапе про-екта.

Конечно, могут быть и сочетания типажей, например, «недоверчивый самодур», «отсутст-вующий уклонист». Еще одной особенностью ведения проектов собственными силами является отсутствие биз-нес – консультантов, задача которых понять и формализовать идеи (пожелания, требования) заказчика. Заказчику не всегда понятно, что для того, чтобы довести их идеи до реализации, нужна гораздо более детальная информация. Функциональным специалистам кажется, что они и так уже сказали (выдали) все что нужно, а ИТ-специалисты просто не обладают доста-точной квалификацией, чтобы их понять. В действительности они просто не видят той части айсберга, которая для них скрыта под водой, ведь для того чтобы реализовать идею специа-листа функционального подразделения нужно пройти несколько этапов уточнения этой идеи, даже если она есть в виде документа (положения, методики). Т.е. на одного специалиста функционального подразделения требуется от трех до пяти, а иногда и больше, других спе-циалистов.

Рис. 9

На рис. 9 изображен тот самый айсберг, у которого есть надводная часть (1) и подводная часть (2,3,4). Собственно ИТ-специалисты находятся на 4-м уровне, а уровни 2 и частично 3 во всем мире относятся к бизнес - консалтингу. Но поскольку надобность в бизнес - консал-тинге часто не осознается или отсутствует возможность (в силу высокой стоимости) его при-влечь – то эта функция ложится на ИТ-специалистов. Это заставляет их глубоко вникать в сферу автоматизируемой деятельности и за небольшой срок (несколько проектов) ИТ-специалист (методолог, постановщик) знает специфику бизнеса лучше, чем функциональный специалист. Это может вызывать крайнее раздражение у функциональных специалистов («яйца курицу учат!»), хотя в этом нет ничего необычного, ведь автомобиль лучше знает тот, кто его проектировал, а не кто на нем ездит.

Теме не менее вышесказанное заставляет нас считать ключевыми фигурами команды проек-та именно ИТ-специалистов.

Положения, методические рекомендации

Техническое задание, (техническое решение)

Постановка задачи для реализации в АС

Специалист функционального подразделения

Системный аналитик (глав-ный методолог)

Методолог, (постанов-щик задач)

Программист, тестировщик, администратор БД

Реализация (програм-мирование, отладка, настройка, докумен-тирование)

1

2

3

4

33

Преодоление сопротивления Известно полезное соотношение, выведенное Хаммером3. Оно звучит как «20/60/20».Согласно этому соотношению около 20% людей воспринимают преобразования с воодушевлением. Нужно искать и ценить таких людей, пользоваться их энтузиазмом. Но ес-ли преобразования будут остановлены, они будут чувствовать себя не просто разочарован-ными, а преданными. Их энтузиазм превратится в цинизм и мы навсегда потеряемте этот ценный ресурс.

Еще 20% сотрудников будут всегда настроены против любых преобразований. По большому счету у них нет рациональных причин для недовольства, более того, происходящее им может быть выгодно. Не это важно. Они так глубоко сжились с привычной практикой бизнеса, что не представляют себе, как можно работать или вести себя по-другому. Эти 20% неисправи-мы, неприятие перемен у них в крови, и перевоспитать их не удастся. Будьте готовы к их увольнениям, однако многие этому удивятся, т.к. в числе увольняющихся будут и лучшие работники (которые, увы, могут работать только старыми методами). Оставшаяся часть (60%) относится к преобразованиям нейтрально и именно на них необхо-димо обратить весь арсенал приемов, обеспечивающих их заинтересованное участие в про-екте.

Существует еще одна классификация участников проекта[4], согласно которой выделяются 4 категории людей по отношению к проекту, где 20% хаммеровских противников разделены на 2 части. Далее будем пользоваться этой классификацией.

Открытое «Сторонник» «Противник» Проявление отно-шения к проекту Скрытое «Пассивный сторонник» «Опасный элемент»

Принимается Не принимается Отношение к проекту

Поскольку мы подразумеваем, что сопротивление проекту неизбежно будет, уже на этапе предпроектного обследования для себя нужно составить список людей, связанных с проек-том (как внутри, так и вне команды проекта) и в дальнейшем его уточнять, т.к. отношение к проекту может меняться. Понятно, что команду проекта лучше формировать из сторонников, но часто туда бывают включены и противники (например, по должности). Это конечно усложнит работу, но выше мы уже рассматривали способы, которые позволяют сильно ослабить их позиции. Самая сложная ситуация с «опасными элементами», поскольку их отношение к проекту скрытое. Задача состоит в том, чтобы сделать сопротивление открытым, тогда ему можно противосто-ять. Можно предложить несколько общих методов преодоления сопротивления. В [12.2] со ссыл-кой на Дж. Коттера и Л. Шлезингера приведены 6 методов преодоления сопротивления из-менениям.

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

3 Майкл Хаммер (Michael Hammer), профессор Массачусетского технологического института, автор концепции реинжиниринга бизнес-процессов.

34

Участие и вовлеченность. Если привлечь потенциальных противников к участию в плани-ровании, то они зачастую можно избежать сопротивления. Часто не дает желаемого резуль-тата.

Помощь и поддержка. Помощь и поддержка особенно необходимы, когда в основе сопро-тивления лежит страх и беспокойство. Основной недостаток этого подхода заключается в том, что он требует большого количества времени, следовательно, является дорогостоящим и тем не менее зачастую терпит неудачу. Если же времени, денег и терпения просто нет, то ис-пользовать методы поддержки не имеет смысла. Переговоры и соглашения. Способ заключается в предоставлении стимулов активным или потенциальным (пассивным) противникам изменения. Переговоры особенно подходят в том случае, когда ясно, что кто-то теряет в результате изменения, и тем не менее он обладает су-щественной силой сопротивляться. Достижение соглашения является сравнительно легким способом избежать сильного сопротивления, хотя оно, как и многие другие способы, может быть довольно дорогостоящим. Манипуляции и кооптации. Манипуляции в данном случае подразумевают избирательное использование информации и сознательное изложение событий в определенном, выгодном для инициатора изменений порядке. Одна из наиболее распространенных форм манипуляции — кооптация. Кооптация личности подразумевает предоставление ей желаемой роли при планировании и осуществлении изменений. Кооптация коллектива подразумевает предос-тавление одному из его лидеров или кому-то, кого группа уважает, ключевой роли при пла-нировании и осуществлении изменений. Это не является формой участия, потому что ини-циаторы изменения стараются получить не совет кооптируемых, а только их поддержку. При определенных обстоятельствах кооптация может быть относительно дешевым и легким спо-собом достижения поддержки отдельного индивидуума или группы служащих. Но он имеет ряд недостатков. Если люди чувствуют, что их просто дурачат, чтобы они не сопротивлялись изменениям, что с ними обращаются не на равных или им просто лгут, то их реакция может быть крайне отрицательной. Явное и неявное принуждение. Менеджеры часто преодолевают сопротивление путем при-нуждения. В основном они заставляют людей смиряться с изменениями путем скрытой или явной угрозы (потеря работы, льгот, возможности продвижения и т. д.), или путем реального увольнения, либо путем перевода на более низкооплачиваемую работу. Так же как и манипу-ляция, использование принуждения — это рискованный процесс, потому что люди всегда сопротивляются навязанному изменению. Однако в ситуациях, когда необходимо быстро осуществить изменения и там, где она не пользуются популярностью, независимо от того, как она осуществляется, принуждение может быть единственным вариантом. Вышеперечисленные методы сведены в таблицу 12.

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

35

Таблица 12. Методы преодоления сопротивления изменениям

Подход Обычно используется в си-туациях: Преимущества (достоинства) Недостатки

1. Инфор-мирование и общение

При недостаточном объеме ин-формации или неточной ин-формации в анализе

Если вам удалось убедить людей, то они часто будут помогать вам при осуществлении изменений

Подход может требовать очень много времени, если вовлекается большое коли-чество людей

2. Участие и вовлечен-ность

Когда инициаторы изменения не обладают всей информацией, необходимой для планирования изменения, и когда другие име-ют значительные силы для со-противления

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

Этот подход может потре-бовать много времени

3. Помощь и поддержка

Когда люди сопротивляются изменениям из-за боязни про-блем адаптации к новым усло-виям

Ни один другой подход не срабатыва-ет так хорошо при решении проблем адаптации к новым условиям

Подход может быть доро-гостоящим и требовать большого количества вре-мени и тем не менее может потерпеть неудачу

4. Перегово-ры и согла-шения

Когда отдельный служащий или группа явно теряют что-либо при осуществлении изменений

Иногда это является сравнительно простым (легким) путем избежать сильного сопротивления

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

5. Манипу-ляции и ко-оптации

Когда другие тактики не сраба-тывают или являются слишком дорогостоящими

Этот подход может быть сравнитель-но быстрым и недорогим решением проблем сопротивления

Этот подход может порож-дать дополнительные про-блемы, если у людей воз-никнет чувство, что ими манипулируют

6. Явное и неявное принужде-ние

Когда необходимо быстрое осуществление изменений и когда инициаторы изменений обладают значительной силой

Этот подход отличается быстротой и позволяет преодолеть любой вид со-противления

Рискованный способ, если люди остаются недоволь-ными инициаторами изме-нений

При планировании проекта может оказаться полезной метафора нападающих и обороняю-щихся. Для того, чтобы обеспечить успех наступления (успех проекта) полководцу (руково-дителю или координатору проекта) необходимо найти место в обороне «противника», где можно обеспечить успех. Обычно, это те функциональные направления (или подразделения), где менее всего негативно настроенных работников, т.е. «сторонников» или «пассивных сто-ронников». Иначе говоря - место прорыва не там, где самые умные, подготовленные и «ав-томатизированные», а там, где меньше сопротивление. В месте прорыва необходимо скон-центрировать лучшие силы и провести пилотный проект и затем распространить успех на другие подразделения. Если пилотный проект не возможен, рекомендуется выстроить кален-дарный план таким образом, чтобы в месте прорыва были запланированы более ранние сро-ки. В подтверждение сказанного позволю процитировать «Трактат о военном искусстве Сунь-Цзы»4: «Построение армии подобно процессу, в результате которого занимает определенное положение вода. Вода не поднимается вверх и стремится к низким местам; построение армии должно быть таким, чтобы избегать столкновения с сильными частями противника и сра-жаться со слабыми. Движение воды определяется рельефом местности; армия добивается победы в зависимости от поведения противника. Поэтому армия, как и вода, не должна иметь постоянной конфигурации; гениальность командующего проявляется в достижении победы за счет таких действий, которые изменяются в соответствии с изменениями, проис-ходящими у противника»

4 Sun Tzu Ping Fa, гл. 6. [12.1]).

36

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

Ниже, на рис.9 приведена схема из книги Масааки Имаи [9], где П-критерии – это критерии, ориентированные на процесс, а Р-критерии – на результат.

В комментарии к схеме говорится, что «Одна из отличительных особенностей японских ру-ководителей состоит в том, что они прилагают сознательные усилия по созданию системы, которая, отдавая должное Р-критериям, поддерживает и поощряет П-критерии.» Менеджера, ориентированного на процесс, который принимает во внимание П-критерии, интересуют:

• дисциплина (например, посещаемость совещаний, занятий, четкое следование ус-тановленным стандартам, Уставу проекта, технологии проведения работ);

• управление временем (способность успевать к сроку); • развитие навыков (способность к обучению и применению знаний) • соучастие и вовлеченность (достаточное внимание проекту в рамках установлен-

ного времени) • мораль (корректное и дружелюбное отношение к коллегам) • коммуникация (способность общаться, внятно излагать свои мысли)

Таким образом, если мы придерживаемся принципа «Правильный процесс дает правильные результаты» - мы должны создать систему мотивации ориентированную в большей степени на процесс. Предлагается упомянутые выше П-критерии применять для оценки работы уча-стников рабочих групп (о чем должно быть им объявлено). Результат не замедлит сказаться, процесс пойдет лучше, а результат будет выше.

37

Рис. 10

Материальная мотивация С самого начала проекта необходим учет работы участников проекта – как количества, так и качества труда. Эту работу должен вести координатор проекта на основании данных руково-дителей групп. Чем подробнее, тем лучше. Ниже приводится один из возможных вариантов материальной мотивации участников проекта. Следует заметить, что данная система не рас-пространяется на руководителя проекта.

Для оценки работы участников рабочих групп применяются процессные критерии, приве-денные в таблице 13.

Таблица 13. Процессные критерии мотивации К-т Проц. критерий Значение Примечания

Квр Управление вре-менем 0 - 4 Точное выполнение плановых заданий, способ-

ность успевать к сроку

Кдис Дисциплина 0 - 3 Посещаемость совещаний, учебных занятий, четкое следование установленным стандартам, Уставу проекта, технологии проведения работ

Куч Участие (вовле-ченность) 0 – 2 Достаточное внимание проекту в рамках уста-

новленного времени

Кком Коммуникации 0 - 1 Способность общаться, внятно излагать свои мысли, корректные отношения с коллегами

Кнав Развитие навыков 0 - 1 Способность к обучению и применению знаний

На этапе подготовки приказа о реализации проекта оговаривается процент занятости каждо-го участника проекта от установленного фонда рабочего времени (например, Петров - 30%, а Сидоров – 20% рабочего времени должны уделять проекту). Коэффициент участия (Куч) вычисляется как отношение фактической доли участия в фонде рабочего времени к плано-вой. Куч не может превышать 2.

Квр, Кдис, Кком, Кнав определяются координатором проекта по согласованию с руководи-телями рабочих групп.

Критериями связанными с результатом являются: • Коэффициент качества (Ккач); • Коэффициент, устанавливаемый руководителем проекта (Крп).

Коэффициент качества (Ккач) может принимать значение от 1 до 3 и определяется координа-тором проекта по согласованию с руководителями рабочих групп.

П1 П2 П3 П4 Р

П - критерии Р - критерии

Процесс Результат

Действия по со-вершенствованию

Поддерживать и поощрять

Результаты

Управлять методом «кнута и пряника»

38

Крп равен доле от 100% которые распределяются руководителем проекта между участни-ками проекта по своему усмотрению. Для реализации проекта выделяется мотивационный фонд (МФ), который делится на 2 час-ти:

1. Фонд координатора проекта (Фкп) - 80%; 2. Фонд руководителя проекта (Фрп) - 20%.

В случае отсутствия координатора (менеджера) проекта Фкп выделяется в распоряжение ру-ководителей рабочих групп. Следует отметить, что соотношение 80/20 является рекомендуемым и в зависимости от про-екта может быть изменено. Коэффициент премии участника (Кпрем) из Фкп определяется как:

Кпрем = Куч + Квр + Кдис + Кком + Кнав + Ккач Премия участника (Пкп) из Фкп вычисляется по формуле:

Фкп х Кпрем Пкп = -------------------------

Σ Кпрем После того, как основная часть фонда (Фкп) распределена, руководитель проекта добавляет свою персональную надбавку (Крп) «за результат, полезность, ценность для проекта», кото-рую не всегда можно вычислить. Каждому или определенным участникам выделяется доля от 100% Фрп (например Иванову - 60%, Сидорову – 40%).

Премия участника (Прп) из Фрп вычисляется по формуле:

Фрп х Крп Прп = --------------

100 Суммарная премия участника (П) определяется как:

П = Пкп + Прп Иллюстрация вышесказанного приведена на рис.11

Рис.11

Мотивационный фонд должен выплачиваться по окончании этапов работ, а не проекта в це-лом. Далекая премия демотивирует участников проекта, да и не все участники доберутся до конца проекта.

Мотивационный фонд

Фонд координатора проекта (Фкп) Фрп

Куч + Квр + Кдис + Кком + Кнав Ккач Крп

«за процесс» «за результат»

Фонд руко-водителя проекта

39

Нематериальная мотивация Нематериальная мотивация важна не меньше, чем материальная, особенно в процессе вы-полнения проекта. ИТ специалисты в гораздо большей степени придают значение нематери-альным стимулам, чем люди многих других профессий. В статье В.Завадского5 приводятся следующие нематериальные мотивы:

• Социальный мотив; • Процессный мотив; • Мотив достижения; • Идейный мотив.

Люди с ярко выраженным социальным мотивом работают ради одобрения. Для них очень важно отношение к ним непосредственного руководителя и коллектива – уважение, похвала, общественное признание. Им хочется, чтобы их заметило высшее руководство. Стратегия взаимодействия в данном случае строится на развитии неформальных дружеских отношений руководителя и работника, на чувстве долга перед отделом, фирмой. Нужно постоянно да-вать сотруднику понять, насколько он незаменим: прилюдно отмечать его вклад. Целесооб-разно назначать их руководителями рабочих групп. Люди с процессным типом мотивации трудятся ради самого процесса выполняемой работы (например, общения с заказчиками, программирования). Процессный мотив уходит корнями в желание ощущать себя источником изменений в окружающем мире. Таких людей нельзя заставлять заниматься скучной рутиной, им нужно давать сложные интересные задания, тре-бующие творческого подхода, свободы в выборе средств достижения цели.

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

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

5 В.Завадский. «Нематериальная мотивация, или Как удержать специалистов не повышая зарплаты». PC Week/re, № 8/2004, с. 42

40

Глава 5. Организация управления проектом

Инициирование проекта

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

Устав проекта должен определять: 1. Цели проекта; 2. Перечень процессов, подлежащих автоматизации; 3. Перечень функций процессов, подлежащих автоматизации; 4. Что остается за рамками проекта (процессы, подразделения) и возможность их ох-

вата на последующих стадиях или проектах; 5. Основные результаты, говорящие о достижении целей проекта; 6. Органы управления проектом, их функции; 7. Распределение функций между заказчиком и исполнителем. Матрица ответствен-

ности; 8. Порядок документирования проекта, отчетность по проекту; 9. Порядок изменения Устава проекта; 10. Управление проблемами (отклонениями); 11. Сроки реализации проекта в целом и его стадий.

Устав проекта рекомендуется утверждать как приложение к приказу о начале реализации проекта. Часть информации, а именно, перечень процессов и функций затем попадет в тех-ническое задание и будет описан подробно. Поэтому в Уставе эта информация дается кратко. В приложении 7 дается типовой Устав проекта. В тексте типового Устава приняты следую-щие обозначения:

• <…> - треугольные скобки. Требуется подставить соответствующее название до-кумента, должности;

• {…} – фигурные скобки. Дается альтернативное понятие (название). Требуется выбрать нужное.

• ООО «Служба АСУ» - условное наименование исполнителя проекта. Если это под-разделение предприятия – нужно оставить «Служба АСУ» (или иное название), а если это юридическое лицо (например, инсорсинговая компания) - нужно подста-вить соответствующее наименование.

Изложенное в типовом Уставе (приложение 7) немного отличается от изложенного ниже. Это показывает, что Устав нужно адаптировать к условиям и масштабу конкретного проекта, возможно увеличивая или уменьшая количество рабочих групп, перераспределяя функции. Главное – не упустить важных функций, отсутствие которых может увеличить риски срыва проекта. Объем Устава можно уменьшить, утвердив Положение по управлению проектами. В этом случае, значительная часть Устава может быть перенесена в Положение, а в Уставе даются только отклонения от Положения.

Команда проекта Команда проекта состоит из:

• руководителя проекта (ориентация на результат) • координатора проекта (ориентация на процесс)

41

• рабочих групп внедрения (основное исполнительное звено) • координаторов от подразделений (ориентация на коммуникации и обучение) • секретаря проекта (при необходимости).

При формировании команды проекта необходимо учитывать личные качества и нематери-альную мотивацию участников проекта (см. Главу 3.).

Органы управления проектом В соответствии с таблицей 6 для управления проектом могут создаваться один орган управ-ления (Координационный комитет) либо два - Управляющий совет и Методический совет. Далее рассматриваются функции этих двух органов, поскольку они охватывают наиболее полный круг решаемых задач. Функции Координационного комитета зависят от «силы» ру-ководителя проекта и определяются путем сложения и частичного усечения функций двух упомянутых органов управления.

Управляющий Совет Управляющий совет – высший орган управления проектом. Целью создания Управляющего совета является разрешение противоречий и устранение административных и функциональ-ных барьеров между подразделениями, контрольные функции.

Задачи Управляющего совета:

• Рассмотрение хода выполнения проекта, внесение корректировок в план работ, принятие решения о завершении или прекращении проекта;

• Контроль бюджета проекта, графика финансирования, внесение корректировок в бюджет;

• Введение и выведение из состава Методического совета и Рабочих групп новых членов;

• Рассмотрение вопросов, по которым Методическому совету не удалось достичь согласия;

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

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

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

Методический совет Методический совет является совещательным органом. Целью создания Методического со-вета является необходимость корректировки действующих методологий выполнения БП, вы-званных внедрением АС, согласование интересов подразделений, подготовка решений об изменении регламентов выполнения БП, необходимости структурных преобразований. Ре-шения Методического совета носят рекомендательный характер и вступают в действие после утверждения Руководителем проекта или председателем Управляющего совета. Задачи Методического совета:

42

• определение состава и структуры внутреннего и внешнего документооборота, ут-верждение форм документов, определение статуса электронных документов;

• выработка рекомендаций по оптимизации БП, определение и переопределение функций персонала;

• определение методик учета, расчетов, нормирования, планирования и др.; • выработка и утверждение системы классификации и кодирования, структуры спра-

вочников, определение владельцев и совладельцев информации; • консультирование членов рабочих групп и другие вопросы.

Периодичность заседаний Методического совета – по мере необходимости, но не реже 1 раза в 2 недели. Возглавляет Методический совет, как правило, заместитель генерального директора (предсе-датель Методического совета), либо Руководитель проекта. Функции секретаря выполняет один из членов Методического совета.

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

Руководитель проекта Руководитель проекта – должностное лицо, полностью отвечающее перед руководством за выполнение проекта.

Руководитель проекта:

• выполняет обязанности и освобождается от них приказом высшего руководителя; • входит по должности в состав Управляющего совета и является заместителем

председателя Управляющего совета; • возглавляет Методический совет; • согласовывает состав Рабочих групп; • утверждает базовые документы проекта и изменения в них; • обеспечивает своевременное финансирование проекта согласно бюджету проекта; • обеспечивает проведение организационных мероприятий и контроль хода работ по

проекту; • определяет договорные отношения с поставщиками консалтинговых услуг и про-

граммного обеспечения в целях проекта; • имеет право созывать внеочередные заседания управляющего или методического

совета. Следует считать целесообразным назначение на эту должность руководителя, в ранге не ни-же заместителя высшего руководителя, выполняющего обязанности связанные с проектом по совместительству. Назначение на должность Руководителя проекта руководителя службы ИТ возможно в отдельных случаях (например, в проектах, связанных с инфраструктурой). Как правило, Руководитель проекта должен быть заинтересованным в автоматизации своего про-цесса (процессов) лицом. Специалистом же по ведению проекта должен быть координатор проекта.

43

Координатор проекта Координатор проекта осуществляет оперативное управление ходом проекта согласно про-ектным документам Управляющего совета, Методического совета или Руководителя проек-та. Координатор проекта:

• подчиняется непосредственно Руководителю проекта, выполняет его поручения; • разрабатывает проектные документы и изменения к ним, предоставляет на утвер-

ждение Руководителя проекта; • готовит планы проекта совместно с руководителями Рабочих групп; • ведет мониторинг хода проекта, готовит отчеты Руководителю проекта, Методи-

ческому совету и Управляющему совету; • готовит повестку дня Методического совета и Управляющего совета; • организовывает экспертизу документов проекта; • осуществляет функциональное руководство рабочими группами; • имеет право собирать совещания с членами рабочих групп и приглашенными.

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

Рабочие группы Как уже было отмечено выше, рабочие группы являются основными исполнителями работ по проекту. В соответствии с видами работ проекта необходимо сформировать следующие рабочие группы:

• Процессные рабочие группы; • Группу программно-технической поддержки.

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

Все члены Рабочих группы выполняют свои обязанности по совместительству и не покидают своих рабочих мест, поэтому для сбора Рабочих групп должно быть выделено отдельное по-мещение (проектная комната). Она должна быть оснащена «круглым» столом, видеопроек-тором, экраном, доской (флип-чарт), компьютером с выходом в сеть. Проектная комната ис-пользуется также для проведения заседаний секций Методического совета, других совеща-ний.

Процессные рабочие группы В процессную рабочую группу входят специалисты из подразделений-участников автомати-зируемого процесса и ответственные методологи (постановщики задач) от службы ИТ. Основными задачами Процессных рабочих групп являются:

• сбор и обработка информации о бизнес-процессах; • описание бизнес процессов согласно методике; • проверка моделей БП на адекватность (соответствие реально существующим); • выработка предложений по совершенствованию бизнес-процессов;

44

• формулировка проблем и вариантов их решений для Методического совета и Управляющего совета;

• участие во внедрении автоматизированной системы: моделирование бизнес-процессов, формирование требований к доработке функционала и отчетности сис-темы, разработка регламентов и инструкций.

Все члены Процессных рабочих групп проходят обучение методикам описания БП, модели-рования БП и соответствующему функционалу внедряемой системы автоматизации.

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

Рекомендуемое количество участников Процессных рабочих групп не больше 8-10 человек. В случае, когда автоматизируемый процесс, представлен несколькими вариациями анало-гичных функций, например: закупкой металлов занимается бюро 1, закупкой ГСМ – бюро 2, закупкой расходных материалов – бюро 3, нет необходимости включать в состав Процесс-ных рабочих групп представителей всех подразделений, важно, чтобы были представители принципиально отличающихся процессов. Участники Процессных рабочих групп, представ-ляющие несколько «типовых» функций должны провести согласование «типового» описания или макета с подразделениями-участниками.

Количество Процессных рабочих групп и их участников, несомненно, важная характеристи-ка, но главное другое - в рабочую группу должны быть включены сотрудники, которые ре-ально могут и будут работать, поэтому к участнику Процессной рабочей группы предъявля-ются следующие требования:

• быть не слишком загруженным, чтобы иметь возможность заниматься проектом, наряду с текущей работой, либо нагрузка этого сотрудника должна быть пере-смотрена руководителем подразделения;

• знать «свой» процесс в общем (а не только в виде локальных функций), понимать его цель и взаимодействие с другими «соседними» процессами;

• представлять «актив» автоматизируемого подразделения, иметь желание и спо-собность проанализировать и оптимизировать «свой» процесс;

• быть коммуникабельным; • быть способным работать с автоматизированной системой.

Руководитель Процессной рабочей группы несет персональную ответственность за автома-тизацию своего процесса, поэтому им должен быть руководитель в должности не ниже на-чальника (заместителя начальника) отдела, заинтересованный в результате внедрения и яв-ляющийся его непосредственным пользователем. По этим причинам руководителем Про-цессной рабочей группы не рекомендуется назначать сотрудника службы ИТ.

Рабочая группа программно-технической поддержки В рабочую группу программно-технической поддержки входят специалисты службы ИТ предприятия:

• Главный методолог (системный аналитик); • Главный программист (руководитель группы программирования); • Программисты; • Администраторы системные, баз данных; • Технические специалисты (установка оборудования, прокладка кабельных линий

связи и т.п.); • Администратор бизнес – модели.

Распределение участников данной группы по бизнес - направлениям (процессным рабочим группам) не требуется.

45

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

• анализирует поступившие от Процессных рабочих групп требования к разработ-ке/доработке функционала и отчетности, определяет возможность доработки, ее сложность, приоритет, необходимость формирования частного ТЗ;

• в зависимости от функционального направления, приоритета, трудоемкости опре-деляет исполнителей работ, плановые сроки, критерии завершения;

• следит за загрузкой методологов в разных группах и выполнением работ в соот-ветствии со сроками;

• согласовывает сроки и возможные изменения в связи с перераспределением работ с руководителями Процессных рабочих групп ;

• Принимает выполненную работу. Работу программистов в проекте планирует главный программист, который:

• анализирует поступившие от методологов (постановщиков) частные ТЗ, требова-ния к разработке/доработке функционала и отчетности, загрузке данных, реплика-ции;

• в зависимости от функционального направления, приоритета, трудоемкости опре-деляет исполнителей работ, плановые сроки, критерии завершения;

• следит за загрузкой программистов в разных группах и выполнением работ в соот-ветствии со сроками;

• согласовывает сроки и возможные изменения в связи с перераспределением работ с главным методологом;

• Принимает выполненную работу. Программисты осуществляют доработку/разработку функционала и отчетности системы, за-грузку исторических данных в систему, репликацию с другими системами (если нужно).

Администраторы - инсталлируют программное обеспечение, управляют доступом участни-ков проекта к АС, обеспечивают процедуры защиты и сохранности информации (резервное копирование) Технические специалисты необходимы в случае большого объема работ по установке обору-дования, прокладке кабельных линий связи и т.п. Администратор бизнес – модели6 назначается в тех случаях, когда планируется большой объем описания или изменения бизнес-процессов. Он обеспечивает качество разработки и связность всех моделей БП предприятия. Администратор бизнес – модели:

• обеспечивает целостность и актуальность библиотеки моделей БП предприятия, подготовленных Рабочими группами проекта;

• принимает непосредственное участие в разработке методики описания БП; • оказывает помощь Рабочим группам в описании и анализе БП;

6 Бизнес-модель – это совокупность описаний (моделей) бизнес-процессов

46

• осуществляет контроль качества (аттестацию) разработки моделей БП на соответ-ствие методике;

• имеет право инициировать корректировку моделей БП для обеспечения их акту-альности;

• должен в совершенстве владеть выбранными для проекта нотациями и инструмен-тарием описания БП.

Координатор от подразделения Координатор от подразделения, является связующим звеном между Процессной рабочей группой , которая занимается макетированием процесса (подпроцесса) в системе, и подраз-делением, где данный подпроцесс (подпроцессы) внедряются. Координатор от подразделе-ния обязан:

• знать функционал и документацию программы; • оказывать помощь в освоении системы пользователями; • собирать и обобщать информацию по ошибкам, замечаниям и предложениям, воз-

никающим в процессе опытной эксплуатации у пользователей, готовить предло-жения по их устранению;

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

Координатор от подразделения – это, как правило, человек молодого или среднего возраста, хорошо работающий на компьютере, коммуникабельный (который способен оказать помощь пользователям, а те готовы ее принять), заинтересованный во внедрении.

Секретарь проекта Секретарь проекта – участник проекта, в обязанности которого входит:

• регистрация и ведение архива документов и корреспонденции по проекту; • распространение информационных материалов, документов, повесток заседания

среди сотрудников предприятия; ведение протокола заседаний Управляющего со-вета и Методического совета;

• контроль исполнения протокольных решений, поручений Руководителя проекта и Координатора проекта.

Функции секретаря могут совмещаться Координатором проекта.

47

Глава 6. Оперативное управление работами по проекту Оперативное управление работами по проекту на каждом из этапов реализуется стандартным циклом PDCA:

• Планирование; • Исполнение и учет работ; • Контроль, выявление отклонений; • Принятие решений по отклонениям.

Планирование работ, распределение ресурсов В управлении проектом используется три вида планов:

• Укрупненный план проекта; • План-график этапа проекта; • Детальный план-график.

Укрупненный план проекта Планирование осуществляется сверху-вниз и начинается с формирования укрупненного плана проекта. Укрупненный план представляет собой последовательность и длительность этапов проекта (вех), в соответствии с поставленными целями и выделенными ресурсами. Укрупненный план готовится Координатор проекта, согласовывается с Руководителя проек-та и утверждается как приложение к приказу о начале реализации проекта.

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

Детальный план-график Детальный план-график формируется для каждой рабочей группы по принципу еженедель-ного скользящего планирования с горизонтом 3 - 4 недели. На ближайшие 3-4 недели план-график содержит последовательность работ конкретных исполнителей группы, плановые да-ты начала и окончания работ (до дней), критерии завершения (результаты). Желательно, что-бы результат был документально оформлен: протоколы, отчеты, акты, регламенты, инструк-ции и т.д. Детальные планы-графики работ разрабатываются совместно руководителями рабочих групп и Координатором проекта. Для возможности контроля планы должны содержать работы дли-тельностью не больше двух недель. Оптимальным является разбивка до работ длительно-стью в одну неделю. Для ведения планов проекта рекомендуется использовать программный продукт MS Project или аналогичный. Использование специализированного продукта позволит:

• вести и отслеживать иерархию планов: укрупненный план, план-график этапа, де-тальный план-график;

• отслеживать загрузку исполнителей, так как один и тот же специалист может быть участником нескольких рабочих групп;

• сохранять утвержденные планы-графики этапов как «базовые» планы и формиро-вать отчеты по отклонениям от них;

• получать графические отчеты о выполнении планов; • ранжировать задачи по важности, выделять критичные задачи, от которых напря-

мую зависит успех проекта.

48

Для разработки планов рекомендуется пользоваться приложением 3.

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

Для решения данной проблемы рекомендуется отказаться от привычного в службах ИТ пла-нирования на месяц и ввести механизм еженедельного скользящего планирования работ включающий в себя:

• учет заявок пользователей на доработку/разработку, ранжирование работ, уста-новление приоритета;

• группировка заявок и работ по проектными направлениями; • еженедельное планирование работ конкретных исполнителей на три-четыре неде-

ли вперед (по существу заключается в распределении заявок пользователей по ис-полнителям или учете уже распределенных заявок);

• еженедельная выдача исполнителям планов-заданий с закрепленными «задания-ми» на ближайшую неделю и «планами» на последующие;

• еженедельный учет выполненных работ и отклонений от плана, получение ежене-дельных отчетов по исполнителям, предоставление непосредственному руководи-телю;

Использование для планирования MS Project позволит вести планы текущих и проектных работ в одной базе, осуществлять ранжирование работ, адекватно оценивать загрузку испол-нителей, вести учет выполненных работ (в том числе с целью последующей мотивации) и как результат повысить управляемость исполнения критичных задач. Это особенно важно, когда наблюдается острый дефицит ресурсов. В этом случае рекомендуется по возможности остановить доработку старой системы, выполняя только критичные требования, а посту-пающие заявки использовать при моделировании процессов в новой системе.

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

Контроль хода проекта Контроль плана-графика осуществляется еженедельно. За поддержание плана-графика рабо-чей группы в актуальном состоянии, оперативное внесение всех изменений/дополнений от-вечает руководитель группы, либо назначенный им ответственный исполнитель. Анализ вы-полнения планов предыдущей недели осуществляется на еженедельных совещаниях. Про-цент завершения работ должен быть указан в плане за день до совещания руководителем группы либо ответственным исполнителем. Руководитель проекта должен осуществлять контроль хода проекта не реже 1 раза в месяц. В зависимости от важности этапа и текущей ситуации контроль хода проекта Руководитель проекта может осуществлять еженедельно или ежедневно. Для осуществления контроля Ко-ординатор проекта готовит для Руководителя проекта отчеты о выполнении работ по рабо-чим группам, содержащие процент выполнения работ, сравнение с базовыми планами, вели-чину и причины отклонений. Рекомендуется визуальное представление информации с ис-пользованием средств MS Project и MS Excel.

49

Управление изменениями Под изменениями понимаются любые изменения в сроках, последовательности, результатах работ. Инициаторами изменений могут быть все участники проекта. Предложения по внесе-нию изменений первоначально рассматриваются на рабочих заседаниях групп и если они яв-ляются значимыми (существенное отклонение от сроков, изменение результатов проекта, воздействие на планы других рабочих групп и т.д.) выносятся на уровень Руководителя про-екта, Методического совета, Управляющего совета, закрепляются проектными документами (приказами, протоколами и т.д.)

Управление проблемами Для обеспечения контроля за проблемами и своевременного их решения все принципиаль-ные вопросы и проблемы, возникающие у членов рабочих групп, регистрируются в специ-ально созданной для этого базе данных (например, в файле Excel) с указанием сути пробле-мы, необходимой даты решения, предполагаемого ответственного, предлагаемого решения, Ф.И.О. инициатора. Руководители рабочих групп ежедневно просматривают перечень проблем, предпринимают действия по решению, по необходимости выносят проблему на совещание Рабочей группы, приглашают необходимых специалистов.

Координатор проекта отслеживает решение проблемы, по необходимости выносит решение проблемы на соответствующий уровень (техническое совещание, Методический совета Управляющий совет).

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

• Приказы о ходе проекта (начало, реализация этапов, окончание); • Планы и регламенты проекта; • Протоколы заседаний Управляющего совета; • Протоколы заседаний Методического совета; • Протоколы совещаний Рабочих групп; • Проектную базу данных (электронную); • Отчеты Руководителя проекта; • Акты о завершении работ.

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

50

размещения в базе не является критичным. Например, все работники были ознакомлены с приказом, и его отсканированная копия размещается в базе данных. Под управляющей информацией понимается информация, которая является критичной для исполнения работ по проекту и размещение ее вызывает начало других работ. Обычно в про-екте участвуют большое количество людей, многие работы идут последовательно-параллельно (в виду жестких сроков) и проектная база используется для обмена данными между Рабочими группами. Например, Процессные рабочие группы являются «поставщика-ми» работы для других рабочих групп, и зафиксированные ими требования к доработке, к загрузке, регистрация проблем, предложений и т.д. инициируют работу других или файл «доска объявлений» позволит не терять время на сообщение информации каждому участни-ку.

Работа с проектной базой данной, ее структура, вид информации, ответственные за размеще-ние и достоверность, сроки определяются регламентирующими документами проекта. При-мерный состав базы данных проекта приведен в таблице 14. По разным причинам (отсутствие практики проектного управления, высокая стоимость) для ведения проектов на предприятиях не используются специализированные системы автомати-зации, которые позволяют погрузить управление проектами в единую информационную сре-ду. Поэтому мы рекомендуем применять как минимум MS Project и MS Excel или их бес-платные аналоги (GanttProject, OpenOffice.org).

51

Таблица 14. Состав базы данных проекта Разделы

001 Управление проектом 01.1 Планы работ 01.2 Приказы и распоряжения 01.3 Протоколы совещаний и официальная переписка 01.4 Отчеты и Акты 01.5 Технология работ по проекту 3Мониторинг проекта и проблемы.xls 3Состав рабочих групп.xls 002 Процессы КАК ЕСТЬ. Требования к автоматизации 002.1 Закупки 002.2 Продажи 002.3 Финансы 002.4 Бухучет 002.5 Экономика 3Перечень алгоритмов.xls 3Перечень документов.xls 3Перечень операций.xls 3Перечень процессов .xls 3Модель процесса КАК ЕСТЬ.pdf 003 Моделирование процессов КАК БУДЕТ. Настройка алгоритмов 003.1 Закупки 003.2 Продажи 003.3 Финансы 003.4 Бухучет 003.5 Экономика 003.6 Роли и права доступа 004 Доработка системы 004.1 ТЗ на функционал 004.2 ТЗ на отчеты 3Образец ТЗ на доработку функционала.doc 3Образец ТЗ на разработку отчета.doc 3План доработки функционала.xls 3План разработки документов.xls 005 Словари и разделы 3Перечень словарей и разделов.xls 3План загрузки словарей и разделов.xls 006 Обучение и администрирование пользователей 3Перечень пользователей и ролей.xls 3График обучения и администрирования пользователей.xls 007 Регламенты и инструкции 007.1 Регламенты 007.2 Инструкции 008 Информационные материалы 008.1 Документация на систему 008.2 Документация по управлению проектом 90 Прочее

52

Глава 7. Стадии и этапы проекта Стадии и этапы проекта создания АС во многих методиках совпадают или отличаются не-значительно. Например, стадии и этапы, определяемые ГОСТ 34.601-90 и приведены в таб-лице 15.

Таблица 15. Стадии и этапы работ Стадии Этапы работ

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС 1.2. Формирование требований к АС 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (технического предложения)

2. Разработка концепции АС 2.1. Изучение объекта 2.2. Проведение необходимых научно-исследовательских работ 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям за-казчика 2.4. Оформление отчёта о выполненной работе

3. Техническое задание. Разработка и утверждение технического задания на создание АС 4. Эскизный проект 4.1. Разработка предварительных проектных решений по системе и её частям

4.2. Разработка документации на АС и её части 5. Технический проект 5.1. Разработка проектных решений по системе и её частям (макетирование)

5.2. Разработка документации на АС и её части 5.3. Разработка и оформление документации на поставку изделий для комплек-тования АС и (или) технических требований (технических заданий) на их раз-работку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации

6. Рабочая документация 6.1. Разработка рабочей документации на систему и её части 6.2. Разработка или адаптация программ

7. Ввод в действие 7.1. Подготовка объекта автоматизации к вводу АС в действие 7.2. Подготовка персонала 7.3. Комплектация АС поставляемыми изделиями (программными и техниче-скими средствами, программно-техническими комплексами, информационны-ми изделиями 7.4. Строительно-монтажные работы 7.5. Пусконаладочные работы 7.6. Проведение предварительных испытаний 7.7. Проведение опытной эксплуатации 7.8. Проведение приёмочных испытаний

8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание

И хотя ссылаться на ГОСТ нынче не модно, состав работ нам представляется весьма разум-ным и более того, типичным. С нашей точки зрения, первые 3 стадии сводятся к изучению объекта автоматизации (включая описание бизнес-процессов), формулированию требований к АС и оформлению некоторых отчетных документов. Стадии 4,5 и 6 можно назвать техническим проектированием, моделированием или макети-рованием, в процессе которого происходит с одной стороны, настройка АС под требования заказчика, а с другой, подстройка бизнес-процессов к работе в условиях автоматизации. За-канчиваются эти стадии разработкой рабочей документации (регламентов, инструкций). Стадия 8 – «Сопровождение АС» здесь рассматривается, как часть проекта, хотя это после-проектная стадия. Этот этап можно рассматривать как резерв на непредвиденные обстоя-тельства (может составлять до 20% от совокупной длительности предыдущих этапов). Поэтому предлагается реализовывать проект в 4 стадии:

1. Предпроектное обследование 2. Техническое проектирование 3. Ввод в действие 4. Сопровождение (гарантийный/резервный срок)

53

Данный подход изображен на рис.12. Из него видно, что провести четкие грани между ста-диями не всегда возможно, поскольку процесс последовательно-параллельный. Указанные сроки являются средними для внедрения 1-2 модулей системы (например, снабженческо-сбытовая логистика и бухгалтерский учет).

Рис.12

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

• Проект всегда несет в себе нововведения, которым среда обязана сопротивляться. На преодоление сопротивления, необходимо время (возможно, речь не идет о не-больших проектах);

• Большая часть затрат на проект связана с привлечением внешних консультантов, следовательно привлекать их можно «точечно» и в необходимых случаях.

Не стоит также верить фирмам, которые предлагают слишком краткие сроки внедрения. Ес-ли они предлагают сроки, меньшие, чем на рис.11 – следует внимательно разобраться, в чем дело? Либо это некомпетентность, либо попытка «зацепить» клиента, либо перечень работ значительно уже, чем описывается в данной книге (см. приложение 3).

Обратной стороной высокой интенсивности проекта является перегрузка работников вплоть до психических срывов. Это тоже говорит за приоритет времени.

Естественно, что проект не может затягиваться надолго. Предельным сроком следует считать год, в противном случае (скорее всего) неправильно определен объем проекта (слишком ве-лик).

Предпроектное обследование Стадия предпроектного обследования может состоять из нескольких этапов. Перечень этапов приведен в таблице 16.

Таблица 16. Предпроектное обследование Этап Регламентирующий

документ Результат

Обследование предприятия. Оценка рисков

Методика обследования Отчет об обследовании

Описание БП «как есть» Методика описания БП Описания (модель) БП Выбор системы Критерии выбора Отчет, техническое задание на созда-

ние АС

Описание БП «как есть»

Выбор системы

Создание команды проекта

Обучение системе команды проекта

Обучение пользователей

Проектирование системы и БП «как будет»

Опытная экспл.

Опытно-пром. экспл.

Предпроектное обследование Техническое проектирование Ввод в действие

Обследование объекта

1,5 месяца 2,5 месяца 3 месяца 1,5 мес.

Сопро-вожде-ние.

Сопро-вожде-ние.

54

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

• функции подразделений; • документооборот подразделений

В отличие от описания процессов, которое производится «сверху-вниз», сбор информации производится «снизу-вверх», т.е. обследованию подлежат в первую очередь функции под-разделений нижнего уровня (бюро, участков, групп). Возможно описание функций отдель-ных исполнителей, если они выполняют функцию единолично и подчиняются, как правило, напрямую руководителю (например, экономист в техническом отделе). Совокупность функ-ций подразделений нижнего уровня составляет функцию подразделения верхнего уровня и т.д. При обследовании применяется «Инструкция по обследованию предприятия в целях описа-ния бизнес-процессов» (см. приложение 5), которая содержит порядок:

• Обследования функций подразделений; • Обследования документооборота; • Проведения интервью; • Документирования информации, включая формы бланков.

Для того чтобы ничего не упустить в процессе обследования иногда бывает полезно ознако-миться с типовыми процессами подобных предприятий и использовать их при описании сво-их бизнес-процессов.

Описание БП «как есть» Целесообразно выделение двух уровней процесса – верхнего и нижнего. Это делается в связи с разными целями и задачами, которые ставятся при описании и разными группами, исполь-зующими формализованное описание БП (модель БП). При описании верхнего уровня процесса главной задачей является правильное выделение функциональных блоков и связность подпроцессов (входы должны соответствовать выхо-дам, не должно быть потерянных связей). Наиболее известной и широко применяемой для этих целей методикой является SADT (Structured Analysis and Design Technique - Технология структурного анализа и проектирования), часть которой, под названием IDEF0 предлагается применять при описании верхнего уровня процесса. Подробно эта методика изложена в до-кументе [11]. Нотация верхнего уровня часто используется для формирования процессных рабочих групп.

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

Цели использования модели БП руководителями разных уровней: Руководители верхнего уровня:

• Формирование эффективной системы управления на основе процессного подхода; • Четкое разграничение ответственности и полномочий между руководителями и

подразделениями в рамках процессов; • Разработка показателей результативности процессов, методик их оценки и анали-

за;

55

• Создание механизмов (процедур и методик) непрерывного улучшения процессов предприятия;

• Подготовка к созданию и внедрению интегрированной информационной системы предприятия.

Руководители нижнего уровня и специалисты: • Разработка нормативных документов (положений), регламентирующих процессы

подразделений; • Разработка должностных инструкций и методик, определяющих деятельность ис-

полнителей в рамках процессов.

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

Таблица 17. Зависимость нотации от этапов описания бизнес-процесов Этап Объекты Нотация

Выделение БП Предприятие в целом Структурные схемы

Описание верхнего уровня БП

Управления, департаменты, производства (заводы), от-делы, цеха

IDEF0 диаграммы

Описание нижнего уровня БП

Отделы, цеха, бюро, участ-ки, группы, исполнители

Блок-схемы, таблицы, текстовое описание

Таблица 18. Объем описания бизнес-процессов Уровень описания

Уровень де-композиции

Владельцы процесса Документы

Глобальный процесс

Зам. ген. директора

Процесс Директора по направлениям, нач. управлений, департа-ментов, директора произ-водств (заводов)

Верхний

Подпроцесс Нач. отделов, цехов

- Описание БП (графические диа-граммы IDEF0, текстовая часть, альбом входящих и исходящих до-кументов)

- Положения о подразделении

Операция (функция)

Нач. бюро, участков

Нижний Действие (рабо-

та) Исполнители

- Описание БП (блок-схема, табли-цы, текст, альбом входящих и ис-ходящих документов)

- Положения о подразделении - Должностные инструкции - Рабочие (технологические) инст-

рукции

56

Выбор системы Утверждение, будто заказчику неважно знать, на какой платформе и какими средствами реа-лизована система, а важен только необходимый функционал - неверно. На сегодняшнем эта-пе развития АС происходит концентрация данного бизнеса, количество систем практически не увеличивается. Системы достигли такого уровня развития, что функционал их примерно одинаков и значение начинают иметь особенности реализации. Нормальным становится иметь несколько АС вместо одной интегрированной (или в дополнение к ней). И тут в пол-ный рост встает проблема стыковки систем, наличия в них развитых средств экспорта-импорта, репликации данных, API-интерфейсов. Конечно, гораздо удобнее (и дешевле) иметь единую СУБД, единые средства генерации отчетов (например, Crystal Reports). Впо-следствии это скажется на стоимости сопровождения и развития системы (например, владе-ние «экзотической» СУБД повлечет за собой затраты на подготовку персонала). Предлагается проверенная на практике процедура выбора систем, состоящая из 3-х этапов:

1) Отбор систем – кандидатов; 2) Рейтинговый отбор; 3) Выбор АС.

На 1-м этапе производится анализ рынка АС, изучение печатных материалов и источников Интернет, выяснение наличия внедрений по профилю деятельности, референс-визиты на родственные предприятия, проведение презентаций поставщиков решений, тестовые испытания АС (в случаях, когда поставщик на это идет). На 2-м этапе, основываясь на результатах 1-го этапа составляются рейтинговые таблицы (табл. 19,20,21). Задача данного этапа сузить диапазон выбора до 1-3 АС. Оценка АС идет по трем направлениям:

• функциональный рейтинг (наличие в АС необходимого функционала, соответст-вие его ТЗ7);

• ценовой рейтинг (стоимость начального приобретения, расходы будущих перио-дов на сопровождение и развитие, стоимость услуг по внедрению и обучению)

• организационно-технический рейтинг (например, наличие подготовленных спе-циалистов на объекте внедрения, применяемая платформа – операционная систе-ма, СУБД, опыт внедрения и их количество, требования к квалификации персона-ла, риски и т.п.).

Для каждой рейтинговой таблицы устанавливается перечень показателей и весовой коэффициент таблицы (табл. 22). В результате формируется итоговая таблица (табл. 23), которая и определяет победителей второго этапа. На 3-м этапе происходит обсуждение результатов 2-го этапа, проводятся дополнительные презентации победителей (при необходимости)

Окончательный выбор остается за первым руководителем или его заместителем – владельцем автоматизируемого процесса. Мнение службы ИТ при выборе учитывается, но не имеет решающего значения. Если для выбора АС создается коллективный орган - выбор производится голосованием его членов.

7 Решающее значение имеет наличие качественного ТЗ. Иначе объективная оценка невозможна.

57

Таблица 19. Функциональный рейтинг № Функция / Поставщик или Система Макс. значение <наименование 1> <наименование n>

1 Функция 1 3 2 Функция 2 3 3 Функция 3 3 4 Функция 4 3 5 Функция 5 3 6 Функция 6 3 7 Функция 7 3 8 Режим работы пользователей 2 9 Общие требования к системе (в целом) 2

10 Требования к количеству пользователей 2

11 Требования к интерфейсу пользователя и отчетам

2

12 Требования к взаимодействию с другими ПП

2

13 Требования к администрированию 2 14 Требования к аппаратному обеспечению 2

15 Документация, руссификация 2 Интегральная оценка: 37

Соответствие предъявляемым требованиям (1-7) 3 – полностью соответствует 2 – скорее соответствует 1 – скорее не соответствует 0 – не соответствует (отсутствует)

Соответствие предъявляемым требованиям (8-15) 2 – соответствует 1 – соответствует частично 0 – не соответствует (отсутствует)

Таблица 20. Организационно-технический рейтинг Поставщик (Система) Макс. значение <наименование 1> <наименование n>

Наличие специалистов по месту нахождения заказчика

2

Платформа (ОС, СУБД) 2 Наличие исходных текстов программ (откры-тые коды)

2

Преимущества 2 Недостатки 2 Риски 2

Интегральная оценка: 12

Значение показателя «Наличие специалистов по месту нахождения заказчика» 2 – да 0 – нет

Значение показателя «Наличие исходных текстов » 2 – да 0 – нет

Значение показателя «Платформа» 0 - одноплатформенная, на предприятии заказчика не используется 1 - одноплатформенная, применяется на предприятии заказчика 2 – многоплатформенная, одна из платформ применя-ется на предприятии заказчика

Значение показателя «Преимущества» (опыт внедре-ний, их количество, распространенность системы и т.п.) 2 – значительные 1 – средние 0 – незначительные

Значение показателя «Риски» (риск поглощения вен-дора, сильная зависимость от поставщика решения, риск срыва проекта из за отсутствия ресурсов, изме-нения цен, применения непроверенных технологий и т.п.) 0 – значительные 1 – средние 2 – незначительные

Значение показателя «Недостатки» (удаленность от объекта внедрения, повышенные требования к квали-фикации персонала, необходимость применения до-полнительных ПП и т.п.) 0 – значительные 1 – средние 2– незначительные

58

Таблица 21. Ценовой рейтинг Поставщик (Система) Макс. значение <наименование 1> <наименование n>

Стоимость лицензий 4 Годовая техподдержка 4 Стоимость платформы (ОС, СУБД) 3

Стоимость консультационных услуг (при вне-дрении)

3

Стоимость технических средств (приобретае-мых дополнительно)

3

Интегральная оценка: 17 Значение показателя «Стоимость лицензий» 4 – условно-бесплатно (открытые коды) 3 – низкая 2 – средняя 1 – высокая 0 – очень высокая

Значение показателя «Стоимость консультационных ус-луг » 3 – отсутствует (собственными силами) 2 – низкая 1 – средняя 0 – высокая

Значение показателя «Годовая поддержка» 3 – отсутствует 2 – низкая 1 – средняя 0 – высокая

Значение показателя «Стоимость технических средств» 3 – отсутствует (имеется) 2 – низкая 1 – средняя 0 – высокая

Значение показателя «Стоимость платформы» 3 – отсутствует или уже применяется 2 – низкая 1 – средняя 0 – высокая

Таблица 22. Весовые коэффициенты

Наименование Макс. зна-чение

Вес Итого Важность рейтин-га для заказчика

Функциональный рейтинг (ФР) 37 (Мф) 1 (Вф) 37 (Мф х Вф) Наиболее важно Организационно-технический рейтинг (ОТР) 12 (Мо) 2 (Во) 24 (Мо х Во) Наименее важно Ценовой рейтинг (ЦР) 17 (Мц) 2 (Вц) 34 (Мц х Вц) Важно

Таблица 23. Итоговый рейтинг Поставщик (Система) Вес <наименование 1> <наименование n>

Функциональный рейтинг (ФР) Вф Мф1 х Вф Мфn х Вф Организационно-технический рейтинг (ОТР) Во Мо1 х Во Мon х Во Ценовой рейтинг (ЦР) Вц Мц1 х Вц Мцn х Вц

Итоговая оценка:

Примечание: числовые значения в таблицах даны для примера

Рабочая документация этапа обследования Документации данного этапа должна включать:

• Утвержденный отчет об обследовании; • Утвержденные описания бизнес-процессов по установленной методике с альбома-

ми форм входящих, исходящих и внутренних документов; • Утвержденное техническое задание на создание АС

Техническое проектирование Стадия технического проектирования может состоять из нескольких этапов. Перечень этапов приведен в таблице 24.

59

Таблица 24. Этап Документ Результат (документ)

Обучение проектной команды Программа обучения Список обученного и аттестованного персонала

Техническое проектирование (макетирование) и совершен-ствование БП

Утвержденный план-график работ

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

Информационно-справочное обеспечение системы (НСИ, загрузка исторических дан-ных)

Утвержденный план-график работ

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

Документирование этапа мо-делирования

Перечень документов про-екта

Регламенты, инструкции

Обучение проектной команды Обучение проектной команды осуществляется поставщиком системы на месте и/или с выез-дом к поставщику. Обучать необходимо заложенному в систему функционалу (обзорно, по-скольку основное обучение будет в процессе проектирования) и настройке системы (разви-тие функционала, разработка новых отчетов). Этого достаточно, чтобы начать проект, но не-достаточно, чтобы реализовать. Поэтому присутствие, как минимум, одного консультанта от поставщика необходимо на весь срок внедрения. В процессе работы над проектом из состава участников сформируются свои «учителя», которые и будут обучать в массовом порядке пользователей. Следует заметить, что процесс обучения пользователей не заканчивается ни-когда в связи с ротацией кадров. Результатом этапа является понимание членами Рабочих групп функционала системы, об-щих принципов работы и настройки системы. Дальнейшее обучение производится в процес-се макетирования.

Техническое проектирование (макетирование) Реализация этапа предполагает проведение следующих видов работ:

• Выбор путей реализации имеющихся процессов средствами системы, разработка требований на доработку системы, если функционал не устраивает;

• Определение подразделений, реализующих конкретную функцию, определение состава рабочих мест;

• Определение форм документации и требований по их доработке; • Определение документооборота (порядка прохождения документов); • Определение состава справочников, реквизитного состава, системы классифика-

ции и кодирования объектов учета, владельцев справочников; • Пробные прогоны системы на тестовых данных; • Создание (загрузка) справочников с реальной информацией, которая включает:

− анализ и выверку существующей информации; − написание интерфейсных программ; − экспорт/импорт информации; − обеспечение репликации данных при ведении одинаковых справочников в раз-

ных системах; − доработка функционала и документов.

• Пробные прогоны на реальной информации с доработкой настроек системы и справочников.

В процессе макетирования заполняются рабочие таблицы базы данных проекта, которые со-держат информацию о модели бизнес-процесса в системе:

• кто, что, когда и как делает в системе, какие документы формируются;

60

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

Данная информация, во-первых, является управляющей для деятельности других участников проекта (Рабочие группы, Координатор проекта), во–вторых, используется впоследствии для формирования рабочей документации этапа (регламентов и инструкций). Обновление данной информации в проектной базе данных рекомендовано ежедневно, в конце рабочего дня. Не будет преувеличением сказать, что от достоверности и своевременности информации этапа моделирования и организации обмена ею, напрямую зависит успех проекта. Промоделированные в системе процессы демонстрируются руководителям и активу подраз-делений-участников. Спорные вопросы и вариантность выполнения функций устраняются протокольными решениями. Протоколы также используются при разработке регламентов.

Информационно-справочное обеспечение Работа по формированию информационно-справочного обеспечения системы начинается на этапе моделирования системы.

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

Часто справочники содержат большой объем данных, поэтому для удобства работы боль-шинство справочников организовано в виде классификаторов. Т.е. все записи справочника можно классифицировать по определенным характеристикам, разделить на группы (папки) и организовать в виде иерархического дерева. Такое дерево-классификатор называется струк-турой справочника. Структуризация позволяет улучшить поиск информации, вести анализ по группам информации, разграничить права пользователей при работе с данными.

Первоначальное наполнение и выверка справочников Как правило, к моменту внедрения АС значительная часть необходимой информации уже существует в электронном виде в базах данных, отдельных файлах. Перенос ее в БД системы следует начинать как можно раньше, поскольку правильно «закачать» и увязать информацию с первого раза никогда не удается. Конечно, можно начать выверять информацию и вносить недостающую можно и после первой «закачки», но правильнее и быстрее будет дорабаты-вать ее в источнике и повторять «закачки» до тех пор, пока данные не «лягут» процентов на 70-80%. Остальное уже можно сделать вручную. Выверка информации должна начинаться владельцами информации после назначения владельцев (совладельцев) справочников. Вы-верка является разовым мероприятием и если не создан механизм поддержки информации в актуальном состоянии, выверки приходится повторять, что крайне неэффективно.

Участники процесса управления справочниками Процесс управления справочниками включает функции по созданию и изменению структуры справочника, созданию и изменению данных справочника, обеспечению актуальности дан-ных в справочниках. Для осуществления указанных функций в процессе управления спра-вочниками выделяются следующие роли:

• Собственник; • Владелец (совладелец);

61

• Ответственный специалист; • Консультант • Пользователь; • Аудитор.

Собственником информации, содержащейся в БД, является предприятие в лице высшего руководителя. Организационно-распорядительным документом собственник передает права оперативного управления информационными ресурсами, установления режима и правил об-работки, защиты информационных ресурсов, доступа к ним владельцам справочников. Владелец справочника – подразделение предприятия в лице его руководителя, ответствен-ное за ведение справочника. Перечень владельцев справочников определяется регламентом. Оперативные изменения в список владельцев справочников вносятся распоряжением руко-водителя, утвердившего регламент. Владелец несет всю ответственность за правильность и полноту информации в справочнике, а также за своевременность внесения изменений в них в соответствии с регламентом и инструкциями по ведению справочников Совладелец – подразделение предприятия в лице его руководителя, осуществляющее согла-сованное с владельцем и под его руководством ведение справочника, отвечающее за часть справочника, порученную ему владельцем. При этом совладелец ведет порученную ему часть справочника, а владелец осуществляет контрольную функцию. Совладелец явно ука-зывается в перечне владельцев справочника с указанием части справочника, за которую он отвечает. Ответственный специалист - специалист, назначенный руководителем подразделения предприятия владельца (совладельца) справочника для непосредственного ведения справоч-ника (необходимо назначить не менее двух ответственных специалистов). Несет ответствен-ность за участок работ по ведению справочника (создание начальной информации, класси-фикацию и кодирование, заполнение дополнительной информации и т.п.), отведенный ему распоряжением владельца справочника. Пользователь – обученный работник предприятия, зарегистрированный в системе, исполь-зующий информацию справочников в своей работе. Аудитор системы – это работник, в обязанности которого входит ежедневный контроль за состоянием содержания справочников, отслеживание динамики изменений в них, оператив-ное информирование ответственных специалистов владельца справочника об имеющихся нарушениях. Консультант (эксперт) – компетентный, в силу своей деятельности, специалист в области информации, содержащейся в справочнике, но по каким-либо причинам не являющийся вла-дельцем/совладельцем информации. Определяется для конкретного справочника. Консуль-тация эксперта необходима при возникновении спорных вопросов, неоднозначности тракто-вок, при использовании специфической документации.

Права собственника, владельцев и пользователей приведены в таблице 25. Таблица 25. Права участников процесса управления справочниками

Уровень прав Объем прав Собственник Создание и удаление баз данных (в т.ч. справочников). Назначение вла-

дельцев. Владелец (совла-делец)

Определение структуры (разделов, каталогов) справочников, установ-ления режима и правил ведения, защиты, доступа, назначение ответст-венных исполнителей.

Ответственный специалист

Ведение справочника

Пользователь Использование информации справочников для создания рабочих фай-лов (оперативной информации)

62

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

Рабочая документация этапа проектирования Документирование предполагает разработку рабочей документации для эксплуатации систе-мы к этапу опытной эксплуатации.

Предусматривается создание 3-х видов документации: • Регламент; • Инструкция • Руководящий технический материал Регламент – это документ, описывающий процесс (подпроцесс), его ход, алгоритм.

Функция подразделения в этом процессе описывается Положением о подразделении. Регламент определяет: • Кто (подразделение, исполнитель), что (какой набор функций) и в какие сроки вы-

полняет; • Права, обязанности и ответственность исполнителей; • Какие документы возникают при выполнении функций, их формы. Порядок разра-

ботки, согласования и утверждения документов, включая сроки. В документ может включаться блок-схема алгоритма выполнения процесса (подпро-

цесса). В обязательном порядке описывается способ выполнения процесса в обычных усло-виях и при возникновении отклонений от нормального течения процесса.

Наименование регламента может начинаться со слов «Регламент …», «Порядок…», «Организация…», «Положение…

Пример табличной формы регламента приведен в приложении 6. Инструкция – это документ, описывающий действия исполнителя на конкретном ра-

бочем месте. Инструкция описывает, какие операции (работы) выполняет исполнитель на рабочем месте, и каким образом.

Наименование инструкции может начинаться со слов: «Инструкция по [выполнению функции]», например, «Инструкция по созданию сквоз-

ных технологических процессов»; «Инструкция для [рабочее место], например, «Инструкция для нормоконтролеров».

Руководящий технический материал (РТМ) – это справочники, ограничительные перечни, методики расчета, технические условия и т.п. Т.е. это информация, помогающая выполнить работу наиболее рациональным методом или накладывающая ограничения на те или иные варианты применения компонентов, методик, материалов и т.д. Часто РТМ содер-жатся в виде электронных документов или баз данных.

Изложенное выше иллюстрируется на рис. 13. Любой из этих документов (регламент, инструкция, РТМ) может быть назван стандартом предприятия (СТП).

63

Рис. 13

Ввод в действие Стадия ввода в действие может состоять из нескольких этапов. Перечень этапов приведен в таблице 26.

Таблица 26. Ввод в действие Этап Документ Результат

Обучение пользователей Программа обучения Список обученного и аттесто-ванного персонала

Опытная эксплуатация Приказ о сдаче системы в промышленную эксплуата-цию, образование приемоч-ной комиссии

Акт сдачи в промышленную эксплуатацию

Завершение проекта База данных проекта и таблица трудоемкости сдана в архив для последующего изучения

Обучение пользователей Обучение пользователей следует начинать как можно раньше (как только будут подготовле-ны свои «учителя»). С одной стороны, полученные знания без практики в значительной сте-пени утрачиваются. С другой стороны, в процессе обучения проходит боязнь перед новой системой и мы обретаем союзников при внедрении. С нашей точки зрения второе перевеши-вает первое и затраты на повторное обучение оправдываются, тем более, что в процессе вне-дрения все равно может потребоваться переобучение (например, в связи с новой версией системы).

Опытная эксплуатация Опытная эксплуатация (ОЭ) проводится в 2 этапа:

Первый этап ОЭ начинается в соответствии с разработанными на этапе макетирования вре-менными регламентами и инструкциями.

Положение о подразделе-нии

Должностная инструкция

Технологиче-ская (рабочая) инструкция Процесс

(подпроцесс)

Роль

Подразделение

Регламент процесса (под-процесса)

Должность

СТП

Руководящий технический материал

64

В течение примерно 2-х месяцев средствами системы осуществляется обработка реальных данных (договоров, счетов-фактур, накладных, ордеров и пр.) в объеме не менее 20% от об-щего документооборота. В АС должен быть представлен весь диапазон документов и пол-ный цикл их прохождения. Параллельно по этим данным производится работа в сущест-вующей системе.

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

На первом этапе опытной эксплуатации должны быть: • Обучены пользователи, участвующие в опытной эксплуатации; • Устранены несоответствия процессов и макета (алгоритма процессов), разрабо-

танного на этапе технического проектирования; • Определены и переданы Координатор проекта в виде служебных записок все тре-

бования к доработкам функционала и документов, возникшие у пользователей подразделений. После окончания 1-го этапа ОЭ требования к доработкам не при-нимаются;

• Разработана система взаимосвязи справочников АС и связанных систем; • Определены регламенты управления нормативно-справочной информацией: вла-

дельцы, совладельцы, ответственные за сопровождение справочников, порядок внесения изменений и пр.;

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

В течение 1-го этапа, по мере возможности, осуществляется сравнение и проверка соответст-вия данных новой и существующей системы по параллельно введенной информации. Следу-ет отметить, что из-за различий в методологии этого можно не достичь никогда. Поэтому не рекомендуется в качестве критерия выполнения проекта применять полное соответствие по-лученного результата действующей (заменяемой или «ручной») системе. На втором этапе (1месяц) осуществляется параллельное сопровождение новой и сущест-вующей системы в объеме 100% реальных данных (опытно-промышленная эксплуата-ция). В процессе опытно-промышленной эксплуатации должны быть:

• Осуществлены все доработки функционала и документов, возникшие на 1-м этапе ОЭ;

• Полностью определена схема рабочих мест, проведено администрирование рабо-чих мест;

• Обучены и аттестованы все пользователи, работающие с системой; • Сформирован в системе полный объем НСИ, полный объем необходимых опера-

тивных данных (остатки, движение, документы) К началу промышленной эксплуатации должны быть:

• Создан весь необходимый объем нормативно-справочной информации; • Определены и настроены рабочие места пользователей; • Назначены: администратор системы, аудитор системы, владельцы справочников; • Обучены и аттестованы пользователи, внесены необходимые изменения в должно-

стные инструкции; • Разработан недостающий функционал системы (программы, отчеты); • Разработана рабочая документация (регламенты, инструкции); • Внесены и утверждены необходимые изменения в должностных инструкциях; • Подписан акт сдачи системы в промышленную эксплуатацию.

65

Управление опытной эксплуатацией системы Управление этапом опытной эксплуатации осуществляется на 3-х уровнях:

1. Встречи рабочих групп и конечных пользователей с целью выявления и оператив-ного устранения замечаний конечных пользователей, программных ошибок;

2. Еженедельные плановые совещания Процессных рабочих групп у руководителей подразделений с участием Руководителя проекта и Координатора проекта с целью мониторинга процесса внедрения, принятия решений по несоответствиям макета и процессов и пр. График совещаний утверждается Руководителем проекта. Решения совещаний оформляются протоколом;

3. Расширенные совещания руководителей и актива подразделений, участвующих в ОЭ, по вопросам взаимодействия подразделений с участием Руководителя проек-та, Координатора проекта, Процессных рабочих групп , актива. Совещания прово-дятся по мере необходимости, решения оформляются протоколом.

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

После того, как система сдана в эксплуатацию, необходимо произвести «свертку» проекта. Опыт, накопленный в результате выполнения проекта, является ценнейшим материалом, ко-торый должен быть доступен для изучения и использования в последующих проектах. Это наиболее надежный способ избежать ошибок в будущем и снизить риски. Сдаче в архив и длительному хранению подлежит база данных проекта (табл. 12) и таблица трудоемкости (приложение 3). Кроме того, необходимо:

• Подготовить справку по фактическим затратам по проекту (по статьям затрат); • Подготовить финальные отчеты (для каталога проектов, пресс-релиза, руково-

дства); • Провести анализ документов проекта и извлечь из завершенного проекта полез-

ную информацию на будущее (сделать это нужно сразу же по завершении проекта, иначе многое забудется);

• Поместить документы проекта в архив.

66

Глава 8. Управление рисками Риски - это события, которые могут произойти и повлиять на проект, если не будут предпри-няты меры по их сдерживанию или устранению. Если риски по проекту не отслеживаются, то, как правило, возникает ситуация, когда на первые 90% работ по проекту приходится 10% затрат, а последние 10% работ требуют 90% затрат. Управление рисками производится на всех стадиях проекта от его инициации и вплоть до завершения. Наступление многих рисков предсказуемо. Цель управления рисками состоит в том, чтобы минимизировать возможный ущерб для проекта, если избежать проблемы не представляется возможным. Меры по сдерживанию рисков могут повлиять на распределение работ по проекту и их стои-мость, что повлечет внесение коррективов в рабочий и финансовый планы проекта. Ниже, в таблице 27 приведена классификация рисков по этапам проекта. Частично, она со-держит рекомендации из таблицы 4, из которой исключены рекомендации, имеющие «техно-логический» характер и не имеющие существенного значения для сдерживания рисков.

67

Таблица 27. Управление рисками Этап Виды рисков Описание и примеры рисков Реагирование на риски

Риски, связанные с природными или соци-альными явлениями

Катастрофа в серверном помещении (зато-пление, пожар)

Риски, связанные с не-стабильностью дея-тельности органов вла-сти

Неожиданные государственные меры ре-гулирования (ценообразование, налогооб-ложение, нормативы и т. п.)

Риски, связанные с эко-номической политикой государства

Кризис денежно-кредитной системы, ин-фляция, изменение курсов валют

ü Данные риски неуправляемы в том смысле, что их нельзя предотвратить (форс-мажор). Однако можно считать их частично управляемыми, так как можно умень-шить последствия и ущерб от их наступления за счет превентивных мер

ü Рекомендуется не запускать длительных проектов (особенно с переходом в новый год), на коротких проектах риски значительно ниже

Риски, связанные с раз-делением интересов разных социальных групп и ростом соци-альной активности на-селения

Вандализм, саботаж, забастовки и пр. ü Вести пропаганду социальной направленности проекта, провести грамотную PR-компанию

Риски, связанные с от-сутствием необходи-мых условий для авто-матизации

Необходимость реализации проекта заказ-чиком не осознается. Проект начинается «потому что у других есть» или под влия-нием поставщика решения

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

Внепроект-ный

Риски, связанные с от-сутствием механизма проектного управления

Отсутствует структура поддержки проект-ной деятельности. Нет регламента инве-стиционной деятельности, внедрение ИТ проектом не считается

ü Внедрить корпоративные стандарты управления проектами, проектного финансиро-вания, создать оргструктуру поддержки проектной деятельности (инвестиционный комитет, проектный офис)

Риск, не достижения целей проекта, связан-ный с неправильным выбором АС

АС выбрана без учета всех действующих факторов, без достаточного анализа, опи-раясь на некомпетентное (или ангажиро-ванное) мнение. Обычно это ведет к по-вышенным затратам либо в момент приоб-ретения, либо в будущих периодах

ü Разработать подробные и согласованные технические требования к системе ü Разработать механизм отбора систем, исключающий волюнтаристские решения (см. Гл.5)

Определение области применения проекта неясное. Не определено в полной мере, что ожидают от проекта все заинтересованные стороны

ü В Уставе проекта четко определить, какие должны быть получены результаты и како-вы основные допущения и предположения. Также данный документ нужно использо-вать как средство распределения полномочий и ответственности между участвующи-ми в проекте сторонами. Разработать матрицу ответственности по проекту

Иницииро-вание про-екта

Риск срыва проекта из-за отсутствия или сла-бого применения прак-тики управления проек-тами Неясен механизм управления проектом, в

том числе в случае отклонений от нор-мального хода работ

ü Оговорить правила делегирования полномочий (в том числе и подписания докумен-тов) при отсутствии руководителя в Уставе проекта. Назначить заместителя руково-дителя проекта, передать ему (официально, приказом) часть полномочий

68

Этап Виды рисков Описание и примеры рисков Реагирование на риски ü Создать коллегиальный орган управления проектом - Управляющий Совет, утвердить регламент его работы

ü Создать коллегиальный орган взаимодействия - Методический Совет, утвердить рег-ламент его работы

ü Регламентировать периодичность проведения рабочих совещаний. Протоколировать все решения

Нет ясности, кто несет ответственность за обеспечение проекта материальными и финансовыми ресурсами

ü В приказе на реализацию проекта назначить руководителя проекта, определить, кто отвечает за финансирование проекта, составить график платежей

ü Утвердить состав рабочих групп. Указать процент занятости членов рабочих групп в проекте (от рабочего времени), вести подробный учет работ участников проекта, ис-пользовать его при стимулировании. Установить (в уставе или приказе) ответствен-ность руководителей функциональных подразделений за невыделение ресурсов в со-гласованном объеме

Стратегия сдерживания риска не опреде-лена или не отражена в планах проекта

ü Сделать приблизительный обзор рисков, выявленных на стадии подготовки исполни-телем технико-коммерческого предложения. В рабочем и финансовом планах проекта для каждого «количественно измеримого» риска создать резерв и предусмотреть ме-ры по сдерживанию рисков

Не удается сформировать полноценные рабочие группы

ü Сделать ставку на персонал со 100% занятостью в проекте (как правило, ИТ-специалисты). Нанять отсутствующий персонал на принципах «аутстаффинга»

Риск срыва проекта из-за отсутствия необхо-димого персонала Не созданы условия для работы рабочих

групп, Методического совета ü Выделить помещение, организовать проектную комнату (круглый стол, проектор, флип-чарт)

Не запланированы (не допускаются) ре-зервы. Обычно это связано с недооценкой рисков, сложности проекта (объема и ус-ловий внедрения)

ü Запланировать временные резервы (например, введением дополнительного этапа) ü Запланировать финансовый резерв (например, введением дополнительного этапа)

Риск срыва проекта из-за ошибок планирова-ния

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

ü Применить иерархическое планирование проекта, определить критический путь ü Применить типовую модель внедрения, имея в виду типовой график, перечень работ и нормативы времени на их выполнение

Риск срыва проекта из-за изменения требова-ний по ходу проекта

Возможна смена руководства и отношения к проекту, изменения в документы проекта своевременно не вносятся

ü Подробно все документировать, результаты фиксировать для того, чтобы иметь воз-можность прервать проект на любом этапе

ü Все изменения оформлять письменно Риск срыва проекта из-за недостаточной про-работки условий дого-вора

Недостаточное внимание к заключению и исполнению договоров. Договор составлен из условий что «все хорошо», а не «все плохо» (но если считать, что все будет

ü Этапы планировать на короткие сроки (месяц), четко оговаривать результат, закры-вать этапы актами

ü Тщательно проработать форс-мажорные обстоятельства в договоре ü Прописать в договоре санкции за неисполнение условий договора. Прекращать рабо-

69

Этап Виды рисков Описание и примеры рисков Реагирование на риски хорошо, то и договор не нужен!) ты после первого случая невыполнения условий.

Предпро-ектное об-следование

Риск неполного охвата управленческого цикла и снижения ценности и эффективности внедре-ния

Не обследованы процессы управленческо-го учета. Не определен состав информации для управления, способ донесения управ-ленческой информации не ориентирован на конкретных руководителей

ü Определить руководителей, нуждающихся в информации, выяснить информационные потребности руководства и впоследствии удобно их реализовать

ü Предусмотреть оснащение рабочих мест топ-менеджеров компьютерами ü Предусмотреть выдачу информацию для топ-менеджеров на бумажных носителях ü Применить Web – интерфейс для руководителей (чтобы не изучать интерфейс АС)

Недооценка сложности решаемой задачи, отсутствие достаточных знаний, пользова-ние непроверенной, неполной, искаженной (иногда целенаправленно) информацией

ü Применить спиральную (стадиями) модель развития проекта. На первом этапе пред-ложить (запланировать) минимальные изменения или «пилотный» проект

ü Апробировать проектные решения на прототипах

Риски возникновения ошибок в проектных разработках, проектной документации

Применение непроверенных технологий и методик. Иногда хочется «быть впереди планеты всей»

ü «Используй только надежную, испытанную технологию» (восьмой принцип TPS). В технологиях лучше быть на шаг назад, чем на шаг вперед. Это снижает риск срыва проекта и обычно дешевле

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

ü Сделать описание процесса «как есть» (лучше собственными силами), чтобы осознать решаемую задачу, как часть процесса и именно так ее реализовывать

ü Предложить для реализации референтную модель (где уже прописаны необходимые изменения)

Риски противодействия со стороны персонала и части руководителей

Исполнение проектных документов игно-рируется. Часто это обусловлено отсутст-вием контроля со стороны руководителя проекта, вседозволенностью и безнаказан-ностью

ü Обеспечить контроль соблюдения установленных норм, правил и методик выполне-ния проекта

ü Организовать жесткое административное давление со стороны высшего руководства (через приказы, контроль исполнения, решения руководящих органов проекта)

ü Обеспечить своевременную эскалацию проблемы по вертикали (Координатор –> Ру-ководитель проекта –> Управляющий совет)

ü Выдавать персональные наряды на работу (ежедневно, еженедельно), обеспечить контроль исполнения, учитывать количество и качество работ при подведении итогов

ü Письменно информировать высшее руководство о ходе проекта. Сделать проект глас-ным (через прессу)

Область применения проекта корректи-руется без соответствующего управления изменениями

ü Механизм проведения изменений должен быть отражен в Уставе проекта. Следует убедиться, что основные положения и результаты предыдущего этапа зафиксированы. Обеспечить утверждение запросов на изменения с соответствующей корректировкой рабочего и финансового планов

Техническое проектиро-вание

Риски невыполнения установленной проект-ной технологии

Выделенные время и персонал не доста-точны для того, чтобы обеспечить вы-полнение этапа или требуется привлече-ние персонала, ранее не планировавшего-

ü Через механизм управления проектом внести изменения в состав рабочих групп. Ко-ординатор проекта должен представить поименный список, согласованный с руково-дителями функциональных подразделений. Определить потребность в обучении но-

70

Этап Виды рисков Описание и примеры рисков Реагирование на риски ся для использования в проекте вых членов рабочих групп Финансовые ресурсы не предоставляются вовремя и/или в полном объеме

ü Через механизм управления проектом внести изменения в объемы работ и/или график финансирования

Материальные ресурсы не предоставля-ются вовремя и/или в полном объеме

ü Оборудование, требующее подготовки (настройки, тестирования и т.п.), должно быть поставлено заранее. Объекты, требующие длительного времени ввода, должны быть подготовлены заранее. Новое программно-аппаратное обеспечение должно быть про-тестировано. Все это необходимо отразить в графике проекта

Риск выявления техни-ческих проблем на поздних стадиях

Приобретенное оборудование оказалось ненадежным и постоянно отказывает в работе

ü Использовать апробированные вне проекта технические решения. Организовать по-ставки через корпоративных поставщиков – с ними можно договориться о замене. «Уважай своих партнеров и поставщиков, ставь перед ними трудные задачи и помо-гай им совершенствоваться» (одиннадцатый принцип TPS)

ü Приобрести надежное оборудование, переместив ненадежное на участки, где данный недостаток можно компенсировать (например, резервированием) и сохранив, хотя бы частично, сделанные инвестиции

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

ü Обучить персонал, отвечающий за эксплуатацию технической инфраструктуры. Включить затраты в проект

Риск конфликта испол-нителя и заказчика из за различного понимания признаков успешного (неуспешного) завер-шения проекта

Неоднозначная оценка заказчиком и ис-полнителем результатов проекта. Проце-дуры приемки результатов этапа и проек-та в целом не согласованы с заказчиком. Заказчик пытается оттянуть момент окончания проекта из за опасений, что без исполнителя он не справится с экс-плуатацией системы

ü Исполнителю и заказчику необходимо совместно провести анализ планируемых проект-ных результатов, определить критерии качества, согласовать контрольный пример. При-казом утвердить план приемки, состав приемочной комиссии

ü Провести деловую игру ( с участием руководства), демонстрирующую зависимость ре-зультата от взаимодействия исполнителей. Показать, что при правильной эксплуатации системы получается правильный результат

Новые процессы не регламентированы или разработанные регламенты не соблюдают-ся

ü На стадии реализации проекта разрабатывать временные регламенты, которые к этапу ввода в действие преобразовывать в стандарт предприятия, подлежащий исполнению и проверке соблюдения

ü Привлекать службу качества к участию в проекте, особенно на стадии опытной экс-плуатации, когда отрабатываются новые правила

ü Создать многоуровневую систему непрерывного обучения

Ввод в дей-ствие и за-вершение проекта

Риск неприятия систе-мы частью пользовате-лей и руководителей

Переход к новым системам блокируется использованием прежних систем (заменяе-мых или «ручных»)

ü Не допускать длительной параллельной эксплуатации новой и старой систем ü Прекратить прием «ручных» документов или документов из старых систем

71

Глава 9. Управление качеством Управление качеством проекта мало чем отличается от управления качеством любого про-цесса. Принципы этого управления соответствуют ISO 9001. Соответственно можно приме-нять инструменты и методы обеспечения качества, такие как «5 почему», диаграмма Исика-вы и другие. Безусловно, применимы и методы TPS, объединенные под общим названием «Правильный процесс дает правильный результат».

Следует разделять качество процесса реализации проекта и качество продукта проекта (см. рис. 2).

Качество процесса определяется применением специальных методик управления проектами, зафиксированных в Уставе проекта, организационно-распорядительных документах.

Качество продукта процесса подтверждается сравнением заданных параметров (отраженных ТЗ) с реально полученными. Следовательно, управление качеством продукта процесса со-стоит в своевременном утверждении изменяющихся параметров продукта и корректировка ресурсов проекта (в случае серьезных изменений в требованиях). Возможно, потребуется изменение процедуры приемки продукта проекта. Если нет заранее оговоренных требований к продукту проекта, определить качество самого продукта не представляется возможным. В большинстве случаев это приводит к конфликту между заказчиком и исполнителем.

Процесс управления качеством можно разбить на подпроцессы: • Планирование качества • Обеспечение качества • Контроль качества

Минимальный объем выполняемых работ по управлению качеством приведен в таблице 28.

Таблица 28. Управление качеством Подпроцесс Качество процесса Качество продукта проекта Планирова-ние качества

Анализ доступных ресурсов (по ко-личеству и качеству), адаптация ти-пового регламента управления про-ектом к имеющимся условиям, раз-работка Устава проекта. Разработка графика создания продук-та процесса и контрольных точек.

Разработка требований к продукту (ТЗ) и регламента внесения измене-ний в ТЗ (можно отразить в плане управления качеством или в уставе проекта).

Обеспечение качества

Мониторинг хода проекта, выработка предложений по улучшению, приме-нение корректирующих действий. При необходимости внесение изме-нений в Устав, в состав и объем ре-сурсов (приказы, решения органов управления проектом)

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

Контроль качества

Проверка соблюдения установлен-ных регламентов и стандартов, ка-сающихся процесса (например, веде-ния базы данных проекта).

Проверка качества продукта (тести-рование, верификация). Проверка со-блюдения установленных регламен-тов и стандартов, касающихся про-дукта (например, оформления доку-ментов).

72

Глава 10. Бизнес-процессы предприятия Данный раздел не относится впрямую к управлению проектами, но часто бывает полезен при выделении и описании бизнес-процессов, разногласиях со Службой качества. Перечень процессов производственного предприятия приведен ниже (табл. 29). Он является наиболее полным, перечень БП других предприятий (например, снабженческих, сбытовых) получается усечением данного типового перечня. На многих предприятиях часть процессов выведена на аутсорсинг. Группировка процессов произведена в соответствии с ISO 9001. Декомпозиция процессов до функций приведена в приложении 4.

Таблица 29. Перечень процессов

Процессы жизнен-ного цикла

1. Изучение рынка и потребностей потребителей 2. Управление конструкторско-технологической подготовкой произ-

водства 3. Управление основным производством 4. Управление закупками (снабжением) 5. Управление продажами (сбытом) 6. Управление техническим обслуживанием (сервисом) и ремонтом

выпускаемой техники

Процессы менедж-мента ресурсов

7. Управление финансами и экономикой 8. Управление трудовыми ресурсами 9. Управление вспомогательным производством (изготовлением не-стандартного оборудования, инструмента, технологической осна-стки)

10. Управление ремонтами оборудования 11. Управление энергобеспечением 12. Управление строительством и ремонтом зданий и сооружений 13. Управление информационными технологиями и созданием АС 14. Управление телекоммуникациями и связью 15. Управление транспортом 16. Управление контрольными и измерительными приборами

Процессы ответст-венности руково-дства

17. Стратегическое управление 18. Управление улучшениями и изменениями 19. Управление охраной окружающей среды 20. Обеспечение безопасности 21. Юридическое обеспечение 22. Управление документами

73

Не все процессы (или его подпроцессы) могут подлежать автоматизации. Состав автоматизируемых процессов и последовательность их автоматизации в каждом конкретном случае определяется приоритетами. С нашей точки зрения есть 7 тесно увязанных приоритетных процессов («синергетический куб»), автоматизация которых должна дать основной экономический эффект (рис.14).

Рис.14

Управление сервисом и отношениями с кли-ентами

Управление трудовыми ресурсами (Кадры и Зарплата)

Управление финансами и экономикой

Управ-ление закуп-ками

Управление производством

Управ-ление реали-зацией

Конструкторско-технологическая под-готовка производства

74

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

В согласовании документов на АС (концеп-ция, программа, ТЗ) участвует большое коли-чество людей. Часто они не понимают о чем идет речь, не представляют механизмов реа-лизации. Непонимание и неуверенность (а подпись ставить нужно!) заставляют их тре-бовать все новых и новых пояснений. Это может затянуть разработку документа до бес-конечности, затормозить проект. Требуется воля руководства, чтобы поверить разработ-чику и прекратить этот процесс. Часто фор-мально правильная процедура («пригласить друзей взглянуть на полотно») может превра-титься в своего антипода, похоронив под бю-рократией здравый смысл.

С.Михалков. «Слон-живописец» Слон-живописец написал пейзаж, Но раньше, чем послать его на вернисаж, Он пригласил друзей взглянуть на полотно: Что, если вдруг не удалось оно. … Все пожеланья принял Слон. Опять за краски взялся он И всем друзьям по мере сил Слоновьей кистью угодил, … Картина у Слона готова, Друзей созвал художник снова. Взглянули гости на пейзаж И прошептали: "Ералаш!" Мой друг! не будь таким слоном: Советам следуй, но с умом! На всех друзей не угодишь, Себе же только навредишь.

Нередко на предприятии появляется человек, который говорит руководству, что все можно сделать просто, быстро, дешево и незаметно для пользователей. Это именно то, что хочет слышать руководство от своих служб ИТ, но не слышит. И тогда этому человеку оказыва-ется полное доверие и возможность решить наболевшие проблемы. Конечно, все кончится плохо (сложно, долго, дорого), но это те граб-ли, на которые так хочется наступить.

И.Крылов. «Щука и кот» Беда, коль пироги начнет печи сапожник, А сапоги тачать пирожник: И дело не пойдет на лад, Да и примечено стократ, Что кто за ремесло чужое браться любит, Тот завсегда других упрямей и вздорней; Он лучше дело все погубит И рад скорей Посмешищем стать света, Чем у честных и знающих людей Спросить иль выслушать разумного совета.

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

И.Крылов. «Мартышка и очки» "Тьфу пропасть! - говорит она, - и тот дурак, Кто слушает людских всех врак: Все про Очки лишь мне налгали; А проку на волос нет в них". Мартышка тут с досады и с печали О камень так хватила их, Что только брызги засверкали. К несчастью, то ж бывает у людей: Как ни полезна вещь, - цены не зная ей, Невежда про нее свой толк все к худу клонит; А ежели невежда познатней, Так он ее еще и гонит.

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

И.Крылов. «Булат» "Скажи, на что вся жизнь твоя похожа? И если про Булат Так много громкого неложно говорят, Не стыдно ли тебе щепать лучину, Или обтесывать тычину, И, наконец, игрушкой быть ребят?" - "В руках бы воина врагам я был ужасен, - Булат ответствует, - а здесь мой дар напрасен;

75

ба, но такое отношение к ней не сделает ее сильней.

Так, низким лишь трудом я занят здесь в дому. Но разве я свободен? Нет, стыдно-то не мне, а стыдно лишь тому, Кто не умел понять, к чему я годен".

Много проектов заканчивается неудачно, по-тому, что руководство не считает задачу сложной, не видит всех «подводных камней», поручает проект непрофессионалам. В коман-ду проекта часто откомандировываются те, кого не жалко отдать и от кого мало что зави-сит.

И.Крылов. «Скворец» У всякого талант есть свой; Но часто, на успех прельщаяся чужой, Хватается за то иной, В чем он совсем не годен. А мой совет такой: Берись за то, к чему ты сроден, Коль хочешь, чтоб в делах успешный был конец.

Заказчик (руководство, функциональные службы) плохо понимает, чего он хочет от системы, но его ожидания завышены. Иногда, давление руководства, зажатого сроками реа-лизации той или иной задачи (которую нужно было решать вчера), доводит ситуацию до аб-сурда, но это оправдывается важностью зада-чи. В конечном итоге виноватой оказывается служба ИТ, которая «не захотела» решить за-дачу.

Л. Филатов. «Про Федота-стрельца, удалого мо-лодца» Исхитрись-ка мне добыть То-Чаво-Не может быть! Запиши себе названье, Чтобы в спешке не забыть! А не выполнишь к утру - В порошок тебя сотру, Потому как твой карахтер Мне давно не по нутру! Так что неча губы дуть, А давай скорее в путь! Государственное дело - Ты ухватываешь суть?

Все чаще и чаще дефицит кадров становится непременным атрибутом проекта. И не всегда его можно преодолеть деньгами.

Л. Филатов. «Про Федота-стрельца, удалого мо-лодца» Кабы здесь толпился полк - В пререканьях был бы толк, Ну а нет - хватай любого, Будь он даже брянский волк!..

Данная книга не является методикой или учебным пособием, не содержит кейсов и вопросов для самопроверки. Это скорее некая философия терпимого отношения к имеющимся (всегда разным) условиям ведения проектов, прагматический взгляд на способы решения непростых проблем, с которыми приходится сталкиваться при внедрении автоматизированных систем.

Эта книга для оптимистов, которые верят, что есть на Земле место, где они очень нужны!

Г.Горин. «Тот самый Мюнхгаузен» "Я понял, в чем ваша беда. Вы слишком серьезны. Серьезное лицо - еще не признак ума, господа. Все глу-пости на Земле делаются именно с этим выражением. Вы улыбайтесь, господа, улыбайтесь!"

76

Приложения

Приложение 1. Термины и определения Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций Бизнес-процесс (БП) - Устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя. Процесс протекает в соответ-ствии с управляющими директивами, вырабатываемыми на основе целей деятельности. В ходе процесса потребляются ресурсы.

Модель БП - Графическое, табличное, текстовое, символьное описание бизнес- процесса ли-бо их взаимосвязанная совокупность.

Макет - функциональный прототип АС, реализующий вариант БП «как будет», предназна-ченный для проведения опытной эксплуатации

PDCA – управленческий цикл, в т.ч.: Plan – планирование какой либо деятельности (план); Do – исполнение и учет этого исполнения (факт); Check – контроль и анализ результатов деятельности Act – принятие решения по отклонениям и/или совершенствованию деятельности

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

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

Aутсорсинг (англ. outsourcing: внешний источник) — передача организацией определенных функций на обслуживание другой компании, специализирующейся в соответствующей об-ласти. В отличие от услуг сервиса и поддержки, имеющих разовый, эпизодический, случай-ный характер и ограниченных началом и концом, на аутсорсинг передаются обычно функции по профессиональной поддержке бесперебойной работоспособности отдельных систем и ин-фраструктуры на основе длительного контракта (не менее 1-2 лет).

Аутстаффинг (англ. outstaffing — вывод персонала за штат) — привлечение компанией вне-штатного специалиста (фрилансера), имеющего соответствующие знания, профессиональные навыки и опыт на время выполнения определённого проекта. В нашем случае мы понимаем аутстаффинг как замещение недостающего собственного ресурса – внешним ресурсом, кото-рым мы управляем. Инсорсинг — создание собственных автономных структурных единиц (компаний), оказы-вающих специализированные услуги как подразделениям предприятия, так и внешним контрагентам. Поступают обычно так: отбирают стандартные, общие для нескольких под-разделений оперативные процессы и поручают выполнять их автономному центру совмест-ного обслуживания. За оказанные подразделениям компании услуги он взыскивает с каждого из них плату, пропорциональную объему услуг. Чаще всего инсорсинг применяют для про-цессов, связанных с финансами, трудовыми ресурсами и информационными системами.

77

Приложение 2. Причинно-следственная диаграмма для неудачного проекта

Рис. А

Проект внедре-ния АС потер-пит неудачу

Руководство в прин-ципе понимает необ-ходимость реализа-ции проекта, но реально не оказывает ему поддержки

1

Руководитель проекта лично не заинтересован в результате

Отсутствует системный подход к проекту. Проект рассматривается вне связи с общей концепцией автоматизации.

Руководство не связывает проект с оптимиза-цией системы управления и считает, что ин-форматизация - это дело службы ИТ

Руководство не доверяет решениям, предла-гаемым собственными службами ИТ

Руководство не считает задачу сложной, не видит проблем ее формализации и реализации

2

3

Цели руководства и автоматизируемых подраз-делений не совпадают

Желания совершить изменения при реа-лизации проекта у большинства участ-ников проекта не наблюдается

6

Сотрудники не готовы объединиться в команду

Сроки выполнения работ не выдерживаются. Бюджет проекта превышается

Проект продвигает-ся, но с большими трудностями

Директивы от двух начальников - функ-ционального и про-ектного противоречат друг другу

Заказчики консультант неоднозначно понима-ют цели и задачи проекта

Имеет место неэффективная координация работ по проекту

Персонал в целом не готов (не способен) к приобретению новых знаний и навыков, изме-нению стиля поведения

Способность закре-пить изменения (соблюдать новые правила) отсутствует

Люди не считают, что информация является ценнейшим ресурсом, они его владельцы, и у них есть обязательства по отношению к ней

Низкая исполнительская дисциплина - разрабо-танные регламенты не выполняются в связи с отсутствием контроля.

У заказчика существуют технические сложно-сти (сеть, рабочие места)

3

6

I II III

Руководство недовольно неспособностью службы ИТ оперативно решать насущные задачи

Заказчики не оплачивает выполненные работы

78

Продолжение приложения 2

Рис. Б

Предыдущие проекты изменений потерпели неудачу или не принесли ожидаемого эффекта

Руководство не доверяет решениям, предлагаемым собственными службами ИТ

Руководство не считает задачу сложной, не видит проблем ее фор-мализации и реализации

Слабый кадровый состав службы ИТ

Отсутствует лидер службы ИТ

4 Недостаточная и/или необъективная информация об опыте аналогичных внедрений, затратах и результатах

Отсутствует практика проектного управления.

Система была выбрана неправильно (не соответствовала требованиям, реальной ситуации)

III IV V

Информация, содержащаяся в АС топ – менеджерами не востребована

Топ – менеджеры не привыкли работать с экраном

Для управления не требовался большой объем информа-ции

Нет информации рассчитанной на топ - менеджеров

Неудобный интерфейс

Плохая управляемость коллективом ИТ

Устаревшие технологии

Квалификация специалистов не соответ-ствует современному уровню

Недостаточно обоснована польза для бизнеса Руководство недовольно неспособностью службы ИТ оперативно решать насущные задачи

Текучесть кадров

Сложная структура управления службой ИТ

Отсутствие лидеров по направлениям

Не выделяются деньги на приобрете-ние новых технологий

Не выделяются деньги на обучение

Организация работ не позволяет использовать специали-стов невысокой квалификации

Отсутствует материальная мотивация

Отсутствует нематериальная мотивация

Недостаточная информированность об успехах и достижениях службы ИТ

Непонятная руководству документа-ция

Отсутствие мероприятий по пропа-ганде ИТ-решений

Начальник службы ИТ не считает этот вопрос важным

Руководство не считается заказчиком систем, документ рассчитан на специалиста

79

Продолжение приложения 2

Рис. В

Цели руководства и автоматизируемых подразделений не совпадают Персонал настроен к внедрению враж-

дебно, т.к. опасается утери ряда тене-вых льгот,

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

Люди не хотят делиться ценной ин-формацией т.к. это является их конку-рентным преимуществом

Внедрение ИТ - это перераспределение функций и полномочий (власти)

Несоответствие бизнес-процессов и структуры управле-ния (Процессы раздроблены, имеются функциональные барьеры. Владельцев процессов нет или они назначены формально).

2

Часть персонала теряет влияние на руководителя, воз-можность дополнительного заработка. Есть шанс поте-рять работу. Есть чувство опасности и неопределенно-сти.

6

Сотрудники автоматизируемых под-разделений не ассоциируют себя со всем коллективом предприятия (хол-динга). Отсутствует единство в руководстве

Процессы считаются незыблемыми. Предпринимается попытка автомати-зировать существующие процессы.

Руководство не связывает проект с оптимизацией системы управления и считает, что информатизация - это дело службы ИТ

Персонал не готов взять на себя дополнительные (дру-гие) функции, а главное, ответственность за полноту и достоверность вводимой информации

3

Руководитель проекта лично не заинте-ресован в результате

Отсутствует системный подход к про-екту. Проект рассматривается вне связи с общей концепцией автоматизации.

Руководитель назначен формально (по должности, по традиции, по возрасту)

Утвержденная концепция автоматизации отсутствует

Проекту не уделяется должного внима-ния, т.к. непонятна его роль

2 Отсутствует какое либо описание автоматизируемого процесса или оно не соответствует реальному

Роль руководителя проекта не понимается или не оцени-вается

III IV V

80

Продолжение приложения 2

Рис. Г

Сотрудники не готовы объединиться в команду

В рабочую группу вошли те, кого не жалко отдать и от кого мало что зави-сит

Требования постоянно меняются, зафиксированные требования мало что значат

Идет реорганизация, процессы не устоялись

Заказчики консультант неоднозначно понимают цели и задачи проекта

Коммуникации затруднены, общение участников проекта эпизодическое

Имеет место неэффективная координа-ция работ по проекту

Сроки выполнения работ не выдержи-ваются. Бюджет проекта превышается

Внедрение отдано на откуп исполнителю (консультанту)

Отсутствует подробное техническое задание.

Не проведены пробные испытания (тестовая эксплуата-ция, пилотный проект)

Специалисты по управлению проекта-ми у заказчика и исполнителя отсутст-вуют

Недооценена сложность проекта

1, 8

3

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

Изменения в группах внедрения (уход, замена)

4

Механизм корректировки сроков и бюджета отсутствует

Не выполняется устав (регламент) проекта

Роль коммуникаций недооценена

5

7

Заказчик плохо понимает, чего он хочет от системы (программы), но его ожидания завышены

Временные резервы не предусмотрены

Финансовые резервы не предусмотрены

Слабая мотивация участников проекта (материальная и нематериальная)

8

III IV V

81

Продолжение приложения 2

Рис. Д

Заказчики не оплачивает выпол-ненные работы

У заказчика нет денег

У заказчика есть деньги, но он не хочет их пла-тить

Просчеты на стадии инициирования проекта

Заказчик считает, что таким образом он заставляет испол-нителя работать лучше

Заказчик показывает свою власть над исполнителем

Безнаказанность Заказчика В договоре не прописаны санкции за неисполнение условий договора

У заказчика есть нефинансовые рычаги давления на исполнителя

Плохо прописаны результаты этапов проекта

Исполнитель срывает сроки выполнения этапов проекта

III IV V

82

Продолжение приложения 2

Рис. Е

Персонал в целом не готов (не спосо-бен) к приобретению новых знаний и навыков, изменению стиля поведения

Люди не привыкли к самостоятельной обработке информации в системе. Им легче дать задание службе АСУ

Люди не считают, что информация является ценнейшим ресурсом, они его владельцы, и у них есть обязательства по отношению к ней

Низкая исполнительская дисциплина - разработанные регламенты не выпол-няются в связи с отсутствием контроля.

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

Часть старых (а иногда и молодых) работников сопротивляется переменам, т.к. не хочет ничего менять

Люди понимают, что изменения нуж-ны, но ничего не хотят для этого де-лать.

У заказчика эксплуатируются устаревшие системы или программы собственного производства, отказаться от которых сложно

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

У заказчика существуют технические сложности (сеть, рабочие места)

Отсутствует или недостаточен бюджет для приобретения технических и про-граммных средств

Раздутые штаты служб, что приводит к необоснованно большому количеству АРМ (высокая цена АС большой объем внедрения)

Устаревшая технология обработки информации

3

Не действует СМК 6

6

7

Отсутствует система непрерывного обучения

Отсутствует необходимая квалификация персонала

III IV V

83

Продолжение приложения 2

Рис Ж

Тщательно проработать форс-мажорные обстоятельства в договоре

Применить спиральную (стадиями) модель развития проекта. На первом этапе предложить минимальные изменения или «пилотный» проект

Предложить для реализации референтную модель (где уже прописаны необходимые изменения)

Обучить специалистов по ИТ методике описания процессов с использованием спе-циального ПО. Описать процессы «как есть»

Планировать этап сопровождения и мониторинга результатов, совместно со служ-бой качества контролировать выполнение регламентов (стандартов)

Провести предпроектное обследование, разработать подробное ТЗ

Сделать описание процесса, чтобы осознать решаемую задачу, как часть процесса и именно так ее реализовывать

Подробно все документировать, результаты фиксировать для того, чтобы иметь возможность прервать проект на любом этапе

Этапы планировать на месяц, закрывать этапы актами

Несоответствие бизнес-процессов и структуры управления (Процессы раздроблены, имеются функциональ-ные барьеры. Владельцев процессов нет или они назначены формально)

Утвержденная концепция автоматиза-ции отсутствует

Идет реорганизация, процессы не устоялись

Отсутствует подробное техническое задание

Не проведены пробные испытания (тестовая эксплуатация, пилотный проект)

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

На предприятии в различных системах содержится большое количество не увязанной между собой информации, применяется несколько однотипных справочников, систем кодирования

Раздутые штаты служб, что приводит к необоснованно большому количеству АРМ (высокая цена АС большой объем внедрения)

Отсутствует какое либо описание автоматизируемого процесса или оно не соответствует реальному

Не действует СМК (несмотря на нали-чие сертификата)

Отсутствует единство в руководстве

Система была выбрана неправильно (не соответствовала требованиям, реальной ситуации)

При выборе системы обратить внимание на возможность быстрого и удобного изменения функционала, настроек

Разработать и утвердить концепцию автоматизации предприятия (холдинга)

Разработать механизм отбора систем, исключающий волюнтаристские решения

Подготовить (вместо концепции) ряд взаимоувязанных документов, утвердив их у отдельных руководителей

Обучить ключевых пользователей функционалу АС с целью ознакомления с воз-можными вариантами исполнения бизнес-процессов

Привлекать СК участию в проекте, особенно на стадии опытной эксплуатации, когда отрабатываются новые правила

На стадии реализации проекта разрабатывать временные регламенты, которые затем преобразовывать в СТП

Не допускать длительной параллельной эксплуатации новой и старой систем. Сде-лать интерфейс от новой к старой системе, запретить ввод в старую систему

Отказаться о кодирования вообще (современные системы это позволяют)

Разработать регламент идентификации и кодирования объектов учета

V Решение

84

Продолжение приложения 2

Рис. З

В приказе на реализацию проекта указать процент занятости членов рабочих групп в проекте (от рабочего времени), вести подробный учет работ участников проекта, использовать его при стимулировании

Раздробить функции на мелкие роли

Написать подробные инструкции

Создать операторские группы (для временной замены неспособных к обучению)

Выявить способных к обучению на ранних стадиях проекта

Сделать ставку на персонал со 100% занятостью в проекте (как правило, ИТ-специалисты) Персонал не готов взять на себя дополни-

тельные (другие) функции, а главное, ответственность за полноту и достовер-ность вводимой информации

Отсутствует система непрерывного обучения

Создать систему многоуровневую систему непрерывного обучения

Организовать жесткое административное давление со стороны высшего руково-дства (через приказы, контроль исполнения, решения руководящих органов проекта)

Выявить функциональных (неформальных) лидеров, обеспечить им материаль-ную и моральную поддержку. Способов много!

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

Часть персонала теряет влияние на руководителя, возможность дополни-тельного заработка. Есть шанс поте-рять работу. Есть чувство опасности и неопределенности.

Обеспечить эскалацию проблемы по вертикали Координатор –> Руководитель проекта –> Управляющий совет (несмотря на возможность испортить отношения с функциональным руководителем)

Создать коллегиальный орган управления проектом - Управляющий Совет, утвердить регламент его работы

Создать коллегиальный орган взаимодействия - Методический Совет, утвердить регламент его работы

Отсутствует необходимая квалифика-ция персонала

Блокировать неправильные действия пользователей (программно, организацион-но)

Автоматизировать ввод данных (штихкод)

Все изменения оформлять письменно

Не выполняется устав (регламент) проекта

Слабая мотивация участников проекта (материальная и нематериальная)

Протоколировать все решения

На этапе опытной эксплуатации провести деловую игру (в учебном классе) что-бы показать взаимозависимость всех участников процесса, от кладовщицы до руководителя

V Решение

85

Продолжение приложения 2

Рис. И

Организовать проектную комнату (круглый стол, проектор, флип-чарт)

Роль руководителя проекта не понима-ется или не оценивается

Привлечь внешнего независимого управляющего проектом (руководителя проекта)

Предоставить (официально) больше полномочий координатору проекта (ГИПу)

Назначить заместителя руководителя проекта, передать ему (официально) часть полномочий

Оговорить правила делегирования полномочий (в том числе и подписания докумен-тов) при отсутствии руководителя

Запланировать финансовый резерв (например, введением дополнительного этапа)

Запланировать временные резервы (например, введением дополнительного этапа)

Финансовые резервы не предусмот-рены

Временные резервы не предусмотре-ны

Выдавать персональные наряды на работу (ежедневно, еженедельно)

Функциональные группы сделать небольшими, руководителя (лидера) группы назначить из работников службы ИТ

Вошедшим в группу специалистам подразделений поручается техническая работа, разбитая на мелкие части

Заменить ключевых специалистов подразделений специалистами службы ИТ или консультанта (с соответствующей корректировкой сроков и затрат)

Необходимый персонал для формиро-вания рабочих групп у функциональ-ных подразделений отсутствует

Четко определить распределение обязанностей заказчика и исполнителя (Устав проекта). Разработать матрицы ответственности по проекту

Применить автоматизацию управления проектами, начиная с планирования и до оперативного уровня

Применить типовую модель внедрения, имея в виду типовой график, перечень работ и нормативы времени на их выполнение

Применить иерархическое планирование проекта, определить критический путь

Создать список типовых работ, вести и постоянно уточнять нормативы на выпол-няемые работы после каждого проекта

Отсутствует практика проектного управления

Издать «Блокнот участника проекта» с описанием целей и задач, укрупненного графика, выдержек из устава проекта, списком участников, их данными для связи (раздается всем участникам проекта)

Автоматизировать ведение проекта (электронные коммуникации, база данных про-екта, контроль исполнения поручений)

Регламентировать периодичность проведения совещаний

Роль коммуникаций недооценена

V Решение

86

Продолжение приложения 2

Рис. К

Вывести функцию на аутсорсинг

Отсутствует лидер службы ИТ Предложить услуги независимого консультанта

Взять руководство проектом на себя (заказчика). Нанимать консультантов на прин-ципах «аутстаффинга»

Слабый кадровый состав службы ИТ

Внедрение отдано на откуп исполнителю (консультанту)

Для управления не требовался большой объем информации

Неудобный интерфейс

Сложная структура управления службой ИТ

Отсутствие лидеров по направлениям

Организация работ не позволяет исполь-зовать специалистов невысокой квали-фикации

Отсутствует материальная мотивация

Отсутствует нематериальная мотивация

Выяснить информационные потребности руководства и удобно их реализовать

Упростить структуру, укрупнить подразделения (кадровый маневр), сократить чис-ленность

Изучать и использовать методы нематериальной мотивации

Предусмотреть выдачу информацию на бумажных носителях

Определить руководителей, нуждающихся в информации

Находить и воспитывать лидеров (постоянно), решая для них вопрос оплаты инди-видуально

Использовать обучение, как нематериальный стимул, включать затраты на обучение в проекты

Топ – менеджеры не привыкли работать с экраном

Предусмотреть оснащение рабочих мест топ-менеджеров компьютерами

Применить Web – интерфейс для руководителей (чтобы не изучать интерфейс АС)

Организовать процесс таким образом, чтобы задействовать специалистов разной квалификации

Недостаточно обоснована польза для бизнеса

Начальник службы ИТ не считает этот вопрос важным

Руководство не считается заказчиком систем, документ рассчитан на специа-листа

Начальнику службы ИТ необходимо выступать на совещаниях, конференциях, публиковаться в прессе, много лично общаться с менеджерами всех уровней (в т.ч. неформально)

Разрабатывать понятные документы в терминах бизнеса, писать «красивые» отчеты

V Решение

В договоре не прописаны санкции за неисполнение условий договора

У заказчика есть нефинансовые рычаги давления на исполнителя

Плохо прописаны результаты этапов проекта

Исполнитель срывает сроки выполнения этапов проекта

Своевременно вносить изменения в планы работ по проекту

Делать этапы короче (месяц) четко оговаривать результат

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

Упреждать нежелательные действия заказчика (письменно информировать высшее руководство о ходе проекта)

Сделать проект гласным (через прессу). Пресса – тоже власть

Просчеты на стадии инициирования проекта

87

Приложение 3а. Состав работ и их трудоемкость в проектах по автоматизации управ-ления финансово-хозяйственной деятельностью.

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

§ Подготовка заявки на проект 8 16 24 § Подготовка приказа и назначение руководи-теля, разработка укрупненного плана- графика, установление KPI

16 8 24

§ Подготовка устава (описания) проекта 16 8 24 § Формирование рабочих групп; 8 40 48

Инициирование проекта

§ Организация и оборудование проектного офиса

0 24 24

Итого: 48 96 144 § Планирование работ по обследованию и опи-санию БП

16 16 32

§ Разработка структуры базы данных проекта; 8 0 8 § Обучение рабочих групп методике обследо-вания и описания БП

40 0 40

§ Обследование объекта 240 480 720 § Описание процесса "как есть"* 240 480 720 § Подготовка детального плана реализации проекта

24 8 32

§ Разработка ТЗ 160 40 200

Предпроектное обследование

§ Разработка регламента создания, приемки, хранения ПО

24 24 48

Итого: 728 1024 1752 § Планирование (перепланирование) этапа 16 8 24 § Инсталляция системы и начальное админи-стрирование

24 16 40

§ Обучение системе команды проекта и ключе-вых пользователей;

60 0 60

§ Макетирование (проектирование системы "как будет"), в т.ч.

704 1440 2144

§ Определение ролей пользователей**; § Настройка модели в системе** § Тестирование созданной модели; § Донастройка по результатам тестирова-ния (без изменения функционала)

§ Разработка документов по процессам (регла-менты) и ролям (инструкции), в т.ч.

120 1120 1240

§ Разработка перечня документов, требо-ваний к оформлению

§ Разработка регламентов*** § Разработка инструкций*** § Разработка альбома ролей и прав § Описание настроек § Доработка функционала системы, в т.ч. 320 480 800 § Разработка частных ТЗ на доработку § Выполнение доработок и тестирование § Документирование доработок и расшире-ний системы.

§ Доработка отчетов системы, в т.ч. 320 480 800 § Разработка проектных решений по соста-ву отчетности, очередности разработки

§ Разработка отчетных форм § Разработка системы ведения НСИ, в т.ч. 80 160 240 § Разработка проектных решений по соста-ву НСИ (справочники, классификация, кодиро-вание)

§ Разработка регламента ведения НСИ

Техническое проектиро-вание

§ Перенос начальных и исторических данных, 160 480 640

88

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

в т.ч. § Разработка проектных решений по пере-носу начальных и исторических данных.

§ Разработка и тестирование программ переноса данных.

§ Подготовка основных и исторических дан-ных.

§ Тестовый перенос основных и историче-ских данных.

§ Организация взаимосвязи с внешними систе-мами, в т.ч.

80 80 160

§ Разработка проектных решений по инте-грации с внешними системами.

§ Разработка и тестирование интерфейс-ных программ.

§ Подготовка сценария и проведение ком-плексного тестирования 24 24 48

§ Доработки по результатам тестирования. 60 60 120 Итого: 1968 4348 6316

§ Планирование (перепланирование) этапа 16 8 24 § Опытная эксплуатация, в т.ч. 320 640 960 § Определение перечня пользователей § Настройка пользователей и прав доступа. § Установка системы для конечных пользо-вателей.

§ Обучение конечных пользователей систе-мы. Проведение деловой игры.

§ Перенос и выверка справочников и остат-ков, ввод оперативных данных (20%)

§ Консультации конечных пользователей по работе в системе

§ Оперативное устранение замечаний. § Опытно-промышленная эксплуатация, в т.ч. 160 320 480 § Перенос и выверка справочников и остат-ков, ввод оперативных данных (100%)

§ Сопровождение продуктивной системы, оперативное устранение замечаний.

§ Подготовка решения о переходе к про-мышленной эксплуатации системы.

§ Выполнение процедур по окончанию про-екта (передача документации по доработкам и администрированию)

Ввод в дейст-вие

§ Подписание актов ввода в ПЭ, завершения инвестиционной фазы.

Итого: 496 968 1464 § Устранение замечаний в период гарантийно-го срока

40 0 40

§ Осуществление технической поддержки и сопровождение дальнейшей работы пользова-телей****

40 0 40

§ Оценка результатов и эффективности исполь-зования системы.

0 16 16

Сопровож-дение

§ Сбор информации с целью определения воз-можностей дальнейшего развития проекта.

0 24 24

Итого: 80 40 120 Всего, чел/час.: 3320 6476 9796 Примечания * с учетом референтной модели ** типовые модели и роли *** по образцу **** по горячей линии (дистанционно)

89

Приложение 3б. Состав работ и их трудоемкость в проектах по автоматизации управ-ления персоналом (включая табельный учет и расчет зарплаты)

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

§ Подготовка заявки на проект 8 16 24 § Подготовка приказа и назначение руководителя, разработка укрупненного плана- графика, уста-новление KPI

16 8 24

§ Подготовка устава (описания) проекта 16 8 24 § Формирование рабочих групп; 8 40 48

Инициирование проекта

§ Организация и оборудование проектного офиса 0 24 24 Итого: 48 96 144

§ Планирование работ по обследованию и описа-нию БП

16 16 32

§ Разработка структуры базы данных проекта; 8 0 8 § Обучение рабочих групп методике обследования и описания БП

40 0 40

§ Обследование объекта 240 480 720 § Описание процесса "как есть"* 240 480 720 § Подготовка детального плана реализации проек-та

24 8 32

§ Разработка ТЗ 160 40 200

Предпроектное обследование

§ Разработка регламента создания, приемки, хра-нения ПО

24 24 48

Итого: 728 1024 1752 § Планирование (перепланирование) этапа 16 8 24 § Инсталляция системы и начальное администри-рование

24 16 40

§ Обучение системе команды проекта и ключевых пользователей;

60 0 60

§ Экзамен ключевых пользователей с предостав-лением отчетности руководству

8 8 16

§ Макетирование (проектирование системы "как будет"), в т.ч.

504 1440 1944

§ Определение ролей пользователей**; § Настройка модели в системе** § Тестирование созданной модели; § Донастройка по результатам тестирования (без изменения функционала)

§ Разработка документов по процессам (регламен-ты) и ролям (инструкции), в т.ч.

120 1120 1240

§ Разработка перечня документов, требований к оформлению

§ Разработка регламентов*** § Разработка инструкций*** § Доработка функционала системы, в т.ч. 240 480 720 § Разработка частных ТЗ на доработку § Выполнение доработок и тестирование § Документирование доработок и расширений системы.

§ Доработка отчетов системы, в т.ч. 240 480 720 § Разработка проектных решений по составу отчетности, очередности разработки

§ Разработка отчетных форм § Разработка системы ведения НСИ, в т.ч. 80 160 240 § Разработка проектных решений по составу НСИ (справочники, классификация, кодирование)

§ Разработка регламента ведения НСИ § Перенос начальных и исторических данных, в т.ч.

160 480 640

Техническое проектиро-вание

§ Разработка проектных решений по переносу

90

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

начальных и исторических данных. § Разработка и тестирование программ пере-носа данных.

§ Подготовка основных и исторических дан-ных.

§ Тестовый перенос основных и исторических данных.

§ Организация взаимосвязи с внешними система-ми, в т.ч.

40 80 120

§ Разработка проектных решений по интегра-ции с внешними системами.

§ Разработка и тестирование интерфейсных программ.

§ Подготовка сценария и проведение комплексно-го тестирования 24 24 48

§ Доработки по результатам тестирования. 60 60 120 Итого: 1576 4356 5932

§ Планирование (перепланирование) этапа 16 8 24 § Опытная эксплуатация, в т.ч. 320 640 960 § Определение перечня пользователей § Настройка пользователей и прав доступа. § Установка системы для конечных пользова-телей.

§ Обучение конечных пользователей системы. Проведение деловой игры.

§ Экзамен конечных пользователей с предостав-лением отчетности руководству

§ Перенос и выверка справочников и остатков, ввод оперативных данных (20%)

§ Консультации конечных пользователей по работе в системе

§ Оперативное устранение замечаний. § Опытно-промышленная эксплуатация, в т.ч. 160 320 480 § Перенос и выверка справочников и остатков, ввод оперативных данных (100%)

§ Сопровождение продуктивной системы, опе-ративное устранение замечаний.

§ Подготовка решения о переходе к промыш-ленной эксплуатации системы.

§ Выполнение процедур по окончанию проекта (передача документации по доработкам и адми-нистрированию)

Ввод в дейст-вие

§ Подписание актов ввода в ПЭ, завершения инвестиционной фазы.

Итого: 496 968 1464 § Устранение замечаний в период гарантийного срока

40 0 40

§ Осуществление технической поддержки и со-провождение дальнейшей работы пользовате-лей****

40 0 40

§ Оценка результатов и эффективности использо-вания системы.

0 16 16

Сопровож-дение

§ Сбор информации с целью определения воз-можностей дальнейшего развития проекта.

0 24 24

Итого: 80 40 120 Всего, чел/час.: 2928 6484 9412 Примечания * с учетом референтной модели ** типовые модели и роли *** по образцу **** по горячей линии (дистанционно)

91

Приложение 3в. Состав работ и их трудоемкость в проектах по автоматизации управ-ления производством.

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

§ Подготовка заявки на проект 8 16 24 § Подготовка приказа и назначение руководите-ля, разработка укрупненного плана- графика, установление KPI

16 8 24

§ Подготовка устава (описания) проекта 16 8 24 § Формирование рабочих групп; 8 40 48

Инициирование проекта

§ Организация и оборудование проектного офи-са

0 24 24

Итого: 48 96 144 § Планирование работ по обследованию и опи-санию БП

8 16 24

§ Разработка структуры базы данных проекта; 8 0 8 § Обучение рабочих групп методике обследова-ния и описания БП

40 0 40

§ Обследование объекта 240 480 720 § Описание процесса "как есть"* 240 480 720 § Подготовка детального плана реализации про-екта

24 8 32

Предпроектное обследование

§ Разработка ТЗ 160 40 200 § Разработка регламента создания, приемки,

хранения ПО 24 24 48

Итого: 720 1024 1744 § Планирование (перепланирование) этапа 16 8 24 § Инсталляция системы и начальное админист-рирование

24 16 40

§ Обучение системе команды проекта и ключе-вых пользователей;

60 0 60

§ Макетирование (проектирование системы "как будет"), в т.ч.

640 1440 2080

§ Определение ролей пользователей**; § Настройка модели в системе** § Тестирование созданной модели; § Донастройка по результатам тестирова-ния (без изменения функционала)

§ Разработка документов по процессам (регла-менты) и ролям (инструкции), в т.ч.

120 1120 1240

§ Разработка перечня документов, требова-ний к оформлению

§ Разработка регламентов*** § Разработка инструкций*** § Доработка функционала системы, в т.ч. 320 480 800 § Разработка частных ТЗ на доработку § Выполнение доработок и тестирование § Документирование доработок и расширений системы.

§ Доработка отчетов системы, в т.ч. 160 480 640 § Разработка проектных решений по составу отчетности, очередности разработки

§ Разработка отчетных форм § Разработка системы ведения НСИ, в т.ч. 80 160 240 § Разработка проектных решений по составу НСИ (справочники, классификация, кодирова-ние)

§ Разработка регламента ведения НСИ § Перенос начальных и исторических данных, в т.ч.

320 480 800

Техническое проектиро-вание

§ Разработка проектных решений по переносу

92

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

начальных и исторических данных. § Разработка и тестирование программ пе-реноса данных.

§ Подготовка основных и исторических дан-ных.

§ Тестовый перенос основных и исторических данных.

§ Организация взаимосвязи с внешними систе-мами, в т.ч.

160 160 320

§ Разработка проектных решений по инте-грации с внешними системами.

§ Разработка и тестирование интерфейсных программ.

§ Подготовка сценария и проведение комплекс-ного тестирования 24 24 48

§ Доработки по результатам тестирования. 60 60 120 Итого: 1984 4428 6412

§ Планирование (перепланирование) этапа 16 8 24 § Опытная эксплуатация, в т.ч. 320 640 960 § Определение перечня пользователей § Настройка пользователей и прав доступа. § Установка системы для конечных пользо-вателей.

§ Обучение конечных пользователей систе-мы. Проведение деловой игры.

§ Перенос и выверка справочников и остат-ков, ввод оперативных данных (20%)

§ Консультации конечных пользователей по работе в системе

§ Оперативное устранение замечаний. § Опытно-промышленная эксплуатация, в т.ч. 160 640 800 § Перенос и выверка справочников и остат-ков, ввод оперативных данных (100%)

§ Сопровождение продуктивной системы, оперативное устранение замечаний.

§ Подготовка решения о переходе к промыш-ленной эксплуатации системы.

§ Выполнение процедур по окончанию проекта (передача документации по доработкам и ад-министрированию)

Ввод в дейст-вие

§ Подписание актов ввода в ПЭ, завершения инвестиционной фазы.

Итого: 496 1288 1784 § Устранение замечаний в период гарантийного срока

40 0 40

§ Осуществление технической поддержки и со-провождение дальнейшей работы пользовате-лей****

40 0 40

§ Оценка результатов и эффективности исполь-зования системы.

0 16 16

Сопровож-дение

§ Сбор информации с целью определения воз-можностей дальнейшего развития проекта.

0 24 24

Итого: 80 40 120 Всего, чел/час.: 3328 6876 10204 Примечания * с учетом референтной модели ** типовые модели и роли *** по образцу **** по горячей линии (дистанционно)

93

Приложение 3г. Состав работ и их трудоемкость в проектах по автоматизации управ-ления технологической подготовкой производства.

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

§ Подготовка заявки на проект 8 16 24 § Подготовка приказа и назначение руководите-ля, разработка укрупненного плана- графика, установление KPI

16 8 24

§ Подготовка устава (описания) проекта 16 8 24 § Формирование рабочих групп; 8 40 48

Инициация проекта

§ Организация и оборудование проектного офи-са

0 24 24

Итого: 48 96 144 § Планирование работ по обследованию и опи-санию БП

16 16 32

§ Разработка структуры базы данных проекта; 8 0 8 § Обучение рабочих групп методике обследова-ния и описания БП

24 0 24

§ Обследование объекта 120 400 520 § Описание процесса "как есть"* 120 400 520 § Подготовка детального плана реализации про-екта

24 8 32

Предпроектное обследование

§ Разработка ТЗ 64 32 96 § Разработка реглмента создания, приемки, хра-

нения ПО 24 24 48

Итого: 376 856 1232 § Планирование (перепланирование) этапа 16 8 24 § Инсталляция системы и начальное админист-рирование

24 24 48

§ Обучение системе команды проекта и ключе-вых пользователей;

56 0 56

§ Макетирование (проектирование системы "как будет"), в т.ч.

320 1440 1760

§ Определение ролей пользователей**; § Настройка модели в системе** § Тестирование созданной модели; § Донастройка по результатам тестирова-ния (без изменения функционала)

§ Разработка документов по процессам (регла-менты) и ролям (инструкции), в т.ч.

80 1120 1200

§ Разработка перечня документов, требова-ний к оформлению

§ Разработка регламентов*** § Разработка инструкций*** § Доработка функционала системы, в т.ч. 320 480 800 § Разработка частных ТЗ на доработку § Выполнение доработок и тестирование § Документирование доработок и расширений системы.

§ Доработка отчетов системы, в т.ч. 40 320 360 § Разработка проектных решений по составу отчетности, очередености разработки

§ Разработка отчетных форм § Разработка системы ведения НСИ, в т.ч. 80 160 240 § Разработка проектных решений по составу НСИ (справочники, классификация, колдирова-ние)

§ Разработка регламента ведения НСИ § Перенос начальных и исторических данных, в т.ч.

120 480 600

Техническое проектиро-вание

§ Разработка проектных решений по переносу

94

Этап Содержание работ Исполни-тель

(чел./час.)

Заказчик (чел./час.)

Всего (чел./час.)

начальных и исторических данных. § Разработка и тестирование программ пе-реноса данных.

§ Подготовка основных и исторических дан-ных.

§ Тестовый перенос основных и исторических данных.

§ Организация взаимосвязи с внешними систе-мами, в т.ч.

80 160 240

§ Разработка проектных решений по инте-грации с внешними системами.

§ Разработка и тестирование интерфейсных программ.

§ Подготовка сценария и проведение комплекс-ного тестирования 24 24 48

§ Доработки по результатам тестирования. 60 60 120 Итого: 1220 4276 5496

§ Планирование (перепланирование) этапа 16 8 24 § Опытная эксплуатация, в т.ч. 160 640 800 § Определение перечня пользователей § Настройка пользователей и прав доступа. § Установка системы для конечных пользо-вателей.

§ Обучение конечных пользователей систе-мы. Проведение деловой игры.

§ Перенос и выверка справочников и остат-ков, ввод оперативных данных (20%)

§ Консультации конечных пользователей по работе в системе

§ Оперативное устранение замечаний. § Опытно-промышленная эксплуатация, в т.ч. 160 320 480 § Перенос и выверка справочников и остат-ков, ввод оперативных данных (100%)

§ Сопровождение продуктивной системы, оперативное устранение замечаний.

§ Подготовка решения о переходе к промыш-ленной эксплуатации системы.

§ Выполнение процедур по окончанию проекта (передача документации по доработкам и ад-министрированию)

Ввод в дейст-вие

§ Подписание актов ввода в ПЭ, завершения инвестиционной фазы.

Итого: 336 968 1304 § Устранение замечаний в период гарантийного срока

40 0 40

§ Осуществление технической поддержки и со-провождение дальнейшей работы пользовате-лей****

40 0 40

§ Оценка результатов и эффективности исполь-зования системы.

0 16 16

Сопровож-дение

§ Сбор информации с целью определения воз-можностей дальнейшего развития проекта.

0 24 24

Итого: 80 40 120 Всего, чел/час.: 2060 6236 8296 Примечания * с учетом референтной модели ** типовые модели и роли *** по образцу **** по горячей линии (дистанционно)

95

Приложение 4а. Процессы жизненного цикла продукции Процесс Подпроцесс Функция (документированная процедура)

Мониторинг потреб-ностей и пожеланий потребителей

- Мониторинг удовлетворенности продуктами и услугами - Мониторинг удовлетворенности потребителей при разреше-

нии жалоб - Мониторинг удовлетворенности потребителей от общения

Мониторинг измене-ний на рынке или в ожиданиях потреби-телей

- Определение слабых сторон в предложении продуктов/услуг - Отслеживание инноваций, которые обеспечивают потребности

потребителей - Определение реакции потребителей на конкурирующие пред-

ложения - Прогнозирование покупательского спроса потребителей - Разработка предложений по улучшению (расширению) потре-

бительских качеств продукта - Разработка предложений по удалению (снятию с производст-

ва) устаревших продуктов

Изучение рынка и потребностей по-требителей

Разработка концеп-ции нового продукта

- Перевод потребностей и желаний потребителя в требования к продукту (разработка ТЗ)

- Планирование и детализация целей по качеству - Планирование и детализация целей по стоимости - Разработка жизненного цикла продукта и определение целей

по времени - Разработка и интеграция лидирующих технологий в концеп-

цию продукта/услуги Конструкторская подготовка основно-го производства

- Разработка конструкторской спецификации продукта - Параллельное проектирование - Расчет стоимости - Документирование конструкции - Получение патентов

Изготовление опыт-ного образца (опыт-ное производство)

- Планирование подготовки производства опытного образца - Разработка техпроцесса производства опытного образца - Проектирование и изготовление средств технологического

оснащения - Обеспечение необходимыми материалами, оборудованием,

инструментом - Изготовление опытного образца - Испытания опытного образца - Внесение изменений в конструкцию

Технологическая подготовка основно-го производства

- Разработка процесса производства (расцеховка) - Разработка техпроцессов - Расчет мощностей и заказ оборудования - Расчет потребности в инструменте и заказ инструмента - Отработка конструкции на технологичность - Отладка техпроцесса - Разработка управляющих программ для оборудования с ЧПУ - Проектирование нестандартного оборудования и оснастки - Проектирование нестандартного инструмента

Управление кон-структорско-технологической подготовкой про-изводства

Организационная подготовка основно-го производства

- Планирование технической подготовки производствава; - Мониторинг технической подготовки производства; - Управление изменениями проекта ТПП - Приобретение технологий (ноу-хау, патентов) - Обеспечение технической информацией

Планирование ос-новного производст-ва

- Определение необходимых материалов и комплектующих - Объемно-календарное планирование - Планирование потребностей в материалах и комплектующих - Планирование производственных мощностей - Расчет производственных заданий

Управление ос-новным произ-водством

Производство про-дукции

- Учет перемещения материалов (производственная логистика) и/или ресурсов

- Учет производства продукции - Контроль качества продукции, устранение проблем качества - Испытания продукции - Упаковка продукции - Складирование и хранение продукта

96

Процесс Подпроцесс Функция (документированная процедура) - Подготовка продукта к поставке

Оперативное управ-ление процессом производства (дис-петчирование)

- Мониторинг статуса заказов (движение ДСЕ в производстве) - Управление запасами и НЗП - Планирование и выполнение текущего ремонта оборудования

(ППР); - Мониторинг отклонений и ограничений, внесение изменений

в процесс производства Управление закуп-ками

- Планирование закупок - Работа с поставщиками - Учет поставок и контроль исполнения договоров

Управление за-купками (снабже-нием)

Управление запаса-ми

- Поступление ТМЦ - Идентификация и раскладка на хранение - Комплектование (разукомплектование) и выдача ТМЦ

Позиционирование продуктов и услуг на сегментах потреби-тельского рынка (маркетинг)

- Разработка ценовой стратегии - Разработка рекламной стратегии - Оценка объемов рекламы и требований по ее финансированию - Идентификация выделенных (особенных) целевых потребите-

лей и их потребностей - Разработка прогноза продаж

Обработка заказов потребителей

- Получение заказов от потребителей - Ведение переговоров об условиях поставки - Оформление договорных отношений - Выставление счетов потребителям - Включение заказов в процессы производства и доставки

Поставка продукции - Планирование поставки продукции - Таможенное оформление - Поставка (доставка) продукции потребителю

Управление про-дажами (сбытом)

Послепродажное обслуживание

- Установка (ввод в эксплуатацию) продукции - Гарантийное обслуживание и претензионная работа - Работа с жалобами потребителей - Информирование потребителей

Планирование и обеспечение ресур-сами

- Выбор и сертификация поставщиков - Приобретение материалов и комплектующих - Приобретение технологий (ноу-хау, патентов)

Оказание услуг по-требителю

- Определение требований по обслуживанию конкретного по-требителя

- Планирование ресурсов для удовлетворения требований по обслуживанию

- Обеспечение обслуживания специальных клиентов

Управление тех-ническим обслу-живанием (серви-сом)

Обеспечение качест-ва обслуживания

- Определение требований по квалификации персонала - Проведение тренингов - Мониторинг и управление повышением квалификации

97

Приложение 4б. Процессы менеджмента ресурсов Процесс Подпроцесс Функция (документированная процедура)

Управление бюдже-тами

- Бюджетное планирование - Учет исполнения бюджета - Контроль и анализ исполнения бюджета, оперативное управ-

ление бюджетом Оперативное управ-ление финансовыми средствами

- Учет расчетов с контрагентами, управление дебиторской и кредиторской задолженностью

- Учет движения денежных средств - Учет движения привлеченных и выданных средств

Бухгалтерский и на-логовый учет

- Ведение бухгалтерских регистров (главная книга) - Формирование бухгалтерской отчетности - Ведение налоговых регистров - Формирование налоговой отчетности

Расчет зарплаты - Табельный учет - Расчет зарплаты

Управление затрата-ми

- Планирование доходов и затрат - Учет доходов и затрат - Расчет плановой и фактической себестоимости продукции - Расчет цен - Расчет технико-экономических показателей

Анализ ФХД - Анализ финансовой деятельности - Анализ хозяйственной деятельности - Формирование внутренней финансовой отчетности (управлен-

ческой)

Управление фи-нансами и эконо-микой

Внутренний аудит - Контроль источников учетной информации - Контроль полноты отражения и методов сведения информа-

ции в учетные регистры - Контроль соответствия принципов отражения информации в

учете, принципам установленным во внешних и внутренних стандартах.

- Контроль сохранности активов предприятия. - Контроль цен

Разработка стратегии в области HR

- Определение требований организации к HR в стратегическом плане

- Определение затрат на HR - Определение требований к HR

Разработка органи-зациионно - функ-циональной структу-ры

- Анализ, разработка и реорганизация функций персонала - Определение и систематизация выполнения функций и уста-

новление метрик (показателей) - Установление сфер ответственности за выполнение функ-

ций/процессов - Установление сферы ответственности управляющих - Установление сферы ответственности команд

Управление приемом персонала

- Планирование потребности в рабочей силе - Планирование продвижения и карьеры - Поиск, подбор и прием персонала - Формирование и развертывание команд - Перемещение персонала - Реорганизация и сокращение персонала - Увольнение персонала - Обеспечение трудоустройства увольняемого персонала

Развитие и обучение персонала

- Приведение в соответствие квалификации персонала и требо-ваний по развитию организации

- Разработка и управление программами обучения - Разработка и управление программами профориентации пер-

сонала

Управление тру-довыми ресурса-ми (HR)

Управление произ-водительностью, материальное и мо-ральное стимулиро-вание

- Определение показателей производительности - Разработка подходов к управлению производительностью и

обратной связью - Управление производительностью команд - Оценка ценности функции с точки зрения внутренней стоимо-

сти

98

Процесс Подпроцесс Функция (документированная процедура) - Разработка и управление постоянной и переменной частью

зарплаты - Управление программами материального и морального стиму-

лирования Обеспечение здоро-вья и удовлетворен-ности персонала

- Управление удовлетворенностью персонала - Разработка системы поддержки здоровья - Разработка системы поддержки семьи

Управление соци-альной инфраструк-турой

- Управление спортивными объектами - Управление объектами общественного питания - Управление бытовым и хозяйственным обслуживанием - Управление объектами для отдыха и развлечений

Производство не-стандартного обору-дования и оснастки

- Техническая подготовка производства нестандартного обору-дования и оснастки

- Изготовление нестандартного оборудования и оснастки Инструментальное производство

- Техническая подготовка производства инструмента - Изготовление стандартного и нестандартного инструмента

Управление вспомогательным производством

Ремонтное произ-водство

- Техническая подготовка ремонтного производства - Изготовление комплектующих для ремонта оборудования и

ремонт оборудования Обеспечение ремон-тов технологическо-го оборудования

- Планирование ремонтов (монтажа) - Планирование закупки (производства) оборудования, запча-

стей и материалов; - Выбор и сертификация поставщиков - Приобретение оборудования, материалов и комплектующих

Управление ре-монтами обору-дования

Оперативное управ-ление ремонтом тех-нологического обо-рудования;

- Прием заявок на ремонт (монтаж) технологического оборудо-вания

- Производство работ - Учет результатов выполнения работ и анализ отклонений

Энергообеспечение - Планирование энергообеспечения объектов - Планирование мероприятий по энергосбережению - Закупка (производство) энергоресурсов - Эксплуатация технических средств контроля расхода энерго-

ресурсов Обеспечение ремон-тов (монтажа) объек-тов энергообеспече-ния

- Планирование ремонтов (монтажа) - Планирование закупки (производства) оборудования, запча-

стей и материалов; - Выбор и сертификация поставщиков - Приобретение оборудования, материалов и комплектующих

Управление энер-гобеспечением

Оперативное управ-ление ремонтом (монтажом) объектов энергообеспечения

- Прием заявок на ремонт (монтаж) - Производство работ - Учет результатов выполнения работ и анализ отклонений

Обеспечение строи-тельства и ремонта зданий и сооружений

- Планирование ремонтов (строительства) - Планирование закупки (производства) оборудования, запча-

стей и материалов - Выбор и сертификация поставщиков - Приобретение оборудования, материалов и комплектующих

Управление строительством и ремонтом зданий и сооружений

Оперативное управ-ление ремонтом объ-ектов строительства

- Прием заявок на ремонт (строительство) объектов - Производство работ - Учет результатов выполнения работ и анализ отклонений

Планирование и управление ИТ и созданием АС

- Определение требований на основе стратегии бизнеса - Планирование развития ИТ на период - Установление ИТ - стандартов

Разработка и внедре-ние АС

- Анализ потребностей и разработка требований к АС - Выбор и приобретение (разработка) АС - Ввод в действие АС - Эксплуатация и сопровождение АС

Управление инфор-мацией

- Сбор, упорядочивание и преобразование информации - Хранение информации - Осуществление доступа к информации - Уничтожение информации - Анализ угроз и разработка систем информационной безопас-

ности

Управление ин-формационными технологиями и созданием АС

Управление обору- - Управление оборудованием

99

Процесс Подпроцесс Функция (документированная процедура) дованием и сетями передачи данных

- Управление сетевыми ресурсами (администрирование) - Обеспечение публикаций в Интернет

Управление приоб-ретением и ремонта-ми оборудования

- Прием заявок на поставку и ремонт оборудования - Планирование закупки СВТ и оргтехники - Планирование закупки запчастей и расходных материалов - Выбор и сертификация поставщиков - Приобретение оборудования, материалов и комплектующих - Производство ПНР и ремонтов - Учет результатов выполнения работ и анализ отклонений

Управление теле-коммуникациями и связью

Управление теле-коммуникациями и связью

- Планирование обеспечения объектов связью - Закупка средств связи, и услуг операторов связи - Планирование ремонтов телекоммуникационного оборудова-

ния - Планирование закупки (производства) запчастей и материалов - Выбор и сертификация поставщиков - Приобретение материалов и комплектующих - Производство работ - Учет результатов выполнения ремонтов и анализ отклонений

Управление авто-транспортом

- Прием заказов на обслуживание - Управление подвижным составом - Учет выработки водителей, расхода ГСМ и запчастей - Планирование ремонтов и ресурсов - Планирование закупки (производства) запчастей и материалов - Выбор и сертификация поставщиков - Приобретение ГСМ, материалов и комплектующих

Управление транспортом

Управление желез-нодорожным транс-портом

- Прием заказов на обслуживание - Заказ подвижного состава - Погрузочно-разгрузочные работы

Управление кон-трольными и из-мерительными приборами

- Учет средств измерения - Проверка и ППР средств измерения - Отчетность по средствам измерения в государственные орга-

ны

100

Приложение 4в. Процессы ответственности руководства Процесс Подпроцесс Функция (документированная процедура)

Мониторинг внеш-ней среды

- Анализ и выявление причин конкуренции - Определение экономических трендов - Идентификация политических и правовых вопросов - Оценка новых технологических инноваций - Анализ демографии - Идентификация социальных и культурных изменений - Анализ экологических проблем

Определение кон-цепции бизнеса и стратегии предпри-ятия

- Выбор рынков - Определение долгосрочных перспектив - Формулировка стратегии бизнес – единиц - Разработка миссии - Разработка и ранжирование целей организации, разработка

KPI - Разработка организационной структуры и системы взаимоот-

ношений между орг. единицами

Стратегическое управление

Осуществление внешних связей (PR)

- Обмен информацией с владельцами предприятия - Взаимодействие с правительством - Взаимодействие с обществом - Разработка программы PR

Измерение показате-лей деятельности организации

- Создание системы измерения показателей - Измерение качества продуктов и услуг - Измерение затрат на обеспечение качества - Измерение длительности циклов - Измерение производительности (продуктивности)

Оценка качества - Оценка качества на основе внешних критериев - Оценка качества на основе внутренних критериев

Сравнительный ана-лиз деятельности

- Определение возможности проведения сравнительного анали-за

- Сравнительный анализ бизнес-процессов - Сравнительный анализ конкурентных преимуществ

Улучшение процес-сов и систем

- Определение направлений улучшений - Внедрение непрерывного улучшения бизнес-процессов - Реорганизация бизнес-процессов и систем - Управление улучшениями

Управление улучшениями и изменениями

Внедрение TQM - Определение направлений TQM - Разработка и внедрение системы TQM - Управление жизненным циклом TQM

Разработка мер по охране окружающей среды

- Разработка и реализация программ по предупреждению за-грязнения окружающей среды

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

Управление охра-ной окружающей среды

Проведение меро-приятий по реагиро-ванию на угрозы

- Обучение персонала и проведение тренингов - Разработка и реализация программ реагирования на угрозы - Управление восстановительными работами

Охрана объектов и физическая охрана

- Разработка и реализация программ реагирования на угрозы - Обучение персонала и проведение тренингов - Патрулирование и сопровождение - Эксплуатация технических средств безопасности

Пожарная охрана - Разработка и реализация программ реагирования на угрозы - Обучение персонала и проведение тренингов - Инструктажи и организация проверок - Эксплуатация технических средств пожаротушения

Защита от чрезвы-чайных ситуаций

- Разработка и реализация программ реагирования на угрозы - Обучение персонала и проведение тренингов - Инструктажи и организация проверок

Обеспечение безопасности

Охрана труда и про-мышленная (техни-ческая) безопасность

- Разработка мер по охране труда - Разработка инструкций по технике безопасности - Обучение персонала и проведение тренингов - Взаимодействие с государственными органами (инспекциями)

Юридическое Контроль докумен- - Контроль договорных отношений

101

Процесс Подпроцесс Функция (документированная процедура) тов - Контроль организационно - распорядительной документации обеспечение Защита интересов предприятия в судах и арбитражах

- Подготовка документов - Участие в судебных заседаниях

Управление до-кументами

- Организация учета, хранения и обращения бумажных и элек-тронных документов

- Коллективная (автоматизированная) разработка документов

102

Приложение 5. Инструкция по обследованию предприятия Обследование предприятий может проводиться с разными целями. Данная инструкция используется в целях описания бизнес-процессов и их последующей автоматизации.

Общие положения Обследованию подлежат:

- функции подразделений; - документооборот подразделений

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

Информация собирается на бланках. Формы бланков приведены ниже.

Обследование функций Описание функций производится по операциям, которые выполняют подразделения или от-дельные исполнители с перечислением работ. Форма бланка для обследования функции под-разделения приведена в таблице 1.

Таблица 30. Бланк обследования функций Наименование операции

Наименование подразделения, полное и краткое

Численность подразделения

Руководитель подразделения

Куда входит (отдел, управление, департамент)

Работы Исполни-тель

Вход / Иниции-рование

Поставщик Выход / Завер-шение

Получатель

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

Таблица 31. Бланк параметров операций Наименование подразделения

Операция Среднее вре-мя выполне-ния, час

Время «про-стоя», час

Периодич-ность

Трудоем-кость, н/час

Стоимость, руб.

Прочие

Пояснения к таблице:

Время простоя - среднее время ожидания события, инициирующего выполнение операции Периодичность - ежедневно, еженедельно, ежемесячно, ежегодно

Стоимость - количество человеко-часов, умноженное на почасовую ставку оплаты труда исполнителя (группы исполнителей)

103

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

Обследование документооборота Документооборот является неотъемлемой частью бизнес-процессов. Рассматриваются 4 вида документов:

- входящие (документы, созданные вне данного процесса и не выходящие за преде-лы процесса);

- исходящие (документы созданные данным процессом и выходящие за его преде-лы);

- внутренние (документы созданные данным процессом и не выходящие за его пре-делы);

- транзитные (документы, созданные вне данного процесса и выходящие за пределы процесса).

Описание документооборота производится на бланках, приведенных в таблицах 3,4,5,6.

Таблица 32. Реестр ВХОДЯЩЕЙ информации Документ Наименование подразделе-

ния Характеристики обработки документов

№ Наименование и назначение документа

Откуда по-ступает

Кто получа-ет

Трудоем-кость

Периодичность,

регламент

Способ полу-чения

1 2 3 4 5 6 7

Таблица 33. Реестр ИСХОДЯЩЕЙ информации Документ Наименование подразделе-

ния Характеристики обработки документов

№ Наименование и назначение документа

Кем создает-ся

Куда пере-дается

Трудоем-кость

Периодичность,

регламент

Способ полу-чения

1 2 3 4 5 6 7

Таблица 34. Реестр ВНУТРЕННЕЙ информации Документ Наименование подразделе-

ния Характеристики обработки документов

№ Наименование и назначение документа

Кем создает-ся

Кому пере-дает

Трудоем-кость

Периодичность,

регламент

Способ полу-чения

1 2 3 4 5 6 7

104

Таблица 35. Реестр ТРАНЗИТНОЙ информации Документ Наименование подразделения Характеристики обработки документов

№ Наименование и назна-чение документа

Откуда по-ступает

Кем обра-батывает-ся

Куда пере-дается

Трудоем-кость

Периодич-ность, рег-ламент

Способ получения

1 2 3 4 5 6 7

Пояснения к таблице:

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

В графе «Трудоемкость» указать время, которое тратится на заполнение или обработку одного документа указанного наименования (в минутах, часах, днях). Достаточно экспертной оценки или усредненных значений. Например, 5 мин, 2 часа и т.п. В графе «Периодичность, регламент» указать количество обрабатываемых документов за определенный интервал времени (год, квартал, месяц, неделя, день). Достаточно экспертной оценки или усредненных значений (например, «70/день»; «200/месяц»). НЕ ДОПУСКАЕТСЯ указывать значения типа – «ежесменно», «каждый день», «по потребности», «по графику» и т.п. Если утверждены предельные сроки подготовки или обработки документа(ов) (например, «до 20 числа месяца, предшествующего планируемому», «до 9 часов следующего за отчетным дня» и т. п.), то после указания периодичности обработки указать эти сроки (например, «200/месяц; до 25 числа каждого месяца»; «1/месяц; до 10 числа планируемого периода» и т.п.)

В графе «Способ получения» указать способ получения и передачи информации (документа): на бумаге, по телефону, на магнитном носителе, по локальной сети, электронной почте, из общей базы данных и т.п. К каждому реестру необходимо приложить по 1 экземпляру заполненного документа или его ксерокопии (не пустографки). Если в подразделении ведутся какие-либо накопительные документы (например. журналы регистрации), необходимо представить их образец (достаточно ксерокопии одного развернутого заполненного листа).

Правила проведения интервью При проведении интервью следует придерживаться следующих правил:

1) Длительность интервью не должна превышать 2 часов, но и дробить интервью на не-сколько мелких частей не следует.;

2) Не рекомендуется проводить интервью перед обедом или перед концом рабочего дня; 3) Необходимо четко представлять цель интервью; 4) Все вопросы должны быть подготовлены и продуманы заранее; 5) Перед проведением интервью необходимо познакомиться с документацией по рас-

сматриваемым вопросам 6) В начале интервью сотруднику подразделения нужно сказать:

- Почему проводится это интервью; - От кого получено разрешение его проводить или иное основание (например, при-

каз); - Кто еще будет проинтервьюирован; - По какому принципу и кто выбирал интервьюируемых;

105

- Как будет использована полученная информация; - Будет ли интервью анонимным; - Будет ли интервью отражено в отчете; - Какова будет обратная связь по итогам обработки результатов интервью; - Как интервьюируемый может помочь процессу в целом; - Почему важно получить детальную и точную информацию в процессе интервью.

7) В процессе проведения интервью: - Не отвлекаться на пространные комментарии по проблемам, связанным с обсуж-

даемым предметом; - Не пытаться завязать дружеские отношения; - Не указывать интервьюируемому на его затруднения при описании предметной

области; - Давать интервьюируемому время подумать; - Отделять «мнения» от фактов; - Не иронизировать; - Концентрироваться на наиболее сложных аспектах предметной области; - Не пытаться показывать свои знания (эксперт не вы, а интервьюируемый); - Не увеличивать длительность проведения интервью.

Если интервью проводится заочно, к комплекту опросных листов необходимо приложить за-писку с изложением вопросов по п.6.

Обработка полученной информации Не позднее дня следующего за интервью необходимо перенести полученную информацию в электронную форму в формате MS Word

В процессе переноса необходимо проверить информацию на корректность: - названия подразделений должны совпадать с официальными названиями; - названия функций (операций) должны соответствовать утвержденным в Положе-

ниях о подразделениях; - не должно быть разночтений в названиях одной и той же функции (операции).

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

- «Сторонник» - «Пассивный сторонник» - «Противник» - «Опасный элемент»

Данная информация собирается у руководителя проекта и используется в дальнейшем при формировании рабочих групп и возможного участка для осуществления пилотного проекта.

106

Приложение 6. Пример табличной формы регламента

Р Инициирующее событие, вход

Выполняет/ Разрабатывает

Контролирует/ Согласует

Получает/ Ут-верждает Переход, условие , выход Блок-схема №

опер. Наименование опера-

ции В Дата/срок Дата/срок Дата/срок Дата/срок Дата/срок

Р Поступил заказ на производство

Вед. инженер отдела А

Нач. отдела А ОМИР

Коммерческий директор

Утвержденный приказ и ПМ разослать участникам 1

Подготовить приказ и план мероприятий (ПМ) по подготовке договора В 8 часов 4 часа 4 часа Не позднее 2-х суток с мо-

мента получения заявки

Р

Приказ и ПМ Ведущий спе-циалист

Зам. главного конструктора

Главный конст-руктор

Решение главного конст-руктора (ГК):

♦ Документация имеется полностью – п. 5 ♦ Документация имеется не полностью – п.3

2

Определить необходи-мость конструкторской подготовки производ-ства (КПП)

В 8 часов 4 часа 4 часа

Р Решение (распо-ряжение) ГК

Нач. бюро1, нач. бюро 2, нач. бю-

ро 3

Зам. главного конструктора

Главный конст-руктор

План КПП (с исполнителя-ми и трудоемкостью)

3

Разработать план КПП

В 8 часов 4 часа 4 часа Не позднее 6-хи суток с момента получения заявки

Р

План КПП Ведущий спе-циалист

Зам. главного конструктора

Главный конст-руктор

Конструкторские специфи-кации (КС), ЧКД, ведо-мость покупных изделий (ВПИ) 4

Разработать ЧКД на основные ДСЕ (в т.ч. для кооперации)

В 48 часов 8 часов 8 часов Не позднее 13-ти суток с момента получения заявки

Р КС, ЧКД Ведущий спе-циалист

Нач. ПДО Директор по про-изводству

РВ по кооперации

5

Разработать раздели-тельную ведомость (РВ) по кооперации В 8 часов 4 часа 4 часа Не позднее 15-ти суток с

момента получения заявки

Р РВ по кооперации Ведущий спе-циалист

Нач. ПДО Директор по про-изводству

Изменения к РВ по коопе-рации

6

Отработать РВ с под-рядчиками

В 8 часов 4 часа 4 часа Не позднее 17-ти суток с момента получения заявки

Примечания:

Р – работа, В – время.

Заказ на пр-во

1

3

2

4

3

5

5

6

С1

С2

Приложение 7. Типовой устав проекта

ТИПОВОЙ УСТАВ ПРОЕКТА

Автоматизация финансово-хозяйственной деятельности ОАО «…» средствами автоматизированной системы управления «…»

Общие положения Настоящий документ разработан для целей управления проектом и определяет:

• цели и рамки проекта; • организационную структуру проекта; • обязанности и взаимоотношения участников проекта в процессе автоматизации; • основные работы проекта и их результаты; • правила документирования хода проекта и хранения информации о проекте; • процедуры оперативного управления проектом; • процедуру управления проблемами проекта; • процедуру управления изменениями проекта;

Проект реализуется в соответствии с <наименование документа> и охватывает <список под-разделений>.

Основные цели проекта Основными целями проекта являются:

• <полноценный оперативный и бухгалтерский учет материальных и финансовых ресурсов на предприятии>;

• <обеспечение руководителей всех уровней непротиворечивой сводной и аналити-ческой отчетностью в необходимом формате и к нужному сроку для принятия управленческих решений>;

• <…>

Автоматизируемые процессы В соответствии с целями в проекте выделяются следующие направления автоматизации:

• <учет и контроль договорных отношений>; • <учет и контроль движения товарно-материальных запасов в соответствии с дого-

ворными отношениями>; • <учет и контроль финансовых операций в соответствии с договорными отноше-

ниями>; • <бухгалтерский учет>; • <…>.

Диапазон автоматизируемых функций может быть расширен после обследования предпри-ятия; Для автоматизации указанных бизнес-процессов используется АС <наименование>.

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

Порядок формирования и согласования технического задания (ТЗ) приведен в настоящем Уставе.

Участники проекта Непосредственными участниками проекта являются:

108

• ОАО «…» (далее …); Консультационно-методологическую поддержку осуществляют:

• ООО «…». (далее …); • <…>.

Надзорную и контролирующую функцию выполняют: • <Департамент ИТ управляющей компании>.

Распределение обязанностей и ответственности между сторонами определяются: • Договорами; • Настоящим Уставом проекта; • Прочими проектными документами, согласованными сторонами-участниками.

Для заседаний органов управления проектом, совещаний рабочих групп, работы внешних участников должно быть выделено отдельное помещение (проектная комната). Он должен быть оснащен «круглым» столом, видеопроектором, экраном, доской (флип-чарт), компью-тером с выходом в сеть, принтером, бумагой, а так же должна быть обеспечена возможность быстрого копирования документов.

Организационная структура, роли и функции участников проекта Организационная структура проекта включает:

По автоматизируемому предприятию: • Управляющий совет; • Методический совет; • Руководитель проекта; • Процессные рабочие группы; • Главный специалист по АСУ предприятия;

По ООО «Служба АСУ»: • Координатор {менеджер}проекта; • Главный методолог {системный аналитик, архитектор}; • Группа методологов {постановщиков}; • Группа программистов; • Группа администраторов серверов и баз данных; • Группа программно-технической поддержки;

По Департаменту ИТ управляющей компании: • Куратор проекта

Участники проекта со стороны предприятия назначаются и освобождаются от выполнения функций в проекте приказом <наименование должности>, согласованным с руководителями подразделений-участников проекта;

Участники проекта со стороны ООО «Служба АСУ» назначаются <наименование должно-сти>, согласовываются с руководителями подразделений-участников и закрепляются <на-именование документа>; Куратор проекта от управляющей компании назначается руководителем департамента ИТ.

Управляющий совет – высший орган управления проектом. Целью создания Управляющего совета является разрешение противоречий, устранение административных и функциональ-ных барьеров между подразделениями, контрольные функции. Его задачи:

• рассмотрение хода выполнения проекта, внесение корректировок в план работ, принятие решения об изменении проекта;

• контроль бюджета проекта, графика финансирования, внесение корректировок в бюджет;

109

• введение и выведение из состава Методического совета и рабочих групп новых членов;

• рассмотрение вопросов, по которым Методическому совету не удалось достичь согласия;

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

Председателем Управляющего совета является <наименование должности>. В состав Управ-ляющего совета входят руководители функциональных направлений предприятия, Руково-дитель проекта, руководитель ООО «Служба АСУ», Координатор проекта (исполняет функ-цию секретаря Управляющего совета);

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

Методический совет является совещательным органом8. Целью создания Методического совета является необходимость корректировки действующей методологии выполнения биз-нес-процессов (БП), вызванных внедрением АС, согласование интересов подразделений, подготовка решений об изменении регламентов выполнения БП, необходимости структур-ных преобразований. Решения Методического совета оформляются протоколом и вступают в действие после согласования и утверждения Руководителем проекта {председателем Управ-ляющего совета}. Задачи Методического совета:

• определение состава и структуры внутреннего и внешнего документооборота, ут-верждение форм документов, определение статуса электронных документов;

• выработка рекомендаций по оптимизации БП, определение и переопределение функций персонала;

• определение методик учета, расчетов, нормирования, планирования и др.; • выработка и утверждение системы классификации и кодирования, структуры спра-

вочников, определение владельцев и совладельцев информации; • консультирование членов рабочих групп и др. вопросы.

Периодичность заседаний Методического совета – по мере необходимости, но не реже 1 раза в месяц. Методический совет, как правило, работает по секциям (направлениям); Председателем Методического совета является Руководителя проекта. Роль секретаря Мето-дического совета выполняет Координатор проекта. Руководитель проекта – должностное лицо, полностью отвечающее перед руководством за выполнение проекта. Руководитель проекта:

• входит по должности в состав Управляющего совета и является заместителем председателя Управляющего совета;

• возглавляет Методический совет; • согласовывает состав Рабочих групп; • утверждает документы по управлению проектом и изменения в них; • обеспечивает своевременное финансирование проекта согласно бюджету проекта; • обеспечивает проведение организационных мероприятий и контроль хода работ по

проекту; • имеет право созывать внеочередные заседания Управляющего совета и Методиче-

ского совета.

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

110

Координатор проекта осуществляет оперативное управление проектом согласно проектным документам, решениям Управляющего совета, Методического совета или Руководителя про-екта. Координатор проекта:

• подчиняется непосредственно Руководителю проекта, выполняет его поручения; • занимается организацией работ на всех этапах внедрения; • координирует взаимоотношения участников проекта; • ведет мониторинг хода проекта, осуществляет планирование работ, предоставляет

отчетность Руководителю проекта, руководителю ООО «Служба АСУ», куратору проекта от управляющей компании;

• ведет учет проблем внедрения, следит за своевременной передачей проблемы на необходимый уровень и ее решением;

• готовит повестку дня и протоколы совещаний рабочих групп, Методического со-вета и Управляющего совета;

• готовит для утверждения проектные документы и изменения к ним; • организовывает экспертизу документов проекта; • имеет право собирать совещания с членами рабочих групп и приглашенными.

Главный специалист по АСУ предприятия является работником автоматизируемого пред-приятия и отвечает за коммуникации между участниками проекта на предприятии:

• подчиняется непосредственно Руководителю проекта, выполняет его поручения; • осуществляет организацию выполнения проектных работ и решений участниками-

сотрудниками предприятия согласно проектным документам; • организовывает экспертизу и согласование проектных документов внутри пред-

приятия; • обеспечивает своевременное решение проблем автоматизации, зависящих от пред-

приятия; • обеспечивает организационную поддержку проекта: работу проектной комнаты,

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

Процессная рабочая группа представляет собой группу специалистов из числа сотрудников предприятия, объединенных по процессному признаку. Персональный состав Рабочих групп утверждается Руководителем проекта по согласованию с руководителями подразделений. Руководителем Процессной рабочей группы назначается работник предприятия по должно-сти не ниже начальника (заместителя начальника) отдела. Все члены Процессных рабочих групп выполняют свои обязанности по совместительству и не покидают своих рабочих мест. Совещание Процессных рабочих групп проходят в проектной комнате. Основными задачами Процессных рабочих групп являются:

• сбор и обработка информации о бизнес-процессах, формирование описания со-гласно методике;

• проверка моделей БП на адекватность (соответствие реально существующим); • выработка предложений по совершенствованию бизнес-процессов, формирование

детальных требований к автоматизации (форм документов, реквизитный состав и т.д.);

• формулировка проблем и вариантов их решений для Методического совета и Управляющего совета;

• участие в работах по внедрению автоматизированной системы: моделирование процессов в системе, подготовка описания модели, разработка регламентов и ин-струкций процессов, формирование требований к доработке/разработке дополни-тельного функционала системы и отчетности, разработка схемы контрольных примеров, тестирование ПО и др.

• Все члены Рабочих групп проходят обучение методике описания БП и соответст-вующему функционалу внедряемой системы автоматизации. На разных этапах

111

проекта, по мере необходимости, в состав Рабочих групп могу вноситься измене-ния.

Куратор проекта от управляющей компании: • осуществляет мониторинг хода проекта и вырабатывает рекомендации с целью со-

блюдения утвержденных сроков, результатов и бюджетов в соответствии с поли-тикой информатизации предприятий холдинга;

• оказывает методическую помощь на всех этапах ведения проекта: подготовке про-екта, формировании планов, проектных документов, обследованию, описанию, регламентации бизнес-процессов и т.д.;

• имеет право инициировать совещания с участием руководителя, координатора, членов рабочих групп и других участников проекта, а так же присутствовать на совещаниях по проекту на всех уровнях;

• имеет право дистанционно и на месте получать необходимую информацию для осуществления мониторинга.

Главный методолог: • Является разработчиком модели автоматизации БП, которая должна соответство-

вать утвержденной политике {концепции} автоматизации, быть увязанной со смежными БП;

• Анализирует бизнес-процессы предприятия, требования к автоматизации, выявля-ет отклонения от утвержденной (далее – референтной) модели9, согласовывает решения по ее изменению;

• Оказывает консультационную поддержку группе методологов. Группа методологов выполняет основной объем работ по внедрению системы на предпри-ятии. Среди методологов филиала определяются ответственные по следующим направлени-ям:

• методологи по бизнес-процессам <управление закупками, управление продажами, управление финансами, бухгалтерский учет>;

• Ответственный за управление справочниками; • Ответственный за формирование начальных (исторических) данных в системе (как

правило, остатков, движения); • Ответственный за администрирование пользователей (формирование ролей).

Один методолог может совмещать несколько функций, и наоборот, если зоны ответственно-сти можно явно разделить, то за направлением может быть закреплено несколько методоло-гов. Ответственность закрепляется распоряжениями руководителя ООО «Служба АСУ», приложением по распределению функций к настоящему Уставу и другими проектными до-кументами (приказами, протоколами); Методологи по бизнес-процессам:

• проводят обследование и описание БП совместно с Процессными рабочими груп-пами ;

• формируют требования к автоматизации и выявляют отклонения от референтной модели, согласовывают их с главным методологом;

• формируют предложения по изменению БП, связанных с автоматизацией; • оформляют соответствующие разделы ТЗ, согласовывают их с руководителем

группы методологов и с автоматизируемыми подразделениями; • моделируют процессы в системе в соответствии с утвержденным ТЗ;

9 Под утвержденной моделью может пониматься типовая модель реализации БП, «зашитая» в АС, либо рефе-рентная модель, предлагаемая консультантами. Это также может быть модель, используемая в рамках холдин-га. Далее под референтной моделью понимается описание бизнес-процесса в той или иной форме, регламенты их исполнения, описание типовых ролей пользователей, типовые формы документов.

112

• формируют постановку задачи на изменение функционала, доработку/разработку отчетов, согласовывают их с руководителем группы методологов;

• осуществляют тестирование и приемку программного обеспечения; • документируют результаты процесса моделирования, размещают их в проектной

БД; • формируют регламенты и инструкции по работе с АС по своему направлению; • формируют планы по обучению пользователей, обучают пользователей в соответ-

ствии с планом. Руководитель группы методологов осуществляет функциональное руководство деятельно-стью методологов:

• отвечает за процесс формализации требований к автоматизации БП, выявление от-клонений от референтной модели и согласования их с главным методологом;

• отвечает за процесс формирования ТЗ и согласования его с главным методологом; • отвечает за процесс моделирования процессов в системе в соответствии с утвер-

жденным ТЗ, целостность модели и соответствие утвержденным целям автомати-зации;

• осуществляет анализ требований к разработке/доработке функционала и отчетов, согласовывает их с главным методологом, утверждает постановку задачи на изме-нение функционала для группы программистов;

• осуществляет анализ постановок задач на формирование справочников и загрузку исторических данных в АС, утверждает их;

• осуществляет экспертизу регламентов и инструкций, сформированных методоло-гами по направлениям.

Группа программирования: • Выполняет работы по доработке функционала в соответствии с постановками за-

дач, утвержденными руководителем группы методологов; • Выполняет разработку/доработку отчетов, в соответствии с постановками задач,

утвержденными руководителем группы методологов; • Разрабатывает интерфейсные программы для загрузки справочников и начальных

данных в соответствии с постановками задач, утвержденными руководителем группы методологов;

Руководитель группы программирования: • Управляет процессом разработки/доработки функционала и отчетности, приемки,

тестирования, хранения программного обеспечения и документации; • Принимает от методологов утвержденные постановки задач, распределяет по про-

граммистам, формирует планы доработки, отслеживает их исполнение. Ответственный за управление справочниками:

• моделирует процесс управления справочниками: взаимодействует с методологами, собирает, анализирует, обобщает, формирует предложения по организации клас-сификационной структуры справочников («дерева»), правилам кодирования и идентификации объектов, регламенту сопровождения и владельцам справочников;

• документирует модель управления справочниками, размещает в проектной БД; • формирует планы по формированию справочников, предоставляет на согласование

руководителю группы методологов; • формирует постановки задач по загрузке справочников историческими данными,

оценивает правильность загрузки справочников; • курирует работу по ручному заполнению и выверке справочников функциональ-

ными подразделениями, организует экспертизу правильности заполнения; • формирует регламенты и инструкции по управлению справочниками; • формирует планы по обучению пользователей, обучает пользователей в соответст-

вии с планом.

113

Ответственный за загрузку исторических данных: • Взаимодействует с методологами по формированию требований к загрузке данных

из унаследованных систем или ручному формированию; • формирует планы по формированию исторических данных, предоставляет на со-

гласование руководителю группы методологов; • Управляет процессом загрузки исторических данных из унаследованных систем

(определяет источники выгрузки, формирует предложения по правилам загрузки данных (за какой период, с какими ограничениями и т.д.), формирует постановку задачи по загрузке для программистов, оценивает правильность загрузки разде-лов);

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

Группа администраторов серверов и баз данных: • подготавливает сервера к эксплуатации (устанавливает операционную систему,

СУБД, необходимые модули АС, сервисные программы (мониторинга, копирова-ния, защиты и т.п.);

• осуществляет формирование ролей, согласование с методологами; • осуществляет администрирование пользователей в соответствии с планом и пе-

речнем прав роли процесса; • осуществляет приемку отлаженных модулей АС и включение их в состав системы; • обеспечивает защиту и сохранность данных.

Группа программно-технической поддержки: • осуществляет монтажные и пусконаладочные работы; • устанавливает и настраивает клиентские рабочие места; • обеспечивает сетевое взаимодействий серверов и клиентских рабочих мест (сете-

вое администрирование); • оперативно устраняет технические неисправности.

Документирование хода проекта и проектная база данных Проект имеет свой внутренний документооборот, который не входит в документооборот предприятия, но необходим для эффективного управления проектом и обмена информацией между участниками; Все документы по проекту разделяются на 3 категории, каждая из которых предполагает свои правила документооборота:

• официальные документы взаимодействия сторон (в случае привлечения внешних субподрядчиков);

• документы по управлению проектом; • рабочие документы проекта (внутренние).

Официальные документы взаимодействия сторон – это документы, имеющие юридическую силу:

• договоры; • дополнительные соглашения; • акты сдачи-приемки выполненных работ и др.

Правила документооборота данных документов настоящим Уставом не регламентируются.

Документы по управлению проектом содержат информацию о значимых для проекта реше-ниях, событиях и результатах, к ним относятся:

• Инвестиционные документы проекта (заявка, приказ о реализации проекта, изме-нение параметров проекта и пр.);

• Устав проекта и изменения к нему; • Приказы по предприятию о ходе проекта (начало, реализация этапов, окончание); • Документы (приказы или распоряжения) по ООО «Служба АСУ»;

114

• Состав рабочих групп, Управляющего совета, Методического совета, сторонних подрядчиков;

• Протоколы заседаний, совещаний (Управляющего совета, Методического совета, Процессных рабочих групп);

• Планы работ; • Отчеты о выполнении задач и работ проекта; • Перечень проблем проекта и отчеты об их решениях.

К рабочим документам проекта относятся внутренние документы и справочная информация, например рабочая переписка и т.д.;

Для хранения информации по проекту используется база данных проекта, расположенная на общем сетевом ресурсе и предназначенная для хранения всей информации по проекту и об-мена данными между рабочими группами. Доступ участников к базе данных проекта осуществляет администратор соответствующего сетевого ресурса. Структура базы данных, описание хранимой информации и ответственные за своевременное размещение и актуальность информации приведены в приложении <…>.

Основные этапы проекта по автоматизации предприятия Основными этапами проекта являются:

• Подготовка серверов и баз данных; • Обследование и описание бизнес-процессов, определение требований к автомати-

зации; • Формирование и утверждение технических решений по автоматизации процессов; • Моделирование процессов, определение объема доработок/ разработок; • Программирование (доработка/разработка функционала и отчетов); • Формирование в системе справочников и исторических данных о документах (дви-

жении) и остатках; • Разработка схемы контрольных испытаний; • Разработка и утверждение регламентов и инструкций в соответствии с моделями

БП; • Администрирование и обучение пользователей; • Опытная и опытно-промышленная эксплуатации; • Доработка систем по результатам эксплуатации;

Общая схема взаимосвязи работ, участников и результатов приведена в приложении <…>.

Порядок завершения и приемки работ проекта Начало и окончание этапов проекта закрепляется <наименование документа>.

Приемка работ по окончании этапов проекта оформляется актами сдачи-приемки работ. Состав комиссии для приема работ определяется на этапе разработки схемы контрольных испытаний (опытной эксплуатации), закрепляется протоколом, согласуется со сторонами-участниками, утверждается <наименование должности>.

В общем случае к моменту завершения автоматизации направления должно быть выполнено следующее:

• создан необходимый объем нормативно-справочной информации; • определены и настроены рабочие места пользователей; • назначены: администратор системы, аудитор системы, владельцы справочников; • обучены и аттестованы пользователи, внесены необходимые изменения в должно-

стные инструкции; • разработан недостающий функционал системы (программы, отчеты) и описание

его;

115

• разработана рабочая документация для работы пользователей: регламенты и инст-рукции;

• разработано полное описание настроек системы и прав ролей.

Описание основных этапов проекта, порядок взаимодействия участников в проекте Планирование работ В управлении проектом используется три вида планов:

• Укрупненный план проекта; • План-график этапа проекта; • Детальный (внутренний) план-график проекта.

Планирование осуществляется «сверху вниз» и начинается с формирования укрупненного плана проекта. Укрупненный план представляет собой последовательность и длительность этапов проекта (вех), в соответствии с поставленными целями и выделенными ресурсами. План-график этапа проекта детализируется до основных задач, выполняемых рабочими груп-пами, сроков их выполнения и результатов. План-график первого этапа строится в соответ-ствии с укрупненным планом проекта. Планы-графики последующих этапов формируются в соответствии с результатами предыдущих этапов.

Укрупненный план проекта и планы этапов формируются Координатором проекта и согласо-вывается с Руководителем проекта и Куратором проекта. После устранения замечаний планы утверждаются приказами <наименование должности> о начале проекта или этапа проекта. Детальный план-график проекта формируется для каждого направления по принципу ежене-дельного скользящего планирования с периодом 3-4 недели. Еженедельное планирование работ по направлениям, контроль выполнения плана предыдущей недели и отклонений от общего плана, осуществляется на рабочих совещаниях и регистрируется в плане проекта ко-ординатором проекта. План проекта ведется в формате MS Project и размещается в проект-ной базе данных. Оперативные планы по загрузке данных и разработке программного обес-печения могут сопровождаться в Excel.

Подготовка технической базы Закупка оборудования для реализации проекта осуществляется <наименование>.

Подготовка серверов к эксплуатации осуществляется <наименование>. Начальное администрирование серверов осуществляется <наименование>, последующее - <наименование>. Обучение администраторов осуществляется <наименование>.

Обследование и описание бизнес-процессов, определение требований к автоматизации Координатор проекта составляет детальный план описания бизнес-процессов на предпри-ятии с указанием сроков и ответственных лиц. План утверждается приказом по предпри-ятию.

Обследование предприятия осуществляется группой методологов согласно инструкции по обследованию.

Автоматизация предприятия осуществляется согласно референтной модели автоматизации, разработанной <наименование>;

Описание референтной модели сравнивается с результатами обследования и расхождения отрабатываются с главным методологом и принимаются решения об ее изменении.

Формирование и утверждение технических решений (заданий) по автоматизации про-цессов Техническое решение по автоматизации бизнес-процесса - это документ, содержащий:

116

• Данные о составе, владельце, участниках процесса, краткие характеристики про-цесса;

• Цели автоматизации процесса; • Общую модель по автоматизации процесса: организации процесса с применением

АС, перечень автоматизируемых подпроцессов (функций) и результатов, в соот-ветствии с целями автоматизации;

• Перечень и формы документов процесса при работе с системой (получаемых из системы или вводимых в систему);

• Перечень основных справочников процесса; • Перечень основных информационных разделов процесса; • Дополнительную информацию по автоматизации бизнес-процесса: планируемые

средства автоматизации и др. Формирование и утверждение технических решений осуществляется в следующей последо-вательности:

• Методолог по направлению готовит проект технического решения на основании проведенного обследования БП, описания референтной модели и передает его на рассмотрение главному методологу;

• Главный методолог изучает техническое решение и предлагает его на согласова-ние владельцу процесса и процессной группе. Факт передачи технического реше-ния на согласование процессной группе закрепляется протоколом с указанием сроков согласования и предоставления замечаний в письменном виде;

• После изучения замечаний всеми заинтересованными сторонами, проводится со-вещание по обсуждению и согласованию требований. Спорные вопросы выносятся на заседание Методического совета и/или Управляющего совета. Принятые реше-ния закрепляются протокольно;

• Утвержденное техническое решение передается для организации работ по модели-рованию, формированию справочников и разделов АС методологу направления, ответственному за формирование справочников, ответственному за формирование в системе данных о документах (движении) и остатках;

• Все передачи технических решений сопровождаются служебными записками или фиксируются протокольно.

Моделирование бизнес-процессов Процесс моделирования заключается в подготовке алгоритмов реализации БП в системе в соответствии с утвержденным техническим решением и является «поставщиком» информа-ции для других процессов: загрузки, программирования, администрирования и др.

Результатами процесса моделирования являются следующие данные в формате Excel, раз-мещенные в проектной базе данных:

• Модели бизнес-процессов, содержащие информацию о том, какие подразделения и исполнители (должности), какие действия, когда и как выполняют в конкретной системе, какие данные вводят, какие документы получают;

• Перечень типовых ролей пользователей бизнес-процесса с их описанием (функции и права доступа);

• По словарям (справочникам) системы: o полный перечень словарей, используемых в процессе; o для каждого словаря перечень обязательных для заполнения реквизитов (с

пометкой реквизитов, которые не являются обязательными и необходима программная доработка);

o предлагаемые правила идентификации (наименования) и кодирования объ-ектов словарей;

o предлагаемая классификационная структура словаря и владельцы словаря. • По разделам системы, содержащим данные о документах (движении) и остатках:

117

o полный перечень разделов системы, содержащих документы (например, раз-дел «Приходные накладные», «Расходные накладные»);

o правила идентификации и нумерации документов (записей) раздела; o перечень разделов и реквизитов, необходимых для ручного или программно-

го формирования для начала опытно-промышленной эксплуатации; • Перечень конкретных доработок/разработок функционала, постановки задач; • Перечень документов, которые необходимо разработать/доработать, постановки

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

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

Регламент – документ, разрабатываемый на конкретный процесс (подпроцесс). Отвечает на вопросы: кто выполняет работу (функцию), в каком порядке (алгоритм), в какие сроки. Опи-сывает документы, их форму, порядок разработки, согласования, утверждения. Ссылается на инструкции и другие документы.

Регламенты, формируемые для проведения опытной эксплуатации, называются «временны-ми», и утверждаются приложением к приказу о начале опытной эксплуатации.

Регламенты, формируемые для промышленной эксплуатации, утверждаются приказом <на-именование должности> о начале промышленной эксплуатации, и должны быть преобразо-ваны в стандарты предприятия. Инструкция – документ, разрабатываемый на конкретную роль или функцию. Разрабатыва-ется на основе регламента. Отвечает на вопрос «как», «каким образом» выполняется работа, упоминаемая в регламенте, в системе.

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

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

• данные, на которых пойдет опытная эксплуатация; • последовательность проведения опытной эксплуатации; • перечень подразделений и ключевых пользователей этих подразделений.

Схема согласовывается на заседании Методического совета. Утверждается приложением к приказу <наименование должности> о начале опытной эксплуатации. Рекомендовано прове-дение опытной эксплуатации на 20 % реальных данных, с параллельным сопровождением существующих систем.

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

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

Администрирование рабочих мест и обучение пользователей осуществляется в два этапа: • ключевых пользователей (для проведения опытной эксплуатации); • всех пользователей (для начала опытно-промышленной эксплуатации);

118

Обучение проводится только с зарегистрированными в системе пользователями в соответст-вии с их ролями.

Управление изменениями проекта Под изменениями понимаются любые изменения в сроках, последовательности, результатах работ. Инициаторами изменений могут быть все участники проекта. Предложения по внесе-нию изменений первоначально рассматриваются на заседаниях групп и если они являются значимыми (существенное отклонение от сроков, изменение результатов проекта, воздейст-вие на планы других рабочих групп и т.д.) выносятся на уровень Руководителя проекта, Ме-тодического совета, Управляющего совета, закрепляются проектными документами (прика-зами, протоколами и т.д.), согласовываются со всеми заинтересованными сторонами.

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

• Номер проблемы; • Дата регистрации проблемы; • Ф.И.О. регистратора проблемы; • Наименование вопроса/проблемы; • Необходимый срок решения проблемы; • Предлагаемое решение проблемы (кратко); • Ответственный за решение проблемы; • Плановый срок решения проблемы; • Фактический срок решения проблемы; • Фактическое решение проблемы (кратко);

119

Процедура управления проблемами представлена в таблице: № Этап Участник

проекта Действия

1 Выявление про-блемы

Участник ра-бочей группы

Выявление проблемы и доведения ее сути до руководителя рабочей группы (РРГ) в письменной или устной форме

2 Анализ пробле-мы, регистрация проблемы

РРГ Изучение проблемы. Подтверждение или отклонение про-блемы. В случае подтверждения - регистрация проблемы в журнале проекта.

3 Решение пробле-мы на уровне РРГ

РРГ Если РРГ способен решить проблему, он с помощью уча-стников рабочей группы осуществляет ее решение. При этом назначается ответственный исполнитель за решение проблемы (указывается в журнале проекта). РРГ контроли-рует решение проблемы и закрывает ее, заполняя при этом соответствующие поля журнала проекта. Если РРГ не может решить проблему на своем уровне, он выносит ее на уровень Координатора проекта.

4 Решение пробле-мы на уровне Ко-ординатор проек-та

Координатор проекта

Координатор проекта регулярно просматривает журнал учета проблем и предпринимает действия по решению проблемы. У Координатора проекта есть три способа ре-шить проблему: 1) решить самостоятельно или с привлече-нием Руководителя проекта; 2) вынести на уровень Мето-дического совета; 3) вынести на уровень Управляющего совета. При этом Координатор проекта (Руководитель про-екта) назначает ответственного исполнителя за решение проблемы или подготовку решения для Методического (Управляющего) совета. Координатор проекта контролиру-ет решение проблемы и закрывает ее, заполняя при этом соответствующие поля журнала проекта.

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

Мониторинг хода проекта Общий мониторинг работ осуществляет Координатор проекта на еженедельном рабочем со-вещании, согласно расписанию. На общем совещании присутствует вся группа проекта и Ко-ординатор проекта, по необходимости могут быть приглашены другие участники. На общем совещании выявляются проблемы, решаются методологические вопросы, решения оформ-ляются протоколом, согласовываются с исполнителями и утверждаются руководителем про-екта. В случае необходимости вопросы выносятся на Управляющего совета и Методического совета; Для встреч по направлениям по необходимости составляется отдельный график встреч. Все графики встреч размещаются в проектной базе данных; Общий контроль за ходом проекта осуществляет Руководитель проекта на рабочем совеща-нии. На совещании с участием Руководителя проекта присутствуют Координатор проекта, руководители рабочих групп, приглашенные. Решения оформляются протоколом, согласо-вываются с исполнителями, утверждаются Руководителем проекта. Отчеты Руководителю проекта о выполнении работ и проблемах формируют Координатор проекта и руководители рабочих групп. Отчеты предоставляются Руководителю проекта ка-ждые две недели или по требованию. Формы отчетов приведены в приложении <…>.

120

Структура проектной базы данных (приложение к Уставу) Структура БД Основная информация Владелец папки

01. Методические материалы по АСУ Описание систем 02. Инвестиционный план Инвестиционные документы

на проект Координатор проекта

03. Управление проектом Координатор проекта 03.1. Устав проекта 03.2. Планы работ 03.3. Приказы и распоряжения 03.4. Протоколы и официальная

переписка

03.5. Отчеты и Акты 03.6. Технология работ по проекту Состав рабочих групп, контакты Мониторинг проблем

04. Бизнес-процессы «как есть». Тре-бования к системе

Методика описания процес-сов. Описание бизнес-процессов. Тех. решения по автоматиза-ции.

Руководитель группы методологов

05. Моделирование процессов Модели процессов. Перечни ролей и прав пользо-вателей Постановки задач.

Руководитель группы методологов

06. Доработка системы Регламент программирования. План-график доработ-ки/разработки функционала и отчетов

Руководитель группы программистов

07. Словари и разделы Постановки задач на загрузку, план-график загрузки, переч-ни словарей и их владельцев

Ответственный за формирование слова-рей и разделов

08. Администрирование и обучение пользователей

Перечень пользователей, план-график администриро-вания и обучения

Руководитель группы методологов

09. Регламенты и инструкции Регламенты и инструкции Руководитель группы методологов

10. Объявления 11. Прочее

121

Формы отчетов (приложение к Уставу) Отчет координатора проекта за период с_______________ по ________________

Наименование проекта

Ключевые вопросы

1. Изменился ли состав задач? ¢ Да ¢ Нет 2. Будут ли планируемые сроки нарушены? ¢ Да ¢ Нет 3. Существуют ли проблемы в планировании и отчетности? ¢ Да ¢ Нет 4. Существуют ли технические проблемы ¢ Да ¢ Нет 5. Существуют ли административные проблемы ¢ Да ¢ Нет 6. Существуют ли проблемы согласований (рецензирования) и

утверждений? ¢ Да ¢ Нет

7. Существуют ли проблемы методологии? ¢ Да ¢ Нет 8. Существуют ли проблемы финансирования? ¢ Да ¢ Нет

Объяснения по вопросам, отмеченным «Да» Достижения отчетного периода Планируемые достижения будущего периода Координатор проекта ______________________________ «____»________________________

Отчет руководителя рабочей группы _______________________________________________

Наименование рабочей группы

по проекту _______________________________________________________________________

Наименование проекта

Отчетный период с____________________ по ___________________ № Решаемая задача Дата

начала Дата

окончания (план)

Дата окончания

(факт)

Текущее состояние,

% вып.

Примечания

Проблемы по выполнению задач № за-дачи

Описание проблемы, при-чины

Путь решения Ожидаемое время решения

Примечания

Руководитель рабочей группы ______________________________ «____»________________________

122

Литература

1. Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, New-town Square, PA 19073 – 3299 USA / США (Американский национальный стандарт ANSI/PMI 99-001-2004).

2. Попов Ю.И., Яковенко О.В. Управление проектами: Учеб. пособие. – М.: ИНФРА-М, 2007.- 208 с. – (Учебники для программы MBA)

3. Управление высокотехнологичными программами и проектами / Рассел Д. Арчи-бальд; Пер. с англ. Мамонтова Е.В.; под ред. Баженова А.Д., Арефьева А.О. - 3-е изд., перераб. и доп. – М.: ДМК Пресс; Компания АйТи, 2006. – 472 с., ил.

4. Царьков А.С. Управление проектами: от идеи к документу: В графиках, таблицах, рисунках, примерах: Учебное пособие. — 2-е изд., перераб. и доп. / ГУ-ВШЭ. — М.: Издательский дом ГУ-ВШЭ, Н. Новгород: Университетская книга, 2007. — 320 с.

5. Управление проектами в области информационных технологий. Джозеф Филипс. Пер. М.Алексашин; ред. М.Ромашова. М.: Издательство «Лори», 2008.

6. Дао Toyota: 14 принципов менеджмента ведущей компании мира / Джеффри Лай-кер; Пер. с англ. – 2-е изд. – М.: Альпина Бизнес Букс, 2006. – 402 с. – (Серия «Модели менеджмента ведущих корпораций»)

7. Практика Дао Toyota: Руководство по внедрению принципов менеджмента Toyota / Джеффри Лайкер, Дэвид Майер; Пер. с англ. – М.: Альпина Бизнес Букс, 2006. – 588 с. – (Серия «Модели менеджмента ведущих корпораций»)

8. Система разработки продукции в Toyota: Люди, процессы, технологии. / Джеффри Лайкер, Джеймс Морган; Пер. с англ. – М.: Альпина Бизнес Букс, 2007. – 440 с. – (Серия «Модели менеджмента ведущих корпораций»)

9. Кайдзен: Ключ к успеху японских компаний / Масааки Имаи; Пер. с англ. – 3-е изд. – М.: Альпина Бизнес Букс, 2006. – 274 с. – (Серия «модели менеджмента ве-дущих корпораций»),

10. Монстр перемен. Причины успеха и провала организационных преобразований» / Джини Даниэль Дак; Пер. с англ. – М:. Альпина Паблишер, 2002.

11. Р50.1.028-2001 Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла. Методология функционального моделирования. Госстандарт России. Москва.

12. Материалы сайта WWW.ELITARIUM.RU: 12.1.Применение принципов военных стратегий в современном бизнесе. Авторы: Яо-

СуХу (Yoaho Su-Houh) из Hong Kong Shue Yan College и Пьер Бертон (Pierre Berton) из Cardiff Business School.

12.2.Методы преодоления сопротивления изменениям. Автор: О. Д. Волкогонова, доктор философских наук, профессор кафедры теории и технологий управления факультета государственного управления МГУ им. М.В. Ломоносова.