Служба технической поддержки для операторов связи. Support-Desk — создание центра поддержки для своего бизнеса Создание техподдержки

Одним из ключевых моментов любого бизнеса есть общение с клиентами, в сфере интернет это выражается в виде технической, информационной и другой поддержке. Многие хостинги, регистраторы, интернет магазины, партнерки и другие сервисы, предоставляющие услуги, имеют в своем штате человека или группу людей, которые общаются с заказчиками, отвечают на вопросы и т.п. Для небольшого сайта организовать это можно и с помощью обычной почты, но если говорить о малом, среднем и крупном бизнесе, то ситуация гораздо сложнее. Здесь просто таки не обойтись без специального программного обеспечения. Вообще в последнее время часто вижу как интернет компании меняют самописные скрипты на уже готовые продукты. Сегодня речь пойдет об одном из таких решений — сервис Support-Desk — новый и один из немногих в рунете проект для создания и организации профессиональной службы поддержки.

Вообще поддержка может быть организована как для классического случая (хостинг), так и на пример при общении с клиентами (заказчиками) в любом другом бизнесе. Все обращения от них будут поступать вам не на e-mail, а в админку сервиса, при этом, конечно, вы можете разделить запросы по категориям и даже назначить для каждой из них ответственного сотрудника. Вместо того чтобы распыляться на разные направления (почта, тикеты, icq) логично было бы завести все эти потоки в Support-Desk и там уже сортировать в зависимости от темы обращения. Например, все коммерческие предложения, вопросы сотрудничества читаете сами, счета оплаты автоматически уходят в бухгалтерию, а вопросы пользователей — тех.поддержке.

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

По функциональности вопросов к Support-Desk также не возникает, здесь предусмотрен весь базовый необходимый набор функция для подобных проектов:

• Удобная переписка с расширенными возможностями (статусы, перенаправление, персональные комментарии для администраторов).
• Отделы и подотделы для обработки писем с разными темами (поддержка, жалобы, оплаты) + настройка прав доступов пользователей к ним.
• База ответов на типовые вопросы с категориями, комментированием, оценками ответов, а также подборками избранных и популярных записей. Также имеется возможность поиска по базе.
• Управление сотрудниками — добавление, прав доступа, статистика активности и т.п.
• Интеграция с Gmail — позволит полностью перевести всю почту, касающуюся технической поддержки или работы сайта в админ панель Support-Desk.
• Расширенные возможности центра поддержки — внутренняя почта, архив запросов, шаблоны ответов с поддержкой макросов.

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

Как видите, все очень просто и быстро. Для начала работы вам нужно зарегистрироваться на сайте Support-Desk.ru . После этого на выбор будут предложены 2 тарифных плана — Стандартный и Pro . В первом случае вы сможете только 2-х сотрудников, обрабатывающих до 10 тикетов в день + самостоятельно решаете какие именно опции вам нужны (интеграция с Gmail, статистика, внутренняя почта) и т.п. Все базовые возможности билетной доски и базы вопросов при этом включены. Стоимость Стандартного тарифа 5р/день, Pro обойдется вам в 10р/день, содержит больше сотрудников, тикетов и все дополнительные расширенные возможности сервиса без ограничений.

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

Здесь есть как простые опции типа названия, шаблона формы, так и более продвинутые — по работе с пользователями, отделами и т.п. Дальше попадаете непосредственно в панель управления . Здесь, в админке, есть возможность уже более детально все рассмотреть и настроить. В меню представлены основные пункты:

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

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

Собственно, вникнуть в это не сложно для пользователя, который, например, работает с той же почтой Gmail или просто разбирается в интернете. На базовое введение всех параметров, просмотр админ панели Support-Desk ушло менее 10 минут, спустя которые я уже мог видеть результат своей работы:

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

Дипломный проект «АВТОМАТИЗИРОВАННАЯ СИСТЕМА УЧЕТА И РАСПРЕДЕЛЕНИЯ ЭЛЕКТРОННОЙ КОРРЕСПОНДЕНЦИИ»

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 СЛУЖБА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ

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

Методология организации службы технической поддержки

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

