Типовая структура SLA

Различные примеры соглашений SLA приведены в описаниях стандартов ITIL и COBIT, где также даны развернутые рекомендации по оценке ключевых показателей эффективности (KPI) при анализе работы с SLA.

Типовая модель SLA должна включать следующие разделы:

1. Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.

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

3. Число и размещение пользователей и/или оборудования, использующих данный сервис.

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

5. Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.

6. Спецификации целевых уровней качества сервиса, включая:

· Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса

· Минимальная доступность для каждого пользователя

· Среднее время отклика сервиса

· Максимальное время отклика для каждого пользователя

· Средняя пропускная способность

· Описания расчёта приведённых выше метрик и частоты отчётов

7. Описание платежей, связанных с сервисом. Возможно как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.

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

9. Процедура разрешения рассогласований, связанных с предоставлением сервиса.

10. Процесс улучшения SLA.

6. Структура и задачи ит-службы компании

Можно предложить примерно следующее распределение задач между центральной и децентрализованными ИТ-службами:

· скорее централизованные задачи:

o планирование (особенно стратегическое);

o разработка общего ИТ-бюджета;

o закупки (типовые для ряда децентрализованных ИТ-служб закупки технических и программных средств, сетевого оборудования), работа с поставщиками;

o разработка стандартов на технические и программные средства, сетевое оборудование;

o разработка стандартов на ИТ-услуги; разработка новых типовых ИТ-услуг; сертификация и управление качеством типовых ИТ-услуг, оказываемых децентрализованными ИТ-службами;

o обучение персонала (типовое для ряда децентрализованных ИТ-служб), обмен опытом успешной работы;

o создание и поддержка корпоративных сайтов и телекоммуникационной сети для связи предприятий холдинга;

o разработка типового программного обеспечения.

· скорее децентрализованные задачи:

o поддержка ИТ-сервисов;

o поддержка технических и программных средств, телекоммуникаций;

o оперативное планирование и управление текущей деятельностью;

o подбор рядового персонала ИТ-служб;

o анализ потребностей пользователей в ИТ-сервисах.

· в зависимости от конкретной ситуации, центральная ИТ-служба может также выполнять следующие задачи:

o участие в назначении руководителей децентрализованных ИТ-служб;

o переход к общим классификаторам информации.

7. Стандарты в области управления проектами

Стандарты в области управления проектами можно разделить по следующим признакам:
• Классификация по уровню стандартизации:
o международные;
o национальные;
o отраслевые;
o фирменные (корпоративные).
• Классификация по направленности требований:
o проекты;
o организации;
o персонал (стандарты компетенций). Профессиональная пневматическая винтовка. На арсенал007.ру есть такая.

К международным стандартам относятся:
• ICB IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee: Caupin G. Knopfel H., Morris P., Motzel E., Pannenbacker O. Bremen: Eigenverlag, 1999. pp.112.
• ISO 10006 Quality Management – Guidelines to quality in project management (12/97). (ISO 10006 Управление качеством – Руководство по качеству при управлении проектами (12/97)
• ISO 10006:1997 Quality management — Guidelines to quality in project management
• ISO 10007:1995 Quality Management – Guidelines for configuration management
• ISO 9000:2000 Quality Management Systems – Fundamental and Vocabulary.
• ISO 9004:2000 Quality Management Systems – Guidelines for performance improvements
• ISO 15188:2001 Project management guidelines for terminology standardization
• ISO 15288:2000 Life Cycle Management – System Life Cycle Processes
• ISO/AWI 22799 Building construction — Process management — Guidelines for project management systems
• ISO/IEC TR 16326:1999 Software engineering — Guide for the application of ISO/IEC 12207 to project management

Стандарты компетенций:
• International Competence Baseline IPMA — ICB – IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee. – Bremen: Eigenverlag, 1999
• International Competence Baseline IPMA — ICB – IPMA Competence Baseline. Version3.0. IPMA Editorial Committee. – IPMA: June 2006
• Национальный стандарт Российской Ассоциации Управления проектами (СОВНЕТ) — НТК СОВНЕТ — Основы профессиональных знаний и Национальные Требования к Компетентности специалистов по управлению проектами, Москва, 2001
• Project Manager Competency Development Framework PMI® PMCDF

Разработано множество национальных стандартов управления проектами, представленных АРМ (Великобритания), VZPM (Швейцария), GPM (Германия), AFITEP (Франция), CEPM (Индия), PROMAT (Южная Корея)

Стандарты института управления проектами PMI в США:
• Organizational Project Management Maturity Model (OPM3®)
• Practice Standard for Work Breakdown Structures
• Project Manager Competency Development Framework
• Government Extension to the PMBOK® Guide
• Construction Extension to the PMBOK® Guide
• Practice Standard for Earned Value Management
• The Standard for Program Management
• The Standard for Portfolio Management
• Practice Standard for Scheduling
• Practice Standard for Project Configuration Management
• Unified Project Management Lexicon
• Practice Standard for Risk Management

PMBOK Guide:
• С 1999 г. является национальным стандартом США, как «глоссарий терминов и сокращений» в области управления проектами.
• Третья редакция PMBOK Guide® 2000 Ed. (предыдущие издания – 1987 и 1996 гг.) подтверждена в качестве стандарта ANSI в марте 2001 г.
• Основа – процессная модель (операционный PM).
• Популярность PMBOK Guide® объясняется простотой представления.
• Простота PMBOK Guide® достигнута за счет применения упрощенной (процессной) модели управления проектами применительно к обособленным проектам.
• Не нашли должного отражения стратегический МП, менеджмент по проектам, мультипроектное управление и др.

Распределение стандартов по классификационным признакам:

По основным областям применения стандарты могут быть разделены на следующие группы:

1) применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления;

