Крупные поставщики программного обеспечения класса ERP, такие как SAP и Oracle, а также ведущие фирмы-консультанты разработали стан­дартные методики внедрения систем данного класса.

Цель каждой из та­ких методик — снижение затрат на проект и связанных с ним рисков на основе предыдущего опыта внедрения аналогичных систем. Это достига­ется за счет наличия:

· шаблона плана работ. Как правило, речь идет о так называемой «кар­те маршрута» (roadmap). В ней в иерархической форме описан на­иболее полный из возможных перечней работ по внедрению данной системы. Реальный план работ создается посредством исключения не­нужных шагов из «карты маршрута». За счет этого резко снижается риск пропуска тех или иных необходимых работ в плане проекта; данных по трудоемкости работ с учетом реального объема проекта. Эта информация позволяет рассчитывать сроки и стоимость работ при составлении плана и бюджета проекта исходя из выделенных на проект ресурсов предприятия;

· шаблонов организационных структур проекта. В результате снижается риск построения неверной организационной структуры и упрощается обос­нование выбора той или иной организационной структуры перед руко­водством предприятия;

· шаблонов проектной документации. Шаблон включает в себя требо­вания к содержанию документа и общий механизм его согласования и утверждения. Конкретная схема согласования определяется путем наложения на этот шаблон организационной структуры конкретного предприятия;

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

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

Рассмотрим в качестве примера методику ASAP фирмы SAP AG по внедрению системы R/3. За основу описания возьмем маршрутную кар­ту данной методики.

Этап 1. Подготовка проекта. На этом этапе формируются стандарты проекта, руководящие органы проекта и проектная команда. Исходный пункт — принятие руководством предприятия решения о внедрении сис­темы SAP R/3 и подписание пакета договоров с поставщиком програм­много обеспечения и консультантом по проекту внедрения. Подготавли­ваемые проектные документы:

· устав проекта, определяющий руководящие органы проекта, правила взаимодействия сотрудников предприятия и консультантов в проект­ной группе, сферы ответственности проектной команды в целом и от­дельных ее органов;

· объем проекта, определяющий перечень организационных единиц (дочерних предприятий, филиалов, подразделений) предприятия, затро­нутых проектом, и виды внедряемой функциональности R/3 (бухгал­терия, финансы, закупки, сбыт и т.д.);

· обобщенный план проекта — сформированный на основании марш­рутной карты ASAP перечень мероприятий проекта с указанием сро­ков выполнения работ и ответственных лиц. Данный план подлежит уточнению на последующих стадиях проекта;

· бюджет проекта, составленный на основе обобщенного плана работ. Также может корректироваться в ходе выполнения проекта;

· положение о проектной группе, определяющее ее состав, роли отде­льных ее участников, условия участия сотрудников предприятия в про­ектной группе;

· стандарты всех основных видов деятельности проекта' (документация, тестирование, управление системой, безопасность и т.д.);

· стандарты учета затрат в проекте, связывающие шаги плана проек­та с определенными сервисами (подробно методика учета затрат будет описана ниже);

· системный ландшафт, то есть план создания отдельных копий систе­мы, в которых ведется разработка и тестирование системы, а также регламент переноса данных между этими копиями.

Подготовленный пакет документов вводится в действие приказом ру­ководителя предприятия. Типовым руководящим органом проекта явля­ется Управляющий совет, включающий спонсора проекта (это топ-ме­неджер предприятия, поддерживающий проект со стороны руководства и координирующий работу проектной группы), руководителя проекта, представителей подразделений и дочерних предприятий, участвующих в проекте, представителей консультанта и представителя SAP AG, от­ветственного за контроль качества проектных решений. Общее требова­ние к составу Управляющего совета таково: он должен быть достаточно представителен, чтобы принятые на его заседаниях решения были обя­зательны для всех структур, участвующих в проекте. (Далее мы будем называть высший орган управления проектом Управляющим советом.) Этой же цели — повышению статуса проекта — служит его утверждение приказом руководителя предприятия. Издание такого приказа с прила­гаемым к нему пакетом документов завершает фазу подготовки проекта.

Особняком стоит проблема организации системного ландшафта. Ме­тодика ASAP требует как минимум трех независимых друг от друга копий системы R/З — для разработки, для тестирования, для промышленной эксплуатации (в терминах компании SAP — продуктивной эксплуата­ции). Эти копии называются средой разработки, средой тестирований и продуктивной средой соответственно. Копии должны быть полностью изолированы друг от друга, фирма SAP рекомендует размещать их на различных серверах. Перенос данных между копиями должен быть стро­го регламентирован: в противном случае недостаточно протестирован­ные данные из среды разработки или среды тестирования могут попасть в продуктивную среду и привести к сбоям в работе действующих серви­сов ИТ. Таким образом, технические риски проекта во многом зависят от того, насколько верно спроектирован системный ландшафт.

Непосредственный риск остановки проекта на этой фазе весьма неве­лик. Однако именно на ней могут быть заложены или исключены основ­ные факторы данного риска. К ним относятся:

· достаточность ресурсного обеспечения проекта. Положение о проект­ной группе должно зафиксировать необходимый состав ее участников и распределение ролей между ними, а устав проекта должен устано­вить ответственность руководителей подразделений за отвлечение вы­деленных сотрудников от работ по проекту;

· вовлечение в проект топ-менеджеров и руководителей среднего звена. Определение объема проекта должно включать в себя не только оцен­ку денежного потока, но и выявление руководителей, интересам кото­рых отвечает проект;

· составление реалистичного предварительного плана проекта и уста­новление процедуры его пересмотра. На основании объема проекта разрабатываются его предварительный план и бюджет, а устав проек­та фиксирует процедуру корректировки плана и бюджета на последу­ющих стадиях проекта;

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

