Управление проектами по внедрению КИС - ВКР

Московский Государственный Университет им. М.В. Ломоносова Экономический факультет Кафедра Экономической информатики.

Выпускная квалификационная работа Тема: "Управление проектами по внедрению КИС"

Студент 4 курса д/о 3 курса 412 группы Казаков И. В.

Научный руководитель Профессор М. И. Лугачев

Управление проектами по внедрению КИС

Введение ................................................................................................... 3 Цель работы ........................................................................................... 3 Определение проекта ................................................................................. 4 Цели проекта .......................................................................................... 4 Управление проектом .............................................................................. 5 Жизненный цикл проекта......................................................................... 7 Разработка информационной системы предприятия......................................10 Разработка КИС в рамках проектного подхода ..........................................10 Жизненный цикл информационной системы .............................................11 Организация управления проектами ...........................................................13 Организационные структуры управления проектами .................................13 Участие в проекте сторонней управляющей компании-консультанта. Взаимоотношение заказчика проекта с консультантом ..............................14 Управление проектами...............................................................................16 Подбор персонала – стратегический взгляд ..............................................16 Организация офиса проекта и команды проекта .......................................17 Планирование проекта ...........................................................................21 Архив проекта .......................................................................................41 Информационные системы управления проектами .......................................43 Практический пример: методологии внедрения КИС.....................................47 Определение бизнес-требований .............................................................47 Анализ бизнес процессов ........................................................................47 Отображение бизнес-требований.............................................................49 Приложение и техническая архитектура...................................................50 Проектирование и программирование модулей .........................................51 Преобразование данных .........................................................................51 Документирование .................................................................................51 Тестирование.........................................................................................52 Тестирование бизнес-систем ...................................................................53 Тестирование производительности ..........................................................53 Обучение ..............................................................................................53 Переход к промышленной эксплуатации ..................................................53 Определение .........................................................................................54 Анализ операций....................................................................................54 Техническое проектирование ..................................................................55 Рабочее проектирование.........................................................................56 Переход ................................................................................................56 Промышленная эксплуатация ..................................................................56 Заключение ..............................................................................................57 Литература ...............................................................................................58

2

Управление проектами по внедрению КИС

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

Цель работы Внедрение информационной системы довольно сложная задача, затрагивающая все сферы деятельности коммерческого предприятия. По сути, внедрение информационной системы представляет собой мультипроект и включает в себя подмножество отдельных проектов как, например, разработка нового программного обеспечения, реинжиниринг процессов предприятия, обучение персонала. Особенностями проекта по внедрению корпоративной информационной системы (далее КИС) являются: 1. Высокая степень технической или эксплуатационной сложности 2. Высокая степень инноваций и сложная структура связанных с ней рисков 3. В таких проектах участвуют, как правило, несколько организаций, от которых зависит конечный результат 4. Большой экономический риск, так как создание информационной системы предприятия требует огромных ресурсов и от качества внедрения зависит дальнейшая работа предприятия Очевидно, что управление таким проектом представляет собой сложнейшую задачу, которая может быть решена только с использованием современной методологии управления проектами. Поэтому целью данной работы является изучение методологии управления проектам, в том числе по внедрению корпоративной информационной системы. Перед началом работы необходимо ограничить рамки, в пределах которых изучается методология управления проектами: 1. Работа носит концептуальный характер. 2. Работа не дает точных ответов, а лишь задают идеи, которые должны быть использованы в практической работе. 3. Под внедренной системой понимается эффективно работающая КИС 4. Внедряется готовая информационная система. 5. КИС внедряется при помощи консультантов.

3

Управление проектами по внедрению КИС

Определение проекта Перед тем как подробно начать рассматривать проект, необходимо определить терминологию1. Проект – это совокупность задач и мероприятий, связанных с достижением запланированной цели, который обычно имеет уникальный и не повторяющийся характер Основные характеристики, общие для всех проектов, приведены ниже [1]: 1. Проект – комплекс действий, имеющий начало и конец. Каждый проект уникален. Проекты направлены на достижение цели в рамках бюджета и календарного плана. 2. Проект – процесс достижения определенных результатов. Проект можно рассматривать как целостный процесс: строительство завода, запуск нового продукта, или внедрение новой информационной системы. 3. Проект имеет жизненный цикл. Жизненный цикл проекта имеет определенную начальную и конечную точки, которые обычно привязаны к временной шкале. Проект по внедрению информационной системы полностью соответствует данным характеристикам: он уникален, направлен на достижение своей цели – повышение эффективности предприятия путем внедрения КИС – и имеет строго фиксированный жизненный цикл. Вместе с тем, необходимо различать проект и программу. Так: • Программа – долгосрочная деятельность, подразумевающая выполнение более чем одного проекта. • Проект – комплекс действий, состоящий из взаимосвязанных задач, выполняемых организацией для достижения определенных целей в соответствии с бюджетом и календарным планом Программа и проект связаны между собой отношением система – подсистема.

Цели проекта Ключевая характеристика отдельно взятого проекта – это его цель или группа целей, объединенная в миссию проекта. Цель проекта – желаемый результат деятельности, достигаемый в переделах установленного интервала времени. [1] Четко определенная цель – это необходимое условие выполнения проекта. Цель проекта - это не только общая установка, это еще и характеристика достижения этой цели. То есть при целепологании нельзя ограничиться лишь отельными установками. Чтобы быть значимыми, цели должны удовлетворять ряду характеристик [2]:

1

В данной работе термины используются в соответствии с рекомендациями PMI [23], если не указано иное.

4

Управление проектами по внедрению КИС Во-первых, цели должны быть конкретными и измеримыми. Лишь устанавливая измеримые цели можно отслеживать и оценивать их достижение. Во-вторых, цели должны быть ориентированы во времени, то есть, связаны с определенными горизонтами планирования. В-третьих, цель должна быть достижима. Кроме того, цели должны поддерживать друг друга, то есть достижение одной цели не должно мешать достижению других. Это означает, что цели проекта должны быть четко определены, иметь ясный смысл; результаты измеримы, а заданные ограничения и требования выполнимы. Для случая с внедрением КИС выработка цели проекта представляет довольно сложную задачу. Поскольку выработка целей процесс творческий, здесь не существует определенных методов и стандартов. Но определенные закономерности присущи и этому процессу. Прежде всего, заказчику проекта необходимо четко сформулировать свои желания по поводу проекта: для чего внедряется КИС. Кроме того, необходимо учесть пожелания коллектива предприятия. После того, как все пожелания были учтены, необходимо требования формализовать и привести к целям проекта. Далее необходимо выработать критерии достижения этих целей. Пример. Первоначально цель проекта звучала как «Внедрение КИС». Но, действуя в соответствии с этой целью, заказчик может получить вовсе не то, что он хотел. Поэтому цель необходимо формализовать, разбить на измеримые подцели. Так, например, цель для предприятия со сложной логистикой может звучать так: «снизить транзакционные издержки предприятия на 12 %». Оценить такую цель достаточно сложно, но если ее разбить на подцели «снижение складских запасов на 24% путем использования MRPII», «снижении расходов на персонал на 5% путем введения автоматической системы подсчета товара на складе», то оценить результат по целям будет гораздо проще. Поэтому определенные достижимые цели проекта должны быть четко сформулированы и описаны. Это по существу должно стать документированным соглашением сторон о целях и результатах проекта. Заказчику этот документ позволит понять, что он получит по окончанию работы, а исполнителю – что необходимо осуществить. Цели проекта должны быть описаны в понятной и однозначной форме. Последовательность описания целей проекта может быть следующей [1]: 1. Результаты проекта • описание целей и результатов проекта • описание основных экономических показателей 2. Реализация проекта 3. Сроки проекта 4. Ресурсы проекта 5. Корректировка целей проекта 6. Описание альтернативных и дополнительных целей

Управление проектом Управление проектом – это использование знаний, навыков, методов и средств для выполнения работ проекта с целью получения продукта проекта,

5

Управление проектами по внедрению КИС соответствующего заданным требованиям. Такое определение дается в русскоязычном Глоссарии PMI. Постараемся его расширить. Прежде всего, как видно из определения, управление проектами является междисциплинарной практической наукой, которая имеет ряд пересечений с другими управленческими, финансовыми, математическими и социальными дисциплинами. Наиболее значимую часть в процессе управления проектами занимают управленческие дисциплины, такие как общая теория управления, управление производством, управление динамическими процессами, а также психология. Наука об управлении проектами имеет свою уникальную область знаний, частично пересекающуюся с другими областями. Управление проектами состоит из процессов по осуществлению проекта. Система управления проектами состоит из объекта управления (проекта) и субъекта управления (команды проекта), связанных между собой прямой (управляющей) и обратной (реактивной) связями. В этой системе реализуются два вида процессов: • Проектно-ориентированные работы, связанные с объектом управления проектом или самим проектом (в нашем случае это может быть, например, процессы, связанные с выполнением настройки ERP системы под требования заказчика). • Процессы, связанные с субъектом управления проектом. Они включают в себя планирование, организацию работ и т.д. То есть эти процессы выполняют сервисные функции, без которых нельзя реализовать проект. Процессы управления проектами могут быть разделены на пять групп: 1. Процессы инициации • инициация проекта или его очередной фазы • разработка концепции управления проектами • технико-экономическое обоснование • оценка и утверждение проекта или его фаз 2. Процессы планирования • планирование предметной области (цели, результаты) • структурная декомпозиция целей проекта • определение работ их взаимосвязей • планирование ресурсов • оценка продолжительности работ • объемно-календарное планирование • оценка стоимости и бюджетирование проекта • организационное планирование • формирование команды проекта или фазы проекта • планирование коммуникаций проекта • идентификация и оценка рисков проекта • разработка мер реагирования на риски • планирование контрактов • разработка плана проекта (фазы проекта) 3. Процессы выполнения • организация и координация выполнения плана проекта • распределение информации • размещение заказов на работы и услуги • заключение и сопровождение контрактов 4. Процессы контроля и регулирования проекта • предоставление отчетов о ходе выполнения проектов 6

