[Из песочницы] Мониторинг заявок в ИТ. Проще чем бургер
Случилось так, что назначили меня начальником ИТ отдела. В бытность того времени я занимал должность начальника группы разработки и эксплуатации электронных информационных систем, и, благодаря то тому что вся группа на тот момент состояла из одного человека — меня, я легко с ней управлялся. Однако же мои рационализаторские таланты не прошли мимо руководства, и, в период реорганизации компании, группу ИТ (с парой админов и начальником) решили вывести из под отдела инженерно-технического департамента и сделать отдельный ИТ отдел. Меня же в свою очередь вывели из отдела обеспечения качества (не спрашивайте, что там делала группа РЭЭИС) и сделали начальником этого «новосозданного» отдела. С одной стороны, это тешило самолюбие. С другой стороны, помимо той работы, которую я выполнял, мне еще придется заботиться о ковриках для мышек, и «у меня курсор не мигает» … Отказаться тоже было не особо возможно. Собственно, мне просто положили на стол приказ о том, что теперь я начальник. Предполагая, что количество работы от этого назначения не уменьшится, я уведомил начальство (которое, видимо, думало, что я ничем не занимался), что руководить группой у меня скорей всего времени не хватит, хватит только управлять. Начальство махнуло рукой — для него видимо разницы не было.Вступив в должность, я быстро уволил обоих админов, оставив более сообразительного начальника группы, и вместо двух не шибко расторопных нанял одного, как мне тогда казалось более расторопного. Все, бинго, я начальник, управленческие решения приняты, осталось два замечательных работника, сообразительных и мотивированных. Если что нужно будет помочь — звоните, всегда помогу. А сейчас позвольте — вы умные взрослые люди, занимайтесь своей работой, а я пошел дорабатывать свои корпоративные системы.
Так все и шло некоторое время. Мне казалось, что я управляю процессом, и на пике сложностей, когда моим сотрудникам необходима помощь, прихожу как супермен-спасатель, а рутинно все качественно и здорово работает само по себе. Им казалось — начальство далеко, мы представлены сами себе и нехай так будет. (Партисипативный стиль управления, ога…)
Спустя же какое-то время меня стали дергать по любому поводу. Сеть не подключается, ворд не открывается, картридж не меняется, и мышка не ездит. Вы же из ИТ отдела? Кому какое дело, что начальник — мне работать надо! Особенно удручал тот факт, что звонившие уже один или несколько раз обращались в службу поддержки, но админы забывали о них, поскольку выполняли какую-то другую работу или просто забивали. Внушения и нагоняи админам в этой ситуации разумеется бесполезны. Начал назревать момент, когда стала необходима классическая очередь заявок в ИТ отдел.
Руководителем ИТ я был новоиспеченным и понятия не имел о ITSM, однако, как Хосе Аркадио Буэндиа, открывший, что земля круглая как апельсин, я так же примерно себе прикинул, как должна быть организована служба заявок в ИТ. После некоторого тугодумья я нарисовал коротенький процесс.
Заявки были организованы в системе корпоративного документооборота. После создания они попадали в специальный раздел системы и рассылались на почту всем сотрудникам ИТ отдела. Руководитель группы ИТ и я могли назначать заявки на любого исполнителя или принимать их к работе, простой администратор мог только принять заявку. После выполнения работы исполнитель отмечал исполнение заявки, присваивая ей новый статус, а сотрудник, создавший заявку, должен был отметить степень своей удовлетворенности, или согласие с отменой заявки, если она была составлена не корректно.
Вид заявок в системе документооборота (в своей конечной инстанции. На описываемый момент вид был несколько другой).
Ну все, вроде все ок, процесс автоматизирован, все довольны. Ребята — вот вам система, она вам поможет. Пользователи — вот вам кнопочка — заполняйте заявки, там всего три поля, и админы тут же придут на помощь. Уфф, система налажена, работайте на здоровье, а я снова пошел заниматься процессами в системе документооборота.
Но опытный руководитель ИТ, читающий эту статью, догадается, что не тут-то было. Заявки просто начинали копиться в разделе, админы то «не увидели почтовое сообщение», то «мы не заходим в систему документооборота», то еще что-нибудь веселое. Вроде и возразить нечего и не виноват никто. Ок, хорошо же, стал организовывать еженедельное совещание, на котором разбирали каждую не закрытую заявку. Часто оказывалось что большинство заявок уже выполнено, но не отмечено исполнение, поэтому мы сидели и глупо, как в детском саду, тыкали в кнопочку «Исполнено», а в незакрытых писали комментарии о ходе исполнения. Через пару недель картина начала меняться другим образом. Заявки копились до вторника, к вечеру вторника большинство закрывалось, и в среду к 11 на совещание приходили кристально чистые админы, так что и докопаться не до чего. И тем не менее процесс не работал, приходилось именно руководить, а не управлять, и я от бессилия поскрипывал зубами.
Мне мнилась идеальная картина, в которой пользователь, если у него перестал шуршать диск или стерся коврик от мышки, писал заявку, которая мгновенно улетала админам, они мгновенно распределяли кто ее будет делать, в порядке очереди исполняли ее, а пользователь тут же отмечал свою удовлетворенность. Этот процесс представлялся мне как в макдональдсе, когда ты делаешь заказ он отправляется в систему, и сотрудники на кухне видят на мониторе что нужно приготовить, тут же свободный сотрудник готовит, а менеджер выносит довольному клиенту поднос. Мне хотелось того же — пользователь — заявка — мгновенных подхват заявки свободным админом — исполнение — удовлетворение — оргазм. В реальности же, помимо того, что половина пользователей не писали заявки, а как всегда звонили, админы еще и затягивали исполнение без особой причины.
Процессу нужна была доработка. Админы должны были видеть заявки, как только они появлялись, а кроме того, и все остальные заявки, особенно с подходящим сроком исполнения. Опять и опять у меня в голове крутилась схема работы макдональдса, и веселый монитор, с выпрыгивающими заказами. Собственно, а почему бы нет?
Некоторое время назад я инициировал переход от утлых табличных отчетов в системе документооборота, напоминающих экселевские таблицы, к куда более приятному, информативному и открывающему широкие перспективы MS Reporting Services, входящему в состав честно купленного MS Sql Server. Отчеты составляются с помощью специального средства редактирования и размещения отчетов MS Report Builder, который в своем базисе, наверное, даже и получше Crystal Reports«a, а уж дружелюбнее — точно! Кроме того, просматривать их можно прямо в браузере и конечно выгружать в любой формат.
С помощью моего коллеги, администратора баз данных, был написан отчет в MS Reporting Services, который выбирал из базы заявки, и формировал удобочитаемый экран, в первую очередь выводя заявки у которых нет исполнителя, во вторую которые надо выполнить сегодня, потом просроченные, и в порядке убывания по дате исполнения. Первые пол часа новая заявка подсвечивалась желтым, так что не заметить было нельзя. Что бы больше не апеллировать к совести админов, и даже не слушать отговорки про «не видел» — «не слышал», был взят старый ноутбук, на котором запущен браузер с отчетом (отчет обновлялся каждую минуту), и подключен к одному из списанных мониторов. А монитор, в свою очередь, повешен на стену в админской, так чтоб его было видно из любого угла. Система приобрела такой вид.
Красным отображались просроченные заявки. В карточке была исчерпывающая информация. Заявитель, ответственный, срок исполнения, номер заявки. А так же общее количество неисполненных, просроченных…
Ну теперь то все? Заявка есть, пользователь есть, админ есть, монитор есть. Что еще может пойти не так? Ведь это полностью реализованная схема макдаковского конвейера. Все звенья цепи сложились, заявка должна была катиться по этому процессу, как детки в аквапарке по желобу. Однако же не была учтена скрытая от посторонних глаз сторона процесса Мака — мотивация. Ведь на кухне у сотрудника де факто нет возможности отказаться от выполнения или затянуть время приготовления заказа, но что-то же его заставляет работать с максимально возможной скоростью. А у нас получались сплошь красные заявки, которые уже пора бы либо отменить, либо выполнить.
Когда созрело осознание этой проблемы, начало вызревать и решение. Моя задача не карать или миловать работников, я только хочу, чтобы все работало без моего участия, но в хорошем темпе и без косяков. Чего такого сложного в моем желании? Ок. Хотели мотивацию? Вот вам!
Теперь за каждую заявку стали начисляться баллы. Их, как водится, два типа — положительные и отрицательные. Положительные баллы (в размере 4 штук) начисляются за исполнение заявки. Далее идут отрицательные:-Е. За день просрочки исполнения заявки — 1 балл. За каждый дополнительный перенос срока исполнения — 1 балл. В заявке была реализована функция фидбэка от пользователя после ее исполнения, с несколькими градациями качества выполненных работ. Если отзыв пользователя отличался от «Выполнено в полном объеме и в срок», то приписывались еще отрицательные балы в зависимости от степени неудовлетворенности пользователя. Монитор принял такой вид (я взял февральский отчет, поэтому даты заявок красные):
Отдельно были выделены заявки, которые имеют отношение к закупкам, поскольку объективно админы не отвечают за сроки согласования и доставки заказанного оборудования.
Появилась договорённость, что через три месяца после введения данной системы баллы за заявки будут приниматься как объективное качество выполнения работы администраторами, и квартальная премия будет начисляться в соответствии с пропорциями положительных и отрицательных баллов. 90% положительных баллов — 100% премии. Затем, премия снимается пропорционально увеличению отрицательных баллов сверх 10%.
Баллы считаются всегда за последний квартал, т.е. по тем заявкам, которые были закрыты за предыдущие три месяца, что обеспечивает всегда актуальную информацию, и серьезно мотивирует, особенно ближе к премии. Однако же система получается построена так, что для получения премии в полном объеме работать надо все время в течении квартала, а не только под конец.
В целом работа этой системы эффективна. Появился процесс, которым можно управлять, регулировать потоки. Сложности возникли с приучением пользователей создавать заявки, но это разрешилось достаточно быстро, поскольку сразу стало заметно, что админы гораздо быстрее реагируют на заявки, созданные в системе, а не полученные в коридоре. После написания инструкции для пользователей я разрешили администраторам вообще не выполнять заявки, полученные вне системы, либо, если у пользователя нет возможности создать заявку, создавать их самим.
Этой статьей я хотел поделиться интересным опытом, который возможно где-то уже доведен до совершенства. Если это так, поделитесь своим опытом — как заставить людей работать добровольно, качественно и с полной отдачей.
Жду не дождусь отзывы людей, которым в своей суровой жизненной реальности довелось, так сказать, узнать кухню МакДональдс изнутри, т.е. поработать в системе быстрого питания. Расскажите, какие методы стимулирования и мотивации можно почерпнуть, что бы реакция на инциденты в сфере ИТ напоминала приготовление аппетитного бутерброда, и пользователь от админов был удовлетворен не меньше чем от сочного бургера.
Комментарии (1)
2 августа 2016 в 11:38
0↑
↓
Я правильно понимаю, что вы рассказываете, как придумывали ITIL?
