Управление внедрением систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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