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

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

Методической поддержкой для подготовки технического задания является ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Техническое задание на создание автоматизированной системы", в котором определен перечень требований к содержанию документа и проведению испытаний.

В соответствии с указанным стандартом техническое задание включает следующие разделы, которые могут быть разделены на подразделы:

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приемки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

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

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

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

Примером организационной структуры проекта внедрения ERP-системы на крупном промышленном предприятии может служить следующая организационная структура:

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

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

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

Следует отметить, что в состав организационной структуры проекта внедрения обязательно входят продуктовые ИТ- консультанты. Так, в организационную структуру проекта SAP включают лидеров по модулям (Module Leaders ), которые несут ответственность за каждый из базовых модулей, планируемых к внедрению.

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

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

6.7.6. Работы при определении границ проекта и плана внедрения

Основой подготовки устава проекта является стандарт ANSI PMI PMBOK® 3-rd Edition (2004) - основной стандарт, описывающий все процессы управления проектами.

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

Устав может включать в себя:

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

В процессе подготовки Устава проекта и базового плана основными задачами продуктового ИТ-консультанта является определение рамок проекта внедрения, выбор стратегии внедрения и стратегии развертки (определяющей план разворачивания системы с пилотного участка на остальные, определенные рамками проекта внедрения), планирование проектной деятельности .

Для определения рамок проекта необходимо выделить те виды деятельности и подразделения, которых коснется автоматизация.

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

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

Стратегия внедрения определяет подход к внедрению программного продукта в организации. Существуют различные стратегии внедрения, используемые ведущими разработчиками программных продуктов. Например, при внедрении ERP-систем обычно применяют стратегии "Большого взрыва", "Шаг за шагом", пилотное внедрение.

Принцип "Большого взрыва" предполагает одновременное внедрение всех функциональных модулей программного продукта и замен старых систем.

При подходе "Шаг за шагом" внедрение функциональных модулей разносится во времени, когда по окончании одного внедрения начинается другое.

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

Выбор подходящих стратегий внедрения и развертки является решающим фактором успеха проекта внедрения.

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

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

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

6.7.7. Разработка документа "Дизайн системы"

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

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

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

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

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

6.7.8. Управление процессом настройки программного продукта

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

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

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

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

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

6.7.9. Работы при управлении процессом создания пилотной версии информационной системы

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

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

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

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

По окончании работ продуктовый ИТ-консультант участвует в подготовке отчета, содержащего результаты пилотного проекта .

6.7.10. Обучение персонала организации методологии внедрения и использования выбранного ИТ - решения

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

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

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

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

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

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

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

6.7.11. Организация опытной эксплуатации информационной системы и разработка методики испытаний

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

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

В соответствии с ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем" для информационных систем устанавливаются следующие виды испытаний: предварительные, опытная эксплуатация, приемочные.

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

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

При организации опытной эксплуатации информационной системы задачей продуктового ИТ-консультанта является разработка документа "Программа и методика проведения испытаний".

Документ "Программа и методика испытаний" включает:

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

  6.7.12. Управление вводом информационной системы в промышленную эксплуатацию и разработка ее регламентов

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

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

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

  В соответствии с ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем" документ "Программа приемочных испытаний " содержит:

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

  Приемочные испытания включают проверку:

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

  6.7.13. Организация мониторинга результатов внедрения информационной системы и внесения необходимых модификаций

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

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

Порядок ввода ЭИС в эксплуатацию.

ТИПОВОЕ АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ. СТАДИЯ ВВОДА В ЭКСПЛУАТАЦИЮ.

ЛЕКЦИЯ 10.

Согласно ГОСТ 34.601-90 «АС. Стадии создания» и ГОСТ 34.603-92 «Виды испытаний АС» В рамках стадии ввода системы в эксплуатацию проводят следующие работы:

1) организационная подготовка объекта автоматизации к вводу ИС в действие – реализация проектных решений по организационной структуре, обеспечение подразделений объекта управления инструктивно-методическими материалами, внедрение классификаторов информации;

2) подготовка персонала – обучение персонала и проверка его способности обеспечить функционирование ИС;