В описании концепции ITIL, построенной на процессном подходе, Service Desk является единственным описанным функциональным подразделением. Это исключение сделано ввиду большой важности подразделения техподдержки при внедрении практическом использовании современных ИТ — подходов и методик.
Правильно организованная техническая поддержка (Service Desk) всегда начинается с регистрации всех обращений конечных пользователей, служит единой точкой для обращений пользователя с ИТ — службой. Наиболее популярные решения по практической организации техподдержки часто строятся на базе «Call-center» (иногда даже пользователи их отождествляют). Он является начальной точкой контактов конечных пользователей со службой техподдержки и служит источником информации об их фактической удовлетворенности уровнем сервиса, что дополняет информацию о технических параметрах качества обслуживания компании-клиента (внешнего или внутреннего). На больших предприятиях или в крупных компаниях — аутсорсерах служба технической поддержки часто организована по следующему многоуровневому принципу:

Пользователь – обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки;

Оператор (1-я линия поддержки, «Call-center») – регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки;

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

Основополагающие принципы организации службы

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

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

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

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

В этом случае пользователь может выбрать различные варианты поведения:

заняться «самолечением» – то есть попробовать самостоятельно решить проблему;

обратиться за помощью к коллегам;

обратиться к поставщику сервиса.

У каждого варианта существуют свои достоинства и недостатки.

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

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

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

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

При решении обратиться за помощью возникают новые вопросы.

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

кому именно можно обратиться.

Здесь тоже возможны различные ситуации:

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

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

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

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

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

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

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

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

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

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

Обращения пользователей
В предлагается следующий вариант классификации обращений пользователей в службу поддержки:

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

Запрос информации (консультации). Пользователю нужна дополнительная информация по сервису ИТ, порядку работы и т.п.

Инцидент. Пользователь не может нормально работать: сервис ИТ недоступен или качество сервиса не удовлетворяет пользователя.

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

Запрос на внесение изменений. Пользователь хотел бы изменить параметры сервиса ИТ либо изменить список получаемых сервисов. Часто такие запросы связаны с низким (не удовлетворяющим пользователя) качеством сервиса по вине оборудования или программного обеспечения.

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

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

Формирование правил взаимодействия

На основе выше изложенного можно сделать следующие выводы:

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

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

Вывод третий: оказание поддержки — обязанность службы ИТ; пользователи имеют право обращаться за поддержкой только к ней.

Вывод четвертый: должны быть четко определены ответственные за оказание поддержки сотрудники службы ИТ.

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

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

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

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

Можно ответить на каждый из поставленных вопросов в отдельности, но будет правильнее это делать сгруппировать ответы в некоторые последовательности действий — в процедуры и процессы .

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

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

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

Роли в службе поддержки пользователей.

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

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

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

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

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

Диспетчеры.

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

Руководитель службы поддержки пользователей.

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

Специалисты по различным направлениям деятельности службы ИТ открывают «вторую линию поддержки».

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

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

Еще одна группа ролей – внешние поставщики сервисо в.

Порядок взаимодействия с ними определяется в соответствии с сервисными контрактами.

Последняя роль – это конечный пользователь сервиса ИТ .

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

1.2 ПРИНЦИПЫ АРХИТЕКТУРЫ «КЛИЕНТ – СЕРВЕР»

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

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

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

Наиболее важными свойствами открытых систем являются свойства мобильности и интероперабельности.

Мобильность – возможность относительно простого и быстрого переноса программной системы с одной платформы на другую.

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

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

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

1.3 ОБЗОР АНАЛОГОВ

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

Рассмотрим возможности некоторых коммерческих систем.

ANDesk Service Desk (ранее Touchpaper IT Business Management Suite) – коммерческий программный комплекс с закрытым кодом, предназначенный для автоматизации работы службы технической поддержки в соответствии с рекомендациями ITIL/ITSM.
LANDesk Service Desk реализован на базе технологии Microsoft .NET

Framework и построен по архитектуре клиент/сервер. Серверные модули функционируют под управлением операционной системы Windows 2008 Server, Windows 2003 Server или Windows 2000 Server. В качестве СУБД поддерживаются Microsoft SQL Server или Oracle. LANDesk Service Desk поддерживает четыре типа консолей пользователя. Полнофункциональная консоль работает под управлением операционной системы Windows 2000, Windows XP или Windows Vista или Windows 7. Данная консоль предназначена для выполнения всех операций по настройке и администрированию системы и для работы сотрудников службы технической поддержки. Web-консоль функционирует под управлением Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator и Safari. Данный тип консоли предназначен как для работы сотрудников службы технической поддержки, так и для работы конечных пользователей по медленным каналам связи. Мобильная Web-консоль функционирует на карманных персональных компьютерах под управлением браузеров, поддерживающих HTML 4. Консоль WebDesk предназначена для работы сотрудников технической поддержки и реализована на базе Ruby.

