Управление эксплуатацией и сопровождением информационных систем

 

3. Информационная система службы сопровождения

 

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

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

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

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

 

3. РЕАЛЬНОСТЬ ЭКСПЛУАТАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ.

 

Эксплуатационные работы можно подразделить на подготовительные и основные.

К подготовительным относятся:

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

Основные эксплуатационные работы включают:

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

 

Хотя эксплуатация и стоит на последнем месте в процессе жизненного цикла программных средств по ГОСТ Р ИСО 12207–1999., на данный момент времени а «на дворе 2010 год действующий отечественный ГОСТ 34.601 «Автоматизированные системы. Стадии создания», введен в действие в 1992 году, вообще не акцентирует внимание на эксплуатации. Накоплен значительный опыт в организации эксплуатации информационных систем. Есть международные материалы, например, ITIL/ITSM. Есть и отечественные стандарты:

• ГОСТ Р ИСО 12207–1999 «Процессы жизненного цикла программных средств» акцентирует внимание на том, что помимо стадий приобретения и внедрения есть не менее важные стадии жизненного цикла «Эксплуатация» и «Сопровождение»;
• готовящийся к официальному выходу в свет ГОСТ Р ИСО 20000 перечисляет требования к системе управления ИТ-сервисами (что также во многом связано именно с эксплуатацией систем).

 

3.1 Поддержка пользователей новой системы (пример №1)

 

Проект заканчивается. Система  работает в соответствии с техническим заданием (прошла квалификационные испытания и внедрена в опытную эксплуатацию). Пользователи начинают работать с новой системой и сталкиваются с первыми сложностями. Обнаруживаются первые ошибки: где-то - очевидные (сообщение об ошибке при вызове той или иной функции), где-то - трудноуловимые (неправильные результаты расчетов по некоторым отчётам). Что нужно, чтобы помочь пользователям преодолеть отторжение нового и начать использовать систему на 100%? Хорошо организованная поддержка пользователей. Консультанты покидают компанию, им пора рисовать новую звездочку на фюзеляже - проект закончен. Не занимались они никогда организацией поддержки, да и договором это не предусмотрено. Поддержкой пользователей на предприятии традиционно занимались несколько специалистов. В проекте внедрения ERP они не участвовали, обучение прошли краткое, на уровне первичного инструктажа. Может быть, срочно дать им какой-нибудь инструмент для регистрации обращений? Может быть, вручить им описание процесса управления инцидентами? Но что это даст, когда на них, едва прошедших обучение, обрушится 300 обращений в день? Немного.

А ведь об этом можно было подумать заранее и предпринять, например, следующие шаги:

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

 

3.2 Управление изменениями (пример №2)

 

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

И опять своевременная подготовка позволяет во многом смягчить эти проблемы:

• до запуска проекта необходимо оговорить с консультантами в договоре документирование системы. В некоторых продуктах для этого даже есть готовые инструменты, которые поставляются заказчику в рамках внедрения бесплатно (например, SAP Solution Manager) и, тем не менее, консультанты часто их не используют, избегая дополнительных трудозатрат;
• организовать управление изменениями и релизами (хотя бы только по этой системе). Совместно с консультантами проработать вопросы классификации изменений, правил обновления, тестирования и документирования. Согласовать подход к управлению изменениями с бизнес-руководством, чтобы не создавать неоправданных ожиданий и обеспечить участие заказчиков в управлении системой (в ряде случаев создаются специальные органы управления, состоящие из ИТ-специалистов и представителей бизнес-подразделений, которые совместно решают вопросы проведения изменений - приоритетов, сроков, согласования);
• запускать механизмы управления изменениями и релизами не после окончания проекта, а с самого начала опытной эксплуатации;
• включать своих специалистов в команду разработчиков, прививая им знания новой системы и ее внутренних механизмов, доработанных консультантами, не «за школьной партой», а в реальной жизни.

 

3.3 Управление архитектурой решений (пример №3)

 

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

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

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

Но кое-что можно было сделать  заранее:

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

 

4. РАБОТА НАД ОШИБКАМИ

 

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

С одной стороны, эта ситуация сложилась  исторически. Например, отечественный  ГОСТ 34.601 «Автоматизированные системы. Стадии создания» вообще не акцентирует внимание на эксплуатации. С другой стороны, на дворе 2010 год (упомянутый ГОСТ введен в действие в 1992 году), накоплен значительный опыт в организации эксплуатации информационных систем. Есть международные материалы, например, ITIL/ITSM. Есть и отечественные стандарты:

• ГОСТ Р ИСО 12207–1999 «Процессы жизненного цикла программных средств» акцентирует внимание на том, что помимо стадий приобретения и внедрения есть не менее важные стадии жизненного цикла «Эксплуатация» и «Сопровождение» (рис. 1).
• готовящийся к официальному выходу в свет ГОСТ Р ИСО 20000 перечисляет требования к системе управления ИТ-сервисами (что также во многом связано именно с эксплуатацией систем)

Рис.1 Процессы жизненного цикла программных средств. ГОСТ Р ИСО 12207–1999.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

Что же необходимо на практике сделать для эффективного управления эксплуатацией и сопровождением информационных систем?

На наш взгляд, следующее:

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