2) применимые к субъектам управления (менеджеры проектов, участники команд УП) и определяющие требования к знаниям и квалификации соответствующих специалистов и процессу оценки квалификации;

3) применимые к системе УП и организации в целом и позволяющие оценить уровень зрелости организационной системы менеджмента.

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

- ISO 10006. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов;

- PMBOK Guide. А Guide to the Project Management Body of Knowledge. Руководство к своду знаний по управлению проектами, PMI;

- PMBOK Guide Government Extension. Руководство к своду знаний по управлению проектами для правительственных организаций, PMI;

- WBS. Руководство по разработке иерархической структуры работ проекта, PMI;

- Earned Value. Руководство по применению методики освоенного объема, PMI;

- PRINCE2. Стандарт управления проектами, OGC (Office of Government Commerce), Великобритания;

- The Standard for Portfolio Management, PMI. Стандарт управления портфелем проектов, PMI и The Standard for Program Management, PMI. Стандарт управления программой, PMI;

- Managing Successful Programmes, OGC UK. Стандарт управления программой, OGC (Office of Government Commerce), Великобритания;

- P2M Japan. Стандарт управления проектами и программами в организации;

- OPM3. Модель зрелости организации в области проектного менеджмента, PMI

- IPMA Competence Baseline (ICB). Международные требования к компетенции менеджеров проектов, IPMA

- НТК Россия. Основы профессиональных знаний и Национальные требования к компетентности (НТК) специалистов по управлению проектами, СОВНЕТ

- PMCDF PMI. Структура развития компетенций в проектном менеджменте (Project Management Competence Development Framework), PMI

- GPBSPM. Общий стандарт оценки проектного персонала на основе опыта (Global Performance Based Standards for Project Management Personnel), GPBSPM Initiative.

8. Особенности ит-проекта

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

Кроме того, необходимо сделать акцент на следующие особенности ИТ-проектов:

IT-проект создается на базе других IT-продуктов и должен работать в их окружении;

Вовлечены все структурные подразделения организации;

• Максимальное количество команды проекта требуется на фазе планирования;
• Каждый исполнитель может принимать участие в нескольких проектах;
• Зачастую в компании заказчика одновременно выполняются несколько ИТ-проектов;
• Налицо трудности планирования творческой деятельности, отсутствуют единые нормативы и стандарты;

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

· Наибольшее потребления ресурсов приходится на фазу реализации;

· На последующих фазах происходит постепенное высвобождение участников проектной команды;

• Возможна модификация существующей организационной структуры на предприятии;
• Происходит постоянное совершенствование технологии выполнения работ;
• Приоритеты выполнения проектов постоянно корректируются;
• По мере реализации проектов выполняется уточнение и корректировка требований и содержания проектов;