Нет похожих постов...

Текст пишу в реальном времени, т.е. за этим словом, я даже не знаю какое будет следующее. :)

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

С1.1. Проблематика и отклонения в типовых ситуациях

1. Нет понимания между службой ИТ и руководством организации. Что приводит к конфликтам, которые потом выражаются в виде анекдотов аля "я - дартаньян, а руководство - ...". Хотя в большинстве ситуаций реальность противоположна.
2. Пользователи в шоке
   1. вынуждены тратить свое время на то, чтобы у них все работало
   2. не редко получают хамство вместо помощи
   3. доверие к службе ИТ отсутствует, т.к. одни и те же, элементарные вопросы нужно повторять, напоминать, т.к. они забываются или забиваются;
   4. про пожелания к развитию можно вообще забыть... делается только то, что хочется специалистам по ИТ, а не то, что нужно пользователям или организации;
3. В службе бардак
   1. Мало кто или практически никто из специалистов не понимает, что является результатом их труда;
   2. Путается понятие ведущих специалистов и руководителей, точнее ведущих специалистов назначают руководителями
   3. Загрузка специалистов под большим вопросом, а ее справедливость - тем более.
   4. Энергия людей распыляется в разные стороны, в итоге усталость - есть, а заметных результатов - нет.
4. Высокие издержки организации
   1. Одни и те же сбои в процессах повторяются многократно, но это мало кого волнует
   2. Простои в процессах также имеют место быть, но это также быстро забывается и повторяется с завидной регулярностью.
5. Ну и последнее, но наиболее важное... без управления процессом специалисты думают, что ИТ как то завязаны на компьютеры, и вместо развития ИТ, занимаются компьютерной техникой.

С1.2. Желаемая ситуация

1. Клиент всегда прав. Организация, руководство организации и ее сотрудники являются клиентами службы ИТ.
   1. Ключ к сердцу клиента - факты и цифры, показывающие динамики и позволяющие делать прогнозы, чтобы принимать решения.
   2. Все люди, белые и черные, принимают решения одинаково (за исключением клинических отклонений в развитии разума и закрытие в дурдоме). Разность лишь в исходной информации. Умение подобрать нужную информацию - это основа успеха и понимания.
   3. Сбор нужной информации это один из результатов правильной организации поддержки.
2. Нужно получить доверие пользователей
   1. Они должны быть уверены в том, что сообщив один раз свою мысль, она будет записана, рассмотрена, будет ответ или решение. А не игнорирование или "а я забыл".
   2. Первая фраза человека достигшего состояния Будды: я это ты. Если вы видите перед собой тупого человека... задумайтесь. Это не шутка.
   3. Начинается все с записи обращений, но затем списки (базы данных, реестры, справочники) расширяются с развитие всей системы.
3. Порядок - дело тонкое
   1. Результат службы ИТ это наличие нужной информации у сотрудников и отсутствие простоев в их деятельности. Но это лишь слова. Понять это сложно и понимание этого приходит лишь после некоторого времени использования системы управления ИТ.
   2. Справедливость штука сложная. Для ее понимания есть отдельная статья и она
   3. Кто у руля ИТ? Руководитель или специалист? Есть очень простой тест: ведется у вас регистрация обращений пользователей? Если - да, то у руля или руководитель или человек подающий надежды, если - нет, гнать нужно этого руководителя в шею, или понижать до специалиста, пусть даже ведущего.
   4. У любого действия должен быть приоритет... и в первую очередь должны выполняться те действия, которые дают больший эффект с точки зрения целей организации. Добиться этого не просто, но реально.
4. Режем издержки
   1. Простои минимизируем любой ценой, кровь из носу, т.к. любой простой это не просто "ща ща починим", это последствия, которые не всегда можно отследить, снижение репутации, потери клиентов и т.д.
   2. Сбои нужно записывать, выслеживать причины, причины устранять - повторяющийся сбой это позор джунглям.
5. Ну а выполнив эти 4 пункта, приходит понимание, что ИТ - это ИТ, и им уже сотни тысяч лет... а комьютеры - это компьютеры им всего-то лет 50 и сейчас они используются чаще, чем стены пещер лишь потому, что чуть-чуть эффективней и не более того:)

С2. Особенности

