Обсуждение кейсов. Кейс №3 «Кризисная оптимизация бизнес-процессов ИТ-подразделения»

Просмотров: 2354
Автор:
Редакция Global CIO

Сегодня представляем решение очередного кейса «Интеллектуального марафона 2017». Его подготовила Татьяна Орлова, замдиректора по инновационной и экспериментальной деятельности ЗАО «ЕС-лизинг», консультант по управленческим дисциплинам, член cовета директоров itSMF России, эксперт itSMF России «Цифровая трансформация бизнеса». Условия этого кейса для некоторых участников Марафона показались неоднозначными, они не решились предлагать какие-то варианты решений, поэтому в этот раз мы публикуем не так много ответов. Знакомьтесь с решениями, и как обычно, ждем ваших комментариев, замечаний, альтернативных вариантов решений непростой задачи.

Описание кейса:

В компании, много лет занимающейся деятельностью в области ИТ и обладающей серьезной экспертизой в разных ИТ- областях, сетевая структура. Одно из подразделений (Подразделение А) занимается всеми видами деятельности в некой ключевой области, очень востребованной у заказчиков — ИТ-специалистов. Заказчики и конечные пользователи, а также их инфраструктура находятся в разных городах. Количество специалистов в Подразделении А – 15 человек. 

При необходимости получить консультацию по смежным областям Подразделение А работает с другими подразделениями, а также с несколькими вендорами. В свою очередь оно оказывает консультации другим отделам компании. Его ИТ-инфраструктура  частично управляется централизованно (ЦОД, сеть), частично локально.

Система управления в части, которая затрагивает Подразделение А

Вид деятельности

Способ обработки

Уровень управления

1

Управление внешними заявками всех типов, включая инциденты

Автоматизированное отдельное приложение уровня предприятия

Централизованное

2

Управление внутренними заявками

Ручное

Уровень подразделения

3

Управление договорной деятельностью

Автоматизированное. отдельное приложение уровня предприятия

Централизованное

4

Управление проектами

Ручное

Уровень подразделения

5

Управление взаимоотношениями с заказчиками

Ручное

Уровень подразделения

6

Управление командировками

Ручное

Централизованно – локальное, т.е. распределенное

7

Управление документооборотом

Ручное

Централизованное

8

Управление финансами

Ручное

Централизованно – локальное, т.е. распределенное

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

Это повлекло за собой в Подразделении А большой объем срочной разработки новых продуктов, изменение существующих и «перекраивания» существующей системы продуктов заказчика. А также изменение системы взаимодействия с представителями заказчиков и необходимость в срочном изучении новых продуктов.


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

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


Решение Сергея Авдаляна, «Лаборатория Гемотест»:

1. В первую очередь необходимо провести подробный анализ структуры доходов в разрезе их корреляции с трудозатратами. Понять, на какие виды работ, систем, клиентов, приходится наибольшее количество работ на единицу дохода и наименьшее, соответственно.
2. С наименее выгодными клиентами провести работу, сославшись на то, что в первоначальном контракте не было предусмотрено резкое изменения инфраструктуры заказчика и состава ПО. Запросить за новые виды работ дополнительные деньги, если не получится, разорвать отношения.
3. Провести ревизию списка инцидентов и найти решения, которые покроют наибольшее их число. Сосредоточиться на более емких решениях.
4. Проанализировать затраты на командировки. Какие виды работ и направления наиболее затратные. Перевести часть работ на удаленную основу.

Решение Алексея Степанко, ЗАО «НТСК»: 

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

Решение Виталия Шишаева, ОАО «ГСК «Югория»: 

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

Шаг 1. Организационные изменения.
1.1. Выделить в Подразделении А два направления по 6-7 человек: направление инфраструктуры и направление ПО. Назначить в каждой группе руководителя направления.
По видам деятельности см. Шаг 2.
1.2. Выделить в составе подразделения одного человека, который будет выполнять административную функцию («работа с документами»), занимаясь на постоянной основе следующими видами деятельности:
5) Управление документооборотом
6) Управление договорной деятельностью
7) Управление финансами
8) Управление командировками
В целях обеспечения взаимозаменяемости этого сотрудника подключать к решению его задач сотрудников направлений, которые в текущий момент не имеют задач.
1.3. Перенаправить поток внутренних заявок на централизованное приложение, исключить ручное управление этим потоком.
Срок: 2 месяца. 
Ожидаемые результаты: 
- сформированные команды, каждая из которых отвечает за конкретные виды деятельности без отвлечения внимания на административную составляющую,
- выделенная административная функция, 
- все обращения централизованы и учитываются в одной системе.

