IT-бюджет

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

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

Небольшое эссе формирования бюджета.

Сразу можно определить несколько этапов формирования IT-бюджета:
1. Сбор
2. Анализ
3. Формирование и обоснование

1. Сбор информации

Для составления (и обоснования) бюджета на IT необходимо знать, помнить, понимать:

1. Что компания уже купила в прошлом и за что продолжает платить в настоящем, а именно:

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

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

3. Какие цели, планы и задачи у компании на ближайший период, какие существуют проблемы и что должно быть решено?

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

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

2. Анализ

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

• Производительность оборудования.

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

• Надежность.

Все ли предприняты меры для обеспечения сохранности данных? Допустимо ли менять оборудование по мере выхода из строя или все таки стоит его обновить заранее? Возможно ли в случае какого либо сбоя восстановить работоспособность в обозначенные сроки или лучше заранее приобрести доп. оборудование или ПО для этого? Есть ли какие-то другие известные проблемы, которые влияют на безотказность работы IT-систем?

• Функциональность.

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

• Безопасность.

Защищены и насколько защищены данные компании от внешних и внутренних угроз? Существует или соответствует ли система защиты уровню угроз? Как изменятся требования к информационной безопасности в обозримом будущем? Как ее видит IT-специалист?

• Удобство.

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

• Операционные расходы.

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

• Запасы

Есть ли необходимые расходные материалы? Сколько нужно будет дополнительного оборудования и лицензий в случае расширения? Нужны ли будут дополнительные разовые или постоянные услуги в случае планируемого развития бизнеса?

3. Формирование бюджета и обоснование

Собственно, вся основная работа выполнена на двух вышеуказанных этапах. Последняя задача — представить полученные выводы руководству в понятном и удобном для принятия решений виде. Здесь нужно разложить все по полочкам:
1. Операционные расходы на поддержание деятельности: расходные материалы, сервисные контракты, услуги, оплата труда специалистов.
2. Необходимые капитальные вложения, в случае отсутствия которых возможны серьезные потери для бизнеса. Сюда относятся расходы, которых компании не избежать и вопрос лишь в том, будет она инвестировать деньги в это заранее, или когда уже понесет обозначенные потери.
3. Рекомендуемые инвестиции – в сочетании с необходимыми позволяют значительно повысить показатели работы, а также устранить риски, которые могут оказать негативное влияние на бизнес.
4. Расходы, связанные с развитием – необходимый объем инвестиций для обеспечения работы систем и поддержания качественных показателей в случае реализации планов по росту бизнеса.
5. Возможные инвестиции, позволяющие улучшить функциональные возможности и/или удобство работы сотрудников с IT-системами. 

     И последняя, но самая важная деталь – это обоснование каждой из статей бюджета. Большие руководители к сожалению, не понимают понятия «морально устаревший сервер» и как правило  ничего не понимают в технике — они оперируют только категориями потребностей в IT-сервисах, возможностями, рисками и их стоимостью для бизнеса. Каталог услуг (IT-сервисов), который был описан в самом начале, нужно для того, чтобы общаться с руководством компании на "одном языке" – это общая точка соприкосновения. И говорить на "одном языке" - как правило нетривиальная задача. Выявив потребность в оборудовании, программном обеспечении, персонале и пр. необходимо обосновывать необходимость в них конкретными показателями работы конечных IT-сервисов (риски, качество, скорость реакции и пр.), которые получает или получит бизнес.

Как-то так.

Читать далее ...

Как стать грамотным, знающим и понимающим IT-руководителем?

          Не каждому дано стать IT-руководителем. Не каждый IT-руководитель понимает в процессах, которые он курирует или руководителей. 90 % IT-руководителей понаслышке знают какой продукт разрабатывает компания.

Вот основные черты, которыми должен обладать IT-руководитель (мое мнение).

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

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

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

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

Учиться на практике.  Нет ничего зазорного в том, если IT-руководитель подойдет к рядовому сотруднику и попросит его объяснить тот или иной нюанс в работе разрабатываемого продукта или в работе сети. Это не стыдно!

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

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

Иметь техническое образование.  IT-руководителю не обязательно с головой погружаться в исходный код, но он должен понимать элементарные технические требования. Одно дело сказать» «Сделайте мне то-то и то-то», и совсем другое – понимать, как это сделать. За простым с виду заданием может скрываться масса работы, которую просто нереально выполнить с данными ресурсами или в указанные сроки.

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

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

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

