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

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

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

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

Руководителем ИТ я был новоиспеченным и понятия не имел о ITSM, однако, как Хосе Аркадио Буэндиа, открывший, что земля круглая как апельсин, я так же примерно себе прикинул, как должна быть организована служба заявок в ИТ. После некоторого тугодумья я нарисовал коротенький процесс.

image

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

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

Ну все, вроде все ок, процесс автоматизирован, все довольны. Ребята – вот вам система, она вам поможет. Пользователи – вот вам кнопочка – заполняйте заявки, там всего три поля, и админы тут же придут на помощь. Уфф, система налажена, работайте на здоровье, а я снова пошел заниматься процессами в системе документооборота.

Но опытный руководитель ИТ, читающий эту статью, догадается, что не тут-то было. Заявки просто начинали копиться в разделе, админы то «не увидели почтовое сообщение», то «мы не заходим в систему документооборота», то еще что-нибудь веселое. Вроде и возразить нечего и не виноват никто. Ок, хорошо же, стал организовывать еженедельное совещание, на котором разбирали каждую не закрытую заявку. Часто оказывалось что большинство заявок уже выполнено, но не отмечено исполнение, поэтому мы сидели и глупо, как в детском саду, тыкали в кнопочку «Исполнено», а в незакрытых писали комментарии о ходе исполнения. Через пару недель картина начала меняться другим образом. Заявки копились до вторника, к вечеру вторника большинство закрывалось, и в среду к 11 на совещание приходили кристально чистые админы, так что и докопаться не до чего. И тем не менее процесс не работал, приходилось именно руководить, а не управлять, и я от бессилия поскрипывал зубами.

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

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

Некоторое время назад я инициировал переход от утлых табличных отчетов в системе документооборота, напоминающих экселевские таблицы, к куда более приятному, информативному и открывающему широкие перспективы MS Reporting Services, входящему в состав честно купленного MS Sql Server. Отчеты составляются с помощью специального средства редактирования и размещения отчетов MS Report Builder, который в своем базисе, наверное, даже и получше Crystal Reports’a, а уж дружелюбнее – точно! Кроме того, просматривать их можно прямо в браузере и конечно выгружать в любой формат.

С помощью моего коллеги, администратора баз данных, был написан отчет в MS Reporting Services, который выбирал из базы заявки, и формировал удобочитаемый экран, в первую очередь выводя заявки у которых нет исполнителя, во вторую которые надо выполнить сегодня, потом просроченные, и в порядке убывания по дате исполнения. Первые пол часа новая заявка подсвечивалась желтым, так что не заметить было нельзя. Что бы больше не апеллировать к совести админов, и даже не слушать отговорки про «не видел» — «не слышал», был взят старый ноутбук, на котором запущен браузер с отчетом (отчет обновлялся каждую минуту), и подключен к одному из списанных мониторов. А монитор, в свою очередь, повешен на стену в админской, так чтоб его было видно из любого угла. Система приобрела такой вид.

image

Красным отображались просроченные заявки. В карточке была исчерпывающая информация. Заявитель, ответственный, срок исполнения, номер заявки. А так же общее количество неисполненных, просроченных…

Ну теперь то все? Заявка есть, пользователь есть, админ есть, монитор есть. Что еще может пойти не так? Ведь это полностью реализованная схема макдаковского конвейера. Все звенья цепи сложились, заявка должна была катиться по этому процессу, как детки в аквапарке по желобу. Однако же не была учтена скрытая от посторонних глаз сторона процесса Мака – мотивация. Ведь на кухне у сотрудника де факто нет возможности отказаться от выполнения или затянуть время приготовления заказа, но что-то же его заставляет работать с максимально возможной скоростью. А у нас получались сплошь красные заявки, которые уже пора бы либо отменить, либо выполнить.

Когда созрело осознание этой проблемы, начало вызревать и решение. Моя задача не карать или миловать работников, я только хочу, чтобы все работало без моего участия, но в хорошем темпе и без косяков. Чего такого сложного в моем желании? Ок. Хотели мотивацию? Вот вам!

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

image

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

