Назад | Перейти на главную страницу

Как управлять инфраструктурными проектами и справочной службой

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

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

Каковы хорошие способы справиться с этим?

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

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

  • Создание хорошей документации для пользователей требует времени, но в конечном итоге сэкономит вам гораздо больше времени, особенно в разделах самоподдержки.
  • Если у вас есть хорошая документация, создайте шаблоны для ответа на почту со ссылками на указанную информацию.
  • То же самое и с телефонными звонками: вместо того, чтобы проводить абонента по шагам, скажите ему, что вы отправите ему ссылку по почте. Сделай так.
  • Если у вас еще нет, настройте систему сообщений о неисправностях, такую ​​как RT или OTRS. Это поможет вам отслеживать ваши запросы на поддержку и отправит письма с подтверждением. Это хорошо для пользователей, потому что они знают, что их проблемы будут решены, даже если вы не ответите немедленно. Это также может помочь вам получить представление об общих проблемах с вашей установкой и о том, где вы можете улучшить свою документацию. Это также помогает вам документировать свою рабочую нагрузку перед начальством.
  • Разработайте политику относительно того, какие запросы на поддержку являются действительными, и обсудите это со своим начальством. Обеспечьте соблюдение этой политики. Это упрощает отклонение запросов о помощи с домашними линиями DSL для пользователей, настройкой iTunes и т. Д.
  • Создавайте временные блоки «без звонков», когда вы не занимаетесь поддержкой, за исключением действительно срочных случаев. Это должно быть частью вашей политики и строго соблюдаться. Опять же, вы, боссы, должны вас поддержать.

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

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

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

Судя по звукам, картина будет крайне некрасивой. Это именно то, что вы хотите, потому что тогда самое время сказать своему боссу: «Что ж, если вы хотите, чтобы я делал больше, тогда мне нужно больше ресурсов. Конечно, если у ИТ-отдела не может быть больше ресурсов, мы будем следовать ваши приоритеты, а это значит, что нижняя часть списка никогда не будет выполнена ».

А теперь к вопросу о балансе между службой поддержки и инфраструктурными проектами: в любой инженерной дисциплине (и ИТ ничем не отличаются от этого) есть хорошо зарекомендовавший себя девиз: «Решайте проблемы дважды».
Сначала вы устраняете проблему, которая обычно является признаком того, что что-то не так. Это гарантирует, что пользователь счастлив и уйдет.
Затем вы устраняете основную причину проблемы. Это гарантирует, что симптомы не вернутся.

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

Ключевыми факторами здесь являются тайм-менеджмент и планирование. Раньше я просто выделял несколько часов каждый день для HD-материалов (обычно днем, потому что именно тогда легче отсылать пользователей от их ноутбуков для обслуживания) и несколько определенных часов каждый день или неделю для инфраструктуры, проектов, тестирования интересных новых способов o делать что-то и т. д.

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

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

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

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

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

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