Управление проектами по внедрению КИС • •

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

Жизненный цикл проекта Каждый проект от возникновения идеи до полного завершения проходит ряд фаз. Полный набор этих фаз представляет собой жизненный цикл проекта. Жизненный цикл проекта (Project Life Cycle) - набор последовательных фаз, количество и состав которых определяется потребностями управления проектом организацией или организациями, участвующими в проекте. Жизненный цикл проекта имеет определенную начальную и конечную точки, которые могут быть привязаны к временной шкале. Жизненный цикл проекта можно разделять на фазы, фазы – на стадии и этапы. Одно из определений, выходящих за рамки PMI звучит так: «Жизненный цикл проекта – это набор последовательных фаз, выделенных для лучшего контроля и управления». Общепринятой концепцией разделения жизненного цикла проекта на фазы нет и быть не может, так как каждый проект уникален. Тем не менее, ключевые фазы жизненного цикла присутствуют в любом проекте и присущи практически всем успешным проектам. Жизненный цикл проекта описан во многих работах, но наиболее развернуто он представлен в работе PMI: «A guide to the Project Management Body of Knowledge». Основными фазами проекта являются 1. Определение концепции проекта. Основное содержание этой фазы предпроектный анализ, то есть предварительная формулировка целей проекта. 2. Разработка проекта. Прежде всего, это анализ проекта и поиск подрядчиков, контрактные торги, основные тендеры. 3. Реализация проекта включает в себя детальное проектирование, создание объекта проекта (строительство завода или написание программы), опытная эксплуатация. 4. Завершение проекта – основная задача запустить объект проекта в эксплуатацию. Руководители проектов разбивают цикл жизни проекта на этапы различными способами. Например, в проектах по разработке программного обеспечения часто выделяются такие этапы как осознание потребности в информационной системе, формулирование требований, проектирование системы, кодирование, тестирование, эксплуатационная поддержка. Однако, наиболее традиционным является разбиение проекта на четыре крупных этапа: формулирование проекта, планирование, осуществление и завершение.

7

Управление проектами по внедрению КИС Формулирование проекта по существу подразумевает функцию выбора проекта. Проекты инициируются в силу возникновения потребностей, которые нужно удовлетворить. Однако, в условиях дефицита ресурсов невозможно удовлетворить все потребности без исключения. Приходится делать выбор. Одни проекты выбираются, другие отвергаются. Решения принимаются исходя из наличия ресурсов, и в первую очередь финансовых возможностей, сравнительной важности удовлетворения одних потребностей и игнорирования других, сравнительной эффективности проектов. Решения по отбору проектов к реализации тем важнее, чем масштабнее предполагается проект, поскольку крупные проекты определяют направление деятельности на будущее (иногда на годы) и связывают имеющиеся финансовые и трудовые ресурсы. Определяющим показателем здесь является альтернативная стоимость инвестиций. Иными словами, выбирая проект "А", а не проект "В", организация отказывается от тех выгод, которые мог бы принести проект "В". Для сравнительного анализа проектов на данном этапе применяются методы проектного анализа, включающие в себя финансовый, экономический, коммерческий, организационный, экологический, анализ рисков и другие виды анализа проекта. Системы для планирования и управления проектами на этой стадии, как правило, используются в ограниченном виде. Планирование. Планирование в том или ином виде производится в течение всего срока реализации проекта. В самом начале жизненного цикла проекта обычно разрабатывается неофициальный предварительный план - грубое представление о том, что потребуется выполнить в случае реализации проекта. Решение о выборе проекта в значительной степени основывается на оценках предварительного плана. Формальное и детальное планирование проекта начинается после принятия решения о его реализации. Определяются ключевые точки (вехи) проекта, формулируются задачи (работы) и их взаимная зависимость. Именно на этом этапе используются системы для управления проектами, предоставляющие руководителю проекта набор средств для разработки формального плана: средства построения иерархической структуры работ, сетевые графики и диаграммы Гантта, средства назначения и гистограммы загрузки ресурсов. Как правило, план проекта не остается неизменным, и по мере осуществления проекта подвергается постоянной корректировке с учетом текущей ситуации. Осуществление. После утверждения формального плана на менеджера ложиться задача по его реализации. По мере осуществления проекта руководители обязаны постоянно контролировать ход работ. Контроль заключается в сборе фактических данных о ходе работ и сравнении их с плановыми. К сожалению, в управлении проектами можно быть абсолютно уверенным в том, что отклонения между плановыми и фактическими показателями случаются всегда. Поэтому, задачей менеджера является анализ возможного влияния отклонений в выполненных объемах работ на ход реализации проекта в целом и в выработке соответствующих управленческих решений. Например, если отставание от графика выходит за приемлемый уровень отклонения, может быть принято решение об ускорении выполнения

8

Управление проектами по внедрению КИС определенных критических задач, за счет выделения на них большего объема ресурсов. Завершение. Рано или поздно, но проекты заканчиваются. Проект заканчивается, когда достигнуты поставленные перед ним цели. Иногда окончание проекта бывает внезапным и преждевременным, как в тех случаях, когда принимается решение прекратить проект до его завершения по графику. Как бы то ни было, но когда проект заканчивается, его руководитель должен выполнить ряд мероприятий, завершающих проект. Конкретный характер этих обязанностей зависит от характера самого проекта. Если в проекте использовалось оборудование, надо произвести его инвентаризацию и, возможно, передать его для нового применения. В случае подрядных проектов надо определить, удовлетворяют ли результаты условиям подряда или контракта. Может быть, необходимо составить окончательные отчеты, а промежуточные отчеты по проекту организовать в виде архива.

9

Управление проектами по внедрению КИС

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

Разработка КИС в рамках проектного подхода Масштабы и сложность практического внедрения КИС предъявляют новые требования к управлению подобными проектами. У проблемы управления ERPсистемами есть две стороны – человеческий фактор и технологический аспект. Пакет средств управления предприятием охватывает всю организацию, и его внедрение сказывается на работе едва ли не каждого работника. Более того, в некоторых случаях руководитель проекта ERP просто не способен заранее предвидеть, кто именно попадет под влияние новых технологий, а это чревато весьма неприятными сюрпризами. Например, возможна ситуация, когда ошибки в управлении такой системой могут заблокировать поступление комплектующих на завод по производству какого-либо оборудования и как следствие привести к закрытию фирмы-производителя. Практически невозможно заранее составить четкое представление и о технологической стороне реализации проекта ERP, в котором тесно переплелось огромное множество аппаратных средств и программного обеспечения. Менеджеру проекта приходится иметь дело буквально с тысячами отдельных компонентов. А ведь независимо от того, добавляется в систему одинединственный модуль или полностью обновляется какой-либо ее сегмент, необходимо обеспечить полную совместимость и интеграцию нововведения со всеми остальными компонентами. По результатам проведенного Ч. Треппером опроса [8] был составлен неофициальный список основных проблем, с которыми приходится сталкиваться инициаторам развертывания систем управления ресурсами предприятия и менеджерам таких проектов. Почти все опрошенные в первую очередь жаловались на масштабность выполняемых работ. В десятку наиболее сложных проблем вошли также кадровые вопросы и выработка организационной политики. Десять наиболее значимых проблем, возникающих на проекте по внедрению КИС 1. Масштабы проекта 2. Кадровое обеспечение (в том числе текучесть кадров) 3. Управление рисками 4. Нереальные сроки 5. Финансирование проекта 6. Организационная политика 7. Многочисленные задержки 8. Неожиданные функциональные бреши 9. Проблемы взаимодействия 10.Сопротивление нововведениям И еще одной важной проблемой является то, что сразу же после ввода ERPсистемы в эксплуатацию виден огромный разрыв между тем, что она обещает, и

10

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

Жизненный цикл информационной системы Под жизненным циклом системы обычно понимается непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент ее полного изъятия из эксплуатации. Традиционно выделяются следующие этапы жизненного цикла информационной системы – анализ требований, предъявляемых к системе, проектирование информационной системы, программирование, внедрение, тестирование и отладка, эксплуатация и сопровождение, изъятие из эксплуатации/внедрение новой версии. То есть жизненный цикл системы пересекается с жизненным циклом проекта, но не соответствует ему. Жизненный цикл проекта внедрения КИС начинается и заканчивается раньше жизненного цикла информационной системы, ведь проект внедрения начинается еще до анализа требований и заканчивается после того, как система запущена в эксплуатацию. Стоит отметить, что некоторые авторы придерживаются иной точки зрения и отождествляют жизненный цикл ИС и жизненный цикл проекта по внедрению ИС. В данной работе эти понятия будут разнесены. Существуют три основных модели жизненного цикла – каскадная, поэтапная модель с промежуточным контролем и спиральная[3]. Суть каскадной модели (70-80 годы) заключается в разбиении всей разработки на этапы, причем переход от предыдущего этапа к последующему осуществляется только после полного завершения работ предыдущего этапа. Соответственно на каждом этапе формируется законченный набор проектной документации, достаточной для того, чтобы разработка могла быть продолжена другой группой разработчиков. Другим положительным моментом каскадной модели является возможность планирования сроков завершения работ и затрат на их выполнение. Однако у каскадной модели есть один существенный недостаток - очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему и поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. Результатом такого конфликта стало появление модели с промежуточным контролем (80-85 годы), которую представляют или как самостоятельную модель, или как вариант каскадной модели. Эта модель характеризуется межэтапными корректировками, удлиняющими период разработки изделия, но повышающими надежность. Однако и каскадная модель, и модель с промежуточным контролем обладают серьезным недостатком - запаздыванием с получением результатов. Данное обстоятельство объясняется тем, что согласование результатов возможно только после завершения каждого этапа работ. На время же проведения каждого этапа требования жестко задаются в виде технического задания. Так что существует опасность, что из-за неточного изложения требований или их изменения за

11

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

12

Управление проектами по внедрению КИС

