Брайан Трейси - Оставьте брезгливость, съешьте лягушку

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

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

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

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

Итак, суть - служба поддержки пользователей - это в первую очередь персонал, который там работает, те люди, которые изо дня в день занимаются не самой интересной, но крайне важной в масштабах всей службы работой. И кого туда набирать - решать Вам.
По моему мнению, выбор очевиден - необходимо набирать максимально квалифицированный персонал. Т.е. данная позиция ни в коем случае не должна быть начальной в масштабах отдела, управления, службы. Если у Вас есть хелп-деск, но единственная его работа в перераспределении поступивших заявок, их эскалация и минимальный контроль за ними, плюс решение мелких проблем - то Вы находитесь на тупиковой ветви развития. Все эти функции уже довольно давно умеют делать автоматизированные системы хелп-деск. Сами же специалисты хелп-деск должны владеть максимально возможным количеством технологий, которые внедрены в организации, и прав доступа для работы с ними. Желательно, чтобы на период организации службы поддержки пользователей, персонал туда был набран из числа уже работающих сотрудников.
Вполне естественно, что бонусы для таких позиций должны быть соответствующими.
Теперь поясню, допустим в вашей организации успешно внедрены и ежедневно используются 6-7 ключевых технологий, но абсолютно несхожих из разных областей. Пусть для примера это будут 1С - в нескольких конфигурациях, и с количеством разных баз от 25 до 50, корпоративный портал, развернутый на SharePoint со всеми рюшечками, которые были прикручены, несколько интернет-ресурсов, какая-нибудь ERP-система, а если не повезет то несколько, и это не беря в расчет базовых сервисов, локальной сети, домена\дерева доменов\леса ActiveDirectory, офисной техники, предоставления интернета, без которого никуда, тучи специфического софта, которым пользуется только два сотрудника, и который вы всем отделом устанавливали в течение недели, и то с костылями. Список сервисов можно составлять долго, а главное то, что специалист по поддержке пользователей должен обо всем этом знать, иметь представление. Довольно объемно. И одному человеку знать это все досконально не нужно, в рамках одной специальности.
Но поддержка пользователей это очень специальные люди, которые не всегда и во всем похожи на остальных. Дело в том, что все мы работает с железом, даже если нам иногда кажется, что у него есть душа. И это железо имеет одно очень нехорошее свойство - ломаться в самый неожиданный момент, а SLA таки да, - существует и от него не спрятаться не скрыться.
Конечно, у вас в компании есть много разных специалистов, каждый из них отвечает за какой-то свой сервис, работает с одной-двумя технологиями, но он. это специалист ни разу не железо, у него есть вполне себе такие осознаные потребности, нужности, интересы, ему нужно какое-то свободное время.
А разные поломки и косяки, только и ждут подходящего момента. и случаются, и вот тогда ведущий программист проекта, находясь у любимой бабушки на дне рождения диктует по телевону оператору поддержки пользователей свои учетки, расказывает куда тыкнуть, поправляет по телефону беду, и говорит себе, что как только окажется у компьютера, сразу подключится на работу и поменяет все пароли. И пусть даже так и будет, но на некоторое время, оператор имеет учетку ключевого сотрудника (замечу, что операторы обычно набираются из студентов, которым все по барабану, за то дешевые). И пусть даже ничего не случиться, но все же не красиво.
Придумать других ситуаций вагон не проблема, проблема уже озвучена - грамоная модель построения службы ИТ-поддержки.

Итак, мое виденье (фанфары)

1. составляем каталог услуг. смотрим и ужасаемся от числа ни за кем не закрепленных сервисов.
2. с боями составляем, согласованный с бизнесом, SLA.
3. создаем новую боевую еденицу из уже работающих сотрудников, желательно не junior, пусть даже от этого на определенное время пострадает бизнес. Важно, чобы они представляли разные отделы ИТ. Во время обкаточной работы они смогут создать начальную базу знаний, определят узкие места в работе службы.
4. в зависимости от предполагаемого количества специалистов поддержки пользователей, по желанию\жребию\на удачу назначаем руководителя вновь созданного подразделения, определяем обязанности.
5. Начинаем по одному выводить из работы по поддержке старых сотрудников и вводим в коллектив новых, сразу делая упор на комплексном обучении всем системам, в рамках администратора этих систем. Именно поэтому, на все позиции в поддержку пользователей, набираем не студентов, а системных администраторов со стажем, иначе не видать успеха. Настраиваемся на высокую цену таких специалистов и необходимость продалжительной работы по подбору.
6. Когда выучено достаточно технологий и так сказать получен некий кредит доверия - выделяем полноценные административные учетные данные необходимые для работы во всех системах. С одной стороны, это может показаться ударом по безопасности систем, ведь количество администрирующих возрастает. Здесь помогают административные меры и правило для поддержки - "работает не лезь!". Да им в принципе и так есть чем заняться:)

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

Все сказанное выше является сугубо моим личным мнением, применимым для компаний от средней до умеренно крупной, работающей с различными технологиями (ну т.е. для хостеров и провайдеров эти мои слова не представляют никакой роли, а только вред, их системы с "пожалуйста, подождите", "У вас вирусы, переустановите ОС", "мы все проверили у нас все нормально", "проблемы у сторонней организации" работают идеально, практически не дают сбоев и не поспоришь). Применено в организации с такими показателями - 70-100 заявок в день, 120-150 звонков, письменные обращения мимо всех и вся:), число сотрудников поддержки в смене - 2, процент закрытых заявок на первом уровне поддержки от 24 % до 36 % (месяц на месяц не приходится, смотря что сломается).

