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

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

Факторы, повлиявшие на успех выполнения задачи:

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

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



1 Этап. Изучение нормативной документации

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

Основные нормативные документы, зарегистрированные в системе электронного документооборота(СЭД) и регламентирующие деятельность ИТ службы:

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

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

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

2. Этап. Оценка текущей ситуации в ИТ службе

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

Цели, поставленные в рамках данной работы:

• Определение структуры рабочего времени
• Выявление потерь времени в рабочем процесса
• Выявление причин невыполнения норм

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

Ключевые выводы, которые были получены в ходе анализа:

• Множество каналов поступления задач (почта, звонок, смс, вайбер и т.д.)
• 80% задач поступают ad hoc
• Приоритеты задач постоянно меняются
• Руководители не имеют возможности планировать работы
• Отсутствует гармоничность в развитии информационных систем
• Нет «установленных правил игры» при реализации изменений

Как итог, предоставление сервиса значительно отставало от потребностей бизнеса.

Этап 3. Классификация обращений в ИТ

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

Все обращения, поступающие в ИТ, были классифицированы на 3 основных вида:

• Запрос на изменение (ЗНИ, CR, RfC)
• Инцидент (включая тип «Проблема»)
• Запрос на обслуживание (ЗНО, SR, RfS)

Запрос на обслуживание(ЗНО) был разделен на несколько составных обращений: Стандартное ЗНО, Нестандартное ЗНО, Запрос на получение информации.

Визуально схему можно представить так:



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

Таким образом в Банке присутствовало 3 источника поступления обращений к ИТ службе Банка:

• 1 линия поддержки (Основные обращения: инцидент, консультация, проблема)
• Бизнес пользователь (Основные обращения: ИТ услуга, консультация, изменение функциональности ПО)
• 3 линия поддержки (Основные обращения: изменение конфигурации, консультация)

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

4 Этап. Построение сервисной модели и подготовка нормативной документации

Вернувшись к существующим документам было принято решение полностью отменить их действие. А в основу новых документов лег “ITIL собственного приготовления”. Из существующих нормативных документов планировалось оставить только документ по управлению проектами.

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



На формирование документов ушел приблизительно месяц. Очень много внимания было уделено процессу управления изменениями, так как задача была оптимизироваться в части Time-To-Market, а классический процесс (являющийся частью ITIL) сильно тормозил данный показатель. В процесс управления изменений вошли элементы Scrum.

5 Этап. Выбор инструмента для автоматизации работы ServiceDesk

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

На ServiceDesk возлагались следующие функции:

• Единая точка входа для пользователей Банка
• Контроль времени выполнения обращений
• Возможность четкой приоритизации обращений
• База знаний
• Управляемость и контроль изменений ИТ инфраструктуры
• Построение отчетности

Выбор осуществлялся между несколькими решениями: Atlassian Jira (положительный опыт работы вне Банка), HP Service Manager (рекомендации контрагентов), IBM Control Desk (решение от стратегического партнера).

Для проведения пилота, победа была отдана компании Atlassian(trial версия), ключевыми факторами стали скорость внедрения и поддержка методологии Scrum (возможно в след. статье расскажу какие части методологии были перенесены и использованы в части управления изменениями и какой положительный эффект удалось достигнуть в связи с внедрением).

6 Этап. Внедрение новой модели ИТ службы

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

• Заведение проектов, типов обращений, настройка полей, описание бизнес процессов (workflow)
• Настройка каталога услуг, SLA счетчиков
• Описание и настройка ролевой модели
• Наполнение базы CMDB (конфигурационная база данных)
• Подготовка обучающих материалов для пользователей

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



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

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

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

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

Заключение

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

Прошел месяц с момента начала опытно-промышленной эксплуатации системы ServiceDesk, была собрана статистика, получены отзывы пользователей. В системе официально зарегистрировано 700 обращений, 109 пользовательских отзывов, средняя оценка ИТ службы 4.8 (из 5 баллов), более 80% задач были выполнены с учетом выставленных SLA.

Дальнейшие шаги – оптимизация процессов, интеграция с системами Банка (IDM, СЭД, внутрикорпоративный портал), совершенствование организационной структуры ИТ службы, перевод контрагентов Банка на взаимодействие с ИТ службой через систему ServiceDesk Банка.