Организация управления проектами При внедрении КИС, задача создания организационной структуры управления проектами становится чрезвычайно сложной. Это связано с тем, что нет однозначных универсальных ответов на следующие ключевые вопросы управления проектами: • Кто будет нести ответственность за проект, и в каком объеме? Как будет распределяться ответственность между менеджером проекта и другими руководителями? • Кому подотчетен менеджер проекта? На каком уровне и в каком подразделении? • Кто из участников проекта должен входить в офис проекта, кто должен принимать участие в проекте, оставаясь в рамках своего функционального подразделения, кого в проект включать нельзя? Попытке ответить на данные вопросы посвящена эта часть работы.

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

13

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

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

управляющей компаниизаказчика проекта с

Переход на проектно-ориентированные методы управления проектами по построению КИС обусловил создание адекватных организационных структур управления, независимых от заказчика – рыночных предприятий по управлению проектами (PriceWhaterHouse, Accentures и т.д.). В их задачи входит обеспечение стабильного, четкого и низко рискового внедрения информационной системы. Эти качества связывают, прежде всего, с тем, что эти компании накопили большой опыт по созданию таких систем. Включение таких компаний в состав проекта связано, прежде всего, с тем, что позволяет заказчику проекта сосредоточится на решении стратегических задач управления проектом, передав функции по управлению проектами профессиональным менеджерам. Кроме управленческих функций, консультанту передается ряд иных функций. Так для проектов внедрения КИС консультант часто выполняет следующие функции: • Управленческий консалтинг - всестороннее обследование предприятия и выработка оптимальной модели управления o всестороннее детальное предпроектное обследование предприятия o детальная проработка бизнес процессов предприятия с построением функциональной и информационной моделей до уровня функций и операций каждого должностного лица; o рекомендации по оптимизации или реинженирингу бизнес процессов с построением программы и плана перехода от текущего к целевому состоянию; o создание оптимизированной модели предприятия Заказчика; o на основе оптимизированной модели создаются модели оптимальных систем управления предприятием: автоматизации производства, автоматизации продаж, автоматизации маркетинга и сервисной поддержки, документооборота и учета кадров, автоматизации логистики и складского учета, управления взаимоотношениями с клиентами, бюджетирования и учета затрат, управления знаниями, поддержки принятия решений и т.д.; o определение, совместно с Заказчиком, стратегии развития и формирование требований к Информационной Системе предприятия;

14

Управление проектами по внедрению КИС

•

o обучение персонала Заказчика. Технический консалтинг, касающийся внедрения КИС o формализация и документирование требований Заказчика к будущей информационной системе предприятия; o разработка системного проекта с построением дательных функциональных, информационных моделей и подготовкой пакета документации; o анализ существующих систем автоматизации на основании требований Заказчика с целью выбора наиболее подходящей для данной компании системы; o анализ существующей информационной системы предприятия; o определение, совместно с заказчиком, стратегии развития информационной инфраструктуры предприятия, приоритетных направлений и оптимальных планов внедрения новых IT-систем; o предпроектная подготовка, выработка технических требований и подготовка технического задания к разработке Информационной Системы; o техническое проектирование, предваряющее внедрение выбранной системы или разработку новой; o оценка проекта на разных этапах его развития с оформлением заключений по текущему состоянию. o внедрение информационной системы в практическую деятельность предприятий; o обучение специалистов Заказчика

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

15

Управление проектами по внедрению КИС

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

Подбор персонала – стратегический взгляд Очень важно с самого начала привлекать к реализации проекта тех, кто обладает нужными для этого знаниями и качествами. Ошибка здесь чревата не только неприятными последствиями для самого проекта, но и серьезными политическими осложнениями в отношениях с руководством. Менеджер проекта не может ограничиваться только анализом программ управления ресурсами предприятия, ему нужно сразу же разобраться в том, какие интерфейсы понадобятся для работы с ним. В этот процесс следует вовлечь все подразделения, которым придется иметь дело с новой системой. Порой команда разработчиков ERP-проекта поддерживает отношения лишь с теми пользователями и сотрудниками организации, которые принимают в развертывании системы самое непосредственное участие. В таких случаях неизбежно наступает момент, когда становится ясно: в процессе реализации проекта была упущена жизненно важная информация, и произошло это из-за того, что еще на ранней стадии работ к ним не был привлечен нужный человек. И, конечно же, одним из главных вопросов, как и в любом проекте информационных технологий, становится кадровый. Найти хорошего специалиста, особенно с богатым опытом работы в области ERP, очень трудно. Да и включение в команду нового участника, равно как и исключение из нее уже работающего, происходит далеко не безболезненно. Поэтому следует с самого начала выявить тех сотрудников, которые играют ключевую роль в реализации проекта, но не слишком надежно привязаны к вашей организации. Чтобы предотвратить их уход, менеджер проекта должен разработать программу закрепления таких специалистов, которая поможет удержать их в команде. Проекты в области управления ресурсами предприятия могут оказаться долгими и вызвать немало разочарований, и очень полезно создавать благоприятные условия для общения между сотрудниками, открытого обсуждения рабочей обстановки. Помогает в этом и раскрепощение графика работы, предоставление сотрудникам возможности по своему выбору изменять рабочие часы в определенных рамках. Как показали результаты некоторых исследований, введение гибкого рабочего графика значительно повышает производительность труда и вызывает у служащих чувство удовлетворенности условиями работы [10].

16

Управление проектами по внедрению КИС

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

17

Управление проектами по внедрению КИС Однако менеджер проекта должен координировать этот процесс контролировать соответствие конечного продукта проектной документации.

и

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

Менеджер проекта Ключевой фигурой на внедрении КИС является менеджер проекта. Наиболее важным одиночным фактором успеха или провала проекта являются, по-видимому, личные качества его руководителя – знания, навыки, способности и опыт работы. Хороший менеджер проекта должен быть специалистом в области не только бизнеса, но и технологий. Во избежание индивидуальной переделки программных продуктов компаниям зачастую приходится перестраивать свои бизнес-процессы, приспосабливая их к новому программному обеспечению. Поэтому менеджер системы управления ресурсами предприятия должен детально разбираться в том, какое влияние окажет реализация ERP-проекта на бизнес, и поддерживать тесное сотрудничество с руководителями производства. Только так ему удастся плавно перевести операционную бизнес-среду с накатанных рельсов на те пути, по которым она должна развиваться дальше. Менеджер проекта представляет проект клиенту и руководству консультантов, и должен ожидать, что именно он будет нести ответственность за успешное воплощение ожиданий от проекта той и другой стороны. Для достижения этого

18

Управление проектами по внедрению КИС менеджер проекта должен понять бизнес-цели проекта с обеих точек зрения и иметь ясное представление о том, каким образом эти цели могут быть достигнуты. Менеджер проекта ответственен перед лицом, предоставляющим ресурсы консалтинговой компании за эффективное использование этих ресурсов и перед сотрудниками, работающими по проекту, за обеспечение их возможностями личностного развития. Менеджер проекта обязательно столкнется с конфликтом целей обеих сторон, как и других заинтересованных в проекте сторон. Основная обязанность менеджера проекта - урегулирование конфликтов и спорных вопросов, и недопущение их воздействия на ход проекта. Менеджер проекта отвечает за составление плана проекта, обеспечение проекта запланированными ресурсами, контроль и составление отчетов о ходе проекта в соответствии с планом. Он добивается предоставления необходимых для проекта физических ресурсов, набирает сотрудников, при необходимости увольняет их. Он отвечает и за качество результатов проекта и за качество работ, выполняемых в соответствии с планом качества. Менеджер проекта согласовывает с заказчиком область охвата проекта и обеспечивает проведение проекта в согласованных рамках. Он определяет или одобряет всю стратегию, которую группа управления проектом будет использовать для достижения поставленных целей проекта. Менеджер проекта должен быть готовым к тому, что он будет проверять все ключевые документырезультаты, особенно на начальных фазах проекта. Менеджеру проекта нужно быть очень гибким, чтобы быстро реагировать на все изменения в ходе развертывания ERP-системы и не теряться перед постоянно возникающими неприятными сюрпризами. Он должен уметь находить контакт чуть ли не с каждым служащим своей компании, от сугубого технаря ИТ и сменного инженера до почтового служащего и завхоза. Не обойтись ему и без способностей очень быстро осваивать новое, ведь менеджер проекта просто обязан хорошо разбираться в основных проблемах бизнеса даже в тех областях, с которыми ему никогда раньше сталкиваться не приходилось. Менеджер ERP-проекта должен быть и высоко дисциплинированным работником. Ему нужно четко представить себе конечные цели проекта, а затем вывести всю организацию на тот единственный путь, который ведет к успеху. А для этого нужно научиться оперативно, выправлять любые отклонения от главного курса и преодолевать все раздоры, быстро возвращая других участников проекта на путь истинный. Менеджер проекта должен быть всегда готов к принятию трудных решений, понимая при этом, что они могут быть восприняты кое-кем в штыки. Толстокожесть – несомненное достоинство такого руководителя. Подытожив вышесказанное, менеджер проекта должен: • быть очень гибким; • быть дисциплинированным; • уметь быстро овладевать новыми знаниями; • уметь оперативно принимать правильные решения; • обладать опытом работы со средствами управления ресурсами предприятия; • иметь богатый деловой опыт; • быть сильным политиком; • иметь хорошее образование; • нравиться окружающим; • уметь стимулировать работу других сотрудников. (Источник: Gartner Institute) 19

Управление проектами по внедрению КИС