1. Ключевой факто успеха это регистрации всех обращений пользователей. Ключевое слово в этом предложении: всех . Начнешь халтурить и пропускать обращения - пошел вон, ты не руководитель.
2. Когда добьешься регистрации всех обращений, то система начнет развиваться... сразу становятся заметны узкие места:
   1. нет инструкций по процессам или инструкции кривые - много вопросов
   2. нет обучения сотрудников - много вопросов
   3. оборудование или программы слабо настроены или плохо подобраны - много сбоев
   4. специалисты занимаются чем попало, но не тем, что нужно для организации, а значит и для руководства.
   5. если проект какой-то плохо выполните, то динамика обращения подпрыгивает... надо проекты лучше планировать...
   6. ну, в общем картинка становится ясная и в голове сразу появляется множество идей о том как улучшить ситуацию...
3. Очень важный элемент системы это CMDB или КБД - конфигурационная база данных или объекты услуг:
   1. Здесь указываются все объекты, которые попадают под сферу влияния ИТ, для того, чтобы отслеживать те действия, которые над ними выполняются.
   2. Частота сбоев по программам... что чаще вызывает сбои 1С БП 8 или 1С БП 7.7? Как следствие кто из них вызывает больше затрат?
   3. Какие изменения и кто выполнял в программах? В каких? Пришло время перехода на новую версию? Какие изменения стоит повторить, а какие нет? Сколько это по финансам? Тут ответы находятся в лет.
   4. Кто то пытается сюда же пихать мышки и сетевые карты... это личное дело каждого и каждый сходит с ума по своему... но мой опыт показывает, что такая детализация дает много затрат и мало толку и по сути это мартышкин труд.
   5. В основном если вы отвечаете за ИТ, то достаточно вести учет в разрезе программ, баз данных, модулей системы, а компьютеры ваще можно записать как Компьютеры, даже без детализации по кабинетами, не говоря уже о детализации по комплектующим)
   6. А если вы отвечаете еще и за качество (это уже ИСО 9000), то сюда же можно внести перечень всех инструкций и регламентов регулирующих и нормирующий порядок действий сотрудников. В этом случае руководство на вас уже молиться начнет, свечки в церквях ставить за ваше здоровье. Это не считая прочих бонусов и соц.пакетов))

С3. Варианты решений

1. Рассмотрим для начала характеристики обеспечивающие качество ИТ
   1. Основные, обязательные, которые нужно выполнить в первую очередь
      1. Запись обращений, даты приема, даты завершения, еще можно результат фиксировать
      2. Регулярный (ежедневный, еженедельный, ежемесячный) мониторинг показателей, загрузки, результативности, динамики...
   2. Дополнительные, удобные, улучшающие, можно выполнять во вторую очередь
      1. Запись изменений, проектов, объектов услуг для дополнительных разрезов анализа
      2. Ведение истории общения по обращениям, автоматические рассылки уведомлений на эл.почту обратившимся.
