Управление проектами по внедрению корпоративной информационной систем - Казаков И.В

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

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

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

Проектирование и программирование модулей

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

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

Преобразование данных

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

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

Документирование

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

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.«Бизнес-моделирование для внедрения ИСУ предприятия». Дмитрий Слиньков, DSlinkov@kopyc.ru. Директор по маркетингу и продажам компании КОРУС Консалтинг. Статья опубликована в журнале «Директору информационной службы»

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