Проблема двойного руководства
#dailygrowth — Сколько людей у тебя в отделе? — Двадцать два, разделены на 2 подразделения.
— А чем эти подразделения отличаются? Зачем плодить сущности и руководителей? Давай объединим и оставим одного! Экономия налицо! — Одни занимаются поддержкой пользователей на местах, другие — удалённой. Но функционал действительно очень похож.
— Таак... А как заявки распределяются? В ITSM-системе у них разные группы исполнителей? — Нет, зачем? Группа одна — они обслуживают одни и те же бизнес-сервисы. Заявки распределяются между исполнителями.
— Тем более! Одна группа — значит, можно объединить подразделения! А если заявка не назначена? Что тогда? — Исполнитель должен сам её забрать в разумный срок. Если нет — вмешивается руководитель и распределяет вручную.
— Так какой из двух руководителей распределяет? У них же вечная путаница: кто должен брать заявку? Вечный пинг-понг! Однозначно надо объединять и убирать лишнего руководителя! — Не-не-не! Всё продумано! Да, в ITSM они в одной группе, но оказывают разные услуги в рамках одних сервисов! Одни заводят пользователя, другие настраивают его рабочее место! Услуга в заявке сразу определяет исполнителя — и SLA-статистика по сервисам просто собирается, так как группа общая!
Боже, храни автоматическую маршрутизацию по услугам!.. А как вы считаете — может, всё-таки что-то объединить?👇
Из болота к звездолёту
· 11.05.2025
Полагаю неверно выстроено деление функционала. Мб стоило разделить на эникеев и админов. Раз одни настраивают армы, а другие заводят в систему. Выгнать вторых из ветки заявок. Чтобы на них заявки переводили первые. Организовать подобие 1 и 2 линии. И да, в такой иерархии руководители групп смотрятся эффективнее.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён