Дальнейшие работы
В дальнейшем работы должны быть продолжены по следующим направлениям:
- разработка методических руководств и документов для практического использования;
- подготовка вариантов методологии для различных групп партнеров;
- разработка, выбор и адаптация программных инструментов для решения задач внедрения и сопровождения.
- использование при разработке полных и точных данных;
- согласованность с корпоративным видением бизнеса;
- реалистичность в отношении возможностей предприятия и ограничений используемых технологий.
- выбор оптимальной конфигурации внедряемой системы;
- создание программно-аппаратной инфраструктуры и сети, обеспечивающих работу прикладной системы
- выбор и/или разработка инструментов и процедур, необходимых для управления прикладной системой.
- определение предмета, рамок, целей проекта;
- создание организационной структуры и системы управления проектом;
- ориентацию всех участников проекта;
- распределение ответственности между исполнителем и клиентом;
- обеспечению ресурсами;
- составление бюджета;
- установление сроков для основных работ.
- соблюдение сроков и ресурсных ограничений;
- обеспечение требуемой функциональности;
- достижение целевых рабочих характеристик (производительности, времени ответа, надежности и т.п.).
- ПРИЛОЖЕНИЕ 1. Процессы и задачи выполнения проекта
- ПРИЛОЖЕНИЕ 2. Процессы управления проектом
- ПРИЛОЖЕНИЕ 3. Рабочий план проекта внедрения
- ПРИЛОЖЕНИЕ 4. ГЛОССАРИЙ
- ПРИЛОЖЕНИЕ 5. Выдержки из ГОСТов на автоматизированные системы
This site is hosted for FREE on VirtualAve -- yours can be, too! Click here for more information.
Содержание раздела
Общий вывод состоит в наличии четкой корреляции между масштабом и сложностью системы, вариантом поставки и уровнем сервиса партнеров. Соответственно, методология должна поддерживать два типа процессов внедрения: ускоренный и полномасштабный, как это показано ниже.
Уровня отдела
| Стандартный Профессиональный | Индустриальный | Ускоренный | ||||
Уровня предприятия | Профессиональный Комплексный | Прикладной | Полномасштабный |
Выполнение проекта
В данном разделе рассматривается структура задач выполнения работ по проекту внедрения. Приводится краткая характеристика фаз и процессов выполнения проекта.
Фазы выполнения проекта
Проект внедрения разбивается на следующие фазы:
01 | Постановка задачи | ||
02 | Анализ и оценка | ||
03 | Техническое проектирование | ||
04 | Рабочее проектирование | ||
05 | Ввод в эксплуатацию | ||
06 | Промышленная эксплуатация |
Ниже приводится их краткая характеристика.
Постановка задачи
В данной фазе осуществляется планирование проекта, анализ бизнес-задач организации и оценка возможности выполнения этих задач в условиях ограниченного времени, ресурсов и денежных средств. Акцент делается на создании выполнимого рабочего плана и ориентации на достижение общих целей. Для каждого процесса определяются стратегия, задачи и подходы, обеспечивая основу для создания реалистичного плана проекта.
В этой фазе группа проекта проводит моделирование процессов. Целью является определить бизнес-требования и требования к системе, предложить будущую бизнес-модель с учетом текущей ситуации. Группа проекта изучает финансовые, операционные, технические и административные процессы, добиваясь понимания и согласия с детальными бизнес-требованиями. Четкое понимание этих требовании является критическим фактором успеха проекта.
Анализ и оценка
В этой фазе группа проекта разрабатывает сценарии выявления и реализации бизнес-требований, основанные на результатах предыдущей фазы, которые затем используются для оценки соответствия бизнес-требований и стандартной функциональности внедряемой системы. Выявляются разрывы и разрабатываются соответствующие решения по их устранению.
Разрабатывается программно-техническая архитектура. Документы по архитектуре используются для разработки детального проекта во время фазы технического проектирования.
При необходимости готовятся предложения по разработке/модификации модулей расширения функциональности и интеграции с другими приложениями.
С самого начала большое внимание уделяется тестированию. Группа тестирования разрабатывает модели для тестирования рабочих характеристик новой системы. Эти модели обычно сконцентрированы на критических показателях (время реакции, производительность), связанных с ключевыми бизнес-функциями и операциями.
Техническое проектирование
Целью данной фазы является определение и детальная разработка технических решений, обеспечивающих выполнение бизнес-требований. Для этого группа проекта создает детальные описания решений, основываясь на процессах, построенных на предыдущей фазе.
Для удовлетворения бизнес-требований может потребоваться программирование расширений. Возможные варианты соответствующих решений были выработаны на предыдущей фазе. Группа проекта тщательно исследует эти варианты и выбирает из них наиболее подходящий.
Для эффективного использования внедряемой системы может потребоваться внести изменения в существующие роли и процедуры будущих пользователей. Группа проекта тщательно готовит соответствующие предложения.
В этой фазе разрабатывается программно-техническая архитектура, которая в состоянии поддерживать выбранную конфигурацию прикладной системы и пользовательские расширения. Также рассматриваются будущие потребности компании и оцениваются возможные изменения в архитектуре. Параллельно идет работа по подготовке тестов рабочих характеристик системы.
Как только приняты основные решения, начинает готовиться рабочая документация. Документация уточняется и корректируется по мере движения проекта.
Проектирование бизнес-процессов является повторяющейся процедурой. Задачи, охватывающие как фазу анализа, так и фазу технического проектирования, могут выполняться как отдельная часть проекта. Например, группа проектирования/отображения реализует целостный итерационный процесс, включающий создание модели бизнес-процессов и формулирование детальных требований, вытекающих из этой модели, их отображение на прикладную систему, выявление и документирование разрывов, поиск обходных путей и т.д.
Рабочее проектирование
В этой фазе выполняется программирование и тестирование программного обеспечения, включая модули расширения, программы преобразования данных и интерфейсы. Также проводится тестирование для определения соответствия разработанных решений бизнес-требованиям.
Если настройка, расширения и преобразования не требуются, фаза рабочего проектирования все равно остается важной, потому что в нее включен тест бизнес-системы, который обычно выполняется в среде, максимально приближенной к реальным условиям эксплуатации.
Во время фазы рабочего проектирования группой тестирования рабочих характеристик создаются программы тестирования и выполняются сами тесты. Разработчики создают программные модули и проводят их автономное тестирование, а также тестирование связей. Также проводятся тесты интеграции с внешними приложениями. Результатом является работоспособное протестированное программно-техническое решение.
Ввод в эксплуатацию
Во время данной фазы группа проекта реализует окончательное решение в организации. Все элементы внедрения выполняются совместно для успешного перехода к промышленной эксплуатации. Группа проекта проводит обучение конечных пользователей, в то время как техническая группа конфигурирует среду эксплуатации и преобразует данные. Фаза завершается переходом к промышленной эксплуатации, как только конечные пользователи начинают. выполнять свои должностные обязанности, используя при этом новую систему.
В данной фазе управление изменениями и защита организации от негативного влияния внедрения являются наивысшим приоритетом, требующим тщательной предварительной подготовки и планирования.
Если используется подход к реализации по фазам, фаза ввода в эксплуатацию может состоять из нескольких этапов, когда компоненты/экземпляры прикладной системы внедряются на различных географических площадках и/или в бизнес-единицах в различное время.
Промышленная эксплуатация
Данная фаза является последней фазой внедрения и началом процесса сопровождения системы. Персонал ИТ-подразделений работает в ускоренном режиме, обеспечивая использование системы в регулярном режиме и создавая инфраструктуру сопровождения. В данной фазе проводится сравнение фактических результатов с задачами проекта. Наконец, формулируются возможные направления развития системы в контексте совершенствования бизнеса предприятия.
Процессы проекта
Проект может быть представлен как совокупность следующих взаимосвязанных процессов, протекающих параллельно:
БП |
Моделирование бизнес-процессов |
БТ |
Определение бизнес-требований |
БО |
Отображение бизнес-требований |
ТА |
Построение программно-технической архитектуры |
ГШ |
Создание программных модулей |
ПД |
Преобразование данных |
ДО |
Документирование |
ГС |
Тестирование бизнес-системы |
ГР |
Тестирование рабочих характеристик |
ОБ |
Освоение и обучение |
ПЭ |
Переход к промышленной эксплуатации |
Типичная структура проекта показана на рисунке. Ниже приводится краткая характеристика процессов выполнения проекта. Состав задач и основных результатов для каждого процесса приведен в Приложении 1.
УП |
Управление проектом |
======= |
======= |
======= |
======= |
======= |
======= |
БП |
Моделирование бизнес-процессов |
===== |
= |
= |
|||
БТ |
Определение бизнес-требований |
=== |
======= |
||||
ВО |
Отображение бизнес-требований |
======= |
== |
||||
ТА |
Построение технической архитектуры |
===== |
====== |
= |
======= |
||
ПМ |
Создание программных модулей |
= |
= |
====== |
==== |
||
ПД |
Преобразование данных |
= |
====== |
==== |
|||
ДО |
Документирование |
===== |
== |
==== |
|||
ТС |
Тестирование бизнес-системы |
= |
==== |
======= |
= |
||
ТР |
Тестирование рабочих характеристик |
= |
== |
==== |
======= |
||
ОБ |
Освоение и обучение |
======= |
= |
====== |
== |
== |
== |
ПЭ |
Переход к промышленной эксплуатации |
= |
== |
======= |
======= |
Задачи данного процесса в основном связаны с построением укрупненного (высокоуровневого) описания организации клиента: структуры бизнеса, перспектив развития, основных бизнес-процессов, организационной структуры, системы управления, приоритетов информатизации, иных существенных моментов. По существу, речь идет о построении архитектуры организации клиента.
В рамках процесса моделирования бизнес-процессов также решается важная задача определения укрупненного баланса между доработкой прикладной системы и внесением изменений в организацию и технологию деятельности предприятия клиента.
Определение бизнес-требований
В процессе определения бизнес-требований формулируются потребности поддержки бизнеса, которым должна удовлетворять внедряемая прикладная система. Существенные требования отражаются в т.н. сценариях бизнес-требований, которые описывают источник требований, их обоснование, связь с другими требованиями, способы обеспечения его выполнения и проверки, другие существенные моменты.
Как часть процесса определяются финансовая и операционная структуры предприятия. Дополнительно собирается информация об объемных показателях деятельности, которая позволяет оценить интенсивность и структуру информационных потоков, а также структуру размещения и объемы данных.
Отображение бизнес-требований
В процессе отображения проводится сравнение бизнес-требований со стандартной функциональностью прикладной системы. Главная цель сравнения - выявить разрывы, которые должны быть устранены для достижения максимально возможного соответствия бизнес-требованиям. Основой для проведения работ является описание архитектуры предприятия и сценарии бизнес-требований.
По мере выявления, разрывы между требованиями и функциональностью удаляются с помощью разработки каких-либо обходных путей, включая изменения в бизнес-процессах, изменение структуры базы данных, либо разработку модулей расширения функциональности.
Построение технической архитектуры
Техническая архитектура представляет собой описание принципиальных технических решений, включая прикладное программное обеспечение, аппаратные средства, локальную сеть, системную платформу. В частности, решаются такие важные вопросы, как выбор типа сервера, схема размещения данных, схема управления доступом и разделения данных между различными подразделениями, интерфейсы к внешним приложениям.
Именно на уровне архитектуры производится дальнейшее уточнение требований. Главная цель процесса - адекватное отображение бизнес-требований на уровне технических решений.
Целостная и адекватная архитектура прикладной системы является критическим фактором успеха для любого проекта внедрения. Проект технической архитектуры должен удовлетворять следующим требованиям:
Первый из перечисленных выше пунктов особенно важен, поскольку архитектурная часть проекта зачастую считается чисто технической, в результате чего возникает риск подгонки бизнес-требований к применяемой технологии. Хорошо управляемый проект разработки архитектуры использует бизнес-требования и их отображение для решения следующих задач:
Будучи связанным с другими процессами, процесс построения архитектуры начинается уже на ранних фазах проекта внедрения. Хотя формально процесс действует только во время фаз постановки задачи, анализа и оценки, технического проектирования, документы по архитектуре используются на протяжении всего проекта внедрения. В конечном итоге, именно архитектура является переходным элементом между требованиями бизнеса и конкретными решениями на уровне реализации.
Создание программных модулей
В процессе проектирования и Программирования модулей принимаются решения по разработке дополнительного программного обеспечения (либо модификации существующего) с целью устранения разрывов в функциональности, выявленных в процессе отображения бизнес-требований.
Предлагаемые решения охватывают программные модули (формы интерфейса, отчеты, обработка данных и т.д.), которые должны быть спроектированы, запрограммированы и протестированы до того, как они будут включены в систему.
Основой для подготовки внешних спецификаций модулей, как и всего процесса в целом, служит техническая архитектура и результаты отображения бизнес-требований.
Преобразование данных
В процессе преобразования данных решаются задачи по идентификации, преобразованию и переносу унаследованной информации в базу данных внедряемой прикладной системы. Преобразованные данные используются как во время эксплуатации, так и при тестировании модулей, обучении и приемочном тестировании.
Общая стратегия определяет средства, методы и процедуры преобразования. Отдельно рассматриваются ручные процедуры для отдельных фрагментов данных. Процесс преобразования включает разработку и тестирование необходимых процедур и программ, а также проверку правильности фактически преобразованных данных.
Документирование
Процесс документирования начинается с самого начала проекта. Обязательно документируются и формально утверждаются решения по ключевым вопросам, включая планы и организацию проекта, бизнес-требования, принципиальные технические решения, результаты комплексного и приемочного тестирования, техническое обслуживание, управление системой и работу пользователей.
Полный набор документации включает руководство по управлению системой, руководство пользователя, справочное руководство пользователя, техническое справочное руководство и текст оперативной подсказки. Создание прототипов каждого документа начинается уже на ранних фазах проекта.
Тестирование бизнес-системы
Главной задачей процесса тестирования бизнес-системы является разработка и проведение тестов, результаты которых позволяют объективно оценить степень выполнения бизнес-требований, прежде всего, требований к бизнес-логике, функциональности, пользовательскому интерфейсу, совместной работе с внешними приложениями и пользовательскими расширениями.
Процесс тестирования бизнес-системы обеспечивает формальный интегрированный подход к тестированию. Основным результатом является высококачественная прикладная система, объединяющая стандартные компоненты и пользовательские расширения.
Тестирование рабочих характеристик
Процесс тестирования рабочих характеристик нацелен получение объективного подтверждения требуемых показателей производительности, времени реакции, надежности и других критичных для конкретной ситуации параметров.
Важной задачей данного процесса является использование общей методологии при тестировании различных компонентов, минимизация объемов повторного тестирования, установление связей между показателями тестирования отдельных компонентов и системы в целом.
Эффективность тестирования, и даже сама возможность его проведения, существенно зависит от наличия соответствующих инструментальных средств, позволяющих смоделировать различные ситуации функционирования в реальных условиях. Чаще всего для этих целей может использоваться командный язык интерпретирующего типа (например, командная оболочка операционной системы либо специальный язык для моделирования прикладной системы), позволяющий описывать различные сценарии.
Освоение и обучение
В процессе освоения и обучения достигается главная цель - обеспечение эффективного использования всех возможностей прикладной системы, а также средств управления и обслуживания. Для этого разрабатывается и реализуется программа подготовки менеджеров различного уровня к работе в новых условиях, а также проходит интенсивное обучение администраторов системы, специалистов по техническому обслуживанию и конечных пользователей. При этом важно адаптировать учебные курсы к конкретной ситуации, ориентируясь на ролевые задачи и должностные обязанности персонала, а не на изучение отдельных модулей прикладной системы и выполнение отдельных операций.
Следует проводить четкое различие между теоретическими и практическими занятиями. Теоретические занятия обеспечивают понимание основ и логики функционирования бизнеса в новой информационной среде, в то время как практические занятия направлены на освоение практических навыков в работы информационной системой в реальных условиях.
Составной частью процесса обучения и освоения является выработка рекомендаций по созданию условий эффективной работы персонала в новой среде.
При внедрении информационной системы часто приходится сталкиваться с непониманием и даже прямым противодействием со стороны отдельных групп сотрудников и менеджеров предприятия клиента. Существенным элементом процесса обучения и освоения является продвижение новой концепции деятельности с помощью проведения специальной разъяснительной компании, ориентированной на различные контактные аудитории, способные повлиять на успех проекта.
Переход к промышленной эксплуатации
Процесс перехода к промышленной эксплуатации переводит предприятие и персонал на полномасштабное использование новой информационной системы. Процесс перехода к промышленной эксплуатации включает в себя планирование и обеспечение готовности к эксплуатации, собственно переход к эксплуатации и последующую поддержку.
Переход считается завершенным, когда полностью сформирована база данных, и пользователи начали полностью работать в новой системе. После этого старая система выводится из использования. Как только достигается режим стабильного функционирования, начинается постоянное сопровождение и улучшение системы.
В процессе перехода, а также в начальный период эксплуатации могут готовиться рекомендации по усовершенствованию как отдельных бизнес-процессов, так и функций самой прикладной системы. Основой для этого служат планы и решения руководства предприятия клиента о дальнейшем развитии бизнеса и его информатизации.
Управление проектом
В конечном итоге управление проектом направлено на достижение гарантированного результата при заданных ограничениях на сроки, денежные и трудовые ресурсы. Для этого используется тесная интеграция задач собственно внедрения с задачами управления проектом. Именно хорошая организация и управление проектом является гарантией успеха.
Стадии и этапы управления проектом
С точки зрения управления проект разбивается на ряд стадий -по числу фаз. Все стадии имеют схожую структуру и включают в себя следующие этапы:
Взаимосвязь процессов собственно выполнения работ и процессов управления показана на рисунке. Ниже приводится краткая характеристика этапов. Состав зада
ПП |
Планирование проекта |
При запуске проекта |
ФП |
Планирование фазы |
В начале каждой фазы проекта |
ФК |
Контроль фазы |
В процессе выполнения каждой фазы проекта |
ФЗ |
Завершение фазы |
При окончании каждой фазы проекта |
ПЗ |
Завершение проекта |
При окончании проекта |
Планирование проекта
На данном этапе основное внимание уделяется решению стратегических задач проекта, включая:
Планирование фазы
Планирование фазы носит более оперативный характер и представляет собой, по сути, адаптацию задач планирования проекта применительно к более детальному уровню отдельной фазы. На этапе планирования фазы при необходимости происходит коррекция планов, включая планы проекта.
На практике планирование проекта и планирование первой фазы часто представляются в виде одного этапа.
Контроль фазы
Процесс контроля протекает параллельно процессу собственно внедрения. Основными задачами этапа является мониторинг хода проекта, подготовка отчетов и оперативное регулирование.
Завершение фазы
На этапе завершения фазы проводятся в основном организационные мероприятия, связанные с подведением итогов и переходом к выполнению следующей фазы. Главной задачей этапа является обеспечение приемки результатов фазы клиентом и подписание соответствующих официальных документов.
Завершение проекта
Состав задач этапа завершения проекта аналогичен этапу завершения фазы. При завершении проекта происходит сдача-приемка всего проекта в целом. Важнейшими задачами данного этапа являются урегулирование всех спорных вопросов и окончательные расчеты.
На практике завершение всего проекта и завершение последней фазы часто представляются в виде одного этапа.
*** Схема «Взаимосвязь процессов выполнения и управления» – не приводится из-за своей бессодержательности.
Процессы управления проектом
Структура задач каждого этапа определяется с помощью следующих процессов управления:
УО |
Контроль и отчетность |
УР |
Управление работами |
УС |
Управление ресурсами |
УК |
Управление качеством |
УФ |
Управление конфигурацией |
Ниже приводится краткая характеристика процессов управления проектом. Состав задач каждого процесса определяется в описании процессов управления проектом (Приложение 2).
Контроль и отчетность
Задачи данного процесса состоят в мониторинге и оперативном регулировании, направленном на выполнение планов, соблюдение установленного подхода к реализации проекта, разрешение споров, проведение изменений проекта в зависимости от ситуации.
Управление работами
Данный процесс в основном связан с составлением и контролем выполнения рабочего плана и бюджета проекта.
Управление ресурсами
Задачи данного процесса направлены на решение вопросов по обеспечению и эффективному использованию ресурсов, необходимых для успешного выполнения проекта, важнейшим из которых являются люди. Данный этап также тесно связан с созданием инфраструктуры проекта, т.е. организационно-технологического комплекса, в рамках которого развивается проект. Примерами элементов инфраструктуры может служить создание оборудованного участка для проведения тестов, генерации прикладной системы для последующего переноса в подразделения предприятия клиента.
Управление качеством
Задачи данного этапа решаются с целью обеспечить надлежащее качество промежуточных и итоговых результатов проекта. Это достигается за счет соблюдения стандартов и процедур для всех видов деятельности, а также за счет тщательного анализа и оценки выходных результатов каждой фазы.
Управление конфигурацией
Управление конфигурацией имеет своим предметом элементы проекта любой природы, которые создаются и используются в ходе выполнения проекта, а также передаются клиенту. Такими элементами могут быть документы, программы, вычислительное оборудование, обученный персонал и т.д. Управление конфигурацией направлено на поддержку эффективного учета, хранения и использования всех элементов проекта.
УО |
Контроль и отчетность |
======== |
======== |
======== |
== |
== |
УР |
Управление работами |
====== |
==== |
======== |
||
УС |
Управление ресурсами |
======== |
====== |
======== |
==== |
==== |
УК |
Управление качеством |
== |
== |
======== |
== |
== |
УФ |
Управление конфигурацией |
== |
== |
======== |
== |
==== |
Рабочий план проекта
Регулярная декомпозиция задач проекта позволяет построить детальный сетевой график, который отражает взаимосвязи задач. На основе сетевого графика создается рабочий план, представляющий собой структурированный перечень задач, упорядоченный во времени.
Типовой рабочий план представлен в Приложении 3.
Обязательные и дополнительные задачи
Рассматриваемый типовой рабочий план охватывает все ситуации внедрения, включая случай комплексной поставки системы масштаба предприятия с большим объемом разработок. Однако независимо от масштаба и сложности системы можно выделить набор обязательных задач, выполнение которых реально обеспечивает достижение высокого уровня качества.
Следует, отметить, что именно набор обязательных задач устанавливает стандарт качества для реализации проектов внедрения системы «1С: Предприятие».
Выполнение обязательных задач требует от исполнителя значительной методической подготовки и создания у себя продвинутой технологии. Основную часть работ по разработке конкретных методик, форм документов и инструментов внедрения для обязательных задач выполнит компания «1С». Соответствующие результаты будут доступны всем партнерам, что в значительной степени облегчит переход всей партнерской сети на новый уровень обслуживания клиентов.
Документирование результатов
Важнейшим элементом технологии внедрения является документирование основных результатов на всех стадиях проекта. Набор обязательных документов для всех проектов внедрения представлен в рабочем плане. Данные документы служат в конечном итоге достижению одной цели: подтверждению качества конечного результата, понимаемого комплексно:
Данные документы позволяют объективно оценивать качество деятельности каждого партнера, а также служат конструктивной платформой при разрешении споров с клиентом. Аналогично методическому обеспечению компания «"1С"» разработает формы всех обязательных документов, которые будут доступны всем партнерам.
События проекта
В рабочем плане представлены основные контрольные точки, соответствующие началу и окончанию фаз и этапов проекта.
Обобщенные процессы
Некоторые задачи выполнения и управления проектом для удобства объединены в типовом плане в обобщенные процессы:
ФП-КОР |
Провести обзор и ревизию планов |
ФК-ИНД |
Контролировать выполнение фазы |
ФК-РЕЗ |
Контролировать не размещенные резервы |