Шаг 2. Организация производства на направлениях.
2.1. Организовать на направлениях следующие принципы:
1. Проведение изменений по методологии Kanban\DevOps
2. Обработка заявок (инциденты, запрос на обслуживание) по методологии ITIL
Важно! Руководитель направления выполняет две роли - ITIL Service Owner, отвечая за услугу целиком и соблюдение SLA, и Product Owner, отвечая за развитие линейки продуктов направления. Соответственно у направления 2 основных KPI, над которыми работает вся команда направления: 
соблюдение и улучшение SLA; 
сокращение времени цикла разработки.
2.2. Каждая команда отвечает за соблюдение SLA по сервисам, которые относятся к ее направлению, выполняя все процессные роли в рамках процессов управления инцидентами, запросами на обслуживание, проблемами, доступности, непрерывности и т.д.
С целью сокращения нагрузки по поддержке на Подразделение А организовать внутри каждого направления создание и передачу технологических карт и инструментов по типовым обращениям на первую линию поддержки, в том числе по запросам внутренних подразделений компании.
Сократить количество командировок для решения технических вопросов до минимума, т.е. для случаев, когда требуется непосредственное присутствие специалиста на месте, в остальных случаях перейти на удаленное решение проблем и привлечение компаний партнеров и вендоров.
Реализовать обратную связь из продуктивной среды в среду разработки, т.е. оперативное устранение проблем на продуктивной среде силой всей команды.
2.3. Выстроить работу с проектами и запросами на развитие по методологии Kanban. Чтобы не вдаваться в подробности, предположим, что деятельность выстраиваться на основании «книжной» методологии. 

Из особенностей:
1. Приоритизировать Backlog на основании предполагаемых финансовых показателей проекта\запроса, важности клиента и текущих возможностей команды.
2. Не брать в работу нерентабельные проекты, но подходить к отказам от проектов системно, т.е. рассматривая заказчика целиком с учетом всех его заказов.
3. При определении WIP учесть необходимость обеспечения оперативной петли обратной связи, чтобы исключить недоступность ресурсов для решения проблем продуктивной среды.
4. Сократить количество командировок до минимума, выезжая только на важные переговоры. Все остальные контакты проводить удаленно.
5. Для эффективного внедрения методологии провести по ней тренинг для обеих команд.

2.4. Внедрить в работы инструменты автоматизации, которые описаны в DevOps (continuous deploy, continuous integration, управление инфраструктурой на уровне кода и т.д.). Внедрение инструментов должно проводиться так же, как и остальные изменения, т.е. с расчетом экономической эффективности, занятием WIP.
2.5. Выделить в каждой команде специалиста, который будет отвечать за управление взаимоотношениями с заказчиками, включая встречи по обсуждению SLA. Это может быть руководитель направления.

Срок: 
Внедрение: 3 месяца с момента формирования команд.
Стабилизация: 6 месяцев с момент внедрения.

Ожидаемые результаты: 

  • Налаженное производство, направленное на быструю реализацию рентабельных проектов.
  • Нацеленность команд на сокращение операционных затрат.
  • Нацеленность команд на качественный сервис.
Решение Светланы Бусуриной, ГК «Премьер»: 

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

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

Существует 2 варианта развития событий – имеющийся персонал ценен для компании или компания легко меняет людей.
Если персонал не является ценностью для компании, то часть сотрудников может быть заменена на уже подготовленных и владеющих новыми технологиями
Рассмотрим вариант, когда персонал – ценность компании.
На период активного обучения при острой необходимости временно привлекаем с рынка людей, уже владеющих технологиями для ускорения разработки новых продуктов.
Автоматизируем (даже если это автоматизация «на коленке» и решение будет временным) собственными силами (т.к. это ИТ-компания) процессы уровня подразделения (управление внутренними заявками, управление проектами и управление взаимоотношениями с заказчиками), что дополнительно высвобождает ресурсы.
В зависимости от сложности технологий и скорости их освоения сроки могут сильно варьироваться. Полагаю, что в течение 3-4 месяцев можно внутри компании уже иметь группу обученных сотрудников, которые могут выступать наставниками для переобучения остальных. 
Автоматизировать ручные процессы, считаю, можно в течение месяца.
В обязательном порядке проводим анализ причин роста инцидентов, запросов на обслуживание и устраняем причины роста.
Рассматриваем причины учащения командировок. По возможности командировки заменяем на дистанционное взаимодействие. Если полностью отказаться от командировок не получается, то можно рассмотреть вопрос привлечения на аутсорсинг специалистов на местах или проанализировать решаемые в командировках задачи и сознательно управлять очередностью их решения с учетом, в том числе, командировок.