Обладать хорошими коммуникативными навыками.  IT-руководитель должен быть вдохновителем масс. Ему нужно донести свои идеи до ключевых руководителей бизнеса на понятном им языке. Нельзя использовать технический жаргон или отраслевую терминологию. Речь IT-руководителя должна быть простой, ясной и убедительной. Кроме того, он должен уметь отстаивать свою точку зрения. Вежливо, но уверенно.

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

Только так можно стать грамотным, знающим и понимающим IT-руководителем.

Читать далее ...

Service Desk. Как? Что? Куда? Зачем?

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

                 В результате чего появилось вот это.

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

1. Сколько это стоит?

Сегодня найдется немало компаний, которые могут помочь в построении службы Service Desk (ссылок давать не буду - гугл рулит). Квалифицированные консультанты оценят уровень зрелости процессов ITIL на предприятии, разработают для ИТ-отдела план по внедрению того или иного процесса, подберут и настроят оптимальный инструментарий. Однако услуги консультантов не бесплатны и зачастую достаточно дороги. А руководители компаний среднего и малого бизнеса, как правило, не считают ИТ-отдел стратегическим подразделением и, следовательно, неохотно инвестируют средства в ИТ-проекты. Возникает вопрос: как доказать руководству необходимость выделения средств на развертывание службы Service Desk?

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

Итак, если не удается построить Service Desk на средства компании, то можно попробовать развернуть службу самостоятельно, без привлечения сторонних консультантов и затрат на специализированное ПО.

2. С чего начать?

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

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

Шаг I. Фиксируем и пишем регламенты.

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

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

           Какие регламенты и правила функционирования Service Desk следует описать? Однозначных, предельно конкретных советов и ответов здесь нет и быть не может. Можно перечислить лишь наиболее общие из них

          Количество линий поддержки службы Service Desk. Классика ITIL рекомендует развернуть три линии. К первой линии поддержки могут относиться операторы call-центра, ко второй – администраторы баз данных, системные администраторы, технические специалисты, к третьей – программисты, старшие системные администраторы. Подрядчики, организации, которые предоставляют услуги по сопровождению ПО, провайдеры телекоммуникационных услуг и т. д. также могут быть отнесены к третьей линии поддержки.

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

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

           Вторым способом обращений пользователей за поддержкой может быть электронная почта. В этом способе коммуникации с Service Desk есть свои преимущества и недостатки. Далеко не на всех предприятиях пользователи настолько грамотны в области применения ИТ, чтобы с первого раза кратко и понятно описать ситуацию (произошедший сбой). Неточное описание может повлечь за собой долгую переписку между оператором call-центра и пользователем. Результат – увеличение времени решения проблемы. Положительные стороны обращения пользователя в службу Service Desk при помощи электронной почты, разумеется, тоже есть. Например, пользователь направляет электронное письмо с описанием сбоя на определенный адрес. При поступлении нового сообщения в этот почтовый ящик происходит автоматическая регистрация обращения в предварительно настроенной системе службы Service Desk. В этом случае оператор первой линии поддержки не тратит время на регистрацию обращения, а может сразу же приступить к поиску решения инцидента.

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

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

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

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

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

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

           «Главный регламент». Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация сотрудников. По собственному опыту могу сказать, что однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько небольших рекомендаций, которые помогут в построении грамотной схемы мотивации.

• Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например, при нарушении сотрудником установленных регламентов.
• Материальная мотивация должна быть ощутимой. 5% от оклада специалиста – это пародия на мотивацию.
• Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.

Шаг второй. Обучение.

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

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

         После того как все сотрудники (или часть сотрудников) прошли тренинг по основам ITIL/ITSM, следует ознакомить их с регламентами, которые уже составлены. И никак не раньше. Уже с обученными сотрудниками (или с некоторыми из них) можно и нужно проконсультироваться, узнать их мнение, выслушать предложения. Здесь может произойти первая корректировка процесса приема и обработки обращений пользователей.

Шаг третий. Организация call-центра.

