Введение в управление проектами.

Лекция 1 . Введение в управление проектами. История управления проектами. Определение понятия «проект». Типы и виды проектов Цели и стратегия проекта. Структура проекта История управления проектами История развития управления проектами как таковыми восходит к Ноеву Ковчегу и коллективной охоте первобытных людей на мамонта. Более того, некоторые элементы управления проектами можно усмотреть в поведении хищников, охотящихся стаями. Однако история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам прошлого века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США – авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon» [1]. В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов. Становление проектного менеджмента связано с военными разработками. В 1941 г. США приступили к выполнению Манхэттенского проекта с целью создания атомной бомбы. В 60-х годах стартовал проект НАСА «Аполлон», целью которого была высадка человека на Луне. В обоих случаях стояла задача координации действий по достижению целей в условиях жесткого ограничения времени. Проектный менеджмент разрабатывался и усовершенствовался как инструмент реализации сложных проектов, требовавших участия специалистов различных направлений и различных организаций. Первыми областями применения проектного менеджмента стали оборонные авиационные и космические проекты, введение новых технологий, например ядерной техники или поезда на магнитной подвеске и др. В 1937 г. американским ученым Л. Гуликом была предложена матричная организация для выполнения сложных проектов. Практическое применение в полном объеме она получила в 1953 – 54 гг. в подразделениях совместных проектов Воздушных Сил США, специальных проектов по вооружению и с 1955 г. в подразделении специальных проектов морского флота США. В 1956 г. компания «Du Pont de Nemours Co» образовала специальную группу для разработки методов и средств управления проектами. В 1957 г. к этим работам подключился исследовательский центр UNIVAC и фирма «Remington Rand». Коллектив, который возглавляли Дж. Келли и Р. Уолкер, разработал метод критического пути (CPM) с программной реализацией на ЭВМ. В последующие два года была завершена и опробована при создании ракеты «Поларис» система сетевого планирования PERT. Программа «Поларис» включала 250 фирмконтракторов и более 9 тыс. фирм-субконтракторов. С этого времени CPM и PERT стали использовать для планирования работ, оценки риска, контроля стоимости и управления ресурсами для ряда крупных военных и гражданских проектов в США. В 1959 г. комитетом Андерсона в НАСА был сформулирован системный подход к управлению проектом по стадиям его жизненного цикла. Тогда же вышла первая обобщающая статья Л. Гэддис по управлению проектами в журнале «Harvard Business Review». До этого времени, а отчасти и сейчас, секретность, присущая большинству проектов в военно-космической сфере, препятствовала распространению методологии управления проектами. В особенности это касается анализа проблем, определения целей и задач проектов, формулировок ограничений и критериев их успеха. В Советском Союзе было реализовано большое число крупных проектов как гражданских, так и оборонных. В качестве примеров можно назвать план ГОЭЛРО, сооружение Магнитогорского и Новокузнецкого металлургического комбинатов, строительство Волжского каскада ГЭС, создание атомного и ракетного оружия и т.д. Соответственно был накоплен и опыт управления такими проектами. Как правило, 1 проекты разрабатывались специализированными организациями – проектными институтами и научно-производственными объединениями, такими как, например, «Гидропроект», «Теплоэлектропроект» и др. В СССР, начиная с 30-х годов прошлого века, в ходе индустриализации страны и подготовки к войне реализовывались поражающие по своим масштабам и сложности проекты, осуществить которые в рамках относительно слабо развитой страны было гораздо труднее, чем в США. К таким проектам можно отнести создание каналов, каскадов гидроэлектростанций, атомного оружия и др. Министерство среднего машиностроения (атомная промышленность) стало, по существу, государством в государстве, производя для отрасли практически все – от атомного оружия до продуктов питания. При выполнении этих проектов, несомненно, был накоплен уникальный и ценный опыт. К сожалению, положительные стороны этого опыта до сих пор не обобщены и не опубликованы. Большая его часть, оригинальные творческие находки потеряны безвозвратно, поскольку основных организаторов и участников этих проектов уже нет в живых. Появление первых публикаций о сетевых методах дали толчок их развитию в СССР. В начале 70-х годов в СССР были разработаны оригинальные сетевые модели, более гибкие и мощные, чем в США (Г. М. Адельсон-Вельский, В. И. Воропаев, М. В. Шейнберг). Эти обобщенные сетевые модели были предназначены для сложных проектов с различными взаимосвязями между работами и временными ограничениями разного типа. Тогда же был разработан ряд стохастических и альтернативных моделей, учитывающих вероятностную природу различных элементов проекта: продолжительности работ, связей, ресурсов, альтернативных работ и др. (Д. И. Голенко, К. А. Антонавичюс, С. И. Лившиц). С 70-х годов сетевые методы начали преподавать студентам вузов как в США, так и в СССР. Движение в защиту окружающей среды в 70-е годы создало серьезные проблемы при осуществлении крупных проектов по сооружению атомных электростанций, гидростанций, химических производств и др. В связи с этим началась интенсивная проработка вопросов, связанных с внешним окружением проектов и включением в их планирование экономических, политических, экологических и других факторов. В это же время интенсивно разрабатывались методы управления конфликтами, проблемы организационных структур, формирования команды проекта, стиля управления. В 80-х годах П. Левене рассмотрел проблемы ресурсного и финансового обеспечения проектов как неотъемлемую составную часть проектного менеджмента. В эти же годы в СССР полностью централизованная и все более усложняющаяся система управления народным хозяйством подтолкнула к развитию методов мультипроектного управления и интегрированных систем управления (ИАСУ). В 1987 г. в США было опубликовано первое издание коллективной работы сотрудников института PMI (Project Management Institute) «Project Management Body of Knowledge» («Свод знаний по управлению проектами»). Проектный менеджмент окончательно сформировался как междисциплинарная сфера профессиональной деятельности. Далее началось стремительное распространение проектного менеджмента по странам и разным, в том числе нетрадиционным, сферам. Проектный менеджмент стал широко применяться в социальных и экономических проектах, программах помощи и т.д. Если на начальном этапе развития методология управления проектами рассматривалась только применительно к крупным и сложным проектам, то в дальнейшем утвердилась точка зрения, что многие ее элементы могут быть весьма эффективны и для выполнения малых проектов, вплоть до личных – организации отпуска, юбилея родителей, свадьбы и т.п. Ежегодно проходят всемирные конгрессы по управлению проектами. Были созданы национальные и международные организации, объединяющие специалистов по проектному менеджменту, например: 2 - Международная ассоциация управления проектами IPMA (International Project Management Association, г. Цюрих, Швейцария), в которую объединены свыше 50 национальных ассоциаций и десятки тысяч специалистов во всем мире (www.ipma.ch); - в Северной Америке – упомянутый выше PMI, членами которого являются более 500 тыс. человек в 185 странах (www.pmi.org); - в Германии – Союз проектных менеджеров Германии (www.gpm-ipma.de); - в Великобритании – Ассоциация проектных менеджеров APM (Association for Project Management); - в Японии – Японская ассоциация развития инжиниринга и др. Советская (ныне Российская) ассоциация управления проектами СОВНЕТ (www.sovnet.ru) была учреждена в конце 1990 г. и зарегистрирована 1 февраля 1991 г. как добровольное объединение коллективов и общественных организаций, частных компаний, фирм и предприятий, а также отдельных специалистов, осуществляющих подготовку, выпол-нение и управление проектами в разных сферах деятельности. Таким образом, в последней четверти прошлого столетия сформировался международный «Мир управления проектами», в котором объединены специалисты разных стран, направлений и сфер деятельности, разных национальностей и культур, что, несомненно, играет большую роль в развитии и обогащении управления проектами. Развитие мировой экономики в последние годы ясно продемонстрировало, что предприятия могут выжить в длительной перспективе, только если им удастся при тех же или меньших издержках производить больше товаров или товары лучшего качества. Постоянно нарастающие технические и организационные нововведения и изменения в связи с сокращающимся жизненным циклом товаров, необходимость выпуска их широкой номенклатуры, интернационализация рынка приводят к необходимости мобилизации последних резервов рационализации производства. Если в прошлом повышение качества товаров и увеличение прибыли могли быть реализованы главным образом за счет рационализации и усовершенствования производственных процессов, то сегодня эти резервы в основном исчерпаны. Поэтому проектный менеджмент может и призван помочь тем, что он мобилизует творческие способности каждого работника. Уже в 60-х годах прошлого века компании начали осознавать, что внедрение проектного менеджмента является необходимостью, а не просто одной из альтернатив. При этом вопрос состоял не в том, как внедрять управление проектами, а как быстро это должно быть сделано. Почти каждая компания сегодня использует методологию управления проектами в той или иной мере. Следует отметить, что процесс внедрения проектного менеджмента порой связан со значительным сопротивлением со стороны высшего руководства организаций, которое видит в нем определенную угрозу своему положению. Чаще всего эта категория руководителей заинтересова-на в сохранении статус-кво, причем эта заинтересованность основана скорее на интересах этого руководителя, чем на стратегических интересах организации в целом. Это обстоятельство, в свою очередь, приводит к разочарованию руководителей среднего уровня, стремящихся внедрить проектный менеджмент в интересах фирмы. Определение понятия «проект» Институт проектного менеджмента PMI определяет проект как ограниченное во времени намерение создать уникальный продукт, услугу или результат Проект (project) – это идея и действия по ее реализации с целью создания продукта, услуги или другого полезного результата. 3 Реализация проекта – это комплекс мер, дел и действий, направленных на достижение целей проекта Результат – созданный продукт, услуга, соответствующая требованиям, указанным в проекте. Существуют также различные толкования термина «управление проектами». Управление проектами – это процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью воплощения замыслов участников проекта. Энтони Уокер определяет управление проектами как планирование, координацию и контроль проекта с позиций его завершения (и ввода в действие) от лица заказчика и с учетом его целей в единицах полезности, предназначения, качества, сроков реализации и затрат; установление взаимосвязи между ресурсами, координацию и контроль участников проекта, их персонального вклада в общий результат, а также оценку и выбор альтернатив ради наибольшего удовлетворения потребностей заказчика . Гарольд Оберлендер считает управление проектами искусством и умением скоординировать людей, оборудование, материалы, деньги и последовательность работ по реализации проекта во времени и в рамках утвержденной стоимости . Профессор В. И. Воропаев предлагает следующее определение проекта: проект – это ограниченное по времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и специфической организацией. Включение в определение «отдельной системы» указывает не только на целостность проекта и наличие у него границ, но и подчеркивает единственность проекта (в отличие от серийного производства или текущей деятельности организации), а значит, его неповторимость и признаки новизны Таким образом, для различных людей управление проектами может означать разные вещи: науку, искусство, творчество и управление действиями. Однако в любом проекте большая часть времени управляющего тратится на организацию взаимодействия между участниками проекта. В процессе переговоров определяются проблемы, возникающие при реализации проекта и их возможные решения. Именно люди являются наиболее ценным ресурсом при управлении проектами. Они генерируют идеи, выявляют и решают проблемы, выполняют все необходимые работы. Иногда термины «реализация проекта» и «управление проектом» употребляются как синонимы, хотя на самом деле это не так. Управление проектом (project management) – это управление процессом его реализации. В свою очередь, реализация проекта – это комплекс мер, дел и действий, направленных на достижение целей проекта. Таким образом, управление проектом – это управление комплексом мер, дел и действий, направленное на достижение целей проекта. Типы и виды проектов Проекты могут различаться по сфере предложения, предметной области, масштабам, длительности, составу участников, степени сложности, влиянию результатов и другим характеристикам. Для удобства анализа и синтеза проектов, а также системы управления проектами их можно классифицировать по различным критериям (рис. 1.): 4 Рисунок 1 – Классификация проектов (1) 1. Класс проектов характеризует их по составу и структуре. Выделяют монопроекты, мультипроекты и мегапроекты. 5 2. Тип проектов зависит от сфер деятельности, в которых они осуществляются. Различают технические, организационные, экономические, социальные и смешанные проекты. 3. Вид проектов определяется характером предметной области. Существуют инвестиционно-строительные, инновационные, научно-исследовательские и учебнообразовательные проекты. 4. Масштаб проектов характеризует их по размерам, количеству участников и степени влияния на окружающий мир. Проекты делят на мелкие, средние, крупные и очень крупные. 5. Длительность проектов характеризует продолжительность их осуществления. По этому признаку проекты подразделяются на краткосрочные, среднесрочные и долгосрочные. 6. По степени сложности выделяют простые, сложные и очень сложные проекты. Современные проекты почти всегда имеют смешанный характер. Принято выделять социальный и культурологический, а также технический и технологический аспекты управления проектами (рис. 2). Рисунок 2 –Аспекты управления проектами Рациональное сочетание этих аспектов определяет результат и экономические показатели проекта. Обычно управляющие проектом уделяют больше внимания техническим и технологическим аспектам. Это неверно, так как социальные и культурологические аспекты играют значительную роль не только в реализации проектов, но и в текущей деятельности любого предприятия. Цели и стратегия проекта Этапом зарождения проекта является возникновение идеи (замысла) возможности что-то сделать и получить какой-либо результат. В процессе проработки о 6 идея принимает конкретные очертания в виде целей проекта. Постановка целей – необходимое условие успешной реализации проектов, она позволяет сконцентрировать усилия на одном или нескольких конкретных Цели проекта (project objectives) – это желаемый результат деятельности, достигаемый при реализации проекта в заданных условиях и направлениях Каждый проект включает как минимум одну цель, однако чаще таких целей несколько. Цели разных участников проекта могут различаться и даже конфликтовать между собой. Достижение целей проекта характеризуется тремя основными показателями: _ качеством; _ временем; _ издержками. Совокупность целей обычно подчинена определенной иерархии приоритетов:1-й уровень – генеральная цель проекта (миссия); 2-й – необходимые цели проекта; 3-й – желаемые цели проекта. Генеральная цель проекта (main objective), или миссия (mission) – это основная, наиболее общая причина его реализации с точки зрения будущего использования результатов проекта. Успешное достижение генеральной цели определяет успех реализации проекта. Разработка генеральной цели может осуществляться различными способами. Часто используется метод мозгового штурма: приглашаются представители поставщиков, подрядчиков, консалтинговых компаний и в процессе совместной работы формируется единое рабочее направление. Необходимые цели проекта (required project goals) представляют собой промежуточные цели различных этапов управления проектами. В отдельных случаях они могут изменяться и дополняться в процессе реализации проекта. Желаемые цели проекта (desired project goals) – это цели, которые не обязательны для успешной его реализации, однако некоторые участники проекта хотят и могут их достичь при определенных условиях. При определении цели проекта нельзя ограничиться заданием абстрактно желаемого результата, необходимо найти ответы на следующие вопросы: _ как в точности должен выглядеть этот результат (качественные и количественные характеристики результата проекта); _ какие условия должны учитываться при реализации проекта. Определение цели проекта – важный этап в разработке его концепции. После определения цели приступают к поиску и оценке альтернативных способов ее достижения. Для каждого проекта может быть построено множество взаимосвязанных целей, которые должны быть четко определены и иметь ясный смысл. Результаты, получаемые при достижении цели, должны быть измеримы, а заданные ограничения и требования – выполнимы. При управлении проектами область допустимых решений обычно ограничивается временем, бюджетом, ресурсами и требуемым качеством получаемых результатов. Все цели проекта можно разделить на явные (указанные в официальных документах и неявные (конфиденциальные или даже нелегальные, которые формально нигде н не записываются, но которым следуют в процессе управления проектом). В ходе реализации проекта под влиянием изменений в его окружении или в зависимости от получаемых промежуточных результатов цели проекта могут изменяться. Поэтому целеполагание нужно рассматривать как непрерывный процесс, в котором анализируются сложившаяся ситуация, тенденции и при необходимости осуществляется корректировка. 7 Следующей важной составляющей управления проектами является стратегия проекта (project strategy), в которой определяются процессы, действия и результаты достижения целей и миссии проекта. Иерархия различных ступеней целеполагания может быть представлена в виде пирамиды (рис. 3), в которой отражаются основные характеристики каждого уровня. При движении от вершины пирамиды к основанию детализируются действия по достижению результата проекта, впервые обозначенного идеей. Стратегия проекта должна вырабатываться на самой первой стадии его осуществления, быть комплексной и охватывать все основные аспекты его реализации. По мере разработки проекта стратегия должна обновляться и пересматриваться. Рисунок 3 –Пирамида проекта Процесс создания стратегии проекта состоит из следующих этапов: 1. Анализ ситуации (стратегий завершенных проектов-аналогов, а также факторов внешней и внутренней среды). 2. Оценка альтернатив и окончательный выбор стратегии (соответствие стратегии проекта целям долгосрочного развития предприятия; согласование целей и возможностей участников проекта; учет интересов сторон, не принимающих непосредственного участия в проекте, но на которые проект может оказывать прямое воздействие). 3. Реализация и контроль стратегии проекта (исполнение стратегии всеми участниками проекта, а также ее корректировка в зависимости от изменившихся условий и целей хозяйствования). Часто требуется специальный механизм координации исполнения проекта, для чего в организационной структуре предприятия формируют координирующий 8 орган. Структура проекта Понимание проекта как структурированного информационного объекта, подчиняющегося логическим суждениям и формальным правилам, является основой профессиональных методов управления проектом. Структура проекта (project structure) – это основные его части (элементы), необходимые и достаточные для эффективного осуществления процесса управления проектом. Построение структурных моделей проекта осуществляется по определенным принципам и методам. Для выявления и осознания целей, состава и содержания проекта, организации планирования и контроля процессов его осуществления необходимо определить и построить структуру работ проекта, используя методы декомпозиции. Структура декомпозиции работ (work breakdown structure – WBS) является графическим представлением проекта, т. е. совокупностью взаимосвязанных элементов проекта различных степеней детализации. Количество уровней детализации зависит от класса и сложности проекта, а также от разработчиков и исполнителей. Принятая структура проекта с выделенной в ней иерархией устойчивых элементов образует основу информационного языка проекта, на котором общаются все его участники и ведется документирование. В зависимости от вида проекта разрабатываются и используются различные структурные модели. 1. Дерево целей и результатов (cтроится в соответствии с основным назначением проекта). 2. Бюджет проекта (строится на основе расчета потребности в финансовых ресурсах) 3. Матрица распределения работ во времени и по исполнителям (строится в соответствии с директивным временем реализации проекта и набором возможных исполнителей). 4. Сетевая модель проекта (строится на основе логической очередности выполнения работ проекта и алгоритмов разработки сетевых моделей). 5. Матрица распределения и минимизации рисков (указывает возможные риски и способы их минимизации). 6. График обеспечения ресурсами (структурная модель ресурсов, требуемых для выполнения работ). 7. График финансирования проекта (указывает сумму средств, необходимых для реализации проекта в определенный промежуток времени). 8. Матрица распределения ответственности (строится на основе матрицы распределения работ по исполнителям). 9. Структурная декомпозиция контрактов (строится на основе матрицы распределения работ по исполнителям). 10. Структурная модель организации проекта (представляет декомпозицию организационной структуры проекта). 9 Рисунок 3 - Структура проекта Каждую из функций управления проектом, можно подвергнуть декомпозиции и внутренней структуризации. Примеры декомпозиции функций управления предметной областью ИСП, управления конфликтами, а также управления проектом по временным параметрам . Можно осуществить декомпозицию любой функции управления проектом, а структура и уровни декомпозиции, степень детализации зависят от целей и задач реализуемого проекта. Например, вполне очевидно, что декомпозиция функции управления предметной областью ИСП в жилищном строительстве будет отличаться от декомпозиции той же функции для проекта организации производства новых материалов для авиакосмической промышленности. К структуре проекта предъявляются следующие требования: 1. Уровни декомпозиции должны различаться степенью детализации. Совокупность элементов каждого уровня должна представлять весь проект. 2. Исходя из первого правила суммарные значения характеристик проекта (объемы работ, стоимость, потребляемые ресурсы и др.) на каждом уровне структуры проекта должны совпадать. 3. Каждый уровень декомпозиции должен содержать такие элементы работ, на основе которых могут быть определены количественные значения характеристик 10 работ, необходимые и достаточные для оперативного управления проектом на данном уровне. Ответственность за структурирование и декомпозицию работ возлагается на заказчика, подрядные предприятия, консультантов и других участников проекта. Разделение работ на этапы является основой для управленческого контроля в процессе реализации проекта. Литература: Заренков В.А. Управление проектами: Учеб. пособие. – 2-е изд. – М.: Изд-во АСВ; СПб.: СПбГАСУ, 2006. – 312 с. Дульзон A. A. Д81 Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 11 Лекция 2 . Основы управления проектами Стандарты и сертификация. Уровни международной сертификации. Правовое обеспечение проекта. Окружение проекта. Участники проекта 1.Стандарты и сертификация Международные и национальные ассоциации проектных менеджеров издают руководства и стандарты, которые регулируются и координируются IPMA (International Project Management Association, г. Цюрих, Швейцария) . Наиболее известным и широко распространенным стандартом является PMBoK («Project Management Body of Knowledge»). Впервые он был издан американским Институтом проектных менеджеров в 1987 г. В 2000 г. вышло второе, в 2004 г. третье, а в 2008 г. четвертое издание этого стандарта. Руководства и стандарты обеспечивают интернациональный и междисциплинарный характер управления проектами. Благодаря им руководители проектов во всем мире руководствуются аналогичной философией и методологией управления проектами и, соответственно, говорят на «одном языке». Вместе с тем стоит отметить, что стандарт PMBoK отражает требования к управлению проектами прежде всего с позиций интересов государственного заказчика, в частности министерства обороны США. В реальной жизни некоторые из этих требований, например критерии успеха проекта, существенно зависят от того, являемся ли мы заказчиками или исполнителями проекта. Нередко организация-исполнитель перерасход бюджета проекта рассматривает как успех, если это не привело к санкциям, хотя это и противоречит кодексу этики проектных менеджеров. Международные и национальные ассоциации проектных менеджеров активно участвуют в подготовке управляющих проектами и производят их сертификацию. Они ведут также и общедоступные реестры сертифицированных проектных менеджеров, с которыми можно ознакомиться на сайтах этих организаций. Группа сертифицированных специалистов Российской ассоциации управления проектами на основе и в соответствии с Международными требованиями к компетенции специалистов по управлению проектами (International Competence Baseline of the International Project Management Association – ICB, IPMA) разработала национальные требования к компетентности (НТК) специалистов по управлению проектами. В процессе разработки НТК вышли за рамки предусмотренного содержания и объема и по существу переросли в основы профессиональных знаний и требования к компетентности специалистов по управлению проектами. В итоге была подготовлена и издана книга «Основы профессиональных знаний и национальные требования к компетентности (НТК) специалистов по управлению проектами» (2002), ставшая основополагающим документом национальной сертификационной программы специалистов по управлению проектами IPMA / SOVNET. Кроме того, в издательстве «ЗАО “Проектная практика”» в 2010 г. вышла в свет книга «Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0)» [6]. Издание представляет основы профессиональных знаний, национальные требования к компетентности специалистов по управлению проектами и систему оценки их компетентности (NCB – National Competence Baseline SOVNET Version 3.0) и является нормативным документом Российской национальной сертификационной программы по управлению проектами. 1 2. Уровни международной сертификации Система сертификации, предлагаемая IPMA, включает четыре уровня, причем требования для каждого уровня зависят от требуемых в практической деятельности знаний, опыта, ответственности. Уровень А. Сертифицированный директор программ или проектов СДП (Certificated Project Director – CPD) должен: быть способным управлять всеми проектами компании или проектами ее отделения, или всеми проектами программы; иметь минимум 5-летний опыт управления комплексными проектами и программами, из которых не менее 3-х лет быть ответственным за руководство, координацию и управление портфелем проектов; уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения; иметь портфель конкретных стратегических предложений по общему управлению в компании; принимать участие в подготовке персонала, задействованного в управлении проектами, и управляющих проектами; нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств. Уровень B. Сертифицированный управляющий проектами – СУП (Certificated Project Manager – CPM) должен: быть способным самостоятельно управлять сложными проектами иметь минимум 5-летний опыт управления проектами, из которых не менее 3-х лет в качестве ответственного за руководство и управление сложными проектами; уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения; иметь портфель конкретных стратегических предложений по общему управлению в компании; принимать участие в подготовке персонала, задействованного в управлении проектами, и управляющих проектами; нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств. Уровень C. Сертифицированный профессионал по управлению проектами – СПУП (Registered Project Management Professional – RPMP) должен: быть способным самостоятельно управлять несложными проектами и помогать управляющему сложными проектами во всех функциональных областях управления проектами; иметь минимум 3-летний опыт управления проектами в качестве руководителя в функциональных областях несложного проекта; нести ответственность за осуществление несложного проекта и за все его параметры; 2 руководить небольшими группами персонала по управлению проектом; применять методы, средства и инструментарий по управлению проектами; быть способным работать в качестве руководителя группы специалистов, входящей в команду сложного проекта, и нести ответственность за соответствующие параметры проекта. Уровень D. Сертифицированный специалист по управлению проектами – ССУП (Certificated Project Management Specialist – CPMS) должен: обладать знаниями во всех областях управления проектами (и быть способным применять их в некоторых областях как специалист); обладать широким спектром знаний в управлении проектами и быть способным применять эти знания на практике; быть способным выступать в качестве члена команды проекта в любой функциональной области по управлению проектами 3.Правовое обеспечение проекта Реализация проектов происходит в условиях определенного правового окружения, которое включает систему законодательных актов, регулирующих инвестиционную деятельность, налоговое законодательство, порядок использования земельных, водных ресурсов, природной среды и др. Таким образом, нужно выбирать только легальный способ реализации проекта. При необходимости в команду проекта следует включать юрисконсульта, который свободно ориентируется в сфере реализации проекта (международном праве, национальном, региональном и местном законодательствах страны, в которой реализуется проект или часть проекта). В таких случаях основные решения имеют знания в области контрактных отношений и контрактного права. Предприятие, реализующее проект, обязано соблюдать федеральное, региональное и местное законодательство, а также требования органов государственного регулирования. Эти органы обеспечивают принудительное выполнение законов в сферах своей компетенции, а также вводят собственные требования, зачастую также имеющие силу закона. Региональные власти требуют от предприятий приобретения лицензий, ограничивают возможности выбора места расположения предприятия, облагают налогами, а иногда даже устанавливают фиксированные цены на некоторые виды продукции. Таким образом, предприятие, реализующее проекты в разных регионах и тем более в разных государствах, сталкивается со сложными правовыми системами, которые иногда противоречат друг другу. Рассмотрим основные этапы управления правовым обеспечением проекта: правовое планирование проекта; реализация правового планирования; адаптация к изменению правовых аспектов внешней среды; внутренняя координация правовой сферы проекта; правовые аспекты мотивации и компенсации работников и участников проекта; контроль выполнения обязательств. На первом этапе команда проекта планирует распределение прав и ответственности за реализацию проекта в целом и его отдельных частей между участниками проекта, анализирует сферу регулирования и вмешательства государства, а 3 также допустимые формы партнерства. Правовые вопросы имеют особое значение при реализации проектов за рубежом. Например, если иностранный банк решит осуществить проект выхода на российский рынок банковских услуг и открыть представительство в Москве, то ему необходимо принять во внимание правовые условия организации бизнеса в России. Иностранный банк не сможет открыть в России свой филиал (в соответствии с настоящими требованиями ЦБ РФ). Он должен учредить дочерний банк со стопроцентным иностранным участием, как это сделали Сити-банк, Райффайзенбанк, Дрезднер банк и др. На втором этапе происходят получение необходимых лицензий, заключение контрактов с участниками проекта, получение согласований и разрешений от государственных контролирующих органов, заключение трудовых договоров с дополнительным персоналом, специалистами и др. На третьем этапе осуществляется мониторинг состояния законов и норм госрегулирования, которые определяют, что может и чего не должно делать предприятие при реализации проекта. Только если предприятие подчиняется всем этим законам и нормативам, оно может считаться юридически ответственным. После выявления изменений в правовых аспектах внешней среды команда проекта должна адаптировать правовое обеспечение проекта к требованиям нового законодательства, а при невозможности – рассмотреть вопрос о ликвидации проекта. На четвертом этапе происходит внутренняя координация правовой сферы проекта. Это значит, что в случае изменения условий хозяйствования, поведения участников проекта, неисполнения ими своих обязательств и т. п. разногласия должны быть согласованы в рамках правовой сферы. Также необходимо проанализировать правовые последствия влияния одного события на другое. Например, в случае забастовки рабочих предприятие может не выполнить обязательства по проекту перед заказчиком и понести существенные убытки. Таким образом, при возникновении разногласий с рабочими следует пересмотреть правовую сторону конфликта и его последствия, проанализировать правовые взаимоотношения с заказчиком, если забастовка все-таки состоится. После этого команда проекта должна принять решение о нейтрализации конфликта и координации отдельных аспектов правовой сферы в нынешнем и будущих проектах, чтобы не допустить возникновения кризисной ситуации. На пятом этапе осуществляется пересмотр правовых аспектов мотивации и компенсации работников, выполняющих проект. Сложность и повышенная опасность выполнения работ в некоторых проектах требуют особого юридически закрепленного подхода для успешного выполнения работ. Так, трудовые договоры с работниками, выполняющими специализированные работы по проекту, могут предусматривать страхование жизни, предоставление дополнительного отпуска, оплату лечения при получении травмы и другие формы мотивации и компенсации. Для других предприятий, участвующих в проекте, могут предусматриваться программы разделения ответственности, дополнительных выплат за досрочную сдачу объекта и др. На шестом этапе производятся контроль выполнения обязательств, указанных в контрактах и договорах, а также решение спорных вопросов. В основе контроля лежит правовое поле, сформированное на предыдущих этапах управления правовым обеспечением проекта. Основой контроля является документооборот компании, подтверждающий совершение тех или иных хозяйственных операций. Таким образом, скорость движения информационных потоков в проекте является одной из важных составляющих всей системы правового обеспечения. Разделение управления правовым обеспечением проекта на этапы является условным (подчиняясь при этом логике реализации проекта), так как зачастую все этапы идут параллельно, пересекаясь во времени и дополняя друг друга. В управлении проектами выделяют следующие юридические аспекты [3]: 4 использование правовых основ во взаимосвязи с фактической ситуацией в проекте (трудовое законодательство, контрактное право, лицензии на продукцию, патенты, страхование, обязательства, конфиденциальность данных, дисциплинарное право, законы об охране окружающей среды и т. д.); предоставление информации, необходимой для выполнения проекта. Чтобы лучше понять степень влияния системы нормативно-правового регулирования в России на правовое обеспечение проекта, необходимо знать основные составляющие данной системы (рис. 1). Рисунок 1 – Схема нормативно-правового регулирования в России Правовое обеспечение является неотъемлемой составляющей управления проектами и очень важной формой функционирования правового общества. Единое законодательство и неукоснительное исполнение законов всеми хозяйствующими субъектами государства положительно влияют как на инвестиционную привлекательность перспективных проектов, так и на их практическую реализацию. 5 4.Окружение проекта Любой проект осуществляется в окружении некоторой динамической среды, частью которой он и сам является. Очевидно, что среда оказывает на него определенное, порой решающее воздействие [2]. Когда проект начат, он вскоре получает самостоятельную жизнь. Во время осуществления проекта его участники концентрируются на выполнении своих заданий. Они живут, думают и действуют в мире их проекта. В рамках долговременной организации - предприятия возникает маленькая, относительно кратковременная «организация - проект». При этом важно не потерять связь с окружающей действительностью. Руководитель и команда проекта должны понимать и постоянно отслеживать изменения внешней и внутренней среды. Рисунок - Окружение проекта К факторам ближнего окружения проекта прежде всего относится руководство предприятия, которое определяет цели и основные требования к проекту. Большое влияние на проект могут оказывать основные структурные подразделения предприятия, инфраструктура предприятия, отношение общественных организаций и коллектива в целом. К факторам дальнего окружения проекта могут относиться политические факторы, например политическая стабильность, поддержка проекта правительством; экономические факторы (цены, тарифы, налоги и т.п.); законы и право; характеристики общества; уровень развития и состояние науки, техники и технологий; состояние инфраструктуры страны; уровень развития и особенности культуры; природные и экологические факторы. Существенное влияние на проект, особенно на процесс его успешной реализации, оказывает внутренняя среда проекта. Внутреннюю среду проекта определяют[2]: стиль руководства проектом определяет психологический климат и атмосферу в команде проекта, влияет на ее творческую ак- тивность и работоспособность; специфическая организация проекта определяет взаимоотно- шения между основными участниками проекта, распределение прав, от- ветственности и обязанностей; участники проекта реализуют свои различные интересы в про- цессе осуществления проекта, формируют требования в соответствии с их целями и 6 мотивацией и оказывают влияние на проект в соответст- вии с собственными интересами, компетенцией и степенью участия в проекте; команда проекта является «мозговым центром», мотором и ис- полнительным органом проекта, от которого во многом зависит прогресс и успех проекта; методы и средства коммуникации определяют полноту, достоверность и оперативность обмена информацией между участниками проекта, что в значительной степени определяет успешность проекта; экономические условия проекта связаны со сметой и бюджетом проекта, ценами, налогами и тарифами, риском и страхованием, стимулами и льготами и другими экономическими факторами проекта и факторами, определяющими его основные экономические характеристики; социальные условия проекта характеризуются: - обеспечением стандартных условий жизни для участников проекта, - уровнем заработной платы, - предоставляемыми коммунальными услугами, - предоставляемыми социальными услугами (школы, детские сады, медобслуживание, отдых и т.д.), - условиями труда и техники безопасности, - страхованием и социальным обеспечением и др. Факторы окружения проекта демонстрируют, как глубоко простираются связи проекта с его окружением. Степень влияния этих факторов для различных проектов различна. В таблице 1 приведены экспертные данные о степени влияния факторов окружения проекта для основных типов и видов проектов сопоставимых масштабов. Таблица 1 -Влияние факторов окружения на различные виды проектов (оценка экспертов) [1] Из таблицы 1 видно, что наибольшему влиянию внешнего окружения подвержены социальные и инвестиционные проекты, затем организационные, экономические, в меньшей степени инновационные. Наибольшее влияние на проекты оказывают: 7 экономика, законы и право, затем культура, что несколько неожиданно, и только после этого политика и общество. Наименьшее влияние на проекты оказывают природа, экология и инфраструктура. Учитывая сказанное выше, в задачи руководителя проекта и его команды входят: - сбор полных требований к проекту и обеспечение проектной информацией всех заинтересованных участников; - формирование прогноза динамики окружения проекта; - постоянный мониторинг изменений внешнего и внутреннего окружения проекта; - формирование критериев оценки приоритетов и иерархии требований: от обязательных для исполнения до мелких пожеланий. 5.Участники / стейкхолдеры проекта В русскоязычной литературе по управлению проектами распространен термин «участники проекта». В зарубежной литературе обычно используется термин «stakeholders», который вошел в целый ряд языков мира. Под стейкхолдерами проекта понимают все организации и всех личностей, которых так или иначе (в положительном или отрицательном смысле) затрагивает проект и которые могут быть заинтересованы как в успехе проекта, так и в том, чтобы он вообще не состоялся. К примеру, в Германии строительство одной из автострад пришлось надолго приостановить, поскольку один из фермеров воспротивился прохождению ее через свой земельный участок, на котором жили и были похоронены многие поколения его предков. Состав стейкхолдеров проекта, их цели, роли, распределение функций и ответственности зависят от типа, вида, масштаба и сложности проекта, а также от фаз жизненного цикла проекта. Очевидно, что для любого проекта принципиальный состав функций остается неизменным. Однако в простейшем случае (например, теплица на дачном участке) все основные функции проекта могут осуществляться одним лицом. В другом крайнем случае (например, строительство автозавода) мы будем иметь полный набор стейкхолдеров с детальным разделением функций. Рассмотрим распределение ролей и как связаны с проектом и между собой основные стейкхолдеры проекта по выпуску новой продукции (рис.2 ). Заказчик – главная сторона, заинтересованная в осуществлении проекта и его успешности. Он будущий владелец и пользователь результатов проекта. Заказчик определяет основные требования и масштабы проекта, обеспечивает финансирование проекта за счет своих средств или средств привлекаемых инвесторов, заключает контракты с основными исполнителями проекта, несет ответственность по этим контрактам, управляет процессом взаимодействия между всеми участниками проекта. Он несет ответственность за проект в целом перед обществом и законом. Инициатор – стейкхолдер проекта, который является автором главной идеи проекта, его предварительного обоснования и предложений по осуществлению проекта. Часто, хотя и далеко не всегда, инициа-тива исходит от заказчика. Но в любом случае для успеха проекта важ-но, чтобы заказчик был реально заинтересован в осуществлении проекта. Инвестор(ы) – стейкхолдер(ы) проекта, вкладывающие средства в проект, например посредством кредитов. Цель инвесторов – максимизация прибыли на свои инвестиции от реализации проекта. Если инвестор и заказчик не являются одним и тем же лицом, то в качестве инвесторов обычно выступают банки, инвестиционные фонды и другие организации. Инвесторы вступают в контрактные отношения с заказчиками, контролируют выполнение контрактов и осуществляют расчеты с другими сторонами по мере выполнения проекта. Инвесторы являются полноправными партнерами проекта и владельцами всего имущества, которое приобретается за счет их инвестиций, пока им не 8 будут выплачены все средства по контракту с заказчиком или по кредитному соглашению. Рисунок 2 – Стейкхолдеры проекта по выпуску новой продукции [2] Руководитель проекта – лицо, которому заказчик и инвестор делегируют полномочия по руководству работами по осуществлению проекта (планирование, контроль и координацию работ всех участников проекта). Состав функций и полномочий руководителя проекта определяются контрактом с заказчиком. Обычно перед руководителем проекта и его командой ставится задача всеобъемлющего руководства и координации работ на протяжении жизненного цикла проекта до достижения определенных в проекте целей и результатов при соблюдении установленных сроков, бюджета и качества. Какими же профессиональными качествами должен обладать управляющий проектом? Рассел Арчибальд выделяет 14 основных личностных характеристик [4]: 1. Гибкость и адаптивность. 2. Высокая инициативность и лидерские качества. 3. Смелость, уверенность, убедительность, умение ясно выражать мысли. 4. Честолюбие, активность, влияние. 5. Эффективность в координации и интеграции усилий участников проекта. 6. Широкий круг личных интересов. 7. Уравновешенность, энтузиазм, умение творчески мыслить, искренность. 8. Умение сопоставлять технические решения со временем, необходимым на их реализацию, затратами и человеческим фактором. 9. Высокая организованность и дисциплинированность. 10. Больше универсал, чем специалист в какой-то одной области. 11. Способность и готовность посвятить большую часть своего времени планированию и контролю. 12. Способность выявлять проблемы. 13. Готовность к принятию решения. 14. Способность сохранять оптимальное равновесие при распределении 9 времени. Команда проекта – специфическая организационная структура, возглавляемая руководителем проекта и создаваемая на период осуществления проекта. Задача команды проекта – осуществление функций управления проектом до эффективного достижения целей проекта. Состав и функции команды проекта зависят от масштабов, сложности и других характеристик проекта, однако во всех случаях состав команды должен обеспечить высокий профессиональный уровень всех возложенных на нее обязанностей. Состав команды проекта может меняться. В обобщенном варианте команда проекта состоит из трех групп во главе с управляющим (рис. 3): основного состава команды проекта, вспомогательного состава и консультантов Рисунок 3- Состав команды проекта Управление небольшими проектами происходит по упрощенной схеме: управляющий может формировать команду из нескольких человек и осуществлять руководство от начала до конца, не разбивая команду на группы. В отдельных случаях возможно привлечение в команду сторонних специалистов для выполнения специальных работ по временному договору. В простых проектах управляющий может не формировать команду управления, а решать все вопросы по реализации проекта самостоятельно по договору с заказчиком или инвестором. Сегодня в России в большинстве случаев проектом руководят заказчик или генподрядчик и немного реже – инвестор. Как уже отмечалось, постепенно в России появляются компании, предлагающие услуги по управлению проектами «под ключ». Они действуют от имени заказчика или инвестора, или совместно с ним. Когда сложность и масштаб проекта требуют вовлечения в управление нескольких команд, общий результат проекта достигается реализацией локальных целей и задач каждой команды (рис. 4). Каждый треугольник представляет собой команду или группу команд. Несмотря на то что каждая из них выполняет свои функции, все они работают ради достижения целей проекта. Вне зависимости от размера команды, всегда должен быть управляющий проектом, который несет полную ответственность за результаты работы. Управляющий проектом генподрядчика (см. рис. 4) отвечает за весь проект, а управляющие проектами в подразделениях отвечают за выполнение работы командой в рамках своих подразделений Контрактор (генеральный контрактор) – участник проекта, вступающий в отношения с заказчиком и берущий на себя ответственность за выполнение работ по контракту. Это может быть весь проект или его часть. В функции генерального контрактора входит заключение контракта с заказчиком (инвестором), отбор и заключение договоров с суб10 контракторами, обеспечение координации их работ, принятие и оплата соисполнителей. В качестве контрактора может выступать руководитель проекта или другие активные участники проекта. Рисунок 4 – Управление проектом с помощью нескольких команд Субконтрактор – это лицо (в т.ч. юридическое), которое вступает в договорные отношения с контрактором или субконтрактором более высокого уровня. Он несет ответственность за выполнение работ и услуг в соответствии с контрактом. Проектировщик – юридическое лицо, выполняющее по контракту проектноизыскательские работы в рамках проекта. Он вступает в договорные отношения с генеральным контрактором проекта или непосредственно с заказчиком. Генеральный подрядчик – юридическое лицо, которое выбирается для реализации проекта. Он несет ответственность за выполнение работ в соответствии с контрактом, подбирает субподрядчиков для выполнения отдельных работ и услуг и заключает с ними договоры. В строи- тельных проектах роль генподрядчика обычно выполняют строительные или проектно-строительные фирмы и организации. Поставщики – субконтракторы, осуществляющие разные виды поставок на контрактной основе (материалы, оборудование транспортные средства и др.). Лицензор – организации, выдающие лицензии на право владения земельным участком, ведения торгов, выполнения определенных видов работ и услуг и т.п. Органы власти – сторона, удовлетворяющая свои интересы путем получения налогов от участников проекта, выдвигающая и поддерживающая экологические, социальные и другие общественные и государственные требования, связанные с реализацией проекта. Владелец земельного участка – юридическое или физическое лицо, являющееся владельцем участка земли, вовлеченного в проект. Он вступает в отношения с заказчиком и передает на договорной основе право пользования или владения этим участком земли. Производитель конечной продукции проекта – эксплуатирует созданные основные фонды и производит конечную продукцию. Его главная цель состоит в получении прибыли от продажи готовой продукции потребителям. Он принимает участие на всех фазах проекта и взаимодействует с основными участниками проекта. Его роль и функции зависят от доли собственности в конечных результатах проекта. Во многих случаях он является заказчиком и инвестором проекта. 11 Потребители конечной продукции – юридические и физические лица, являющиеся покупателями и пользователями конечной продукции, определяющие требования к ней и оказываемым услугам, а также масштаб рыночного спроса. Именно за счет средств потребителей возмещаются затраты на проект и формируется прибыль всех участников проекта. Рисунок 5 - Схема взаимодействия участников проекта Другие участники проекта. На осуществление проекта оказывают влияние и другие стороны из окружения проекта, которые по существу также могут быть отнесены к стейкхолдерам проекта: конкуренты основных стейкхолдеров проектов; общественные группы и население, чьи экономические и вне-экономические интересы затрагивает осуществление проекта; спонсоры проекта; различные консалтинговые, инжиниринговые, юридические организации, вовлеченные в процесс осуществления проекта, и др. Кроме субъектов – индивидов, групп, организаций – в число стейкхолдеров (в данном случае термин «участники проекта» совсем не подходит) рекомендуется также включать так называемых «безмолвных» стейкхолдеров, а именно [5]: будущие поколения (их еще нет, но их интересы необходимо учесть, чтобы не создать проблем нашим вмешательством в сегодняшнюю реальность, как это сделали с нами предыдущие поколения, – долги, исчерпание даже возобновляемых ресурсов, проблема атомных и промышленных отходов, кислотные дожди и т.п.); прошлые поколения (их уже нет, но их интересы представлены оставленной ими культурой. Мы не должны наносить ущерб материальной или духовной культуре); окружающая среда (мы не должны вредить среде нашего обитания, живой и неживой природе). Для определения полного состава стейкхолдеров проекта, построения его функциональной и организационной структур для каждого проекта на стадии разработки концепции проекта должны быть определены: 12 1. Предметная область – цели, задачи, работы и основные результаты, т.е. «что нужно сделать, чтобы реализовать проект?», а также его масштабы, сложность, допустимые сроки. 2. Отношения собственности, вовлеченной в процесс осуществления проекта (что, сколько стоит и кому принадлежит?). 3. Основные идеи реализации проекта (как сделать?). 4. Основные стейкхолдеры проекта (кого касается проект?). 5. Основные активные участники проекта (кто будет делать?). 6. Мотивации участников проекта (возможные подходы, ущербы, риски и т.д.). Ответы на эти вопросы позволяют выявить релевантных стейкхолдеров проекта, их цели, мотивации, определить взаимоотношения и на этой основе принять обоснованные решения по организации и управлению проектом. Литература: 1. Управление проектами: учебник для бакалавров / А.И.Балашов, Е.М.Рогова, М.В.Тихонова, Е.А.Ткаченко: под общей редакцией Е.М.Роговой.- М.: издательство «Юрайт»,2014.- 383с 2. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 3. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 4. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 5. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 6. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 7. Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 13 Лекция 3 . Процессы и функции управления проектами Процессы инициации. Разработка Устава проекта. Процессы планирования. Группа процессов исполнения. Группа процессов мониторинга. Группа процессов завершения Эффективная реализация проекта подразумевает последовательное (иногда параллельное) выполнение всех процессов управления проектами. В управлении проектом функции представляют собой различные группы деятельности, реализация которых на различных фазах жизненного цикла проекта определяет достижение конечного результата. Рисунок 1 – Системная модель управления проектом Рассматривая процессы управления проектами, подчеркнем важную роль в успешном достижении целей проекта процессов инициации, разработки и планирования. 1 Процессы Управления Проектами Именно здесь закладывается будущая эффективность проекта, которая достигается по завершении всех остальных процессов . 2 Процессы Управления Проектами  Процессы управления проектами могут быть разбиты на шесть основных групп: – процессы инициации - принятие решения о начале выполнения проекта; – процессы планирования - определение целей и критериев успеха проекта и разработка рабочих схем их достижения; – процессы исполнения - координация людей и других ресурсов для выполнения плана; – процессы анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям и принятие решений о корректирующих воздействий; – процессы управления - определение корректирующих воздействий, их согласование, утверждение и применение; – процессы завершения - формализация выполнения проекта и подведение его к упорядоченному финалу. Процессы инициации Под инициацией (initiation) в управлении проектами понимается процесс придания инвестиционной привлекательности новому проекту и работа по продвижению проекта. Прежде чем вкладывать в проект значительные инвестиции, необходимо его детально рассмотреть (рис. 2) и принять решение о целесообразности инициации проекта. Рисунок 2 – Алгоритм определения целесообразности проекта 3 Группа процессов инициации состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Процессы инициации часто выполняются вне рамок проекта и связаны с организационными, программными или портфельными процессами (рис. 3), которые и обеспечивают входы для группы процессов инициации. Тем самым границы проекта могут размываться. Например, перед началом операций в рамках группы процессов инициации документируются практические нужды или требования организации. Осуществимость нового предприятия может быть установлена путем оценки альтернатив и выбора наилучшей из них. Разрабатываются четкие описания целей проекта, куда включается и указание причин, почему данный проект является лучшим вариантом, удовлетворяющим требованиям. В документацию по данному решению также входит базовое описание содержания проекта, результатов поставки, длительности проекта, а также прогноз требуемых ресурсов для анализа инвестиций организации. Рамки проекта могут быть уточнены путем документирования процессов выбора проекта. Ответственность руководства в рамках организации определяется местом проекта в стратегическом плане организации. В многофазных проектах последующие фазы также включают в себя процессы инициации; это делается для оценки допущений и решений, принятых во время начальных процессов разработки Устава проекта и разработки предварительного описания содержания проекта. Рисунок 3 – Границы проекта (6) В ходе процесса инициации уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. На этом этапе также выбирается менеджер проекта, если он еще не назначен, и документируются исходные допущения и ограничения. Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется. Хотя команда управления проектом может участвовать в написании Устава проекта, одобрение и финансирование происходят вне границ проекта. Многие большие или сложные процессы могут быть разделены на фазы, как часть группы процессов инициации. Анализ процессов инициации в начале каждой фазы позволяет сохранять ориентированность проекта на те практические нужды, для достижения которых он был предпринят. Проверяются критерии начала проекта, в том числе наличие необходимых ресурсов. Затем принимается решение о том, может ли проект продолжаться или он должен быть отложен или прерван. На последующих фазах проекта производится дальнейшая проверка и разработка содержания проекта для данной фазы. 4 Повторение процессов инициации в каждой последующей фазе также способствует приостановке проекта, если практическая необходимость в нем отпала или решено, что проект ей не соответствует. Подключение заказчиков и других участников проекта во время инициации обычно способствует сотрудничеству, успешной приемке результатов поставки и, в конечном итоге, удовлетворению заказчиков и других участников проекта. Приемка проекта жизненно важна для успеха проекта. Группа процессов инициации (рис. 3) служит началом проекта (фазы проекта), а выход определяет цели и ставит задачи проекта, а также служит менеджеру проекта авторизацией для начала проекта. Рисунок 4 – Содержание процессов инициации (6) В группу процессов инициации входят следующие процессы управления проектами: 1.Разработка Устава проекта Этот процесс связан прежде всего с авторизацией проекта или фазы проекта (в многофазном проекте). Это процесс, необходимый для формулирования практических нужд и документального оформления нового продукта, услуги или иного результата, который должен удовлетворять этим требованиям. С помощью Устава проект привязывается к текущей работе организации, а также осуществляется авторизация проекта. Составление Устава проекта и авторизация проекта проводятся вне рамок проекта подразделением, управляющим организацией, программой или портфелем. В многофазных проектах в ходе этого процесса оцениваются или исправляются решения, принятые в предыдущем процессе разработки Устава проекта на предыдущей фазе. 5 2.Разработка предварительного описания содержания проекта Это процесс, необходимый для предварительного общего описания проекта с использованием Устава проекта и других входов процессов инициации. Этот процесс направляет и документирует требования к проекту и результатам поставки, требования к продукту, границы проекта, методы приемки и общее управление содержанием. В многофазных проектах этот процесс оценивает или уточняет содержание проекта для каждой фазы. Рисунок 6-Разработка предварительного содержания проекта: входы и выходы(6) Группа процессов планирования Команда управления проектом использует группу процессов планирования и составляющие ее процессы и взаимодействия для планирования и управления успешным проектом в интересах организации. Основные процессы планирования Цель группы процессов планирования – собрать информацию из нескольких источников, различных по уровню полноты и доверия. Процессы планирования разрабатывают план управления проектом. Эти процессы также обнаруживают, 6 определяют и дорабатывают содержание и стоимость проекта и составляют расписание для операций проекта, которые будут предприняты в рамках проекта. По мере того как появляется новая информация по проекту, будут выявляться или исчезать дополнительные зависимости, требования, риски, возможности, допущения и ограничения. Из-за присущей управлению проектами многомерности в ходе проекта неоднократно возникает необходимость в дополнительном анализе, а значит и в возвращении к уже утвержденным процессам. По мере того как выявляются и осознаются новые характеристики и информация, касающиеся проекта, могут возникнуть необходимость в доработках. Значительные изменения, происходящие во время жизненного цикла проекта, приводят к необходимости пересмотреть один или несколько процессов планирования и, возможно, некоторые из процессов инициации. Вспомогательные процессы планирования Это затрагивает также и частоту итераций процессов планирования. Например, план управления проектом, разработанный в качестве выхода группы процессов планирования, будет фокусироваться на изучении всех аспектов содержания, технологий, рисков и затрат. Обновления, возникшие в связи с одобренными изменениями в течение исполнения проекта, в значительной степени влияют на отдельные части плана управления проектом. Обновления плана управления проектом обеспечивают большую точность по отношению требований к расписанию, затратам и ресурсам для достижения заданного содержания проекта в целом. Обновления могут ограничиваться операциями и проблемами, связанными с выполнением отдельной фазы. Такую постепенную детализацию плана управления проектом часто называют "планированием методом набегающей волны", подчеркивая этим, что планирование в этом случае представляет собой итеративный и непрерывный процесс При планировании проекта команда проекта должна вовлекать в этот процесс всех необходимых участников проекта, в зависимости от их влияния на проект и его результаты. Команда проекта должна использовать участников проекта при планировании проекта, так как у них имеются навыки и знания, которые могут способствовать разработке плана управления проектом и вспомогательных планов. Команда проекта должна создать окружение, в котором участники проекта могли бы содействовать проекту. Так как процесс обратной связи и уточнения не может продолжаться бесконечно, установленные организацией процедуры определяют, когда планирование заканчивается. 7 На эти процедуры может влиять сущность проекта, установленные границы проекта, соответствующие операции по мониторингу и управлению, а также окружение, в котором будет исполняться проект. Взаимодействия между процессами в рамках группы процессов планирования зависят от характера проекта. Например, в некоторых проектах не будет никакого или почти никакого риска до тех пор, пока основная часть планирования не будет завершена. В этот момент команда проекта может осознать, что стоимость и расписание проекта составлены очень агрессивно, а риск на самом деле значительно выше, чем считалось ранее. Результаты итераций документируются как уточнения к плану управления проектом Группа процессов планирования способствует планированию проекта путем нескольких процессов. В нижеприведенном списке указываются процессы, к которым команда проекта должна обратиться, чтобы решить нужно ли их выполнять, и если да, то кем. В группу процессов планирования входят следующие процессы управления проектами: 1 Разработка плана управления проектом Это процесс, необходимый для определения, подготовки, координации и интеграции всех вспомогательных планов в план управления проектом. План управления проектом становится первичным источником информации по планированию, исполнению, мониторингу и управлению, а также закрытию проекта. Рисунок 7 -Разработка плана управления проектом: входы и выходы 2 Планирование содержания Это процесс, необходимый для создания плана управления содержанием проекта, который описывает, как будет определяться, проверяться и управляться содержание проекта и как будет создана и определена иерархическая структура работ. 8 Рисунок 8 - Планирование содержания: входы и выходы 3Определение содержания Это процесс, необходимый для разработки подробного описания содержания проекта, на основании которого будут впоследствии приниматься решения по проекту. Рисунок 9 - Определение содержания: входы и выходы 4.Создание иерархической структуры работ (ИСР) Это процесс, необходимый для разделения основных результатов поставки проекта и работ проекта на меньшие элементы, которыми легче управлять. 9 Рисунок 10 - Создание иерархической структуры работ (ИСР): входы и выходы 5.Определение состава операций Это процесс, необходимый для идентификации конкретных операций, которые следует выполнить для получения различных результатов поставки проекта. Рисунок 11-Определение состава операций: входы и выходы 6.Определение взаимосвязей операций Это процесс, необходимый для определения и документирования взаимосвязей между операциями 10 Рисунок 12- Определение взаимосвязей операций: входы и выходы 7.Оценка ресурсов операций Это процесс, необходимый для оценки типа и количества ресурсов, необходимых для выполнения каждой плановой операции. Рисунок 13- Оценка ресурсов операций: входы и выходы 8.Оценка длительности операций Это процесс, необходимый для оценки количества рабочих периодов, которые потребуются для завершения отдельных плановых операций. 9.Разработка расписания Это процесс, необходимый для анализа последовательности операций, длительности операций, требований к ресурсам и ограничений на сроки с целью создания расписания проекта. 11 10.Стоимостная оценка Это процесс, необходимый для разработки приблизительных значений стоимости ресурсов, необходимых для выполнения операций проекта. 11.Разработка бюджета расходов Это процесс, необходимый для суммирования оценок стоимости отдельных операций или пакетов работ для оценки базового плана по стоимости. Рисунок 14 -Разработка бюджета расходов: входы и выходы 12 Планирование качества Это процесс, необходимый для определения стандартов качества, которые соответствуют проекту, и средств достижения этих стандартов. 13 Планирование человеческих ресурсов Это процесс, необходимый для определения и документирования ролей в проекте, ответственности и отчетности, а также создания плана управления обеспечением проекта персоналом. 14.Планирование коммуникаций Это процесс, необходимый для определения потребностей участников проекта в информации и коммуникациях. 15.Планирование управления рисками Это процесс, необходимый для определения подходов к планированию и выполнению операций по управлению рисками проекта 16.Идентификация рисков Это процесс, необходимый для определения того, какие именно риски могут повлиять на проект, а также для документирования их характеристик. 17.Качественный анализ рисков 12 Это процесс, необходимый для установления приоритетов рисков с целью их дальнейшего анализа или действий путем оценки и совмещения их вероятности и воздействия. 18.Количественный анализ рисков Это процесс, необходимый для количественного анализа воздействия определенного риска на общие цели проекта. 19.Планирование реагирования на риски Это процесс, необходимый для разработки вариантов и операций дляповышения возможностей и снижения угроз целям проекта. 20.Планирование покупок Это процесс, необходимый для определения, что, как и когда следует приобрести. 21 Планирование контрактов Это процесс, необходимый для документирования требований к продуктам, услугам и результатам, а также для поиска потенциальных продавцов Рисунок 15-Планирование контрактов: входы и выходы (6) Группа процессов исполнения Группа процессов исполнения состоит из процессов, используемых для осуществления работ, означенных в плане управления проектом для выполнения требований проекта. Команда проекта должна определить, какие из процессов нужны для конкретного проекта команды. 13 Процессы исполнения Под исполнением подразумеваются процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Данная группа процессов включает в себя координацию людей и ресурсов, а также интеграцию и исполнение операций проекта в соответствии с планом управления проектом. Кроме того, в ходе этой группы процессов идет работа с содержанием проекта, определенным в описании содержания проекта, и в него вносятся одобренные изменения . Рисунок 16– Содержание процессов исполнения 14 Обычно при исполнении имеют место отклонения, приводящие к корректировке планов. Эти отклонения могут затрагивать длительность операций, наличие и эффективность ресурсов, а также непредусмотренные риски. Независимо от того, повлияют такие отклонения на план управления проектом или нет, они могут потребовать анализа. Результаты этого анализа могут повлечь за собой запрос на изменение. Если этот запрос будет одобрен, то это может привести к изменению плана управления проектом и, возможно, утверждению нового базового плана. Подавляющая часть бюджета проекта пойдет на выполнение группы процессов исполнения. В группу процессов исполнения входят следующие процессы управления проектами: 1 Руководство и управление исполнением проекта Это процесс, необходимый для управления различными организационными и техническими интерфейсами, имеющимися в проекте, для выполнения работ,предусмотренных в плане управления проектом. Результаты поставки представляются как выходы выполненных процессов, указанных в плане управления проектом. По мере выполнения проекта собирается информация о завершении подготовки результатов поставки и о том, какие именно работы завершены. Эта информация становится входом для процесса отчетности по исполнению. 2.Процесс обеспечения качества Это процесс, необходимый для применения плановых систематических операций по проверке качества например аудит или независимая экспертиза, чтобы удостовериться, что в проекте используются все необходимые процессы для выполнения требований. 3. Набор команды проекта Это процесс, необходимый для получения человеческих ресурсов, нужных для проекта 4. Развитие команды проекта Это процесс, необходимый для повышения компетенции и взаимодействия членов команды для улучшения исполнения проекта, выполнения проекта. 5.Распространение информации Это процесс, необходимый для обеспечения своевременного доступа участников проекта к нужной им информации 6.Запрос информации у продавцов Это процесс, необходимый для получения информации, расценок или предложений. Рисунок 17- Запрос информации у продавцов: входы и выходы (6) 15 7. Выбор продавцов Это процесс, необходимый для изучения предложений, выбора из потенциальных продавцов и заключения письменного контракта с продавцом. Группа процессов мониторинга и управления состоит из процессов, выполняемых для правильного исполнения проекта, так чтобы возможные проблемы были обнаружены вовремя и, в случае необходимости, могли быть предприняты корректирующие действия для управления исполнением проекта. Команда проекта должна определить, какие из процессов нужны для конкретного проекта команды. Главное достоинство этой группы процессов в том, что ход исполнения проекта регулярно контролируется и оценивается, что позволяет выявить отклонения от плана управления проектом. Процессы мониторинга  Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. В группу процессов мониторинга и управления входят также управление изменениями и рекомендации относительно предупреждающих действий в связи с возможными проблемами. В группу процессов мониторинга и управления, например, входят:  Мониторинг соответствия текущих операций проекта плану управления проектом и базовому плану исполнения проекта  Влияние на факторы, которые нарушают общее управление, для того чтобы внедрялись только одобренные изменения. Постоянный мониторинг дает команде проекта представление о состоянии проекта и выделяет участки, которым нужно дополнительное внимание. Группа процессов мониторинга и управления не только наблюдает и управляет работами, производимыми в течение группы процессов, но также наблюдает и управляет всеми действиями по проекту. В многофазных проектах группа процессов мониторинга и управления также обеспечивает обратную связь между фазами проекта с целью применения корректирующих или предупреждающих действий, чтобы проект не вышел из рамок плана управления проектом. Когда отклонения ставят под угрозу цели проекта, приходится возвращаться к соответствующим процессам управления из группы процессов планирования в соответствии с уточненной моделью цикла "планирование-исполнениепроверка-воздействие". Результатом такого анализа может стать рекомендация скорректировать план управления проектом. Например, если операция не завершена к намеченной дате, то может потребоваться изменение действующего плана обеспечения персоналом, введение сверхурочных работ, поиск компромиссных решений между 16 выполнением целей проекта и его бюджетом. На рис 18 приведены некоторые взаимодействия процессов, которые существенны для данной группы процессов. Рисунок 18 В группу процессов мониторинга и управления входят следующие 1 Мониторинг и управление работами проекта Это процесс, необходимый для сбора, измерения и распространения информации об исполнении проекта и оценки измерений и тенденций для влияния на улучшение процессов. Этот процесс включает в себя мониторинг рисков, что позволяет обеспечить выявление рисков на ранних стадиях, после чего составляется отчет об их состоянии и приводятся в исполнение соответствующие планы реагирования на риски. Мониторинг включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование. Отчеты об исполнении предоставляют информацию об исполнении проекта по таким показателям, как содержание, расписание, стоимость, ресурсы, качество и риски. 2.Общее управление изменениями Это процесс, необходимый для управления факторами, создающими изменения, чтобы эти изменения были благотворными. Он необходим также для отслеживания внесения изменений и для управления одобренными изменениями, в том числе временем их обработки. Этот процесс выполняется в течение всего проекта, от инициации до закрытия проекта. 3. Подтверждение содержания Это процесс, необходимый для формализации приемки завершенных результатов поставки проекта 4.Управление содержанием Это процесс, необходимый для управления изменениями в содержании проекта. 17 Рисунок 19 – Управление содержанием (6) 5.Управление расписанием Это процесс, необходимый для управления изменениями в расписании проекта. Рисунок 20- Управление расписанием (6) 6.Управление стоимостью Процесс влияния на факторы, создающие отклонения, и управление изменениями бюджета проекта. 7.Процесс контроля качества Это процесс, необходимый для мониторинга определенных результатов проекта с целью определения их соответствия принятым стандартам качества и выработки путей устранения причин неудовлетворительного исполнения. 8.Управление командой проекта Это процесс, необходимый для отслеживания деятельности членов команды, обеспечения обратной связи, решения проблем и координации изменений с целью улучшения исполнения проекта. 9. Отчетность по исполнению Это процесс, необходимый для сбора и распространения информации об исполнении. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса, а также прогнозирование. 18 10.Управление участниками проекта Это процесс, необходимый для управления коммуникациями с целью удовлетворения требований участников проекта и решения вместе с ними возникающих проблем. 11.Наблюдение и управление рисками Это процесс, необходимый для отслеживания выявленных рисков, мониторинга остаточных рисков, выявления новых рисков, выполнения планов реагирования на риски и оценки их эффективности в течение жизненного цикла проекта. 12.Администрирование контрактов Это процесс, необходимый для управления контрактом и взаимоотношениями между продавцом и покупателем, для изучения и документирования действий продавца и, в соответствующих случаях, для управления контрактными отношениями с внешним покупателем проекта. Группа завершающих процессов В группу завершающих процессов входят процессы, используемый для формального завершения всех операций проекта или фазы проекта, передачи завершенного продукта другим лицам или закрытия остановленного проекта. Когда эта группа процессов выполнена, она подтверждает, что во всех группах процессов должным образом совершены определенные процессы для закрытия проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта окончены. См. рис. 20. Рисунок 20- Состав завершающих процессов (6) В группу завершающих процессов входят следующие процессы управления проектами: .1 Закрытие проекта 19 Это процесс, необходимый для завершения всех операций всех групп процессов, чтобы формально закрыть проект или фазу проекта. 2.Закрытие контрактов Это процесс, необходимый для завершения и урегулирования каждого контракта, в том числе завершение действующих контрактов и закрытия каждого контракта, затрагивающего проект или фазу проекта Процессы завершения  Процессы завершения формализация выполнения проекта и подведение его к упорядоченному финалу. Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 3. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 4. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 5. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 6. Руководство кСводу знаний по управлению проектами Третье издание (Руководство PMBOK®) 20 7.Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 21 Лекция 4 . Планирование проекта Цели и задачи планирования проекта. Структурный план проекта. Процессный план проекта Проекты необходимо тщательно планировать, чтобы вопреки множеству воздействующих факторов достичь желаемого успеха проекта. Планирование проекта устанавливает ход его выполнения Общее содержание планирования проекта наглядно представлено на рис. 1. Поскольку на начальном этапе детали проекта еще не известны, то начинают с грубого планирования, а затем по мере прогресса проекта его все более детализируют. Планирование проекта представляет собой динамический процесс, результаты которого постоянно проверяются, актуализируются и уточняются. Рисунок 1 – Содержание планирования проекта Результаты планирования проекта являются существенной основой для принятия решений, и прежде всего, для решения о его проведении. Очень часто, особенно в больших проектах, возникают значительные отклонения по ходу проекта. Это порой приводит к сомнению в целесообразности планирования вообще. Фактом же является то, что отклонения становятся видимыми только при сравнении фактического состояния с планом. Поэтому необходимо найти баланс между обязательностью планов и достаточной гибкостью, чтобы не держаться за них тупо, когда в связи с изменениями или появившейся новой информацией целесообразнее их изменить. К примеру, понятно, что поставленные задачи по разработке нового изделия должны быть скорректированы, если конкурент в это время вышел на рынок с изделием, которое превосходит по своим характеристикам разрабатываемое. Планы существуют не ради самих планов, а для того, чтобы достигать целей. Если они своевременно помогают не пойти по ошибочному пути, то они свою задачу уже исполнили, даже если их приходится при этом заменить на новые. Увеличенные затраты времени на планирование обычно с лихвой окупаются меньшей общей продолжительностью проекта и меньшими общими затратами. Опыт создания военной техники показал также, что к моменту, когда 1 закончено планирование прототипа изделия и еще ничего не изготавливалось, уже предопределено 85 % будущих затрат на его разработку, изготовление, эксплуатацию и ремонт . Аналогичное соотношение справедливо не только для крупных военных разработок, но и для малых изделий гражданского назначения. Очень важно, чтобы в планировании проекта принимала участие вся команда проекта. Даже прекрасно составленный план, спущенный сверху, будет встречен скептически. Члены команды обычно желают быть успешными в работе, и все их протесты и сомнения по поводу плана работ, как правило, имеют под собой достаточно серьезные основания и должны быть внимательно рассмотрены. Исполнителям могут быть известны многие специфические детали работ и условия их выполнения, которые даже опытный планировщик может упустить. Кроме того, причастность членов команды к планированию приводит к тому, что они воспринимают планы как свои и готовы брать на себя ответственность за их соблюдение. Планирование начинается с описания структуры проекта, то есть описания состава входящих в проект работ и взаимосвязей между ними. Деление проекта на целесообразные и обозримые частичные задачи является существенным шагом в начале процесса планирования. Поскольку на начальном этапе детали проекта еще не известны, то начинают с грубого планирования, а затем по мере прогресса проекта его все более детализируют. Исходным и главным плановым документом, служащим основанием для всех остальных планов, является структурный план проекта. Структурный план проекта Структурный план проекта (WBS – Work Breakdown Structure) представляет собой стройную иерархическую декомпозицию проекта на составные части (элементы, модули), необходимые и достаточные для планирования и контроля осуществления проекта для различных участников проекта. Как следует из этого определения, структурный план проекта (СПП) представляет собой основной стержень для всех частей проекта и всех его участников. Иногда его называют также «планом планов» СПП используется в основном для реализации следующих целей: структурирования технических и административных плановых документов проекта, контроля над ходом выполнения проекта, установления графика отчетности, структурирования проектной документации, распределения работ между участвующими в выполнении проекта фирмами и между структурными подразделениями предприятия, создания баз данных по проекту. Деление проекта на составные части необходимо, чтобы каждая составная часть могла отдельно планироваться, управляться и контролироваться (рис. 2). Последняя, далее не декомпозируемая в структурном плане проекта задача (т.е. находящаяся на последнем уровне декомпозиции), носит название рабочего пакета или просто работы. Она должна быть точно определимой, контролируемой и четко ограниченной, а также относящейся к совершенно определенным ответственным за нее подразделениям или лицам. Этим определяется требуемое число уровней иерархии. Для небольших проектов может быть достаточно трех уровней, в то время как для больших и сложных проектов нередко требуется шесть и даже семь уровней. Работы с высокой степенью риска приходится порой разбивать до мельчайших деталей, чтобы спланировать 2 меры по их уменьшению. Прежде чем вкладывать в проект значительные инвестиции, необходимо его детально рассмотреть (рис. 2) и принять решение о целесообразности инициации проекта. Рисунок 2 – Структурирование проекта Желательно, чтобы по времени выполнения рабочие пакеты были по возможности относительно короткими. Это уменьшает потребность оценки степени выполнения по ходу работ. Установление состояния проекта становится возможным на базе законченных рабочих пакетов. Необходимо с самого начала выбрать подходящую цифровую систему кодирования работ. Коды работ могут быть использованы в течение всего проекта как уникальные индикаторы для самых разных целей: для определения ответственных за них лиц, отнесения издержек, отслеживания хода работ, отчетности. Весьма желательно, чтобы система кодирования была совместима с используемой системой управленческого учета, что существенно упрощает контроль издержек проекта. Большинство современных программных средств автоматически генерируют коды работ в процессе составления СПП. При этом они оказываются одинаковыми при планировании и контроле времени и издержек. Базой планирования является проектное/техническое задание (ТЗ). Особенно важно составление технического задания по инвестиционным проектам. В. А. Дьяченко по этому поводу пишет : «1. Без Техзадания вы никогда не сможете объективно сравнить результаты тендера, так как окажется, что один подрядчик имел в виду одно, а другой – совсем другое. 2. Без Техзадания (подписанного подрядчиком, которого вы выбрали) вы никогда не докажете подрядчику, что он что-то не сделал или сделал не так, как вы хотел 3. Без Техзадания вам никогда не получить близкую к реальности калькуляцию стоимости объекта до того момента, пока этот проект не выполнен» [8]. Прежде чем приступить к декомпозиции и детальному планированию, составитель плана должен ознакомиться с имеющейся информацией, из которой важнейшей является формулировка цели и ее описание. Желательно, чтобы она была представлена в форме технических требований (ТТ) и всегда в виде письменного документа. В технических требованиях на разработку материального продукта как минимум должны быть зафиксированы следующие данные 58: 3 идентификация продукта (название, обозначение, номер) с коротким пояснением применения. Целесообразно указать также родственные продукты (свои или чужие), а также родственную группу продуктов; цели маркетинга, которые предполагается решить с помощью разработки (группы потребителей, объем производства, целевые рынки по отраслям и регионам, имидж, уровень претензий); предварительные представления о цене и издержках; функциональные требования (техническая концепция): - принцип работы, рабочие области, - данные по рабочим характеристикам, граничные значения, допуски, - условия приемки; размеры и вес: - форма, конструктивные размеры, положение и функции подвода энергии, - места и конструктивные требования к точкам подключения энергии, газа, воды, стоков; условия эксплуатации, включая условия окружающей среды (например, для страны, в которую продукт предполагается экспортировать); конструктивные требования: - удобство обслуживания, доступность, - условия ухода, возможность ремонта, - возможность разборки на вторичное сырье, - системы контроля; требования по безопасности: - безопасность в эксплуатации, - защита от нанесения вреда, защита от шума, - условия ликвидации, защита окружающей среды. Начиная планирование проекта, следует сразу зафиксировать известные опорные даты. К ним относятся промежуточные и конечные сроки выполнения проекта, например предусмотренные договором. Они могут быть заданы как в виде точной даты, так и в виде интервала времени. Кроме того, они могут быть выражены в виде пожелания либо в виде твердо установленного договорного срока, в экстремальном случае с соответствующими финансовыми (или иными) санкциями за их нарушение. Следующая существенная для планирования информация касается различных ограничений, например информация по вопросам получения разрешений от различных инстанций. При этом следует уяснить, какие виды деятельности могут быть начаты только после получения таких разрешений. Для обзорности в качестве первого шага планирования составляется список известных к данному моменту частных задач (табл. 1). Таблица 1 4 Структурирование проекта может осуществляться по различным принципам: по объектам/предметам, например по изделиям, по видам деятельности или функциям, по фазам проекта, в виде комбинации из двух или трех вышеназванных подходов. Схема деления структурного плана проекта должна по возможности соответствовать естественному делению рассматриваемой системы. Предметная структуризация (рис. 3) не предоставляет достаточно информации для формирования рабочих пакетов Рисунок 3 - Предметная структура СПП Для формирования рабочих пакетов лучше подходит структурирование по видам деятельности или по функциям (рис. 4). Для малых, легко обзорных проектов зачастую достаточно структурировать СПП по видам деятельности, но многим проектам требуется большая детализация. Для них часто используется комбинированное структурирование СПП (рис. 5). Не существует единого, пригодного на все случаи жизни структурного плана, и, соответственно, нет и патентованных рецептов, каким образом выбрать оптимальный структурный план для конкретного проекта. Он зависит от вида проекта, установившихся традиций на предприятии и его организационных структур, а также от руководителя и команды проекта. 5 Рисунок 4 - Структурирование СПП по видам деятельности Структурный план проекта не рекомендуется составлять в один «проход». Он развивается циклично от грубого (в качестве первого эскиза) до все более детального плана. В каждом цикле появляются дополнительные представления о взаимосвязях, и наряду с другой информацией это дает основу для дальнейшей детализации. Порой становится очевидным, что первоначально выбранное деление целесообразнее заменить другой структурой, поскольку она лучше подходит для наглядного представления дальнейшей работы над проектом. Как правило, тщательная работа на этом этапе окупается за счет экономии времени и усилий на последующих этапах планирования и выполнения проекта. Уточнить структурный план проекта позволяет также анализ рисков. Дело в том, что должны быть выделены не только действия, связанные с подлежащими выполнению работами, но и действия, связанные с рисками и мерами противодействия им. Подход с позиций рисков особенно полезен для социальных проектов (работа с молодежью, проблемы безработицы и др.). Для этих проектов, в отличие, скажем, от строительства дома, нельзя уже на ранних этапах сказать, что необходимо сделать, и уж совсем невозможно оценить требуемые для этого время и средства. Если же подойти к делу с другой стороны и поставить вопрос о том, какие риски могут помешать достижению поставленной цели, то очень быстро можно выйти на действия, способные предупредить провал проекта. 6 Рисунок 5 - Комбинированный СПП В конечном счете СПП должен быть составлен так, чтобы: − весь проект мог быть описан как сумма всех элементов; − могло быть выполнено детальное планирование проекта; − могли быть определены издержки и бюджет проекта; − могли отслеживаться время, издержки и выполнение предметной области (работы); − цели могли быть логическим образом увязаны с ресурсами компании; − могли быть установлены процедуры контроля хода выполнения проекта; − могла быть установлена ответственность за каждый элемент проекта. Структурный план проекта содержит базовую информацию для всех дальнейших частных планов – организационного, временного, ма-териального снабжения, ресурсного, плана издержек, финансового. К сожалению, универсального алгоритма, который позволял бы абсолютно надежно идентифицировать все составные части проекта, до сих пор создать не удалось. На первом этапе целесообразно составить укрупненный структурный план проекта, ограничившись первой ступенью иерархии работ. Для дальнейшей декомпозиции структурного плана командой проекта могут быть применены обычные инструменты: 7 мозговой штурм, картографирование мыслей и др. Большую помощь могут оказать также различного рода вопросники. Даже весьма тщательное выполнение этой работы не может исключить риск пропуска существенных элементов проекта (порой с тяжелыми последствиями), однако сводит его к минимуму. В результате должен быть составлен по возможности полный список работ проекта. Каждый рабочий пакет должен иметь хозяина и быть четко описан. В общем случае описание пакета должно содержать: название проекта и фамилию руководителя проекта; название рабочего пакета; идентификационный номер пакета; описание пакета; фамилию ответственного за пакет и/или его непосредственного исполнителя; точное описание цели пакета; срок выполнения и время раннего начала и раннего окончания работы; технические и материальные предпосылки для реализации пакета; оценку объема работ; потребные ресурсы; если известны предшественники и последователи пакета, то фамилии их ответственных с указанием, с кем должен быть установлен контакт. Для описания пакетов может быть подготовлен бланк или заведены отдельные файлы. Для небольших единичных проектов часть вышеприведенных пунктов может быть опущена. Уровень детализации структурного плана должен быть таким, чтобы для каждого конечного рабочего пакета мог быть определен конкретный исполнитель (или организация), для которого дальнейшая детализация не требуется. При этом следует убедиться, что каждый исполнитель знает состав своего пакета и действительно достаточно компетентен для его качественного выполнения. К примеру, ответственный за пакет «Регистрация участников конференции» должен принять решения о том, когда, где и как будет проводиться регистрация, кто будет ее вести, обеспечить место регистрации мебелью, анкетами, раздаточными материалами, указателями «Регистрация участников конференции», передать итоги регистрации в президиум, организовать запись на экскурсии, а материалы передать для архивирования. Если имеются малейшие сомнения в том, что ответственный знает досконально весь объем работы по пакету и способен оценить затраты времени и ресурсов, может потребоваться введение следующего уровня иерархии СПП. Объем действий или операций, объединяемых понятием «работа», обычно соразмеряют со связанным с ним риском (как в отношении времени, так и в отношении затрат). Так как риск большой работы трудно оценить и еще труднее с ним управляться, каждому руководителю проекта следует стремиться к тому, чтобы раздробить работы до определенного уровня. Этот уровень определяется достижением обзорности работ. В результате риск оказывается достаточно хорошо просчитываемым. Далее лица, ответственные за работы, должны позаботиться об этих рисках с помощью соответствующих предупредительных мер. В отдельных случаях для пакетов, сопровождаемых большим риском, может быть целесообразна их дальнейшая детализация с позиций менеджмента рисков. В СПП в блок «Завершение проекта» целесообразно также сразу включить работу по оценке уроков проекта, а также заключительные мероприятия (ликвидация структур проекта, решение судьбы человеческих и материальных ресурсов, оформление заключительных финансовых и технических документов, архивирование, проведение заключительного собрания, награждение участников и т.п.). 8 На практике нередко возникают недоразумения по поводу структурного плана проекта и его организационной структуры. Обе структуры действительно являются организационными инструментами, однако служат различным целям. Структурный план проекта касается содержания проекта (что необходимо сделать?), а проектная организация касается организации работ (кто должен это делать?). Поэтому СПП нельзя рассматривать как органиграмму. Представленные в СПП иерархические уровни (ступени входимости) не идентичны уровням организационной структуры даже в том случае, когда имеется большое сходство. Должно быть выдержано правило: для каждого элемента СПП и для каждого рабочего пакета имеется ответственная единица (но только одна) в органиграмме. С другой стороны, та же единица (работник, подразделение) может быть ответственной за выполнение ряда элементов или рабочих пакетов СПП. Процессный план проекта Планирование процесса выполнения проекта (Project Logic Evaluation – PLE) осложняется тем обстоятельством, что многие работы связаны с выполнением других работ. Процессный план содержит информацию о том, какие работы связаны между собой и как их следует располагать во времени с учетом этих зависимостей, и. может быть представлен в виде графа (рис. 6) или таблицы (табл.2). Рамки проекта могут быть уточнены путем документирования процессов выбора Рисунок 6 – План процесса приготовления чая Часть этих причин почти не поддается управлению, другие же в определенных рамках могут быть изменены либо путем переговоров, либо за счет дополнительных затрат. Одни работы могут выполняться параллельно, другие же могут начинаться и выполняться только после полного или частичного завершения других работ 9 Таблица 2 10 Определить все взаимосвязи в объемных и сложных проектах возможно только при систематическом подходе к их определению. На практике используются два основных метода. Наиболее употребительным является способ, в котором начинают с конца проекта и идут шаг за шагом к его началу. Для каждой определенной работы определяют все предшествующие действия (работы), которые должны быть завершены, чтобы можно было приступить к выполнению данной работы. Другой, менее употребительный способ заключается в том, что начинают с первой от старта проекта работы и определяют все последующие работы, к которым можно приступать. Разработка плана процесса выполнения проекта осложняется еще и тем, что часто последовательность выполнения некоторых работ можно изменять. С одной стороны, это усложняет планирование, но, с другой стороны, за счет перестановки работ можно достичь оптимизации процесса выполнения проекта как с точки зрения времени, так и с точки зрения эффективного использования человеческих и материальных ресурсов. Далее следует иметь в виду, что даже если ряд работ может выполняться параллельно, в реальности может существовать (и, как правило, всегда существует) ограничение по ресурсам. Это может привести к изменению исходной логической последовательности работ. Так в примере, приведенном на рис. 6, три работы после старта могут выполняться одновременно (у них нет предшественников). Однако если чай готовит 11 один человек, у него просто не хватит рук (ограничение по ресурсам). Поэтому две работы он будет выполнять в период кипячения воды. Для небольших и простых проектов процессный план может быть составлен без привлечения программных продуктов. Но даже для относительно несложных проектов полезно применить достаточно простые программные продукты, например программу MS Project. Для больших и сложных проектов может потребоваться использование более мощных программных пакетов. Удобно вначале составить укрупненный процессный план проекта, а затем постепенно разворачивать каждый блок. Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 3. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 4. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 5. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 6. Руководство кСводу знаний по управлению проектами Третье издание (Руководство PMBOK®) 7.Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 8. Дьяченко В. А. Организация промышленного инвестиционного проекта: краткое пособие для «промбоцманов» / В. А Дьяченко. – Уфа, 2000. 12 Лекция 5 . Календарное планирование проектов . Метод сетевого планирования. Правила построения сетевой модели Расчет параметров сетевого графика (графический метод расчёта параметров сетевого графика ,табличный метод расчёта. ) Календарное планирование проектов с помощью линейной диаграммы Гантта Управление проектами (УП), как раздел теории управления, имеет продолжительную историю – начиная с 50-х годов прошлого века (появление метода критического пути) и заканчивая современными механизмами и технологиями управления проектами. Программа реализации модели системы на практике (в данном случае программа рассматривается не в смысле крупного проекта, а в традиционном смысле – как содержание и план действий ) – это конкретный план действий по реализации модели в определенных условиях и в установленные (определенные) сроки. Построение программы начинается с операции «определения основных вех». Определение вех составляет начальную, наиболее обобщенную часть программы, которая потом развертывается в укрупненный и, наконец, в детальный план. При определении вех используется информация о ключевых точках, состояниях, через которые будет проходить процесс реализации проекта. Вехи отмечают существенные, определяющие дальнейший ход развития процесса точки перехода. Поэтому вехи позволяют решать проблемы контроля реализации проекта, составляя набор естественных контрольных точек. При анализе выполнения работ вехи становятся эффективным средством управления (самоуправления), помогающим понять, на каком этапе находится процесс реализации проекта, оценить, достигнуты ли основные показатели состояния и сколько осталось времени, средств и конкретных работ до завершения проекта. Вехи не имеют продолжительности. Они используются в качестве дискретной шкалы, которая имеет всего две оценки – «выполнено» или «не выполнено». Так, например, при принятии решений по финансированию очередного этапа выполнения работ по договору вехи используются для оценки завершенности работ. Когда основные вехи определены, приступают к детальному планированию процесса реализации системы. 1 Детальное планирование – это разработка детального графика (графиков в случае сложного проекта) выполнения работ по реализации системы. Детальный график, независимо от размеров проекта и его сложности, должен включать: – все ключевые события и даты; – точную последовательность работ. Логика их выполнения должна быть зафиксирована с помощью сетевого графика, который позволяет проследить все виды зависимостей между работами и взаимосвязь событий реализации; – график служит основой для определения этапов и прочих временных интервалов по реализации системы. Кроме того, он позволяет при необходимости определять потребности в ресурсах для каждой из частей, фрагментов или событий процесса реализации системы. Форма представления графика, естественно, произвольна. Но она должна быть удобна для пользования, в том числе – наглядна и понятна для всех участников реализации системы. Метод сетевого планирования проектов При разработке детального графика реализации системы наиболее удобным и часто используемым является метод сетевого планирования. Суть его заключается в построении сетевого графика, являющегося графическим отображением всех работ по реализации системы и зависимостей (в том числе временных и «пространственных») между ними. Сетевые графики строятся в виде графа– множества вершин, соответствующих работам, и связывающих их линий, представляющих взаимосвязи между работами Основная цель работы с сетевым графиком заключается в том, чтобы сократить до минимума продолжительность проекта (время реализации системы), в первую очередь – за счет выделения и минимизации так называемого «критического пути». Максимальный по продолжительности путь в сети, связывающий начальную и конечную вершину, называется критическим. Сетевой график по сравнению с ленточным (всё ещё широко применяемым) имеет ряд преимуществ, в частности: на нём широко просматриваются взаимосвязи между работами; в график легко вводятся ранее не предусмотренные работы; на графике может быть легко выявлена технологическая последовательность работ, которая определяет конечные сроки всей разработки – критический путь; по сетевому графику можно определять резервы времени работ, не лежащих на критическом пути, что позволяет наиболее рационально перераспределять наличные, людские, материальные и финансовые ресурсы; этот график даёт возможность оптимизировать план предстоящих работ. Сетевой график (сеть) представляет собой план работ по созданию сначала промежуточной продукции с определённой степенью готовности, а в конце – полному его завершению, т.е. достижению конечной цели. Действительная работа и ожидание изображаются в сети сплошными стрелками , а зависимость(фиктивная работа) – пунктирами . Термин “событие” обозначает факт свершения одной или нескольких работ, без чего невозможно начало последующих. События изображаются на графике кружками или другими геометрическими фигурами. Событие в отличие от работы не является процессом, оно не имеет длительности, так как совершается мгновенно и не сопровождается затратами времени и ресурсов. Правила построения сетевой модели 2 При построении сетевых графиков необходимо соблюдать несколько весьма несложных логических правил: 1. График должен быть простым, без лишних перечислений. 2. Стрелки (работы) должны быть направлены слева направо. 3. Между двумя событиями может быть изображена только одна работа (рис начальное событие наименование работы продолжительность работы (t(i-j)) i j конечное событие Рис.1 4. Для параллельно выполняемых работ вводятся дополнительное событие и зависимость (рис.2). a b 1 2 неправильно a 1 3 b 2 правильно Рис 2 5. В сетевом графике не должно быть тупиков, т.е. событий, из которых не выходит ни одной работы (за исключением завершающих событий) или в которые не входит ни одна работа (за исключением исходных событий), например на рис.3 событие 4 является тупиковым, а в событие 2 не входит ни одна работа. 1 4 3 6 7 5 Рис 3 2 3 6. В сетевом графике не должно быть замкнутых контуров (на рис.4 работы 1-2, 2-3, 3-1 образуют замкнутый контур). 2 1 3 4 Рис 4 7. В сетевом графике не должно быть событий, обозначенных одинаковыми кодами (на рис.5 одинаково закодированы два события). 3 2 1 5 3 Рис. 5. 8. Сетевой график должен кодироваться так, чтобы стрелки (работа) выходила из события, закодированного меньшим числовым значением, и входила в событие с большим числовым значением. Расчет параметров сетевого графика Параметры сетевого графика рассчитываются одним из способов: аналитическим, табличным, методом расчёта на самом графике, с применением ЭВМ и др. Наиболее широко применяют метод расчёта сетевого графика на самом графике и табличный метод. В них полностью используются формулы аналитического метода. Для того , чтобы изучить методику расчета параметров сетевого графика и его оптимизацию , решим задачу. Задача.Разработать план выполнения ОКР по созданию нового образца телевизора в виде сетевого графика на основе перечня работ и трудоёмкости их выполнения, приведенных в табл.1, гр.1, 3-6. Произвести расчёт продолжительности каждой работы (i − j) исходя из заданной трудоёмкости и установленной численности (см. табл.1, гр.5 и 6); построить сетевой график на данный комплекс работ; закодировать построенный график; рассчитать параметры данного графика (наиболее ранние и наиболее поздние сроки свершения событий; наиболее ранние и наиболее поздние сроки начала и окончания работ; общие и частные резервы времени работ; продолжительность критического пути); произвести оптимизацию сетевого графика по параметру “время-людские ресурсы”. Решение. 1. Продолжительность выполнения каждой работы (i − j) определяется по формуле t (i − j ) = T(i − j ) Ч (i − j ) К В (1) , 4 T где (i − j ) – трудоёмкость работы (i − j), чел. -недель; Ч (i − j ) – численность исполнителей работы (i − j), чел.; К B – коэффициент выполнения норм времени (принимается равным 1). 1 1 2 3 4 5 2 0-1 1-5 1-2 1-3 2-4 6 4-5 7 3-5 8 5-7 9 5-6 10 11 6-7 2-7 12 7-8 13 8-9 3 Разработка технического задания Патентный поиск Выбор и расчёт скелетной схемы Разработка эскизного проекта Разработка принципиальной схемы Расчёт принципиальной схемы и определение допусков на электронные параметры Блочное проектирование макета нового телевизора Разработка и расчёт конструкторской документации для изготовления макета Проектирование технологии и специальной оснастки Изготовление оснастки Обработка данных расчёта скелетной схемы и подготовка к макетированию Изготовление макета нового телевизора Испытание макета нового телевизора, изучение свойств и параметров, корректировка схем, расчётов, документации Продолжительность выполнения работ, недель Численность исполнителей, чел. Работа Трудоёмкость, чел. -недель Номера предшествующих работ № п/п Код работы Таблица 1. Перечень ОКР по созданию нового образца телевизора 4 1 1 1 3 5 9 10 6 16 12 6 3 2 2 4 4 7 3 5 3 4 3 5 8 4 2 3, 4 20 4 5 2, 6, 7 24 6 4 2, 6, 7 20 4 5 9 3 30 8 6 2 5 4 8, 10, 11 40 8 5 12 15 5 3 Подставив в формулу (1) соответствующие данные по первой работе из табл.1, получим t (0−1) = 9 =3 3 ⋅1 недели. Аналогично производим расчёты по всем остальным работам, а результаты заносим в гр.7 табл.1. 2. Построение сетевого графика осуществляться на основании данных, приведенных в гр.1, 3 и 4 табл.1 (Рис.6). 5 Рис. 6. Сетевой график на выполнение ОКР по созданию нового образца телевизора 3. Кодирование сетевого графика выполняется в соответствии с правилом № 8. Коды событий проставляются по возрастанию от i до j (см. Рис.6), а также в гр.2 табл.1. 4. Расчёт параметров сетевого графика. Для пояснения методики расчёта рассмотрим два метода: 1. Расчёт параметров сетевого графика на самом графике(графический метод) 2. Табличный метод расчёта. Первый метод предусматривает расчёт следующих параметров: p − ранних сроков свершения событий ( ti ); n − поздних сроков свершения событий ( t i ); − резервов времени свершения событий ( Ri ). Для расчёта параметров сетевого графика по первому методу все события (кружки) делятся на четыре сектора (см. Рис.6). В верхних секторах проставляют коды событий. В левые секторы в процессе расчёта вписывают наиболее ранние сроки свершения событий p n t t ( i ), а в правые – наиболее поздние сроки свершения событий ( i ). В нижних секторах проставляют календарные даты или резервы событий ( Ri ). Расчёт наиболее ранних сроков свершения событий ведётся слева направо, начиная с исходного события и заканчивая завершающим событием. Ранний срок свершения p исходного события принимается равным нулю ( ti = 0). Ранний срок свершения j-го t события определяется суммированием продолжительности работы ( (i − j ) ), ведущей к j-му (t событию, и раннего срока предшествующего ему i-го события p j = t ip + t (i − j ) ). Это при условии если в j-е событие, входит одна работа (например, для события № 2 t 2p = 3 + 3 = 6 ), а если j-му событию предшествует несколько работ, то определяют ранние сроки выполнения каждой работы и из них выбирают максимальный по (t абсолютной величине и записывают в левом секторе события p j = max t (po i− j ) ). t (1po−5) = 3 + 5 = 8 t (po = 7 + 5 = 12 t (po = 9 + 2 = 11 ) 3 − 5 Например, ; ; 4 − 5) . Из этих значений выбирают максимальное – 12 и вписывают в левый сектор события № 5. Аналогично расчёт ведётся до завершающего события. Расчёт наиболее поздних сроков свершения событий ведётся справа налево, начиная с завершающего события и заканчивая исходным. Поздний срок свершения завершающего 6 события принимается равным раннему сроку этого события ( t9n = t9p t nj = t jp ). например = 30 . Это значение записывают в правый сектор события. Наиболее поздний срок свершения i-го события определяется как разность между сроками последующего j-го события, записанным в правом секторе, и продолжительностью t in = t nj − t (i − j ) работы, ведущей из i-го события к j-му событию, т.е. . Это значение вписывают в правый сектор i-го события, если из этого события выходит одна работа, а если из i-го события выходит несколько работ, то выбирают минимальное значение и записывают правый сектор i-го события, это и будет поздним сроком свершения i-го события. Например, из события № 2 выходят три работы с поздними сроками свершения событий: t (п2 − 7 ) = 22 − 4 = 18; t (п2 − 4 ) = 10 − 3 = 7 t (п2 − 3) = 7 − 0 = 7 ; . Из трёх значений выбирают минимальное, равное 7, и вписывают его в правый сектор события № 2. Аналогично расчёт ведётся до исходного события. Расчёт резервов времени на свершение событий. Резерв времени i-го события определяется непосредственно на сетевом графике вычитанием величины раннего срока свершения i-го события из величины позднего срока ( свершения i-го события R = t i n i ) − tip . Следует отметить, что все события, которые не имеют резервов времени, лежат на критическом пути, однако этого недостаточно, чтобы выделить работы, находящиеся на критическом пути. Например, несмотря на то, что у работы (5-7) ранние и поздние сроки свершения событий равны, она не лежит на критическом пути. Для выделения t − t i = t (i − j ) критических работ необходимо, чтобы j . p p =4 t Например, для работы (5-7): 22-12 = 10, а (5 − 7 ) , следовательно, данная работа имеет резерв и потому не является критической. Критический путь проходит по работам (0-1), (1-3), (3-5), (5-6), (6-7), (7-8), (8-9). Второй метод расчёта параметров сетевого графика (табличный) предусматривает расчёт следующих параметров: − наиболее ранних сроков начала i – j работ ( t (рi −.нj ) − наиболее ранних сроков окончания i – j работ ( − наиболее поздних сроков начала i – j работ ( r′ t (рi −.oj ) t (пi.−н j ) − наиболее поздних сроков окончания i – j работ R − общих резервов времени i – j работ ( (i − j ) ); ); ); ); t (рi −.оj ) ( ); r ′′ − частных резервов времени первого (i − j ) и второго (i − j ) вида работы i – j. Все указанные параметры сетевого графика определяются в табличной форме (табл.2). 7 Таблица 2. Расчёт параметров сетевого графика табличным методом Код i 1 1 1 1 2 2 2 3 4 5 5 6 7 8 j 2 1 2 3 5 3 4 7 5 5 6 7 7 8 9 t (i − j ) t (рi −.нj ) t (рi −.oj ) t (пi.−н j ) t (пi.−о j ) R(i − j ) r(′i′− j ) r(′i − j ) 3 3 3 4 5 3 4 5 2 5 4 5 5 3 4 3 3 3 6 6 6 7 9 12 12 17 22 27 5 3 6 7 8 6 9 10 12 11 17 16 22 27 30 6 4 3 7 7 7 18 7 10 12 18 17 22 27 7 3 7 7 12 7 10 22 12 12 17 22 22 27 30 8 1 4 1 1 12 1 6 9 4 1 12 1 6 10 1 4 11 6 Расчёт параметров сетевого графика начинают с заполнения первых трёх граф таблицы. В гр.1 и 2 записывают коды событий, строго по их возрастанию, а в гр.3 проставляют продолжительность выполнения работ.д.алее рассчитывают наиболее ранние сроки начала и окончания работ (см. табл.2, гр.4 и 5). Расчёт ведётся сверху вниз. Для работ, опирающихся на исходное событие, наиболее раннее начало принимают равным нулю ( t (рi −.нj ) ) = 0 и проставляют в гр.4 табл.2. Ранний срок окончания работ t (рi −.нj ) t (i − j ) (t в каждой строке ( р.o i− j ) = t (рi −.нj ) + t (i − j ) ) получается в результате сложения и . Полученный результат записывают в гр.5 табл.2. Для определения раннего срока начала последующих работ в вышерасположенных строках таблицы находится обозначение работы, у которой последующее событие j имеет номер предыдущего события i рассчитываемой работы, и значение t (рi −.oj ) из этой строки t (рi −.нj ) (гр.5) переносят в гр.4 строки рассчитываемой работы. Если начальному событию рассматриваемой работы предшествует несколько работ, то в качестве t (р5.−н6 ) t (рi −.нj ) выбирают наибольшее значение (t( р.н i− j ) { }). = max t (рh.−oi ) Например, = 12 , так как работе (5-6) предшествует три работы: (1-5), (3-5), (4-5), из которых работа (3-5) имеет максимальное раннее окончание равное 12, а работы (1-5) и (4-5) t (рi −.oj ) соответственно имеют , равное 8 и 11. Расчёт наиболее поздних сроков начала и окончания работ ведётся снизу вверх в гр.6 и 7 табл.2. Для завершающего события наиболее ранний срок свершения равен наиболее позднему t (рj.−ok ) = t (пj.о−k ) = t кр сроку и равен продолжительности критического пути, т.е. . 8 t (р8.−o9 ) = t (п8.−о9 ) = 30 Для нашего случая . Это значение записываются в гр.7 табл.2. Позднее t (пi.−о j ) начало определяется как разность между t (пi.−н j ) = t (пi.−о j ) и её продолжительностью, т.е. − t (i − j ) . Позднее окончание для каждой работы (i – j) определяется путём отыскания поздних п .н t начал работ − последующих за данной работой. Если за ней следует одна работа, то (i − j ) t п.о будет являться (i − j ) для рассматриваемой работы и её значение из гр.6 переносят в гр.7 табл.6.2. Например, данная работа (5-7), за ней следует одна работа (7-8), у которой t (п7.н−8 ) = 22 t п.о = 22 , следовательно, (5−7 ) . Если за данной работой следует несколько работ, тогда выбирается минимальное значение позднего их начала. Например, за работой (4-5) t = 12 t (5−7 ) = 18 следуют две работы (5-6) и (5-7), т.е. (5−6 ) и . Выбирают минимальное п .н п .н t (п4.о−5 ) = 12 значение, равное 12, и переносят из гр.6 в гр.7 для работы (4-5), т.е. . Полный (общий) резерв времени работы (i – j) определяют как разность между наиболее поздним (гр.7) и наиболее ранним (гр.5) окончанием работы (i – j), а результат R(1− 5 ) = t (п1.−о5) − t (1p−.o5. ) = = 12 − 8 = 4 записывают в гр.8 табл.2. Например, . Расчёт частных резервов времени работы (i – j) ведётся в табличной форме снизу вверх с использованием формул для определения частного резерва времени первого вида (результат записывают в гр.10 табл.2) r(′i − j ) = t (пi.−о j ) − t (пh.о−i ) − t (i − j ) . r(′2−7 ) = 22 − 7 − 4 = 11 Например, . Частный резерв времени второго вида рассчитывается по формуле (результат заносят в гр.9 табл.2) r(′i′− j ) = t (pj.−нk ) − t (pi −.oj ) . r(′2′ −7 ) = 22 − 10 = 12 Например, . 5. Оптимизация сетевого графика по параметру “время – ресурсы”. Эта оптимизация производится эвристическим методом. Сначала график оптимизируют по параметру “время”, а затем, если он удовлетворяет длительности критического пути, – по ресурсам (людским, материальным и др.). По параметру “время” существует несколько способов приведения графика в соответствие с заданными сроками, например, пересмотр топологии сети, сокращение продолжительности работ, лежащих на критическом пути, и др. t = 30 В нашем случае кр недель устраивает разработчика, и график пока не оптимизируется по параметру “время”. Оптимизация сетевого графика по параметру “людские ресурсы” сводится к расчёту численности исполнителей по календарным периодам и приведению её к заданным ограничениям. Для этого сетевой график наносят на календарную сетку (рис.7, а), при этом работы изображаются стрелками в масштабе времени их свершения по наиболее ранним срокам, а резервы времени работ (частные резервы времени работ второго вида) изображают пунктирными линиями со стрелкой. 9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 После построения графика в масштабе времени над стрелками (работами) проставляют числа исполнителей, которые затем суммируются по календарным периодам, и результаты сравнивают с располагаемой численностью. Под сетевым графиком строят график загрузки людских ресурсов по плановым периодам (рис.7, б). Если расчётные числа превышают располагаемую численность исполнителей в каком-либо периоде (в нашем случае располагаемая численность – 8 человек), то начало работ сдвигается на более ранние или более поздние сроки в пределах имеющихся резервов времени выполнения работ с таким расчётом, чтобы сумма людских ресурсов по календарным периодам не превышала наличную численность работников. В нашем случае имеется превышение численности в отдельные плановые периоды (см. рис.7, б) и недогрузка исполнителей в отдельные недели. В этой связи было перемещено начало выполнения отдельных работ в пределах имеющихся резервов времени. В частности, работа (1-5) перемещена на более раннее её начало с изменением топологии сетевого графика; начало работ (4-5) и (2-7) перемещено соответственно на величину их резервов; время выполнения работы (5-7) увеличено с 4 до 6 недель с сокращением численности исполнителей; срок выполнения завершающей работы (8-9) сокращён с 3 до 2 недель с увеличением численности исполнителей. 2 4 3 3 1 2 2 4 3 3 4 3 4 2 5 12 4 4 2 1 4 5 4 5 5 6 5 6 6 4 7 6 8 5 8 5 3 9 4 а) 12 11 10 9 8 7 6 5 4 3 2 1 12 10 8 10 8 8 6 5 4 4 3 б) Рис.7. Сетевой график и график движения людских ресурсов до оптимизации по параметру “время – ресурсы”. Сетевой график и график загрузки людских ресурсов после оптимизации представлены на рис.8. Приоритет передвижения работ по оси времени отдавался работам с наибольшими резервами времени. Из рис.8 видно, что критический путь сократился на 1 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 неделю и составил 29 недель, а численность исполнителей по всем плановым периодам не превышает 8 человек. 2 4 12 3 3 2 2 4 3 3 4 3 4 1 2 6 4 4 1 2 4 5 4 5 5 6 5 6 4 5 2 1 4 7 8 5 88 9 2 6 а) 12 11 10 9 8 7 6 5 4 3 2 1 8 5 б) Рис.8. Сетевой график движения людских ресурсов после оптимизации по параметру “время – ресурсы”. Календарное планирование проектов с помощью линейной диаграммы Гантта При разработке детального графика реализации спроектированной системы удобно также использовать так называемую диаграмму Гантта (ленточный график) – горизонтальную линейную диаграмму, на которой задачи реализации системы представляются протяженными во времени отрезками, характеризующимися календарными датами начала и окончания выполнения работ, а также, возможно, другими временными параметрами и, быть может, указанием взаимосвязи работ, используемых в них ресурсов и т.д. Пример диаграммы Гантта для такого организационного проекта, как проведение научной конференции, приведен на Рис. 9. Диаграмма Гантта - горизонтальная линейная диаграмма, на которой задачи проекта представляются протяженными во времени отрезками, характеризующимися датами начала и окончания, задержками и возможно другими временными параметрами. 11 Рисунок 9.1. Диаграмма Гантта Рис. 9. Временной график организации научной конференции (диаграмма Гантта) На Рис. 9 работы изображены горизонтальными прямоугольниками, пунктиром обозначены временные этапы. Здесь важно подчеркнуть то обстоятельство, что исполнители по тем работам, которые невозможно начать сразу, не дождавшись результатов предыдущих работ, не должны ждать, ничего не предпринимая. Они могут плодотворно использовать это время для планирования своей деятельности. Кроме того, несколько работ могут выполняться параллельно, если для этого хватает ресурсов. 12 В процессе освоения материала этой лекции рекомендуется изучение видео ресурсов: учебного фильма о сетевом планировании, мастер-класса построения диаграммы Гантта в Excel Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 3. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 4. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 5. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 6. Руководство кСводу знаний по управлению проектами Третье издание (Руководство PMBOK®) 7.Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 8. Дьяченко В. А. Организация промышленного инвестиционного проекта: краткое пособие для «промбоцманов» / В. А Дьяченко. – Уфа, 2000. 9. Новицкий Н.И., Пашуто В.П. Организация, планирование и управление производством: Учеб. -метод. пособие / Под ред. Н.И. Новицкого. – М.: Финансы и статистика, 2006. – 576 с 13 Лекция 6 . Управление стоимостью проектов Материальное и ресурсное планирование. Планирование издержек. Определение цены внешнего проекта Бюджет и финансовый план проекта Материальное и ресурсное планирование Нормальный ход проекта обеспечивается только в том случае, если в его распоряжение предоставлены необходимые виды и соответствующего качества ресурсы, причем: в необходимом количестве, в нужное время и в нужном месте. Планирование ресурсов происходит в три шага: 1) определение потребности в ресурсах: какие материальные и человеческие ресурсы требуются для выполнения проекта в соответствии с планом? 2) уточнение наличия ресурсов: какие ресурсы предоставлены в распоряжение проекта? 3) сравнение плановых и фактических ресурсов: какие имеются узкие места? Планируемая потребность в ресурсах должна быть привязана к определенной работе/рабочему пакету. Поэтому сначала определяют потребность по каждому виду ресурса для каждой работы. Затем ее суммируют для проекта в целом с учетом времени возникновения потребности. Для наглядности потребность в ресурсах представляется в виде диаграмм по каждому виду ресурсов. Описание рабочих пакетов, составляемое на основании структурного плана проекта, дает возможность определить также, когда должны выполняться те или иные монтажные работы. Полезно с самого начала планирования завести таблицу потребного оборудования, инструментов и программных продуктов (табл. 1). По мере детализации работ она будет уточняться и дополняться. Такая таблица позволяет команде проекта не только своевременно подготовить ресурсы, но и сделать более реальным план издержек проекта Таблица 1 . Далее определяются наличные ресурсы. При этом их надо группировать так же, как это было сделано при составлении плана потребности в ресурсах. Только следует иметь в виду, что располагаемые ресурсы, как правило, существенно меньше максимальных ресурсов предприятия. Так, например, для механизмов необходимо учитывать время на их обслуживание и ремонт, а для персонала отпуска, болезни, занятость на других работах и т.д. 1 Далее производится сопоставление плановой потребности в ресурсах с фактическим их наличием. Чаще всего выясняется, что в определенные периоды времени располагаемых ресурсов не хватает, а в другие периоды времени они оказываются не полностью загруженными (рис. 1). Рис.1. Сравнение плановой потребности в ресурсах с их фактическим наличием (- - - - наличие ресурсов) Флуктуации потребностей в ресурсах в период выполнения проекта неизбежны и всегда имеют место в той или иной степени. Чем больше разность между максимумом и минимумом потребности, тем обычно ниже эффективность их использования. Большие флуктуации не сказываются существенно на эффективности, если имеется возможность оперативного обмена ими с другими одновременно выполняемыми проектами. В противном случае возникают простои, которые ведут к снижению оплаты труда и, соответственно, к демотивации персонала, а также ряду других издержек. Если коэффициент использования трудовых ресурсов в проекте, определяемый как отношение суммарной трудоемкости проекта к общему располагаемому числу человеко-часов, ниже некоторого приемлемого значения (например, 70 %), то обязательно должно проводиться выравнивание потребности в ресурсах. Такое выравнивание повышает коэффициент использования трудовых ресурсов, что обеспечивает ряд преимуществ: уменьшение максимума потребных ресурсов означает, что в проекте будет единовременно занято меньше людей. Это упрощает для руководителя проекта процессы координации и контроля, а также может снизить издержки; отдельные члены команды будут работать в проекте более длительное время; сокращение резервов времени отдельных работ обеспечивает большую степень непрерывности процесса. Это может быть существенным, когда имеются непосредственные связи между работами; выравнивание ресурсов может сократить время, на которое проекту требуется субконтрактор, что также способно сократить издержки. Для решения проблемы неравномерной потребности в ресурсах используется несколько возможностей: компенсация в рамках рассмотренных в предыдущем разделе резервов времени, т.е. за счет смещения работ во времени; замена ранее планировавшихся ресурсов на другие, имеющиеся в наличии; 2 наращивание ресурсов, причем это может быть сделано как за счет привлечения ресурсов со стороны, так и за счет расширения собственных ресурсов предприятия (например, приобретение механизма); если приведенные меры недостаточны, то может быть рассмотрен вариант продления срока завершения проекта. При планировании материалов нужно иметь в виду, что они должны быть не только доступны, но также и предоставлены в распоряжение работников в нужное время, нужного качества, в нужном количестве и в нужном месте. К материалам относятся: сырье, которое входит непосредственно в состав создаваемого продукта; вспомогательные материалы, которые, хотя тоже входят в состав продукта, но с точки зрения их ценности и количества не имеют столь большого значения, как сырье; эксплуатационные (производственные) материалы, которые необходимы в процессе выполнения работ, но в состав готового продукта не входят (например, топливо и смазочные масла для механизмов); покупные изделия, которые приобретаются в других фирмах и непосредственно входят в состав создаваемого продукта. При часто повторяющихся работах потребность в материалах для отдельных работ зачастую указывается в виде норм расхода на единицу продукта с одновременным указанием стоимости. При планировании персонала требуется определенная дифференциация, в частности по уровню образования и квалификации. С точки зрения соответствия плановой потребности в человеческих ресурсах и фактического их наличия важным является вопрос о том, могут ли быть выделены в распоряжение проекта на определенное время дополнительные человеческие ресурсы и, соответственно, могут ли временно свободные исполнители проекта быть задействованы на других работах предприятия. Зачастую проблема таким способом не решается. Тогда в рамках проектного менеджмента могут быть использованы возможности регулирования отдельных работ в пределах резервов времени. Может быть также рассмотрено введение скользящего графика рабочего времени. Логическая схема планирования материалов представлена на рис. 2 3 Рис. 2. Схема материального планирования При решении вопросов обеспечения проекта необходимым оборудованием и материалами обычно рассматривается целый ряд альтернатив: делать самим или покупать (make or buy), взять в лизинг или купить (lease or buy), купить или арендовать (buy or rent), взять в лизинг или арендовать (lease or rent). Факторы, влияющие на выбор альтернативы «делать самим»: дешевле (но не всегда!); облегченная интеграция операций; использование существующих незадействованных ресурсов; сохранение прямого контроля; сохранение секретности разработки и производства; избежание ненадежных поставщиков; стабилизация имеющейся рабочей силы. Факторы, влияющие на выбор альтернативы «купить»: дешевле (но не всегда!); использование знаний и умений поставщиков; нужно незначительное количество (нет смысла затевать производство); ограниченные мощности или способности; необходимость набора дополнительного персонала; сохранение множественных источников (список квалифицированных поставщиков); непрямой контроль. 4 Многообразие взаимосвязей в планировании наглядно представлено на рис. 3. Понятно, что по ходу выполнения проекта план должен постоянно корректироваться, чтобы своевременно реагировать на возникающие ограничения. Определенные проблемы появляются в случае, когда специально для выполнения проекта необходимо приобретение дополнительных средств производства. К средствам производства относятся машины, установки, транспортные средства, оснащение зданий, сами здания, электронно-вычислительная техника и т.д., т.е. то, что необходимо для выполнения работ и что по окончании работ останется в прежнем, хотя и несколько изношенном виде. Обычно на проекты относится только часть стоимости средств производства в размере амортизационных отчислений. Однако если существующих средств производства для выполнения проекта недостаточно и требуется приобретение дополнительных, то необходимо сопоставить прибыль от реализации проекта со стоимостью приобретаемых средств. Если эта прибыль выше стоимости приобретаемых средств, такое приобретение имеет смысл. Если же реализация проекта позволит компенсировать лишь часть этих затрат, то следует выяснить, могут ли приобретенные средства быть эффективно применены на предприятии после завершения проекта или проданы. В последнем случае надо иметь в виду, что даже новое оборудование обычно может быть продано по цене, заметно меньшей, чем цена первоначального приобретения. Рис. 3. Взаимосвязи в интегрированном планировании Планирование издержек 5 Оценка издержек является прогнозом затрат на конкретные работы. Как слово «оценка», так и слово «прогноз» отражают большую долю неопределенности. Принимающий решение о выполнении нового проекта нуждается в надежных стоимостных оценках именно на ранней стадии проекта, т. к. приходится принимать решение не только о старте данного проекта, но и зачастую делать выбор между альтернативными вариантами. Общая дилемма заключается в том, что в начале жизненного цикла проекта должны приниматься самые важные решения, а уровень информации в этот момент минимальный. В последние годы все настойчивее ставится вопрос о последующих затратах, которые приходится нести тому, кто эксплуатирует вновь созданный продукт (установку, прибор, здание и др.). Это могут быть затраты на дополнительный персонал, топливо, обслуживание и ремонт и т.д. С ростом сложности проектов эти последующие затраты обычно существенно возрастают, что наглядно демонстрирует десятилетняя статистика Управления снабжения бундесвера Германии. Суммарные расходы на разработку, приобретение и эксплуатацию военной продукции оказались в соотношении 1:3: 6. Аналогичные данные (по 1979 г.) приводятся также и по Министерству обороны США: 1:2,6:6. При этом проблема последующих затрат не ограничивается только областью военной техники, космонавтики или самолетостроения, но во все большей мере затрагивает также общественный сектор, как, например, транспортные средства . Здесь нельзя умолчать также о том, что очень часто стоимость проектов неумышленно, а иногда и умышленно, сильно занижается. Умышленное занижение происходит по принципу: «Проект начнем, а недостающие деньги потом найдутся». Неумышленное занижение стоимости проектов происходит обычно из-за того, что не учитывается объем и сложность многих работ или упускаются некоторые факторы внешней среды проекта (например, экология или общественное мнение). В том и другом случае обычно возникают серьезные проблемы для проекта, которые не только осложняют его выполнение, но могут привести и к его прекращению. Кроме того, они серьезно вредят имиджу организаций, принимающих участие в таких проектах. Конечно, при оценке стоимости работ можно ошибиться. По этой причине многие люди испытывают глубокое отвращение к оценкам и стараются их обойти, особенно когда речь идет об оценках, опирающихся, образно говоря, на «глиняные ноги». Дело в том, что по опыту многие знают: раз высказанная оценка потом в определенной степени их обязывает, даже если, давая оценку, они настойчиво обращали внимание на ее низкую обоснованность. Однако даже при самых благоприятных обстоятельствах оценка остается оценкой и не более того. Непредвиденные обстоятельства в ходе проекта и обусловленный инфляцией рост издержек, правда, тоже можно оценить, но именно оценить, а не точно предсказать. Некоторые же внешние обстоятельства, могущие оказать решающее влияние на стоимость проекта, как, например, забастовки, приостановка строительства из-за протестов населения, стихийные бедствия и др., практически вообще не могут быть предсказаны. План издержек в рамках общего планирования проекта служит нижеприведенным целям и задачам: 1. Он необходим при калькуляции и определении цен в целях: заблаговременного определения издержек, создания основы для предварительной калькуляции, подготовки базы для принятия решения о том, стоит ли начинать проект. 2. Он служит вспомогательным средством при планировании, по-зволяя оценить экономичность рабочих процессов при: оценке альтернатив, сравнительных экономических оценках, оптимизации проекта, 6 реалистичной, привязанной к времени оценке издержек, что одновре-менно служит основой для последующего составления финансового плана. 3. Он нужен для контроля экономичности при выполнении проекта путем: задания плановых издержек для каждой работы, сравнения фактических и плановых издержек, своевременного обнаружения отклонений, чтобы была возможность как можно раньше принять корректирующие меры. Прямые издержки проекта имеют место, когда материальные ценности и услуги приобретаются непосредственно для проекта и, соответственно, могут быть непосредственно отнесены на издержки проекта. Для определения прямых издержек используются разные источники информации: - стандартные справочники; - базы данных предприятия; - материалы ранее выполненных проектов; - знание и опыт сметчиков. А. Roberts и W. Wallace подчеркивают, что хорошие сметчики жизненно важны для успеха проекта. Они должны быть точными и последовательными, что обеспечивает уменьшение общих рисков проекта. Каждый сметчик индивидуален, и два сметчика, анализирующие одну и ту же работу, дают различающиеся оценки издержек. Руководитель проекта должен правильно классифицировать сметчиков и при необходимости вводить определенные поправки В книге А. Roberts и W. Wallace приводят интересные характеристики различных сметчиков: точных, оптимистичных, пессимистичных и непоследовательных. Оптимистичные сметчики опасны. В связи с тем, что они занижают издержки проекта, они зачастую выигрывают контракты, но за это потом приходится дорого расплачиваться. Пессимистичные сметчики лишь незначительно менее опасны (потеря контрактов, неэффективное использование ресурсов). Но, пожалуй, наиболее опасны непоследовательные сметчики, поскольку на их оценки, в отличие от первых двух типов, невозможно ввести поправки. Косвенные издержки (накладные расходы) возникают, когда для проекта используются материальные ценности или услуги, которые одновременно служат и другим целям предприятия и которые необходимо поддерживать на работоспособном уровне либо сохранить их готовность. По этой группе отнесение издержек на проект не столь очевидно и однозначно. При выполнении внутренних проектов в организации зачастую на них либо вообще не относят накладных расходов, либо относят только в той степени, в которой они возросли в связи с выполнением проекта (граничные издержки). A. Roberts и W. Wallace приводят несколько иную, но весьма наглядную классификацию издержек (рис. 4.), которая отражает логику определения цены внешних проектов. 7 Определение цены внешнего проекта 8 Определение прямых издержек осуществляется в две фазы: сначала определяют расход ресурсов в натуральных единицах, например человеко-часах, литрах, метрах, кВтчасах и т.д., а затем их стоимость (табл. 2). Таблица 2- Определение издержек проекта Достоинством такого подхода является то, что минимальная единица проекта – работа (рабочий пакет) – является одновременно носителем информации о сроках, длительности, необходимых ресурсах и издержках. Это улучшает последующую их фиксацию и контроль во время выполнения проекта. При этом отдельные работы могут подвергаться оптимизации. Например, могут быть рассчитаны издержки при проведении проекта своими силами и сопоставлены со стоимостью заказа на стороне. Вполне может оказаться, что заказать на стороне выгоднее, например, если стороннее предприятие в связи со своей специализацией имеет более совершенную технологию и более опытный персонал. При расчете издержек это традиционный вопрос: «Сделать или купить?» (Make or by). Даже в том случае, когда изготовление у себя является более экономичным вариантом, выяснение цены в случае покупки на стороне может оказаться весьма полезным впоследствии, если, например, накопилось опоздание в ходе проекта и собственных ресурсов предприятия недостаточно для его компенсации. Если предприятие при неполной загрузке мощностей очень заинтересовано получить заказ клиента на проект, оно может при калькуляции работы установить возможный нижний уровень цены на основе граничных издержек. До тех пор, пока заказчик готов платить не менее этой цены, выполнение проекта для организации все же выгодней, чем отказ от него, даже если покрывается только часть накладных расходов. При этом улучшается экономическое состояние предприятия в целом. Основные трудности с оценкой стоимости материалов и оборудования связаны с непредсказуемостью проектов (особенно проектов НИОКР) и трудностью определения потребных объемов на ранних стадиях. Конструкторские работы к этому времени еще не выполнены, и во всяком случае часть материалов и оборудования не может быть специфицирована достаточно точно. С практической точки зрения полезно, чтобы люди, производящие оценку стоимости проекта, работали совместно с отделом снабжения предприятия. Отдел снабжения имеет информацию о широком круге поставщиков товаров и услуг и может уже иметь опыт приобретения того, что требуется для проекта. Кроме того, если отдел снабжения вовлечен в проект на стадии определения издержек, он будет более эффективно работать, когда начнется приобретение. 9 Расчет издержек с учетом временного плана проекта позволяет полу-чить план издержек с разверткой по времени (рис. 4.). Рис. 4.. План издержек Обычно при планировании издержек мы имеем дело с предварительной калькуляцией, а не с окончательными надежными цифрами, а всякий прогноз, как известно, связан с риском. Риск может, к примеру, заключаться в том, что материальные ценности в будущем уже нельзя будет купить по запланированным ценам. При долгосрочных проектах, продолжающихся больше года, целесообразно предусмотреть возможное повышение заработной платы. Цены на покупные изделия и на услуги тоже подвержены колебаниям, в особенности если они связаны с курсами валют. При оценке издержек в проектах по разработке и постановке на производство нового продукта используются различные подходы. Наиболее известным и наиболее часто применяемым из них является рассмотренный выше метод оценки, при котором для каждой работы оцениваются потребные ресурсы в натуральном выражении, как, например, потребные инженеро-часы, машино-часы, количества материалов. Затем эти цифры умножаются на принятые на предприятии расценки и цены. Однако такой детальный метод оценки предполагает, что к этому моменту должно быть выполнено глубокое структурирование и планирование проекта, на основе которого могут быть определены все работы и задачи проекта. Но именно это является большой проблемой на начальных этапах проекта, когда еще нет, да и не может быть, детальных плановых документов. В связи с этим попытка провести детальную оценку издержек на основе неполных плановых документов наверняка приведет к мало 10 реалистичным результатам. Кроме того, требующиеся для такой оценки относительно большие затраты усилий на этот момент не оправданы. Поэтому более рационально проводить укрупненную оценку издержек. При единоличной оценке на практике применяются два способа. В одном случае руководитель проекта сам оценивает все работы, в другом он поручает оценку каждому ответственному за рабочий пакет. Первый способ, конечно, быстрее и проще. Возникает вопрос: какие достоинства и недостатки имеют эти два способа с позиций точности оценки? Руководитель проекта, возможно, знает детали конкретной работы поверхностно, поэтому скорее даст заниженную оценку издержек, в особенности если на него «давит» ограниченная смета. Когда оценку производит конкретный ответственный за работу специалист, надо учесть разницу между новичком и «старым волком». Новичок скорее переоценит свои возможности и тем самым придет к заниженным издержкам. «Старый волк», наоборот, предусмотрит на всякий случай запас и скорее завысит издер Результат оценки зависит также и от того, является человек оптимистом или пессимистом. Каждый человек имеет некоторый зачастую достаточно стабильный коэффициент ошибки, который опытному руководителю проекта следовало бы знать. При многократной оценке руководитель проекта опрашивает ряд специалистов (по отдельности) и затем выводит среднее значение. Далее может проводиться также групповая оценка, где в результате общей дискуссии приходят к конечному результату. Здесь можно упомянуть и часто применяемый метод Дельфи. Сравнение приведенных четырех методов представлено в табл. 3 Сравнение методов оценки издержек Оценка издержек может производиться как сверху вниз (top-down), так и снизу вверх (bottom-up). В первом случае руководство организации на основе своего опыта, знаний и доступных данных о проекте устанавливает общий бюджет проекта и доводит эту сумму до руководителей следующего уровня. Они в свою очередь дальше дробят ее до уровня отдельных рабочих пакетов. Преимуществом такого подхода является то, что бюджет проекта совместим с общими стратегическими целями организации. Велика вероятность, что бюджет будет реален, т.к. исходит от высшего руководства. Недостатком подхода является то обстоятельство, что высшее руководство может плохо знать детали. Это проявится в нереалистичном бюджете, что отрицательно скажется на мотивации команды проекта, которой он навязан. Нереалистичный бюджет большого проекта может дезорганизовать всю финансовую систему предприятия. Кроме того, у руководства нередко есть «любимчики», которые могут получить неоправданно большой бюджет. Преимуществом оценки издержек проекта «снизу вверх» является то, что люди на «передовой» могут лучше знать, что необходимо и сколько это будет стоить. Кроме того, возрастает мотивация людей: самостоятельно установив свой бюджет, они более склонны его соблюдать. Недостатки такого способа установления бюджета: 11 - бюджет имеет более низкий статус, чем установленный руководством; - он может быть отвергнут руководством организации; - требуется следить за тем, чтобы его не урезали; - может оказаться трудным регулирование бюджета в соответствии со стратегическими изменениями; - руководители иногда ревниво реагируют на потерю части власти; - менеджеры нижнего уровня зачастую стараются на всякий случай завысить стоимость; - весь бюджет проекта может оказаться определяемым процессом его выполнения, а не условиями рынка. Компромиссным вариантом определения издержек и бюджета проекта является итеративный подход, основанный на переговорах. При этом исполнители и менеджеры нижнего и среднего уровня разрабатывают детальный план проекта и одновременно производят оценку стоимости работ, за которые они отвечают. Затем они представляют эти планы руководству организации. В процессе обсуждения и переговоров происходит уточнение объема и стоимости работ. В результате получается оценка стоимости проекта, лежащая где-то между консервативной оценкой высшего менеджмента, определяемой условиями рынка, и оценкой операционных менеджеров, определяемой процессом. Такой подход часто применяется для проектов, в основе которых лежит заказ. Преимуществом итеративного подхода является то, что он объединяет практические (операционные) соображения операционных менеджеров со стратегическими соображениями высшего руководства. Тем самым обеспечивается его реальность и одновременно учитываются стратегические цели организации и условия рынка. К недостаткам подхода относится то, что процесс переговоров требует много времени, а соответственно, дорог. Способность успешно вести переговоры может оказаться более существенной, чем умение верно оценивать работы. Некоторые операционные менеджеры могут «выторговать» себе более выгодный бюджет, чем их менее «пробивные» коллеги. Смета проекта может быть также заказана профессиональному сметчику. Он должен иметь специальную подготовку и соответствующий опыт. Достоинством является то, что сметчик может достаточно точно оценить отдельные работы, взаимозависимости, связанные с использованием множественных ресурсов, возможные риски и потребные для них резервы, а также он обычно представляет ограниченность оценок. Сметчик не подвержен влиянию команды проекта. Основным недостатком профессионального сметчика является то, что он не привержен команде проекта и его обязанности ограничены только профессиональной компетенцией. Наконец, оценка издержек может быть поручена непосредственно команде проекта. Достоинством здесь является то, что люди, производящие оценку, прямо ответственны и за реализацию работ. Команда проекта лучше всех знает потребности в ресурсах и их наличие. Она также хорошо представляет себе все ограничения системы. Основной недостаток команды проекта как оценщика издержек состоит в том, что часто у членов команды нет достаточного профессионализма в сметных вопросах. В результате увеличивается риск ошибок и слишком оптимистичных оценок. Выбор метода оценки издержек существенным образом зависит также от стадии выполнения проекта. В предпроектной стадии, когда информация о будущем составе работ минимальна, оценка уровня затрат обычно делается специалистами на основе укрупненных показателей стоимости. К примеру, при разработке новых высоковольтных импульсных устройств порядок затрат на их разработку может быть оценен исходя из 1$/В или 1$/Дж. Ошибка при этом, как правило, не превышает 100 %. Для большинства проектов вполне приемлемой на этой стадии считается точность ± 25 %. 12 Такая оценка обычно достаточна для принятия решения о принципиальной возможности выполнения проекта. С момента разработки концепции проекта оценки должны производиться уже на основе параметрических методов. Основой для оценки в этом случае являются известная информация и опубликованные данные. Обычно достигается точность оценки ± 10–15 %. Такой уровень точности достаточен для стадии участия в тендере и для переговоров с заказчиком. Методы детальной оценки могут быть использованы только в той фазе проекта, когда уже разработан структурный план проекта и составлены перечни работ и спецификации. Считается (по крайней мере, в США), что они должны обеспечивать точность ± 5 %, что с лихвой перекрывается резервами, предусматриваемыми большинством стандартных контрактов. Тщательный анализ издержек завершенных проектов позволяет накопить информацию для надежной оценки стоимости будущих проектов. Дело в том, что новые и сложные проекты в значительной степени состоят из известных элементов, по крайней мере их аналогов. Поэтому для фирм и директивных организаций очень важно иметь базы данных выполненных проектов с детальной информацией об их составе и стоимости. При оптимизации проектов с точки зрения их экономического эффекта необходимо рассматривать две стороны вопроса: повышение эффективности работ; здесь речь идет о том, чтобы то, что мы делаем, делать верно (англ. – doing things right); повышение результативности; здесь речь идет о том, чтобы делать верное дело (англ. – doing right things). Экономический эффект проекта, т.е. соотношение между входом и выходом, может быть повышен, если удастся заменить некоторые составляющие, дающие малый конечный результат на единицу издержек, на составляющие, дающие значительно больший результат на единицу издержек. Этот тезис требует пояснений. Дело в том, что обычно стараются снизить издержки проекта. Однако порой целесообразно их несколько повысить, если это дает существенное улучшение конечного результата. За радикальное улучшение тактико-технических характеристик изделия клиент нередко готов заплатить гораздо большую сумму. Бюджет и финансовый план проекта Для всех крупных (с позиций организации, выполняющей работу) проектов необходимо их финансовое планирование. Целями финансового планирования являются: обеспечение ликвидности, т.е. способности очередные платежи производить без задержек; обеспечение экономичности финансирования, в том числе, например, чтобы за счет ясных представлений о сроках платежей финансовые средства излишне не замораживались; сохранение финансовой независимости по отношению к контрагентам, поставщикам и другим внешним организациям. Основой для составления плана платежей обычно является план издержек. Однако необходимо учитывать, что только часть платежей совпадает по сумме и времени с издержками. К примеру, при приобретении материалов и комплектующих изделий имеют место исходящие платежи, а издержки появляются со значительной задержкой во времени только после списания материалов на проект. 13 При внешних проектах характер соглашения о платежах имеет осо-бое значение. Чем больше размер аванса и чем чаще осуществляется оплата за выполненные объемы работ, тем у исполнителя меньше проблем с сохранением ликвидности и меньше риск в случае прекращения проекта. К примеру, возможна ситуация, когда по проекту создается новое изделие по столь специальным требованиям заказчика, что оно не может быть использовано другими, или имеет для других только ограниченную ценность, или круг возможных клиентов весьма узок. В этом случае возникает риск, что при неплатежеспособности заказчика другое применение изделия либо совсем невозможно, либо сопряжено с большими убытками, даже если договором предусмотрено право собственности на изделие. Составление бюджета проекта преследует цель обеспечить финансовую прозрачность различных его альтернатив. Утверждение бюджета знаменует завершение плановой фазы. С момента его утверждения он становится обязывающим документом для ответственных за проект лиц и основой для последующего контроля. Ответственной за проект организационной единице для выполнения поставленных задач бюджетом на определенный период выделяются определенные средства. Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 3. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 4. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 5. Руководство к Своду знаний по управлению проектами Третье издание (Руководство PMBOK®) 6. Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 7. Дьяченко В. А. Организация промышленного инвестиционного проекта: краткое пособие для «промбоцманов» / В. А Дьяченко. – Уфа, 2000. 8. Новицкий Н.И., Пашуто В.П. Организация, планирование и управление производством: Учеб. -метод. пособие / Под ред. Н.И. Новицкого. – М.: Финансы и статистика, 2006. – 576 с 14 Лекция 7 . Управление рисками проектов Понятие «риск реализации проекта». Причины возникновения рисков . Классификация рисков проекта Количественный и качественный анализы рисков. Планирование управления рисками проекта. Мониторинг и контроль. Риск реализации проекта Управление рисками проекта включает в себя процессы, относящиеся к планированию управления рисками, их идентификации и анализу, реагированию на риски, мониторингу и управления рисками проекта ПОДСИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ УПРАВЛЕНИЕ содержанием и объемом работ продолжительностью стоимостью и качеством закупками и запасами ресурсами изменениями и рисками Интеграционное управление информацией и коммуникациями Большинство из этих процессов подлежат обновлению в ходе проекта. Цели управления рисками проекта – повышение вероятности возникновения и воздействия благоприятных событий и снижение вероятности возникновения и воздействия неблагоприятных для проекта событий. Управление рисками в проекте (project risk management) представляет собой функцию управления, обеспечивающую анализ, реагирование и контроль рисков в проекте. Реализация любого проекта сопряжена с различными видами рисков, обусловленных наличием неопределенности в хозяйственной деятельности предприятия. Основанием для возникновения рисков является неполнота знаний о событиях, которые должны произойти в будущем. Различие между риском и неопределенностью состоит в том, что, когда мы говорим о риске, то имеем в виду вероятность наступления рискового события, если же речь идет о неопределенности, то определить вероятность наступления связанного с ней события невозможно. Рассмотрим основные параметры, характеризующие риск проекта : рисковое событие (risk event), которое может нанести ущерб проекту; вероятность наступления такого события (risk probability, likelihood); размер потерь в результате наступления рискового события (amount at stake). 1 ПРИЧИНЫ ВОЗНИКНОВЕНИЯ РИСКОВ Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть "известные"- те, которые определены, оценены, для которых возможно планирование. Риски "неизвестные" - те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть. Для каждого события величину риска можно определить как функцию от вероятности и размера потерь от наступления события. Риск = f (вероятность, размер потерь) Увеличение вероятности наступления рискового события или размера потерь от его наступления влечет за собой увеличение риска. Каким же образом избежать рисков в проектах и насколько это необходимо? Ответ на эти вопросы зависит от степени толерантности к риску управляющего проектом. Выделяют три основных вида толерантности: избежание риска, нейтральное отношение к риску и ориентация на риск. Управление риском необходимо начинать на ранних стадиях реализации проекта, так как именно в этот период риск неудачи проекта особенно велик из-за отсутствия информации. На более поздних стадиях наибольшее значение имеют финансовые риски проекта . Рассмотрим основные компоненты функции управления риском: определение источников предполагаемых рисков; анализ и оценка рисков; реагирование на риск; оценка мероприятий по снижению риска. 2 Рисунок 1- Влияние рисков на протяжении жизненного цикла проекта Определение источников риска начинается с выявления факторов, которые могут оказать негативное воздействие на проект и препятствовать его реализации. Классификация рисков проекта Общие риски можно разделить на четыре основных группы: временные риски, связанные с тем, что проект не будет завершен в запланированные сроки и в наихудшем случае задержки в его реализации окажут негативное воздействие на участников проекта; финансовые риски, связанные с тем, что затраты превысят средства, которые планируется вложить в проект, или себестоимость проекта превысит цену продажи; риски, связанные с низким качеством работ, материалов и результатов проекта; целевые риски, связанные с тем, что задача, ради которой был инициирован проект, не будет выполнена или будет выполнена не полностью. В управлении риском принято выделять три категории рисков, характеризующие особенности реакции на него предприятия : риск, который можно исключить; риск, от которого можно застраховаться; риск, для компенсации которого необходимо принятие профилактических мер. Анализ и оценка рисков являются одними из самых важных этапов управления риском проекта, так как масштаб и качество оценки сильно влияют на последующие действия по снижению рисков. После выявления источников рисков необходимо провести их количественную оценку, определить вероятность наступления рискового события, чувствительность к нему проекта и др. Для агрегирования полученных данных целесообразно построить матрицу оценки параметров рисков (табл. 1). 3 Таблица 1 Анализ рисков проводят с помощью специальных методов с использованием различной информации: _ сравнение с аналогичными проектами и рисками; _ метод построения дерева решений; _ результаты тестов и опытного производства; _ экспертные оценки; _ имитационное моделирование; _ анализ чувствительности альтернативных решений; _ опыт реализации уже завершенных проектов; _ другие методы. Обычно анализ и оценка рисков состоят из двух базовых этапов: качественного и количественного анализов (рис. 2). Рисунок 2 - Алгоритм анализа и оценки рисков После оценки рисков управляющий проектом должен выбрать методы их минимизации: диверсификация (реализация различных видов проектов, инвестиционных портфелей); 4 распределение рисков (частичная передача рисков другим участникам проекта); избежание (разработка мероприятий внутреннего характера, полностью исключающих конкретный вид риска); страхование (передача отдельных рисков страховой компании); резервирование средств (создание специальных фондов покрытия на случай форсмажорных обстоятельств); прочие методы (получение гарантий, составление контрактов, снижающих риски предприятия и др.). После выполнения мероприятий по снижению рисков необходимо оценить их эффективность. КОЛИЧЕСТВЕННАЯ ОЦЕНКА РИСКОВ Для этого осуществляют количественный анализ рисков и сопоставляют затраты по их минимизации с размером потерь при наступлении рисковых событий. Затем управляющий проектом принимает решение о допустимости или недопустимости данного уровня риска. 5 ШЕСТЬ ПРОЦЕДУР УПРАВЛЕНИЯ РИСКАМИ • Планирование управления рисками - выбор подходов и планирование деятельности по управлению рисками проекта. • Идентификация рисков - определение рисков, способных повлиять на проект, и документирование их характеристик. • Качественная оценка рисков - качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта. • Количественная оценка - количественный анализ вероятности возникновения и влияния последствий рисков на проект. • Планирование реагирования на рискиопределение процедур и методов по ослаблению отрицательных последствий рисковых событий и использованию возможных преимуществ. • Мониторинг и контроль рисков - мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков. Процессы управления рисками проекта включают в себя следующее: Планирование управления рисками – выбор подхода, планирование и выполнение операций по управлению рисками проекта. Идентификация рисков – определение того, какие риски могут повлиять на проект, и документальное оформление их характеристик. Качественный анализ рисков – расположение рисков по степени их приоритета для дальнейшего анализа или обработки путем оценки и суммирования вероятности их возникновения и воздействия на проект. Количественный анализ рисков – количественный анализ потенциального влияния идентифицированных рисков на общие цели проекта. Планирование реагирования на риски – разработка возможных вариантов и действий способствующих повышению благоприятных возможностей и снижению угроз для достижения целей проекта. Мониторинг и управление рисками – отслеживание идентифицированных рисков, мониторинг остаточных рисков, идентификация новых рисков, исполнение планов реагирования на риски и оценка их эффективности на протяжении жизненного цикла проекта. Эти процессы взаимодействуют как друг с другом, так и с процессами из других областей знаний. В зависимости от потребностей проекта в каждом процессе могут принимать участие один или несколько человек или групп. Каждый процесс имеет место по крайней мере один раз в ходе каждого проекта, а если проект разделен на фазы – то в одной или нескольких фазах проекта. Хотя в данном руководстве процессы представлены как дискретные элементы с четко определенными интерфейсами, но на практике они могут накладываться друг на друга и взаимодействовать между собой; такие наложения и взаимодействия здесь не описаны. Риск проекта – это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие по меньшей мере на одну из целей проекта, например сроки, стоимость, содержание или качество (т. е. в зависимости от конкретного проекта: когда цель проекта определена как сдача результатов согласно определенному расписанию или как сдача результатов, не превышающих по стоимости оговоренный бюджет и т. д.). 6 Риск может быть вызван одной или несколькими причинами и в случае возникновения может оказывать влияние на один или несколько факторов. Например, причиной риска может быть необходимость получения разрешения от местного Комитета по охране окружающей среды или недостаток персонала, привлеченного для разработки проекта. Наступлением риска в этих случаях будет задержка с выдачей разрешения или нехватка персонала, привлеченного для разработки проекта. Возникновение любого из этих точно не известных заранее событий может повлиять на стоимость проекта, его расписание или выполнение. К условиям возникновения риска могут также относиться аспекты внешней среды организации или проекта, способствующие увеличению риска (например, неудачный выбор методов при управлении проектом, отсутствие общих систем управления, одновременное выполнение нескольких проектов или зависимость от внешних участников проекта, которых невозможно контролировать). Рисунок 3 - Общая схема управления рисками проекта согласно PMBOK 7 Планирование управления рисками Тщательное и подробное планирование повышает вероятность успешного достижения результатов пяти других процессов управления рисками. Планирование управления рисками – это процесс определения подходов и планирования операций по управлению рисками проекта. Планирование процессов управления рисками позволяет обеспечить соразмерность уровня, типа и прозрачности управления рисками как самому риску, так и значению проекта для организации, а также выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками и определить общее основание для оценки рисков. Процесс планирования управления рисками должен быть завершен на ранней стадии планирования проекта, поскольку он крайне важен для успешного выполнения других процессов. ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ 8 ПЛАНИРОВАНИЕ РЕАГИРОВАНИЯ Мониторинг и управление рисками Плановые операции по реагированию на риски, включенные в план управления проектом, выполняются в течение жизненного цикла проекта, однако, в отношение работ проекта должен проводиться постоянный мониторинг и контроль на предмет обнаружения новых и измененных рисков. Мониторинг и управление рисками – это процесс идентификации, анализа и планирования вновь возникших рисков, отслеживания идентифицированных рисков и тех, которые отнесены в список для постоянного наблюдения, а также проверки и исполнения операций реагирования на риски и оценки их эффективности. В процессе мониторинга и управления рисками используются различные методики, например, анализ трендов и отклонений, для выполнения которых необходимы данные об исполнении, собранные в процессе выполнения проекта. Мониторинг и управление рисками, также как и другие процессы управления рисками, являются непрерывным процессом, происходящим на протяжении всего жизненного цикла проекта. Другие цели процесса мониторинга и управления рисками подлежат определению, если: Допущения проекта по-прежнему действительны Анализ трендов показал, что с момента первоначальной оценки состояние риска изменилось Надлежащим образом выполняются правила и процедуры управления рисками Резервы стоимости и расписания должны обновляться одновременно с изменениями рисков проекта. 9 МОНИТОРИНГ И КОНТРОЛЬ Мониторинг и управление рисками может включать в себя выбор альтернативных стратегий, выполнение плана на случай возникновения непредвиденных обстоятельств и запасного плана, выполнение корректирующих действий и обновление плана управления проектом. Ответственный за реагирование на риск должен периодически отчитываться перед менеджером проекта об эффективности выполнения плана, о всех непредвиденных эффектах и корректировках, необходимых для надлежащего управления риском. Мониторинг и управление рисками также включает в себя обновление активов организационного процесса , включая базы данных накопленных знаний проекта и шаблоны управления рисками, которые понадобятся для будущих проектов. 10 Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 3. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 4. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 5. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 6. Руководство кСводу знаний по управлению проектами Третье издание (Руководство PMBOK®) 7.Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 8. Дьяченко В. А. Организация промышленного инвестиционного проекта: краткое пособие для «промбоцманов» / В. А Дьяченко. – Уфа, 2000. 9. Новицкий Н.И., Пашуто В.П. Организация, планирование и управление производством: Учеб. -метод. пособие / Под ред. Н.И. Новицкого. – М.: Финансы и статистика, 2006. – 576 с 11 Лекция 8. Информационные технологии в управлении проектами Автоматизация управления проектами. Распределение функций в Microsoft EPM Корпоративное управление проектами Корпоративные информационные системы (КИС) обеспечивают поддержку принятия управленческих решений на основе автоматизации процессов, процедур и других способов осуществления деятельности крупной компании, организации или корпорации. КИС помогают, могут заменить и взять на себя большинство рутинных процессов, но далеко не все процессы принятия решений. В свою очередь, менеджмент без информационных систем, построенных на современных информационных технологиях,становится все менее эффективным. В процессе реализации проекта В процессе реализации проекта менеджерам приходится оперировать значительными объемами данных, которые могут быть собраны и организованы с использованием компьютера. Кроме того, многие аналитические средства, например, пересчет графика работ с учетом фактических данных, ресурсный и стоимостной анализ подразумевают достаточно сложные для неавтоматизированного расчета алгоритмы. Поэтому возникает необходимость использования методов и средств автоматизации (информационных систем). Целью информационной системы поддержки принятия решений является информационное обеспечение принятия решений при разработке и реализации проектов на основе современных технологий обработки информации. Основными функциями этих систем являются: сбор, передача и хранение данных; содержательная обработка данных в процессе решения функциональных задач управления проектами; представление информации в форме, удобной для принятия решений; доведение принятых решений до исполнителей. В качестве основных потребителей информации проекта выступают: проектменеджер (для анализа расхождений фактических показателей выполнения работ от запланированных и принятия решений по проекту); заказчик (для осведомленности о ходе выполнения работ проекта); поставщики (при возникновении потребности в материалах, оборудования и т.п., необходимых для выполнения работ); проектировщики (когда необходимо внести изменения в проектную документацию). Эффективность реализации проектов в любой сфере деятельности зависит от качества управления. В настоящее время ситуация складывается таким образом, что проще и дешевле перестроить менеджмент для обеспечения лучшего соответствия применяемым технологиям, чем вносить изменения в программные системы поддержки менеджмента, в сами технологии. Компьютерная индустрия предлагает целый “букет” новых инструментов – корпоративные информационные системы для осуществления совместной проектной деятельности, составления расписаний работ, распределения ресурсов, контроля исполнения заданий и поручений и аналитической работы. Эти новые инструменты управления проектами в соответствии с жизненным циклом создания приложений (application lifecycle management - ALM), как правило, хорошо описаны. Например: • IBM Rational Unified Process (RUP) • Методология ARIS компании IDS Scheer AG • Microsoft Solutions Framework (MSF) Описание каждой из перечисленных выше методологий значительно превышает по сложности процедурный подход применения только лишь стандарта PMI.org для менеджмента проектов, поскольку они включают в себя не только процедуры управления проектами, но и инструменты по реализации самих проектов. По сути, эти системы являются технологиями решения задач проектирования. Интеграция дополнительных функций или сервисов информационных систем с базовым набором процедур 1 менеджмента предназначается, в первую очередь, для повышения эффективности использования проектного менеджмента в прикладной области применения, но ведет к их специализации и усложнению процесса освоения таких систем пользователями . В настоящее время компьютерная индустрия предлагает широкий выбор специализированных систем, предназначенных для решения задач в области проектного менеджмента . К продуктам достойным серьезного внимания следует отнести такие системы, как Microsoft EPM (Enterprise Project Management), Primavera, Artemis, Open Plan, CA (Clarity), PlanView, SAP(xRPM). Последний успех системы Primavera в значительной степени основан на производительности и предоставлении предприятиям и организациям спроектированной модели управления проектом для автоматизации процесса планирования, создания, контроля, учета и корректировки планов проекта. Программный продукт Open Plan компании Welcom имеет хорошие позиции в сегменте решений для строительных организаций. Система управления проектами Artemis предоставляет анализ портфелей проектов и может получать детализированную проектную информацию из других систем, управлять ресурсами и документами. Многие крупные предприятия и организации делали и продолжают делать попытки внедрения корпоративного управления портфелем проектов. Не все эти попытки заканчиваются успехом. Автоматизация управления проектами ] По неоднократным публикациям фирмы Gartner, Inc , одной из наиболее авторитетных и объективных среди компаний, проводящих маркетинговые исследования на рынках высоких технологий- система Microsoft EPM в настоящее время является лидирующим программным продуктом в сфере автоматизации процессов управления проектами (“Project and Portfolio Management Applications”). Корпоративная информационная система Microsoft EPM предоставляет организации – пользователю возможности по эффективному управлению портфелем проектов, ресурсами и проектами в рамках выбранной стратегии своего развития. Решение для корпоративного управления проектами необходимо предприятиям и организациям, в которых ведется множество проектов и требуется координация проектной деятельности, представление целостной картины управления портфелем проектов, централизованное управление ресурсами, а также обобщенная отчетность по проектам и ресурсам для топ-менеджмента. 2 Рисунок1 - Компонентная архитектура типовой EPM системы. Из компонентной архитектуры системы Microsoft EPM (рис.1) следует, что она представляет собой сложное интеграционное решение, в котором задействован десяток основных информационных продуктов компании Microsoft. Каждый компонент системы отвечает за выполнение своих функций и может применяться независимо от остальных: обслуживание электронной почты, поддержка функций Интернет, работа с базами данных, компьютерная безопасность и другие. Система Microsoft EPM предоставляет возможности планирования и контроля хода выполнения задач, совместной работы в проектной группе и доступа через Интернет к проектной информации за счет интеграции следующих продуктов и технологий: • MS Office System (MS Outlook) – настольная система, используемая для обеспечения решения стандартных офисных задач, включая почтовую службу. • MS Office Project Professional – специализированная персональная система для планирования и управления отдельными проектами (“клиент” для Microsoft EPM). • MS Project Web Site - технология, предоставляющая членам проектной группы доступ к версиям проектных документов и средства коммуникации между участниками. • MS Project Web Access – технология на основе MS Project Server, обеспечивающая поддержку функций управления корпоративными проектами и ресурсами, управления рисками в проектах и правами доступа пользователей, а также позволяющая готовить сводную отчетность по проектам (“сервер” для Microsoft EPM). Для реализации всех возможностей управления проектами и ресурсами требуется использовать MS SQL Server в качестве сервера базы данных и MS SharePoint Service для доступа к проектным документам и поддержки различных способов коммуникации. Распределение функций в Microsoft EPM Персональная система планирования предоставляет пользователю инструменты и возможности для выполнения следующих процедур: составление плана работ (задач) проекта и контроль хода их выполнения; формирование автоматизированных правил обновления проекта; проведение анализа бюджета проекта, в том числе - по методике освоенного объема; учет использования материальных и трудовых ресурсов. Доступ к информации имеет гибкие настройки представления данных, их группировки и сортировки, а так же графические индикаторы, сигнализирующие о проблемах и отклонениях от плана. Планирование возможно с учетом приоритетов задач в проекте и 3 проведением расчета критического пути при выполнении задач проекта для анализа. Система планирования MS Office Project Professional используется в качестве интерфейса при управлении ресурсами проектов, в том числе для работы с общим пулом корпоративных ресурсов. В настоящее время эта система, из-за своей распространенности, “де факто” является отраслевым стандартом в менеджменте проектов. Корпоративная система управления проектами (рис.3), построенная на основе MS Project Server, предоставляет интерфейс для совместной работы членов команды по отдельному плану проекта и, в том числе, обеспечивает управление Рисунок 2 - Распределение функций по основным интерфейсам в типовой EPM системе Под управлением портфеля проектов подразумевается выполнение следующих процедур: сводный анализ показателей по проектам для руководства компании; процедуры анализа уровня использования ресурсов в целом по компании; формирование аналитической отчетности по проектам, в том числе финансовой; агрегирование с помощью OLAP итогов для вариантов планов работ; управление рисками. К сильным сторонам системы Microsoft EPM можно отнести: • Доступность информации. Сведения о портфеле проектов по всей компании доступны через Internet для анализа и эффективного процесса принятия решений. Вместе с тем, обеспечены процедуры повышенной безопасности доступа к информации. • Управление производственным процессом (Task Tracking). Имеется встроенный механизм оповещений и напоминаний о наступлении запланированных событий (диспетчеризация расписания для выполнения задач плана проекта). • Обеспечение совместной работы. Доступ к общим файлам данных, предоставление членам проектных групп возможностей по созданию отчетов о ходе выполнения задач. 4 • Гибкость настроек системы. Обмен информацией с другими системами и масштабирование системы по мере роста объемов данных. Система представляет разнообразные возможности по интеграции, например, интеграция с Microsoft Business Scorecard Accelerator для анализа сбалансированных показателей деятельности компании. • Администрирование. Возможность для назначения прав доступа членов проектной группы к информационным объектам, процедурам, формам отчетности и другим настройкам в системе. Возможность выбора содержимого и внешнего интерфейса для пользователей Web-сайтов проектов. Корпоративная система предоставляет возможности по формированию табелей занятости и автоматизирует процесс утверждения табелей, профилей доступности и характеристик ресурсов проекта, поддерживает разнообразные варианты шаблонов настроек представления информации и шаблонов проектов, общий пул ролевых ресурсов и модуль управления рисками. Система масштабируется в зависимости от потребностей компании, и может быть установлена на несколько серверов для достижения необходимых показателей по производительности. К недостаткам системы Microsoft EPM можно отнести следующие: ограниченные возможности управления рисками; ограниченные возможности управления бюджетами; недостаточность возможностей планирования «сверху - вниз». Корпоративное управление проектами К основным декларируемым результатам внедрения системы Microsoft EPM относятся следующие: единая методология, общий портфель проектов; управление ресурсами; накопление и передача опыта. Под внедрением системы подразумевается не только инсталляция программного обеспечения, перестройка организационных структур компании, но и первоначальное конфигурирование справочников и внешнего интерфейса информационной системы. Эти независимые задачи требуют высокого профессионализма исполнителей, которых может и не быть в компании. Методология корпоративного проектного управления может быть определена в соответствии с рекомендациями стандарта ANSI/PMI 99-01-2004 PMBOK. Следует отметить, что не все так называемые области знаний стандарта должным образом покрываются функциональностью системы Microsoft EPM, в частности - процедуры инициации проектов, процедуры менеджмента персонала, качества и снабжения. Накопление и передача опыта или в соответствии с теорией принятия решений - передача знаний, может быть условно разделено на два типа : накопление фактов (декларативное знание) и умение решать задачи (процедурное знание). Если знания первого типа аккумулируются в системе, то знания второго – остаются вне её рамок. Модели жизненного цикла проектов Принято классифицировать модели Жизненного Цикла проекта в сфере высоких технологий на два типа: прогнозирующий и адаптивный . К прогнозирующему типу моделей относятся проекты с детальным планом достижения декларируемых целей и подцелей. К моделям осуществления плана работ с адаптивным Жизненным Циклом относятся проекты с заранее предусмотренными возможностями изменений в ходе процесса достижения целей проекта, проекты в которых заранее отвергается детальное планирование работ. Первые упоминания о моделях Жизненного Цикла прогнозирующего типа относятся к началу 70-х прошлого века . Теоретическое обоснование применения модели базировалось на экономических предпосылках о полноте достижения подцелей проекта и возможности их оптимального упорядочивания. Прогнозирующие модели жизненного цикла: 5 • Водопад, или "традиционная", или "сверху вниз" . Модель характеризуется линейным упорядочиванием фаз, которые могут быть строго последовательными или в некоторой степени перекрываться, ни одна из фаз обычно не повторяется. • Прототипирование (аналогично RAD). Быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом, построение и использование эволюционирующего прототипа создаваемого приложения.. Модель характеризуется тем, что разработка функциональных требований и проектирование архитектуры осуществляются одновременно. • Инкрементное проектирование. Модель характеризуется разбиением большого объема проектно-конструкторских работ на последовательность малых составляющих частей, где каждая часть имеет некоторую законченную форму. • Спираль . Модель характеризуется тем, что повторяется один и тот же набор фаз жизненного цикла, таких как планирование, проектирование, построение и оценивание, до тех пор, пока разработка продукта не будет завершена. Модели с адаптивными Жизненными Циклами: • Адаптивная разработка. Модель характеризуется тем, что реализация проекта определяется миссией, основанная на компонентах, подразумевает итеративные циклы и циклы с известной длительностью, определяемые степенью риска, допускает изменения. • Экстремальное программирование. Модель характеризуется тем, что реализация проекта разбивается на небольшие команды, включающие в себя менеджеров, пользователя и разработчика. Процесс разработки имеет итеративный характер, предусмотрено групповое владение правами интеллектуальной собственности. • SCRUM. Эта модель подобна модели адаптивной разработки. Реализация проекта выполняется на итеративной основе. Итерации носят название "спринтов", которые имеют длительность порядка 30 дней (типовое значение). Каждый "спринт" должен дать на выходе определенную степень функциональности продукта, предусматривается активная роль менеджмента компании-заказчика в течение всего жизненного цикла. Портфель проектов В практической работе адаптация модели Жизненного Цикла для разрабатываемых проектов отражает важные характеристики среды окружения проекта, в частности, выбор типа модели зависит от структуры компании и применяемых процедур принятия решений. Как следует из приведенного ранее определения «портфеля» проектов, необходимость в управлении портфелем возникает лишь при наличии многих проектов, возможно не связанных между собой. Вопросы управления портфелем проектов, как правило, входят в обязанности топ-менеджмента компании и обычно не являются их единственными функциональными обязанностями. По этим причинам в качестве модели управления портфелем проектов чаще всего выбирается модель Жизненного Цикла «водопад» или традиционная (рис. 4). К преимуществам использования этой модели в данном случае следует отнести простоту в интегральной оценке состояния проектной деятельности компании («покрытие» проектами ключевых областей основной деятельности, этапы и стадии проектов, ход распределения и освоения инвестиций). 6 Управление проектами в соответствии с моделью Жизненного Цикла Рисунок 3 Деятельность по управлению портфелем проектов процедурно связана с менеджментом отдельного проекта, но есть и существенные отличия. Если основной деятельностью при менеджменте проекта является управление реализацией проекта, то в работе по управлению портфелем проектов главное – это процедуры инициации новых проектов. Следует отметить, что система Microsoft EPM реализует лишь базовые средства для автоматизации управления портфелем проектов на этой стадии, ограничиваясь хранением фиксированного состава учетных данных по проекту. Работа с портфелем проектов в системе Microsoft EPM начинается после того, как планы проектов подготовлены и загружены в систему. Имеющиеся в системе процедуры анализа, фактически являются средствами агрегирования проектов для упрощения контроля сводных значений по стоимости и по использованию ресурсов. Для анализа портфеля проектов имеется широкий набор заранее подготовленных форм отчетов, а также OLAP средства оперативного анализа, так называемый гиперкуб. Достаточно ли имеющихся в системе Microsoft EPM средств и процедур для управления портфелем проектов – ответ положительный в том смысле, что этих процедур достаточно в той же степени, насколько достаточно возможностей, заложенных в системе MS Office Word для того, чтобы быть использованной при написании произведения типа «Война и мир». Естественно, без каких-либо рекомендаций автору о том, как этот проект реализовать на практике. Отметим, что для анализа портфеля проектов можно выбрать отчеты по одному из трех доступных представлений: по объему выполненных работ; по использованию трудовых ресурсов; по использованию финансовых ресурсов. А также, при формировании конкретного портфеля проектов, можно ввести числовой приоритет для каждого входящего в портфель проекта. Логическое и временное взаимодействие групп процессов управления портфелем проектов, в соответствии с моделью Жизненного Цикла (рис.4), в настоящее время в системе Microsoft EPM отсутствует. Деятельность по инициированию нового проекта в ряде компаний условно относится к проектной деятельности (т.н. организационный проект), в других компаниях эти задачи решают при помощи специальных корпоративных регламентов. Компаниям – пользователям системы Microsoft EPM в обеспечение этой цели рекомендовано самостоятельно разрабатывать или интегрироваться с имеющимися корпоративными системами делопроизводства, с одной стороны, и аналитическими системами оптимизации портфеля проектов, с другой стороны, предлагаемыми на рынке информационных систем независимыми производителями. 7 Технологические риски Обобщая итоги теоретических выводов и добавляя результаты практического опыта в области управления портфелем корпоративных проектов, наиболее существенные риски проектного менеджмента в условиях применения системы Microsoft EPM можно классифицировать так, как показано на рис4 Рис 4 Риски в типовой Microsoft EPM системе Программное обеспечение Primavera Project Planner Spider Project Основа ПО математические модели планирования и управления Open Plan Microsoft Project Программные средства для конечных пользователей 8 Программное обеспечение для персональных компьютеров MS Project позволяет осуществлять: планирование; временной анализ; ресурсный анализ; документирование; мониторинг. Интегрируется в MS Office      Open Plan имеет дополнительные возможности: для экономического анализа проекта; для оценки рисков. Допускает обмен данными:  с MS Project;  с системой Cobra для управления бюджетом.   Другие средства: www.cfin.ru/cdrom/index.shtml Программное обеспечение Project - инструмент планирования для поддержки следующих задач: • Создание плана реализации проекта и детализация необходимых задач. • Создание графика окончательных сроков, которые должны быть соблюдены. • Планирование реализации задач в подходящей последовательности. • Назначение ресурсов и стоимости задачам, планирование выполнения задачи с учетом наличия ресурсов. • Тонкая настройка плана для выполнения временных и бюджетных ограничений или адаптации к изменениям. • Создание связи между элементами проекта (задачи, ресурсы и назначения) и документами по управлению проектом в других приложениях. • Взаимодействие участников проекта в интерактивном режиме. • Создание профессиональных отчетов, разъясняющих задачи проекта участникам и заказчикам, например, владельцам, менеджерам высшего звена, рабочим, подрядчикам и общественности. • Просмотр портфеля всех проектов предприятия с целью анализа влияния нового проекта на использование ресурсов и поток средств. • Моделирование портфеля для оптимизации назначения ресурсов между всеми проектами предприятия. • Публикация проекта на сервере, чтобы другие менеджеры проектов и заинтересованные лица могли получить к ним доступ с помощью броузера. 9 Программное обеспечение Microsoft Project – инструмент для поддержки реализации проекта: • Контроль над ходом выполнения и анализ реального графика для соблюдения заданных пределов временных и бюджетных ограничений. • Уведомление ресурсов об изменениях в их назначении и получение отчетов о проделанной и еще незавершенной работе. • Пересмотр графика для его адаптации к изменениям и непредвиденным обстоятельствам. • Проверка различных версий предложенных изменений, с помощью анализа "что, если" до внесения изменений в план. • Обсуждение с остальными участниками внесенных изменений в график (например, с использованием автоматического оповещения). • Отправка автоматически обновляемых отчетов на сервер проекта, Web-сервер в Internet или во внутреннюю сеть компании. • Создание окончательных отчетов об успешном завершении проекта и оценка проблемных областей для рассмотрения их в следующих проектах. Программное обеспечение Компьютерное программное обеспечение заметно упрощает управление проектами, являясь инструментом записи, расчетов, анализа и подготовки презентаций, помогающих сообщать подробности проекта. Microsoft Project помогает создать идеальный план проекта и гарантировать его успешное выполнение настолько, насколько Microsoft Word может гарантировать создание успешной книги. ППО по управлению проектами: •помогает разработать «лучший» план; •упрощает расчеты и делает их более надежными; •упрощает использование различных сценариев "что, если" для поиска оптимального плана проекта; •помогает обнаружить несоответствия и проблемы в плане; •помогает донести план до сведения окружающих; •помогает следить за текущим состоянием и выявлять потенциальные сложности; •помогает уточнить план и предвидеть последствия, если после начала проекта изменяются внешние обстоятельства. 10 Программное обеспечение Программное обеспечение по управлению проектами, как и любое другое программное обеспечение, полезно настолько, насколько надежными и исчерпывающими являются предоставленные исходные данные. Поскольку предоставление таких данных требует большого количества времени, необходимо или отвести для этого определенное время, или нанять специалиста, который это сделает за Вас. Программное обеспечение Задачи (работы) и их параметры Задача (работа) часть деятельности по проекту, имеющая определенный значимый результат Название (уникальное) Веха (значимое событие, происходящее в определенное время) Задача (работа) длительности 0 Тип задачи: завершить Как Можно Раньше; завершить Как Можно Позже; начальная веха; конечная веха; с переменной длительностью; с фиксированным объемом; простая; составная (или подпроект). Параметры задачи Идентификатор (код) Период выполнения задачи: длительность; начало и конец. 11 Программное обеспечение Образец таблицы задач (работ) Программное обеспечение Связи между задачами Связь – независимый от времени порядок (частичный) выполнения пары задач. Параметры связи Предшественник и/или последователь Предшественник время Задача Последователь Тип связей: конец-начало; конец-конец; начало-начало; начало-конец. Сдвиг: вперед (+); назад (-). 12 Программное обеспечение Образец таблицы связей Программное обеспечение Образец представления расписания проекта в форме диаграммы Задача, перемещение которой не влияет на общую длительность проекта 13 Программное обеспечение Ресурсы/затраты задачи и их параметры Ресурсы - все необходимое для выполнения задачи /Затраты - средства для платежей, которые производятся при выполнении задачи Параметры ресурса/затраты Название (уникальное) Идентификатор (код) Единица измерения Стоимость единицы Класс: - людские; - неодушевленные; - финансовые. Тип: - возобновляемые; - расходуемые; - ограниченные. Доступность - периоды, в которые можно использовать ресурс. Программное обеспечение Образцы таблиц ресурсов/затрат: назначения ресурсов задачам распределения ресурсов по задачам 14 Программное обеспечение Образец ресурсной гистограммы: Интервал времени, где ресурс перегружен Разрешение ресурсного конфликта Программное обеспечение Календарь проекта и его настройки Календарь проекта – описание интервалов времени, в которые происходит (или не происходит) деятельность по проекту. Стандартная рабочая неделя: - рабочие дни; - выходные (нерабочие) дни; - график работы (стандартное время начала и окончания рабочего дня, начала и окончания обеденного перерыва). Праздничные нерабочие дни: - ежегодные; - не ежегодные (по годам). Особые дни: Настройки календаря - работа в выходные или нерабочие праздничные дни ; - рабочие дни с особым графиком. Начало отсчета времени: - первый месяц года; - первый рабочий день недели, … 15 Программное обеспечение Образец настроек календаря 2003 Сокращенный рабочий предпраздничный день … Подробности (дополнение) Что такое групповое планирование и управление проектами? Потребность сегодняшних проектов в отлаженной групповой работе и связи высока как никогда. Благодаря новому поколению инструментальных средств для управления проектами, основанных на web-технологиях, каждый член команды проекта может зайти на централизованный сервер компании для распространения или ввода плановой информация о проекте … MS Project Central Интернет изменяет наш стиль жизни, и нет ничего удивительного, что также меняется и стиль управления проектами - и в особенности проектами ИТ. Благодаря Интернет, менеджеры проектов могут создавать команды из специалистов, находящихся за тысячи километров друг от друга … WelcomHome WelcomHome - это средство совместной работы, основанное на Webтехнологиях и предназначенное для ведения проектов, c использованием единого web-интерфейса доступа ко всей проектной информации. WelcomHome обеспечивает членам команды централизованное место взаимодействия … 16 Подробности (дополнение) Введение в проектный менеджмент. Что же такое проект? Все мы постоянно осуществляем проекты в своей повседневной жизни. Вот простые примеры: подготовка к юбилею, ремонт в квартире, проведение исследований, написание книги … Процессы управления проектами Управление Проектами - интегрированный процесс. Действия (или их отсутствие) в одном направлении обычно влияют и на остальные направления. Такая взаимосвязь заставляет балансировать между задачами … Ключевые определения и концепции методов планирования, организации и контроля проектов. Pабота в плане проекта представляет некоторую деятельность, необходимую для достижения конкретных результатов (конечных продуктов нижнего уровня). Таким образом, работа является основным элементом (дискретной компонентой) деятельности … Microsoft Project Professional 2010 [RUS] 17 Microsoft Project Professional 2010 предоставляет мощные, удобные средства для успешного управления различными проектами и их выполнения. Более простой и интуитивно-понятный выпуск Project Professional 2010 предоставляет различные средства для упрощения планирования, совместной работы и управления ресурсами. Microsoft Project 2010 имеет превосходный новый интерфейс. Приложение содержит мощные новые средства планирования и управления задачами, а также усовершенствованные представления, что обеспечивает улучшенное управление проектами и их презентацию. Новое в версии: Улучшенный интерфейс Новые возможности просмотра Простая настройка представлений Управляемое пользователем планирование Упрощенная совместная работа Совместимость с предыдущими версиями Системные требования: Процессор: Pentium с частотой 1,0 ГГц или выше. ОЗУ: не менее 512 МБ. Разрешение экрана: не менее 1024 x 768 Совместим с операционными системами: Windows XP с пакетом обновления 3 (SP3) (только 32-разрядная версия) Windows Server 2003 R2 с пакетом обновления 2 (SP2) (32- и 64-разрядная версия) Windows Server 2008 с пакетом обновления 1 (SP1) (32- и 64-разрядная версия) Windows Vista с пакетом обновления 1 (SP1) (32- и 64-разрядная версия) Windows 7 (32- и 64-разрядная версия) Windows Server 2008 R2 (64-разрядная версия) 18 Лекция 9 Процессный подход: концепция внедрения в организации Определения понятий «процесс», «владелец процесса», «границы процесса». Основные задачи оперативного управления в процессном подходе. Контроль входов/выходов процессов Управление бизнес-процессами – важнейший элемент системы управления современной компании. Методики процессного управления активно развиваются. Появляются новые и совершенствуются существующие инструменты для описания и регламентации бизнес-процессов. Активно используются подходы и инструменты для управления процессами на основе показателей . Чтобы успешно внедрить процессный подход к управлению, руководители компании должны четко понимать, в чем заключается процессное управление, как будут выделяться и управляться процессы организации, почему такой подход эффективен. Концепция должна восприниматься не только интуитивно, но и формулироваться в конкретных терминах: • бизнес-процесс (процесс); • архитектура процессов; • владелец процесса; • описание процесса; • регламентация процесса; • стабильность процесса; • улучшение процесса; • автоматизация процесса и т. д. 1 Рисунок 1- Структурная схема процесса На рис. 1 представлена структурная схема процесса. Она является универсальной и может быть использована для анализа процесса любого уровня, вплоть до элементарных операций. Это базовая схема для понимания сущности процесса как некоторой части деятельности организации. Процесс включает в себя деятельность по преобразованию ресурсов и деятельность по управлению. Сформулируем определение. Процесс – это периодически повторяемая, управляемая деятельность, результатом которой является некоторый ресурс, имеющий ценность для конкретного потребителя (клиента). С точки зрения состояния ресурсы могут: • храниться; • перемещаться; 2 • находиться в состоянии обработки. Связь ресурса с процессом можно определить при помощи понятий «вход» и «выход». Если какой- либо ресурс нужен для выполнения процесса, то он может рассматриваться как вход с точки зрения данного процесса. А ресурс, преобразованный при выполнении этого процесса и получивший определенную ценность для потребителя, – в качестве выхода. Таким образом, ресурсы движутся, хранятся, перерабатываются. Их можно называть входами или выходами только по отношению к конкретному процессу. Выход одного процесса будет входом для другого. Говорить о входах и выходах безотносительно конкретного процесса не имеет смысла. На рис. 1. показано, что с точки зрения процесса ресурсы могут быть преобразуемыми, преобразованными, обеспечивающими и ресурсами по управлению. Преобразуемый ресурс поступает на вход процесса. При выполнении процесса ресурс приобретает дополнительную ценность, становится преобразованным и поступает на выход процесса – внутреннему или внешнему потребителю. В свою очередь, потребитель может рассматривать преобразованный ресурс в качестве входа для своего процесса, то есть в качестве преобразуемого ресурса, и т. д. Для выполнения процесса кроме преобразуемых ресурсов нужны также обеспечивающие ресурсы. К их числу можно отнести оборудование, программное обеспечение, инфраструктуру, сотрудников. Обеспечивающие ресурсы могут: • периодически, по мере необходимости поставляться в процесс другими процессами; • выделяться процессу на постоянной основе. Трансформируются ли обеспечивающие ресурсы при выполнении процесса? С точки зрения рассматриваемой модели – нет. В реальной жизни обеспечивающие ресурсы меняются: • сотрудники приобретают опыт работы, стареют и т. п.; • оборудование изнашивается; 3 • программное обеспечение морально устаревает. Однако при использовании данной модели указанными явлениями можно пренебречь. Напротив, если мы будем описывать и анализировать процессы управления персоналом или процессы технического обслуживания и ремонта оборудования, то изменение обеспечивающих ресурсов – важный фактор. Они являются для таких процессов основными объектами добавления ценности, поступают на выход в качестве преобразованных ресурсов. Ресурс по управлению представляет собой информацию, необходимую для управления. В зависимости от направления потока это может быть информация фактическая, плановая или содержащая управленческие решения Деятельность по управлению процессом, представленная на схеме, включает улучшение процесса и регулирование процесса (оперативное управление). Основная задача оперативного управления – поддержание процесса в стабильном воспроизводимом состоянии за счет выявления и устранения причин отклонений (вариаций). В свою очередь, улучшение процесса ориентировано на постоянное, целенаправленное изменение процесса на основе целей, установленных вышестоящим органом управления (на схеме это «Деятельность по управлению на более высоком уровне иерархии»). Для каждого процесса организации всегда существует иерархически вышестоящий орган управления. Чтобы управлять процессом, руководителю нужны полномочия по распоряжению ресурсами и информацией. На схеме показаны так называемые ресурсы по управлению. Они, как правило, представляют собой плановую и фактическую информацию. Например, от вышестоящего органа управления поступают цели и плановые показатели деятельности, при выполнении процесса возникает оперативная фактическая информация и т. д. Руководитель управляет процессом также через информационные воздействия (устные сообщения, информационные письма, распоряжения, приказы). Они являются выходами деятельности по управлению процессом. 4 Говоря об управлении процессом, определим понятие «владелец процесса». Подход, при котором для каждого выделенного процесса назначается владелец процесса, появился давно[1]. Сейчас существует множество различных взглядов на то, что собой представляет владелец процесса и чем он должен заниматься. Однако чем больше консультанты по управлению рассуждают об этом, тем меньше ясности для практиков – руководителей, которые должны внедрять институт владельцев процессов в компании. Владельцем процесса, как правило, назначается руководитель структурного подразделения (либо его заместитель, помощник). Существующая в компании иерархия управления структурными подразделениями не разрушается. Какая-либо иерархия владельцев процессов не создается. Количество ресурсов, переданных в управление владельцу процесса, и его ответственность за результаты процесса могут быть различными. Они меняются в зависимости от типа процесса, его важности для организации и т. д. В целом владелец процесса – это руководитель, способный как минимум: • проводить мониторинг хода процесса; • анализировать факторы, влияющие на процесс и приводящие к вариациям; • разрабатывать предложения по улучшению организовывать их обсуждения и согласования; • координировать (или совершенствования процессов управлять) процесса внутренние и проекты Границы процесса Понятие границ процесса является важнейшим при внедрении процессного подхода. Установление границ осуществляется субъективно – путем достижения договоренности между несколькими сторонами (поставщиками и потребителями). Для обсуждения границ процесса нужно сформулировать несколько определений. 5 Пусть ресурс «А» является результатом преобразования в некотором процессе (рис..2.). С точки зрения владельца этого процесса ресурс «А» – выход. С точки зрения владельца процесса-потребителя ресурс «А» – вход. В момент передачи ресурса «А» от одного процесса к другому происходит переход ответственности за этот ресурс между владельцами процессов. Факт движения ресурса, сопровождающийся переходом ответственности, может быть идентифицирован при помощи события. С точки зрения владельца первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2»[2]. В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ. Рисунок 2 – Границы процесса Приведем примеры формулировки событий, связанных с движением материальных ресурсов: • «Товар помещен в зону хранения»; • «Продукция упакована и передана покупателю»; 6 • «Оборудование установлено». Примеры формулировки событий, связанных с передачей информации: • «Поступил заказ клиента»; • «Факс отправлен»; Переход ответственности за ресурсы возможен и внутри процесса, по ходу выполнения работы различными сотрудниками. Соответствующие события могут использоваться для определения зон ответственности сотрудников внутри процесса. Спецификации на входы и выходы процесса Требования к ресурсам, пересекающим границы процессов, могут быть зафиксированы в различных документах, например в спецификациях на входы и выходы процесса. Эти спецификации могут быть выполнены в виде отдельных документов или входить в состав регламентирующих документов по процессам. Спецификации могут детально описывать требования, которым должны удовлетворять: • документация; • сырье, вспомогательные и упаковочные материалы; • полуфабрикаты; • готовые изделия; • производственные и офисные помещения, инфраструктура; • персонал; • оборудование; • программное обеспечение; • прочее. В спецификации необходимо фиксировать все предъявляемые к объекту конкретным процессом (табл. 1.). требования, 7 Содержание спецификаций зависит от типа входа или выхода процесса. Ниже приводится несколько примеров структуры спецификаций[1]. Таблица 1- Структура спецификации для готового продукта Контроль входов/выходов процесса Говоря о границах процессов, необходимо обсудить методы контроля входов и выходов. Существует два способа контроля: сплошной и выборочный . При сплошном контроле проверяется каждый ресурс (изделие, продукт, товар), поступающий на вход процесса. При выборочном – отбирают несколько изделий и осуществляют их контроль. Далее при помощи статистических методов оценивают долю несоответствующих изделий в их общем количестве. Ни та, ни другая форма контроля не дают полной гарантии, что в процесс не попадет несоответствующее (дефектное) изделие. Перспективным способом является так называемое встраивание контроля в процесс таким образом, чтобы несоответствия выявлялись сразу при возникновении. В этом случае 8 вероятность появления дефектных изделий на выходе процесса (то есть на входе соответствующего процесса-потребителя) существенно снижается. Одновременно с определением требований к входящим и выходящим ресурсам (например, в соответствующих спецификациях) желательно разработать методы контроля соответствия этим требованиям (спецификациям). Говоря о контроле выходов процесса, следует упомянуть о таких понятиях, как верификация и валидация. В стандартах ИСО 9000 на систему менеджмента качества приводятся следующие определения этих терминов : Верификация (verification) —подтверждение (посредством предоставления объективных свидетельств) того, что установленные требования были выполнены. Примечание 1. Термин “верифицировано” используется для обозначения соответствующего статуса. Примечание 2. Деятельность по подтверждению может включать такие виды деятельности, как: • осуществление альтернативных расчетов, • сравнение технических условий , относящихся к новому проекту, с аналогичной документацией по апробированному проекту, • проведение испытаний и демонстраций, • анализ документов до их выпуска. Валидация (validation) — подтверждение (посредством представления объективных свидетельств того, что требования, относящиеся к конкретному предполагаемому использованию или применению, были выполнены. Примечание 1. Термин “валидировано” используется для обозначения соответствующего статуса. Примечание 2. Условия применения для конкретного применения могут быть реальными или смоделированными». Можно предложить более четкие понятия: верификация – это проверка соответствия продукта установленным требованиям и фиксация результатов 9 этой проверки. Валидация – проверка способности продукта выполнять поставленные потребителем задачи (на практике выполнять свое функциональное назначение). В некоторых организациях принято валидировать процессы. Валидация процесса означает практическую проверку того, что процесс (при исполнении всех установленных требований к входам, технологии, оборудованию) выдает на выходе стабильный результат с приемлемым уровнем дефектов. Результаты валидации процесса обязательно фиксируются документально. Если организация не планирует проходить формальную сертификацию системы менеджмента качества на соответствие стандартам ИСО 9000, то термины «верификация» и «валидация» можно не использовать. Важно наличие четких операционных определений и действующих процедур контроля соответствия входов/выходов требованиям. Технология выполнения процесса Приведем «технология»: некоторые широко известные определения термину 1. е оло ия (от греч. téchne – ‘искусство, мастерство, умение’ и греч. logos – ‘изучение’) –совокупность методов и инструментов для достижения желаемого результата; метод преобразования данного в необходимое; способ производства. 2. е оло ия – в узком смысле – способ преобразования вещества, энергии, информации в процессе изготовления продукции, обработки и переработки материалов, сборки готовых изделий, контроля качества, управления. 3. е оло ия включает в себе методы, приемы, режим работы, последовательность операций и процедур, она тесно связана с применяемыми средствами, оборудованием, инструментами, используемыми материалами. 4. е оло ией, или технологическим процессом, часто называют также сами операции добычи, транспортировки и переработки, которые являются основой производственного процесса». Любой процесс организации базируется на технологии . 10 Окружение процесса Окружение процесса включает в себя два элемента – поставщиков и потребителей. В качестве потребителя (клиента) процесса можно рассматривать владельца процесса, сотрудника подразделения, подразделение, процесс. При внедрении процессного подхода желательно сразу договориться, кого считать потребителем и как это отражать в документах. Приведенные определения поясняет рис. 3. Если организация входит в группу компаний, то ее внешними потребителями могут выступать как другие организации группы, так и внешние организации. Рисунок 3 – Окружение процесса Поставщики, как и потребители процесса, могут быть внешними и внутренними. Приведем также определение исполнителя (участника) процесса. Литература: 1. 11 2.Репин В.В Бизнес-процессы: моделирование, внедрение , управление 12 Лекция 10 Принципы процессного подхода Определения принципов процессного подхода, общее описание проекта внедрения процессного подхода (часть1) Прежде чем приступить к внедрению процессного подхода, следует сформулировать его принципы При их определении можно пользоваться материалами книг, стандартами ИСО (международные стандарты качества), рекомендациями доктора Э. Деминга и другими источниками. В результате получится перечень принципов понятных собственникам и руководителям организации, которые нужно закрепить документально. Например, включить их в такие документы, как: «Методика управления процессами организации», «Руководство по процессам», «Концепция внедрения процессного подхода» и т. п. Руководители всех уровней компании должны понять и принять принципы процессного подхода, руководствоваться ими в своей каждодневной деятельности, довести до сотрудников (это наилучший способ распространения идеологии процессного подхода в организации). Ориентация на удовлетворение потребителей Каждый процесс в компании нужно сориентировать на удовлетворение нужд потребителей (внутренних и/или внешних). При внедрении процессного подхода для каждого процесса выявляются потребители, их требования к продуктам/услугам. Результаты выполнения процесса следует четко определить и зафиксировать документально на основе выявленных требований. Системный подход Деятельность компании должна рассматриваться руководителями как совокупность взаимосвязанных процессов, требующих управления ими как системой. Отсутствие системного ви́дения процессов приводит к принятию неэффективных управленческих решений, разрушающих организацию как систему, снижающих ее эффективность. Выделение и управление сквозными процессами Для обеспечения эффективного межфункционального взаимодействия выделяются и совершенствуются сквозные процессы. Проблемы взаимодействия подразделений устраняют, выделяя, анализируя, 1 оптимизируя и управляя сквозными процессами организации и стыкуя процессы подразделений по входам/выходам. Четкие границы Для каждого процесса необходимо определить границы (по входам/выходам и инициирующим/завершающим событиям). Входы/выходы и события должны быть согласованы для всех взаимодействующих процессов организации. Измеримость процессов Любой процесс в организации и его результаты должны быть измеримы. Для этого используется система показателей. Для каждого показателя разрабатывается методика расчета, определяются источники получения необходимых данных. Любой руководитель должен оценивать результативность и эффективность своих процессов, а также удовлетворенность потребителей. Принятие эффективных управленческих решений основывается на анализе достоверной фактической информации и прогнозировании хода и результатов процесса. Поддержание стабильности и воспроизводимости процессов Руководителям нужно поддерживать процессы в стабильном и воспроизводимом состоянии. Для этого идентифицируются вариации процесса, выявляются и устраняются их причины путем выполнения мероприятий (проектов) по совершенствованию процессов. Непрерывное совершенствование Каждый процесс в организации должен подвергаться непрерывному совершенствованию. Совершенствование процессов – неизменная цель всякого руководителя. Любой процесс может и должен быть улучшен. При улучшении процессов необходимо внедрять новые технологии и современные средства автоматизации процессов. 2 Общее описание проекта внедрения процессного подхода Состав этапов проекта должен быть понятен собственникам, руководителям, исполнителям и всем заинтересованным лицам Проект внедрения процессного подхода состоит из следующих этапов: 1. Принятие решений 2. Подготовка. 3. Разработка процессной архитектуры организации. 4. Разработка системы показателей для управления процессами. 5. Организация управления процессами. 6. Описание и регламентация процессов. 7. Запуск цикла PDCA. График Гантта проекта внедрения процессного подхода показан на рис.1 Рисунок 1 – Этапы проекта внедрения процессного подхода в организации На этапе принятия решений (этап 1) основная задача руководства – изучение и понимание концепции внедрения процессного подхода. Им необходимо формализовать свое ви́дение того, что означает внедрение процессного подхода применительно к их компании. Это видение должно 3 быть по возможности согласовано с ее собственниками. В итоге полезно разработать документ, который содержал бы: • основные определения процессного похода; • цели внедрения процессного подхода; • принципы процессного управления; • концепцию внедрения процессного подхода в организации; • стратегический план внедрения процессного подхода в организации. Называть этот документ можно по разному, например «Концепция внедрения процессного подхода в организации “Х”». Руководство компании должно также понимать, что изменение системы управления на принципах процессного подхода (как и любые другие серьезные организационные изменения) не бывает бесплатным. Нужно быть готовым вложить немалые средства в этот проект. Кроме людей и денег руководителям придется уделить достаточно времени на выполнение проекта, организацию управления процессами. Если они к этому не готовы, то внедрение процессного подхода лучше не затевать. На основе утвержденной «Концепции внедрения процессного подхода» на этапе подготовки(этап 2) и выполняются следующие работы: • создание подразделения организационного развития и обеспечение его необходимой инфраструктурой и оборудованием; • подбор людей, в первую очередь руководителя проекта; • разработка основных методических документов по проекту; • разработка плана выполнения проекта (или устава проекта); • обучение персонала на различных уровнях; • издание приказа о начале проекта. Подразделение организационного развития может состоять из нескольких человек, например начальника отдела и одного-двух аналитиков по процессам (специалистов). Начальник такого подразделения, как правило, и является руководителем проекта внедрения процессного похода. В крупной 4 компании курировать проект может кто-то из заместителей генерального директора, например директор по развитию. Отдел организационного развития включает начальника и четверых-пятерых сотрудников. В средней и небольшой организации он может состоять из двух-трех человек. Для работы подразделения организационного развития подготавливают соответствующую инфраструктуру (помещение и оборудование), закупают необходимое программное обеспечение. Важный аспект подготовки к внедрению – привлечение квалифицированного, опытного руководителя проекта (начальника отдела организационного развития) и специалистов по процессам. Эти люди будут разрабатывать основные методические документы, учить сотрудников, координировать работу по проекту, описывать и регламентировать ключевые процессы, определять показатели (метрики) для процессов, разрабатывать важнейшие нормативно-методические документы, вести документооборот и т. д. Важно понимать, что экономия при подборе сотрудников в отдел организационного развития недопустима. К сожалению, зачастую руководители не готовы платить высокие зарплаты людям, которые занимаются развитием, и подыскивают на рынке труда молодые, неопытные кадры[2]. Прием сотрудников в отдел лучше осуществлять поэтапно: начать с руководителя, а потом, по мере подготовки инфраструктуры и четкого обозначения ближайших задач по проекту, набирать специалистов. Подразделение организационного развития (или методическая группа) разрабатывает комплект методических документов по проекту, к числу которых относятся: • положение об отделе организационного развития (методической группе); • положение о рабочей группе; • методика управления процессами организации; • стандарт описания процессов (соглашение о моделировании); • формы планов и отчетов для оперативного управления процессами (то есть формы для использования показателей/метрик по процессам); 5 • формы нормативно-методических документов, которые будут использоваться для регламентации процессов; • процедура управления внутренними нормативно-методическими документами; • план (устав) проекта; • программы обучения руководителей и специалистов на различных уровнях. Работа по методическому обеспечению проекта может занять от двух до четырех месяцев в зависимости от количества документов, глубины и качества их проработки и скорости согласования руководителями компании. Подчеркну, что важна не длительность этого этапа как таковая, а комплекс тщательно продуманных, взаимоувязанных методических документов: • обеспечивающих возможность внедрения процессного подхода; • снижающих риск неудачного выполнения проекта. В качестве примера приведем структуру документа «Методика управления процессами организации». Документ довольно сложный, содержит множество приложений. Возможно создание нескольких методических документов. Например, в одном можно описать процедуры разработки и использования целей и показателей по процессам, привести формы планов и отчетов. В другом (процедура управления внутренними нормативно-методическими документами) – деятельность по управлению документацией, а в приложения включить формы регламентирующих документов по процессам. Важно, чтобы все необходимые при последующем внедрении процессного подхода аспекты были продуманы, а ключевые – описаны в методических документах. Конечно, вполне допустимо, чтобы необходимые документы создавались по ходу выполнения проекта. Обучение персонала – важнейшая задача подготовительного этапа. Полезно проводить обучение на трех уровнях: • собственники и руководители организации; • подразделение организационного развития или методическая группа; 6 • руководители среднего звена и специалисты. Подготовительный этап завершается утверждением всех разработанных документов, в первую очередь плана проекта внедрения процессного подхода. В рамках подготовительного этапа обычно проводится первичное обучение руководителей и специалистов. Процессная архитектура (этап 3), или, иными словами, система процессов организации, – основа системного внедрения процессного подхода. По ходу формализации система процессов может быть представлена в виде таблицы, которая включает следующие столбцы: 1. Порядковый номер в таблице. 2. Наименование процесса. 3. Руководитель, ответственный за выполнение процесса (владелец процесса). 4. Участники процесса (перечень подразделений или должностей). 5. Входы процесса. 6. Выходы процесса. Обычно процессы в такой таблице показывают на трех-четырех уровнях. На первом и втором описание входов и выходов делается укрупненным (либо вообще не делается). Подробное описание входов/выходов и событий целесообразно приводить начиная с процессов третьего уровня. Построить систему процессов означает взглянуть на деятельность организации по-новому – увидеть процессы, которые в ней выполняются. Для успешного решения этой задачи необходимо использовать определенную методику, которая подробно представлена в лекции 4. Разработка процессной архитектуры (системы процессов) позволяет: • определить границы процессов; устранить зоны безответственности и зоны пересечения ответственности (дублирования); • увидеть реальную картину документированности деятельности организации (какой процесс какими документами регламентирован); спланировать работу по регламентации процессов (определить недостающие 7 документы или документы, которые требуют пересмотра, расставить приоритеты, спланировать разработку и т. п.); • получить основу для разработки показателей (метрик) для управления процессами[1]; • сформировать базу для создания электронного репозитория процессов организации (с последующим описанием процессов при помощи специализированного средства моделирования); • получить основу для тиражирования процессов в регионах; • получить основу организациями отрасли; для бенчмаркинга процессов с другими • прочее. Этап завершается согласованием руководителями верхнего уровня системы процессов всеми Этап разработки системы показателей (этап 4) исключительно важен для внедрения процессного управления. Значимость разработки и практического использования показателей для управления процессами многократно превышает важность описания и регламентации процессов. Более того, если руководители не управляют своими процессами на основе системы показателей, то инструмент регламентации процессов в большинстве случаев будет использоваться формально, существующие регламенты – постоянно нарушаться и т. п. При разработке системы показателей для управления процессами учитываются следующие аспекты: • наличие у организации формализованной стратегии, в том числе стратегических целей и показателей их достижения; • необходимость увязки стратегических целей с показателями для управления процессами; • ориентация системы показателей на повышение операционной эффективности[1] процессов и удовлетворенности внутренних и внешних клиентов; 8 • необходимость агрегирования (декомпозиции, каскадирования) показателей при переходе от процесса одного уровня к другому. Показатели, разработанные на этом этапе, не окончательные. По мере их практического использования они могут пересматриваться, дополняться или, наоборот, устраняться. Этап разработки показателей заканчивается утверждением: • системы показателей для управления процессами организации; • форм планов и отчетов, которые руководители (владельцы процессов) будут использовать для оперативного управления процессами; • определением допустимых границ и целевых значений показателей 9 Лекция 11. Принципы процессного подхода Общее описание проекта внедрения процессного подхода (часть2) Напомним состав этапов проекта внедрения процессного подхода, который был рассмотрен в лекции №2 данного курса: 1. Принятие решений 2. Подготовка. 3. Разработка процессной архитектуры организации. 4. Разработка системы показателей для управления процессами. 5. Организация управления процессами. 6. Описание и регламентация процессов. 7. Запуск цикла PDCA. Итак, Этап организации управления процессами (этап 5) – ключевой с точки зрения внедрения процессного подхода по концепции «Совершенствование процессов». Организация процессов: управления процессами • планируют выполнение своих установленных показателей (метрик); означает, процессов с что владельцы использованием • оперативно проводят мониторинг хода и результатов выполнения процессов; • выявляют отклонения от нормального (стабильного) хода процесса (другими словами, идентифицируют вариации процесса); • анализируют причины отклонений (вариаций), разрабатывают и осуществляют мероприятия (проекты) по устранению причин отклонений (вариаций); • разрабатывают и реализуют проекты по совершенствованию процессов. На этапе организации управления процессами необходимо научить руководителей управлять процессами при помощи показателей, передать им 1 методы мониторинга процесса, поиска и анализа причин отклонений, планирования и выполнения проектов развития. По ходу этапа должны быть выполнены несколько циклов по управлению процессами (два-три месяца), в течение которых руководители осваивают соответствующие инструменты управления. По итогам этих циклов следует провести внутренний аудит, который должен показать, в какой степени руководители освоили эти методы, какие возникли проблемы, что нужно скорректировать в работе и т. д Описание и регламентация процессов (этап 6) – один из мощных инструментов процессного подхода. Однако рекомендуется описывать и регламентировать процессы постепенно, по мере возможности их оптимизации и практического внедрения регламентирующих документов. В большинстве компаний, которые сразу пытались описать большое количество процессов, полученные документы практически не удалось использовать. К сожалению, иногда целые отделы работают «в корзину», создавая описания и нормативно-методические документы, которые руководители просто не способны переварить (внимательно прочитать, оптимизировать, согласовать, внедрить на практике) за время, ограниченное рамками проекта. По сути, описание и регламентация процессов – это не разовый этап, не эпизод в жизни компании, а постоянно действующая система, позволяющая сотрудникам работать по стандартам и поддерживающая эти стандарты в актуальном состоянии. Поэтому этап описания и регламентации может считаться выполненным, когда: • внедрена процедура управления нормативно-методической документации; НМД организации поддерживается в актуальном состоянии; • создан, частично наполнен информацией (описание процессов) и используется электронный репозиторий процессов организации; • владельцы процессов освоили инструмент описания и регламентации процессов; • владельцы процессов осуществляют периодический исполнения требований НМДпо своим процессам; контроль • владельцы процессов используют НМД в качестве инструмента для совершенствования процессов и обучения персонала; 2 • начала формироваться культура работы по стандартам, изменилось отношение сотрудников к документации по процессам Запуск цикла PDCA (этап 7) Цикл Деминга (цикл PDCA) в книге Генри Нива «Пространство доктора Деминга» цикл характеризуется , как дающий нам ориентиры на пути к улучшениям. Он известен еще и как "Цикл Шухарта", "PDCA цикл" или "PDSA цикл". Деминг ссылается на него как на "Цикл Шухарта", поскольку его идея, по-видимому, имеет своим источником книгу Шухарта 1939 года. Японцы обычно ссылаются на него как на "Цикл Деминга" и именно так мы будем его здесь называть. Касательно мнемоники, PDCA (Plan-Do-Check-Act: Планируй-СделайПроверь-Действуй) - более распространенная версия, хотя Деминг предпочитает PDSA (Plan-Do-Study-Act: Планируй-Сделай-Изучи-Действуй). Книга Шухарта начинается с выделения трех стадий в управлении качеством: 1. Разработка Спецификации (техническое задание, технические условия, допуски) того, что требуется. 2. Производство Продукции, удовлетворяющей Спецификации. 3. Проверка (контроль) произведенной продукции для оценки ее соответствия Спецификации. Шухарт подчеркивает, насколько именно данная последовательность стадий необходима для использования в этом, реальном мире, где все процессы подвержены вариациям, в противоположность другому миру, который верует в точность науки. В том, другом мире, который к несчастью некоторые люди смешивают с реальным, упомянутые три шага могли бы быть независимы друг от друга. Как говорит Шухарт: "Кто-то мог бы определить, что он хочет, кто-то другой мог бы взять эту спецификацию как руководство и сделать эту вещь, а инспектор по качеству мог бы проверить продукт и определить, удовлетворяет ли он спецификации. Прелестно простая картина!" 3 Рисунок 1 Устаревший процесс управления качеством в виде линии Рисунок 2-Новый процесс управления качеством в виде круга Шухарт преобразовал линию на рис. 1 в круг, который он отождествил с "динамическим процессом приобретения знаний". После первого же круга многое можно узнать из результатов Контроля с тем, чтобы улучшить Спецификации того, что на самом деле необходимо. Производственный процесс корректируется соответствующим же образом и новый выход из него контролируется. Это проясняет все еще желательные улучшения, и цикл продолжается. Рисунок 3 -Процесс научно обоснованных усовершенствований (Профессор Джорж Бокс) 4 "Цикл Деминга" представлен в виде, который дает нам понять, что последовательность шагов может повторяться, конечно, в лучшей форме, используя знания, накопленные на предшествующей стадии. По мнению профессора Джорджа Бокса процесс научно-обоснованных улучшений (инноваций), который представлен на рис. 3, тесно связан с циклом Шухарта и этой версией Цикла Деминга. Рисунок 4.- Цикл Шухарта (нарисован на семинаре профессором Демингом) В настоящее время предпочитают использовать упрощенное представление Цикла, которое представлено на рисунке 4. Этот рисунок Деминг нарисовал во время семинара. Как это ему свойственно, он дает ей исчерпывающее описание буквально несколькими словами. Два момента достойных того, чтобы их выделить особо, таковы: 1.Деминг рекомендует, чтобы "Шаг 2" (обычно называемый "Делай", хотя и не на этом рисунке) проводился в малом масштабе - достаточно большом, чтобы получить полезную информацию, но не больше, чем необходимо на тот случай, если дела не пойдут удачно; и 2. За "Шагом 4" ("Действуй") может последовать еще один проход по кругу, с использованием полученных знаний, или в связи с намеренно измененными требованиями, чтобы узнать еще больше или, напротив, это может быть последним шагом решения - принять или отклонить План. 5 Рисунок 5- . Цикл Шухарта Характерная черта работ Деминга, - его способность сконцентрировать внимание на идее, которая, очевидно, вполне соответствует здравому смыслу, и которой мы все же не склонны последовать в реальной жизни. Кто может отрицать, что Цикл Деминга суммирует во вполне логично завершенной форме метод введения изменений и улучшений практически любого вида? Но используем ли мы его, когда приступаем к новому виду деятельности? Как много из того, что вы сделали сегодня, было сделано все тем же способом (который вы изучили может быть много лет назад), без единой мысли о возможных его улучшениях. Эксперт Британской Ассоциации качества Ян Грэхем, сравнивает, что должно было бы случиться с тем, что на самом деле случается (рис 6 и 7). 6 Рисунок 6 Цикл Деминга. (Предложение Яна Грэхема для сравнения с рисунком 7) Рисунок 7- Обычный подход к планированию (Ян Грэхем) Почему же мы реализуем ситуацию, представленную на рисунке 7, а совсем не ту, которая представлена на рисунке 6. Наше воспитание в духе принципа "Делай" тому виной . Делание - "продуктивно", в то время как Планирование, Проверка, Изучение, "непродуктивны". "Делая" что-либо, мы чувствуем продвижение куда-либо, в то время как при планировании, обдумывании, обсуждении, изучении - мы чувствуем, что как будто мы еще даже и не приступали к делу. Здесь проявляется сильное влияние нашего ориентированного на практические результаты общества - каждый может с легкостью предложить какие-то меры для того, чтобы оценить то, что было Сделано, но не так легко это проделать по отношению к тому, что было Спланировано. 7 К тому же, вследствие того, что мы привыкли к образу жизни, соответствующему рисунку 7, предложенных Яном Грэхемом, "тушение пожаров" является весьма уважаемым родом деятельности. И, в самом деле, это то занятие, на котором многие люди сделали себе карьеру. Мы забываем, что было бы гораздо лучше, если бы пожары просто не возникали. Идея о цикличности пути улучшений предстает в работах Деминга в различных обличиях. Наиболее очевидной иллюстрацией служит диаграмма "Старый путь производства "(рис 8), обратных связей в целях дальнейших улучшений не существует. Другой пример - диаграмма рис 9 "Новый путь производства", которая не просто подобна одному из ранее приведенных рисунков, взятому из книги Шухарта. Эта диаграмма полностью поддерживает идеи Шухарта-Деминга о необходимости постоянных непрерывных улучшений во всех сферах производственного процесса. Рисунок 8-. Старый путь производства Рисунок 9-. Новый путь производства Четырьмя шагами в этом цикле являются 1. 2. 3. 4. Разработай продукт; . Изготовь его, проверь на производственной линии и в лабораториях Поставь его на рынок; и Проверь его в работе, узнай, что о нем думает потребитель, пользователь и почему "не потребители" не нашли его. 8 И конечно, Шаг 4 ведет к новому Шагу 1: перепроектируй продукт и цикл начинается вновь. Другой пример такого "цикличного мышления" появляется, когда Деминг обсуждает свое утверждение: "Опыт не учит ничему, если он не изучается с помощью теории" "Опыт учит же (дает возможность планировать и предсказывать) только тогда, когда мы используем его для модифицирования и понимания теории". На этапе запуска цикла PDCA руководство компании должно добиться, чтобы: • собственники и руководители организации были вовлечены в этот цикл: – постоянно анализировали результативность и выполняемых проектов по совершенствованию процессов; эффективность – выделяли необходимые ресурсы для выполнения проектов по совершенствованию процессов; – анализировали достижение целей по совершенствованию процессов, периодически корректировали эти цели (с учетом корректировки стратегии, требований клиентов и т. д.); – поддерживали и развивали систему организационного развития (анализ эффективности, планирование развития, выделение ресурсов); – организовывали постоянное обучение персонала; – создавали механизмы, необходимые для вовлечения персонала в деятельность по улучшению процессов; • владельцы процессов: – анализировали свои процессы; – разрабатывали мероприятия (проекты) по улучшению процессов и внедряли их; – развивали свой персонал, вовлекали его в деятельность по совершенствованию процессов. Запуск цикла PDCA в организации можно считать успешным, когда выполнены как минимум все эти требования. 9 Лекция 12 Разработка системы процессов организации (часть1) Определение системы процессов организации Основные концепции и технологии моделирования бизнес-процессов. Описание процессов с помощью MS Excel Цели разработки системы процессов организации Определение системы процессов организации В лекции 12 рассмотрим методику описания системы процессов организации. Приведем определение системы процессов. Описание системы процессов организации означает создание модели, в которой в структурированном виде представлена информация обо всех процессах организации. Построение системы процессов не означает комплексного описания процедур (алгоритмов) выполнения всех процессов на всех уровнях управления, то есть создания так называемой комплексной модели процессов. Речь здесь идет только о дереве процессов. Для компании среднего размера можно разработать систему процессов за два-три месяца, в то время как описание всех процессов на операционном уровне займет несколько лет (в зависимости от количества выделенных ресурсов), что нецелесообразно. Описывать нужно только те процессы, которые предполагается оптимизировать и регламентировать.[1] Система процессов может быть описана в файле MS Excel или в виде специального справочника в инструментальном средстве моделирования процессов[2]. Как правило, система процессов организации представляет собой иерархический справочник процессов следующего вида: 1. Процессная категория (1-й уровень). 1.1. Процессная группа (2-й уровень). 1.1.1. Процесс (3-й уровень). 1.1.1.1. Операционный процесс (4-й уровень). 1.1.1.1.1. Операция (5-й уровень). 1.1.1.1.1.1. Транзакция (6-й уровень). 1 В табл. 1 представлены основные определения, которые можно использовать при формировании системы процессов организации. Таблица 1.- Определения уровней деятельности в системе процессов организации 2 Рис. 1.- Пример представления системы процессов организации в виде графической схемы 3 Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0[3]). Концепция IDEF0 Методология IDEF0 (Integrated Definition Function Modeling) основана на подходе, разработанном Россом (Douglas T.Ross) в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, - метод структурного анализа и проектирования) [ 3]. На рисунке 2 представлен пример IDEF0-модели. Рисунок 2 - Пример IDEF0-модели 4 Основу подхода и, как следствие, методологии IDEF0 составляет графический язык моделирования систем, обладающий следующими свойствами: 1. графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; 2. язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания. 3. язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (предприятия); 4. язык может генерироваться рядом CASE-средств, например, BPwin (компания Computer Associates, http://www.ca.com). Эти свойства предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в принятии методологии в 1993 г. федеральным стандартом Национальным институтом по стандартам и технологиям США (NIST) [ 4 ]. В 2000 г. методология IDEF0 была использована в нормативном документе Российской Федерации по функциональному моделированию в статусе «Рекомендации по стандартизации» [ 3 ]. Методология положениях: IDEF0 основана на следующих концептуальных Модель - искусственный объект, представляющий собой отображение системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих элементов, выполняющих некоторую полезную работу. Элементами системы могут быть любые комбинации разнообразных сущностей, включающих людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергоносители. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит. 5 Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF0 - представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Связи, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых систем. Итеративное моделирование. Разработка модели в IDEF0 представляет собой итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению и последующему редактированию, после чего цикл повторяется. Отделение «организации» от «функций». При разработке моделей следует избегать изначальной привязки функций исследуемой системы к существующей организационной структуре моделируемого объекта. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет: оценить адекватность модели, предложить решения, направленные на совершенствование этой структуры. Смыловые компоненты концепции IDEF0 IDEF0 - это методология функционального моделирования и поэтому имя блока описывающее функцию, должно быть глаголом или глагольным оборотом. Примеры имен функций: производить детали, наблюдать за выполнением. 6 Стрелки и их сегменты помечаются существительными или оборотами существительных. Примеры меток стрелок: менеджер, бюджет. Каждая сторона блока имеет своё определенное значение с точки зрения связи блок-стрелка. Верхняя сторона имеет значение «управление», левая - «вход», правая - «выход», а нижняя - «механизм». В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Пример блока представлен на рисунке 3. Рисунок 3 - Основные компоненты IDEF0 В IDEF0 различают пять классов стрелок - стрелка входа, стрелка выхода, стрелка управления, стрелка механизма, стрелка вызова. Стрелка входа - это материал или данные, которые преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелка входа рисуется как входящая в левую грань блока. Допускается, что функция может не иметь ни одной стрелки входа. Часто бывает сложно определить, являются ли данные входом, или управлением. В том случае, когда данные изменяются или перерабатываются, это вход, если нет управление. 7 Стрелка управления - это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелка управления рисуется как входящая в верхнюю грань блока. Каждая функция должна иметь хотя бы одну стрелку управления. Управление влияет на функцию, но не преобразуется функцией. Если цель функции - изменить процедуру, то такая процедура будет для функции входом. В случае возникновения неопределенности в классифицировании стрелки (вход или управление) рекомендуется создавать стрелку управления. Стрелка выхода - это данные или материальные объекты, произведенные функцией. Стрелка выхода рисуется как выходящая из правой грани блока. Каждая функция должна иметь хотя бы одну стрелку выхода. Функция без выхода не имеет смысла и не должна моделироваться. Стрелка механизма - это ресурсы (персонал, техника, оборудование), поддерживающие выполнение функции. Стрелка механизма рисуется как входящая в нижнюю грань блока. Стрелка механизма может не изображаться на модели. Стрелка вызова - это стрелка, указывающая на другую модель. Стрелка вызова рисуется как исходящая из нижней грани блока. Такая стрелка используется как указание на то, что некоторая функция выполняется за пределами моделируемой системы. IDEF0-модели состоят из трех типов документов: графических диаграмм, текста, глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма - главный компонент модели, содержащий блоки, стрелки, соединения блоков и стрелок. Диаграмма является единицей описания системы и располагается на отдельном листе. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть декомпозированы на составные части и представлены в виде более подробных диаграмм. Процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. 8 Модель может содержать следующие типы графических диаграмм: контекстная, декомпозиции, дерева узлов, иллюстрации. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма А-0 устанавливает область моделирования и ее границу. Необходимо установить, что входит в систему, а что лежит за ее пределами, то есть определить, что будет рассматриваться как компоненты системы, а что - как внешнее воздействие. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Цель - это краткая формулировка причины создания модели. Цель должна отвечать на вопросы: Почему этот процесс должен быть смоделирован? Что должна показать модель? Что может получить читатель? Точка зрения - это указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться. Это связано с тем, что в конечном итоге финансового директора не интересуют аспекты обработки сырья на производственном оборудовании, а главному технологу ни к чему прорисованные схемы финансовых потоков. Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Таким образом, дочерняя диаграмма как бы вложена в свой родительский блок. 9 Диаграмме может быть поставлен в соответствие текст, представляющий собой краткий комментарий к содержанию диаграммы. Текст не должен использоваться для описания и без того понятных блоков и стрелок на диаграмме. Глоссарий - это список определений для ключевых слов, фраз, аббревиатур, связанных с блоками, стрелками или с моделью в целом. Глоссарий определяет термины, которые должны одинаково понимать все участники разработки. Диаграммы иллюстрации используются в качестве дополнений, поясняющих специфику содержания основных диаграмм, для иллюстрации альтернативной точки зрения. Такие диаграммы могут не подчиняться правилам IDEF0. Диаграммы дерева узлов показывают иерархию функций в модели и позволяют рассмотреть всю её целиком. На диаграммах узлов нет стрелок. Диаграмм узлов может быть в модели сколько угодно, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. В современном менеджменте известны моделирования бизнес-процессов помимо IDEF0: несколько концепций 1. IDEF1 2. . методика моделирования IDEF1X 3.функциональное моделирование в методике IDEF3 Методология IDEF3 (Integrated Definition Process Description Capture Method) была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Эта методика, в отличии от IDEF0, не стандартизирована. С ее описанием и другими концепциями моделирования можно познакомиться на сайте http://www.idef.com ; 4. IDEF4 5. IDEF5 6. концепция DFD DFD (Data Flow Diagrams) - диаграммы потоков данных - это способ представления процессов обработки информации. Авторы методики Гейн и Сарсон разработали ее независимо от IDEF0. Эта методика, в отличии от IDEF0 не стандартизирована. 10 После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний –с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в лекции 6. Как правило, на уровне операционных процессов в системе процессов компании определяются и согласуются между собой входы/выходы процессов. Вопрос определения и согласования входов/выходов не такой простой, как кажется. Дело в том, что определение входов/выходов – весьма неоднозначная и ресурсоемкая задача. Если есть уверенность в том, что система процессов построена адекватно (а это зависит от методики и опыта бизнес-аналитиков), то входы/выходы могут быть корректно определены уже на следующем этапе – описания бизнес-процессов. Конечно, при этом в систему придется вносить некоторые изменения. Но система процессов – не застывшая, а живая, развивающаяся модель деятельности организации. Поэтому не стоит бояться вносить в нее изменения. Важно определить и регламентировать правила их внесения. Описание процессов с помощью MS Excel Для описания системы процессов организации можно использовать MS Excel. Форма представления системы процессов в MS Excel показана на рис.4. Каждая процессная категория находится на отдельном листе файла. Рис. 4. Представление системы процессов в виде таблицы MS Excel 11 Рис.унок 4.- Представление системы процессов в виде таблицы MS Excel При формировании дерева процессов и описании его в виде таблицы (рис. 4) возникает вопрос – как правильно показывать входы/выходы для процессов? Для нижнего уровня (четвертого и, возможно, третьего) ответ очень прост: следует описывать конкретные документы (бумажные, электронные) и материальные потоки. Но что делать при описании входов/выходов для процессов верхнего уровня (первый-второй, иногда третий)? Существует как минимум три основных варианта: 1. Агрегировать информационные и материальные потоки и показывать их в обобщенном виде, соответствующем уровню процессов. 2. Не показывать входы/выходы на тех уровнях процессов, где нужно делать агрегирование (то есть там, где невозможно или слишком сложно показывать потоки реальных документов/материалов). 3. Дублировать описание входов/выходов в виде списка, повторяя все входы/выходы, определенные для процессов нижних уровней. Первый вариант предполагает, что бизнес-аналитики, проектирующие систему процессов организации, достаточно квалифицированны, чтобы выполнять декомпозицию/агрегирование как процессов, так и потоков ресурсов (информационных и материальных). Если в этом есть сомнения, то лучше оставлять ячейки с описанием входов/выходов для процессов верхнего уровня пустыми (вариант 2), заполняя их только для детальных процессов конкретными наименованиями документов/материалов. 12 Третий вариант – наименее удобный, так как ведет к дублированию большого количества информации в таблице и усложнению ее восприятия. Заполнение таблицы процессов вида 2 в MS Excel сопряжено с существенными затратами рабочего времени. Ее лучше всего использовать на начальной стадии проекта внедрения процессного подхода, пока нет возможности применить более эффективные инструменты (например, среду моделирования процессов). Перенос системы процессов из таблицы в среду моделирования требует незначительных трудозатрат. На первых стадиях внедрения процессного управления использование таблицы в MS Excel – самый простой и удобный вариант. Для небольших компаний дерево процессов в MS Excel вполне может использоваться постоянно, без переноса в какую-либо другую систему. Цели разработки системы процессов организации Практика показывает, что задача создания адекватной системы процессов актуальна для организаций различного масштаба: от крупных холдингов до небольших частных компаний. Приведу несколько примеров. Построение системы процессов организации означает упорядочение ее деятельности в виде процессов. Древовидная структура процессов и согласованные границы позволяют четко определить зоны ответственности руководителей на всех уровнях управления, исключить зоны безответственности и зоны размытой ответственности (пересечения ответственности). Четкое определение зон ответственности руководителей позволяет организовать оперативное управление процессами, не дожидаясь их подробного описания и регламентации. Сказанное иллюстрирует рис. 5. В ситуации 1 процессы не выделены и не управляются. В ситуации 2 процессы выделены, границы процессов четко определены, руководители приступили к организации управления процессами на основе системы показателей. В ситуации 3 процессы регламентированы, оперативно управляются и совершенствуются на основе цикла PDCA. 13 Рисунок 5 - Упорядочение деятельности организации в виде процессов Управление процессами означает, что для каждого из них разработаны и используются показатели. Если не создать систему процессов, то не к чему будет привязывать эти показатели (не будет идентифицированных объектов управления)[3]. Если система процессов будет построена некорректно (например, состав и границы выделенных процессов окажутся неадекватны реальной деятельности[5]), то организация управления такими «процессами» – бессмысленное занятие. Поэтому корректно построенная система процессов – это основа для успешного внедрения процессного подхода. В целом система процессов организации обеспечивает достижение следующих целей: • упорядочение деятельности организации в виде процессов, анализ существующей организационной структуры и обоснование возможных и целесообразных направлений ее реорганизации; • организация управления процессами, в том числе создание основы для разработки системы показателей для управления процессами; • четкое определение зон ответственности руководителей, исключение зон безответственности, зон дублирования ответственности; • четкое определение границ процессов по входам/выходам и событиям; 14 • повышение эффективности межфункционального взаимодействия подразделений за счет определения, описания и оптимизации сквозных процессов; • создание основы для последующего системного описания и регламентации процессов; • создание основы для успешного внедрения различных средств автоматизации деятельности; • прочее. 15 Лекция 13 Разработка системы процессов организации (часть2) Структурный подход к построению системы процессов компании. Продуктовый подход к построению системы процессов Система процессов компании как «блюдо спагетти» Система процессов компании по методу CBM IBM Методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ) По мнению Репина В.В [1], методика построения системы процессов – базовая среди всех методик процессного управления. В российской практике известны следующие подходы: • структурный подход; • продуктовый подход; • подход «блюдо спагетти»; • CBM IBM (Component Business Model компании IBM); • методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ); Рассмотрим каждый из указанных подходов подробнее Структурный подход к построению системы процессов компании Структурный подход наиболее прост и понятен для руководителей и сотрудников компании. Процессы определяются в рамках границ существующих структурных подразделений. Они так же имеют иерархическое представление. Плюс подхода – его простота, минус – искаженный взгляд на процессную модель в целом. Дело в том, что организационная структура развивается исторически, причем с ориентацией на субъективный человеческий фактор (структура строится под людей). Поэтому определение системы процессов на основе организационной структуры – это риск получить дерево функций, определенных «под людей» вместо дерева реальных бизнес-процессов, которые должны выполняться. Также есть риск потерять важнейшие сквозные (межфункциональные) бизнес-процессы. Их фрагменты найдут отражение в справочнике процессов каждого подразделения, но в целом ви́дение сквозных процессов в системе будет отсутствовать. И уж совсем плохо, когда бизнес-процессы 1 приравнивают к подразделениям (отдел продаж = процесс продаж и т. п.), то есть когда система процессов компании копирует схему организационной структуры. Около 40–80 % операционных процессов (в зависимости от специфики конкретного подразделения и степени проектной ориентированности организации в целом) не являются сквозными. Иными словами, их нецелесообразно определять как сквозные, так как они полностью выполняются внутри соответствующих подразделений. Вышеизложенное иллюстрирует рис. 1. Рис..1. Процессы структурного подразделения На рис.1 процессы 1–4 условно можно назвать структурными или сегментированными. Они выполняются целиком в одном подразделении. Это видно по составу участников. Только процесс 5 –сквозной, поскольку в нем участвуют сотрудники нескольких структурных подразделений. Такие сквозные (кросс-функциональные) процессы интегрируют деятельность подразделения в деятельность организации в целом. 2 Если разделить процесс 5 на несколько частей, каждая из которых выполняется в отдельном подразделении, и показать на схеме процессов этого подразделения только ту часть, которую выполняют его сотрудники, то это и будет сегментированный подход. При структурном (сегментированном) подходе сквозные процессы не выделяются, то есть информация о них теряется. В этом состоит главный минус сегментированного подхода. Структурные подразделения взаимодействуют, получая ресурсы и передавая результаты выполнения внутренних операционных процессов друг другу. Анализ взаимодействия сотрудников, находящихся в различных подразделениях, помогает выявлять сквозные процессы. Несущественно, в какую именно часть системы будет включен сквозной операционный процесс. Важно корректно определить его границы и состав участников. Если разработанная компанией методика построения системы процессов (в данном случае это структурный подход) не позволяет идентифицировать сквозные процессы, то ее нельзя признать подходящей. Приведем пример фрагмента системы процессов для иллюстрации структурного подхода (табл..1). Таблица.1. Фрагмент системы процессов из категории «Управление технологией и качеством продукции» В таблице 1 приведен пример структуры процессов из группы «Контроль соблюдения технологии производства». Стоит обратить внимание на процессы «Участие в обработке претензий по готовой продукции» и 3 «Участие в обработке претензий по сырью». Что это за объекты? Насколько они ценны для компании? Увы, они не имеют самостоятельной ценности. Это всего лишь части сквозных процессов «Обработка претензий потребителей по готовой продукции» и «Претензионная работа по сырью и материалам» соответственно.[1] Может возникнуть вопрос: по каким принципам выделяются процессы внутри структурного подразделения? Как правило, принимают во внимание следующие моменты: • количество процессов составляет не более 10–12; • каждый процесс должен заканчиваться результатом, имеющим ценность для деятельности подразделения и/или компании; • процессы должны быть сопоставимы по масштабу; • технология создания продуктов/услуг. Продуктовый подход к построению системы процессов Продуктовый подход к построению системы процессов организации предполагает, что иерархический справочник процессов строится на основе определения перечня продуктов/услуг и последующей декомпозиции процессов по каждому продукту/услуге. При этом рассматриваются процессы, необходимые для создания соответствующих продуктов/услуг. Системы процессов, полностью основанные на продуктовом способе построения, на практике встречаются редко. Один из наиболее наглядных примеров – процессная модель деятельности банка. Представим её фрагмент: 1. Основные процессы. 1.1. Обслуживание физических лиц. 1.1.1. Расчетно-кассовое обслуживание физических лиц. 1.1.1.1. Текущие счета физических лиц. 1.1.1.1.1. Открытие текущего счета для физического лица. 1.1.1.1.2. Прием взносов на счет. 4 1.1.1.1.3. Проведение выплат со счета. 1.1.1.1.4. Взимание комиссии со счета. 1.1.1.1.5. Оформление доверенности на распоряжение счетом. 1.1.1.1.6. Оформление доверенности на распоряжение счетом. 1.1.1.2. Расчетное обслуживание. 1.1.1.3. Кассовое обслуживание. 1.1.1.4. Валютный контроль и валютные операции. 1.1.1.5. Денежные переводы по системам. 1.1.2. Вклады. 1.1.3. Кредитование физических лиц. 1.1.4. Банковские карты для физических лиц. 1.1.5. Индивидуальные банковские ячейки (сейфы) для физических лиц. 1.1.6. … 1.2. Обслуживание юридических лиц. 1.3. Работа на финансовых и межбанковских рынках. 2. Вспомогательные процессы… Плюс такого подхода – его кажущаяся простота: процессы выделяются на основе построения иерархического справочника продуктов и услуг, а на нижнем уровне – на основе анализа технологии создания элементарного продукта/услуги. Но если внимательно присмотреться к полученной структуре процессов, заметим ряд существенных минусов: • большое количество уровней иерархии справочника процессов (реальные операции процессов появляются только на шестом уровне иерархии!); • не выделяются сквозные процессы; 5 • в модели не прослеживаются цепочки создания ценности, на которых держится весь бизнес (вместоэтого представлена мозаика элементарных услуг); • возможное дублирование (например, процесс «Взимание комиссии» может быть типовым и запускаться с разными параметрами при оказании различных услуг; при рассматриваемом подходе он появляется несколько раз в разных частях системы); • при внедрении новых продуктов/услуг придется перекраивать всю систему процессов. Заметим, что если на каждую услугу (продукт) разрабатывать свой регламент, то база нормативных документов компании (банка) усложнится и станет неудобной для работы. В примере с банком есть еще один недостаток, не связанный с продуктовым подходом. Это применение в классификаторе понятия «основные процессы» (еще выделяют «вспомогательные» и «управленческие» процессы). По мнению ряда экспертов , категории «основной» или «вспомогательный» не должны использоваться при построении иерархического справочника процессов, так как это порождает процессные псевдоуровни, усложняющие структуру. При помощи понятий «основной» или «вспомогательный» можно характеризовать процессы, причем на любом уровне иерархии. Кроме них могут вводиться и другие характеристики процессов: степень автоматизации, эффективность, важность для достижения целей бизнеса и т. д. Но они не могут служить основой для построения системы процессов компании. Рассмотрим еще один фрагмент из рассматриваемой модели банка: 1. Управленческие процессы 1.1. Управление финансами. 1.2. Управление персоналом. 1.3. Управление маркетингом 1.3.1. … 1.3.2. … 1.3.3. … 6 1.3.4. Управление продуктами. 1.3.4.1. Разработка и внедрение продуктов и услуг. 1.3.4.1.1. … Обратите внимание, что процесс «Разработка и внедрение продуктов и услуг» попал на четвертый (!) уровень иерархии. Эта категория должна быть в системе процессов для современных компаний (независимо от профиля бизнеса). В качестве примера Репин В.В приводит систему процессов крупной компании, которая выделяла значительные ресурсы на развитие продуктового ряда. Как видим, процессная группа «разработка новых продуктов…» довольно масштабна с точки зрения количества и сложности входящих в нее процессов. Адекватная методика построения системы процессов компании не должна допускать ситуаций, когда важнейшие процессы оказываются на четвертом уровне процессной иерархии. Вывод: продуктовый принцип можно применять только на низком (третий или четвертый) уровне детализации процессов. Очевидно, что для построения системы процессов в целом данный подход неудобен. Система процессов компании как «блюдо спагетти» Ряд консультантов, занимающихся описанием и автоматизацией бизнес-процессов, обходит стороной вопрос построения комплексной системы процессов компании. При выполнении проекта по мере необходимости выделяются сквозные бизнес-процессы, причем количество уровней иерархии редко превышает два. Третий уровень если и определяют, то весьма формально. Полученный результат с системной точки зрения напоминает «блюдо спагетти» – запутанный клубок сквозных процессов, взаимодействующих между собой. Некоторые консультанты говорят о так называемой процессной организационной структуре, где подразделения формируются по принципу выполнения сквозного процесса от начала до конца. Однако на практике таких структур фактически не наблюдается. Некоторые эксперты отношусь к скептически относятся к возможности создания плоской процессной структуры компании. 7 Рассмотрим некоторые характерные признаки (не взаимоисключающие) «системы» процессов, построенной по принципу «блюдо спагетти»: • наличие нескольких файлов с фрагментарным описанием сквозных процессов разного масштаба и важности; • моделей процессов много, но единый иерархический справочник процессов отсутствует; • при декомпозиции процесса появляются операции, относящиеся к другим процессам (то есть процессы верхнего уровня имеют общие подпроцессы); • графические схемы процессов чрезмерно сложные (количество операций превышает двадцать – тридцать); • в моделях сквозных процессов пропущены нужные для выполнения процесса, но неавтоматизируемые операции; • операции разных процессов частично дублируют друг друга. Как правило, отсутствие иерархии процессов в рамках подхода «блюдо спагетти» оправдывается ненужностью определения процессов верхнего и среднего уровня для задач автоматизации. Во многом нежелание работать с системной процессной моделью бизнеса объясняется ориентацией на автоматизацию: • отдельных сквозных процессов операционного уровня (в BPMS); • отдельных операций, поддерживаемых ERP-системой (модели процессов состоят из системных операций, то есть операций, которые поддерживает соответствующая ERP-система. Строго говоря, такие модели не являются моделями бизнес-процессов). Конечно, важность описания, анализа (а при определенных условиях – автоматизации) сквозных процессов не подвергается сомнению, но наличие «блюда спагетти» вместо четкой системы процессов неприемлема для задач бизнеса с учетом стратегических перспектив его развития. Система процессов компании по методу CBM IBM Подход CBM (Component Business Model) компании IBM довольно интересен (табл. 2). Этот метод пока мало распространен в России, но 8 некоторые крупные компании уже используют его для построения процессной модели бизнеса. Таблица 2.- Построение системы процессов компании на основе метода CBM Для построения системы процессов компании в рамках модели CBM нужно: • определить ключевые компетенции компании (в области производства, продуктов/услуг, отношений с потребителями и т. д.); • для каждой компетенции и для каждого уровня управления определить так называемые компоненты; • выполнить процессную декомпозицию каждой компоненты на двачетыре уровня вниз. В результате разработки по методу CBM получается иерархический справочник процессов, основанный на компетенциях и уровнях управления. В модели CBM компоненты, по сути, это группы процессов. Привязка компонент к уровню управления весьма субъективна, как и сами уровни. На мой взгляд, уровни управления – узкое место CBM из-за отсутствия однозначных критериев отнесения к ним компонент. Основная идея подхода CBM – структурирование ключевых процессов компании. Метод CBM предлагает определять не все процессы, а только ключевые по компонентам, необходимым для поддержания и развития основных компетенций бизнеса. 9 Как правило, после построения таблицы вида .2 определяют текущий уровень эффективности выделенных компонент. Затем путем цветового кодирования отображают в таблице состояние системы. Часть процессов (компонент) выделяют желтым или оранжевым фоном (низкая эффективность), часть – голубым (высокая эффективность) и т. п. Цветовое кодирование удобно использовать для формирования презентаций, представляемых руководителям компании. По ходу выполнения проекта на схеме изменяют цвета для оптимизированных (автоматизированных) процессов. При построении модели по методу CBM не возникает уверенности, что она включает все процессы, действительно важные для поддержания эффективности и развития бизнеса. По мнению Репина В.В, лучше построить полную систему процессов, а потом определить приоритеты (характеристики процессов) по оптимизации – регламентации – автоматизации, чем иметь неполную картину бизнеса Построение системы процессов на основе анализа цепочек создания ценности Наша команда консультантов[3] в настоящее время использует метод анализа бизнеса компаний на основе цепочек создания ценности (ЦСЦ). Как само понятие ЦСЦ, так и выбор метода ее описания при помощи графических схем неоднозначны. По мнению Репина В.В, схемы ЦСЦ необходимо использовать в качестве эскизных моделей. Они позволяют понять, как работает бизнес с процессной точки зрения. Главная цель построения и анализа схем ЦСЦ при разработке системы процессов состоит в определении процессных категорий и групп. ЦСЦ строятся на основе процессного взгляда, поэтому полученная система процессов оказывается ориентированной на процессы, а не на организационную структуру. Пример схемы ЦСЦ показан на рис. 2 (обратим внимание, что на схеме есть только основные, системообразующие потоки информации и материальных ресурсов). При построении системы процессов с использованием схем ЦСЦ в рамках нашего подхода: • определяются и группируются основные продукты/услуги компании; 10 • для каждой группы продуктов/услуг разрабатывается схема ЦСЦ (обычно один-два листа формата А4); • выполняется анализ схем ЦСЦ, дополнение их процессными группами в части управления и т. д.; дополнительно разрабатываются схемы ЦСЦ для процессов управления компанией и вспомогательных (обеспечивающих) процессов; • выполняется анализ всех разработанных эскизных схем ЦСЦ; определяются процессные категории и группы для системы процессов компании; • выполняется анализ деятельности структурных подразделений компании; определяются и группируются процессы в рамках структурных подразделений; определяются сквозные процессы; • процессы (операционные процессы), определенные в подразделениях, распределяются по процессным группам и категориям с учетом разработанных ЦСЦ; • выполняется анализ полученного иерархического справочника процессов; • выполняется определение границ процессов на операционном уровне (по входам/выходам); • уточняется распределение процессов по процессным группам и категориям, состав и границы процессов; уточняются ответственные и состав участников процессов; • выполняется согласование системы процессов компании. На рисунке 2 показаны примеры схемы ЦСЦ для части бизнеса торговой компании – «Реализация товара в розницу». Схема выполнена в MS Visio с применением специальной нотации. Фактически на схеме представлены группы процессов и основные связи между ними. Рис..2. Пример схемы ЦСЦ Схема цепочки ценности «Реализация в розницу» 11 Рисунок 2.- Пример схемы ЦСЦ «Реализация в розницу» Рассмотренный подход дает возможность построить систему процессов компании, которая: • является полной (то есть охватывает весь бизнес компании); • на верхнем и среднем уровне ориентирована на процессы; • на среднем и нижнем уровне узнаваема руководителями и специалистами (то есть состав процессов на этих уровнях соответствует реальной деятельности; в системе практически нет надуманных процессов); • на операционном уровне модель содержит информацию о сквозных (кросс-функциональных) процессах. Недостаток подхода – некоторая субъективность перехода от процессного взгляда на уровне ЦСЦ к структурному взгляду на уровне операционных процессов (хотя любая модель организации в определенной степени субъективна). Заметим, что при разнесении процессов (операционных процессов) по группам важно определить сквозные процессы. 12 Корректность определения процессов на операционном уровне во многом зависит от опыта специалистов, выполняющих данную работу. Можно ли определить операционный (в том числе сквозной) процесс без его детального описания? Безусловно, да. Сложность и в какой-то степени искусство формирования системы процессов компании как раз и заключается в том, чтобы по возможности корректно определить структуру процессов без формирования детальных графических схем 13 Лекция 14 Моделирование бизнес-процессов организации (часть 1) Цели моделирования бизнес-процессов организации Формулировка целей моделирования процессов Нотация моделирования процессов Методики описания процессов Объектная модель организации Архитектура типовой среды моделирования процессов Цели моделирования бизнес-процессов организации В этой лекции часто употребляется термин «нотация». Дадим ему определение. Как правило, нотация – это система условных обозначений, принятая в какой-либо области знаний или деятельности, в частности при моделировании процессов. Сами по себе условные обозначения не дают возможности корректно построить схему бизнес-процесса. Поэтому нотацию рекомендуется рассматривать шире – как методику создания схем бизнеспроцессов с использованием принятой системы условных обозначений. Понятие «модель процесса», по мнению Репина В.В [1], имеет более широкий смысл, чем «схема процесса». Схема процесса – это графическое изображение процесса в определенном формате, а модель процесса – это его комплексное описание (в том числе и схема). Под термином «среда моделирования процессов» понимается специализированное программное обеспечение для описания процессов. В современной организации практически невозможно обойтись без описания процессов. По-разному, с неодинаковой степенью детализации, но это делают все. В одних компаниях деятельность по описанию выполняется бессистемно. Схемы создаются без использования утвержденных внутренних стандартов. Файлы со схемами хранятся у нескольких пользователей на разных компьютерах. В других компаниях установлены современные средства моделирования процессов, утверждены внутренние стандарты описания (моделирования). Информация о процессах хранится в промышленных базах данных. У всех этих компаний есть одно общее – их руководители и сотрудники ощутили необходимость и ценность описания и регламентации процессов [1]. Цели описания процессов зависят от размера организации и сути поставленных задач. Прежде чем сформулировать цели описания процессов, рассмотрим несколько практических ситуаций, представленных в табл..1. 1 Таблица масштабов 1- Способы моделирования процессов для фирм разных Как правило, с увеличением численности сотрудников в организации используются более четкие, формальные методики моделирования процессов и соответствующие инструменты – средства моделирования. Бывают и исключения, когда в компании из 100 человек методики описания процессов четко сформулированы и используются, а в крупной, солидной организации они находятся в зачаточном состоянии и бессистемно применяются отдельными специалистами (например, в департаменте управления рисками). Сформулируем цели описания процессов для организаций разного размера. Небольшая организация(10–100 человек) Возможные цели описания процессов (моделирования) в небольшой организации: 1. Четкое определение зон ответственности руководителей по ключевым направлениям деятельности. 2 2. Описание деятельности в формализованном виде для регламентации ключевых процессов организации: сбыт, закупки, бюджетирование, управление проектами и т. д. Использование описаний процессов при создании документов: инструкции по выполнению процессов, положения о взаимодействии. 3. Анализ и улучшение деятельности. 4. Подготовка к автоматизации деятельности, в том числе процессов. 5. Первые шаги по созданию культуры процессного управления у сотрудников (обучение процессному ви́дению). Средняя организация(100–1000 человек) Возможные цели описания процессов (моделирования) в организации среднего размера: 1. Четкое определение зон ответственности руководителей на всех уровнях управления. 2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам. 3. Системное описание процессов в формализованном виде. Централизованное хранение и актуализация моделей процессов. Постоянное использование моделей процессов для регламентации: регламенты выполнения процессов, инструкции по выполнению процессов, положения о взаимодействии и т. д. 4. Тиражирование стандартов деятельности (например, в филиалы). 5. Обучение сотрудников. 6. Автоматизация процессов. 7. Анализ и улучшение деятельности. 8. Развитие культуры процессного управления у сотрудников. Крупная организация(> 1000 человек) Возможные цели описания процессов (моделирования) в крупной организации: 3 1. Четкое определение зон ответственности руководителей на всех уровнях. 2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам. 3. Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации). Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов. 4. Автоматизация создания регламентирующих документов (при помощи выгрузки из среды моделирования на основе стандартных шаблонов). Формирование нормативно-методических документов: регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов: штатное расписание, карточки должности, карта грейдов[3], цели и показатели для управления процессами и т. д. 5. Описание и регламентация процессов управления на всех уровнях. 6. Анализ возможных изменений (реализация сценариев «что если?») в модели организации: 1) создание нового подразделения с передачей ему операций процессов других подразделений; 2) ликвидация подразделения с передачей его процессов другим подразделениям. 7. Тиражирование стандартов деятельности (например, в филиалы). 8. Выполнение внутреннего аудита. 9. Подбор персонала (на основе выполняемых сотрудником процессах). подробной информации о 10. Обучение сотрудников. 11. Автоматизация процессов. 12. Анализ и улучшение деятельности. 13. Управление знаниями о деятельности организации. 4 14. Вовлечение руководителей и сотрудников подразделений в работу по описанию и стандартизации деятельности организации. 15. Развитие культуры процессного управления у сотрудников. Формулировка целей моделирования процессов Прежде всего необходимо четко определить цели описания процессов. Нечеткость или неадекватность целей приведет к некорректному выбору средств их достижения. В результате деньги и время организации будут потрачены впустую. Цели моделирования процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть: • анализ и последующая оптимизация процессов; • разработка регламентирующих документов; • подготовка к автоматизации процессов; • прочее. В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества BPTrends и посетители соответствующего сайта (Северная Америка – 36 %, Европа – 32 % и т. д.). Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия «бизнес- процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессному управлению. В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 1.[1] По сути, на ней показаны цели моделирования (описания) бизнес-процессов. 5 Рисунок 1- Цели моделирования (описания) бизнес-процессов На первом месте (81 %) стоит пункт «Вместе с реинжинирингом и совершенствованием процессов».Это означает, что около 81 % компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов. На втором месте – пункт «Для передачи информации о процессе». Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п. Нотация моделирования процессов Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно будет использовать описания процессов для формирования регламентирующих документов. Департамент по работе с персоналом заинтересован в выгрузке из системы моделирования должностных инструкций. Важно понимать, что описание процесса в среде моделирования содержит гораздо больше информации, чем показано на его графической схеме (независимо от нотации). Но именно эта информация необходима при регламентации, формировании отчетов и т. д. 6 При выборе нотации полезно обратить внимание на следующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление – полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML[10]) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или IT-отдела, а преимущества процессного подхода не будут реализованы в полной мере. Если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN[12] 2.0. Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне: • в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ); • быстрота и низкая трудоемкость создания графических схем для целей регламентации; • схемы процессов просты и понятны всем сотрудникам даже без специального обучения; • простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны –обучение можно проводить силами сотрудников отдела организационного развития); • схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов организации. 7 Методики описания процессов Чтобы успешно выполнить проект по созданию системы работы по описанию процессов, нужны нормативно-методические документы (методики, стандарты), среди которых: • стандарт описания бизнес-процессов («Соглашение о моделировании бизнес-процессов»); • стандарт управления изменениями модели организации; • инструкция по администрированию среды моделирования; • прочее. К сожалению, вопрос методического обеспечения проекта не всегда учитывается руководителями, принимающими решения о приобретении и внедрении среды моделирования процессов. Наличие необходимых специалистов Важнейший фактор успешного внедрения – наличие в организации нескольких специалистов, которые могут: • разрабатывать и изменять систему процессов организации; • согласовывать процессы по входам/выходам; • проводить интервью, получать и структурировать информацию по процессам; • описывать процессы в нужных нотациях в среде моделирования; • настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов; • управлять изменениями объектной модели организации; • обучать сотрудников организации принципам и методам описания процессов; • прочее. Разработка и внедрение в организации системы описания процессов – довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы 8 Объектная модель организации В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации. Моделирование организации предполагает определение и подробное описание таких объектов, как: • процессы; • владельцы/исполнители бизнес-роли); процессов (подразделения, должности, • ресурсы: документы, файлы, ТМЦ; • инициирующие и завершающие события; • термины; • цели и показатели деятельности; • физические лица, занимающие соответствующие должности; • прочее. Каждый из этих объектов обладает рядом атрибутов. Например, для него могут быть определены название, тип, текстовое описание, требования к срокам. По ходу моделирования объекты контактируют между собой, и эти связи также могут иметь определенный тип и соответствующие атрибуты. В результате моделирования появляется объектная модель организации[10] – упорядоченная совокупность объектов, связанных между собой определенными способами. Четкая структура этой модели и наличие связей позволяют в дальнейшем получать любые регламентирующие документы (регламенты, инструкции, положения) и необходимые отчеты. Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнесмоделирования, можно называть метамоделью[12]организации. 9 На рис. 2 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации. Рисунок 2- Формирование объектной модели организации Метамодель организации, по сути, – это совокупность связанных таблиц СУБД (системы управления базы данных), и она может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты: • наименование должности; • номер грейда; • лицо, назначающее сотрудника на данную должность; • лицо, осуществляющее представление на данную должность; • показатели оценки эффективности; • прочее. Для успешного внедрения системы описания процессов нужны квалифицированные специалисты, способные грамотного осуществлять изменения (доработки) в метамодели организации. 10 Архитектура типовой среды моделирования процессов Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитектуры компании. Руководителям и специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса. Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 3 Такая среда, как правило, имеет модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей. Рисунок 3 - Архитектура типовой среды моделирования процессов 11 Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования: создания/изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д. Сервис управления метамоделью – важнейший инструмент бизнесмоделирования. Он позволяет расширять метамодель, предлагаемую поставщиком системы, и создавать новые списки, перечисления, атрибуты для существующих классов объектов. В некоторых системах предусмотрена возможность определять новые классы объектов и связей между ними. Фактически в такой системе доступно спроектировать любую нотацию, которая может потребоваться в организации. Возможность расширения метамодели важна для полного и адекватного моделирования, решения практических задач, возникающих у разных групп пользователей внутри организации. Основной сервис среды процессов[13], где можно: моделирования – сервис описания • создавать различные справочники: – процессов; – подразделений; – должностей; – документов; – терминов; – прочее; • формировать схемы: – процессов; – организационных структур; – прочее[13]; • описывать объекты модели: 12 – заполнять текстовые поля (например, указывать название процесса, его начало, завершение, требования к срокам); – формировать списки (например, указывать должностных лиц, которые согласуют требования к выполнению процесса); – выбирать нужные типы (например, указывать тип подразделения: «департамент» или «отдел»); – задавать количественные параметры (например, номер грейда, количество ставок на должности или среднее время выполнения процесса); – прочее; • формировать отчеты: – выгружать регламентирующие документы (регламенты процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции); – выгружать другие специализированные отчеты (например, отчет по движению документов – где создается, кем согласуется, кем утверждается и т. п.); • осуществлять анализ и изменение объектной модели: – создавать/корректировать/удалять документы; процессы, подразделения, – переназначать исполнителей процессов; – выявлять процессы без назначенных исполнителей; – выявлять документы, которые никто не использует; – прочее. Как правило, основные пользователи сервиса описания процессов – квалифицированные бизнес-аналитики, которые проводят интервью, структурируют информацию и заносят ее в систему в виде различных моделей. В некоторых случаях руководство организации принимает решение вовлекать в работу сотрудников подразделений, которые также используют часть функциональных возможностей в рамках своих полномочий. При выборе системы руководителям компаний стоит уделить серьезное внимание анализу функциональных возможностей и удобства использования 13 модуля описания процессов. Этот аспект важнее, чем выбор той или иной нотации моделирования. Рекомендуется попробовать все интересующие системы, описав в них один-два пилотных процесса. Для управления командной администрирования, в рамках которого: работой служит сервис • выполняются настройки интерфейса системы; • выполняются настройки ряда справочников; • создаются/редактируются группы пользователей системы; • определяются права для групп пользователей и отдельных пользователей; • выполняются настройки, необходимые для отслеживания изменений в системе; • прочее. Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов). При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы. При выборе системы руководитель должен выполнить анализ сервиса формирования отчетов. Лучше выбирать такую систему, генератор отчетов которой легко освоит не только программист (специалист по запросам к СУБД и написанию кода), но и обычный бизнес-аналитик. Очень полезен сервис выгрузки моделей в HTML-формат. Он используется для размещения моделей процессов на интранет– или интернетсервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся 14 регламентирующая информация рядовому персоналу. по процессам становится доступной Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д. Современная среда моделирования бизнес-процессов – это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом. Литература : 1.Репин В.В.,Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов.- М.: РИА «Стандарты икачество», 2004.408 с.. 2.Репин, В.В Бизнес-процессы: моделирование, внедрение , управление 3. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012. 4. Репин В. В. Бизнес-процессы компании: регламентация. М.: Стандартыи качество, 2007. построение, анализ, 5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007. 6. Бьёрн А. Бизнес-процессы. Инструменты совершенствования. – М.: Стандарты и качество, 2003. 7. Де Гиус А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.:Стокгольмская школа экономики в Санкт-Петербурге, 2004. 8. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. –М.: Стандарты и качество, 2004. 9.. Руководство пользователя Business Studio (2012). 10. Руководство технического специалиста Business Studio (2012). 11. Создание пользовательских отчетов Business Studio. Методика (2012). 15 12. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler. – М.: Диалог-МИФИ,2008. 13. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. – М.:Финансы и статистика, 2001. 14. Моделирование бизнеса. Методология ARIS. Практическое руководство / М. Каменнова [и др]. –М.: Серебряные нити, 2001. 15. Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling andimprovement using BPMN 2.0. – Cody-Cassidy, 2009. 16 Лекция 15. Моделирование бизнес-процессов организации (часть 2) Структурные модели процессов организации Модели процессов на операционном уровне Наиболее известные нотации моделирования: нотации типа Work Flow, нотация ARIS eEPC ,нотация BPMN Структурные модели процессов организации В этой лекции мы рассмотрим особенности использования структурных моделей при моделировании процессов организации. Под структурной будем понимать модель, включающую в себя упорядоченный по определенному принципу набор процессов (групп процессов) с указанием основных связей между ними. Основное назначение структурной модели – показать, как устроен бизнес организации, раскрыть информацию об основных группах процессов и их взаимосвязях. Структурная модель не показывает последовательность выполнения процессов во времени. Структурные модели можно использовать локально (не в системе процессов организации) для схематичного описания состава процессов, декомпозированных на следующий уровень. Например, такая структурная схема может быть представлена в регламенте двухуровневого процесса. Для формирования структурных моделей используются соответствующие нотации: IDEF0, ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Структурные модели процессов, как правило, применяются для: • описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации; • разработки системы бизнес-процессов организации по принципу «сверху вниз»; • системного описания процессов, автоматизировать (например, в ERP-системе); которые необходимо • описания состава процессов, декомпозированных на следующий уровень (несистемное,фрагментарное использование). 1 Рассмотрим деятельность торговой компании (розничная торговля продуктами питания). На рис. 1 показан пример структурной модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией. Рисунок 1 –Структурная модель процессов организации На рис. 1 видно, что в модели выделено семь групп процессов. Цель ее построения – демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации. На рис. 2 та же модель, что и на рис..1, только выполненная в стандарте IDEF0. Анализируя рис..2, отметим, что многочисленные стрелки, которые обычно представлены на схемах IDEF0, не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продаж и закупок и т. п.). Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно 2 стремиться минимизировать информативность схемы. количество Рисунок 2.- Пример структурной компании[14]. Стандарт IDEF0 стрелок,сохраняя модели процессов при этом торговой Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко. Вопрос пользы структурных моделей для решения задач бизнесмоделирования спорный. Построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формальные правила, то в такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.). Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов[15]. Если можно обойтись без 3 сложной (понятной только бизнес-аналитику) процессов, то и не нужно ее создавать. структурной модели Итак, структурная модель процессов нужна: • бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow – регламентируемым или автоматически исполняемым в BPMS процессам); • руководителям организации для: – уточнения зон ответственности, целей и задач их деятельности; – анализа и совершенствования архитектуры бизнеса; • руководителям и бизнес-аналитикам при проектировании нового бизнеса. Среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель (например, в IDEF0) – удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативнометодической документацией. Модели процессов на операционном уровне В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow»[14]. Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения. Нотации типа Work Flow На рис. 3 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных: 1. События. 4 2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи [13]). 3. Операции процесса. 4. Стрелки типа «Связь предшествования». 5. Стрелки типа «Поток объектов». События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие по ходу выполнения процесса. Примеры именования событий: «Поступила заявка клиента на отгрузку продукции», «Утвержден план проекта»,«Подписана накладная», «8.00 понедельника» и т. п. Как видно на рис. 3, в различных нотациях события показаны при помощи разных условных обозначений. Рисунок 3 - Основные элементы нотации Work Flow Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам (например, принятие решения, проверка условия). Операторы логики бывают трех типов[15]: логическое «И», логическое исключающее «ИЛИ», логическое неисключающее «ИЛИ». 5 На рис. 4 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные). Рисунок 4.-- Использование операторов логики При использовании логического оператора «И» (ситуация 1) после операции 1 выполняются операция 2 и операция 3. При использовании логического оператора исключающее «ИЛИ» (ситуация 2) после операции 1 выполняется одна из двух операций – 2 или 3 При использовании логического оператора неисключающее «ИЛИ» (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и 3. Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа Work Flow. 6 Важный элемент схемы Work Flow – связи. Они представлены при помощи стрелок определенного вида. Первый тип – стрелки «Связь предшествования». Без них построение модели типа Work Flow невозможно. Стрелка «Связь предшествования», связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки «Связь предшествования» демонстрируют развертку процесса во времени. Стрелки «Поток объектов» используются на схемах типа Work Flow для описания потоков документов и информации[16]. За счет использования событий, операторов логики и стрелок «Связь предшествования» на схеме Work Flow можно показать сложную логику выполнения процесса во времени. Рассмотрим наиболее известные нотации моделирования Простая блок-схема Нотация «Простая блок-схема» реализована в MS Visio. На рис. 5 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко. Рис. 5-. Нотация «Простая блок-схема» в MS Visio 7 Вообще в MS Visio представлено несколько сложных нотаций типа «Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой. Нотация «Простая блок-схема» в самом доступном используемом варианте содержит всего несколько элементов: и часто • процесс; • решение; • ручная операция (реже); • документ; • данные; • стрелка (для отображения связей между объектами схемы). При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации. Рассмотрим некоторые особенности применения простой блок-схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов: • не именуют стрелки вообще; • стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия. На рисунке 6 показан пример применения простой блок-схемы в одной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю –сотруднику компании. 8 Рис. 6.- Пример схемы в нотации «Простая блок-схема» Нотация «Простая блок-схема» часто подвергается в организациях различным вариациям: • изменяется смысл элемента «Решение» (его используют в качестве операции процесса); 9 • по-разному используют стрелки связей (именуют или не именуют и т. п.); • по-разному используют стрелки связей в сочетании с объектом «Документ»; • прочее. Интересно, что нотация «Простая блок-схема» в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из известных. Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов): • простота формирования графических схем процессов; • интуитивная понятность схем сотрудникам (даже без специального обучения); • минимальная потребность в обучении сотрудников; • наличие доступных инструментов для описания процессов (MS Visio, MS Word). Однако, как это часто бывает на практике, если нотация используется без утвержденного внутреннего стандарта и специализированного средства моделирования, компания получает множество нестандартно оформленных схем, которые содержатся в различных файлах. Поддерживать такой массив информации в связном состоянии и отслеживать изменения сложно. Требуется большой объем ручного труда бизнес- аналитиков. Поэтому, выбирая нотацию «Простая блок-схема», необходимо заранее разработать: • внутренний стандарт использования этой нотации; • внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов. Масштабное использование в компании нотации «Простая блок-схема» без современного средстват моделирования неэффективно. 10 Нотация ARIS eEPC Нотация eEPC является частью общей методологии ARIS, в рамках которой организация рассматривается с четырех позиций: организационной, функциональной, структуры данных и бизнес-процессов. При этом каждая из позиций разделяется на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS eEPC – одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации – наличие элементов типа «Событие» и операторов логики «И», неисключающее «ИЛИ», исключающее «ИЛИ». В качестве примера рассмотрим процесс, представленный на рис. 7, который начинается с события «Поступил заказ клиента». Оно инициирует операцию «Выполнить учет заказа в системе», которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту осуществляет операцию «Выполнить анализ на соответствие номенклатуре». Ее результат – два альтернативных события: «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ». Рисунок 7.- Схема процесса в нотации ARIS eEPC 11 Операция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ». Нотация ARIS eEPC содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию), которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. Следует отметить, что типичная схема в ARIS eEPC: • не годится для автоматизации в системе класса BPM (Business Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой); • сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат). Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование в ARIS eEPC не дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация. Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют ARIS eEPC для описания и регламентации бизнес-процессов. В этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной (с точки зрения задач бизнес- моделирования) нотации BPMN 2.0. 12 Нотация BPMN Разработана она компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 году. Предыдущая версия BPMN – 1.2, последняя версия – 2.0. Нотация BPMN появилась относительно недавно. Она ориентирована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации операционных процессов – BPM. Рассмотрим пример. В торговой компании есть отдел продаж, деятельность которого заключается в получении и обработке заявок клиентов, выставлении счетов и т. п. Структура процессов отдела следующая: • получение заявок клиентов; • обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела); • формирование графика доставки; • обработка ждущих (отложенных) заявок; • контроль остатков, рассылка информационных писем клиентам; • изменение статуса товара в базе; • обработка отказов. На рис. 8 показан процесс «Обработка заявки и выставление счета клиенту», описанный в нотации BPMN. Схема рис. 8 содержит три объекта типа Gateway, восемь – типа Event и четыре операции (действия, задачи). Как видим, процесс совсем несложный, но количество условных обозначений, нужных для его описания, значительно. 13 Рисунок 8- Фрагмент модели процесса в нотации BPMN 2.0 К нотации BPMN специалисты относятся по-разному. Для профессионалов, описывающих процессы с целью автоматизации, она весьма удобна. Более того, сейчас BPMN, очевидно, нет альтернативы. Но для руководителей и сотрудников организации, не обладающих компетенциями в области бизнес-моделирования, эта нотация слишком сложна. Применение BPMN в масштабах компании требует значительных затрат на обучение сотрудников, создание у них навыков моделирования. Это сложнее, чем при использовании более простой и понятной нотации. Поэтому выбирать BPMN можно в случае, если: • руководители готовы тратить деньги на обучение и развитие культуры бизнес-моделирования в организации; • руководители сами готовы активно осваивать нотацию BPMN; • предполагается активно использовать схемы процессов в BPMN для автоматизации операционных процессов. К сожалению, сейчас на русском языке нет книг по использованию нотации BPMN. Есть только статьи, презентации, материалы вебинаров. 14 Нотация «Процедура» среды моделирования Business Studio Сейчас одним из распространенных инструментов бизнес-моделирования стала среда BusinessStudio[16]. В этой системе реализованы четыре нотации: IDEF0, «Процесс», «Процедура», eEPC. Нотация IDEF0 используется для построения моделей верхнего уровня, а «Процедура» и eEPC – для создания моделей типа Work Flow. Рассмотрим подробнее нотацию «Процедура» (см. рис. 9), так как она наиболее проста и удобна для описания бизнес-процессов организации. Основные элементы нотации – это: • операция («Действие» в терминологии Business Studio); • событие; • блок «Решение»; • стрелка типа «Связь предшествования»; • стрелка типа «Поток объектов»; • междиаграммная ссылка (МДС); • сноска (текстовый комментарий); • дорожки. 15 Рис. 9-Схема процесса в нотации «Процедура» среды моделирования Business Studio Схема процесса располагается на листе формата А4. Какие-либо изменения размера листа, как правило, не допускаются. Это ограничение дает возможность документировать схемы процессов в привычном формате (включать в регламентирующие документы компании). Рекомендуемое количество операций на одном листе – от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо попытаться разбить процесс на несколько подпроцессов. 16 В рамке автоматически указывается название процесса. Использовать номер процесса в рамке нежелательно. Дело в том, что в справочнике процессов удобно применять автоматическую нумерацию. Если в него вносятся новые процессы, то нумерация меняется. При этом в графических схемах, которые уже включены в регламентирующие документы компании, остается старый номер процесса. Это неудобно. Именно поэтому не рекомендуется указывать номер процесса на его графической схеме. Надписи на стрелках могут располагаться как горизонтально, так и вертикально для обеспечения визуальной наглядности. Операции процесса должны быть связаны между собой стрелками типа «Связь предшествования». Если после выполнения операции необходимо поставить блок «Решение», то связи операций с этим блоком также отображаются при помощи стрелок «Связь предшествования». Если между двумя операциями на схеме представлен блок «Решение», то для моделирования передачи информации/документов из одной операции в другую используют стрелки типа «Поток объектов». В случае перехода на один уровень вверх относительно схемы подпроцесса, разработанной в нотации «Процедура», дорожки на схеме устанавливаются по должности или роли владельца подпроцесса. 17 Лекция 16 Моделирование бизнес-процессов организации (часть 3) Информативность графических схем процессов Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение») Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение») Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Схема процесса в нотации ARIS eEPC Формирование регламентирующих документов на основе описания процессов Информативность графических схем процессов Одна из важнейших целей формирования графических схем процессов – их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой? Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы: • «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»); • «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»); • «Процедура» системы Business Studio (один из возможных вариантов представления); • ARIS eEPC. В качестве тестового примера выбран простой и понятный процесс. Результаты его описания представлены на рис. 1–5. Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение») 1 Анализ доставок за предыдущий день. Корректировка графика доставки на следующий 2 На рис. 1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно: • описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса; • описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже; • описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса. Сформулируем плюсы и минусы рассмотренного использования ромбиков. (рис. 1) способа Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение») На рисунке 2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на 3 этой схеме на 24 графических элемента меньше, чем на рисунке 1. Схема на рис.2 выглядит гораздо проще: от графических элементов не рябит в глазах,а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. Рисунок 2.- Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение») Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день 4 5 Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение») Применение схем в таком же формате, как представленный на рис. 2, удобно как для разработчиков (бизнес-аналитиков), так и для сотрудников. На рисунке .3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение»[11] использованы нестандартным образом – не как графический элемент для отображения ветвления (оператор логики, развилка), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию: описание, начало, завершение,требование к срокам и т. п. Рис. 3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день 6 7 Вторая особенность схемы процесса на рис 3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах. Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию. Тот факт, что название стрелки в Business Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». Плюсы и минусы графического представления процесса на рис. 3 показаны ниже. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Обратите внимание, что в Business Studio нотация «Процедура» может использоваться по-разному. На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. 8 Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика. Рис.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio) OR – неисключающее логическое «ИЛИ»; XOR – исключающее логическое «ИЛИ». 9 10 Трудоемкость ее формирования также гораздо выше ,чем на предыдущих рисунках. Схема процесса в нотации ARIS eEPC (построена в Business Studio) На рис. 5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 1:в нотации BPMN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные. Рис. 5. Схема процесса в нотации BPMN 2.0 11 12 Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением – движком BPMсистемы. В то же время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы. При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к: • трудностям при интерпретации схем рядовыми сотрудниками; • невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение; • значительному увеличению формирование схем; трудозатрат бизнес-аналитиков на • дополнительным сложностям при документировании схем (например, большой объем). Нотация моделирования должна соответствовать уровню процессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию. Формирование регламентирующих документов на основе описания процессов После того как процессы описаны в среде моделирования (говоря шире – создана объектная модель организации), можно и нужно использовать эту информацию для регламентации деятельности. 13 В этом параграфе приведен пример использования среды моделирования Business Studio для формирования регламентирующих документов. Рассматриваются процессы управления транспортным отделом одной из российских компаний С технической точки зрения точно так же можно описывать любые процессы и другие объекты регламентации (подразделения, должности). На рис. 6 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта Рис. 6- Структура процессов управления транспортным отделом Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам 14 Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках предложенной задачи ее использование вполне адекватно. Для описания процессов внутри контуров управления использована нотация «Процедура». На рис. 6 показана кросс-функциональная схема процесса «Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем. Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты: • содержание деятельности; • начало процесса; • результат процесса. Этих атрибутов на первых порах вполне достаточно, но можно использовать и другие (в том числе создавать новые, необходимые бизнесаналитику). Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях: 1. описание контура управления; 2. описание процесса в контуре управления; 3. описание операций процесса (в табличной форме) и схему процесса. На рис.7 показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета – регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на выполнение для объекта «Управление ТО» (рис. 8.). Рис7- Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях 15 Рис.8.- Запуск отчета для объекта «Управление ТО» 16 Отчет, запущенный для объекта модели «Управление ТО», сгенерировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. 9). Рис. 9 - Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio Рис. 10 Вывод информации о процессе управления в табличной и графической форме 17 На рис. 10 показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе формата А4. Видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы: • номер операции; • наименование операции; • исполнитель; • инициирующие события; • входящие документы; • описание операции; • завершающие события; • исходящие документы. Графическая схема процесса представлена в кросс-функциональном виде. Объем регламента процесса управления составил для процесса «Управления ТО» около 70 страниц в MS Word, что совсем немного для такого значительного количества процессов. 18 Среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе: • регламенты выполнения процессов; • положения о подразделениях; • должностные инструкции (на должности и роли). 19