· Часть работ выполняется внешними исполнителями (аутсорсинг);

· ИТ-проект имеет четкое окончание во времени, после которого все работы по проекту закрываются, и на проект перестают тратиться ресурсы.

9. Формирование ит стратегии компании

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

Автоматизация административно-хозяйственных функций происходит путем внедрения системы класса enterprise re­source planning (ERP, информационная система планирова­ния ресурсов предприятия).

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

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

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

• бизнес-архитектура;

• технологическая архитектура;

• технологическая инфраструктура.

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

10. Выбор поставщиков ит-решений

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

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

При выборе поставщика комплексных решений Gartner Research рекомендует следующие критерии оценки:

1. Функциональные возможности.

2. Архитектура: техническая инфраструктура, необходимая для поддержки решения.

· Платформы: операционные системы, базы данных, серверы и сети.

· Масштабируемость: соответствие требованиям больших корпоративных проектов и внедрений, например, в части количества пользователей и объема документов.

· Удобство и простота использования: быстрое и простое обучение новых пользователей эффективной работе с системой.

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

· Безопасность: возможности, обеспечивающие предотвращение несанкционированного доступа к документам и их модификацию; уровни безопасности.

· Поддержка различных каналов: веб-доступ к функционалу, беспроводные технологии.

3. Цена: средняя стоимость приобретения, инсталляции, обновления версий и технической поддержки программного продукта.

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

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

· Стоимость аппаратного обеспечения: необходимые дополнительные устройства и аппаратура (серверы, запоминающие устройства, сетевое оборудование и т.д.).

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

4. Устойчивость продукта: оценка в трех измерениях - финансы, структура и рынок.

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

· Управление и структура: способность предприятия и команды его менеджеров выполнять намеченные цели и требования рынка: разработка продукта, развитие каналов дистрибуции и финансовые показатели.

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

5. Сервис и поддержка: уровень технической поддержки, который обеспечивают поставщик и его партнеры. Это особенно важно, если поставщик обеспечивает поддержку не всех областей.

· Поставщик или какая-либо третья сторона должны обеспечивать высококачественную желательно локальную поддержку и быстро реагировать на запросы клиентов.

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

6. Концепция и видение: прогнозы поставщика относительно тенденций развития отрасли; действия поставщика в плане функциональности и стратегии развития продукта в свете этих прогнозов.

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

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

· Стратегия развития каналов - сравнение прямых и непрямых каналов.
Поставщик оценивается в двух аспектах - стабильность и полнота концепции.

Стабильность:

· Стабильные финансовые показатели за последние 5 лет.

· Инновационные подходы кадровой политики - набор и сохранение сотрудников.

· Инвестиции в расширение областей знаний и компетенции, особенно касающиеся новых, важных технологий, таких как XML.

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

· Явно ощутимые результаты, выраженные в росте дохода, выпуске новых продуктов и увеличении клиентской базы.

Полнота концепции:

· Стратегические планы и видение, включающее знание и понимание основных направлений развития отрасли, например, переход к XML-интерфейсам для интеграции с другими системами.

· Методологии сбора и реализации требований, которые могут быть четко изложены опытной командой менеджеров и разработчиков.

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

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

· Опыт функционирования на определенном вертикальном рынке или на рынке управления документами (отражен в списке клиентов по отраслям).

· Политика маркетинга и продаж, которая зачастую играет большую роль, чем функционал продукта.

Анализ результатов

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

· Для большинства предприятий архитектура и функциональность продукта при принятии решения имеют вес от 25% до 50%.

· Стоимость не менее важна, однако, предприятия, как правило, считают, что поставщики, продукты которых обладают достаточно схожими функциональными возможностями, ведут и сходную ценовую политику. Большая разница цен поставщиков, функциональность продуктов которых схожа, обычно говорит о проблемах у поставщика, предлагающего меньшую цену, либо о неправильности собранной предприятием информации. Стоимость продукта при принятии решения имеет вес от 5% до 10%; однако, предприятиям малого и среднего бизнеса или крупным корпорациям с ограниченным бюджетом следует в первую очередь обратить внимание на цену, а затем уже на функциональность продукта.

· Стабильность имеет при принятии решения вес от 10% до 35%; аналогичный вес имеет критерий оценки сервиса и поддержки. Концепция и видение поставщика составляют от 5% до 10% от общей оценки.

