- •Часть 1. Учебное пособие
- •Содержание
- •1.Планирование
- •1.1.Планирование, основные понятия, виды и структура планов предприятия
- •1.1.1Сущность планирования
- •1.1.2Виды планов
- •1.1.3Структура плана предприятия
- •1.1.4Система плановых показателей
- •1.1.5Особенности внутрифирменного планирования на Западе
- •1.1.6Задачи планирования на предприятии в современных условиях
- •1.1.7Планирование производства. Значение данного раздела плана
- •1.1.8Расчет производственной программы предприятия
- •1.1.9Планирование объема производства
- •1.1.10 Показатели объема выпуска продукции
- •1.1.11 Анализ выполнения производственной программы
- •1.1.12 Производственная мощность предприятий, и планирование ее использования
- •1.1.13 Планирование ассортимента и качества продукции
- •1.1.14 Планирование и анализ баланса сырья
- •1.1.15 Тэп использования сырья
- •1.1.16 Планирование труда и заработной платы
- •1.1.17 Определение численности работающих на предприятии по категориям
- •1.1.18 Определение фондов оплаты труда (планирование расходов на оплату труда)
- •1.1.19 Определение тэп по труду
- •1.1.19.1Удельный расход рабочей силы
- •1.1.19.2Производительность труда
- •1.1.19.3Трудоемкость
- •1.1.19.4Способы расчета видовой трудоемкости
- •1.1.20 Тэп по зарплате
- •1.1.21 Коэффициент работающего оборудования (Кро) и процент плановых остановов
- •1.2.Системы планирования производства
- •1.2.1Введение
- •1.2.2Современные проблемы и противоречия при внедрении методов производственного планирования на отечественных предприятиях.
- •1.2.3Фактор сложности задач планирования
- •1.2.4Иерархия задач планирования. Традиционная отечественная терминология
- •1.2.5Производственная программа предприятия
- •1.2.6Планирование выполнения производственной программы
- •1.2.7Оперативное планирование
- •1.2.7.1Проблемы планирования обеспечивающих подразделений.
- •1.2.7.2Уникальность систем оперативного планирования
- •1.2.7.3Диспетчирование
- •1.2.8Вариативность процесса производственного планирования в традиционных системах
- •1.2.9Примеры ситуаций, приводивших к «разрывам» в системе планирования
- •1.2.10Выводы.
- •1.3.Управление предприятием, workflow, внедрение
- •1.3.1Введение
- •1.3.2Информационная технология и управление предприятием
- •1.3.2.1Взаимоотношения в сфере ит
- •1.3.2.2Функциональные изменения в сфере использования ит
- •1.3.2.3Выводы
- •1.3.3Средства workflow в рамках общей концепции управления предприятием
- •1.3.4Модель автоматизации управленческих процессов
- •1.3.5Системы workflow – понятия и определения
- •1.3.6Поддержка основных функций управления средствами workflow
- •1.3.7Выводы
- •1.4.Стратегия внедрения ит на российских предприятиях
- •1.4.2Условия внедрения ит на западных предприятиях
- •1.4.3Условия внедрения ит на российских предприятиях
- •1.4.4Выводы
- •1.5. Заключение
- •2.Программные системы
- •2.1.Управление программным проектом
- •2.1.1Введение
- •2.1.2Планирование проекта
- •2.1.2.1План разработки программного обеспечения
- •2.1.2.2Структура плана разработки
- •Введение
- •2.1.2.3Классификация действий по реализации проекта
- •2.1.2.4Критические пути
- •2.2.1Классические схемы разработки корпоративных систем
- •2.2.2Адаптивная организация проектных работ
- •2.2.3Процессная модель управления качеством
- •2.2.4Управление качеством проектов корпоративных информационных систем
- •2.2.5Особенности управления качеством проектов корпоративных информационных систем
- •2.2.6Модель управления изменениями и рисками крупного проекта
- •2.2.7Основные факторы, влияющие на риски крупного проекта
- •2.2.8Особенности анализа проектных рисков
- •2.3.Словарь определений
- •3.Заключение
- •4.Список литературы
2.2.6Модель управления изменениями и рисками крупного проекта
В рамках предлагаемой модели проект рассматривается как множество взаимосвязанных процессов, которые сгруппированы по фазам (этапам осуществления проекта, на которых достигаются какие-либо промежуточные результаты). Такая группировка позволяет отслеживать достижения целей и подцелей проекта и оценивать возможный риск его выхода за установленные ограничения. Кроме того, процессы проекта группируются по категориям на процессы, связанные:
с управлением проектом;
с продуктом проекта.
Процессы управления проектом группируются по их сродству, например, те из них, которые связаны со сроками (временем), включаются в одну группу. Практически во всех проектах в той или иной степени бывают представлены группы процессов установления целей проекта, управления взаимосвязями процессов в проекте, а также процессы, связанные с проектным заданием, сроками, затратами, ресурсами, кадрами, информационными потоками, менеджментом рисков и материально-техническим снабжением.
Структура всех процессов проекта связана с конфигурацией ИС таким образом, чтобы в любой момент осуществления проекта была возможность реализовать требования, предъявляемые к ИС на различных стадиях ее жизненного цикла. Она определяет отношения между видами деятельности, непосредственно касающимися процессов проекта и характеристик создаваемой ИС, в их числе функции управления конфигурацией, проектирование ИС, материально-техническое обеспечение, заключение контрактов, управление информацией и т. п.
ИС на каждом этапе ее построения обладает определенной базовой для данного этапа конфигурацией. Соответственно и процессы проекта должны быть выстроены таким образом, чтобы в результате их осуществления была достигнута именно эта конфигурация.
Управление конфигурацией ИС и процессами проекта позволяет координировать управление перечисленными видами деятельности, исходя из тех изменений, которые постоянно возникают в ходе реализации проекта.
При разработке и внедрении ИС существует много причин, приводящих к возникновению рисков: ошибки в выборе стратегии проекта, нечетко поставленные цели и задачи, изменение внешних и внутренних требований, низкая квалификация персонала и т. д.
Одна из важных особенностей предлагаемой модели - управление рисками такого проекта, которое во многом строится на управлении конфигурацией ИС и процессами проекта (табл. 2). Кроме того, умение управлять разработкой и внедрением ИС требует от компаний создания своей собственной корпоративной культуры, т. е. участники проекта должны уметь оценивать риски и выгоду в рамках каждого проекта, принимать на основе этих оценок быстрые и адекватные проектные решения, легко и без серьезных потерь реагировать на изменения требований заказчиков и условий рынка.
Таблица 4
Виды рисков/ варианты менеджмента рисков |
Снижение видов риска |
Допущение риска (для крупных проектов, как правило, не срабатывает) |
Распределение риска |
Снижение вероятности возникновения риска |
Риски, связанные с масштабом проекта |
Детальный анализ каждого этапа работ, взаимодействия участников, организации работ |
Увеличение трудоемкости работ и стоимости проекта |
Разделение проекта на несколько подпроектов, выделение пилотного проекта по подсистемам (ограниченного масштаба) |
Детально проработанная программа качества, отработанное управление конфигурацией проекта, специальные процедуры взаимодействия участников |
Риски, связанные с недостаточным опытом в сфере ИТ |
Проведение обучения пользователей, включая руководство, соблюдение технологий работы |
Увеличение трудоемкости работ и стоимости проекта |
Согласование с заказчиком большинства проектных документов, согласование всех изменений в функциональности системы |
Разработка и утверждение концепции проекта на возможно более ранней его стадии |
Технические риски проекта |
Строгий отбор проектной команды по квалификационным критериям. Обучение участников проекта технологии проектных работ, инструментальным средствам |
Увеличение трудоемкости работ и стоимости проекта |
Документально зафиксированная персональная ответственность участников проекта, документальное фиксирование всех изменений в процессе проекта |
Использование стандартов предприятия на проектные работы, разработка стандартов проекта |
Организационные риски проекта |
Обучение участников проекта (курс "управление проектом"), тренинги команды, как можно более полная формализация деятельности |
Увеличение трудоемкости работ и стоимости проекта |
Включение представителей заказчика в рабочие группы |
Включение в команду администратора проекта, детальное распределение ролей в проекте |
Операционные риски проекта |
Многократное тестирование созданных продуктов, тщательная экспертиза документов |
Увеличение трудоемкости работ и стоимости проекта |
Акт сдачи заказчику любого документа. Фиксирование отсутствия претензий заказчика по каждому этапу работы |
Строгое выполнение процедур программы качества |
Очевидно, что чем сложнее проект, тем сильнее проявляется взаимосвязь проектных рисков и, следовательно, тем более формализованным должно быть управление проектами для адекватного снижения этих рисков. В крупных проектах работы обладают высокой связностью, что приводит к тому, что любые изменения в одном процессе так или иначе влияют на другие процессы проекта.
В основе модели управления качеством крупного проекта должна находиться система управления рисками проекта.
Практически любой процесс проекта имеет свой собственный (специфичный) набор рисков и некоторый общий набор рисков для всех процессов проекта. В соответствии со стандартом ИСО 10006:1996 управление рисками включает следующие виды деятельности:
выявление - определение рисков в проекте;
оценка - оценивание вероятности появления рисковых событий и их воздействия на проект;
развитие реакции - разработка планов реагирования на риски;
контроль за рисками - реализация и обновление рисковых планов.
Для выявления рисков первоначально необходимо выбрать объекты, которые будут анализироваться. К ним относятся процессы и продукты проекта. Как правило, в сферу анализа рисков невозможно включить все процессы и продукты проекта, так как это может потребовать неприемлемых затрат времени и сил, поэтому приходится останавливаться на некоторых наиболее важных и критичных процессах и продуктах. Поможет в выборе таких процессов анализ конфигурации. В стандартах ИСО/МЭК 12207:1995 "Информационные технологии. Процессы жизненного цикла программного обеспечения" и ИСО 10007:1995 представлены процедуры и задачи, которые должны выполняться при управлении конфигурацией. Конфигурация проекта обычно основывается на спецификациях ИС на определенном этапе работ и процессах, выполнение которых приведет к созданию этой системы. Так же можно определить взаимосвязи процессов и соответственно наметить возможные "переходные" риски.
При выявлении и анализе рисков существенную помощь могут оказать формализованные методы. Например, в стандарте SPICE описаны 35 основных процессов, используемых при создании ИС и методы их оценки. Здесь же приводятся пять категорий процессов (взаимодействия поставщика и потребителя, проектирования, обеспечения, управления и организационные процессы) и набор соответствующих базовых методов. При сравнении действующих процессов проекта с приведенными референтными моделями можно выявить вероятные риски каждого из процессов. Процессы, уровень адекватности которых оказался неудовлетворительным, имеют высокую вероятность возникновения риска. Наличие в стандарте также перечня входных и выходных данных, необходимых для исследования того или иного метода, позволяет при оценке процесса определить вид риска. Конечно, ни один стандарт не в состоянии описать полный набор возможных методов и данных, которые могут применяться в том или ином проекте, но отсутствие базовых методов в управлении проектом почти наверняка приведет к возникновению риска.
Управление риском - сложный итерационный процесс. Все его этапы тесно связаны между собой, поэтому при выполнении каждого этапа может возникнуть необходимость повторения предыдущего. Например, при оценке риска может оказаться, что выбранных процессов для проведения анализа недостаточно, так как риск, имеющий большую вероятность возникновения, передается в процесс, первоначально не включенный в анализ.
Важным этапом работ по управлению риском проекта является разработка планов реагирования на риск. Как правило, для разработки таких планов недостаточно идентифицировать и оценить риски, необходимо еще и провести анализ причин их возникновения. Одним из простых и достаточно эффективных методов такого анализа может служить метод FME(С)A (Failure Mode, Effects and (Criticality) Analysis) - метод анализа видов, последствий и (критичности) отказов (дефектов). На этом этапе работ определяется стратегия внесения изменений в проект, так как конфигурация проекта находится в прямой зависимости от вероятных рисков процессов. При необходимости планы реагирования на риск должны строиться на основе данных предыдущих аналогичных проектов, так как это уменьшит вероятность внесения новых рисков. Составляя планы реагирования на риск, целесообразно учитывать возможность с помощью одного мероприятия предотвратить несколько рисков. Такая возможность появляется, например, при наличии "переходных" рисков.
Когда намеченные мероприятия по предотвращению или снижению рисков выполнены, надо убедиться, что они оказали требуемое воздействие. Для этого выявленные риски проекта необходимо контролировать с помощью итеративных процессов идентификации и оценки рисков. Если после осуществления запланированных мероприятий риски находятся на приемлемом уровне, значит проведенный анализ рисков и мероприятия по их снижению оказались эффективными. В противном случае потребуется проанализировать допущенные ошибки и повторить все этапы управления риском проекта.