Моделирование процесса управления изменениями в информационной системе предприятия

Старков И. С., Старкова Н. О.

МОДЕЛИРОВАНИЕ ПРОЦЕССА УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ В ИНФОРМАЦИОННОЙ СИСТЕМЕ ПРЕДПРИЯТИЯ

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

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

став управления ИС сегодня охватывает всю совокупность функций по проектированию системы способов и методов формирования и использования информационных ресурсов на основе использования технических средств [4]. В организационных структурах прогрессивных лидеров современного рынка, таких как Hewlett-Packard, Microsoft, «ВымпелКом», «Чупа Чупс Рус»[3] и т. д., подразделения, осуществляющие

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

Одним из важнейших факторов повышения эффективности реализации функций подсистемы управления ИС для стремящегося к успеху предприятия сегодня является внедрение и использование концепции управления качеством информационных услуг[2] (Information Technology Service Management -ITSM). ITSM предлагает новое видение организации функционирования ИТ-подразделений, порядок управления этими подразделениями, пути повышения эффективности использования ИТ-ресурсов. Базовыми элементами концепции управления качеством информационных услуг являются "эталонные" модели и принципы, изложенные в ITIL (Information Technology Infrastructure Library) - Библиотеке передового опыта в области управления информационными технологиями. Современная ITIL представляет собой динамично развивающуюся и совершенствующуюся систему знаний и опыта в области информационных систем и технологий.

Повышение сложности бизнес-систем и неупорядоченности информационной среды порождает необходимость выработки подходов к повышению эффективности управления изменениями в информационных системах субъектов отечественного бизнеса. Одним из действенных подходов к решению этой проблемы является разработка процедуры управления изменениями в ИС предприятия, способная быть внедренной в систему управления большинства российских фирм. Такая процедура должна учитывать специфику организации управления субъектов российского бизнеса. Чаще всего это выражается в узком взгляде на роль и место подразделения по управлению ИС в организационной системе управления и значение УИ [1]. В основе предлагаемой модели заложены принципы концепции ITSM и системного подхода, позволяющие представить процесс управления изменениями в ИС предприятия как целостную структурированную систему.

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

1. Введение.

Данная процедура является внутренним документом подразделения по управлению ИС (отдел ИС) предприятия.

1.1. Основная терминология

1.1.1. Определение термина «изменение».

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

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

2. Цель и задачи процесса

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

Цель раскрывается через:

- систематизацию внесения изменений в информационную систему предприятия;

- организацию поддержания документации отделов в актуальном состоянии;

- формализацию процесса внесения изменений.

3. Преимущества введения процесса.

- уменьшение рисков, связанных с воздействием изменений;

- более точное прогнозирование издержек и контроль затрат для проведения предполагаемых изменений;

- повышение адаптации компании к частым изменениям;

- уменьшение отрицательного воздействия изменений;

- упрощение доступа к актуальной конфигурации системы.

4. Основные характеристики процесса.

4.1 Применимость

Данная процедура является обязательной для применения всеми сотрудниками отдела ИС предприятия.

В случае внезапного, незапланированного (форс-мажорного) пропадания сервиса возможно отступление от процедуры на этапах «Инициирование», «Формализация» и «Согласование». «Отчетность» является обязательными даже в этом случае.

Данная процедура распространяется на все информационные системы, сервисы и приложения, контролируемые сотрудниками отдела ИС.

4.2 Приоритеты

На всех этапах проведения изменений приоритетом является доступность и качество существующих сервисов и приложений.

4.3 Роли и обязанности

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

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

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

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

«Внедрение» и «Отчетность».

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

5. Процесс

Процесс управления изменениями представлен на рисунке 1.

5.1. Этапы проведения изменений

Проведение любых изменений имеет семь этапов:

- инициирование,

- формализацию,

-моделирование,

- утверждение,

- проведение (внедрение),

- тестирование,

- отчетность (документирование).

В общем случае, «Формализация»,

«Тестирование», «Внедрение» и «Отчетность» выполняются сотрудниками отдела ИС предприятия. Но возможны случаи, когда к «Тестированию» и/или «Отчетности» привлекаются сотрудники других отделов предприятия, а также подрядчики. Предполагается, что управление изменениями будет осуществляться в электронном виде ^ЕВ, БосишепШш).

5.1.1. Инициирование

Инициатором изменения может

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

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

- цель изменения;

- преимущества от внедрения;

- срочность выполнения.

5.1.2. Формализация

Администратор процесса УИ должен рассмотреть запрос и принять предварительное решение о необходимости изменений. В случае отклонения запроса должна быть обоснована причина. При необходимости администратор процесса УИ может привлекать экспертов и корректировать предварительный запрос.

Обращения

пользователей

Документация

Пользователи

Владельцы систем

Подтверждение тестирования

/

Отч етность

6

Итоговая

документация

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

При формализации запроса необходимо описать:

- подготовительные шаги;

- предполагаемое влияние на другие системы;

- риски;

- предполагаемые затраты;

- критерии тестирования.

Назначить:

- сроки моделирования;

- предполагаемое время проведения изменения;

- ответственного администратора системы.

5.1.3 Моделирование

Моделирование производится ответственным администратором системы на основании технического задания (ТЗ) и в назначенные сроки. При необходимости привлекаются другие сотрудники предприятия и/или подрядчики.

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

Администраторы систем

должен вернуть запрос для повторной формализации.

Моделирование считается готовым при выполнении всех условии ТЗ.

5.1.4 Согласование

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

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

5.1.5 Внедрение

Перед началом внедрения сроки проведения изменений и краткое их описание доводятся до сведения всех пользователей системы.

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

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

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

Решение об отказе принимает ответственный администратор.

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

5.1.6 Тестирование

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

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

Изменение считается протестированным при успешном прохождении всех тестов в назначенные сроки.

5.1.7 Отчетность

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

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

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

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

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

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

Библиографический список

1. Алехин З. 1Т1Ъ - основа концепции управления ИТ-сервисами // Открытые системы - 2000 - март - С. 32-36

2. Дубова Н. 1Т8М - новая идеология управления ИТ //Открытые системы -2000 - №10 - С. 37-42.

3. ИТ Сервис-менеджмент, введение. Под ред. Потоцкого М.Ю. (перевод на рус. язык), под ред. Ян Ван Бон (англ. версия). -СПб.: 2003. - С. 93.

4. Костецкий А.Н., Старкова Н.О. Управление интеллектуальными активами. -Краснодар: 2006. - С. 82.