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

"Пиратство" конечно (да простит Microsoft :) ):

Надо стереть ветку реестра:
HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ Windows NT\CurrentVersion\ Winlogon\Notify\ WgaLogon

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

Клиент не получает данные от DHCP сервера

Позвонили - попросили помощи в решении образовавшейся проблемы:
Новая рабочая станция стабильно присваивает себе адрес из сетки 169.254.x.x. Сетевая карта рабочая - проверено.  
Решение конечно оказалось достаточно тривиальным - нужно было отключить поддержку VLAN на сетевой карте.
Нашел еще один способ, как побороть данную напасть, поэтому опишу оба - мало ли - может еще кому-нибудь понадобится:

1.
 int ip reset

netsh winsock reset

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnEnableBcastFlagToggle, установить в 1.

2.

Отключить поддержку vlan с настройках сетевой карты.

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

Системныe коды по анализу log системы Windows Server 2012

Потихоньку все глубже и глубже осваиваю MS Windows 2012. Пускай будет здесь - полезно знать и помнить.

Узнать кто перезагружал систему server 2012
Event Viewer -> Windows Logs -> System (Filter Current Log)
Event id 1074

Event id 6008 — Не штатное выключение сервера. (либо отключали электричество, либо перезагрузили через ilo)

Event id 26 — Сервер выключил УПС по истечении 20 минут. Application popup: System Shutdown

Event id 1076 Выключение системы

Event id 4478 Кто заходит на сервер с помощью RDP

Узнать кто успешно залогинился на сервере Windows Server 2008
Event id 1149

Узнать кто изменял пароль на учетную запись — Event id 4738
Параметр Password Last Set — отмечает дату когда был изменен пароль для учетной записи.
Level: Information

 Контроллеры доменов

Event ID — (Категория) — Описание

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

2) 676, или Failed 672 или 4768
(Аудит событий входа в систему) 
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.

3) 681 или Failed 680 или 4776
(Аудит событий входа в систему) 
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.

4) 642 или 4738 
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.

5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.

6) 624 или 4720 
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя

7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа

8) 517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности

Вход и выход из системы (Logon/Logoff)

Event Id — Описание

528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)

Типы входов в систему (Logon Types)

Тип входа в систему — Описание

2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)

Коды отказов Kerberos

Код ошибки — Причина

6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена

Коды ошибок NTLM

Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание

3221225572 — C0000064 — Такого имени пользователя не существует
3221225578 — C000006A — Верное имя пользователя, но неверный пароль
3221226036 — C0000234 — Учетная запись пользователя заблокирована
3221225586 — C0000072 — Учетная запись деактивирована
3221225583 — C000006F — Пользователь пытается войти в систему вне обозначенного периода времени (рабочего времени)
3221225584 — C0000070 — Ограничение рабочей станции
3221225875 — C0000193 — Истек срок действия учетной записи
3221225585 — C0000071 — Истек срок действия пароля
3221226020 — C0000224 — Пользователь должен поменять пароль при следующем входе в систему

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

Как стать грамотным, знающим и понимающим 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-руководителем.

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

ITSM: что это такое и с чем его едят?

Продолжение темы, которую я начал относительно недавно (тут). 

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

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

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

Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы IT-подразделения. Суть его в том, что вся деятельность IT-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что IT-подразделением можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.

ITIL (Information Techno-logy Infrastructure Library) – это библиотека рекомендаций, обобщающая международный опыт по организации работы IT-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов.  В ITIL описывается, как должна быть организована деятельность IT-структур.  Но там не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

Как объяснить бизнесу необходимость ITSM?

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

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

Как получить финансирование на проект и оценить его окупаемость?

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

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

2. Увеличение эффективности и направление фокуса IT-деятельности на решение задач бизнеса. Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу IT-подразделения таким образом, что в центре ее внимания окажется именно бизнес. IT-подразделение превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

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

Следует ли затраты на IT распределять по бизнес-подразделениям и бизнес-пользователям?

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

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел IT-подразделения. Для анализа можно применять известные методики  или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает IT-подразделение в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы IT, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к IT-подразделению на основе сбора и обобщения требований и ожиданий бизнеса от IT и возможностей IT-подразделения удовлетворить потребности бизнес-подразделений.

После того как сформировано представление о состоянии дел «как есть» и проанализированы требования бизнеса к IT, определяется состав процессов ITIL, которые будут внедрены, и очередность их внедрения. Другими словами, перечень процессов ITIL, которые необходимо внедрить в данной организации, вытекает из бизнес-потребностей предприятия. Тем не менее практически всегда, когда проводится внедрение процессной модели управления IT на основе рекомендаций ITIL, в том или ином виде внедряют процесс управления инцидентами. Что вполне закономерно, поскольку именно этот процесс отвечает за взаимодействие пользователей и IT-подразделения, это своего рода интерфейс между ними. Второй процесс, практически всегда рекомендуемый к внедрению, — управление уровнем услуг. В его рамках непрерывно анализируются потребности пользователей и принимаются меры к повышению качества обслуживания.

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от IT-подразделения, и IT-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

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

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