Решение Людмилы Запеваловой, отдел военного комиссариата Ярославской области (старший помощник по обеспечению безопасности информации): 

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

Решение Олега Зайковского, STEP UP International: 

1. «Предположения и допущения»:
Если этот кейс является (очень похоже) вполне реальным, то для подготовки грамотного внятного ТКП (технико-коммерческого предложения), которое явно ожидает автор, имеющемуся описанию не хватает более чётких формулировок исходных проблем и задач в форме такого же реалистичного предварительного ТЗ с более внятными техническими и финансовыми требованиями и ограничениями.

Потому что по вышеизложенному не очень понятна степень «боли» и проблем Заказчика. То есть, они понятны и очевидны, в такой ситуации оказались бы все без исключения коллективы. И на 80% эти проблемы «просто эмоционально» преувеличены. Где хоть какие-то цифры этих «спадов», «объёмов», «увеличений»?
Можно предложить только спокойно пережить это «лихолетье», тем более что подразделение уже само что-то там для себя «решило» и выполняет, и НИКАКИХ иных внятных ЗАДАЧ в данном кейсе НИКОМУ НЕ ставится.  

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

Решение автора кейса Татьяны Орловой:

По инициативе руководителя Подразделения А была начата деятельность (проект) по изменению системы управления Подразделением А, что было в рамках его полномочий и не требовало дополнительных затрат из бюджета компании.
Был приглашен эксперт в области управления, работающий в компании. После краткого управленческого обучения, в ходе которого в качестве практических занятий были проведены совместные обследования (эксперт и руководитель) в разных областях управления Подразделением А, были выявлены приоритетные задачи, решение которых смогло бы снять перегрузку с сотрудников за счет более грамотного распределения и контроля всей деятельности. Основная задача, которую надо было решить в первую очередь: как научиться учитывать, планировать, распределять и контролировать выполнение ВСЕХ задач, поступающих в Подразделение А и исходящих из него. Это позволило бы динамически и контролируемо распределять и перераспределять задачи в зависимости от их важности, продолжительности, трудоемкости, приоритетности, квалификации и т.п.  
Был выбран подход Agile. За основу был взят метод Канбан в ручной реализации. А в качестве приоритетного объекта — подсистема обработки внешних заявок, включая взаимодействие внутри Подразделения и с сотрудниками других подразделений компании. За две недели была построена система ролей, роли были распределены, все сотрудники Подразделения А были вовлечены в ежедневные встречи по планированию, обсуждению и согласованию хода работ. Все обсуждения проходили с использованием доски и цветных карточек. Все успешные управленческие наработки фиксировались и становились основой для визуализации управленческого статуса. Через месяц была разработана новая система управления, которая позволила оптимизировать работы в Подразделении и значительно снизить количество инцидентов с превышенным целевым временем обработки. Зона охвата системы увеличивалась, постепенно включив все виды деятельности в виде конкретных задач, распределенных по разным доскам. Через некоторое время было принято решение заменить реальную доску виртуальной, т.е. инструментом. Был выбран бесплатный инструмент Trello. Еще через некоторое время в инструмент было встроено средство взаимодействия с мобильными телефонами сотрудников, что позволило автоматизировать подсистему управления командировками и интегрировать эту деятельность в общую систему. Была автоматизирована вся деятельность Подразделения А с учетом распределения ролей и ответственности, были зафиксированы все виды взаимодействия в виде регламентов (схем). Параллельно проводились обсуждения, консультации и обучение с экспертом. Через полтора года Подразделение А увеличило свою прибыть в полтора раза, уменьшив при этом количество управленческих документов вдвое.  
  

Комментарии (0)

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.