Решение для сервисных подразделений
Главная / Решения / SBM для ИТ / Решение для сервисных подразделений

Решение для сервисных подразделений

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

 

Настоящий документ ориентирован на:

    • руководителей ИТ направлений;
    • руководителей служб ServiceDesk;
    • специалистов служб ServiceDesk;

Рассматриваемая задача \ цели:

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

По результатам ожидается:

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

Средний срок внедрения решения:

1-2 месяца с момента заключения договора о выполнении работ и поставке программного обеспечения.

 

Автоматизация службы Service Desk на базе решения Serena Business Mashups

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

    • рабочих процессов;
    • задействованных специалистов;
    • состояний, включающихся в рабочие процессы;
    • количества запросов в подразделение;
 

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

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

 

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

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

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

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

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

  • Обследование существующих бизнес процессов, идентификация операций и их описание. Без наличия чёткого понимания всех участников того, что именно выполняется в том или ином бизнес процессе, кто отвечает за выполняемые операции и с какими иными операциями и как связана каждая из операций будет невозможно сформировать целостную картину работы подразделения, выявить однотипные, похожие и уникальные операции, выделить имеющиеся и действительно необходимые информационные потоки, сформировать перечни метрик, характеризующих качество выполнения бизнес процессов и качество работы специалистов.
    • Проведение комплекса мероприятий в рамках реинжиниринга выявленных бизнес процессов исходя из особенностей предметной области работы сервисного подразделения. В процессе реинжиниринга ставится иная задача, нежели просто проанализировать те процессы и операции, которые уже есть. Главной задачей является построение новых процессов в которых устраняются недостатки уже существующих:
      • Избыточные информационные потоки в одних операциях и недостаточные в других. Избыток информации обычно приводит к увеличению времени выполнения работы ввиду необходимости сбора \ поиска \ проверки излишней информации. Отсутствие же информации может просто не позволить найти решение запроса на самых первых этапах работы с ним в сервисном подразделении.
      • Дублирование операций и неверное распределение ответственности. Сотрудники вынуждены повторно собирать информацию, которую уже мог найти и проанализировать специалист на предыдущих этапах или же вынуждены выполнять перепроверку сведений, так как за саму операцию проверки и её качество отвечают все и никто одновременно.
      • Задержки с передачей информации между участниками, которые можно было бы убрать просто изменив процесс и не передавая информацию или же в случае необходимости передачи выполнять иные взаимосвязанные операции.
    • Разработка регламентов выполнения бизнес процессов. Регламенты будут необходим для того, чтобы:
      • Сами сотрудники были осведомлены о том, как должны выполняться те или иные операции и каждый из сотрудник в цепочке был уверен в том, что поступающая к нему информация необходима и достаточна для выполнения действий по запросу;
      • Все запросы обрабатывались по общим правилам и не получалось, что один запрос выполнен более качественно или быстрее чем другой с таким же приоритетом, так как работа над запросами шла «неизвестно как»;
      • Менеджеры процессов по работе с запросами имели однозначную картину того, каково состояние работы над каждым конкретным запросом и каково состояние работы подразделения в целом;
      • Удовлетворить требованиям законодательных или иных нормативных актов. Так, например, при работе с персональными данными с использованием информационных систем запрещено приступать к работе, пока сотрудники письменно не ознакомились с процессом обработки персональных данных, условиями их обработки и ответственностью за невыполнение регламентов компании.
    • Выбор и создание инструмента управления регламентируемыми бизнес процессами. Это шаг просто невозможно пропустить, так как принимать решение о том, что будет использовано для планирования работы, учёта хода решения заявок, сбора статистики и выполнения анализа всё равно придётся. Пусть это будет набор листочков бумаги. А может это будет специализированная информационная система. Необходимо принять взвешенное решение, так как от выбора инструмента будет зависеть и то, насколько эффективно будет выполняться процесс по новой технологии в самом начале, а также то, насколько сложна будет адаптивность процесса, масштабируемость процесса, управляемость процесса в будущем.
    • Обучение сотрудников работе по новой технологии и её внедрение в деятельность сервисного подразделения.

 

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

    • среднее время регистрации запросов \ обращений;
    • количество регистрируемых запросов в единицу времени;
    • распределение регистрируемых запросов по типам;
    • количество «ложных» обращений;
    • количество регистрируемых запросов по классификационным признакам (специалистам, источникам, по ПО или технических средствам, по услугам, по технологиям поступления запросов, по времени дня и иным критериям);
    • среднее время выполнения запроса \ этапа запроса (по классификационным признакам);
    • доля запросов, результатами которых пользователь не удовлетворён (по классификационным признакам);
    • среднее время реакции, среднее время решения запроса (по классификационным признакам);
    • изменение времени решения запросов (по классификационным признакам);
    • доля запросов, решённых на разных линиях работы службы поддержки (по классификационным признакам);
    • количество повторных обращении по решённым запросам (по классификационным признакам);
    • множество других метрик, которые будут отражать специфику именно вашей области деятельности и структуры вашей сервисной службы.

 

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