Ян Ван Бон - ИТ Сервис-менеджмент, введение

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

Устанавливаем и конфигурируем Apache под Windows

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

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

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

В остальном установка это исключительно выбор дефолтных настроек.

 По окончанию установки и запуска Apache в системном трее мы с увидим перышко (ApacheMonitor).

Другим вариантом установки может являться распаковка архива и конфигурирование вручную.

Терминология ITIL - 3

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

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

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

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

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

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

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

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

Терминология ITIL - 2

Продолжим знакомиться с терминологией ITIL.

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

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

Терминология ITIL - 1

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

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

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

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

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

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

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

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

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

 Учёт затрат - Процесс,отвечающий за идентификацию фактических Затрат на предоставление ИТ-Услуги, их сопоставление с плановыми Затратами, и управление отклонениями от Бюджета. 

Хватит работать сверхурочно, пора работать рационально!

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

А вот и аннотация к книге:

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

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

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

скачать с depositfiles.com

Утро нового дня

У каждого из нас есть свои особые периоды максимальной умственной и физической активности, ясности и тонкости  мыслей, проявления креатива - вот только обычно тратим мы их не совсем рационально. Для меня, время такого подъема - утро.  Два года назад заметил за собой привычку - начинать рабочий день с разгребания почтового ящика, беглого просмотра мировых новостей, ЖЖ, ithappens, bash.org.ru, anekdot.ru, тематических блогов и новостей, за которыми слежу. В итоге пол-дня гарантированно уходило исключительно на это все, с небольшими прерываниями на выполнение прямых обязанностей. А вся соль в том, что это было в порядке вещей у всего отдела, где я тогда работал, с самого утра все втыкали в свои собственные клоаки информационного мусора, бесполезная затуманивающая ум муть лилась отовсюду. Естественно, этой же мутью мы активно обменивались по почте, через icq и jabber. Не могу сказать, что работа выполнялась плохо, или не выполнялась вообще. Нет все работало, но не было одного очень важного момента - развития. Вот оно-то и буксовало.

Предоставление услуг (Service Delivery)

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

  Для начала опишу, какие определения получили процессы этого раздела у нас.

techsupport зачем и как?

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

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

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

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

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

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

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

программные продукты для управления IT-инфраструктурой

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

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

1. Manageengine ServiceDesk Plus - комлексное решение для управления информационными технологиями, поддерживает ITIL, довольно удобен в использовании, обладает богатыеми возможностями по настройке, разграничению доступа и особенно сбору статистической информации в автоматическом режиме. Многие процессы автоматизированы, или позволяют их автоматизировать.  Поддерживает импорт пользователей из ActiveDirectory  и их прозрачную авторизацию.

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

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

2. SysAid - очень комфортное в работа решение, менее функционально в сравнении с Manageengine, зато отлично кастомизировано, есть версия Free - поддерживает работу до 100 пользователей и 2 администраторов, не умеет практически ничего из ITIL, зато дальше есть простор где развернуться - коммерческие версии могут быть сконфигурированы практически как угодно, множество дополнительных подключаемых модулей (естественно, за дополнительную плату). В работе, немного раздражает не совсем корректный русский перевод, и невозможность использовать разные языки для админстраторской части и пользовательской (а может я не нашел). Довольно запутанное меню, требующее привыкания, но затем все просто.

3. GLPI - достойная внимания вещь, для небольшого отдела информационных технологий в самый раз, есть русский интерфейс, интеграция с AD, OCS Inventory. Работал с этой системой мало, т.к. уже был выбран продукт, но в принципе довольно интересная вещица.

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

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

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

Десять заповедей techsupport

Саппорт - лицо компании для пользователя.

Лицо должно быть красивым, улыбающимся и приветливым.

Пользователь - живой человек.
Отвечая на письмо пользователя, подумай: а устроил бы такой ответ тебя? Не забывай, что с другой стороны монитора живой человек и общаться с ним нужно как с живым человеком.

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

Читай переписку.
Тебе понравится, когда одно и то же спрашивают по несколько раз? Обязательно читай переписку полностью.

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

Одно предложение - не ответ.
Ответ обязан содержать помимо ответа на вопрос пользователя еще и объяснение причин возникновения проблемы. Ответ в одно предложение - отписка.

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

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

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

Не бойся спрашивать.
Если не знаешь, что ответить пользователю - спроси у коллег. Лучше узнать точно, чем показать свою некомпетентность в вопросе пользователю. Не поленись проверить ответ перед отправкой.

Поддержка услуг (Service Support)

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

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

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

  Использоватлась своя разработка на основе Lotus Notes.

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

В это документацию мы включили

   - Соглашение о уровне услуг (SLA)

   - Каталог услуг

   - Инструкция по эскалации

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

   Как итог - перерабатывать пришлось абсолютно всю документацию.

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

 

брутальный ITIL

  Не стану вдаваться в описание всех красивостей и полезностей ITIL для среднестатистической службы IT, отдельно взятого it-директора или простого сисадмина, не буду вставлять и большие копипасты с wikipedia и прочих крайне популярных ресурсов, хотя без этого тоже не обойдется. А попытаюсь рассказать о практике внедрения iTIL в отдельно взятой компании, которая по мере своего роста пришла к нему. Так же напомню, всем джедаям, которые особо увлекаются чтением стандартов, но не практикой внедрения, что таких компаний большинство и опыт внедрения ITIL в компании в 20.000 человек, пригодится только 1%,  а опыт внедрения в компании с числом около 1.000 сотрудников будет интересен многим.

    Итак, черный ящик открывается и из него появляется великий и ужасный ITIL, встречайте!

ITIL (произносится как «айти́л», IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

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

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