В процессе управления проектом менеджеру приходится решать целый комплекс задач, связанных с: • Детальным планированием работ большого количества людей, участвующих в проекте • Координированием действий поставщиков компонентов системы, внешних и внутренних консультантов и подразделений предприятия • Планированием, выделением и контролем за эффективным использованием необходимых для выполнения проекта ресурсов (временных, финансовых, материальных) • Документированием проекта по внедрению информационной системы • Определением проблем и организацией необходимых мероприятий по их решению • Нахождением компромиссов в подходах к решению задач между сотрудниками, руководством, поставщиками; • Контролем качества выполняемых работ и множество других не менее важных задач. Роль менеджера проектов более оперативна чем роль менеджеров более высокого звена. В ней отсутствует стратегическая составляющая принятия решений. В большинстве случаев менеджер проекта планирует и управляет ресурсами с тем, чтобы в рамках срока и бюджета достичь результатов проекта. В основные обязанности менеджера проекта входят следующие пункты • Получение конечной информационной системы согласно техническим требованиям • Для внешнего менеджера проекта (если он работает на проекте по внедрению КИС со стороны консультанта) – получение прибыли с проекта внедрения КИС • Обеспечение управления командой проекта • Своевременная обратная связь с высшим руководством • Принятие решений для достижений целей проекта Подбор менеджера проекта – практическая сторона Этот вопрос является наиболее сложной частью в сфере принятия стратегических решений. Дело в том, что хороший менеджер проектов на рынке стоит достаточно дорого. Существует три основных способа получить на проект менеджера проекта – воспользоваться услугами сторонней консалтинговой компании, отыскать менеджера на рынке труда или использовать в качестве менеджера проектами сотрудника компании. В случае, если вы решитесь использовать менеджера сторонней компании, то необходимо четко осознавать, что для него достижение целей проекта является целью опосредованной, вытекающей из основной цели – достижения прибыли компании консультанта. Следовательно, существует возможность недобросовестного выполнения проекта. Кроме того, в подчинение менеджера проекта попадают сотрудники компании, что подчас демотивирует их. Это может быть связано с различной корпоративной культурой менеджера проекта и сотрудников предприятия, разным стилем управления. С другой стороны менеджер проекта из консалтинговой компании обладает большим опытом и большим запасом знаний в сфере управления проектами. Кроме того, он всегда может воспользоваться помощью сотрудников своей же компании для решения нестандартных проблем. Менеджер проекта 20

Управление проектами по внедрению КИС консалтинговой компании обычно знает предметную сторону проекта, в нашем случае информационной системы. Кроме того, за действия менеджер проекта несет ответственность компания консультант. Именно по этим причинам использование менеджеров проекта со стороны консультанта стало популярно как в нашей стране, так и за рубежом. Иногда фирмы, внедряющие КИС прибегают к другой тактике – покупке менеджера проекта на рынке труда, например у хедхантинговой компании. Начальные цены на таких специалистов – от 15000 евро, плюс з/п высокого уровня. Данный способ позволяет получить профессионала по внедрению КИС в штат компании и пользоваться его знаниями на всех информационных проектах. Обычно так поступают крупные нефтяные компании и финансовопромышленные группы. Третий вариант – назначение менеджером проекта сотрудника компании. Обычно им выступает директор по информационным технологиям. Один из основных положительных моментов данной стратегии является то, что он обычно хорошо знаком с предприятием, его бизнес процессами, тактикой, стратегией и наконец культурой. Ему проще устанавливать связи в рамках компании, мотивировать персонал, координировать работу функциональных менеджеров, нежели стороннему менеджеру проекта.

Планирование проекта Планирование – это непрерывный процесс определения наилучшего способа действия для достижения целей с учетом складывающейся обстановки [1]. Планирование является наиболее важным процессом на проекте. С ним взаимосвязаны практически все процессы на проекте. начиная от целеполагания, заканчивая процессами контроля и обратной связи. План является моделью действия и прогноз окружения проекта. Так как окружение и внутренняя среда постоянно меняется, то первоначально составленный план приходится постоянно адаптировать в соответствии с этими изменениями. Но если план постоянно меняется, то зачем он нужен? Не проще ли ориентироваться по обстановке и принимать решение по мере возникновения проблем? Дело в том, что для проекта главное не выполнение плана, а достижение целей проекта. Поэтому основное назначение плана – постоянно направлять проект на достижение его цели. В проекте подлежит планированию все, что подлежит учет, контролю и анализу и регулированию. Это в первую очередь планирование функций управления: • предметной областью • стоимостью • временем • качеством • человеческими ресурсами • коммуникациями • рисками Существуют общие подходы к планированию проектов. Они обусловлены типичностью деятельности по управлению проектами, которая направлена на непрерывное решение таких общих вопросов как: • Что необходимо делать? • Кто и что должен делать • Кто с кем взаимодействует

21

Управление проектами по внедрению КИС • • • •

Когда и что должно быть сделано? Как должны распределятся ресурсы? Какое требуется качество? Каковы риски проекта?

Таким образам к общим принципам планирования проектов отнести следующее: • Целенаправленность – планирование рассматривается как процесс развертывания главной цели проекта в совокупность подцелей, задач и работ • Комплексность – означает полный охват научных, проектных, организационных, производственных и других мероприятий и работ, направленных на достижения целей проекта • Сбалансированность по ресурсам. Планы не должны содержать элементов, не обеспеченных ресурсами • Системность – системный подход предполагает учет всего комплекса факторов, влияющих на проект, то есть рассмотрение проекта как целостной структуры с определением взаимосвязей между составляющими • Гибкость – предполагает способность системы прогнозировать и учитывать изменения, как во внешней, так и во внутренней среде. • Многофункциональность – означает планирование по всем функциям управления проектом. • Оптимальность планирования – формирование не просто приемлемые планы, а планы наиболее выгодные по выбранным критериям • Адаптивность – способность отвечать на изменения внешней и внутренней среды проекта • Непротиворечивость плана – то есть обеспечение полной взаимосвязанности и преемственности принимаемых решений Неадекватное планирование часто является причиной неудачи проекта. Очень часто причиной ошибок планирования является широко известная неприязнь технических специалистов к планированию, стремление скрыть свою компетенцию (или ее отсутствие), а так же общая сложность планирования в сложных проектах. В некоторых случаях адекватному планированию мешает чрезмерная сложность используемой методологии планирования. Несмотря на это, создание качественного плана является ключевой задачей управления проектами. Без адекватного плана нельзя вовремя использовать требуемые ресурсы, члены команды не будут оптимально задействованы на проекте, мониторинг и управление могут оказаться неэффективными, так как не будет стартовой точки отсчета. Тейхман и Уайлмон [9] в своем исследовании, где принимали участие 304 менеджера проектов и их руководство из различных компаний США определили ряд проблем, отрицательно сказывающихся на использовании исполнении проекта, а так же предложили некоторые рекомендации по реализации эффективного планирования и исполнения проекта: • Убедиться, что каждый член команды лично отвечает за часть проекта • Совместно с участниками проекта разработать подробный план проекта • Согласовать план со всеми сторонами проекта • Добиться принятия обязательств по проекту от членов команды • Добиться принятия по проекту от руководства • Определить измеряемые контрольные события • Привлекать и удерживать в проекте компетентных сотрудников

22

Управление проектами по внедрению КИС • •

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

Предварительный план проекта по внедрению КИС Предварительный план проекта должен быть подготовлен еще до или во время начальной стадии работы по проекту. Этот план должен определить цели проекта, основные подходы по их достижению и принятую менеджером ответственность за проект. Предварительный план проекта должен охватывать следующие темы: 1. Содержание проекта, 2. Цели проекта 3. Подход к проекту 4. Контрактные требования 5. технические требования внедренной КИС 6. Календарные планы общей детализации 7. Приблизительную оценку требуемых ресурсов 8. Финансовые ограничения 9. Области рисков План должен быть точным. В то же время без обследования предприятия нельзя составить детализированный план проекта. Не зная точно бизнес процессов предприятия нельзя составить точного плана проекта. Именно поэтому при внедрении КИС широко используются предварительные планы проектов. Основа составления этих планов должны быть пожелания руководства предприятия, требования к системе, первичная (общая) оценка предприятия, консультантов на аналогичных предприятиях. Очень часто предварительный план проекта используется как составная часть коммерческого предложения. Он является основой для предварительным анализом проекта и позволяет сказать стоимость проекта. Поэтому крупные консультанты, такие как Accenture, используют предварительное планирование в своей деятельности. Существуют различные подходы к оценке необходимости составления предварительного плана проекта. Неадекватное предварительное планирование может привести к серьезным ошибками в оценке требуемых на проект ресурсов. В тоже время планирование само по себе весьма ресурсоемкая задача, и для составления более детализированного плана проекта требуется обследование предприятия.

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

23

Управление проектами по внедрению КИС необходимо выполнить для достижения этих результатов, — все это и определяет предметную область проекта. Планирование предметной области проекта является сложным, многоэтапным процессом и содержит следующие основные шаги: • определение предметной области проекта — составление документа, утверждающего конфигурацию предметной области проекта как основу для принятия последующих решений • уточнение предметной области проекта — структурная декомпозиция основных результатов на управляемые компоненты для обеспечения лучшего контроля за осуществлением проекта. Разработка предметной области проекта — документальное представление и подтверждение предметной области, которые включают: • обоснование проекта • основные цели и задачи проекта; • критерии и оценки успеха проекта или его частей. Планирование предметной области заключается в разработке документа, определяющего предметную область проекта как базу для будущего принятия решений по проекту, включая критерии оценки успешного завершения проекта или его отдельных фаз. Этот документ является основой для соглашения между командой проекта и заказчиком, фиксирующим цели, планируемые результаты и критерии оценки успеха работы команды проекта. В случае с КИС планом предметной областью проекта будет Дизайн-решение проекта, содержащего следующую информацию Анализ требований. Анализ требований – это первая стадия планирования предметной области проекта. Эта стадия начинается с формирования целей внедрения КИС. Цели эти могут кардинально различаться от проекта к проекту. В соответствии с целями проекта необходимо провести анализ приемлемости проекта. Следует по мере возможности проанализировать ситуацию «до проекта» и «после». Кроме того, стоит взвесить ситуацию «с проектом» и «без проекта». Этот метод позволят взвесить альтернативные издержки проекта безотносительно стоимости самого проекта. Прежде чем принять решение о внедрении КИС, необходимо изучить и проанализировать все аспекты, связанные с этапами жизненного цикла проекта и результатами внедрения: • Технический • Финансовый • Коммерческий • Организационный • Социальный • Экономический Взвесив все «за» и «против» проекта, необходимо приступать к формулировке требований. На этом этапе необходимо определиться с вопросом «Что должна делать будущая система?». Список требований к КИС должен включать: • Совокупность условий, при которых предлагается эксплуатировать будущую систему • Описания выполнения системой функций