3) комплектация ИС поставляемыми изделиями (в случае описанной в ТЗ необходимости такой поставки) – получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий, проведение входного контроля их качества;

4) строительно-монтажные работы – проведение работ по строительству специализированных помещений для размещения технических средств и персонала ИС, сооружению кабельных каналов, монтажу технических средств и линий связи, испытанию смонтированных технических средств, сдаче технических средств для проведения пусконаладочных работ;

5) пусконаладочные работы – автономная наладка технических и программных средств, загрузка информации в базу данных и проверка ее ведения, комплексная наладка всех средств системы;

6) проведение предварительных испытаний – испытание ИС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний; устранение неисправностей и внесение изменений в документацию на ИС, в том числе эксплуатационную в соответствии с протоколом испытаний; оформление акта о приёмке ИС в опытную эксплуатацию;

7) проведение опытной эксплуатации – опытная эксплуатация ИС; анализ ее результатов; доработка программного обеспечения ИС; дополнительная наладка технических средств ИС; оформление акта о завершении опытной эксплуатации.

8) проведение приёмочных испытаний – испытания на соответствие техническому заданию в соответствии с программой и методикой приёмочных испытаний; анализ результатов испытания ИС и устранение недостатков, выявленных при испытаниях; оформление акта о приёмке ИС в постоянную эксплуатацию.

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

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

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

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

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

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

3. Переход на управление по результатам новой системы при сохранении в работе старой системы на случай возможных сбоев и непредвиденных ситуаций.

4. Окончательный переход на работу новой системы.

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

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

2) накопление информации;

3) выход на проектную мощность.

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

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

В период накопления информации можно столкнуться со знаменитым «упала база». При самом плохом раскладе окажется, что СУБД не выдерживает потока информации. При хорошем - просто параметры конфигурации неверны. Первый случай опасен, так как повлиять на производителя СУБД довольно сложно, а заказчик очень не любит ссылок на службу технической поддержки СУБД. Решать проблему отказа СУБД придется не производителю, а вам - менять схему, снижать поток запросов, менять сами запросы; в общем - вариантов много. Хорошо, если время восстановления базы вписывается в запланированное время проекта.

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

ГОСТ 24.208-80 Требования к содержанию документов стадии «Ввод в эксплуатацию»

Постановлением Государственного комитета СССР по стандартам от 14 мая 1980 г. № 2101 срок введения установлен

с 01.01 1981 г.

Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает требования к содержанию документов, разрабатываемых на стадии «Ввод в эксплуатацию» в соответствии с требованиями ГОСТ 24.101-80

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Документы, разрабатываемые на стадии «Ввод в эксплуатацию» относят к приемно-сдаточной документации на АСУ.

1.2. При составлении документов на части АСУ содержание документов ограничивают рамками соответствующей части АСУ.

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

2. ТРЕБОВАНИЯ К ПРИЕМО-СДАТОЧНОЙ ДОКУМЕНТАЦИИ

2.1. Акт завершения работ

2.1.1. Документ предназначен для фиксации факта завершения отдельной работы при создании АСУ.

2.1.2. Документ не распространяется на строительно-монтажные и пусконаладочные работы.

2.1.3. Документ должен содержать:

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

2.2. Акт приемки в опытную эксплуатацию

2.2.1. Документ предназначен для фиксации факта завершения ввода АСУ в целом или ее частей в опытную эксплуатацию.

2.2.2. Документ должен содержать:

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

2.3. Акт приемки в промышленную эксплуатацию

2.3.1. Документ предназначен для фиксации факта ввода АСУ (или ее части) в промышленную эксплуатацию.

2.3.2. Документ должен содержать:

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

* Обязательно только при приемке АСУ в целом.

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

2.4. План-график работы

2.4.1. Документ устанавливает перечень работ, сроки выполнения и исполнителей работ, связанных с созданием работ.

2.4.2. Документ для каждой работы, включенной в перечень, должен содержать:

• наименование работы;
• дату начала и окончания работы;
• наименование подразделения-участника работы;
• фамилию и должность ответственного исполнителя;
• формулу представления результатов работы.

2.5. Приказ о проведении работ

2.5.1. В зависимости от этапа работ по созданию АСУ установлены следующие разновидности документа:

• приказ о готовности объекта управления к проведению строительно-монтажных работ;
• приказ о готовности объекта управления к проведению наладочных работ;
• приказ о начале опытной эксплуатации АСУ (ее частей);
• приказ о вводе в промышленной эксплуатации АСУ (ее частей).

2.5.2. Документ «Приказ о готовности объекта управления к проведению строительно-монтажных работ» должен содержать:

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

2.5.3. Документ «Приказ о готовности объекта управления к проведению наладочных работ» должен содержать:

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

2.5.4. Документ «Приказ о начале опытной эксплуатации АСУ (ее частей)» должен содержать:

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

2.5.5. Документ «Приказ о вводе в промышленной эксплуатации АСУ (ее частей)» должен содержать:

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

2.6. Приказ о составе приемочной комиссии

Документ должен содержать:

• наименование принимаемой АСУ в целом или ее частей;
• сведения о составе комиссии;
• основание для организации комиссии;
• наименование организации-заказчика;
• наименование организации-разработчика, организаций-соисполнителей;
• назначение и цели работы комиссии;
• сроки начала и завершения работы комиссии;
• указания о форме завершения работы комиссии.

2.7. Программа работ

2.7.1. В зависимости от содержания работ установлены следующие разновидности документов:

• программа испытаний;
• программа опытной эксплуатации;
• программа работ приемочной комиссии.

2.7.2. Документ «Программа испытаний» предназначен для определения порядка проведения и объема предварительных испытаний при передаче в опытную эксплуатацию и приемо-сдаточных испытаний при передаче в промышленную эксплуатацию АСУ.

Документ должен содержать:

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

2.7.2. Документ «Программа опытной эксплуатации» предназначен для определения порядка и объема проведения опытной эксплуатации.

Документ должен содержать:

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

2.7.2. Документ «Программа работ приемочной комиссии» предназначен для определения порядка приемки АСУ в промышленную эксплуатацию. Состав и содержание документа определяют по нормативно-техническим документам, утвержденным в данной отрасли.

2.8. Протокол испытаний

2.8.1. Документ предназначен для фиксации результатов предварительных испытаний при передаче АСУ в целом или ее частей в опытную или промышленную эксплуатацию.

2.8.2. Документ должен содержать:

• наименование объекта испытаний;
• список должностных лиц, проводивших испытание;
• цель испытаний;
• сведения о продолжительности испытаний;
• перечень пунктов технического задания на создание АСУ, на соответствие которым проведены испытания;
• перечень пунктов «Программы испытаний», по которым проведены испытания;
• сведения о результатах наблюдений за правильностью функционирования АСУ;
• сведения об отказах, сбоях и аварийных ситуациях, возникших при испытаниях;
• сведения о корректировках параметров объекта испытаний и технической документации.

2.9. Протокол согласования

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

2.9.2. Документ должен содержать:

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

Переиздание. Май 1986 г.

Система управления ИТ: три составные части …

В контексте этого номера под системой управления ИТ мы будем подразумевать автоматизированную систему управления деятельностью ИТ-подразделения, построенную на базе специализированных подходов, методологий, стандартов и программных решений для ИТ-отрасли. Концептуальной основой построения такой системы является «сервисный подход», то есть организация управления ИТ-службой как сервисным подразделением и ориентация всей работы персонала на предоставление услуг бизнесу. Поэтому такая система управления часто называется «Системой управления ИТ-услугами», а ее внедрение – «Внедрение ITSM-решения» или «ITSM-проект».

Система управления ИТ, конечно, не ограничивается средствами автоматизации. Конечный результат ITSM-проекта – работающая система управления ИТ «под ключ». Это совокупность трех составляющих – «процессы», «люди», «средства автоматизации». Когда мы говорим о коммерческом внедрении или об оказании услуг по внедрению, все эти составляющие, как правило, включаются в договор с исполнителем (системным интегратором, консалтинговой компанией) в качестве формальных объектов поставки.