«Что может быть проще! – Берем стол, стул, компьютер, телефон, принимаем на работу девушку с приятным голосом. И вот call-центр готов». Однако не все так просто. Существует как минимум два вопроса, которым требуется уделить особое внимание: какими качествами должен обладать оператор и где расположить его рабочее место.

           Приятный голос – это далеко не самое главное, чем должен обладать человек, работающий на первой линии поддержки Service Desk. Стрессоустойчивость гораздо важнее для оператора, который в течение одного рабочего дня может несколько десятков раз слышать одну и ту же фразу: «У меня не работает компьютер!» — и при этом обязан всегда одинаково невозмутимо и доброжелательно выяснять у пользователя, что же действительно сломалось. Кроме того, сотрудник первой линии поддержки должен хорошо владеть русским языком. Грубые грамматические и синтаксические ошибки, допущенные оператором при регистрации обращения пользователя, могут неблагоприятно отразиться на понимании сути заявки другими специалистами. Наконец, оператор call-центра должен обладать общими ИТ-знаниями. Комментарии здесь излишни. Очевидно, что оператор, услышав слово «винчестер», должен представлять себе устройство долговременного хранения информации, а не огнестрельное оружие.

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

            Совсем другая обстановка возникает, если расположить рабочее место оператора call-центра рядом с рабочими местами сотрудников второй линии поддержки. Решение задач второй линии поддержки не требует особой сосредоточенности и, следовательно, общение оператора с пользователями не будет сильно их отвлекать. В то же время тесное общение специалистов первой линии поддержки с сотрудниками второй линии может дать положительные результаты: через некоторое время часть проблем, которые ранее решались на второй линии, смогут устраняться уже на первой. Этим можно улучшить один из главных показателей эффективности Service Desk – сократить среднее время решения проблем.

Шаг четвертый

Когда принципы функционирования службы Service Desk описаны (подготовлена документация), сотрудники знают и понимают основы ITIL/ITSM и определено рабочее место операторов call-центра, стоит задуматься об инструментарии. Для того чтобы контролировать процесс приема и обработки обращений пользователей, необходимо специализированное программное обеспечение. Наиболее распространенным инструментом сегодня является HP OpenView ServiceDesk. Но многие компании не имеют средств на приобретение такого программного обеспечения, да и нужен ли на стартовом этапе инструмент такого высокого уровня? Скорее всего, нет, так как сначала требуется наладить сам процесс приема и обработки обращений пользователей.

       Если в штате ИТ-департамента есть хотя бы один программист, то задача построения собственной системы приема и обработки обращений пользователей решается сама собой. Любой программист менее чем за месяц может создать базу данных и подготовить генерацию стандартных отчетов. Если же программиста нет, то можно пойти еще более простым путем: достаточно зайти на сайт, где хранится огромный список ссылок на различного рода программное обеспечение для поддержки служб Help Desk, Service Desk и call-центров. Потратив немного времени, можно найти бесплатный и вполне достаточный по набору функций инструментарий. Если и этот вариант не устраивает по каким-либо причинам, то можно, наконец, использовать «подручные» средства – Microsoft Excel и Access. Потратив несколько часов рабочего времени, можно создать свой собственный уникальный инструмент для службы Service Desk.

Первые результаты

Теперь все готово для запуска в работу новой службы Service Desk. Конечно, нужно не забыть оповестить всех пользователей о новой услуге, сообщить единый телефонный номер отдела ИТ, по которому пользователи могут обратиться с любым вопросом.

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

         Можно выделить две основные проблемы, с которыми придется столкнуться в первое время работы службы Service Desk. Первая заключается в том, что большинство пользователей в первые месяцы будут продолжать «по старинке» звонить системным администраторам, программистам и т. д. Но если система мотивации сотрудников ИТ была выстроена достаточно грамотно и был проведен тренинг по основам ITIL, то об этом можно не беспокоиться. ИТ-руководитель не будет тратить массу своего времени на разъяснительные беседы с пользователями о полезности службы Service Desk. Системный администратор, которому в очередной раз позвонит пользователь, сам объяснит, куда и к кому надо обращаться с вопросами. Причем он найдет такие аргументы, о которых ни один ИТ-менеджер даже не догадывается. Такой путь — приучить пользователей звонить по одному определенному номеру —максимально эффективен.

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

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

Что дальше? Развитие.

После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.

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

Без рисков не обойтись.

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

            Но это темя для другого разговора.

P.$ В чем-то конечно гипотетично, но можно принять к сведению отдельные моменты для работы или для саморазвития.

Читать далее ...

Качества, необходимые современному руководителю

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

Вести команду к успеху.  
Традиционная модель руководства строилась на указаниях и контроле. Сотрудники должны были упорно работать как пчелки, чтобы их руководитель достиг успеха (что в принципе ныне и происходит). Современный же руководитель должен сделать все возможное, чтобы помочь добиться успеха своим сотрудникам. Это предполагает расширение полномочий сотрудников и привлечение их к управлению компанией. Сотрудники являются самым ценным активом любой компании. Если раньше руководитель говорил: «Прыгайте!», и сотрудники спрашивали: «Как высоко?», то сегодня вы должны прыгать вместе с сотрудниками.

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

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

Не бояться ошибок.  

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

Делиться информацией. 

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

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

Читать далее ...