24

Управление проектами по внедрению КИС •

Ограничения в процессе разработки (по времени, по бюджету, по ключевым характеристикам). Список требований должен в общих чертах описывать характеристики системы, для того чтобы выбрать среди множества КИС те системы, которые наиболее точно соответствуют предприятию. Этап формирования требований к системе чрезвычайно сложен для неподготовленных менеджеров, не знакомых с КИС, поэтому необходимо поручить эту работу профессионалам. Наиболее эффективный способ – нанять консультантов – специалистов как в предметной области, так и в области внедрения КИС. Только консультанты могут взглянуть на предприятие извне, четко и внятно сформулировав требования на основе анализа структуры предприятия, его сферы деятельности и конъюнктуры рынка. Описание требований. первоначально необходимо формализовать требования, предъявляемые на первом этапе внедрения. То есть необходимо подготовить документ, в котором будет строго и четко сформулированы требования к системе, а также, что немаловажно, форма их выполнения в конкретной системе. Степень детализации такого документа очень высока. В реальной проектной документации зачастую можно увидеть требования/описания к конкретному окну или строке. То есть, если заказчик желает, чтобы «новые, необслуженные заказы были на виду», то в описаниях требования необходимо указать, что «в модуле ЗАКАЗЫ, в таблице ЗАКАЗАНО сортировка должна быть по выполнению, а невыполненные заказы должны выделяться красным цветом» (пример из проектной документации Columbus IT partners) Анализ процессов, документирование решения. Анализ бизнес процессов является ключевой стадией внедрения ERP системы. Здесь на одном из стандартных языков формируется модель бизнес процессов предприятия. Модель представляет собой последовательность конкретных действий работника предприятия для выполнения своей работы. Далее создается модель реализации этого бизнес процесса в информационной системе. Документ анализа бизнес процессов должен включать графическую модель реально существующих процессов, их описание, модель процессов, которые будут использованы в системе (по сути, после реинжиниринга), описание настроек системы для автоматизации этого бизнес процесса. Пример графической реализации модели бизнес процесса представлен ниже2. В данном примере представлен бизнес процесс, пригодный для автоматизации. В текстовом пояснении консультантом, выполнявшим анализ процесса, должны быть указаны все настройки системы, необходимые для реализации этого бизнес процесса в среде. Документ, раскрывающий все характеристики бизнес процессов, называется дизайном решения. Документ должен включать описание моделей и бизнес процессов, стандартной функциональности и модификаций.

2

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

25

Управление проектами по внедрению КИС

Формирование заказа

Начало

Создание нового заказа

Заказы/заказ, шапка нового заказа

Получение информации о заказе

Создание строк заказа по товарам и услугам

Заказы/заказ, новый заказ с финансовой и складской аналитикой

Нужно регистрировать договор?

нет

Выставление счета на предоплату

Нужно корректировать резервирование товаров и услуг

Менеджер по заказм

Счет на предоплату

Да

Коррекция резервирования товаров и услуг

Закупки/закупка Изменение строки закупки

нет

Нужно изменить условия заказ

да

Изменение строк заказ

Клиент нет

Закупки/закупка Изменение строки закупки

Проводка накладной

Заказы/заказы проверка осуществимости отпуска со склада

да

Все количество товара проведено по накладной ?

Анализ взаимоотношений с клиентом

Бухгалтер

Юрист

Конец

Регистрация договра с клиентом

Регистрация платежа от клиента

26

Проводка счета фактуры

Все количество товара проведено счету-фактуре ?

Заказы/заказы проведен счет факура, осуществлен физический и экономический расход товара

Управление проектами по внедрению КИС Техническая инфраструктура На основе дизайна решения формируются требования к технической части системы. Документ по технической инфраструктуре должен включать: • требование к базе данных • системные требования • требования к данным • описание процесса конвертации исторических данных • описание новых полей в интерфейсе Этот документ является руководством для технических специалистов, которые настраивают всю систему предприятия, готовят технологическую базу для внедрения ERP системы. Дизайн проекта Это заключительная стадия проектирования предметной области ERP системы. Ее результатом должен стать документ, который описывает проектную структуру организации, то есть, как и каким образом будут производиться проектные работы на предприятии.

Детализация проекта и конкретных задач. При выполнении многих сложных проектов необходимо использовать организованный, систематизированный подход с целью дальнейшего деления проекта таким образом, чтобы между всеми его элементами были установлены правильные взаимосвязи и чтобы ни один элемент не был пропущен. Если это сделано должным образом, результат окажется весьма полезным во многих отношениях. Наиболее эффективным методом такого деления проекта является создание иерархической структуры проекта (ИСП), также часто называемой иерархической структурой работ (ИСР) [PMI: Work Breakdown Structure] или структурной декомпозицией работ (СДР) [1]. Иерархическая структура проекта (ИСП) - это графическая или словесная модель проекта, раскрывающая его уровень за уровнем до степени детализации, необходимой для эффективного планирования и контроля. ИСП должна включать все промежуточные и конечные продукты (техническая инфраструктура, программное обеспечение) и основные функциональные работы, которые должны быть выполнены для разработки концепции, проектирования, создания, производства, сборки, тестирования и поставки конечного продукта. Иерархическая структура проекта разрабатывается путем разумного комбинирования структуры продукта с процессом его разработки. Термин "продукт" относится здесь к любым созданным в проекте результатам, включая аппаратные средства, программное обеспечение, оборудование, средства, службы, штатные организации, документы, данные и другие реальные результаты проекта. Процесс разработки продукта, обсуждавшийся ранее в этой главе, является серией фаз, задач и операций, через которые организация проходит при создании различных продуктов проекта. Хотя этот процесс развития связывает различные фазы и задачи в хронологическую последовательность, отображение календарных связей не является целью структуры проекта. Они будут идентифицированы на следующей стадии

27

Управление проектами по внедрению КИС планирования, когда будут готовиться базовые планы операций и календарный план проекта. Во время создания ИСП главную роль играет иерархия результатов или продукта, хотя в соответствующих точках отражается и сам процесс разработки продукта. На самом верхнем уровне часто определяются основные фазы процесса развития - прямым указанием на них или через конечные продукты каждой фазы. Например, основным конечным продуктом фазы формирования концепции часто является пакет документов по концептуальному проектированию. Использование ИСП. В процессе иерархического разбиения проекта менеджер проекта, планировщики и ведущие члены команды проекта продумывают все его элементы. Это позволяет ничего не упустить и прояснить содержание работы, отведенной каждому функциональному лидеру проекта. Структура проекта - это способ осмысленной визуализации всего проекта. При ее создании и использовании часто достигается проникновение в суть проекта и взаимосвязей его элементов. Ниже приводится типичная процедура работы с ИСП [10]: • первоначальная структура проекта разрабатывается методом "сверху вниз" совместными усилиями менеджера проекта и планировщиков. Они используют всю необходимую информацию, предоставляемую ключевыми членами команды проекта; • при участии всех менеджеров и членов команды, которых затрагивает структура проекта, она анализируется и при необходимости переделывается до тех пор, пока не будет достигнуто полное согласие по поводу ее корректности; • определяются пакеты работ (задачи), по которым необходимо подготовить планы, оценки, бюджеты, календарные планы и выполнение которых должно контролироваться; • для каждого элемента структуры проекта ("сверху вниз" - на всех уровнях до каждой задачи) указываются: o ответственная и исполняющая организации и функциональные лидеры проекта; o спецификации продукта o основной контракт, контракты с субподрядчиками и основные заказы o оценки и бюджеты ресурсов (сотрудники, фонды, программное и аппаратное обеспечение) и бюджеты; o номера рабочих заданий/нарядов на работы; o номера счетов издержек (только на уровне задач); o контрольные события и относящиеся к ним операции в сетевых планах: методика анализа и оценки проекта или программы (PERT)/метод критического пути (СРМ)/управление данными о продукте (PDM) с запланированными датами; • суммируется информация о ресурсах, указанных в структуре проекта: для каждого элемента и проекта в целом сравниваются оценки, бюджеты, ответственности, расходы и фактическое выполнение; • расходы на текущую дату добавляются к последней оценке до завершения каждой задачи для получения оценки на момент завершения. Подводится итог по иерархической структуре проекта; • оцениваются результаты с целью выявления проблем и выполнения соответствующих корректирующих действий; 28

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

•

•

• • • • • •

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

Традиционные декомпозиции работ обычно имеют три фундаментальных порока. 29

Управление проектами по внедрению КИС 1. Они создаются преждевременно при разработке продукта. 2. Они преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно. 3. Они специфичны для каждого проекта, поэтому их сравнение для разных проектов обычно затруднительно или невозможно. Поэтому в связи со спецификой работ по внедрению КИС применяются эволюционные модели ИСП Эволюционирующие ИСП организуют элементы планирования вокруг схемы процесса, а не вокруг схемы продукта. Такой подход позволяет лучше подстроиться под ожидаемые изменения в постоянно совершенствующемся плане и допускает изменение уровня качества планирования в прямом направлении. Основной рекомендацией относительно ИСП является организация иерархии следующим образом: • Элементами ИСП первого уровня являются рабочие процессы (управление проектом, создание рабочей среды, управление требованиями, проектирование, реализация, оценка и внедрение). Эти элементы обычно закрепляются за одной командой и формируют «анатомию» проекта, которая используется в целях планирования и сравнения с другими проектами. • Элементы второго уровня определяются для каждой стадии жизненного цикла (начальная стадия, уточнение, конструирование и ввод в действие). Эти элементы позволяют естественным образом повышать точность плана параллельно с повышением уровня понимания требований и архитектуры, а также таящихся в них рисков. • Элементы третьего уровня определяются для выделения видов деятельности, в результате которых производятся рабочие продукты каждой стадии. Эти элементы могут либо образовывать самый нижний уровень в иерархии, который позволяет вычислить стоимость отдельного вида рабочих продуктов для данной стадии, либо разбиваться дальше на несколько видов деятельности более низких уровней, которые, взятые вместе, обеспечивают получение одного вида рабочих продуктов. Стандартная ИСП, соответствующая схеме процесса (стадии, рабочие процессы и рабочие продукты), показана ниже3. Эта рекомендуемая структура является примером того, каким образом элементы процесса могут быть сведены в план. Она предлагает схему для оценки затрат и сроков по каждому элементу, их распределения по организации, выполняющей проект, и отслеживания расходов. A. Управление проектом A.a. Управление начальной стадией A.a.a. Разработка бизнес-плана A.a.b. Спецификации версии стадии уточнения A.a.c. Определение основ ИСП стадии уточнения A.a.d. План разработки ПО A.a.e. Контроль и оценка состояния проекта на начальной стадии A.b. Управление стадией уточнения A.b.a. Спецификации версии стадии конструирования , A.b.b. Определение основ ИСП стадии конструирования A.b.c. Контроль и оценка состояния проекта на стадии уточнения 3

