Сегодня я расскажу о нашем опыте реорганизации процессов IT департамента для одного из банков Украины с помощью внедрения Atlassian инструментов. В таких проектах важно не забывать, что настройка новой системы под существующие процессы не приведет к существенному результату. Довольно часто корень находится в процессах работы, а это уже более глобальный вопрос. Мы помогаем нашим клиентам сначала обдумать бизнес-процессы, упростить их, сделать более гибкими и быстрыми, что дает значительный результат для бизнеса в целом, а только потом внедрять систему управления.
До недавнего времени система HP Service Desk 4.5 для автоматизации ITSM процессов, была практически стандартом в корпоративном мире. Первая версия HP SD была выпущена 2002 году, а в 2012 году, спустя 4 крупных обновления, официальная поддержка системы была прекращена. Конечно, учитывая популярность системы в корпоративном сегменте на смену ей была разработана Omnitracker, которая, фактически, была продолжением “культовой” 4.5. Она изначально делалась с прицелом на замену HP SD, поэтому ее интерфейс не сильно отличался от старшего брата, хотя функциональные возможности и расширились спустя 10 лет с релиза первой версии HewlettPackard. HP также хотели сделать продолжение ITSM системы — Service Management Automation X, но сейчас на рынке она не пользуется успехом.
В 2020 году любому ентерпрайз бизнесу требуется поддержка процессов и инструменты для эффективного ведения дел, как внешних, так и внутренних. Для работы с ITSM и ITIL нужно уже не просто понимать что это такое, но и сокращать издержки на поддержание этих процессов, например, за счет использования правильных инструментов. За последние 2 года появился тренд использования быстрых, гибких и универсальных инструментов, упрощения и движения в сторону гибкости бизнес-процессов с разумным уровнем бюрократии и строгости. Компании стараются отходить от решений за миллионы долларов с десятками модулей, из которых использоваться будет лишь часть.
Теперь о проекте. На момент старта проекта в банке был HP Service Desk 4.5, стояла задача перейти к использованию Atlassian продуктов во всех возможных департаментах (IT департамент, ПМО, АХО, HR, Юристы и пр.). Проект начался с департамента IT. Мы провели дискавери фазу для изучения бизнес процессов департамента, их связи с другими отделами банка, определили объем и задачи проекта и сформировали план работ. На этом этапе начали проявлятся особенности работы с клиентом-банком. Банк — это огромная структура, практически маленькое государство, с внутренней политикой, интересами и курсом развития. Например, получение доступа к серверу может занимать не час-два, как в ИТ компании, а несколько дней, за которые запрос пройдет все круги согласований и проверок. Чтобы уменьшить критический путь выполнения проекта, мы планировали работы в несколько параллельных потоков: задачи, которые находятся на стороне банка, и наши задачи. За это время мы уже ускорили процессы коммуникации из классической почты и ответов на следующий день на более быстрые мессенджеры, начали проводить больше личных встреч.
Во время внедрения продуктов и реорганизации процессов мы столкнулись с излишней сложностью некоторых процессов. Например, на момент старта проекта в банке было более 90 разных процессов, с разным набором вовлекаемых подразделений и связанных задач, которые ждут друг друга только для управления изменениями. Некоторые виды изменений могли проводиться не чаще чем 2 раза в год потому, что суммарно их выполнение занимало пол года. Для таких случаев мы рекомендовали изменения в бизнес процессах. Понятно, что не везде это возможно, в силу юридических, регуляторных и бюрократических ограничений, но, например, в случае с процессами изменений при пересмотре их получилось уменьшить до 46, что сделало настройки более унифицированными.
Как иногда бывает при внедрении новых систем, во время выхода в продакшн мы столкнулись с сопротивлением сотрудников, которые привыкли работать в старой системе. Но нашим прямым заказчиком был руководитель подразделения, поэтому мы перебороли сопротивление достаточно жестко. Для упрощения ввода системы в эксплуатацию, при реализации проекта мы применяли итеративный подход к релизам с промежуточным результатом, поэтому было принято административное решение отключать в старой системе процесс, когда он был готов в новой. Да, конечно, некоторое время банку нужно было использовать 2 системы; например, запросы пользователей уже обрабатывались в Atlassian, а управление изменениями проходило в HP SD. Но это дало время сотрудникам привыкнуть к новым условиям, а также позволило нам получить быстрый фидбэк.
Используя свою экспертизу и имеющуюся структуру IT в банке, мы совместно построили службу поддержки из четырех линий. Нулевая линия работает в Jira Service Desk, она производит первичную обработку заявок внутренних пользователей и обеспечивает выполнение установленных SLA по всем заявкам. Далее, на первую и вторую линии поддержки задачи эскалируются, и сотрудники работают над задачами в Jira Software. Такой подход позволяет разделить инструменты по назначению. Сотрудникам первой, второй, третьей линии далеко не всегда нужны возможности классического Service Desk. Эти люди, а их больше 100 человек, обычно выполняют поставленную задачу одну за другой, и им незачем видеть поток всего, что приходит в ИТ поддержку.
Как козырь в рукаве, остается третья линия. Для них задачи создаются внутри банка, эта линия — внутренние разработчики, тестировщики, аналитики. Они исправляют ошибки программн��го обеспечения или разрабатывают новое. Возможность передать задачу на работу такой внутренней команде есть только при условии, что все предыдущие линии не смогли решить запрос по какой-то причине либо если это Change request.
Кроме IT на новую систему перешли также департаменты АХО и ПМО.
У департамента АХО есть свой набор запросов, то есть свой портал на сервис деске, а ПМО использует классические Jira Core проекты для внутренних задач.
Говоря о классической службе поддержки, нельзя не остановится подробнее на ITIL. В банке был реализован, наверное, самый классический набор процессов для таких проектов:
Таким образом в течении внедрения проекта, процесс за процессом, банк перешел с морально устаревшей HP Service Desk 4.5, выпущенной в 2002 году, на современную, поддерживаемую систему из комплекса продуктов Atlassian. Доработаны и реорганизованы ITIL процессы с учетом сложности банковской структуры. Это дало заказчику несколько важных улучшений:
Историческое отступление
До недавнего времени система HP Service Desk 4.5 для автоматизации ITSM процессов, была практически стандартом в корпоративном мире. Первая версия HP SD была выпущена 2002 году, а в 2012 году, спустя 4 крупных обновления, официальная поддержка системы была прекращена. Конечно, учитывая популярность системы в корпоративном сегменте на смену ей была разработана Omnitracker, которая, фактически, была продолжением “культовой” 4.5. Она изначально делалась с прицелом на замену HP SD, поэтому ее интерфейс не сильно отличался от старшего брата, хотя функциональные возможности и расширились спустя 10 лет с релиза первой версии HewlettPackard. HP также хотели сделать продолжение ITSM системы — Service Management Automation X, но сейчас на рынке она не пользуется успехом.
В 2020 году любому ентерпрайз бизнесу требуется поддержка процессов и инструменты для эффективного ведения дел, как внешних, так и внутренних. Для работы с ITSM и ITIL нужно уже не просто понимать что это такое, но и сокращать издержки на поддержание этих процессов, например, за счет использования правильных инструментов. За последние 2 года появился тренд использования быстрых, гибких и универсальных инструментов, упрощения и движения в сторону гибкости бизнес-процессов с разумным уровнем бюрократии и строгости. Компании стараются отходить от решений за миллионы долларов с десятками модулей, из которых использоваться будет лишь часть.
Старт проекта
Теперь о проекте. На момент старта проекта в банке был HP Service Desk 4.5, стояла задача перейти к использованию Atlassian продуктов во всех возможных департаментах (IT департамент, ПМО, АХО, HR, Юристы и пр.). Проект начался с департамента IT. Мы провели дискавери фазу для изучения бизнес процессов департамента, их связи с другими отделами банка, определили объем и задачи проекта и сформировали план работ. На этом этапе начали проявлятся особенности работы с клиентом-банком. Банк — это огромная структура, практически маленькое государство, с внутренней политикой, интересами и курсом развития. Например, получение доступа к серверу может занимать не час-два, как в ИТ компании, а несколько дней, за которые запрос пройдет все круги согласований и проверок. Чтобы уменьшить критический путь выполнения проекта, мы планировали работы в несколько параллельных потоков: задачи, которые находятся на стороне банка, и наши задачи. За это время мы уже ускорили процессы коммуникации из классической почты и ответов на следующий день на более быстрые мессенджеры, начали проводить больше личных встреч.
Во время внедрения продуктов и реорганизации процессов мы столкнулись с излишней сложностью некоторых процессов. Например, на момент старта проекта в банке было более 90 разных процессов, с разным набором вовлекаемых подразделений и связанных задач, которые ждут друг друга только для управления изменениями. Некоторые виды изменений могли проводиться не чаще чем 2 раза в год потому, что суммарно их выполнение занимало пол года. Для таких случаев мы рекомендовали изменения в бизнес процессах. Понятно, что не везде это возможно, в силу юридических, регуляторных и бюрократических ограничений, но, например, в случае с процессами изменений при пересмотре их получилось уменьшить до 46, что сделало настройки более унифицированными.
Как иногда бывает при внедрении новых систем, во время выхода в продакшн мы столкнулись с сопротивлением сотрудников, которые привыкли работать в старой системе. Но нашим прямым заказчиком был руководитель подразделения, поэтому мы перебороли сопротивление достаточно жестко. Для упрощения ввода системы в эксплуатацию, при реализации проекта мы применяли итеративный подход к релизам с промежуточным результатом, поэтому было принято административное решение отключать в старой системе процесс, когда он был готов в новой. Да, конечно, некоторое время банку нужно было использовать 2 системы; например, запросы пользователей уже обрабатывались в Atlassian, а управление изменениями проходило в HP SD. Но это дало время сотрудникам привыкнуть к новым условиям, а также позволило нам получить быстрый фидбэк.
Технологический стэк
Используя свою экспертизу и имеющуюся структуру IT в банке, мы совместно построили службу поддержки из четырех линий. Нулевая линия работает в Jira Service Desk, она производит первичную обработку заявок внутренних пользователей и обеспечивает выполнение установленных SLA по всем заявкам. Далее, на первую и вторую линии поддержки задачи эскалируются, и сотрудники работают над задачами в Jira Software. Такой подход позволяет разделить инструменты по назначению. Сотрудникам первой, второй, третьей линии далеко не всегда нужны возможности классического Service Desk. Эти люди, а их больше 100 человек, обычно выполняют поставленную задачу одну за другой, и им незачем видеть поток всего, что приходит в ИТ поддержку.
Как козырь в рукаве, остается третья линия. Для них задачи создаются внутри банка, эта линия — внутренние разработчики, тестировщики, аналитики. Они исправляют ошибки программн��го обеспечения или разрабатывают новое. Возможность передать задачу на работу такой внутренней команде есть только при условии, что все предыдущие линии не смогли решить запрос по какой-то причине либо если это Change request.
Кроме IT на новую систему перешли также департаменты АХО и ПМО.
У департамента АХО есть свой набор запросов, то есть свой портал на сервис деске, а ПМО использует классические Jira Core проекты для внутренних задач.
По верхам ITIL стандарта
Говоря о классической службе поддержки, нельзя не остановится подробнее на ITIL. В банке был реализован, наверное, самый классический набор процессов для таких проектов:
- Управление инцидентами (Incident management). Целью этого процесса является управление жизненным циклом всех инцидентов. Процесс направлен на быстрое решение запросов пользователя, которые непредвиденно начали мешать его работе.
- Управление проблемами (Problem management). Этот процесс помогает ИТ департаменту предотвратить инциденты и минимизировать влияние инцидентов, которые невозможно предотвратить или предвидеть.
- Запросы пользователей (Request fulfillment). Основной процесс службы поддержки — выполнение запросов на обслуживание. Как правило, это помощь в решении базовых вопросов или незначительные изменения, например, рабочего места пользователя.
- Управление изменениями (Change management). Процесс контролирует все изменения, которые могут выполняться одновременно несколькими департаментами банка. Это могут быть доработки программного обеспечения, изменения инфраструктуры, внедрение новых инструментов.
- Управление конфигурациями (Configuration management). Этот процесс направлен на управление ИТ инфраструктурой и все что с ней связано. Хранение в едином месте информации по серверам, приложениями, доступам, лицензиями, рабочим местам и использование этих данных во всех остальных процессах помогает четко прослеживать изменения или инциденты. Мы использовали дополнительный плагин Insight — Asset management, который красной нитью проходит через все продукты и позволяет работать с конфигурационными единицами на всех линиях поддержки.
- Управление знаниями (Knowledge management). Отвечает за управление информацией о системе в целом. Предоставляемые услуги для пользователей, имеющаяся инфраструктура, типовые инструкции для пользователей. Все это должно хранится в одном месте и быть доступно для клиентов службы поддержки. В этом кейсе мы использовали Confluence, как продукт для работы с базой знаний и местом для технической документации ИТ департамента.
Результат
Таким образом в течении внедрения проекта, процесс за процессом, банк перешел с морально устаревшей HP Service Desk 4.5, выпущенной в 2002 году, на современную, поддерживаемую систему из комплекса продуктов Atlassian. Доработаны и реорганизованы ITIL процессы с учетом сложности банковской структуры. Это дало заказчику несколько важных улучшений:
- Проведена ревизия бизнес-процессов для работы с запросами пользователя и внутри банка;
- Получены прозрачные SLA, которые можно отслеживать и использовать для улучшения департаментов;
- Разделены зоны ответственности на явные линии поддержки и снижена нагрузка на департамент в целом. Вместо того, чтобы обрабатывать каждую заявку по прямой цепочке “нулевая-первая-вторая-третья линии”, теперь часть заявок автоматически распределяется на нужные линии;
- Ускорилось время реакции и время решения задач.
