Опытная эксплуатация определение. Этапы внедрения большого заказа. «Классический» способ внедрения системы управления ИТ

1 Положение об опытной эксплуатации оборудования и материалов Общие положения Настоящее положение разработано с целью определения порядка: опытной эксплуатации материалов, оборудования, технических и технологических решений для определения возможности и целесообразности их применения для метрополитена; опытной эксплуатации новой техники и технических решений для определения и проверки их соответствия требованиям технического задания, количественных и (или) качественных характеристик, выявления и устранения недостатков в действиях новой техники и технических решений, в разработанной документации для подготовки всех ее элементов к промышленной эксплуатации. Действие данного положения распространяется на все подразделения метрополитена, Службы и отделы Управления при приведении, участии или контроле процесса опытной эксплуатации новых материалов, оборудования, технических или технологических решений, реализации сложных технических решений в условиях действующего метрополитена. Принятые термины и определения Новые материалы, оборудование, технические и технологические решения любая новая продукция, любые новые технические и технологические решения, новая техника, материалы, оборудование, программное обеспечение, программно-аппаратные комплексы, технологические приспособления, оснастка и т.д., ранее не применявшиеся в метрополитене, но предлагаемые к внедрению. Опытная эксплуатация (ОЭ). Эксплуатация заданного числа (количества) опытных образцов по специальной программе и методике в реальных условиях и контроля в этих условиях технических характеристик изделия. Режим функционирования системы, который предназначен для подготовки всех ее элементов к промышленной эксплуатации. Проведение опытной эксплуатации новых материалов, оборудования, технических и технологических решений для определения возможности и целесообразности их применения для метрополитена практическая проверка возможности применения материалов, оборудования, технических и технологических решений в условиях действующего метрополитена на соответствие заявленным характеристикам, расчет и/или подтверждение расчетных данных по эффективности использования (экономический результат) предлагаемых к внедрению материалов, оборудования, новой техники, программного обеспечения, программноаппаратных комплексов и т.д. в метрополитене. Далее по тексту м.б. опытная эксплуатация, проверка, испытание. 1

2 РАЗДЕЛ I. Требования к организации и проведению опытной эксплуатации в рамках определения возможности и целесообразности применения новых материалов, оборудования, технических и технологических решений для метрополитена 1. Общие требования к проведению опытной эксплуатации 1.1. Основными целями внедрения новых материалов, оборудования, технических и технологических решений является достижение положительного эффекта по следующим направлениям (хотя бы одному из направлений): технологический; эксплуатационный; экономический Внедрение новых материалов, оборудования, технических и технологических решений должно способствовать достижению следующих стратегических целей (хотя бы одной из них): Повышение безопасности перевозки пассажиров. Техническое перевооружение устройств и инженерных систем метрополитена с использованием инновационных технологий. Оптимизация бизнес-процессов технического обслуживания и ремонта оборудования, основных средств и других основных фондов. Обеспечение экономической обоснованности расходов на перевозку. Повышение степени удовлетворенности пассажиров уровнем комфорта, повышение их мобильности. Внедрение новых материалов, оборудования, технических или технологических решений может быть направлено на улучшение конструкционных, технических, эксплуатационных и ремонтных характеристик изделия, оборудования, устройств или других объектов метрополитена, а также на снижение затрат на их обслуживание и ремонт, повышение степени комфорта пассажиров Общими основными задачами при проведении опытной эксплуатации являются: проверка функционирования материалов, оборудования в реальных производственных условиях в ходе произведенного процесса с применением соответствующих технических средств; проверка соответствия поставляемых (предлагаемых) материалов, оборудования требованиям технического задания (при наличии); расчет и/или подтверждение экономического эффекта от внедрения новых материалов, оборудования. Опытная эксплуатация новых материалов и оборудования проводится с целью установления их влияния на следующие факторы: обеспечение безопасности перевозки пассажиров; эффективность использования новой продукции в условиях эксплуатации на метрополитене; снижение эксплуатационных затрат и повышение производительности труда; снижение непроизводительных расходов; совершенствование технологий; улучшение условий труда. 2