2. Инструменты
   1. 1С ИТИЛИУМ
      1. Плюсы
         1. Основные требования тут выполнены
         2. Можно изменять ПО
         3. Можно найти пиратку
         4. Есть настройка автоматических уведомлений о создании
         5. Сильная отчетность
      2. Минусы
         1. Историю переписки вести тяжело, нет уведомлений о комментариях на эл.почту или возможности отвечать письмом
         2. Веб-морда тяжелая
      3. Рекомендации
         1. Для безденежных пиратов
         2. Тем, у кого политика привязана к 1С
         3. Тем, кто любит ковырять программы и любит 1С
      4. Цена что-то около 50 т.р. за ПО, услуги добавляются по вкусу.
      5. Заметки
         1. мне нравится т.к. это была моя первая система на которой построил управление ИТ
   2. eStreamDesk - одно из наиболее эффективных решений
      1. Плюсы
         1. веб-ориентированная и модель SaS, т.е. доступ из любого места и не надо парить голову с правильной установкой и тех.поддержкой
         2. интегрирована с Google Apps
         3. есть русский язык
         4. есть конструктор автосообщений как при добавлении и закрытии обращений, так и о переписке по ходу решений;
         5. реально пользоваться даже бесплатным вариантом
      2. Минусы
         1. кривоватый код, глюки и плюшевой интерфейс
         2. отсутствует CMDB
         3. слабая отчетность
      3. Рекомендации
         1. для малых проектов, там где есть проблемы с финансами
         2. и если нет юридических отношений, т.к. у обращенцев нельзя указать организацию
      4. Цена от 0 до см. сайт. Услуги тут если и нужны то по минимуму т.к. функционал базовый.
      5. Заметки
         1. им бы код до ума довести, отчетность гибче и возможность ведения базы пользователей по организациям - было бы клево.
   3. Mojo HD
      1. Плюсы
         1. те же, что и у п.2, но более приятный, отлаженный интерфейс и русификация чуть сложнее
         2. отчетность хорошая
         3. гибкий конструктор уведомлений о изменениях, комментариях...
         4. возможность отвечать на эл.почту
         5. ведение базы пользователей по организациям
      2. Минусы
         1. русского языка нет, но весь интерфейс можно переписать хоть на грубый мат
         2. цены относительно кусачие, бесплатным вариантом пользоваться не реально
      3. Рекомендации
         1. для устойчивых проектов, с наличием стабильных финансов
         2. тем, у кого нужно вести клиентуру по организациям
      4. Заметки
         1. цены чуть потише и можно считать идеальной системой для внутренних служб и проф.бизнесов
   4. ДИРЕКТУМ
      1. Плюсы
         1. Есть выделенный модуль IT.Now но с заточкой под мышки. Нарушение принципа С1.1. п.5. Что-то типа 1С ИТИЛИУМ, но мене гибкий и похуже.
      2. Минусы
         1. Те же, что и у 1С ИТИЛИУМ
         2. Выделенного и продуманного модуля в части ИСО 20000 - нет. 1С ИТИЛИУМ перекрывает возможности в лет.
      3. Рекомендации
         1. Можно написать свой модуль... что оправдано в сложных ситуациях... например в гос.управлении и в гос.услугах, там где практика еще не наработана, но нужна интеграция с большим бумажным документооборотом.
      4. Заметки
         1. ДИРЕКТУМ хорошая система ЭДО, и построение ИТСМ на ее базе оправдано лишь в том случае если на этой системе строится все остальное. как уже было сказано например в гос.управлении.
   5. 1С ITIL чего-то там от Рарус
      1. Плюсы
         1. это 1С
      2. Минусы
         1. сама программа написана теми, кто полностью подчинен стереотипу из С1.1. п.5. ориентирована на учет мышек и микросхем, вместо контроля характеристик по процессам.
      3. Рекомендации
         1. Для тех у кого нет сил сломать свои стереотипы и вместо ИТ хочется и дальше заниматься компьютерами да программами.
      4. Заметки
         1. Рарусу самим тех.поддержку нужно выправить. потом уже другим решения предлагать.
         2. субъективно меня чуть не стошнило при изучении этой программы.
   6. HP, IBM и иже с ними
      1. большие и сложные, скорее всего ориентированы на большие объемы обращений.
      2. может быть интересны для таких монстров как Мегафон или Билайн, там где толпы пользователей.
      3. слышал, что Газпромовцы такие решения покупают. наверное там откаты вкусные.
   7. Naumen ServiceDesk коробка
      1. не видел, но чую, что интересно.
   8. Naumen ServiceDesk SaS
      1. Скоро обещают выпустить.
      2. Учитывая опыт Наумен решение должно получиться интересным.
      3. Если они выберут ценовую политику как у Мегаплана, то я их даже наверно постараюсь полюбить.
      4. Очень надеюсь, что тут получится аналог Можо ХД (п.3), но с ценовой политикой как у Мегаплана.

С4. Резюме

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

С5. Просьба

1. Кто и какие еще инструменты управления ИТ знает? Особенно интересует категория SaS и возможность авторассылки уведомлений для пользователей на эл.почту...
2. Ну и вообще буду благодарен за дополнения, замечания, критику... может я где то ошибаюсь или моя информация уже устарела?

С6. Копирайты

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

Видеопомощь

В этом видеоролике описана следующая информация:
— Общая информация о проекте;
— Процедура регистрации в сети православных сайтов Prihod.ru;
— Авторизация в сети православных сайтов Prihod.ru;
— Как создать свой первый сайт в сети;
— Заполнение формы регистрации сайта;
— Основная информация о шаблонах сайтов.

Если вы уже создали сайт, то наведите курсор на «Мои сайты» в левом нижнем углу и в выпадающем меню выберите пункт «Добавить сайт».

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

Вы сможете отредактировать введенные данные в консоли сайта в разделе «Регистрация».

Форма регистрации сайта

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

Вкладка «Помощь». На вкладке «Помощь» вам предлагается ссылка на видеоролик, в котором рассказывается, как заполнять поля при регистрации. Если у вас нет возможности его просмотреть, вы можете использовать эту инструкцию.

Также на вкладке «Помощь» вам будет предложено выбрать основной язык сайта.