Более стратегически правильным решением было бы применение в качестве инструмента специализированных систем, созданных именно для управления бизнес процессами (системы класса BPM или Business Process Management). Это направление информационных систем обычно позволяет решать следующие задачи:

    • создавать графические модели рабочих процессов по различным типам запросов и обращений;
    • настраивать перечни информационных реквизитов, которые будут доступны пользователям и специалистам сервисной службы по каждому информационному объекту в зависимости от рабочего процесса, прав доступа, состояния объекта;
    • настраивать и формировать отчёты о том, каково на текущий или произвольный момент в прошлом состояние работ сервисного подразделения в части исполнения запросов;
    • настраивать электронные уведомления о событиях в системе и непосредственно их рассылать;
    • обеспечивать приём и отправку сообщений из \ в внешних систем.

Одним из решений класса BPM является решение компании Serena - Serena Business Mashups, позволяющее создать под потребности практически любой компании инструмент управления бизнес процессами, позволяющий:

    • выполнять графический дизайн и настройку рабочих процессов, форм пользовательского интерфейса, ролей, пользователей и их прав;
    • выполнять настройку проектов и их иерархии, групп пользователей, прав на выполнение операций;
    • предоставлять интерфейс конечного пользователя для работы с информацией по запросам (ввод, поиск, выборка, изменение, перевод состояний, удаление запросов, присоединение файлов, комментариев, ссылок и иной информации к запросам, просмотр истории изменений любых данных в системе, настройка и формирование отчётности, работа с базой знаний);
    • настраивать и рассылать электронные уведомления о событиях в системе;
    • считывать электронные письма с системных почтовых ящиков, анализировать содержимое и либо присоединять её к имеющимся запросам, либо создавать новые запросы

 

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

 

Обращение в поддержку

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

 

Консультация

Если обращение в Service Desk потребовало провести консультацию пользователя, то инициируется процесс консультации. Консультация может выполняться один или несколькими внутренними специалистами или внешней компанией-поставщиком ИТ решения.

 

Инциденты

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

 

Задачи по разработке

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

 

Запросы на изменение

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

 

Технические работы

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

 

Несмотря на всё богатство возможностей, практически для любого ИТ решения пользователь может сформулировать набор желаемых изменений, которые бы позволили сделать его более удобным, близким к тем бизнес процессам, к которым пользователь уже привык. Возможность полного изменения и доработки решений заложена в качестве основных в перечень функций Serena. Вся процедура по построению или изменению решения на базе Serena Business Mashups будет состоять из 3х несложных шагов:

 

Разрабатывайте визуально процессы

и соединяйте системы

с использованием  Mashup Composer

 

Используя Serena Mashup Composer бизнес аналитик может визуально сконструировать новый Mashup за считанные часы.

 

Mashup Composer разработан так, чтобы он выглядел как и привычные приложения Microsoft Office.

 

    • Разработайте рабочие процессы;
    • Объедините системы;
    • Разработайте свой или уточните автоматически создаваемый пользовательский интерфейс;

Бизнес Mashup(ы) с лёгкостью

управляются, тестируются и внедряются

 

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

 

    • Сохраните сконструированный Mashup;
    • Выберите среду (например тестовую или рабочую) в которую Вам необходимо опубликовать Mashup;
    • Запустите процедуру публикации;

Использовать бизнес Mashup(ы) так же легко,

 как и обычный Интернет веб сайт

 

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

 

    • Перейдите по ссылке страны входа в систему или воспользуйтесь прямой ссылкой на любой объект системы;
    • Пройдите авторизацию (либо воспользуйтесь функцией SSO - Single Sign On);
    • Начинайте использовать простой для восприятия и интуитивный веб интерфейс SerenaBusinessMashups

 

 

На конец весны 2009 года ряд организаций уже воспользовались решением:

    • ММВБ
    • R-Style Softlab
    • Компьютерные системы для бизнеса (CSBI)
    • АйТи-Аптека
    • СДК Гарант
    • Внешэкономбанк
    • ПЕТЕР-СЕРВИС
    • и другие известные российские компании, имена которых мы не можем разглашать исходя из подписанных соглашений о конфиденциальности.

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