Адаптация ИСП из [14]

30

Управление проектами по внедрению КИС

B.

C.

D.

E.

A.c. Управление стадией конструирования A.c.a. Планирование стадии внедрения A.c.b. Определение основ ИСП стадии внедрения A.c.c. Контроль и оценка состояния проекта на стадии конструирования A.d. Управление стадией ввода в действие A.d.a. Планирование следующего поколения A.d.b. Контроль и оценка состояния проекта на стадии ввода в действие Создание рабочей среды B.a. Спецификации среды на начальной стадии B.b. Базовая среда на стадии уточнения B.b.a. Инсталляция и администрирование среды разработки B.b.b. Интеграция среды разработки и настройка инструментов B.b.c. Формирование базы данных запросов на изменение B.c. Сопровождение среды на стадии конструирования B.c.a. Инсталляция и администрирование среды разработки B.c.b. Сопровождение базы данных запросов на изменение B.d. Сопровождение среды на стадии ввода в действие B.d.a. Сопровождение и администрирование среды разработки B.d.b. Сопровождение базы данных запросов на изменение B.d.c. Формирование и передача среды сопровождения Управление требованиями C.a. Разработка требований на начальной стадии C.a.a. Описание концепции C.a.b. Моделирование вариантов использования C.b. Определение основных требований на стадии уточнения C.b.a. Определение основ концепции C.b.b. Моделирование основных вариантов использования C.c.Сопровождение требований на стадии конструирования C.d. Сопровождение требований на стадии ввода в действие Проектирование D.a. Создание архитектурных прототипов на начальной стадии D.b. Определение базовой архитектуры на стадии уточнения D.b.a. Моделирование проекта архитектуры D.b.b. Планирование и проведение демонстрации проекта D.b.c. Описание архитектуры ПО D.c. Моделирование проекта на стадии конструирования D.c.a. Сопровождение модели проекта архитектуры D.c.b. Моделирование компонентов D.d. Сопровождение проекта на стадии ввода в действие Реализация E.a.Создание прототипов компонентов на начальной стадии E.b. Реализация компонентов на стадии уточнения E.b.a. Интеграция для демонстрации кодирования критичных компонентов E.c. Реализация компонентов на стадии конструирования E.c.a. Кодирование компонентов для начальных версий и их автономное тестирование E.c.b. Кодирование компонентов для альфа-версии и их автономное тестирование E.c.c. Кодирование компонентов для бета-версии и их автономное тестирование E.d. Сопровождение компонентов E.e.Сопровождение компонентов на стадии ввода в действие 31