Как эффективно руководить сотрудниками ИТ-отдела?

          Успех ИТ-отдела определяется не только оборудованием и программным обеспечением. Сами по себе без грамотных ИТ-специалистов они ничего не значат. Руководить сотрудниками ИТ-отдела – непростая задача. У каждого специалиста свой характер, сильные и слабые стороны, амбиции и мотивы. Несколько советов как управлять ИТ-отделом.

1. «Срок годности». Сотрудники заинтересованы в карьерном росте. Это особенно актуально для ИТ-специалистов, отсюда и постоянная текучесть кадров. Важно понять, сколько времени человек сможет эффективно проработать в определенной должности. У разных специальностей разный «срок годности». К примеру, специалист службы поддержки может эффективно работать не более двух лет, а разработчик ПО значительно дольше.

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

3. Стимулирование саморазвития. Для того чтобы сохранить персонал и поддерживать желание работать, руководителю нужно оценить потенциал своих сотрудников и побуждать их к саморазвитию. Замещение других специалистов – отличная возможность для ИТ-специалиста попробовать что-то новое и понять, в какую сторону он хочет двигаться.

4. Обратная связь и поощрение. Руководителю нужна постоянная обратная связь с сотрудниками. Это могут быть как положительные, так и отрицательные отзывы, главное чтобы они были конструктивными. Лучших сотрудников нужно благодарить за работу и, если есть такая возможность, поощрять (необязательно материально). Это стимулирует здоровую внутреннюю конкуренцию.

5. Управление ожиданиями. Как и в любом другом деле, руководитель не должен давать обещаний, которые не сможет выполнить. Управление ожиданиями является важной частью работы любого руководителя. И этот процесс должен затрагивать обе стороны – и бизнес, и ИТ-отдел.

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

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

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

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

10. Сопереживание. Постарайтесь понять людей, которыми вы руководите. Хороший руководитель понимает трудности, с которыми приходится сталкиваться его подчиненным, и переживает их как свои собственные.

Читать далее ...

Бумагомарание, или почему документацию вести все-таки необходимо.

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

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

Знакомая ситуация? Если же вы – сисадмин, то перспективка еще печальнее. Зачастую будет быстрее и проще все переделать «под себя», нежели разбираться, как и что работало раньше.

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

Документация необходима компании.

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

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

Документация необходима ИТ-специалистам.

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

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

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

Таким образом документация сокращает время реакции на инциденты и их решение.

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

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

Другой пример: к вам обратился пользователь с просьбой установить на его компьютер важное приложение «World of Warcraft». Если у вас нет четко определенного и утвержденного генеральным директором перечня допустимого ПО, то нет и оснований ему в этом отказать. А с перечнем вы – хозяин ситуации. Причем, можно отказать без риска испортить с коллегой отношения: дескать, «я бы и рад, да не положено, извините».

Ведение документации – востребованный навык.

Надо признать, что в нашей стране развитие бизнеса в целом и отрасли ИТ в частности основывается на опыте более продвинутых западных коллег. Западные отраслевые стандарты, выраженные в методологиях ITIL, MOF и CobiT, четко определяют документирование как один из ключевых процессов управления ИТ. Рост ИТ-специалиста проходит по стандартной схеме «от меньшего к большему». Иными словами, от ООО «Йо-О» до ОАО «Газпром». Сисадмин, не владеющий ключевыми навыками, шансов устроиться на престижную и высокооплачиваемую работу в крупную компанию практически не имеет. Так что учиться, учиться и еще раз учиться.

Необходимая документация.

 Какого рода документацию вести необходимо?

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

Где и как вести документацию.

Одним из лучших способов хранения и управления документацией является применение CMDB (Configuration Management Database). Разработанный в качестве компонента процесса Управления конфигурациями ITIL, это гибкий и мощный репозиторий информации о компонентах информационных систем. «Лучшая практика», так сказать. Другая сторона медали – коммерческие CMDB достаточно дороги и для бюджетов малого и среднего бизнеса часто неподъемны.

Если денег на CMDB нет (что чаще всего и бывает), то при определении базы хранения и методов управления документацией важно учесть 2 качественные характеристики: интерактивность и доступность. С документацией чаще всего работает не один человек, а коллектив, поэтому лучше использовать привычно сочетающиеся с совместной работой инструменты: wiki, web-платформы (например, Microsoft SharePoint или его бесплатные реализации), CMS. Такие системы позволят наглядно структурировать документацию, четко прослеживать взаимосвязи, отслеживать версионность и обеспечить максимальную доступность. В любом случае, понимание приходит с опытом. Главное начать, а уж наиболее удобный способ выработается сам 

Ну и как водится - заключение.

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

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

Читать далее ...