«Процессы» – это так называемая процессная документация, то есть целый комплекс организационно-распорядительных документов, описывающих и устанавливающих правила работы персонала ИТ-подразделения, области ответственности и порядок взаимодействия. Концептуальная основа современной системы управления ИТ (наряду с уже упоминавшимся сервисным подходом) – это процессное управление в сочетании с отраслевой моделью, описанной в библиотеке ITIL. Конкретный ITSM-проект охватывает один или несколько взаимосвязанных процессов, для которых и разрабатывается процессная документация.

«Люди» – это сотрудники ИТ-подразделения, которые участвуют в процессе внедрения, а затем становятся пользователями системы. Они являются носителями опыта и знаний о специфических технологиях и практиках организации и вносят существенный творческий вклад в дизайн системы.

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

Для компании «Инфосистемы Джет» флагманскими решениями являются (в алфавитном порядке) линейки продуктов «BMC Remedy ITSM Suite» и «HP Software Service Management Center». Таким образом, внедрение ITSM-решения – это целенаправленное изменение трех составляющих системы управления ИТ: нормативной документации, навыков работы персонала и средств автоматизации для ограниченного числа видов деятельности (процессов). После принятия принципиального решения о необходимости изменения системы управления ИТ (запуске ITSM-проекта) начинается стадия планирования. Здесь устанавливаются ключевые параметры проекта, выделяются его составные части (задачи), определяется необходимый объем ресурсов, последовательность проведения работ, устанавливается бюджет.

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

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

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

… и три варианта внедрения

При всем разнообразии платформ и богатстве функциональных возможностей, представленных на рынке специализированных программных средств «промышленного» класса, организация имеет в своем распоряжении всего три альтернативных способа использования их для построения системы управления. Назовем их условно: «Решение от производителя», «Лучшая практика» и «Индивидуальное решение».

«Решение от производителя» – установка системы автоматизации «из коробки» и начало работы по эталонным технологическим схемам производителя (с последующей донастройкой в процессе сопровождения). Это наиболее быстрый и недорогой способ организовать работу по-новому.

«Лучшая практика» – установка типового решения, заранее созданного компанией-интегратором на основе своего опыта. Это наиболее гарантированный способ получить реально работающую систему.

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

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

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

Первые два варианта («решение от производителя» и «лучшая практика») имеют много общего. Это готовые решения, которые в рамках проекта не разрабатываются. Внедрение их, по сути, начинается с развертывания и обучения. Планы внедрения таких решений разработаны заранее, много раз апробированы и от проекта к проекту не меняются. Если организация пошла по одному из этих вариантов модернизации системы управления, самые критичные вопросы проекта – это вопросы выбора правильного производителя (платформы) и правильного интегратора.

Выбираем «Индивидуальное решение». Как будем делать?

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

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

Рис. 1. Карта продуктов

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

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

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

Основной вопрос способа разработки: каким образом мы получаем продукты проекта? Для того чтобы понимать это самим, рассказать об этом заказчику, и, самое сложное, реализовать задуманное, мы используем карты продуктов проекта. Карта продуктов – это схема промежуточных и конечных результатов проектных работ, определяющая, что и в каком порядке будет производиться в ходе проекта (см. ). Методической основой построения карты продуктов является метод «Планирование на основе продуктов» (Product based planning) из Prince2, используемый для разработки «Структурной декомпозиции работ» (Work breakdown structure).

Наши карты «расчерчены» этапами проекта, на которые в виде прямоугольников наносят продукты проекта. Прямоугольники соединяются связями, связи определяют, на основе каких продуктов разрабатываются следующие продукты. Таким образом, карта продуктов определяет технологию изготовления системы управления.

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

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

На основе карты продуктов можно наглядно показать основные отличия и особенности рассматриваемого способа разработки. Большинство реализованных нами проектов может быть отнесено к одному из двух способов организации работ. Назовем их условно «Классический» и «Итерационный» и рассмотрим каждый отдельно.

Каждый пример продукта в статье описан по следующей схеме:

• Форма;
• Назначение;
• Содержание;
• Варианты, рекомендации.

«Классический» способ внедрения системы управления ИТ

Суть «классического» способа внедрения – по-этапная разработка системы, начиная с исследования предметной области и заканчивая внедрением системы «под ключ» и дальнейшим сопровождением. Мы выделяем (и наносим на карту) следующие этапы проекта:

• Обследование;
• Проектирование;
• Разработка;
• Развертывание;
• Опытно-промышленная эксплуатация;
• Ввод в промышленную эксплуатацию;
• Техническая поддержка и сопровождение.

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

Этап 1: Обследование

Цели у этапа обследования две: получить представление о текущей практике в предметной области и уточнить постановку задачи. Основной результат этапа – отчет об обследовании. Если следовать карте, первый продукт этапа – «Структура объекта управления» (другое название – «Модель обследования»). Заказчику он не выдается, это «внутренний» продукт. В нем, по той же схеме «люди – процессы – средства автоматизации», фиксируется: что нужно исследовать в рамках обследования, какие документы получить и изучить, с какими людьми провести интервью, какие средства автоматизации, используемые заказчиком, рассмотреть.

Отчет об обследовании

Форма

Текстовый документ (преимущественно), презентация.

Назначение

Отчет об обследовании является наиболее любопытным и интересным для чтения проектным документом. В начале проекта отчет полезен для создания атмосферы взаимопонимания в совмест-ной проектной группе «Заказчик – Исполнитель»: консультанты демонстрируют понимание специфики и приоритетов организации, а представители заказчика принимают и соглашаются использовать термины и инструментарий ITSM-проектов, например, «ролевая структура процесса» и «уровень зрелости».

Вторая жизнь «Отчета» начинается в конце проекта, когда требуется продемонстрировать эффект от внедрения новой системы (было – стало). В дальнейшем, после запуска системы управления в эксплуатацию, он становится ненужным и практически не используется.

На основе чего разрабатывается

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

Типовой отчет условно делится на три основных блока: общие сведения, описание текущей ситуации, выводы.

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

Описание текущей ситуации – это структурированное изложение текущей практики «как есть», иногда с использованием графических схем и рисунков. Для всех обследуемых областей деятельности организации используется единая структура описания. Например, такая:

• Организационная и ролевая структура;
• Виды деятельности процесса;
• Документационное обеспечение;
• Информационное обеспечение;
• Средства автоматизации.

Часто в раздел включаются требования руководства и собранные в ходе обследования пожелания по улучшению, по возможности, без изменения формулировок.

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

После раздела «Выводы» логичным кажется наличие каких-то рекомендаций, однако, в контексте идущего ITSM-проекта на этом можно сэкономить: проект запущен, бюджет утверж-ден, требования сформулированы – пора приступать к проектированию.

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

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

Этап 2: Проектирование

Цель этапа проектирования – предложить и согласовать с заказчиком организационные и технические решения, которые лягут в основу создаваемой системы управления ИТ. Основные результаты этапа – «Модель системы управления ИТ» и детализирующие ее «Описания (регламенты) процессов».

Процессная модель

Форма

Текстовый документ, презентация (преимущественно).

Назначение

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

На основе чего разрабатывается

Исходными ограничениями при разработке процессной модели являются определение проекта в организации и соответствующие положения договора с исполнителем. Как правило, заранее определен состав процессов – подсистем будущей системы управления. Известны и утверждены цели проекта, например, «Внедрение в Департаменте ИТ-процессного подхода, ориентированного на потребности бизнеса. Внедрение элементов мировой «лучшей практики» управления ИТ».

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

Основной проектный источник разработки – отчет об обследовании, а точнее описание текущей практики и «узкие места» в ней. Новая модель должна сохранить хорошо работающие методы управления и устранить недостатки.

В описании процессной модели имеет смысл опираться на широко используемое деление системы на три составные части – «процессы», «люди», «средства автоматизации».

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

• Термины и определения;
• Профиль применяемых стандартов и методов управления;
• Целевой уровень зрелости и его характеристики;
• Цели процесса;
• Входы и выходы (результаты) процесса;
• Информационные объекты;
• Виды деятельности, общая схема процесса.

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

В части ролевой структуры системы («люди») в модели определяется состав и ответственность ролей за виды деятельности процессов. Для каждой роли должна быть оценена возможность назначения или найма персонала. В случае необходимости изменения оргструктуры на это должно быть явно указано.
Что касается средств автоматизации, если они к этому моменту еще не выбраны и не приобретены, то в процессную модель включается перечень планируемых к использованию программных средств и определяется необходимость и методы интеграции со смежными системами (источниками данных о сотрудниках, системами инвентаризации, почтовой программой и т.д.).

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