Чтобы перейти к регистрации, нажмите кнопку «Далее».

Первый шаг. На первом шаге регистрации нужно указать общую информацию о сайте.

Сначала выберите страну, от этого зависит на каком домене будет находиться Ваш сайт. Каждому сайту на Prihod.ru дается доменное имя третьего уровня. Для Украины это домен church.ua, для всех остальных стран — cerkov.ru или для православных организаций pravorg.ru. В дальнейшем вы сможете .

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

Имя сайта (домен) — укажите имя, которое будет у вашего сайта. Нажмите кнопку «Проверить», чтобы посмотреть, доступен ли этот домен для регистрации.

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

Обратите внимание! Сайты, относящиеся к Украинской Православной Церкви , в обязательном порядке должны иметь доменное имя на church.ua (например, vashHram.church.ua).

Итак, у вас получится доменное имя вида domain.cerkov.ru, domain.pravorg.ru или domain.church.ua.

Мы не рекомендуем указывать полное название храма (Местная Православная религиозная организация ‘Приход храма такого-то’), т.к. получается очень длинное название, это сбивает с толку непросвещенных мирян. Лучше указывать так: ‘Храм Живоначальной Троицы, поселок Доброе’.

Второй шаг . На втором шаге

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

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

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

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

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

Краткое описание курса

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

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

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

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

Цели обучения

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

• руководителям и сотрудникам, перед которыми поставлена задача по планированию и внедрению службы технической поддержки;
• сотрудникам и руководителям служб поддержки пользователей, таким как Service Desk, Help Desk, Hot Line, Call Centre;
• сотрудникам, задействованным в технической поддержке пользователей;
• руководителям подразделений, являющихся потребителями ИТ-услуг.

В результате обучения слушатели

• получат уникальный практический опыт создания комплекта документации для описания процесса поддержки пользователей на примере управления инцидентами;
• приобретут необходимые знания для построения службы технической поддержки;
• сформируют понимание принципов управления ИТ-инфраструктурой в целях осуществления поддержки пользователей;
• получат практические навыки построения службы поддержки пользователей Service Desk;
• получат необходимые знания по планированию, настройке и внедрению процесса;
• приобретут необходимые знания для управления процессом Problem Management;
• познакомятся с такими процессами как: управление событиями, управление запросами, управление доступом.

Обязательный уровень знаний

• Рекомендуется пройти обучение на курсе «ITIL ® Foundation v3. Базовый курс»;
• Желателен опыт работы в ИТ-подразделении, в частности, в одном из рассматриваемых в рамках обучения процессе или в службе технической поддержки.

Предоставляемые материалы

Слушателям предоставляются материалы, разработанные компанией «Мегаполис Профи» на основе оригинальных книг ITIL, предусмотренные программой курса. По окончании курса слушателям выдается сертификат.

Продолжительность и условия обучения

Длительность курса - 16 академических часов (2 дня). В стоимость курса включены обед и два кофе-брейка в течение каждого дня обучения.

Тренеры

Курсы проводят преподаватели, сертифицированные компанией EXIN и APMG. Преподаватели имеют большой практический опыт по внедрению процессов ITIL ® в компаниях различного масштаба.

Программа курса «Организация службы поддержки пользователей: создание документации и структура службы».

Часть 1. Теория

. Вводная часть курса
o Цели курса
o План занятий и выделение рабочих групп
. Стандарты и методологии, применяемые для создания единой точки контакта
o ISO 9001 и ISO 20000
o ITIL® и MOF
. Выбор методов описания процесса
o Многообразие возможных вариантов описания процессов
o Наиболее часто используемые методы и инструментарии
. Рассмотрение взаимосвязанных процессов в поддержке
o Роли и задачи процессов управления событиями, запросами и доступом
o Входы-выходы и взаимодействие с другими процессами
. Управление инцидентами - как основа построения единой точки контакта
o Основные принципы и понятия управления инцидентами.
o Портфолио услуг
o Service Desk - самая важная функция для работы с пользователями
o Схема процесса поддержки пользователей
o Основные активности
o Возможные проблемы внедрения
o Роли и ответственности в процессе
o Оптимизация процесса
. Управление проблемами
o Цель и задачи управления проблемами
o Основные определения
o Схема процесса - реактивный и проактивный подход
o Сложности при внедрении
o Выгоды от организации процесса

Часть 2. Практикум

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

*ITIL ® is a Registered Trade Mark of AXELOS Limited.