Управление проектами по внедрению КИС F. Оценка F.a. Планирование оценок на начальной стадии F.b. Оценки на стадии уточнения F.b.a. Моделирование тестов F.b.b. Реализация сценариев тестирования архитектуры F.b.c. Оценка демонстрации и описания версии Оценки на стадии конструирования F.b.d. Оценка начальной версии и описание версии F.b.e. Оценка альфа-версии и описание версии F.b.f. Оценка бета-версии и описание версии F.c. Оценки на стадии ввода в действие F.d. Оценка версии продукта и описание версии G. Внедрение G.a. Планирование внедрения на начальной стадии G.b. Планирование внедрения на стадии уточнения G.c. Внедрение на стадии конструирования G.c.a. Определение основ руководства пользователя G.d. Внедрение на стадии ввода в действие G.d.a. Передача продукта пользователю Приведенная структура должна рассматриваться как отправная точка. Ее необходимо подогнать под особенности проекта по многим направлениям. • Масштаб. Более масштабные проекты будут иметь больше уровней и подструктур. • Организационная структура. Проекты, где задействованы субподрядчики или участвует множество различных организаций, могут иметь ограничения, которые приведут к необходимости иного распределения ИСП. • Объем разработок на заказ. В зависимости от характера проекта в рабочих процессах управления требованиями, проектирования и реализации внимание может уделяться разным аспектам. Проект реинжиниринга бизнес-процессов, основанный по большей части на уже существующих компонентах, должен иметь большую глубину детализации требований и не слишком углубляться в проектирование и реализацию. Разработка единственного в своем роде технического приложения, выполняемая полностью на заказ, может потребовать действительно глубокой проработки в части проектирования и реализации, для того чтобы справиться с рисками первого поколения новых компонентов. • Бизнес-контекст. Проекты, выполняемые на контрактной основе, требуют более совершенного управления и оценки. Проекты, в которых разрабатываются коммерческие продукты для продажи широкому кругу потребителей, могут потребовать более совершенных структур для внедрения. Приложение, внедряемое в единственном месте, может обладать как совершенно тривиальным элементом внедрения (например, в случае разработки бизнес-приложения внутри организации), так и хорошо проработанным (например, при переходе от критически важной унаследованной системы с обеспечением параллельной эксплуатации для достижения нулевого времени простоя). • Предшествующий опыт. Очень немногие проекты начинаются с чистого листа. Большинство из них разрабатывается либо как новые поколения унаследованных систем (с устоявшейся ИСП), либо в контексте существующих организационных стандартов (с предопределенным 32

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

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

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

33

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

Календарный план Календарный план призван обеспечить создание всех требуемых продуктов, оговоренных в контракте или других требованиях - включая аппаратные средства и программное обеспечение, а также относящихся к ним вспомогательных элементов. Как правило, существуют два уровня планирования расписания: уровень проекта и уровень задач. Календарный план уровня проекта объединяет все задачи, все связующие и ключевые события. В очень крупных проектах могут потребоваться календарные планы и бюджеты промежуточного уровня, но они рассматриваются как расширения или подразделы укрупненного календарного плана всего проекта. При управлении проектами могут оказаться полезными многие типы календарных планов. Менеджер проекта и функциональные лидеры проекта должны проанализировать данный список, чтобы выбрать типы календарных планов, которые потребуются для каждого отдельного проекта: 1. Укрупненный календарный план проекта (календарный поэтапный мастер-план). Календарный план основных ключевых событий (контрольных точек). 2. Укрупненный календарный план инженерно-конструкторских работ. 3. Укрупненный календарный план производственных работ. 4. Укрупненные календарные планы второго и последующих уровней иерархической структуры проекта (ИСП) 5. Календарный план ближайших ключевых событий (контрольных точек). 6. Диаграммы трендов проекта (тренды по стоимостям и выполнению контрольных точек). 7. Сетевой план проекта (PERT) - логическая диаграмма управления, сетевая диаграмма. Календарные планы по задачам. 8. Календарные планы по функциональным элементам. 9. Один или несколько подробных сетевых планов (диаграмм) PERT. 10.Календарные планы создания основного продукта. 11.Календарный план эксплуатации аппаратных средств. 12.Календарные планы доставки элементов аппаратных средств. 13.Календарные планы субподрядов, заключаемых до оплаты контракта. 14.Предоставленные субподрядчиком календарные планы инженернотехнических работ, производства и поставок/сетевые планы (диаграммы) PERT. 15.Календарный план выпуска схем, чертежей. 16.Календарные планы проведения обзоров состояния проекта, требуемых контрактами. 17.Календарный план использования имущества, предоставленного государственными органами или заказчиком. 18.Календарный план предоставления данных государственным органам или заказчику. Календарный план поставки оборудования для обучения и аппаратных средств для демонстрации технического обслуживания. 19.Календарный план выпуска технических публикаций.

34

Управление проектами по внедрению КИС 20.Календарный план испытаний материалов. 21.Календарный план выполнения требований контракта. 22.Календарные планы демонстраций системы. Укрупненный календарный план Укрупненный календарный план - это расписание исполнения проекта, включающее лишь основные этапы и ключевые события. Укрупненный календарный план представляет все элементы и задачи проекта на единой временной шкале. Он должен: • основываться на ИСП • быть полным и охватывать все содержание проекта • отражать условия контракта и обязательства перед заказчиком; • помогать в планировании и эффективном использовании человеческих и других ресурсов • включать основные связующие и ключевые события, которые соединяют все задачи • помогать в оценке хода работ и составлении управленческой отчетности Укрупненный календарный план (мастер-план) проекта первоначально формируется на фазе подготовки предложения (или эквивалентной фазе) и непрерывно уточняется по мере развития проекта. В ходе разработки календарных планов и бюджетов задач календарный мастер-план создается "сверху вниз" и "снизу вверх" усилиями менеджера проекта и планировщиков в сотрудничестве с функциональными руководителями проекта. В начале проекта необходимо предусмотреть резерв календарного плана, то есть установить запланированную дату завершения с некоторым разумным опережением относительно критической даты выполнения обязательств. Это время представляет собой резерв на случай возникновения непредвиденных обстоятельств, и менеджер проекта должен тщательно управлять им, если при выполнении отдельных задач намечаются непредвиденные задержки, влияющие на критический путь проекта. Резерв по календарному плану аналогичен резерву бюджета, который обсуждается ниже. Календарный мастер-план проекта может быть оформлен в виде линейной диаграммы, диаграммы с выбранными связующими и контрольными событиями или привязанного к временной шкале сетевого плана (диаграммы) PERT. В последнем случае он обычно представлен как диаграмма с выбранными связующими и контрольными событиями, а также с отображением логических зависимостей между событиями. Ниже приведены примеры объемно-календарных планов по проекту разработки информационной системы.

35

Управление проектами по внедрению КИС

Task Name Scope Determine project scope

May 2003 June 2003 July 2003 Duration 12 15 18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14 17 20 23 26 29 02 05 08 11 14 17 20 23 3,5 days Management 4 hrs

Secure project sponsorship

1 day

Define preliminary resources

1 day

Secure core resources

1 day

Scope complete Analysis/Software Requirements

0 days 5 days

Draft preliminary software specifi

3 days

Develop preliminary budget

2 days

Review software specifications/b

4 hrs

Incorporate feedback on software

1 day

Develop delivery timeline

1 day

Obtain approvals to proceed (con

4 hrs

Analysis complete Design

Project Manager Project Manager 06.05

14 days

Conduct needs analysis

Secure required resources

Management

Analyst Analyst Project Manager Project Manager;Analyst Analyst Project Manager Management;Project Manager Project Manager

1 day

26.05

0 days 14,5 days

Review preliminary software spe

2 days

Develop functional specifications

5 days

Develop prototype based on func

4 days

Review functional specifications

2 days

Analyst Analyst Analyst Management

Incorporate feedback into functio

1 day

Management

Obtain approval to proceed

4 hrs

Management;Project Manager

Design complete Development Review functional specifications

1 day

Identify modular/tiered design pa

1 day

Assign development staff

1 day

Develop code

15 days

Developer testing (primary debug

15 days

Development complete Testing

13.06

0 days 21,75 days

Developer Developer Developer Developer Developer 15.07

0 days 48,75 days

36

Управление проектами по внедрению КИС

Sunday

Monday 27

Tuesday

Wednesday

28

29

Thursday 30

Friday 02

Determine p Secure project sponsorsh

04

05

Define preliminary resources; 1 day

Saturday

01

03

Define preliminary resources; 1 day

06

07

08

09

10

13

14

15

16

17

Secure core resources; 1 Scope complete

11

12

Draft preliminary software specifications; 3 days

18

19

Develop preliminary budget; 2 days

25

26

20

21

Review so

Incorporate feedback on

27

28

Develop preliminary budget; 2 days

22

23

Develop delivery timeline Obtain appr

Secure required resources; 1 day

29

Secure required resources; 1 day

24

30

31

Develop functional specifications; 5 days

Analysis complete 01

02

03

04

Develop functional specifications; 5 days

08

09

Develop prototype based on functional specifications; 4 days

05

06

07

Develop prototype based on functional specifications; 4 days

10

11

Review functional specifications; 2 days

12

13

Incorporate feedback into Obtain app Design complete

37

14

Управление проектами по внедрению КИС При разработках календарных планов используются следующие методы Метод критического пути При этом методе используется математический анализ, который позволяет вычислить ранние и поздние даты начала и окончания работ по внедрению без учета ограничений на ресурсы, а также резервы — промежутки времени, на которые можно отодвинуть выполнение работы без нарушения ограничений и даты завершения проекта, вычисляет единственное детерминированное расписание проекта и использует заданные единственные оценки продолжительности работ проекта. Метод PERT Использует последовательную сетевую логику и средневзвешенные оценки продолжительности работ для вычисления продолжительности всего проекта. Сегодня метод PERT используется редко, несмотря на то, что оценки продолжительности работ, часто основанные на PERT, используются в вычислениях методом МКП. Метод GERT Позволяет проводить вероятностную обработку, как сетевой логики, так и оценок продолжительности работ. При этом учитываются следующие различные ситуации: одни работы могут вообще не выполняться, другие — выполняться частично, а третьи выполняются несколько раз. Метод сжатие Математический анализ, который сокращает продолжительность выполнения проекта без изменения его предметной области. Для этого определяется ускоренный путь — выполнение параллельно тех работ, которые обычно производились бы последовательно. Ускоренный путь часто приводит к необходимости переделок и повышает риски. Метод сглаживания Метод «Сглаживание» применяют в тех случаях, когда заданы жесткие ограничения на сроки завершения работ и требуется оптимизировать некоторый показатель качества использования ресурсов, например минимум превышения требуемых ресурсов над заданным уровнем их наличия. Общая идея алгоритмов типа «Сглаживание» заключается в следующем. Строят некоторый базисный план (по ранним или поздним допустимым срокам, реже произвольный, допустимый по времени и технологии план), а затем в пределах имеющихся резервов времени по установленным постоянным или изменяемым в процессе вычислений приоритетным правилам варьируют положение работ на оси времени или (и) интенсивность их выполнения до тех пор, пока не будет достигнут алгоритмический оптимум показателя использования ресурса или не найден практически приемлемый «сглаженный» график потребления ресурсов. Алгоритм Калибровка Алгоритм типа «Калибровка» обычно минимизирует сроки или продолжительность выполнения комплекса работ. Идея этого метода заключается в том, что на очередной планируемый отрезок времени (смена, неделя, декада и т.д.) ставятся «на обслуживание» и наделяются необходимыми ресурсами работы в соответствии с принятым приоритетом. Например, в таком порядке: начатые ранее работы, работы критического пути, 38

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

Бюджет проекта. Планирование стоимости. Оценка и планирование стоимости в проекте предназначено для обеспечения выполнения проекта в рамках установленного бюджет. Рассмотрим следующие основные его этапы: Определение ресурсов — расчет потребности в ресурсах, необходимых для успешного внедрения КИС. Оценка стоимости — определение стоимости трудозатрат и ресурсов, необходимых для выполнения работ проекта. Разработка бюджета проекта — распределение предполагаемых затрат в соответствии со сроками внедрения. Управление стоимостью проекта связано в первую очередь с затратами на ресурсы, необходимые для выполнения проекта. Управление стоимостью в проекте должно также рассматривать и учитывать все дополнительные расходы в проекте: затраты на отдельные поручения, вознаграждения и др. После составления расписания работ внедрения можно построить графики потребности в ресурсах, необходимых для выполнения работ проекта. Объемные и временные характеристики потребления ресурсов используются для определения стоимости проекта. Для определения полной стоимости проекта необходимо учесть все используемые в нем ресурсы: • программное обеспечение (среды разработок, лицензии на систему) • трудовые ресурсы (заработная плата, расходы на поиск персонала..) • денежные средства на дополнительные расходы. • офисные расходы • расходы субподряда • рисковые резервы Соответственно необходимо составить ряд бюджетов проекта Бюджет проекта эквивалентен смете текущих затрат организационной единицы. Основное различие состоит в том, что он охватывает весь проект от начала до завершения, между тем как бюджет организационной единицы составляется ежегодно. Для более эффективного контроля бюджет проекта должен подразделяться на две части: бюджет прямых и бюджет косвенных затрат. Бюджет прямых затрат - основное средство контроля и управления для менеджера проекта и участвующих в проекте руководителей функциональных подразделений. Сюда включаются затраты (заработная плата, транспортные расходы и т.д.) всех членов команды проекта, выполняющих отдельные задачи, а также: • стоимость лицензии • стандартная стоимость настройки и программирования; • стоимость технологических отклонений; • стоимость инженерно-программистских работ; 39

Управление проектами по внедрению КИС • • •

стоимость установки (внедрения или ввода в эксплуатацию); стоимость поставок; другие прямые затраты.

Бюджет косвенных затрат проекта включает в себя расходы на гарантийное обслуживание и штрафы, экспертизы НИОКР, услуги и комиссионные сборы, затраты на финансовые операции, маркетинг, общие административные и инвентаризационные затраты и т.д. Бюджет косвенных затрат устанавливается для всего проекта без разбиения на конкретные задачи. При необходимости, чтобы облегчить планирование привлечения фондов в подразделений достигают взаимоприемлемых оценок стоимости и бюджетов по каждой задаче. После того, как будут составлены все бюджеты проекта, необходимо составить план финансирования проекта. Этот план основан на анализе финансовых потоков бюджета проекта и укрупненного календарного плана проекта с целью определения уровня ежемесячных расходов и установки соответствующих требований по финансированию. Менеджер проекта при помощи и с одобрения финансового контролера (если такая роль есть на проекте) определяет источники финансирования на протяжении всего жизненного цикла проекта, основываясь на условиях оплаты по контрактам, соответствующих описаниях научно-исследовательских работ и запросах на авторизацию проекта. План финансирования проекта будет, таким образом, показывать оборотные или инвестированные средства, требуемые ежемесячно или ежеквартально от источника финансирования для обеспечения выполнения проекта. План финансирования должен определять размер затрат за рамками бюджета, при которых исполнение проекта следует прекратить досрочно. Во время разработки укрупненного календарного мастер-плана и бюджета проекта следует сформировать план счетов проекта, необходимый для авторизации работ, учета расходов и контроля стоимости . Проанализировав матрицы задач и ответственности, менеджер проекта, бухгалтер проекта, администратор контрактов и контролер проекта, работающие с руководителями соответствующих функциональных подразделений, могут установить план счетов проекта таким образом, чтобы выполнить все требования бухгалтерского учета и отчетности. Ниже приводятся некоторые важные соображения: • каждой задаче (или пакету работ), для которой необходимо составить календарный план, бюджет и которую необходимо контролировать, следует присвоить уникальный номер счета для учета затрат в корпоративном плане счетов; • суммирование по элементам структуры проекта необязательно должно выполняться системой бухгалтерского учета. Другими словами, план счетов проекта и присвоенные им бухгалтерские номера счетов не обязаны отражать структуру проекта, хотя это желательно; • суммирование по элементам структуры проекта можно осуществлять вручную или с применением программ электронной обработки данных вне основной системы учета себестоимости, но с использованием данных, полученных и контролируемых системой бухгалтерского учета; • необходимо поддерживать разумный баланс между более совершенным контролем (который обеспечивается большим количеством счетов затрат) и дополнительной стоимостью и административными накладными расходами, возникающими в результате возрастания количества этих счетов.

40

Управление проектами по внедрению КИС

Архив проекта Архив проекта - это обычный комплект документов, отражающих все аспекты проекта. Его цель - обеспечить, чтобы вся необходимая информация по любому вопросу, относящемуся к проекту, была постоянно доступна менеджеру проекта и другим его участникам. Это важно по ряду причин: • если в ходе исполнения работ меняется менеджер проекта (или ключевой член команды), архив проекта оказывает помощь в быстрой и необременительной передаче дел • если возникают судебные разбирательства или есть угроза их возникновения, архив проекта предоставляет жизненно важную информацию, которую при его отсутствии было бы невозможно собрать • если позднее выполняется подобный проект, данные архива проекта можно использовать для подготовки предложения, калькуляции цен и управленческого планирования • по завершении проекта аудит поможет выявить сильные и слабые стороны проекта Содержание архива проекта по внедрению КИС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

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

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

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

Документирование Процесс документирования начинается с материалов, созданных в начале проекта. Используя подробную документацию проекта, документировщики разрабатывают пользовательские и технические материалы, соответствующие проводимому внедрению. 51

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

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

52

Управление проектами по внедрению КИС

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

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

Обучение В процессе обучения подготавливаются пользователи и администраторы к выполнению задач по работе с новой прикладной системой. Сюда включается разработка материалов и методов. Преподаватели и разработчики курсов ориентируют свои материалы на роли и должностные обязанности, а не на модули приложений. AIM делает различие между теоретическими и практическими занятиями. Теоретические занятия обеспечивают понимание основ функций бизнеса в конкретной среде, практические занятия направлены на продукты Oracle и получение навыков работы с ними.

Переход к промышленной эксплуатации Процесс перехода к промышленной эксплуатации переводит компанию, систему и людей на новую систему предприятия. Данный процесс контролирует и обновляет систему эксплуатации и проводит планирование на будущее. 53

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

Определение Во время фазы определения панируется проект, проверяются бизнес-задачи организации и проводится оценку целесообразности выполнения этих задач на основе ограничений времени, ресурсов и денежных средств. Делается акцент на создание выполнимого рабочего плана и ознакомление с принципами работы организации на достижение общих целей. Определение области охвата на раннем этапе процесса внедрения дает группе проекта эффективный способ коммуникации. Стратегия, задачи и подходы определяются для каждого процесса AIM, обеспечивая основу для плана проекта. Чтобы понять текущие бизнес-операции, во время этой фазы группа проводит моделирование процессов. Целью является определить бизнес-требования и требования к системе, предложить будущую бизнес-модель и определить текущую архитектуру приложения и информационной технологии. Собранная информация обеспечивает входные данные для действий во время выполнения последующих фаз. Группа проверяет финансовые, операционные, технические и административные процессы, чтобы определить, что все понимают и согласны с детальными бизнес-требованиями. Все бизнес-требования связаны с планированием будущих бизнес-процессов. Четкое понимание этих требований является критическим фактором успеха для проекта.

Анализ операций Во время фазы анализа операций группа проекта разрабатывает сценарии бизнес-требований, основанные на результатах фазы определения, которые затем используются для оценки уровня соответствия бизнес-требований и стандартной функциональности приложений. Выявляются разрывы и разрабатываются соответствующие решения. В результате проведения анализа создается предложение для выполнения на основе предполагаемой технической архитектуры приложений. Создается модель архитектуры приложений и проектируется техническая архитектура. В техническую архитектуру включены высокоуровневое аппаратное и программное обеспечение и компоненты коммуникация, предназначенные для поддержки будущей бизнес-системы. Документы по создания технической архитектуры используются для разработки детального проекта во время фазы технического проектирования. Чтобы разработать модели будущих бизнес-операций, вы должны определить начальные допущения по разрывам. Решения могут потребовать внесения 54

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

Техническое проектирование Целью фазы технического проектирования является разработка детального проекта оптимальных решений, которые будут соответствовать будущим бизнес-требованиям. В течение этой фазы сотрудники группы проекта создают детальные описания решений по процессам, разработанных во время фазы анализа операций. При поддержке бизнес-требований может потребоваться программирование расширений приложений до стандартных характеристик, а несколько альтернативных решений могли быть определены во время фазы анализа операций. Группа проекта тщательно исследует эти решения и выбирает из них наиболее рентабельное. Чтобы спроектировать эффективные бизнес-решения, вам необходимо проверить эффективность запланированных ролей пользователей и процедур. При проектировании решений, рассмотрите организационные изменения, усовершенствование процессов и реорганизацию инициатив. Эти инициативы часто влияют на использование характеристик приложений. Во время завершения работ над проектом решения техническая архитектура начинает принимать форму. Технический персонал проектирует техническую архитектуру, которая может поддерживать стандартную конфигурацию приложений и пользовательские решения, и рассматривает будущие потребности архитектуры системы компании. Технический персонал проектирует также программы тестирования производительности и среды для проведения этих тестов. Как только созданы решения по бизнес-требованиям, вы начинаете разрабатывать рабочую документацию. По мере обновления системы, документация также обновляется. Проектирование бизнес-процессов является повторяющейся процедурой. Задачи, охватывающие как фазу анализа операций, так и фазу технического проектирования, могут выполняться как отдельная часть работы. Например, создание модели бизнес-процессов, отбор детальных требований из этой модели, их отображение на приложения, документирование пробелов и обходных путей и регистрация предлагаемого решения по установке приложений будут являться единым целым для групп проектирования/отображения.

55

Управление проектами по внедрению КИС

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

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

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

Управление проектами по внедрению КИС

Заключение Необходимо отметить, что ключевая часть проекта – это собственно работа на проекте. А методология управления проектами – это лишь надстройка над процессами внедрения, позволяющая постоянно контролировать проект и добиваться достижения целей. Приведенная методология не является единственно верной. Она лишь описывает основные идеи управления проектами по внедрению КИС и является проекцией универсальных стандартов и методологий PMI на подобные проекты. Также приведенная методология не претендует на звание универсальной. Каждый проект уникален, и управлять им необходимо соответственным образом. Методология требует адаптации под конкретную ситуацию. В то же время она является квинтэссенцией методологий таких компаний как SAP, Oracle, Columbus и Accentures. Приведенные в данной работе идеи прослеживаются во всех теоретических работах по управлению IT проектами, а также в реальной проектной документации. В заключении хотел бы отметить, что управление проектами находится на стыке различных отраслей знаний и сродни искусству. Методология управления проектами – это каноны этого искусства. Данная тема была интересна мне по причине своей перспективности. Научный подход к внедрению КИС является новым направлением деятельности компаний, стремящихся динамично развиваться, укреплять свои позиции на рынках. Поэтому специалисты по управлению инновационными проектами (в том числе проектами по внедрению КИС) востребованы рынком. Основной проблемой, с которой пришлось столкнуться при изысканиях, стало отсутствие открытых источников информации. В связи с этим пришлось изучать иностранные источники, интернет. Кроме того, в данной работе мною учтен личный опыт, полученный в ходе работы над проектами внедрения SAP R/3 в компании ТНК, разработке информационных интернет ресурсов различных компаний, а также сайта кафедры экономической информатики МГУ им. Ломоносова. Идеи, изложенные в дипломной работе, находят свое практическое воплощение: так, например, объемно-календарное планирование и составление бюджетных планов используется мною в ходе работы в компании L’Oréal.

57

Управление проектами по внедрению КИС

Литература 1. Государственный университет управления. Модульная программа для менеджеров. «Управление программами и проектами» Инфра-М 2000 2. «Основы менеджмента», Майкл Мескон, Москва, ИД Дело 1999 3. «Жизненный цикл информационных систем». Григорий Ефимов 4. Взаимоотношения "клиент - консультант" Экономика и Время No 30(267), 5. Проектный офис Майк Ньюэлл // Журнал "Директор ИС", #01, 2002 год Издательство "Открытые Системы" (www.osp.ru) Постоянный адрес статьи: http://www.osp.ru/cio/2002/01/044.htm 6. «Управление ИТ проектами» Шарова Елена Степановна Консультант АОЗТ "Супремум" Профессиональный проектный менеджер (уровень D) http://www.cfin.ru/management/practice/supremum2002/03.shtml 7. Материалы сайта http://projectm.narod.ru/content.htm 8. «Управление проектами ERP - ключ к успеху их реализации» Чарльз Треппер 18.02.2003 Планета КИС 9. “Criteria for Controlling Projects According to plan”, Thnhain Hans J., Wilemon David L., Project management journal, PMI, June 1986 10. «Управление высокотехнологичными программами и проектами» Рассел Д. Арчибальд Москва 2002. Структурная 11.http://www.pmsoft.ru/doc/THEORY/PUB/WBS.ASP декомпозиция работ. Автор не известен. На основе PMBOOK 12.http://www.pmsoft.ru/sTheory.asp 13.«Бизнес-моделирование для внедрения ИСУ предприятия». Дмитрий Слиньков, [email protected]. Директор по маркетингу и продажам компании КОРУС Консалтинг. Статья опубликована в журнале «Директору информационной службы» 14.«Software project management – A Unified Framework» Walker Royce 1998 15.«Автоматизация управления предприятием».В.В. Баронов, Г.Н. Калянов, Ю.И. Попов, А.И. Рыбников, И.Н. Титовский. АйТи М- 2000 16.Курс лекций Е. Егорова (Columbus IT partner). Управление проектами 17.Материалы с сайта «Корпоративные финансы» (www.cfin.ru) 18.Материалы с сайта «E-Commerce» (www.e-commerce.ru) 19.Компьютерра от 8 ноября 2001 года (419 номер) 20.Журнал PCWeek. Электронная версия. 21.Проектная документация SAP 22.Методология управления проектами Oracle 23.Глоссарий PMI (www.pmi.ru) 24.Материалы с сайта Корпоративные финансы (www.cfin.ru)

58