Ответы участников марафона на второй тур, кейс 1 (стр. 3 )

Козлов Илья

Судя по описанию ИТ подразделения заняты преимущественно «тушением пожаров». Т. е. реагируют только на инциденты, которых становится все больше, персонал начинает хронически не успевать, перерабатывать, но даже этого уже недостаточно. Количество инцидентов растет слишком быстро. Расширение штата позволит временно снять остроту, но саму проблему не решит.

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

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

Колонский Евгений

Диагноз:

да, метрики в норме, но за метриками потеряно самое главное: связь с потребностями бизнес-подразделений. Возможно, служба ИТ «отстала от поезда»: бизнес изменился, а предоставляемые сервисы остались в прошлом. 

Рекомендации директору по ИТ:

1) Провести серию интервью с CxO и «сверить часы»: выровнять цели ИТ и цели бизнеса. Обычно это делается через документированную стратегию ИТ. (Demand mgmt. ITIL v3)

2) провести ревизию сервисов, определить критически важные, влияющие на удовлетворенность, и сосредоточиться на поддержании их качества. Может быть, за счет ухудшения качества или отключения менее важных сервисов. Выявить недостающие сервисы и спланировать их создание. (Service level mgmt., Service catalogue mgmt)

3) больше пиара, больше гласности и открытости. Использовать новостные поводы, чтобы рассказывать о существующих и новых сервисах. Терпимо и конструктивно относиться к критике.

4) наладить коммуникации в команде ИТ. Например, через совместные совещания по разбору сервис-деска. Обратить внимание на управление проблемами и на накопление базы знаний (problem, knowledge mgmt.).

5) совместно с HR  разобраться с кадровой проблемой. Людей не хватает объективно или субъективно? Сравнить численность службы ИТ с отраслевой нормой. Привлечь HR к поиску и первичному отбору кандидатов и сберечь время линейных руководителей, если это принято в компании.

Кошманенко Ярослав

Возможные причины и варианты решения указанных проблем:

0) Пересмотреть ключевые показатели эффективности!

1) В подразделении отсутствует единая система управления проблемами и инцидентами (ServiceDesk)

- Внедрить систему;

- Обязать всех пользователей обращаться только через SD (то есть автоматически фиксировать все обращения в электронном виде);

- Настроить уведомления о любом инциденте даже для тех руководителей подразделений, которых она "якобы" не касается;

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

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

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

4) При правильно выстроенном FAQ, который будет формироваться вследствие работы с заявками - автоматически будет вырабатываться путь нахождения решения причины каждой проблемы, что позволит в будущем сократить количество ИТ персонала.

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

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

6) Найм персонала должен проходить централизованное согласование через ИТ-директора совместно с HR.

Кудинов Михаил

На мой взгляд в ИТ подразделении:

1. Нехватка кадров

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

2. Нет четкой единой системы взаимодействия между отделами.

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

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

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

Для того чтобы изменить и наладить ситуацию в ИТ отделе, нужно применить комплекс мер:

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

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

3. Нужно принять комплекс мер по удовлетворенности персонала и снижению напряжения повышение З/П, а так же всевозможные бонусы и поощрения за переработку.

Кулешов Михаил

На мой взгляд возможны 2 основных варианта происходящего и как следствие столько же вариантов действий:

1) Классическая "итальянская забастовка" - все усердно выполняют свои инструкции.... Такое часто встречается в крупных компаниях особенно в обслуживающих подразделениях, которые не завязаны напрямую на финансовый результат компании.

Признаки:

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

- Отсутствие взаимодействия между подразделениями ИТ (каждое подразделение - обособленно, задачу пользователя можно "разбить" на последовательные блоки перекидывая между подразделениями (увеличив таким образом сроки исполнения), либо на параллельные (увеличив количество решенных задач). Напр.: "принтер не печатает" - проверяем компьютер, прикладное ПО, сам принтер, бумагу для принтера......

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

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

Меры по улучшению ситуации:

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

- Улучшение ситуации с документированием выявленных ошибок - позволит создать FAQ для сотрудников и уменьшить загрузку ИТ подразделения.

- Внедрение мотивационных программ для сотрудников ИТ подразделения (в т. ч. карьерный рост) направленных на улучшение  «степени удовлетворенности пользователей»

2) Практически обратная ситуация - ухудшение "качества" пользователей.

Увы, в современных российских реалиях, тоже нередкое явление. В связи со снижением качества образования, притока мигрантов и т. д. с одной стороны и повышения требований к компьютерной грамотности пользователей (из за повышения компьютеризированности всех процессов) с другой стороны мы имеем среди пользователей либо "молодых специалистов", зачастую с дипломами о высшем образовании, которые не могут работать даже с табличками Excel и очень сложно обучаются новым программам, либо "старшее поколение", которое тоже воспринимает инновации в ИТ сфере с трудом.

Признаки:

- Превышение целевых показателей отчетов по инцидентам (т. е. "ошибки" стали проще)

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

Меры по улучшению ситуации:

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

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

Лепский Игорь

Как мне кажется, здесь налицо проблемы чисто функциональной модели организации ИТ-службы. Каждое ИТ-подразделение функционирует самостоятельно, выполняя и перевыполняя свои целевые показатели. Соответственно, метрики руководителей каждого из подразделений также выполняются. Все в поте лица закрывают свой участок не особо интересуясь что делают соседние подразделения и что получится в результате.  Возникает классический вопрос – «Кто шил костюм?». Ни к одной из функций претензию предъявить невозможно. «Пуговицы пришиты намертво.»

Напрашивается вывод о целесообразности изменения модели путем внедрения в той или иной мере элементов процессной или сервисной модели.

Цель – добиться организации комплексного выполнения и сквозного контроля каждого процесса оказания услуги и соблюдения SLA с целью максимального удовлетворения пользователя.