3 При положительном результате опытной эксплуатации итогом является Решение о применении продукции в подразделениях метрополитена с внесением изменений в нормативнотехническую, конструкторскую, технологическую документацию. При отрицательном результате опытной эксплуатации итогом является Заключение научнотехнического совета (НТС) подразделения о не целесообразности в применении продукции с указанием конкретных причин. Решение о внедрении новой продукции (технических решений) может быть принято подразделением метрополитена, службой или отделом Управления без проведения опытной эксплуатации на основании теоретических расчѐтов наличия технологической, эксплуатационной или экономической целесообразности, не требующих практического подтверждения, выполненных на основании технических данных производителя при их достаточности для принятия соответствующего решения. Данное Решение должно быть согласовано с курирующим подразделение заместителем начальника метрополитена Случаи отсутствия необходимости проведения опытной эксплуатации. Проведение опытной эксплуатации не является обязательным в следующих случаях: Исполнение требований законодательства и надзорных органов (при отсутствии нескольких альтернативных решений на рынке). Разовое использование материала аналога (заменителя), использование материала аналога (заменителя) при снятии с производства ранее применявшегося материала при наличии подтверждения от производителя о сохранении всех качественных характеристик продукции Испытываемая продукция может быть получена от поставщика безвозмездно или приобретена ограниченной партией через Службу материально-технического снабжения (НХ). 2. Порядок организации и проведения опытной эксплуатации 2.1. Подразделение метрополитена, служба или отдел Управления, инициирующие проведение опытной эксплуатации, готовит служебную записку на имя курирующего заместителя начальника метрополитена с обоснованием необходимости еѐ проведения. В служебной записке должны быть отражены: цели внедрения данной продукции; преимущества предлагаемой продукции (технологии и т.д.) перед аналогами, применяемыми в метрополитене (при наличии таковых); в случае, если продукция является зарубежного производства, должен быть представлен анализ на отсутствие российского аналога требуемого продукта или требуемого качества, или представлены преимущества перед российскими аналогами; указана минимальная партия испытываемой продукции, ориентировочная стоимость продукции и порядок приобретения опытной партии (безвозмездно или через подразделение - закупщик); предполагаемый эффект от внедрения, в том числе экономический (если ожидается), а также наличие или возможность передачи при закупке продукции эксплуатационной, технической, конструкторской и технологической документации Курирующий подразделение заместитель начальника метрополитена согласовывает проведение опытной эксплуатации. 3

4 2.3. После получения согласования подразделение, инициирующее внедрение новых материалов и оборудования, готовит проект указания по типовой форме (приложение 1) за подписью курирующего подразделениие заместителя начальника метрополитена (или первого заместителя начальника метрополитена в случае проведения опытной эксплуатации в нескольких подразделениях) В качестве приложения к указанию вводится программа и методика опытной эксплуатации, утверждѐнная главным инженером соответствующего подразделения (или начальником подразделения, для электродепо обязательно согласование начальника Службы подвижного состава Управления или его заместителя). Программа и методика согласовывается с технологическим отделом Управления, при необходимости программа и методика согласовывается с причастными подразделениями метрополитена, службами и отделами Управления Программа и методика опытной эксплуатации должна содержать следующие разделы: цель внедрения; задачи проведения опытной эксплуатации; преимущество перед материалами аналогами (оборудованием, технологиями и т.д.), применяемыми в метрополитене (если имеются); ожидаемые результаты; порядок проведения; методика проведения; место проведения; используемое оборудование, инструмент или материал; критерии оценки результатов и порядок их расчета, в том числе конкретные количественные и качественные показатели Сроки проведения опытной эксплуатации отражаются в указании При необходимости закупки продукции для проведения опытной эксплуатации подразделения метрополитена, службы или отделы Управления, инициирующие испытания, оформляют заявка в НХ в электронной форме на создание основной записи материала (ОЗМ) (присвоение номенклатурного номера) МПЗ установленным порядком с пометкой «для проведения ОЭ», до принятия окончательного решения об использовании устанавливается метка «разовая закупка» Формирование и согласование заявки на присвоение основной записи материала ОЗМ осуществляется в соответствии с действующим «Регламентом электронного согласования заявок на создание основной записи материала и ведении справочника ОЗМ SAP» По окончанию опытной эксплуатации подразделение в течение 10 рабочих дней, если другие сроки не определены указанием, оформляет результаты в виде заключения научнотехнического совета подразделения (форма заключения приложение 2) и направляет его в технологический отдел Управления. В случае если в ходе опытной эксплуатации было задействовано несколько подразделений, или служб или отделов Управления, в технологический отдел направляется заключение, предварительно согласованное со всеми причастными подразделениями, службами и отделами. Электродепо оформляет результаты в виде заключения научно-технического совета Службы подвижного состава и направляет его в Службу подвижного состава Управления. Служба подвижного состава Управления рассматривает подготовленное заключение на научно техническом совете Службы и направляет согласованное заключение в технологический отдел Управления Технологический отдел Управления, в случае положительных результатов, готовит Решение о целесообразности применения продукции на метрополитене или о необходимости 4

