Организация IT-отдела

Организация IT-отдела — раз рассказал за оптимизацию, то нужно отдельно рассказать и как строить IT-отдел с самого начала. Так логичнее.

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

Выложу сразу, дописывать буду потихоньку, частями.

Структуризация работы

Опишем первичную структуру IT-отдела. Надо потом тут картинку приляпать для наглядности. Сделаю. Начнём с главного. Что главное в IT-отделе, такое центровое, краеугольный камень? Это система подачи и обработки заявок или трекер заявок. Всё здесь сходится и всё сюда упирается. Именно отсюда растёт правильный IT-отдел. Вот то, с чего надо начинать.

Трекер заявок

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

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

Основное правило здесь:

Всё взаимодействие пользователей с IT-отделом должно идти через оформление обращения в трекере заявок.

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

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

Почему письма это плохо? Сравним какие преимущества имеет обращение перед письмом, их множество:

Основная информация, суть проблемы, сформулирована в шапке обращения. Это первое что ты видишь, открывая обращение. Для письма, длинной переписки, основная информация может находиться в самом низу, в середине, где угодно. Нужно внимательно прочесть всю переписку, чтобы хоть как-то разобраться;
У обращения в любой момент времени есть конкретный исполнитель, тот кто ведёт заявку сейчас. Если же письмо было оправлено на несколько получателей или даже на отдел, очень трудно разобраться, кто на момент занимается проблемой. Возможно что никто;
Обращение прозрачно маршрутизируется (по группе, по конкретному исполнителю), в зависимости от текущей задачи. Текущая задача обращения или этап выполнения, понятно, может меняться. В письме же в копию просто наваливается довольно много получателей, в надежде что среди них окажется нужный. И если такой действительно есть, то по-хорошему остальным это письмо и читать-то не надо;
В обращении есть понятные сроки выполнения, есть типы обращений по срочности, визуализация оставшегося на выполнение времени. Сразу понятно эта заявка уже сгорает или ещё живёт. В письме всё всегда срочно, потом часто оказывается что результата по факту в ближайшее время никто и не ждал;
Можно обращение распараллеливать, создав от корневого обращения дочерние. Это удобно, это ускоряет выполнение;
У обращения есть номер, этот номер можно (и нужно) использовать. Например, в поле комментария в файервольном правиле. У письма такого функционала нет;
Существует удобный поиск обращений по их номерам и другим критериям. Хотя у писем тоже поиск есть, тут совсем не то.

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

Пользователи и трекер заявок

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

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

Также в административно-приказном порядке нужно доводить до пользователей информацию, что корректное составление заявок это не какой-то ненужный им бред, а неотъемлемая часть их работы. За которую они денюжку получают. И некачественное выполнение этой работы влечёт за собой сначала прохождение курса, а затем финансовую мотивацию.

Почему это важно? Некачественно составленная заявка типа: "У меня ничего не работает, срочно почините!" при кажущейся невинности влечёт за собой:

Избыточную нагрузку на IT-отдел, привлечение дополнительных специалистов для обработки обращения;
Обращение выполняется дольше, что вызывает снижение эффективности рабочих процессов самого заявителя.

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

Дополнительным средством, немного повышающим качество обращений, является корпоративный интранет-портал. Хотя напрямую он к IT-отделу не относится. Здесь пользователи смогут получать какую-то актуальную информацию по фирме в целом. А значит станут информированнее. Не стоит пренебрегать.

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

Обычно на это внимания никто не обращает. И на работу берут условную "тётю Зину" бухгалтером, а всё что она умеет, это нажимать на кнопку включения, на Пуск, открывать Excel, открывать 1С. И возможно сохранять документы на файловую шару, если покажут как. Понятно что такой пользователь просто не в состоянии составить грамотную заявку. Сотрудники первой линии будут буквально плакать. При работе с этим пользователем.

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

Варианты подачи заявок

Есть три варианта:

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

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

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

Как правильно организовать трекер заявок

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

Существующих решений море разливанное, начиная от 1С "Управление IT-отделом 8", заканчивая десятками решений от мелких фирм. Только ленивый не разработал на момент свой хелпдеск.

Далее нужно формализовать и описать хотя бы минимально услуги, которые IT-отдел будет предоставлять пользователям через трекер заявок. Не такая простая задача. Требует углубления. Предварительно, прежде чем приступать, должно сложиться понимания какие аппаратные и программные средства используются или планируются в компании. Вот тут коллеги делают новый трекер, получилось примерно 1200 услуг. Нормально, да?

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

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

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

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

Масштабирование трекера заявок

В минимальном варианте трекер заявок это только трекер заявок. Далее его можно накручивать и расширять: Запросы на изменения, Поручения, Проектная работа, Экспертиза, Снабжение, Учёт затраченного времени, Согласования, База клиентов, База договоров и прочее. В максимальном варианте трекер превращается в навороченную CRM-систему.

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

Таск-трекер

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

Даёт целостное видение задач и работ в отделе. В первую очередь начальнику отдела. Но и сотрудникам тоже:

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

Без трекера задач никто не знает чем же в реале занимаются сотрудники. С ним же всё по полочкам разложено. Значительное возрастание эффективности работы отдела.

Инциденты

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

Поскольку инцидент связан с прерыванием услуги, другими словами бизнес процессов, то имеет повышенный приоритет над стандартным обращением. Кроме это в зависимости от распространения инцидента выделяют понятие severity (s):

Затрагивает работу одного единственного пользователя, наименьшая важность, s5;
Работу нескольких пользователей до 5 человек, s4;
До 10 человек или отдел, s3;
Департамент, s2;
Локация, s1;
Несколько локаций либо компания целиком, s0.

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

Это целая наука, подробнее про управление инцидентами (Incident Management) можно почитать в нете. Тут при возможности желательно использовать дополнительную тулзу в дополнение к трекеру заявок, например MS SCSM.

Тогда в трекере ведутся s5-s3 подобно стандартным обращениям, но с повышенным приоритетом и дополнительным логированием, дополнительными кодами закрытия. А s2-s0 в тулзе по управлению инцидентами согласно разработанной политики.

База внутреннего обучения

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

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

База знаний отдела

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

Собственно, все 1200 услуг трекера заявок должны быть расписаны в базе знаний. Если по-хорошему. Желательно для каждой услуги:

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

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

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

Найденные решения проблем, носящих массовый характер, заносятся в Базу знаний. Для этого заявка закрывается с пометкой "Решение является кандидатом на публикацию в Базу знаний".

Мессенджер

Обязательный глобальный элемент. Самое простое и дешёвое решение, это создать несколько групп в Telegram. Довольно-таки функциональное. Им пользуются даже прям очень толстые интеграторы. Работал в одном, видел.

Для мелкого IT-отдела будет идеальным решением. Или же как замена Telegram идёт Skype. Конечно есть и другие варианты. Например на "полном фарше" Teams.

Стандарты и регламенты

Обязательный глобальный элемент. Если трекер заявок центровое и главное, сердце, мотор, то стандарты и регламенты нечто всеобъемлющее. Такая материя, которая пронизывает всё и вся в IT-отделе.

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