Реальный Help Desk, или Рекомендации по разведению кроликов

Освобождение рабочих должно

быть делом самих рабочих.

К. Маркс

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

Возможно, с точки зрения теории, мы построили все неправильно, но в текущий момент сооруженная нами система работает достаточно эффективно и, что самое важное, она принята пользователями. Как поет в милой песенке про самолетик Валерий Курас, «в этой жизни есть простое правило: лучше маленький, но свой». 

==============================

Характеристики компании

Общие:

• Всего около 800 чел. (ИТР);
• 4 юридических лица, размещенных в 3-х офисах в разных концах города;
• 12 объектов (объект – мобильный офис на 10–20 рабочих мест, время размещения 1–3 года).

Персонал ИТ-подразделения:

• системные администраторы – 3;
• конфигурационные менеджеры «1С» – 2.

===============================

Об организации процесса

Модель построения системы обслуживания пользователей в основном базировалась на ограничениях, наложенных руководством компании. А именно: ограниченный штат и большое количество территориально удаленных точек обслуживания (3 офиса в разных концах города и много объектов). Функциональное распределение сотрудников ИТ-подразделения в такой ситуации невозможно, а значит. каждый из них должен быть немножко космонавтом. Как показала практика, при достаточно большой ИТ-инфраструктуре и минимуме сотрудников это непросто.

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

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

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

Что откуда берется

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

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

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

Все существующие проблемы я разделил на 4 основных блока (см.рис.1):

Рисунок 1. Структура проблем

• Технические. Выход из строя техники или технические сбои оборудования, в том числе активного.
• Программные. Не работает программа, нет обновления, нет доступа и проч.
• Квалификация пользователя. Незнание или неумение работать в определенных программных продуктах.
• Прочие «хотелки». Дополнительные настройки, улучшения, проверки расчетов и проч.

Тип инцидента	1 год (%)	2 год (%)	3 год (%)
Технические	30	20	10
Программные	30	35	40
Квалификация	35	35	25
Прочие	5	10	25

Давайте рассмотрим примерную динамику изменений количества инцидентов по этим разделам в компании. На основании анализа приведенной статистики можно явно увидеть несколько характерных явлений:

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

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

Рисунок 2. Влияние на сервисы

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

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

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

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

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

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

О необходимости документов

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

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

• Положение по КИС.
• Регламент обслуживания.
• Регламент работы подразделения.
• Положение по планированию.
• Каталог услуг.

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

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

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

Для формирования этих документов или, если они у вас есть, актуализации их я бы посоветовал выполнить ряд следующих действий:

• выделить процессы подразделения;
• разделить весь спектр задач на отдельные блоки – обслуживание пользователей, обслуживание серверов, закупка и проч.;
• сформировать матрицу ответственности сотрудников за процессы подразделения;
• составить регламент работ — кто, чем и когда должен заниматься (не путать с вышеуказанными регламентами — это матрица распределения времени).

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

Проводя ИТ- и ИБ-аудиты в разных компаниях, я часто встречаю забюракратизированные с годами процессы. Например, изучая регламент обслуживания одной уважаемой компании, нахожу там следующее правило: «в случае возникновения проблем у пользователя с почтовым сервисом ему необходимо отправить электронное письмо на support». А вот другой вариант: «для замены картриджа в печатном устройстве надо написать заявку на замену на стандартном бланке предприятия и согласовать данную заявку с главбухом». Таких примеров огромное количество, и вы сами можете их рассказать. Документация и регламентация процессов, несомненно, нужна, но не доводите ее до таких извращенных вариантов.

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

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

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

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

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

База знаний

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

Инструменты, которые мы используем

К сожалению, на текущий момент мне еще не удалось (не было для этого достаточных условий) внедрить нормальный, адекватный инструмент для HD. Вся система сейчас строится на сервисах MS Office 2007, используется единый для всей группы компаний адрес техподдержки, есть технология постановки задач в краткосрочные и среднесрочные планы. В зависимости от инцидентов стандартными инструментами сотрудники ИТ-подразделения составляют свои оперативные электронные планы, доступ к которым я имею и могу их подкорректировать по необходимости.

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

Вместо заключения

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

P.S. Все роли и описанные ситуации вымышлены и утрированы.