5 продолжения проверки (форма решения приложение 3). Решение согласовывается главным инженером (или начальником) подразделения, проводившего опытную эксплуатацию, и утверждается курирующим подразделение заместителем начальника метрополитена. В случае если в ходе проверки было задействовано несколько подразделений, решение согласовывается со всеми причастными подразделениями и утверждается первым заместителем начальника метрополитена. Решение о применении продукции (технологий), предназначенной для использования на подвижном составе, согласовывается со Службой подвижного состава Управления При положительном решении новая продукция (технологии) вводится к применению на метрополитене указанием. Этим же указанием определяется порядок использования остатка запаса материалов-аналогов и удаления их номенклатурных номеров из справочника ОЗМ, а также определяется порядок эксплуатации, технического обслуживания и ремонта новой продукции, в т.ч. порядок разработки новых и корректировки действующих технологических инструкций и карт технологических процессов. Указание подготавливается силами подразделения, инициировавшего проведение опытной эксплуатации Если принимается решение о продлении сроков опытной эксплуатации и/или еѐ расширении, то подразделение готовит соответствующее указание о продлении сроков. При необходимости могут быть внесены изменения в программу и методику опытной эксплуатации В случае отрицательного результата итоговым документом является заключение НТС, которое хранится в Службе, ответственной за проведение опытной эксплуатации продукции (подлинник) и в технологическом отделе Управления (копия) По окончанию опытной эксплуатации, если новая продукция была получена безвозмездно и не является расходным материалом, она возвращается поставщику Подразделения метрополитена ежегодно до 15 января направляют в технологический отдел Управления сводные отчѐты по результатам всех проведенных опытных эксплуатациях новых материалов, оборудования, технических и технологических решений за период с прошлого года до текущего года. Отчѐт о результатах опытных эксплуатаций, проведѐнных в электродепо, готовит и направляет в технологический отдел Служба подвижного состава Управления. Форма отчета указана в приложении 4 к данному Положению Технологический отдел Управления по результатам отчѐтов подразделений готовит сводный отчѐт по метрополитену, который предоставляется на рассмотрение первому заместителю начальника метрополитена до 31 января ежегодно. Форма отчета указана в приложении 4 к данному Положению. 3. Требования, предъявляемые к образцам (материалам, оборудованию и т.д.), требования к обоснованию необходимости проведения опытной эксплуатации, критерии оценки результатов 3.1. Требования, предъявляемые к образцам (материалам, оборудованию и т.д.). Материалы и оборудование, предлагаемые к внедрению должны отвечать всем следующим обязательным требованиям: Иметь все необходимые сертификаты и лицензии, предусмотренные для продукции данного вида; Все сложные технические изделия должны иметь паспорта, руководства по эксплуатации и ремонту на русском языке; 5

6 До момента начала проведения опытной эксплуатации предполагаемый поставщик должен направить в подразделение, инициирующее проведение проверки, коммерческое предложение с указанием стоимости продукции Для обоснования необходимости проведения опытной эксплуатации материалы и оборудование должны отвечать хотя бы одному из следующих требований: Быть обязательными для использования в метрополитене в соответствии с действующим законодательством; Повышать уровень безопасности перевозочного процесса; Быть направленными на создание комфортной среды для пассажиров, повышать их мобильность: При наличии аналогов, уже используемых на метрополитене, должны отличаться от них меньшей ценой или большей надежностью, или иметь более низкие эксплуатационные расходы и т.д., до начала (в исключительных случаях до окончания) опытной эксплуатации д.б. выполнен расчет экономического эффекта от внедрения; Способствовать изменению технологии обслуживания оборудования метрополитена в части снижения материальных или трудозатрат Критерии оценки результатов. В заключении по результатам опытной эксплуатации должны быть отражены конкретные достигнутые результаты (в зависимости от заявленных целей и ожидаемого эффекта): Указано исполнение конкретных требований действующего законодательства; Рассчитан экономический результат внедрения; Указано, каким образом внедрение способствует повышению уровня комфортности или повышению мобильности пассажиров; В количественных показателях выражено снижение числа отказов. РАЗДЕЛ II. Требования, к организации и проведению опытной эксплуатации в рамках внедрения новой техники и реализации сложных технических решений в условиях действующего метрополитена Требования, к организации и проведению опытной эксплуатации в рамках внедрения новой техники и реализации сложных технических решений в условиях действующего метрополитена 1.1. Основными направлениями и целями, по которым возможно включение в состав работ в рамках внедрения новой техники и реализации сложных технических решений в условиях действующего метрополитена этапа опытной эксплуатации, являются: процесс проверки выполнения заданных функций новой техники и технических решений, определения и проверки соответствия требованиям технического задания, количественных и (или) качественных характеристик новой техники и технических решений, выявления и устранения недостатков в действиях новой техники и технических решений, в разработанной документации; оснащение объектов метрополитена программно-аппаратными комплексами и автоматизированными системами; разработка информационных систем, прикладного программного обеспечения и базы данных, задействованных в технологических процессах предприятия; 6

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

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