· грамотное проектирование системного ландшафта с точки зрения как аппаратных и программных ресурсов, так и регламента переноса дан­ных из одной среды в другую.

Этап 2. Концептуальное проектирование. К задачам данного этапа относятся разработка и утверждение модели бизнес-процессов, реали­зуемой в проекте. Модель должна учитывать как требования конечных пользователей, так и возможности самой системы, вследствие чего неиз­бежно представляет собой компромисс. Исходный пункт — приказ руко­водителя предприятия о ведении работ по проекту (см. выше). Конечный пункт — утверждение концептуального проекта Управляющим советом. Основные проектные документы, подготавливаемые на данном этапе, — это:

· концептуальный проект системы;

· настроенные в системе прототипы бизнес-процессов;

· уточненный объем проекта;

· уточненный план проекта.

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

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

С этапом концепту­ального проектирования связаны риски:

· риск отсутствия утвержденного концептуального проекта (основной риск данного этапа);

· риск неполной процедуры согласования, оставляющей место для двой­ственного толкования концептуального проекта в будущем;

· риск излишнего объема пользовательских разработок в системе;

· риск остановки проекта, например, в связи с отсутствием концепту­ального проекта в запланированные сроки.

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

Под настройкой понимаются все работы по адаптации системы к дан­ному предприятию, включая изменение параметров системы, програм­мирование, разработку формуляров^[26] и т.д. Формирование необходимых справочников включает в себя подготовку исходных данных справочников, программирование автоматической загрузки данных в систему, тестиро­вание справочников, разработку и утверждение регламентов их ведения. Под локальным тестированием понимается тестирование настроенных операций и бизнес-процессов в целом на соответствие концептуальному проекту. Протокол тестирования бизнес-процесса утверждается вла­дельцем соответствующего бизнес-процессов2. Интегральное тести­рование — это тестирование всей совокупности настроенных бизнес-процессов, справочников, пользовательских программ и отчетов и т.д. Протокол интегрального теста утверждается Управляющим советом проекта. Утверждение протокола интегрального теста представляет ко­нечный пункт данного этапа. Настройка и программирование системы ведутся посредством так называемых циклов разработки. Цикл разработки состоит в том, что в системе полностью настраивается определенная ветвь (или несколь­ко ветвей) целевой модели бизнес-процесса. Каждый цикл разработки завершается локальным тестом выполненных работ. Циклы разработ­ки ведутся последовательно, от более вероятных ветвей бизнес-про­цесса к менее вероятным. В этом смысле первым, точнее, нулевым цик­лом разработки является настройка прототипа на этапе концептуального проектирования. Все циклы разработки выполняются в среде разработ­ки. Для интегрального теста все настройки и данные переносятся в сре­ду тестирования.

Для этапа разработки характерны следующие основные риски:

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

· риск остановки проекта в связи с невыполнением запланированных сроков. Фаза реализации требует согласования многих направлений деятельности — настройки и программирования, администрирования и других системных работ, подготовки справочников, тестирования и т.д. Соответственно, при недостаточной подготовленности менедже­ра проекта и проектной группы в целом сроки работ могут быть не вы­полнены.

Этап 4. Заключительная подготовка. На данном этапе настроенная и протестированная система переносится в продуктивную среду. Далее производится тестирование устойчивости системы при штатных и не­штатных ситуациях. Работоспособность системы при большой нагруз­ке в штатном режиме работы проверяется объем-тестом, работоспособ­ность в нештатных ситуациях — стресс-тестом.

Объем-тест состоит в моделировании максимальной нагрузки на систему — исполнении объемных отчетов при одновременной работе большого числа пользователей. В этих условиях бизнес-пользователи оценивают соответствие производительности системы требованиям кон­цептуального проекта. Если производительность неудовлетворительна, проводятся работы по оптимизации быстродействия системы; при не­достаточных результатах требуемое быстродействие достигается путем изменения настроек и программ. Стресс-тест оценивает устойчивость сервисов при отказе того или иного оборудования — систем хранения данных, серверов, принтеров и т.д. Тестируются быстродействие резерв­ного оборудования и соответствие времени простоя системы при отказе согласованным в концептуальном проекте параметрам.

На том же этапе проводятся разработка пользовательской документа­ции и обучение конечных пользователей работе в системе. Параллельно на основании рабочих материалов проектной группы готовятся техничес­кое описание и технические инструкции, необходимые для сопровожде­ния системы на этапе эксплуатации. Исходный пункт данного этапа — утверждение Управляющим советом протокола интегрального теста; конечный пункт — издание приказа о начале промышленной эксплуата­ции системы R/3. После этого начинается этап 5 — промышленная экс­плуатация системы.

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

На этапе подготовки проекта в ходе оценки его объема готовится эко­номическое обоснование проекта. В рамках этой работы оценивают­ся денежные потоки, связанные с внедрением системы (см. темы 7, 9). Также строится дерево сценариев (рис. 8.6), увязывающее вероятность отказа от проекта с соблюдением требований методологии различных его этапах.

Рис. 8.6 Пример дерева сценариев.

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

Далее в ходе выполнения проекта дерево сценариев позволяет контролировать финансовую оценку рисков проекта в зависимости от реализации рисков того или иного этапа. Непосредственные затраты на проект определяются также на этапе его подготовки. Впоследствии в рамках процесса управления изменениями относительно каждого изменения оцениваются связанные с ним дополнительные затраты. В случае утверждения изменения на эту сумму корректируется бюджет проекта. Таким образом, стандартные методики ведения проекта (в данном случае — методика ASAP) являются разумной концептуальной основой оценки затрат на проект и связанных с ним рисков.

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