< Информационная система «Супербилет» - ООО "Тонлайн". Документы.

01.09.2017
В 25 музеях оснащенных системой "Супербилет" запущена программа прохода в музеи Москвы по "Карте школьника". Задачи департамента культуры по Программе мэра столицы выполнены в срок.

28.08.2017
Запущена билетная система в музее "Победа", г. Южно-Сахалинск.Современные технологии продажи билетов и услуг музея уже к декабрю 2017г. покажут рост продаж на 20%.

26.07.2017
Автоматизированная музейная билетная система СУПЕРБИЛЕТ-2017 обеспечивает на 100% сервисными функциями экскурсионный отдел, кассы, маркетинговую и финансовые службы. Сетка расписания экскурсий позволяет заказывать и оплачивать экскурсии разными способами, в т.ч. на сайте музея.

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

14.06.2017
Билетная система для музеев Супербилет-музей обретет интеллектуальную оболочку для приема "Карты школьника" при бесплатном посещении экспозиции уже с 01.09.17 согласно программе столичного Департамента культуры( kultura.mos.ru)

22.05.2017
Красноярская филармония http://krasfil.ru начинает работу с АИС "Супербилет-театр" в полном объеме.

14.04.2017
Три музея МК МО http://mk.mosreg.ru подключены к ЕИСЭБ, областной системе продажи билетов и услуг музеев.

15.03.2017
Сразу 11 театров подключили несколько операторов для продажи билетов на своем сайте в общем поле. За первый месяц продажи выросли на 10%.

12.02.2017
КЦ Зеленоград( dkzelenograd.ru )запустил последнюю версию "Супербилет", для интеграции с сайтом и билетным терминалом.

30.01.2017
Столичный Музей Моды http://fashion-museum.ru, внедрил билетную систему "Супербилет".

Архив новостей >>>

Как построить службу поддержки пользователей ИС
Заурбек Алехин

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

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

