При внедрении управления по процессам важно придерживаться следующих принципов:
Принцип взаимосвязи процессов. Организация представляет собой сеть процессов. Процессом является любая деятельность, где имеет место выполнение работ. Все процессы организации взаимосвязаны между собой;
Принцип востребованности процесса. Каждый процесс должен иметь цель, а его результаты должны быть востребованы. У результатов процесса должен быть свой потребитель внутренний или внешний.
Принцип документирования процессов. Деятельность по процессу необходимо документировать. Это позволяет стандартизовать процесс и получить базу для изменения и дальнейшего совершенствования процесса;
Принцип контроля процесса. Каждый процесс имеет начало и конец, которые определяют границы процесса. Для каждого процесса в рамках заданных границ должны быть определены показатели, характеризующие процесс и его результаты;
Принцип ответственности за процесс. В выполнении процесса могут быть задействованы различные специалисты и сотрудники, но отвечать за процесс и его результаты должен один человек.
За счет того, что процессный подход создает горизонтальные связи в работе организации, он позволяет получить ряд преимуществ, в сравнении с функциональным подходом.
Основными преимуществами процессного подхода являются:
Координация действий различных подразделений в рамках процесса;
Ориентация на результат процесса;
Повышение результативности и эффективности работы организации;
Прозрачность действий по достижению результата;
Повышение предсказуемости результатов;
Выявление возможностей для целенаправленного улучшения процессов;
Устранение барьеров между функциональными подразделениями;
Сокращение лишних вертикальных взаимодействий;
Исключение невостребованных процессов;
Сокращение временных и материальных затрат.
ИТ-проект
Термин "ИТ-проект"
обычно используется для обозначения
деятельности, связанной с использованием
или созданием некоторой информационной
технологии. Это приводит к тому, что
ИТ-проекты охватывают очень разнообразные
сферы деятельности: разработку
программных приложений, создание
информационных систем, развертывание
ИТ-инфраструктуры и прочее.
Основными
причинами появлениями (источниками
идей) проектов
являются: неудовлетворенный спрос;
избыточные ресурсы; инициатива
предпринимателей; реакция на политическое
давление; интересы кредиторов.
IDEF6 – метод
рационального представления процесса
проектирования информационных систем.
Метод позволяет обосновать необходимость
проектируемых моделей, выявить
причинно-следственные связи и отразить
это в итоговой документации системы.
По IDEF6
причины инициализации IT
проектов заключаются в проблемах,
необходимостях, ограничениях (или
принуждениях, например, отсутствие
финансов) и ожиданиях. Таким образом,
требования
получаются из ожиданий и набора
проблем, необходимостей и ограничений.
Как результат, необходимость
удовлетворить все требования
заказчика.
Ресурсы
IT
проекта
– это совокупность условий, которые
дают возможность реализовать цели
проекта: организационная структура,
кадровый потенциал, бюджет, информационное
обслуживание, материально-техническая
база проекта, то есть все необходимые
средства для реализации проекта.
Классификация
ресурсов по PMBoK
(10
направлений): Integration
(управление интеграции проектами) Time
(срок проекта) Cost
(затраты, стоимость проекта) Scope
(управление содержанием: что это,
актуальность, тренд) Quality
(качество) HR
(управление человеческими ресурсами
проекта) Risk
(риски, 4 вида: технологический,
финансовый, административный,
управленческий) Коммуникации
(летучки, планерки) Закупки
Stakeholder
(ставки)
План ответа на вопрос 11.
Причины инициации it-проекта и их нотирование по idef6.
Ресурсы it-проекта и их классификация по pmBoK.
К IT-проектам относятся:
- проекты разработки и развития программного обеспечения;
- проекты внедрения информационных (автоматизированных) систем,
- инфраструктурные и организационные проекты.
К IT–проекту следует относиться как к самостоятельному инвестиционному проекту, то есть как к способу инвестирования средств в качественное улучшение управления компанией. Подобная позиция предполагает получение прибыли от реализации проекта через некоторый промежуток времени.
Отличительные особенности IT-проектов:
1. Их эффективность не всегда возможно выразить в деньгах. Информационная система сама по себе не повышает прибыльности предприятия, она может лишь повысить эффективность и ускорить процесс обработки данных. Увеличивает же прибыльность способность менеджмента принимать эффективные решения на основе этой информации. Если же не удается выделить параметры, по которым можно оценить эффективность IТ-проекта, то такой проект является организационным, так как и его идея, и реализация предусматривают изменение бизнес–процессов и системы управления предприятием. Связано это с тем, что некоторые проблемы, которые пытаются решить с помощью автоматизации, связаны с организацией работы на предприятии, и решить их можно только путем организационных и административных мероприятий.
2. IТ–проекты являются высокорисковыми. Риски срыва сроков, превышения плановой трудоемкости и не достижения запланированных результатов по этим проектам особенно высоки. Для IT-проектов характерна высокая интенсивность в сочетании с глубокой детализацией календарно-сетевых графиков и итерационностью выполнения работ. Обычно требуется детализация трудовых ресурсов до конкретного исполнителя. Нетрудовые ресурсы и материалы отслеживаются значительно реже.
3. Любой просчет или ошибка, как правило, очень быстро становятся известны широкому кругу людей. Если, например, осуществляется замена сервера или настройка какой-либо информационной системы и происходит сбой, то все пользователи тут же узнают об этом. Для сравнения в маркетинговом проекте просчеты далеко не так очевидны. Можно в его рамках сделать все правильно, но, допустим, не в полном объеме учесть интересы целевой аудитории. Напрямую обвинить в этом упущении руководителя проекта довольно сложно, т.к. существует большое количество внешних факторов. В IT-проекте кроме многочисленных внешних факторов более очевидна ответственность за результат.
4. Многие IT-проекты имеют колоссальные бюджеты. В крупных компаниях масштабы проектной деятельности в области IT измеряются миллионами долларов, и, причем реализация новых проектов происходит постоянно. Развитие IT-инфраструктуры в растущих компаниях требует больших и регулярных вложений. Большие бюджеты, в свою очередь, подразумевают больший уровень ответственности и, соответственно, больший уровень компетенции тех людей, которые этими проектами управляют.
5. Специфичное разделение на уровне идеологии заказчика и исполнителя: заказчиком, как правило, является бизнес, а исполнителем IT-специалисты. Данный аспект предопределяет наличие определенных трудностей в выявлении требований, ожиданий от проекта, в формировании технического задания. В IT-проектах чаще всего курирование процессами разработки и реализации осуществляется не бизнес-руководителем, а передается руководству IT, как следствие между ними возможны коммуникационные конфликты, несовпадение ожиданий, требований и результатов. Избежать подобного «недопонимания» между бизнесом и IT можно с помощью методик по выявлению и корректному фиксированию ожиданий от проекта, а также за счет четкого сбора требований к проекту на всех уровнях пользователей.
Управление IT-проектами – это один из видов управленческой деятельности, связанный с планированием и реализацией проектов в определенные сроки с определенным бюджетом и определенным качеством.
Инициация проекта (Project Initiating) – стадия процесса управления проектом, результатом которой является санкционирование начала проекта или очередной фазы его жизненного цикла.
Примеры причин отклонения проекта: недостаточный спрос на продукцию проекта или отсутствие его реальных преимуществ перед аналогичными видами продукции; чрезмерно высокая стоимость проекта (экономическая, экологическая, социальная и др.); отсутствие необходимых гарантий со стороны заказчика проекта; чрезмерный риск; высокая стоимость сырья.
Предназначение IDEF6 заключается в том, чтобы методически обосновать целесообразность проектирование информационных систем и выявить причинно-следственные связи. Таким образом, методика IDEF6 предпринимает попытки выявления логики, лежащей в основе решения и конечного дизайна. Четкое установление целесообразного дизайна помогает избежать повторения прошлых ошибок, предоставляет прямые результаты последствий предлагаемых изменений в конструкции, заставляет яснее изложить цели и предположения и в результате помогает определить окончательные спецификации системы. Четкое выявление мотивов, почему дизайнер выбрал и принял конкретный проект и дизайн, стратегию реализации системы на уровне предприятия, информационных систем, является необходимым для поддержания жизненного цикла самой системы.
Классификация ресурсов по PMBoK:
Управление интеграцией проекта (Project Integration Management). Под интеграцией понимается объединение, консолидация, сочленение и разнообразные интегративные действия, направленные на успешное управление ожиданиями заинтересованных сторон и выполнения определенных требований.
Управление содержанием проекта (Project Scope Management). Под управлением содержанием понимаются процессы, позволяющие производить выборку, фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся Руководителю проекта для успешного завершения проекта. Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ - ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.
Управление сроками проекта (Project Time Management). Под управлением сроками проекта или точнее говоря временем т.к. время, более широкое понятие, понимаются процессы, посредством которых обеспечивается своевременное завершение проекта. Схема данных процессов подразумевает: Определение операций, Определение последовательности операций, Оценка ресурсов операций, Оценка длительности операций, Разработка расписания и Управление расписанием.
Управление стоимостью проекта (Project Cost Management). Под управлением стоимостью проекта понимаются процессы, в части планирования и разработки бюджета, а также управления расходами, которые обеспечивают завершение проекта в рамках утвержденного бюджета. Общая блок-схема процессов включает в себя: Оценку стоимости, Определения бюджета и Управление стоимостью.
Управление качеством проекта (Project Quality Management). Под управлением качеством проекта подразумеваются процессы и различные действия со стороны исполняющей организации, подходы и политики в области качества, цели, задачи и зоны ответственности в области качества следующим образом - проект должен удовлетворять тем потребностям, ради которых он был инициирован. Само управление качеством проекта производится с помощью системы управления качеством, которая предусматривает набор определенных правил и процедур, в том числе и действия по постоянному совершенствованию процессов. Лучшей практикой считается, когда данные действия проводятся на всем протяжении проекта. Схема процессов управления качеством включает в себя: Планирование качества, Обеспечение качества и Контроль качества.
Управление человеческими ресурсами проекта (Project Human Resource Management). Процессы управления человеческими ресурсами организации, включают в себя подходы к управлению и руководством команды проекта. Под командой проекта подразумевается пул квалифицированных работников, для которых определены конкретные роли и ответственности за выполнение проекта. В ходе реализации проекта профессиональный и количественный состав команды проекта зачастую может меняться. Правильное распределение ролей по проекту и ответственности между членами команды проекта даёт возможность всем членам команды быть задействованными на этапе планирования проекта и принятия решений. В случае привлечение членов команды к проекту на ранних стадиях даёт возможность применять имеющийся у них опыт уже на этапе планирования проекта, позволяет укрепить нацеленность команды проекта на достижение определенных результатов. Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.
Управление коммуникациями проекта (Project Communications Management). Процессы управления коммуникациями, применяют с целью обеспечения своевременного формирования, подготовки, распространения, архивации, передачи, получения, использования информации на проекте. Наибольшая часть времени на проекте, у Руководителей проектов уходит на осуществление коммуникаций с членами команды и с другими заинтересованными сторонами проекта (внутренние, от обычных сотрудников до высшего руководства или внешние). Эффективность коммуникации заключается в том, что они служат связующим звеном между различными заинтересованными сторонами, вовлеченными в конкретный проект. Правильное управление коммуникациями заключается в объединении разнообразных культурных и организационных особенностей, консолидации накопленного опыта, сопоставления различных взглядов и интересов с целью выстраивания базовой структуры управления проектом. Схема процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Отчеты об исполнении.
Управление рисками проекта (Project Risk Management). Под процессами управления рисками проекта понимается планирование управления рисками, идентификация и анализ рисков, выработке методов реагирования на риски, контроль, мониторинг и управление рисками в ходе реализации проекта. Посредством процессов управления рисками проекта, Руководители проектов добиваются повышения вероятности возникновения и воздействия (влияния) благоприятных рисков (событий) на проект и снижают вероятность возникновения и воздействия (влияния) неблагоприятных рисков (событий) на проект в момент исполнения этого проекта. Схема процессов управления рисками проекта включает в себя: Планирование управления рисками, Идентификация рисков, Качественный анализ рисков, Количественный анализ рисков, Планирование реагирования на известные риски, Мониторинг и управление рисками.
Управление поставками проекта (Project Procurement Management). Процессы управления поставками проекта включают в себя покупку или приобретение тех или иных необходимых сущностей (продукты, услуги, результаты, документы), которые производятся внешними (подрядными) организациями по отношению к той, в которой реализуется проект. Сама организация, в которой выполняется проект может выступать в качестве покупателя или продавца этих сущностей. Также процессы управления поставками проекта включают в себя подпроцессы управления контрактами и изменениями, необходимые для разработки и сопровождения контрактов или заказов на покупку. Благодаря процессам управления поставками проекта появляется возможность администрировать все контракты на приобретение чего-либо в ходе реализации проекта и управлять контрактными обязательствами, которые были возложены на команду проекта. Схема процессов управления поставками проекта включает в себя: Планирование закупок, Осуществление закупок, Управление закупочной деятельностью, Закрытие закупок.
Управление заинтересованными сторонами проекта (Project Stakeholder Management). Под процессами управления ожиданиями заинтересованными сторонами проекта понимается как таковое общение между командой проекта и заинтересованными лицами, а также работы, направленные на удовлетворение их потребностей и решение возникающих проблем, которые могут повлечь за собой изменения на проекте. Благодаря правильному выстраиванию отношений между всеми заинтересованными сторонами на проекте, Руководитель проекта может увеличить вероятность успеха.
План
ответа на вопрос 12. ИТ-проект
ИТ-проекты
представляют собой проекты внедрения
новых информационных систем, а также
модернизацию существующих. При этом
модернизация (изменения, дополнения)
рассматривается как результат действий,
выполненных по запросу и относящихся
к функциональным или нефункциональным
требованиям, которые не были
специфицированы изначально, при
разработке и внедрении системы.
это иерархическое
разбиение всей работы, которую необходимо
выполнить для достижения целей проекта,
на более мелкие операции и действия
до такого уровня, на котором способы
выполнения этих действий вполне ясны
и соответствующие работы могут быть
оценены и спланированы. Она включает
также определение промежуточных
результатов всех составляющих эту
структуру работ.
После проведения
декомпозиции мы получаем список всех
проектных мероприятий (Work package), список
всех элементарных подзадач, стоимость
всех мероприятий, срок исполнения всех
проектных мероприятий, мероприятия,
отдаваемые на outsource, частичный учет
сторонних собственных проектов,
планирование с запасом по времени / по
деньгам, ответственных за исполнение
каждого мероприятия.
После проведения
декомпозиции работ будет известен
список работ, которые компания точно
не сможет провести сама, поэтому
необходимо произвести планирование
использования сторонних сил. Для этого
и существует Request
for
Proposal
(запрос
предложения о помощи). RFP
- это заявка на оказание услуги или
создание проекта, которую создаёт
заказчик для проведения конкурса.
В запросе
формулируются цели, требования к
проекту, продукту или услуге, определяются
критерии качества продукта или услуги,
а также объявляются критерии выбора
поставщика. Запрос может диктовать
структуру и формат предложений
поставщиков для возможности сопоставления
предложений.
Аутсорсинг -
использование фирмой-заказчиком на
контрактной основе ресурсов сторонней
организации.
Преимуществом
такого решения является снижение
затрат на ИТ-отдел, концентрация
ресурсов на основном производстве и
доступ к более высоким технологиям.
Недостатками же является рост расходов
на аутсорсинг (при большом запросе);
потеря контроля процессов, отданных
на аутсорсинг; отсутствие законодательной
базы аутсорсинга и опасность потери
конфиденциальной информации.
Структура декомпозиции работ
3. Request for Proposal и обращение к ит-аутсорсингу
/подробнее про IT-проект в предыдущем вопросе/
Структура декомпозиции работ
Итак, мы определили результаты, которые должны быть достигнуты по завершении проекта, и согласовали их со всеми заинтересованными лицами. Однако мы не можем планировать проект, руководствуясь лишь перечнем этих результатов. Чтобы спланировать проект, необходимо определить, какие конкретные работы должны быть выполнены для достижения этих результатов, т. е. для успешного завершения проекта. Для этого и используется структура декомпозиции работ (СДР, или Work Breakdown Structure, WBS).
WBS является ключевым элементом плана проекта. Без нее невозможно определить работу, которую необходимо сделать для выполнения проекта, а значит невозможно определить ни стоимость проекта, ни его календарный план. А без этого нельзя рассчитать, какие ресурсы потребуются для выполнения проекта и в какое время эти ресурсы должны быть доступны. Средства, выделенные на проект, будут получены вовремя только при условии тщательной проработки детального, поэтапного бюджета проекта. Наконец, не имея представления о том, какие работы должны быть выполнены в ходе проекта, невозможно удовлетворительным образом управлять рисками. Для решения всех перечисленных выше задач и необходима WBS.
В PMBoK WBS определяется как "ориентированное на результаты группирование компонентов проекта, которое определяет, какие работы должны быть произведены в проекте. Работы, не включенные в WBS, не входят в рамки проекта". Из этого определения мы можем извлечь метод выявления работ, которые надлежит выполнить для получения требуемых результатов проекта.