Управление проектами по внедрению корпоративной информационной систем - Казаков И.В
.pdf
Управление проектами по внедрению КИС
Архив проекта
Архив проекта - это обычный комплект документов, отражающих все аспекты проекта. Его цель - обеспечить, чтобы вся необходимая информация по любому вопросу, относящемуся к проекту, была постоянно доступна менеджеру проекта
идругим его участникам. Это важно по ряду причин:
•если в ходе исполнения работ меняется менеджер проекта (или ключевой член команды), архив проекта оказывает помощь в быстрой и необременительной передаче дел
•если возникают судебные разбирательства или есть угроза их возникновения, архив проекта предоставляет жизненно важную информацию, которую при его отсутствии было бы невозможно собрать
•если позднее выполняется подобный проект, данные архива проекта можно использовать для подготовки предложения, калькуляции цен и управленческого планирования
•по завершении проекта аудит поможет выявить сильные и слабые
стороны проекта Содержание архива проекта по внедрению КИС4.
1. Общая информация по проекту Предварительный план проекта Запрос на ассигнования по проекту
План создания информационной системы Контрактные документы
•Тендерные документы
•Предложения
•Оригиналы контрактов и приложений
•Корреспонденция по контракту
•Документы приемки
Описание работ
2.Управление и организация Основная схема организации Линейная схема обязанностей Ключевой персонал проекта
Должностные обязанности менеджера проекта и ключевых членов команды Ключевые менеджеры функциональных подразделений и
персонал, назначенный в проект Политика и директивы
3.Технические вопросы
Технический подход Спецификация КИС Спецификация компонентов Схемы и чертежи системы
Протоколы анализа проектирования Требования по техническим изменениям Требования обеспечения качества и надежности
4.Документы анализа предприятия Протоколы проектного обследования
Описание бизнес процессов предприятия As is Описание бизнес процессов предприятия to be Требования к изменениям Дизайн проект системы
5.Финансовые вопросы
4 На основе [10] и личного опыта
41
Управление проектами по внедрению КИС
Оценки работ Бюджеты План счетов
Платежные документы
6.Планы и расписания работ Структура проекта
Базовый календарный план и план ключевых событий Подробные календарные планы
7.Авторизация работ
Наряды на собственные работы Наряды субподряда
8. Оценка и отчетность Оценки и графики оценка проекта
Протоколы совещаний по оценки проекта Управленческие отчеты
9. Безопасность проекта Секретность работ Инспектирование Списки допуска
42
Управление проектами по внедрению КИС
Информационные системы управления проектами
Первые программы для управления проектами были разработаны почти сорок лет назад. В основе данных систем лежали алгоритмы сетевого планирования и расчета временных параметров проекта по методу критического пути. Первые системы позволяли представить проект в виде сети, рассчитать ранние и поздние даты начала и окончания работ проекта и отобразить работы на временной оси в виде диаграммы Ганта. Позже в системы были добавлены возможности ресурсного и стоимостного планирования, средства контроля за ходом выполнения работ.
Использование систем долгое время ограничивалось традиционными областями - крупными строительными, инженерными или оборонными проектами и требовало профессиональных знаний. Однако, за последнее десятилетие ситуация в области использования ПО календарного планирования резко изменилась.
Благодаря повышению мощности и снижению стоимости персональных компьютеров, а также, при участии таких корпораций, как Microsoft и Symantec, буквально заваливших рынок дешевыми системами для управления проектами, программное обеспечение и методики управления, доступные раньше только состоятельным организациям, пришли на рабочие столы и вошли в повседневную практику менеджеров и сотрудников средних и малых компаний.
В настоящее время на рынке представлено значительное количество универсальных программных пакетов для персональных компьютеров, автоматизирующих функции планирования и контроля календарного графика выполнения работ.
Западные обзоры программного обеспечения для управления проектами традиционно разделяют программы доступные на рынке в две широкие группы: системы "высшего" класса (стоимостью свыше $1000 и более простые системы (продающиеся по цене ниже $1000).
Развитие информационных технологий последних лет практически свело на нет различия между системами по объемным показателям мощности систем (размеры планируемого проекта по работам и ресурсам, скорость пересчета проекта). Даже дешевые пакеты сегодня способны поддерживать планирование проектов, состоящих из десятков тысяч задач и использующих тысячи видов ресурсов. Изучая матрицы сравнения основных функций систем, также достаточно трудно найти существенные пробелы в той или иной системе. Выявить отличия в реализации отдельных функций часто удается лишь при детальном изучении и тестировании системы.
Более правильно разделить пакеты календарного планирования на профессиональные и настольные (непрофессиональные). Профессиональные системы предоставляют более гибкие средства реализации функций планирования и контроля, но требуют больших затрат времени на подготовку и анализ данных и, соответственно, высокой квалификации пользователей. Второй тип пакетов адресован пользователям-непрофессионалам, для которых управление проектами не является основным видом деятельности. От пользователей, использующих пакеты планирования лишь время от времени при необходимости спланировать небольшой комплекс работ или ввести фактические данные по проекту трудно ожидать серьезных затрат времени и усилий на то, чтобы освоить и держать в памяти какие-либо специфические функции планирования или оптимизации расписаний. Для них более важным является простота использования и скорость получения результата.
43
Управление проектами по внедрению КИС
Как правило, современные системы календарного планирования, распространяемые на рынке, обеспечивают основной набор функциональных возможностей, которые включают в себя:
•средства проектирования структуры работ проекта,
•средства планирования по МКП,
•средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов),
•некоторые возможности стоимостного анализа,
•средства контроля за ходом исполнения проекта,
•средства создания отчетов и графических диаграмм.
Различия между пакетами могут заключаться в поддерживаемых ими вычислительных платформах, мощности, наличии дополнительных средств, и в качестве реализации предоставляемых ими функций.
Оценка мощности пакета включает в себя тестирование качества работы системы (скорость вычислений, печати, изменения экранов) и качество представления информации по проекту (диаграммы Ганта и PERT), а также оценку полноты и гибкости функций, необходимых для разработки плана и оперативного управления.
При оценке мощности системы для управления проектами обычно оцениваются следующие основные функциональные возможности:
1.Средства описания комплекса работ проекта, связей между работами и их временных характеристик:
•Поддержка календаря проекта (максимальный размер календаря, наиболее поздняя дата, максимальное количество праздников в одном календаре, возможность задавать рабочие дни недели и различные рабочие дни для различных недель, возможность задавать обычные рабочие часы);
•Ограничения, накладываемые на работы проекта (типы работ (Как Можно Раньше, Как Можно Позже, работы с фиксированной датой начала/окончания), возможность планирования выполнения работ по индивидуальным календарям);
•Возможности назначения временных характеристик (максимальная длительность отдельной задачи, максимальная длительность проекта, единицы времени, доступные в системе, задачи-вехи, вычисляемые резервы времени (полный, свободный), возможность системы автоматически присваивать длительность отдельным задачам, возможность привязки длительностей задач к объему назначенных ресурсов);
•Связи между задачами (максимальное количество предшествующих и последующих задач, допустимые типы связей, допустимые типы задержек/перекрытий);
•Максимально допустимое количество задач в проекте, длина имени задачи, возможности кодирования, возможность автоматического пересчета, многоуровневое представление проекта.
2.Средства поддержки информации о ресурсах и затратах по проекту и назначения ресурсов и затрат отдельным работам проекта.
•Информация о ресурсах (максимальное количество ресурсов на проект, возможность описания различных типов ресурсов (складируемые и нескладируемые, статьи затрат, номенклатура материалов), поддержка ресурсов с фиксированной стоимостью и ресурсов, стоимость которых
44
Управление проектами по внедрению КИС
зависит от длительности их использования, поддержка информации о требуемых и доступных объемах ресурса, возможность задания нормального и максимального объемов ресурса, возможность задания переменного объема ресурса, возможность задания индивидуальных календарей ресурсов);
•Назначение ресурсов задачам (максимальное количество ресурсов на задачу, возможность задания частичного использования ресурсов, возможность задания задержек при использовании ресурса);
•Календарное планирование при ограниченных ресурсах (выделение перегруженных ресурсов и использующих их задач, разрешение ресурсных конфликтов, автоматическое/командное выравнивание ресурсов, выбор ресурсов для выравнивания, выравнивание с учетом приоритетов задач, выравнивание с учетом ограничений по времени или с учетом ограничения на ресурс, оптимальность полученных планов).
3.Средства контроля за ходом выполнения проекта.
•Средства отслеживания состояния задач проекта (фиксация плана расписания проекта, средства поддержки фактических показателей состояния задач (процент завершения));
•Средства контроля за фактическим использованием ресурсов (бюджетное количество и стоимость ресурса, фактическое количество и стоимость ресурса, количество и стоимость ресурсов, требуемых для завершения работы);
•Средства стоимостного анализа состояния проекта и анализа на основе выполненных объемов работ.
4.Удобные графические средства представления структуры проекта (диаграмма Ганта, сетевая диаграмма, иерархическая диаграмма проекта), а также средства создания различных отчетов по проекту.
•Диаграмма Ганта (отображение критического пути, расчетных и фактических дат начала и окончания работ, резервов работ, возможность изменения временной шкалы, отображение текущей даты, отображение составных задач, отображение дополнительной информации);
•PERT диаграмма (отображение критического пути, расчетных и фактических дат начала и окончания работ, длительности, резервов работ, отображение многоуровневости детализации задач, возможность задания различных типов сетевой диаграммы, ручное и автоматическое размещение работ и связей, определение дополнительной информации);
•Средства создания отчетов (отчеты по состоянию выполнения расписания, отчеты по ресурсам и по назначению ресурсов, профили загрузки ресурсов, отчеты по затратам (могут включать стоимость отдельных задач, детализацию стоимости задач по ресурсам, стоимость ресурса по задачам, запланированную и фактическую стоимость), отчеты по денежным потокам, отчеты для анализа фактического состояния
выполнения задач проекта и сравнения с запланированным); Кроме того, следующие дополнительные возможности должны быть рассмотрены при выборе пакета планирования:
•Сортировка данных (максимальное количество критериев, сортировка по кодам задач и датам);
•Критерии отбора данных (исключающий и выделяющий отбор);
•Возможности печати (типы принтеров, плоттеры, многостраничный отчет);
45
Управление проектами по внедрению КИС
•Средства обмена данными (поддержка технологии клиент/сервер, стандартов SQL и ODBC, интеграция с ресурсами Web, импорт/экспорт (ASCII, dBase, Lotus, другие системы для управления проектами);
•Работа в сети;
•Работа с несколькими проектами (многопроектное планирование, объединение проектов, связь проектов, максимальное количество связанных проектов, совместное ресурсное планирование);
•Языки программирования и разработки макроопределений.
Важными для пользователя являются простота изучения и использования системы, а также качество дополнительной консультационной поддержки данной системы на рынке.
В настоящее время существует несколько сотен систем, так или иначе, реализующих функции СКПК. Однако разнообразная «заточенность» и «раскрученность» их делают свое ограничительное дело. Реально, на российском рынке стабильно присутствует не более 10 систем. Среди них есть и отечественные разработки.
46
Управление проектами по внедрению КИС
Практический пример: методологии внедрения КИС
Хотелось бы привести пример реальной методологии внедрения КИС. Ниже приведены основные процессы внедрения КИС Oracle (методология AIM Oracle [22]). Стоит обратить внимание на то, что в методологии Oracle используется иная терминология, нежели в данной работе.
Определение бизнес-требований
В процессе определения бизнес-требований определяются бизнес-потребности, которым должен соответствовать проект внедрения. Вы документируете бизнеспроцессы, определяя бизнес-события и описывая шаги, соответствующие этим событиям. Затем объединяете эти процессы в сценарии, где отображаются бизнес-требования.
Как часть процесса определения бизнес-требований, определяются финансовая и рабочая структуры компании, документируются объемы бизнес-операций и определяются требования к хранению данных. Рассмотрение вопросов аудита и контроля определяют дополнительно требования к защите и работе с информацией.
Анализ бизнес процессов
Любой проект внедрения КИС предприятия состоит из двух этапов.
•разработка прототипа будущей системы (называемого также «бизнесмоделью», «проектным решением» и т. п.);
•развертывание системы
Бизнес-модель — это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения КИС предприятия и определиться со следующими параметрами проекта:
•перечень участков внедрения и последовательность их автоматизации;
•фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
•реальные оценки сроков развертывания и запуска КИС;
•уточненный список членов команды внедрения и ключевых пользователей;
•степень соответствия выбранной КИС специфике бизнеса вашей
компании и многое другое Конечно, создание бизнес-модели — процесс не быстрый и занимает обычно от
четырех до девяти месяцев. Главное — набраться терпения и получить ответы на давно назревшие вопросы. Естественно, если речь идет о локальной автоматизации бухгалтерского учета, то результата можно добиться быстрее. Однако при комплексной широкомасштабной автоматизации ошибки в планировании стоят больших денег.
Можно выделить три уровня детализации бизнес моделирования:
•Концептуальное моделирование — для определения направления развития предприятия.
•Логическое моделирование — для описания деятельности предприятия CASE-средствами.
•Физическое моделирование — для формализации деятельности предприятия средствами ERP-системы (то есть для создания нормативной модели предприятия).
47
Управление проектами по внедрению КИС
Концептуальная модель является отраслевой моделью и, как правило, разрабатывается для предприятия внешним консультантом (обычно на основе эталонных моделей, предлагаемых поставщиками ERP-систем). В ней определяются основные направления развития предприятия через графическое представление передовой мировой практики (заключенной в стандарты ISO и ERP) и через определение несоответствий деятельности предприятия данной практике (на основе проведения сопоставительного анализа — benchmarking). Концептуальная модель подразумевает унификацию основных процессов предприятия в соответствии со стандартами ISO 9001:2000
Эталонная модель с использованием ISO 9000 переводится в IDEF0-модель. Таким образом, можно получить концептуальную модель предприятия, где осуществляются:
•декомпозиция процессов предприятия — верхний уровень иерархии процессов соответствует элементам и подэлементам стандарта ISO 9001:2000, а нижние уровни раскрываются с высокой точностью
•проектирование графического «скелета» документации СМК предприятия;
•определение ключевых пользователей процессов и бизнес-функций;
•определение на базе ERP-системы основных модулей информационной системы предприятия, обеспечивающих выполнение процессов;
•определение связей процессов по входам/выходам.
Второй уровень бизнес-моделирования — логический — необходим для уточнения основных выводов, следующих из концептуальной модели. Логическая модель описывает деятельность предприятия посредством объектно-ориентированного проектирования (опираясь на методологию бизнесмоделирования RUP9 и нотации UML10).
Цель логического моделирования — построить интегрированную модель деятельности предприятия, являющейся связующим звеном между бизнесметодиками и ERP-системой. Логическая модель позволяет спланировать, как нужно реорганизовать текущие способы выполнения процессов предприятия в желаемые — вплоть до каждого рабочего места.
Исходя из требований перехода предприятия на следующий уровень моделирования бизнес процессов логическая модель помогает детально ответить на следующие вопросы:
•кто и где исполняет бизнес-функции (организационный аспект деятельности);
•что перемещается в материальных и в связанных с ними информационных потоках (элементный аспект деятельности предприятия);
•как предприятие выполняет бизнес-функции (функциональный аспект);
•когда предприятие осуществляет бизнес-функции (динамический аспект);
•какая информационная платформа (какие инструменты) необходима для поддержания бизнес-функций на предприятии.
Осуществить функционально-стоимостной анализ процессов предприятия в бизнес-модели (на концептуальном и логическом уровнях) можно только очень приближенно. Поэтому количественные оценки процессов предприятия предлагается выполнять на уровне физического моделирования. Под физическим моделированием понимается определение (нормирование) временных и стоимостных характеристик процессов предприятия в ERPсистеме. На уровне физического моделирования разрабатывается нормативная модель предприятия. Нормативы и отклонения от заданных норм используются
48
Управление проектами по внедрению КИС
для оценки соответствия или несоответствия текущих способов выполнения процессов предприятия желаемым. От качества нормативной модели зависит качество внедрения и функционирования ERP-системы. Деятельность по совершенствованию процессов во многом является деятельностью по уточнению нормативов. ERP-система служит инструментом для достижения описанных в логической модели желаемых способов выполнения процессов предприятия, и с ее же помощью проводится оценка их эффективности и результативности.
Иными словами, бизнес-модель является отображением предприятия и его информационно-управляющей системы. Без бизнес модели Невозможно построить действительно интегрированную и «всеобъемлющую» КИС. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятия.
Очень важно с самого начала определиться, на кого вы будете ориентироваться при построении модели, то есть, кто будет ее конечным потребителем. В большинстве случаев ответ на этот вопрос один: руководство компании. Все попытки использования точек зрения главного бухгалтера или коммерческого директора превращают модель промышленного предприятия в модель финансового института или торгового дома.
С особой тщательностью следует подходить к формату представления бизнес-
модели. Популярная методология SADT (Structured Analysis and Design Technique) или рожденная на ее основе IDEF0 действительно хороши там, где практически отсутствуют описания функций и бизнес процессов, а также в тех случаях, когда построением модели занимается не единая, слаженная команда, а, например, группа, состоящая из внешних консультантов, экспертов поставщика КИС и сотрудников самого предприятия. В таком случае можно гарантировать, что большинство членов «сборной» команды знакомы с общепринятым стандартом IDEF0 (в настоящее время его преподают во многих вузах), следовательно, можно сравнительно быстро приступить к работе над моделью, «поделив» между собой бизнес функции предприятия. Создаваемые диаграммы будут совместимы друг с другом и смогут впоследствии составить единую модель. Однако характерная для стандарта IDEF0 бедность изобразительных средств делает невозможным, например, описание сквозных бизнес процессов, охватывающих весь цикл обработки заказа — от размещения до исполнения. Для подобных задач более подходящим инструментом могут служить такие известные системы проектирования, как ARIS («архитектор интегрированных информационных систем») или BAAN DEM («динамический моделировщик предприятий»). В общем, любой способ изображения модели хорош, если он нагляден и понятен руководству предприятия.
Отображение бизнес-требований
В процессе отображения бизнес-требований проводится сравнение бизнестребований со стандартной функциональность прикладного программного обеспечения и выявляются разрывы, которые должны быть урегулированы с целью полного соответствия бизнес-потребностям. Группы отображения работают с будущими бизнес-процессами и, как правило, связаны с какой-либо бизнес-функцией. Сценарии бизнес-требований отображаются затем на функциональность приложений.
49
Управление проектами по внедрению КИС
По мере возникновения разрывов между требованиями и функциональностью, они удаляются с помощью документирования каких-то обходных путей, альтернативных решений, расширений приложений или изменения основного бизнес-процесса.
После того, как бизнес-процессы отображены на приложении, а разрывы удалены, группа проекта документирует, как будет идти бизнес при использовании новой системы.
Приложение и техническая архитектура
В процессе создания приложения и технической архитектуры проектируется архитектура информационных систем, которая отображает ваше видение бизнеса. Использование бизнес-требований и требований к информационным системам, данный процесс способствует разработке плана для реализации и конфигурации:
•Приложений Oracle, третьей стороны и пользовательских приложений
•Поддерживающих баз данных приложений
•Критических интерфейсов предприятия и механизмов распределения данных между приложениями, серверами и центрами данных
•Компьютерного аппаратного обеспечения, включая серверы и настольные компьютеры заказчика
•Сетей и инфраструктуры связей данных
Согласованная и правильно спроектированная архитектура информационных систем является критическим фактором успеха для любого проекта внедрения. Проект архитектуры информационных систем должен быть:
•Создан на основе соразмерных входных данных о бизнес- и технических требованиях
•Согласован с корпоративным видением бизнеса
•Реалистичным касательно возможностей и ограничений технологии, на которой он основан
Первый из перечисленных выше пунктов особенно важен, потому что архитектурная часть проекта внедрения часть считается чисто технической по своей природе, в результате чего возникает риск зависимости бизнестребований от технологии. Хорошо управляемый проект архитектуры использует бизнес-требования и их функциональное отображение в качестве движущих механизмов для:
•Оптимальной конфигурации внедряемых приложений
•Инфраструктуры аппаратного обеспечения и сети, обеспечивающих обработку приложений
•Инструментов и процедур, необходимых для управления полной системой Чтобы прийти к архитектуре вновь внедренной системы, группа технической архитектуры должна рассмотреть следующие виды вопросов:
•Наилучшая стратегия реализации приложений в рамках одного или более центров данных, бизнес-организаций и бизнес-функций
•Высокоуровневая конфигурация приложений для поддержки финансовой. Административной, производственной и распределительной бизнесединиц
•Интерфейсные точки между приложениями и/или удаленными площадками, включая технические характеристики, потоки данных и механизмы
•Планирование реализации и производственной мощности для аппаратного обеспечения и инфраструктуры сетей, которые будут поддерживать обработку приложений
•Инструментальные средства и процедуры управления, которые дадут возможность системе продолжать работу в соответствие с планом
50