Обязательно ли организовывать Service Desk?

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

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

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных IT-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет все IT-подразделение.

Как оценить численность сотрудников Service Desk?

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

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

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

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

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой. Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами IT-подразделение, легче проводить планирование внедрения, поскольку при четкой организации деятельности IT повышается прозрачность и управляемость IT.

Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как IT-подразделения, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

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

Что будет, когда закончится проект?

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

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

Как включить буфер обмена в VMWare vSphere Client

Продолжаю мучать VMWare.

Как оказалось по умолчанию буфер обмена не включен и когда нужно скопировать какой-нибудь код и или файл - а буфера нет, то впадаешь в уныние. По умолчанию в настройках виртуальных машин VMWare vSphere буфер отключен, но его можно включить. Для этого выключаем виртуалку и открываем ее свойства. Далее на вкладку Options – Advanced – General, жмем кнопку Configuration Parameters…

В открывшемся окне жмем кнопку Add Row и добавляем два новых значения —isolation.tools.copy.disable и isolation.tools.paste.disable со значениями false.

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

P.$.

Буфер можно активировать еще и на самих хостах, как это сделать описано в статье — Clipboard Copy and Paste does not work in vSphere Client 4.1 and later (1026437).

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

Наболевшее

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

В целом я согласен с автором сего повествования.

Есть хорошая книга - "Мужчины с Марса, Женщины с Венеры", где автор Джон Грэй советует парам для улучшения своих отношений признать и принять различия между мужчинами и женщинами. Он утверждает, что мужчины и женщины так же отличаются друг от друга, как существа с разных планет. Если понять эти различия, общаться станет гораздо проще. Аналогично в ИТ - мы должны признать, что существуют значительные различия между специалистами по ИТ и непосредственными руководителями (в данном конкретном случае), хотя, казалось бы, и я, и непосредственный руководитель заинтересованы в ИТ. Нам нужно научиться лучше понимать друг друга, чтобы достичь этой цели. Но всегда ли это получается на практике?

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

         Поэтому и говорят так: о начальстве или хорошо или вообще ничего не говорят.

И я выскажу, почему я не хочу тут работать:

Я "увешан" должностями, функционалом и обязанностями:

1. Начальник отдела сопровождения информационных технологий (в непосредственном подчинении четыре системных администратора)

2. Главный администратор по информационной безопасности

3. Руководитель дежурной службы

4. Выполняю функции системного администратора, при необходимости - функции help-desk.

5. Администратор почтовой системы Exchange 2010, администратор домена, Wsus, антивирусной системы, терминального сервера, баз данных (MS SQL), прокси серверов (FreeBSD), Vmware

6. Оказываю техническую и консультационную поддержку системным администраторам филиалов и операционных офисов

                Если еще вспомнить, получится очень неслабый список.

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

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

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

Я лишился эмоций. У нас не принято завидовать и радоваться. Т.е. все это останется внутри меня, постепенно угасая, но я перестаю показывать это все на своем лице. Скука — это моя новая маска.

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

Меня научили, что такое ЖПП (жопо-прикрывательные письма). Этим особым видом коммуникаций владеет каждый маломальский офисный сотрудник. Я начну в любой переписке генерировать много-много респондентов в поле CC, до тех пор, пока вопрос не станет неразрешимым, а имя создавшего проблему будет забыто.

Я научился не слушать людей, которые говорят со мной. Большинство опытных офисных работников на совещании, как только с ними начинают говорить, утыкаются в смартфон, начинают болтать и т.д. Я научился постоянно проверять почту и верить в то, что я ОЧЕНЬ заняты и от меня ОЧЕНЬ многое зависит.

Я провожу на работе по 9-12 часов. Но работаю я или нет…. Я научился убеждать себя, что я делаю нужную работу, что я перегружен и все это замечают. Главное не вызвать подозрение, что у меня есть что-то еще в жизни и работа — только средство достижения.

Я боготворю пятницу. Для частного предпринимателя пятница — это ужас, бизнес перестает работать на 2 дня. Для меня же — это лучший день в неделе —забыть о работе на два дня.

Я станете кофеиново (чайно)-зависимым и полюбил туалеты. Кофе (чай) утром, кофе (чай) перед полудником, кофе (чай) перед обедом, кофе (чай) после обеда, кофе (чай) до 5 o’clock tea, кофе (чай) перед выходом домой. Если я курю, то сюда следует добавить столько раз кофе, сколько раз курю. Туалеты спасают, когда пить кофе просто не хочется. Если бы там была курилка, то там бы был главный штаб, переговорка, митинг-рум.

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

И так далее и прочее-прочее. Список может быть бесконечно длинным....

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

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.$ В чем-то конечно гипотетично, но можно принять к сведению отдельные моменты для работы или для саморазвития.

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