9 рекомендации по принятию технических средств в постоянную эксплуатацию; перечень должностных лиц причастных подразделений, ответственных за проведение опытной эксплуатации. «Протокол опытной эксплуатации» подписывается должностными лицами причастных подразделений, ответственными за проведение опытной эксплуатации. Ответственным за своевременную подготовку настоящего акт является подразделение-заказчик выполнения соответствующих работ На основании «Протокола о заверении опытной эксплуатации», не позднее, чем за 7 рабочих дней до даты завершения опытной эксплуатации, организуется работа приемочной комиссии по рассмотрению результатов опытной эксплуатации и принятию технических средств в постоянную эксплуатацию. Ответственным за своевременную оценку результатов опытной эксплуатации является председатель приемочной комиссии. Приемочная комиссия рассматривает результаты опытной эксплуатации и принимает решение о готовности (не готовности) технических средств к вводу в постоянную эксплуатацию. Решение приемочной комиссии оформляется соответствующим актом В случае, если для принятия технических средств в опытную эксплуатацию была определена необходимость проведения предварительных испытаний, то по результатам опытной эксплуатации необходимо предусматривать проведение приемочных испытаний. Порядок подготовки и проведения приемочных испытаний аналогичен порядку, описанному в п настоящего раздела. Приемочные испытания проводятся в соответствии с «Программой и методикой приемочных испытаний». Результаты приемочных испытаний оформляются протоколом и предъявляются председателю приемочной комиссии одновременно с «Протоколом опытной эксплуатации» в сроки, установленные п настоящего раздела. В случае, если предварительные испытания были проведены в полном объеме с проверкой всех требований технического задания и в результате опытной эксплуатации не выявлено замечаний результаты предварительных испытаний и опытной эксплуатации могут быть зачтены, как приемочные с оформлением соответствующего акта приемочной комиссией На основании акта приемочной комиссии о завершении опытной эксплуатации силами подразделения-заказчика работ установленным порядком осуществляется подготовка приказа о принятии технических средств в постоянную эксплуатацию Типовой период опытной эксплуатации, как правило, устанавливается в 1-3 месяца. С учетом результатов опытной эксплуатации указанный период может быть продлен на срок, не превышающий 3-х месяцев. Максимальный срок проведения опытной эксплуатации (с учетом возможного продления) не должен превышать 6-ти месяцев. 9

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

В контексте этого номера под системой управления ИТ мы будем подразумевать автоматизированную систему управления деятельностью ИТ-подразделения, построенную на базе специализированных подходов, методологий, стандартов и программных решений для ИТ-отрасли. Концептуальной основой построения такой системы является «сервисный подход», то есть организация управления ИТ-службой как сервисным подразделением и ориентация всей работы персонала на предоставление услуг бизнесу. Поэтому такая система управления часто называется «Системой управления ИТ-услугами», а ее внедрение – «Внедрение 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;
Промышленный стенд СА;
Обученный персонал заказчика;
Персонал заказчика, участвовавший в опытной эксплуатации.

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

Заключение

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

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

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

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

15.3. ОПЫТНАЯ ЭКСПЛУАТАЦИЯСледует отметить, что опытная эксплуатация системы должна проводиться «по полной схеме» функционирования АС. Отличие в том, что - «опытная» заключается в том, что допустимы, а часто и необходимы доработки АС.

3.1. Опытную эксплуатацию проводят в соответствии с программой, в которой указывают:

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

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

3.3. По результатам опытной эксплуатации принимают решение о возможности (или невозможности) предъявления частей АС и системы в целом на приемочные испытания.

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

15.4. ПРИЕМОЧНЫЕ ИСПЫТАНИЯ

4.1. Приемочные испытания проводят в соответствии с программой, в которой указывают:

1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ);
2) критерии приемки системы и ее частей;
3) условия и сроки проведения испытаний;
4) средства для проведения испытаний;
5) фамилии лиц, ответственных за проведение испытаний;
6) методику испытаний и обработки их результатов;
7) перечень оформляемой документации.

4.2. Для проведения приемочных испытаний должна быть предъявлена следующая документация:

1) техническое задание на создание АС;
2) акт приемки в опытную эксплуатацию;
3) рабочие журналы опытной эксплуатации;
4) акт завершения опытной эксплуатации и допуска АС к приемочным испытаниям;
5) программа и методика испытаний.

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

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

1) полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования АС, указанных в ТЗ;
2) выполнения каждого требования, относящегося к интерфейсу системы;
3) работы персонала в диалоговом режиме;
4) средств и методов восстановления работоспособности АС после отказов;
5) комплектности и качества эксплуатационной документации.

4.4. Проверку полноты и качества выполнения функций АС рекомендуется проводить в два этапа. На первом этапе проводят испытания отдельных функций (задач, комплексов задач). При этом проверяют выполнение требований ТЗ к функциям (задачам, комплексам задач). На втором этапе проводят проверку взаимодействия задач в системе и выполнение требований ТЗ к системе в целом.

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

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

Проверке подлежит:

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

4.7. Проверка средств восстановления работоспособности АС после отказов ЭВМ должна включать:

1) проверку наличия в эксплуатационной документации рекомендаций по восстановлению работоспособности и полноту их описания;
2) практическую выполнимость рекомендованных процедур;
3) работоспособность средств автоматического восстановления функций (при их наличии).

4.8. Проверку комплектности и качества эксплуатационной документации следует проводить путем анализа документации на соответствие требованиям нормативно-технических документов ТЗ.

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

1) назначение испытаний и номер раздела требований ТЗ на АС, по которому проводят испытание;
2) состав технических и программных средств, используемых при испытаниях;
3) указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;
4) условия проведения испытаний и характеристики исходных данных;
5) средства хранения и условия доступа к конечной, тестирующей программе;
6) обобщенные результаты испытаний;
7) выводы о результатах испытаний и соответствии созданной системы или ее частей определенному разделу требований ТЗ на АС.

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

Работу завершают оформлением акта о приемке АС в постоянную эксплуатацию. Также разрабатывают и выпускают другие документы, рассматриваемые в следующем разделе.

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

4. Приёмочные испытания

4.1. Приемочные испытания проводят в соответствии с программой, в которой указывают: 1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ); 2) критерии приемки системы и ее частей; 3) условия и сроки проведения испытаний; 4) средства для проведения испытаний; 5) фамилии лиц, ответственных за проведение испытаний; 6) методику испытаний и обработки их результатов; 7) перечень оформляемой документации.

4.2. Для проведения приемочных испытаний должна быть предъявлена следующая документация: 1) техническое задание на создание АС; 2) акт приемки в опытную эксплуатацию; 3) рабочие журналы опытной эксплуатации; 4) акт завершения опытной эксплуатации и допуска АС к приемочным испытаниям; 5) программа и методика испытаний.

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

4.3. Приемочные испытания в первую очередь должны включать проверку: 1) полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования АС, указанных в ТЗ; 2) выполнения каждого требования, относящегося к интерфейсу системы; 3) работы персонала в диалоговом режиме; 4) средств и методов восстановления работоспособности АС после отказов; 5) комплектности и качества эксплуатационной документации.

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

4.7. Проверка средств восстановления работоспособности АС после отказов ЭВМ должна включать: 1) проверку наличия в эксплуатационной документации рекомендаций по восстановлению работоспособности и полноту их описания; 2) практическую выполнимость рекомендованных процедур; 3) работоспособность средств автоматического восстановления, функций (при их наличии).

4.9. Результаты испытаний объектов, предусмотренных программой, фиксируют в протоколах, содержащих следующие разделы: 1) назначение испытаний и номер раздела требований ТЗ на АС, по которому проводят испытание; 2) состав технических и программных средств, используемых при испытаниях; 3) указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов; 4) условия проведения испытаний и характеристики исходных данных; 5) средства хранения и условия доступа к конечной, тестирующей программе; 6) обобщенные результаты испытаний; 7) выводы о результатах испытаний и соответствии созданной системы или ее частей определенному разделу требований ТЗ на АС.

Работу завершают оформлением акта о приемке АС в постоянную эксплуатацию.

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

В данной статье рассматривается шестой этап: опытная эксплуатация и внедрение .

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

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

Под удобством работы с системой понимаются:

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

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

В целом в процессе опытной эксплуатации прототипа происходит уточнение требований к системе: разработчики и пользователи имеют возможность непосредственно изучить и устранить последствия принятых проектных решений. Принцип построения интерфейса WYSIWYG (What You See Is What You Get – что вы видите, то и получаете) позволяет пользователю непосредственно оценить результаты введенных в прототип изменений.