Вывод 1. По всем вопросам, связанным с использованием сервисов ИТ, пользователи должны обращаться только в службу ИТ.

   Рано или поздно и пользователи, и служба ИТ приходят к пониманию такого положения вещей. И обращение за помощью в департамент ИТ становится нормой. Но при этом возникают новые трудности. Приняв решение обратиться за поддержкой в службу ИТ, пользователь обычно оказывается перед проблемой: кому именно задать вопрос? Здесь тоже возможны различные ситуации.
   Легче всего обратиться к человеку, которого знаешь. И он обязательно поможет, если, конечно, это в его силах. А как быть, если такого знакомого нет? Или если у него недостаточно полномочий? Или он занят выполнением важной работы?
   Можно спросить любого сотрудника службы ИТ. Он, скорее всего, посоветует, к кому именно следует обратиться. Далее нужно спросить у рекомендованного. Цепочка может продолжаться и дальше. Пользователю, конечно, действовать таким образом неудобно. И не только пользователю! Отсутствие сотрудников, ответственных за работу с пользователями, приводит к хаосу в деятельности службы ИТ, а в итоге — к контрпродуктивному выяснению отношений.
   Поэтому единственный вариант, когда любой пользователь точно знает, к кому именно следует обращаться с вопросами, а соответствующий представитель службы ИТ всегда готов выслушать обращение и предпринять необходимые шаги для решения поставленного вопроса, — это создание в рамках ИТ-департамента службы поддержки пользователей.

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

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

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

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

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

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

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

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

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

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

    Роли в службе поддержки пользователей
       Следующий важный момент при создании службы поддержки — люди. Как правило, приходится несколько менять организационную структуру информационной службы. Это связано с необходимостью выделить группу сотрудников, которые будут исполнять обязанности диспетчеров — т. е. тех, к кому непосредственно будут обращаться пользователи со своими запросами. В небольшой организации такие обязанности иногда возлагаются на одного или нескольких сотрудников службы ИТ в дополнение к существующим обязанностям. В крупных организациях, а также там, где поддержка очень важна, следует создать специальное подразделение — диспетчерскую службу поддержки пользователей.
       В общем случае необходимые изменения в структуре службы ИТ связаны с появлением новых ролей в результате формального описания процессов взаимодействия. Роль — это набор обязанностей, прав и ответственностей. Это понятие близко к понятию «должность», но отличается тем, что не предполагает штатного закрепления: исполнитель роли может меняться в соответствии с графиком или по иным правилам. В отдельных случаях (например, в случае диспетчеров) для исполнения роли может быть создана специальная штатная единица. Но в основном роли распределяются между имеющимися сотрудниками службы ИТ.
       Какие роли могут возникнуть в ходе организации поддержки пользователей? Во-первых, это уже упоминавшиеся диспетчеры — их еще принято именовать «первая линия поддержки». Диспетчеры — это «лицо» службы поддержки; они отвечают за организацию взаимодействия с пользователями, своевременное информирование пользователей о ходе рассмотрения их запросов, закрытие запросов. Кроме того, диспетчеры инициируют рассмотрение обращения пользователя, регистрируя это обращение и назначая ответственного за его обработку, а также контролируют процесс обработки. На них могут быть возложены и иные обязанности.
       Вторая роль — руководитель службы поддержки пользователей. Его основные задачи — организация поддержки пользователей; координация действий сотрудников в процессе их обработки; контроль эффективности работы службы поддержки; организация обучения персонала службы ИТ, задействованного в поддержке пользователей; обучение пользователей и т. д. Для исполнения данной роли тоже рекомендуется выделить штатную единицу.
       В-третьих, это специалисты по различным направлениям деятельности службы ИТ — так называемая вторая линия поддержки. Специалисты второй линии — основные исполнители запросов пользователей. Для улучшения взаимодействия они могут быть объединены в рабочие группы (например, комплексная группа по поддержке определенного сервиса ИТ, в которую входят специалисты по всем образующим данный сервис технологиям). Очевидно, что в этом случае не стоит формировать отдельные подразделения, а следует привлекать специалистов на временной основе (хотя могут быть и исключения). Но привлекаемые специалисты должны быть четко проинформированы о приоритетах своей деятельности: оказание поддержки пользователям — одно из наиболее приоритетных направлений деятельности службы ИТ, и если возникают ситуации, когда имеющихся сотрудников не хватает для быстрого решения этой задачи, следует рассматривать вопрос о расширении штата службы. С другой стороны, четкое распределение обязанностей, как правило, резко сокращает непроизводительную деятельность персонала службы ИТ, так что на самом деле очень редко приходится увеличивать численность службы (чаще даже речь идет о сокращении).
       Служба поддержки может иметь и большее число уровней. При этом предполагается, что роли последующих уровней исполняются более квалифицированными и опытными сотрудниками, чем предыдущих. Обращения к ним редки и возникают только в действительно важных, критичных для организации случаях.
       Еще одна группа ролей — внешние поставщики сервисов. Порядок взаимодействия с ними определяется в соответствии с сервисными контрактами. Желательно стремиться к стандартизации правил взаимодействия, но это не самоцель.
       И, наконец, последняя роль — это пользователь сервиса ИТ. Ее можно специально не выделять, поскольку данная роль изначально подразумевается. Тем не менее мы это делаем, чтобы еще раз подчеркнуть, что пользователь на самом деле активно участвует в процессе поддержки и имеет не только определенные права, но и обязанности.

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

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

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

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

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

    Средства автоматизации
       Третий (после четких правил и подготовленного персонала) ключевой элемент системы поддержки пользователей — специализированные технологии, используемые для деятельности сотрудников в соответствии с оговоренными правилами.
       Особое место при организации службы поддержки занимают средства голосовой связи. Практика показывает, что для максимальной эффективности службе поддержки нужен единый многоканальный телефонный номер, возможность организации конференц-связи, возможность набора номера непосредственно из компьютерной системы. Часто оказываются полезными специальные телефонные комплекты hands-free, позволяющие освободить руки оператора от телефонной трубки. Остальным специалистам департамента ИТ желательно иметь либо мобильную телефонную связь, либо пейджер, чтобы можно было гарантированно информировать их о необходимости связаться с оператором.
       Кроме того, в службе поддержки пользователей могут быть полезными следующие программные продукты:
  • системы «самопомощи» — автоматизированные системы, дающие пользователям возможность без участия диспетчера выполнить определенные действия: регистрацию заявок, получение информации и т. д.;
  • экспертные системы, базы знаний;
  • средства группового взаимодействия и управления работами;
  • средства регистрации и учета заявок;
  • средства мониторинга сервисов и отдельных их элементов;
  • средства анализа и отображения информации.

  •    Часто отдельные программные продукты объединяют в себе функции, относящиеся сразу к нескольким из перечисленных направлений, реализуя их с большей или меньшей полнотой.
       В теории для деятельности службы поддержки пользователей достаточно только так называемых бумажных технологий: все необходимые данные регистрируются ручкой в бумажных журналах. И в большинстве действующих организаций именно так и происходит. Основные плюсы такого подхода — его предельная дешевизна (если не углубляться в структуру затрат) и понятность: обучать никого не требуется. С минусами намного сложнее. Это и трудности с поиском необходимой информации, и невозможность автоматизированного анализа, и сложность доступа, и проблемы с резервным копированием, и вероятность внесения ошибок, и т. д., и т. п.
       Некоторые из перечисленных недостатков удается устранить, адаптируя несложные программные продукты для целей автоматизации службы поддержки. Например, в небольших организациях часто используют стандартный офисный пакет: текстовый редактор, электронные таблицы и простейшую СУБД. Как правило, этот вариант намного лучше, чем «бумажный», но все же возможности его весьма ограничены, и большинство операций сотрудникам приходится выполнять вручную. Это, как и прежде, приводит к потенциальным ошибкам, усложняет процедуры, требует дополнительных затрат времени. Часто такая автоматизация заслуженно воспринимается как нечто лишнее, только мешающее нормальной работе персонала. В итоге сотрудники не используют системы по назначению и работают так, как им удобнее. Отдельные репрессивные мероприятия периодически «подогревают энтузиазм» в использовании средств автоматизации, но его хватает ненадолго.
       Специализированные программные продукты лишены перечисленных недостатков. При их разработке производители учитывают определенные требования и пожелания, высказываемые потребителями такого рода систем.
       Остановимся подробнее на средствах поддержки группового взаимодействия и учета обращений пользователей — основе системы автоматизации службы поддержки. В крупной организации, где используется множество разнообразных систем и технологий, для системы автоматизации желательны следующие функции и возможности:
  • регистрация обращений пользователей различными способами;
  • однозначная идентификация зарегистрированных обращений;
  • разделение обращений по категориям;
  • автоматизированный учет времени регистрации;
  • автоматизированный контроль сроков обработки обращений;
  • автоматизированная эскалация обращений;
  • интеграция с базой данных оборудования, приложений и документации: связь обращений с элементами базы;
  • интеграция с базой пользователей: связь обращений пользователей с пользователями;
  • интеграция с базой персонала: связь обращений пользователей с исполнителями;
  • расширенный поиск информации;
  • публикация стандартных вопросов и проблем;
  • создание различных отчетов.

  •    При этом логично потребовать, чтобы система обладала достаточной производительностью и масштабируемостью, функционировала на доступных аппаратных и программных платформах, имела средства разграничения доступа и т. д. Для нашей страны также весьма актуальна возможность использования кириллицы в интерфейсе и при регистрации обращений пользователей.
       В идеале систему следует строить «с нуля», выбрав за основу достаточно производительную СУБД. В этом случае решение будет максимально полно отвечать потребностям организации. С другой стороны, цена такого решения окажется весьма существенной, поскольку предстоит разработать довольно сложный продукт и обеспечить его дальнейшее сопровождение. К тому же это потребует длительного времени: системы такого класса не создаются быстро.
       Альтернативное решение — выбрать программный продукт нужного класса из имеющихся на рынке. Сегодня существует ряд продуктов для автоматизации поддержки пользователей с разными параметрами и возможностями. Как правило, эти продукты адаптируются под конкретную организацию. В конечном счете выбор зависит от потребностей организации, а также от соответствия продукта разработанным правилам функционирования службы поддержки и уровню подготовленности персонала.

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

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

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

    Список документов >>>

     

    Супербилет-театр
    Супербилет-кино
    Супербилет-музей
    Супербилет-агентство
    Супербилет-кинофестиваль
    Супербилет-театр-фестиваль

    О фирме
    Наши партнеры
    Наши клиенты
    Дилерам
    Аппаратные требования
    Документы и стандарты
    Интернет-проекты
    Вход для клиентов
    Вакансии

    Написать нам письмоПоиск по сайту

    Центр информационных технологий для театров



    Rambler's Top100