Появилась договорённость, что через три месяца после введения данной системы баллы за заявки будут приниматься как объективное качество выполнения работы администраторами, и квартальная премия будет начисляться в соответствии с пропорциями положительных и отрицательных баллов. 90% положительных баллов — 100% премии. Затем, премия снимается пропорционально увеличению отрицательных баллов сверх 10%.

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

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

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

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

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


  1. Netmoose
    02.08.2016 11:38
    +3

    Я правильно понимаю, что вы рассказываете, как придумывали ITIL?


    1. dskozin
      02.08.2016 13:26

      Да. Я даже упомянул об этом. )


  1. questor
    02.08.2016 12:06

    что руководить группой у меня скорей всего времени не хватит, хватит только управлять.

    и


    приходилось именно руководить, а не управлять, и

    В чём разница?


    1. ifaustrue
      02.08.2016 12:43
      +1

      ##sarcasm
      Видимо у управленца хватает времени на написание статей на хабр, у руководителя уже нет…


    1. dskozin
      02.08.2016 13:34

      Примерно как между прорабом и архитектором.


    1. AdmAlexus
      02.08.2016 13:35
      +1

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


  1. osj
    02.08.2016 13:18
    +1

    Т.е. для начала нужно удалить двух админов и нанять одного толкового, потом: ой, а че это звонки мне, начальнику, поступают. Надо что то делать. Надо затянуть пояса(пояс) админу, чтобы был еще рассторопнее. Делаем баллы и рейтинги. Больше закрытых заявок — больше премия. Больше скрытых бомб, больше зп при их решении.


    1. dskozin
      02.08.2016 13:33
      +2

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


      1. toto20002
        02.08.2016 15:10

        Вообще я исповедую принцип, что хороший админ вообще работать не должен

        ИМХО, Если это выполняется, то это застой, значит нет ни развития бизнеса, ни развития админа.
        У нас 4 админа, и ВСЕГДА есть работа, если нет каких то внедрений нового ПО или сервисов, то значит что-то улучшаем (автоматизируем процессы, увеличиваем надежность, улучшаем безопасность и т.д)


        1. dskozin
          02.08.2016 15:12

          Застоя вообще не бывает. Есть движение либо вверх либо вниз. Естественно, если не заниматься постоянным улучшением — то потом будет очень много работы.


          1. foxmuldercp
            02.08.2016 23:10

            Более интересной и более оплачиваемой, как правило. Вот как у меня сейчас — сапорт — хостмастер — а сейчас пишу свое решение по управлению хостингом


        1. foxmuldercp
          02.08.2016 23:10

          Тоесть, Вы считаете, что раз у меня работает несколько десятков сервисов хостинга и я о их работе знаю исключительно по настроенному сколько то летназад мониторингу, чтобы найти себе работу я должен искать новых клиентов хостинга? или может это всё таки задача менеджера и маректолога?
          А может я всётаки займусь более полезными и вообще не админскими задачами по программированию, и напишу пару внутренних систем на радость автоматизации?

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


  1. maxbatura
    02.08.2016 13:26

    В Макдональдсе всё работает не так, как вы предположили в статье. Монитора с заказами там нет. Есть человек ответственный за кухню, он и следит за наличием готовой продукции. + на основании статистических данных количества посетителей в разное время дня известно сколько готовых бургеров/салатов/ролов и.т.д. нужно держать в запасе т.к. время хранения ограничено. В итоге — это реально конвейер.

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

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

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


    1. dskozin
      02.08.2016 13:41

      Хм, правда?
      Мне казалось что у них висят там мониторчики с заказами что приготовить. Может это новинка или в другой закусочной?


      1. melvin
        02.08.2016 14:09

        Такое есть в DODO PIZZA. Новомодная ИС.


      1. maxbatura
        02.08.2016 14:33

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

        С описанным подходом с мониторами я замечал только пиццерии.

        P.S. Работал в 2008 году в макдональдсе в Киеве. За это время принцип их работы не изменился. + мясо на гриле готовится около 35 секунд, + максимум секунд 25 на то, чтобы собрать/упаковать бургер. Готовые хранятся насколько помню не больше 15 минут. На обслуживание клиента по стандарту времени немного, около минуты, что невозможно если сначала взять заказ и только потом начать его готовить.


      1. olegpisarev
        02.08.2016 17:06

        Такой подход точно есть в KFC.


      1. ahimenid
        05.08.2016 04:36

        Примерно такая система есть в нашей сети ресторанов(хотя есть подозрение, и оно оправдано, так у многих) на сервере демон, ловит свои пакеты с POS терминала(официанты делают заказ блюда\блюд), обрабатывает, и бродкастит обратно в сеть, и уже клиенты с мониторчиками (марочники) ловят пакеты, «свои» обрабатывают — выводят на экран, не свои игнорируют. Соответственно в BOH настроено время приготовления блюд.Есть учет просрочек, времени приготовления(?speed of service?) как инструмент контроля кухни. много много всего в этой системе, и совсем не хотелось бы систему «кнутИпряник» на её основе, но это взгляд снизу.


  1. Exigo
    02.08.2016 13:26

    Вопрос такой, заявки по «весу» были одинаковые? Т.е. за разный тип заявок, давалось одинаковое количество «баллов», не было ли проблем с тем что админы перехватывали друг и друга мало затратные заявки, по времени, и тем самым образовывался дисбаланс?


    1. dskozin
      02.08.2016 13:29

      Да, было. На это есть руководитель группы, который может решить кому какая заявка.
      Вообще ситуация получалась, что они поддерживали друг — друга отдавая малозатратные заявки в случае недобора баллов. А так просто каждый занимается тем, что у него лучше получается.


      1. Exigo
        02.08.2016 14:33

        Ну тогда Вам повезло с совестью у админов, просто ситуация могла сложиться совсем иная)


  1. Sergey-S-Kovalev
    02.08.2016 13:37

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

    У Вас первая ошибка в том, что вы свой документооборот пытаетесь затолкать контроль заявок, для этого лучше взять что нить готовое из коробки вроде ManageEngine ServiceDesk. И не нужно потом будет прикручивать какие то отчеты, рабочие процессы, интеграции с внешними системами.
    Вторая ошибка, говорить «Ну ладно, нужно что то придумать еще» на "Заявки просто начинали копиться в разделе, админы то «не увидели почтовое сообщение», то «мы не заходим в систему документооборота»", хотя оно может вытекать из первого пункта. Иногда, чужими самописными продуктами пользоваться просто жесть. Лишние клики, поля, согласования, требования. Т.е. ты вместо почти автоматической фиксации работ занимаешься электронным бумагомараньем делая кучу ненужных движений, каких то согласований, подтверждений.

    В любом случае инструмент есть, и в нем должны работать. Не запущенный сервисдеск или почта это йенг забитый на работу. Это равнозначно отключенному телефону. И отсутствию сотрудника на рабочем месте.

    А что до KPI, то нужно всего лишь указать категории задач, задать по ним SLA, и перед каждой квартальной премией проходиться по всем заявкам где нарушен SLA для конструктивного анализа, после чего определять размер премирования или депремирования. Естественно после периода тестирования и подтверждения того, что сотрудники понимают как это происходит, да и что система вообще прозрачна для всех.


    1. dskozin
      02.08.2016 13:49

      Да в общем я и постарался запустить сервис деск сразу, только без использования коробочных решений. Никто в компании (в том числе руководство) не стал бы делать это в отдельной системе. Сложности возникают даже несмотря на то, что реализовано в знакомой им системе, даже с учетом того что горячая кнопка заявки находится на главной странице, и что заполнить надо три поля — тип (выбор из справочника), желаемая дата исполнения (выбор из дата-пикера) и описание проблемы (тут уж руками). Никаким новым продуктом никто пользоваться вовсе не будет включая высшее руководство. Да и вторая ошибка — не вытекает из первой. Можно было сделать что угодно — это же наша система. Вопрос в том что некоторым не хочется ничего ни при каких условиях.
      А про SLA — это ценный совет! Наверное что-то попытаюсь сделать в этом роде…


      1. Sergey-S-Kovalev
        02.08.2016 20:20

        Не заставляйте людей работать исключительно на портале. У нас порядка 99% заявок приходит исключительно по почте. Она проще и понятнее для всех. Отправил письмо с описанием и скриншотом на help@, сразу же получил номер тикета от автоответчика. Потом, после выполнения, приходит письмо о том, что заявка закрыта и комментарий от специалиста приложен. Люди вообще на портал не ходят почти. От них требуется проблему обозначить, от нас не потерять ее и решить.

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


    1. las68
      02.08.2016 13:56

      В защиту автора. Хорошо рассуждать, в отрыве от реальных условий. Все, в той или иной мере, знают ITIL, но его последняя буква — это Library, вы в этой библиотеке берёте некоторую книжку процессов, в которой всё хорошо и логично описано, но выясняется, что эта книжка в применении к вашей реальности не содержит конкретных рецептов типа «На 30 заявок в сутки возьмите двух сисадминов, хорошенько перемешайте, сверху посыпьте измельченным сетевым инженером и отправьте в печь на полчаса». Поэтому всё идёт методом проб и ошибок. Замечательно, если есть система мониторинга, которая умеет заводить тикеты и отправлять их в сервисдеск. Замечательно если сервисдеск не стоит ни копейки, при этом умеет сам разбираться с приоритетами и направлять заявки на инженеров, и если при этом он еще умеет отслеживать геолокацию и распределять заявки так чтобы инженер с объекта на объект перемещался по оптимальному маршруту. Но, обычно, этого нет, либо есть, но стоит небюджетных денег.

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


      1. Sergey-S-Kovalev
        02.08.2016 20:39

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

        Вы от сервисдеска уходите в IT Service Intelligence. Возвращайтесь с небес на землю :)
        Автор, на мой взгляд, до сих пор слишком мягок в вопросе управления. Я не говорю, что нужно сразу и всех депремировать, но регулярная отмазка у админа про незапущенную почту и сервисдеск не нашла бы у меня понимания. Люди с такими отмазками у нас в зарплате и по карьерной лестнице не растут и обычно перемещаются на удаленную площадку в качестве эникейщика.


        1. las68
          03.08.2016 05:28

          Вы мне написали тоже самое, что я вам написал, но другими словами.

          мягок в вопросе управления

          Руководитель с опытом как раз должен хорошо понимать, где надо давить, а где давить не стоит. Он должен хорошо понимать, где нормальному выполнению задачи мешает раздолбайство, а где отсутствие ресурса — нехватка людей, времени, знаний, инструмента. Проще всего спрятаться за формальную сторону: «Не сделал? Депремирован, уволен». Шашкой махать — это самое лёгкое. Найти корневую причину и устранить ее, либо минимизировать последствия — это задача поинтереснее будет.

          Хотя организацию работ никто не отменял. Во время работы в «Альфа-банке» в приснопамятные 90-е, по банку был приказ, что сотрудник обязан читать почту в 9.00, 14.00, 17.00, распоряжения поступающие по корпоративной почте приравниваются к письменным. Ссылки, про «я был на выезде»,«на встрече с клиентами» не принимались.


    1. AVX
      02.08.2016 14:09

      Полностью согласен с Вами!
      Но попробую очень кратко описать как было у нас на работе. Изначально так — звонки пользователя, ближайшие территориально сотрудники разбираются, что нужно сделать, делают, или созваниваются-переписываются с другими отделами, внешними разработчиками и т.п. В принципе, всё работало, и достаточно оперативно. За качество не приходилось беспокоиться, т.к. каждый знал, что делать надо всё на совесть, иначе потом тебя же вызовут в 3 часа ночи доделывать-переделывать, а потом ещё премию срежут.
      Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager, с огромными доработками (по ходу эксплуатации). Внедрено всё: ITIL, SLA, KPI… Пользователей обязали звонить только на единый телефон службы поддержки, которая уже раздавала обращения в SM, начальники отделов раскидывали по исполнителям (или исполнитель сам мог забрать, если видел, что это в его компетенции). От звонков напрямую на 90% избавились лишь лет через 6-7, но и после всё ещё звонят напрямую, особенно оперативные рабочие места.
      Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек». Дальше внедрение процессного подхода (в большинстве случаев в нашем деле бесполезное занятие, это не конвейер), распределение сроков по разным видам работ, ну и наказания за просрочки, и другие.
      Дальше — больше, и в текущем состоянии эта система представляет собой неповоротливого монстра, с множеством связей с системами мониторинга (которые тоже автоматически могут генерировать заявки на устранение каких-то неисправностей), и с системами учёта кадров (SAP), по ней же отслеживается загруженность работников, в том числе в разрезе по разным видам работ, и строится прочая разнообразная статистика. Так вот, бывает ложь, бывает наглая ложь, а бывает статистика. А ещё бывает статистика, выведенная из этой системы.
      В итоге

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


      1. DmitryMironov
        02.08.2016 21:21

        Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек».


        Метрики и должны периодически меняться/пересматриваться, так как:
        1. Метрики должны быть нацелены на то что важно для компани в данный момент. Скорость назначения на админа — меряем скорость назначения, скорость закрытия заявки — меряем скорость, количество заявок — меряем количество и т.д.
        2. Скажи как оценивается/изменяется моя работа, я сделаю все чтобы эта метрика было всегда отличная, наплевав на реальное качество. Всегда сотрудники будут подгонять процессы под метрики.

        наказания за просрочки

        Может лучше сделать премирование за хорошее качество, скорость и т.д.?

        Пользователей обязали звонить только на единый телефон службы поддержки

        и это правильно. Менее хорошее решение — писать в СервисДеск на почту (тотже ServiceDeskPlus умеет это из коробки).


        1. AVX
          03.08.2016 08:13

          писать в СервисДеск на почту (тотже ServiceDeskPlus умеет это из коробки).

          Да, я неверное про это не написал, там можно и на почту, и через веб-интерфейс заявки давать. Просто имел ввиду, что запретили звонить напрямую, а если и звонят, то всё равно нужно оформлять заявку.


      1. Sergey-S-Kovalev
        02.08.2016 22:04

        ох, опять полотенце получилось:

        | Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager
        Уже сочувствую.

        | с огромными доработками (по ходу эксплуатации).
        Ужасный неповоротливый монстр. Консольный интерфейс создан что бы специалисты страдали. Для постоянного допиливания нужен отдельно обученный человек. Для обучения использования спецов и пользователей — без курсов никак.
        Евангелисты hpe прям светятся, когда рассказывают. Особенно их торкает от красиво вращающихся менюшек. На вопросы почему окно в котором идет основное описание заявки размером с два спичечных коробка, а скриншот вставленный в письмо появляется на отдельной вкладке и его можно посмотреть только в виде прикрепленного файла через какой нить вьювер — ответить не могут. Почти все скопировано с MS Service Manager (или наоборот, я не знаю). В обоих в системе заявку закрываешь дольше чем в занимаешься работами по заявке.

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

        У нас основные каналы вхождения проблем это почти всегда электронная почта, редко портал и почти никогда звонки. Диспетчера нет, 80%+ заявок разруливают бизнес-правила, остальное начальники групп. Мы аутсорсеры, поставщики оборудования и ПО, разработчики, у нас есть свой ЦОД. Много предприятий и организаций на поддержке. Где то мы полностью рулим ИТ включая бюджетирование и развитие, где то на предприятих есть только начальник ИТ, все остальное наше, где то наши только сисадмины, где то только скуд, монтаж и сервис от нас.
        В сервисдеске дикий микс из групп по организациям и направлениям деятельности. Точка входа одна. Портал для всех единый, но естественно каждый начальник и специалист видит только заявки по области относящиеся к нему. База знаний общая. Отделы ИТ некоторых предприятий сами полностью сидят в нашем сервисдеске, им их пользователи шлют задачи.

        MS Service Manager пытались внедрить для внутренних процессов — не взлетел, у пользователей и ИТ спецов вызывал изжогу. Партнерка позволяет использовать, а не получилось.
        HP Service Manager и LanDesk делали презентации и демо, предлагали тестовую интеграцию, но после описания структуры работы и движения заявок дело затухало. Брали паузу так сказать. Да и дорого.
        Жира больше по проектным вещам, OTRS нужно допиливать слишком сильно, 1С Итилиум — привязка к 1С, а она не у всех есть. В итоге сидим на том, что я написал выше. Очень быстрое, достаточно гибкое. Не заставляет тебя поднимать кучу серверов и сервисов что бы тупо первую заявку зарегистрировать. 30 минут вместе с авторизацией по LDAP на взлет, ставь хоть на свой ПК. Официально до 100 одновременно работающих спецов бесплатно (но есть хинт — можно написать менеджерам и получить столько сколько нужно, правда рекламой завалят, представительства в России нет :) ), ограничения на количество учеток клиентов нет как и ограничения на задач в день/месяц. Проблем с обучением новых специалистов нет, две тестовых заявки и спец уже готов в нем орудовать тут же. Шаблоны отчетов из коробки, график, диаграмы, автоматическая рассылка. Есть модули по управлению закупками, активами, изменениями и портал самообслуживания за отдельное бабло. Там у разработчиков прям комплекс типа ситемцентра мелкомягкого, но сильно дружелюбнее к ИТшникам и ресурсам ваших серверов.

        Про ITIL, SLA, KPI тоже скажу — всем нас#много#, особенно заказчикам. Всех интересует конечный результат без касяков и вовремя. Про показатели вспоминают только, если что то пошло не так, но при наличии протоколирования выполнения работ, почти всегда выясняется, что заказчик сам где то прокасячил.

        Средняя нагрузка ~1200-1500 запросов и инцидентов в месяц, при том, что комплекс мониторинга в общем то в сервисдеск автоматом ничего не шлет.


        1. las68
          03.08.2016 05:30

          Вы ещё про бюджет внедрения и стоимость лицензий на HP SM озвучьте и небольшие конторы тут же Кондратий обнимет. Такой SM никому не нужен.


          1. Sergey-S-Kovalev
            03.08.2016 06:25

            MS/HP SM не предназначен для небольших организаций. Ни по деньгам, ни по идеологии.


            1. las68
              03.08.2016 06:38

              В исходной статье админов 3 человека, мне тоже интересно стало — при чём тут HP SM?
              А вот решения для небольших компаний — это гораздо интересней и ближе к теме.


              1. Sergey-S-Kovalev
                03.08.2016 08:53

                AVX поделился своим опытом, за что ему большое спасибо. И организация, судя по всему у него большая и территориально распределенная… и/или богатая :)


        1. Andreyc4d
          03.08.2016 12:08

          В итоге сидим на том, что я написал выше.
          — это ManageEngine ServiceDesk?


          1. Sergey-S-Kovalev
            03.08.2016 13:18

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


  1. pawellrus
    02.08.2016 13:56
    -1

    А мне интересно, почему в данной статье эникейщиков обозвали админами? И если они и правда админы, то почему они занимаются тасканием компов, закупкой картриджей и вообще беготней по пользователям?


    1. las68
      02.08.2016 13:59
      +2

      Для небольших компаний эникейщик, не только сисадмин, но еще и сетевой инженер и «1С-прогроммист», а иногда и метролог и инженер по АСУТП. И начальник отдела, как правило — не освобождённый.


      1. AdmAlexus
        02.08.2016 14:40

        Не забудьте сюда же включить обязанности инженера по ИБ и инженера по ТБ:) А, еще, чуть не забыл — контрактного управляющего:)


        1. dskozin
          02.08.2016 15:05
          +2

          А так же и управление контролем доступа, видеонаблюдением…


          1. las68
            02.08.2016 15:30
            +2

            … и пожарно-охранной сигнализацией, там же проводочки и печатная плата стоит, такая зелёная. «Мы-то, бухгалтеры, откуда знаем, что там? это программисты должны знать..»


  1. melvin
    02.08.2016 14:02

    Управленец работает в системе, контролирует сотрудников и следует правилам, а руководитель работает над самой системой, мотивирует сотрудников и изменяет правила.


  1. andrzzc
    02.08.2016 14:10
    +2

    Как пользователь схожего сервис-деска, опишу минусы.
    1. Все, что можно будет сделать более легким путем, будет сделано более легким путем.
    2. Зарплата в зависимости от количества/качества заявок — ведет к конкуренции между работниками за количество «баллов» но не за качество работы. Стараются перехватить самые легкие заявки от самых неконфликтных и сговорчивых клиентов. Конкуренция между работниками не всегда честная.
    3. Зарплата в зависимости от просроченных заявок — ведет к тому что заявки принимают в коридоре и выполняют по мере возможности, а потом оформляют официально, «задним числом». Чтобы на бумажке все было красиво и начальник был доволен.
    Сюда же можно добавить работу «тяп-ляп» — если горят сроки, никто не будет делать «чтобы было хорошо», сделают абы как, даже зная что косячные последствия всплывут через полгода (все равно исправлять будет другой).
    4. Появляется имитация бурной деятельности — мелкие работы, которые раньше делались мимоходом за 5 минут, теперь оформляются в официально-бумажном виде аля «пропала кнопка в ворде — оформляем заявку на лечение вирусов, работаем, работаем...»
    5. Ухудшение взаимоотношений с клиентами. Представьте, что позвонили в Сбербанк уточнить списания с карты за полдня, а вам говорят «я без заявки не могу — заходите на сайт, оформляйте заявку...».
    6. Саботажные заявки =) У кого есть доступ, могут без проблем организовать нужному пользователю пропадание кнопки в ворде — и халявная заявка готова, а настоящую причину обнаружить будет крайне сложно…


    1. IPronkin
      02.08.2016 14:20

      Гибкой отчетности не хватает.


    1. AVX
      02.08.2016 14:34

      И тут соглашусь, но есть кое-где решения:
      1. Это на самом деле плюс. Если задача будет выполнена надлежащим образом, почему бы не сделать её более простым путём? Или время исполнителя ничего не стоит, и его можно нагрузить делать то, что не нужно?
      2. Здесь нужно ИТ-специалистов разбивать на функциональные группы/отделы, и заявки чтобы маршрутизировались в нужный отдел, где сделать автораспределение — чтобы ни один специалист не простаивал, и была более-менее равномерная загрузка. Конечно, если начальник отдела решит, что ту или иную задачу может сделать конкретный специалист — ему и переназначит явно.
      3. Если по п.2 у специалиста просто не будет времени принимать какие-то другие заявки, то и не будет «заявок в коридоре». А если и будут, и пользователь согласен подождать — никто не будет в минусе. Работа была нужна? Работа выполнена? пользователь доволен? — да хоть сам оформляй. Главное чтобы была обратная связь (например, в почту пользователю приходил запрос на закрытие обращения, и возможно с указанием оценки).

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

      Тут нужно организовать так, чтобы каждое обращение было привязано к определённому месту, и можно было бы потом отследить, кто и что делал на этом рабочем месте (или к пользователю привязать, вариантов много разных). Тогда каждый будет знать, что история сохраняется, и при наличии косяков могут докопаться. Даже если не докажут, но частые проблемы с рабочим местом после работы определённого специалиста уже может навести на мысль и присмотреться к работе этого человека.
      4. Такое проявляется только когда ИТ-специалист не загружен другими работами, и нет плановых сроков по определённым типам работ (хотя это мне и самому не нравится, но в какой-то мере должно присутствовать).
      5. Если зайти на сайт и сделать заявку быстрее и удобнее чем звонить — люди сами будут так делать. А если там надо заполнять кучу непонятных полей и ещё и баги присутствуют — то вот и будет ухудшение взаимоотношений, или пойдут звонки напрямую специалистам (если знают телефоны).
      6. Классифицировать заявки по «запрос», и «инцидент». Если что-то не работает, или плохо работает — классифицировать как инцидент, а инциденты впоследствии анализировать и вводить меры для снижения их количества. Конечно и тут останется поле для деятельности — сговор с пользователем («скажи, что надо хром поставить, а я попозже подойду и твой синий экран исправлю»), или корректировка/скрытие инцидентов, чтобы выглядело всё красиво.

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


      1. andrzzc
        02.08.2016 15:07

        1. Надлежащим образом это «пофиг как лишь бы клиент был доволен» (практически так и прописано в официальном SLA), вплоть до того чтобы мозги клиенту промыть и убедить его писать в блокноте вместо ворда. Зато отчетность хорошая :)


        1. las68
          02.08.2016 15:38

          Это уже «little dirty things», но так делается, да.


  1. artemsafe
    03.08.2016 10:28
    +1

    Прости Автор, но вы создавали велосипед, вместо того чтобы прочесть хотя бы одну книжку по тому что уже 100 лет назад было придумано…


    1. Andreyc4d
      03.08.2016 13:11
      +1

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


  1. ModoStudio
    03.08.2016 10:32

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

    И вот тут начинает вылезать некомпетентность и полный аншлаг. Вместо нормального хэлпдеска, для управления IT отделом, автор за основу берёт электронную систему управления кухней общепита. WTF!!!?? За основу управления IT отделом взят процесс управления кухней Мака! Причём только видимая для покупателя часть! Почему общепит? почему именно Мак? Чем хуже Бургеркинг или KFC? Почему не Uber, Яндекс такси, или DHL? Реализуется эта система старым ноутбуком и монитором, который весит «на видном всем месте».

    Чем занимается ваша компания? Это стоматологическая клиника, которая делает кузовной ремонт?

    Чтобы была эффективность, для начала каждый должен быть на своём месте! И каждому должна быть интересна его работа! И вам, и админам! И мотивация должна быть денежная, а не галочками, плюсиками, оценками, бабочками и баллами, которые в лучшем случае раз в квартал превратятся в копейки. И для управления IT отделом, нельзя ставить директора школы, который для своего удобства за основу управления введёт электронные дневники. Или прораба у которого система автоматизации — это крепкое словцо, арматура и стенгазета. Или как в вашем случае вообще Мак.

    По вашему описанию, я понял, что у вас навыков управления нет вообще. А вам поручили IT отдел. И насколько я понял, с такой же лёгкостью поручили бы отдел продаж или бухгалтерию или вести склад.

    Вы пытаетесь что-то изобрести, чтобы не дергали вас. Админы всеми способами филонят и делают всё чтобы не дергали их. И в качестве оружия между вами — это интерфейс заказов Макдака. Если вашу историю перевести в кинематограф, получится такой же треш, как это: https://www.youtube.com/watch?v=JS2UaC9G910

    ИМХО. Без обид!


    1. dskozin
      03.08.2016 10:41
      +1

      Вашими устами да мед бы пить. Естественно везде и всегда люди должны заниматься своим делом, однако же такое случается в подавляющем меньшинстве случаев.
      По поводу навыков управления — да совсем нет, учитывая, трудовую деятельность с 2009 года на должностях: начальник производства, заместитель руководителя, начальник группы разработки и наконец начальник ИТ отдела, и участие в президентской программе подготовки управленческих кадров.
      Просто я предпочитаю подходить к делу творчески, пусть и изобретая велосипед. Вы думаете возможно развернуть полноценную ИТ службу в той компании где я сейчас тружусь по всем стандартами ИТИЛа, включая управление конфигурациями, оборудованием, инцидентами, услугами, безопасностью? Нет, уверяю, не возможно.
      Наверное вы работали в компании где ИТ отдел в 50 человек, и управлять им было возможно по всем стандартам. Мне же увы приходится делать малину из того что есть. Да и этого не достаточно… :-/


      1. ioneyaqoo
        03.08.2016 15:08

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

        а я пошел дорабатывать свои корпоративные системы

        По сути статьи хочу добавить, что мотивация выбрана неверно. С Вашим подходом получается, что ИТ-службе выгодно наличие большого количества однотипных простых инцидентов, в то время как для запросов повышенной сложности, для которых требуется навык нажатия более одной кнопки, нужно больше времени и компетенций.
        А теперь представим, что какой-то инцидент происходит с завидной регулярностью на одной и той же системе. Для чего администратору тратить, предположим, 20 рабочих часов на системный подход к проблеме, если он может получить 50 баллов, 100% премии и, в оставшееся время, пить кофе, закрыв 5 заявок суммарно за 10 минут воспользовавшись каким-то «костылем»? Потому что он профессионал и честный парень?
        По работе часто приходится сталкиваться с подобными методами «управления». Ясное дело, для бизнеса важно измерить эффективность работы службы, но это никак не может измеряться количеством отработанных запросов. Работа системного администратора должна быть направлена, в первую очередь, на сокращение числа проблем и уменьшение времени простоя сервиса, а никак не на внутреннюю борьбу за дополнительные 5 копеек к заработной плате.


    1. las68
      03.08.2016 17:46
      +1

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

      От всех иллюзий избавляет работа в крупных конторах. Типа РН-Информ. Все ретивые инженеры там научаются любить Родину, руководители среднего и крупного звена — Правильной работе с Заказчиком, легальным способам оптимизации сроков SLA, работы с доступными ресурсами — одна винтовка отвёртка на три человека. The best, когда ты с представителем Заказчика, после работы, лепите телегу в Центральный аппарат, оттачивая формулировки, так чтобы никому из вас не прилетело. Это значит, что вы — за Заказчика, а Заказчик — за Вас. В ЦА сидят небожители, пукающие радугой, и летающие на единорогах. Их не интересуют проблемы на бренной земле.

      10К за нал из своего кармана на СОВЕРШЕННО НЕОТЛОЖНЫЕ ВЕЩИ, которые через пару месяцев возместят, если вы правильно заполните отчётные документы. Или не возместят, если заполнили неправильно. Никого не волнует. Не будете шевелить булками, вас уволят на следующий день. Приложения по SLA — 60 листов очень мелким шрифтом, и я их помнил все на память. Совещания с раздачей пряников — 12 часов в неделю (полтора дня рабочего времени (!) я протирал штаны, рисуя узоры в ежедневнике)

      Это Роснефть, детка!

      Шо вы мне там говорите за оптимизацию?

      Я чувствую коллег по теме, они из Газпрома, РЖД, Росатома.

      Мы молча пьём красное вино из больших бокалов.

      И смотрим на закат.


      1. AVX
        03.08.2016 21:39

        И, на закуску, вот ещё почитайте. Если что, мопед не мой :)
        http://scbist.com/csh-oao-rzhd-obratnaya-svyaz/45303-kak-daleko-rukovodstvo-gvc-ot-naroda-ili-realy.html
        Не работающие в ГВЦ РЖД половину не поймут, но часть думаю будет понятна.


        1. las68
          05.08.2016 04:58

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


  1. Artarik
    03.08.2016 20:01

    Зря разрешили админам создавать заявки. Как узнать, какая заявка фейк и создана, чтобы увеличить счетчик положительных заявок, а какая настоящая? Лучше уж тогда Вам или «старшему смены» дать права на создание заявок от имени пользователя.
    Насчет ухудшения отношений с пользователями — им надо просто вбить в голову, что если админ выполняет заявку, поданую в обход сервис деска, он за нее ничего не получает. и пусть сам выбирает, плохая зп, но хорошие отношения или хорошая зп, но возможное «ухудшение» отношений.


    1. dskozin
      03.08.2016 21:08

      Ну все не так сложно конечно. Я же вижу кто создает заявку, и насколько она актуальна. Если заявка — фэйк — пресекаю.


      1. Artarik
        04.08.2016 09:43

        а откуда узнается ее актуальность?


        1. dskozin
          04.08.2016 10:01

          Исходя из содержания и здравого смысла.


    1. las68
      05.08.2016 05:03

      Почему это зря? Если сисадмин выявил отказ ДО того как это сказалось на работе пользователя, то сисадмин — молодец, в этом и разница между превентивным и реактивным способом работы. А ловятся эти вещи легко — тикет или событие из системы мониторинга есть?


  1. Aramis087
    04.08.2016 06:48

    Если сотрудник не счастлив на работе, то никакая мотивация не заставит его остаться.


    1. las68
      05.08.2016 04:44

      Как говорили в Роснефти: «А кто хочет головой вниз висеть — идите работать в Google, а у нас — сопровождение производственных процессов».

      С возрастом всё становится по другому.

      Человек умеет делать свою работу, ему за неё платят. Обеспечивать семью — мотивация? Несомненно.
      Человек работает в маленьком городке, где вакансий по его ИТ-специальности просто нет. Держаться за своё место есть мотивация? Да.

      Счастлив он при этом или несчастлив — дело десятое.