Модель – центральный продукт этапа. Разработка и согласование модели происходит в несколько итераций с привлечением максимально широкой рабочей группы заказчика. Ошибки, допущенные при разработке модели, обязательно дадут о себе знать на последующих этапах проекта. Цена вопроса: как минимум, существенная переработка уже полученных результатов и неудовлетворенность заказчика. На основе согласованной модели разрабатываются «Схемы процессов» как промежуточный шаг при разработке «Описаний (регламентов) процессов».

Регламент процесса

Форма

Текстовый документ, содержащий графические схемы.

Назначение

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

На основе чего разрабатывается

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

Регламент представляет собой логически связанное формальное описание видов деятельности процесса с указанием ответственных. Вот примерная структура регламента (возьмем управление инцидентами):

• Термины и определения;
• Общие положения:
  • Цели и задачи процесса;
  • Преимущества процесса;
  • Область применения и границы процесса;
  • Входы в процесс управления инцидентами;
  • Выходы из процесса управления инцидентами;
  • Общая схема и описание процесса;
  • Инструментальные средства процесса;
• Роли и обязанности участников процесса:
  • Функциональные роли;
  • Матрица ответственности;
• Регламент процесса:
  • Прием и регистрация;
  • Классификация и первичная поддержка;
  • Назначение;
  • Разрешение, выполнение;
  • Закрытие;
  • Владение;
• Метрики процесса:
• Компоненты и отчеты, предоставляемые процессом;
• Приложение А – Правила классификации;
• Приложение Б – Правила определения приоритетов;
• Приложение В – Правила эскалации.

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

Этап 3: Разработка

Цель этапа разработки – создание средств автоматизации и разработка процессной документации.

На основе «Описаний (регламентов) процессов» разрабатываются «Спецификации процессов». Для каждого процесса управления в составе системы разрабатываются три спецификации: «Спецификация воркфлоу», «Спецификация метрик» и «Спецификация интеграции». На их основе разрабатываются «Сценарии тестирования СА».

Спецификация процесса

Форма

Текстовый документ.

Назначение

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

На основе чего разрабатывается

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

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

• Описание процедуры:
  • Номер (идентификатор) процедуры;
  • Название процедуры;
  • Описание процедуры (из регламента);
  • Ответственный исполнитель (роль);
• Вход в процедуру (событие, активирующее процедуру);
• Операции.

Для каждой операции указывается:

• Номер операции;
• Название операции;
• Выполняемые действия;
• Результат операции.

После внедрения системы управления в эксплуатацию для сокращения затрат на сопровождение рекомендуется вносить изменения сначала в регламент и спецификацию, а затем «нарезать» из спецификации инструкции и сценарии.

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

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

Этап 4: Развертывание

Цель этапа развертывания – подготовить объект управления к опытному или опытно-промышленному использованию системы автоматизации.

План опытной (опытно-промышленной) эксплуатации

Форма

Текстовый документ, план в MS Project.

Назначение

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

На основе чего разрабатывается

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

Регламент проведения опытной эксплуатации отвечает на следующие вопросы:

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

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

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

Этап 5: Опытно-промышленная эксплуатация

Цель этапа опытно-промышленной эксплуатации – апробировать систему управления ИТ в производственных условиях на площадке заказчика. На основе «Плана опытно-промышленной эксплуатации» в ходе этапа формируется «внутренний» продукт «Результаты опытно-промышленной эксплуатации», на основе которого будут подготовлены «внешние» продукты «Отчет об опытно промышленной эксплуатации» и «Протокол замечаний и доработок». «Опциональным внешним» продуктом этапа может стать «Презентация итогов опытно-промышленной эксплуатации».

Этап 6: Ввод в промышленную эксплуатацию

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

После завершения проекта: Техническая поддержка и сопровождение

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

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

«Итерационный» способ внедрения системы управления ИТ

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

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

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

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

  Все эти продукты должны быть получены в рамках «итерационного проекта», равно как они получаются в рамках «классического проекта».

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

• Исследование (предметной области);
• Определение границ результата итерации (релиза);
• Разработка релиза, которая включает в себя:
  • Разработку;
  • Тестирование результата разработчиком;
  • Тестирование результата постановщиком задачи;
  • Приемка релиза постановщиком задачи;
• Приемка релиза заказчиком.

Очевидно, что «приемка релиза» как в мини-цикле разработки, так и в цикле основной итерации, приводит либо к переходу к новой итерации, либо к повторению (в некотором объеме) текущей с целью устранения недостатков.

Итак, мы описали, что необходимо получить (продукты проекта) и каким способом мы собираемся это делать (цикл одной итерации). Осталось показать, каким числом итераций будет разработан продукт, и немного детализировать работы внутри каждой итерации. Мы считаем, что оптимальным количеством итераций будет три, четвертая и последующие вполне могут выполняться в рамках технической поддержки и сопровождения системы управления ИТ. Так же, как для «классического» способа разработки, рассмотрим логику получения основных продуктов проекта в разрезе трех итераций проекта.

Итерация 1: Разработка пилотного релиза (1.0)

Группа проектных задач «Исследование» в рамках первой итерации включает большой объем работ, которые при «классической» разработке выполняются на этапах обследования и проектирования:

• Обследование;
• Разработка модели.
  Затем выполняется группа проектных задач «Определение границ релиза», в которую войдут следующие работы:
• Определение границ релиза в части воркфлоу, метрик и интеграции;
• Согласование границ релиза.

Задачи, входящие в группу «Разработка», выполняются для получения прототипа системы, готового к демонстрации заказчику.

Завершает первую итерацию разработки группа проектных задач «Приемка», в которую войдут следующие работы:

• Демонстрация релиза рабочей группе заказчика;

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

• Персонал заказчика, участвовавший в обследовании;
• Персонал заказчика, участвовавший в проектировании системы управления;
• Отчет об обследовании;
• Модель;
• Схемы процессов;
• Набор спецификаций;
• Согласованные границы релиза 1.0;
• Рабочий стенд СА.

Итерация 2: Разработка опытного релиза (2.0)

Группа проектных задач «Исследование» в рамках второй итерации имеет существенно меньший масштаб, чем для пилотного релиза, и включает одну задачу:

• Апробация релиза рабочей группой заказчика.

Группу проектных задач «Определение границ релиза» составляют следующие работы:

• Согласование границ релиза.

• Принятие решения о доработке релиза или переходе к следующей итерации.

Результирующими продуктами итерации 2 являются:

• Согласованные границы релиза 2.0;
• Опытный стенд СА;
• Описания (регламенты) процессов;
• Инструкции пользователя системы автоматизации;
• Программа и методика испытаний;
• Персонал заказчика, участвовавший в апробации средств автоматизации.

Итерация 3: Разработка промышленного релиза (3.0)

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

Отчет об опытной (опытно-промышленной) эксплуатации

Форма

Текстовый документ.

Назначение

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

На основе чего разрабатывается

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

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

Общие сведения – это, в первую очередь, источники данных и критерии оценки, используемые для формирования отчета. Желательно, чтобы выбранные критерии охватывали и управление процессами, и выполнение процедур процессов, и результаты выполнения плана опытной эксплуатации.

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

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

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

В группу войдут следующие работы:

• Обучение пользователей системы;
• Опытно-промышленная эксплуатация.

• Формирование перечня доработок;
• Определение способа реализации доработок;
• Согласование границ релиза.

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

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

Итак, продуктами итерации 3 являются:

• Инструкция администратора;
• Описание настроек системы автоматизации;
• Согласованные границы релиза 3.0;
• Промышленный стенд СА;
• Обученный персонал заказчика;
• Персонал заказчика, участвовавший в опытной эксплуатации.

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

Заключение

В статье мы рассказали о нескольких альтернативных вариантах внедрения автоматизированной системы управления деятельностью ИТ-подразделения. Это «Решение от производителя», «Лучшая практика» и «Индивидуальное решение», которое, в свою очередь, может быть разработано как «классическим», так и «итерационным» способом.

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

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

Успешных вам проектов!

Документы