11. Распределание ролей в ит проекте

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

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

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

При этом головная организация рассматривает проект с точки зрения своего стратегического развития и играет роль родительской организации и/или владельца проекта.

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

Владелец проекта определяет требования к проекту и условия его

выполнения, обеспечивает финансирование проекта, извлекает вы-

году из его результатов. Цели владельца — получить оптимальный

продукт за приемлемую цену. В ходе реализации проекта владелец

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

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

12. Виды ит проектов, их особенности

Классификация проектов:

1. По сферам деятельности (Технический, Организационный, Экономический, Социальный, Смешанный);

2. По размерности (Монопроект, Мультипроект, Мегапроект);

3. По объемам финансирования (Малые 200-300тыс.долл, Средние до 10-15млн.долл, Крупные – свыше 10-15млн. долл.);

4. По назначению проекта (Инвестиционный, Инновационный, Научно-исследовательский, Учебно-образовательный, Смешанный);

5. По длительности (Краткосрочный — до 1 года, Среднесрочный — от 1 года до 3 лет, Долгосрочный — свыше 3 лет);

6. По уровням сложности (Простой, Сложный, Очень сложный);

7. По географическому признаку (Проект реализуется в пределах какого-либо города, Региональный проект, Международный проект);

8. По принадлежности предприятию (Внешний, Внутренний);

9. По уровню организации (Локальный, Корпоративный).

Основные виды ИТ-проектов:
• проекты разработки и развития программного обеспечения;
• проекты внедрения информационных систем;
• инфраструктурные и организационные проекты.

Особенности проектов разработки и развития программного обеспечения:
• Разработка программного обеспечения осуществляется в рамках методологий, методов и подходов программной инженерии.
• Программная инженерия (Software Engineering)— это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию.
• Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модели всегда являются упрощениями.
• Метод программной инженерии — это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем. Очень низкие цены индивидуалки нижний новгород можно найти на нашем сайте Практически все методы построены на идее создания графических моделей системы с последующим использованием этих моделей в качестве спецификации или архитектуры системы.

Основные фазы программного процесса:
• Создание спецификации ПО – что система должна делать и ограничения на разработку.
• Разработка ПО – производство программной системы.
• Тестирование ПО (включает в себя validation и verification) – проверка того, что клиент хочет именно того, что прописано в спецификации, и что система соответствует спецификации.
• Развитие или эволюция ПО (software evolution) – изменение ПО в ответ на изменение внешних требований.

Типы моделей программного процесса:
• Модель технологического процесса (workflow model) — показывает последовательность действий, наряду со входами, выходами и зависимостями.
• Модель потоков данных (data flow or activity model) — представляет процесс в виде набора действий, каждый из которых выполняет некоторое преобразование данных. В этой модели действия могут быть более низкого уровня, чем в предыдущей модели.
• Модель роль/действие (role/action model) — показывает роли людей, участвующих в программном процессе, а также действия, за которые они отвечают.

10 основных областей знаний программной инженерии:
• Software requirements – программные требования;
• Software design – дизайн (архитектура);
• Software construction – конструирование ПО;
• Software testing – тестирование;
• Software maintenance – эксплуатация (поддержка) ПО;
• Software configuration management – конфигурационное управление;
• Software engineering management – управление проектами ПИ;
• Software engineering process – процессы ПИ;
• Software engineering tools and methods – инструменты и методы ПИ;
• Software quality – качество ПО.

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

Основные этапы проектов внедрения информационных систем:
q Подготовка проекта;
q Анализ существующих бизнес-процессов;
q Проектирование системы;
q Реализация;
q Подготовка к эксплуатации;
q Поддержка эксплуатации.

13. Процесс разработки и внедрения ИС. Жизненный цикл ИС и его этапы. Методология внедрения и стандарты в области ИС.

Жизненный цикл проекта — это полный набор последовательных фаз

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

ЖЦ проекта состоит из 5 основных фаз ( иногда происходит деление на 4 или 5 фаз, в зависимости от политики предприятия ):

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

Фазы ERP:

Планирование; Анализ; Проектирование; Разработка; Тестирование; Обучение; Внедрение; Поддержка

Исходя из базового стандарта, следующие этапы и их цели: