Уровни зрелости систем «ServiceDesk»

4 июня 2012
21 11118

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

Уровень реализации концепции SD (как единой точки контакта с пользователями и заказчиками), а значит и потенциальный эффект от ее внедрения могут существенно отличаться. Почему? Что же является принципиально важным, определяющим при развертывании SD на конкретном предприятии?

Вариант 1: Определяющим является возможности конкретной программной платформы SD.

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

Вариант 2: Определяющим является уровень организации 1-ой линии.

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

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

Вариант 3: Определяющим является ориентация на результат и соответствие стандартам.

Для проверки на соответствие библиотеке ITIL можно ответить на такие вопросы:

  • Кем и насколько полно (тотально) регистрируются запросы пользователей и сообщения об инцидентах?
  • Кем и насколько полно производится оценка и классификация инцидента? (Категория, критичность, приоритет, крайний срок)?
  • Кем и в каком объеме регистрируется ход работ по устранению инцидента?
  • Кем и как контролируется устранение инцидента по времени?
  • Кем проверяется факт устранения инцидента? Каким образом?
  • Ориентирован ли процесс на скорейшее восстановление сервиса?

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

Вариант 4: Определяющим является уровень организации 2-ой линии.

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

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

Вариант 5: Определяющим является «уровень зрелости» SD как процесса.

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

  • Существует ли система автоматизации процесса?
  • При замене системы, сильно ли поменяется регламент?
  • Востребованы ли отчеты по показателям процесса?
  • Документирована ли связь данного процесса с другими процессами?
  • Документирована ли деятельность по непрерывному улучшению процесса?
  • Насколько процесс связан с ИТ-стратегией?
  • Насколько процесс связан с Бизнес-стратегией?

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

Уважаемые коллеги, какой из предложенных вариантов подходит для Вашей организации?

И что Вы можете назвать в качестве ключевого фактора успеха при создании ServiceDesk?


Коментарии: 21

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Александр Балабанов
    Рейтинг: 858
    Независимый эксперт
    Директор по ИТ и Цифровой трансформации
    05.06.2012 14:54

    Приветствую Игорь! Спасибо за данную тематику дискуссии. По нашей Компании: Какой вариант? Вариант №3, Вариант №5. Конечно же не могу отрицать Вариант №2,4 - это компетентность персонала, но это вторично. Ключевой факторы успеха создания ServiceDesk? Получение бизнес-бенефитов как от процесса, так и от системы, автоматизирующей данный процесс. В настоящий момент в нашей организации в информационных системах по регистрации заказов и контроля их исполнения нуждается каждое подразделение - увидели преимущества для себя при работе с IT ServiceDesk

    • Игорь Клопотов Александр
      Рейтинг: 140
      СКБ ЛАБ, ООО
      ведущий архитектор проектов
      06.06.2012 08:08

      Александр, и вам доброго времени суток! По варианту 5, особенно если планируете включать в цикл новые подразделения, могу добавить следующее: Из методологических руководств поможет COBIT, а также ISO/IEC 15504-2 «Информационная технология. Оценка (аттестация) процессов жизненного цикла программных средств. Часть 2. Эталонная модель процессов и их зрелости». Уровни зрелости процессов по COBIT/ISO 15504 следующие: 0. Non-existent / Неполный процесс (процесс не полностью реализован или не смог достичь своего назначения). 1. Initial/Ad Hoc / Осуществленный процесс (процесс достиг своих определенных выходов). 2. Repeatable but Intuitive / Управляемый процесс (реализовано планирование; мониторинг; регулировка). 3. Defined / Установленный процесс (появилась стандартизация; принимаются во внимание факторы подготовки персонала и уровень ресурсного обеспечения). 4. Managed and Measurable / Предсказуемый процесс (реализована измеримость процесса; контролируется уровень вариаций; появляется увязка с бизнес-целями). 5. Optimised / Оптимизирующий процесс (определены цели улучшения процесса, которые обеспечивают бизнес-цели; проанализировано влияние вносимых изменений; любое вмешательство в ход процесса понятно, согласовано, проверено). Самое интересное, как водится, приведено в скобках :-) Можно еще оценить существующую систему SD на базе набора моделей CMMI for Services. Там можно попробовать ввести весовые коэффициенты, то есть появляется метрика для сравнения систем SD между собой.

  • Игорь Клопотов
    Рейтинг: 140
    СКБ ЛАБ, ООО
    ведущий архитектор проектов
    11.06.2012 06:40

    Обратил внимание, что в дискуссиях GlobalCIO часто возникает вопрос о едином понимании терминов предметной области. Это действительно важно. Поэтому "на берегу" приведу несколько определений, являющихся, по моему мнению, базовыми для направления SD: ========================================================== ITIL® V3 Glossary Russian Translation v0.92, 30 Apr 2009 (огромная благодарность экспертам рабочей группы Комитета по переводам и публикациям itSMF) ========================================================== Help Desk (HD) - Точка контакта для Пользователей для регистрации Инцидентов. Служба поддержки обычно более технически ориентирована, чем Служба Service Desk, и не предоставляет Единой точки контакта для всех взаимодействий (SPOC). Service Desk (SD)- Единая точка контакта (SPOC) между Поставщиком услуг и Пользователями. Типичная Служба Service Desk управляет Инцидентами, Запросами на обслуживание, а также взаимодействует с Пользователями. Single Point of Contact (SPOC) - Предоставление единого простого способа для общения с Организацией или Бизнес-единицей. IT Operations Management - Функция Поставщика ИТ-услуг, которая выполняет повседневную Деятельность, необходимую для управления ИТ-услугами и поддержки ИТ-инфраструктуры. Управление операционной деятельностью ИТ включает Контроль операционного управления ИТ и Управление инженерным обеспечением. Business Service Management (BSM) - Подход к управлению ИТ-услугами, который предполагает, что ИТ-услуги поддерживают Бизнес-процесс и повышают ценность, формируемую Бизнесом. Этот термин также обозначает управление Бизнес-сервисами, предоставляемыми Бизнес-потребителям. Business Continuity Management (BCM) - Бизнес-процесс, отвечающий за управление Рисками, которые могут серьезно повлиять на Бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение Рисков до приемлемого уровня и планирование способов восстановления Бизнес-процессов в случае нарушения Бизнеса. BCM устанавливает Цели, Охват и Требования по отношению к Управлению непрерывности ИТ-услуг. Vital Business Function (VBF) - Функция в Бизнес-процессе, критичная для успеха Бизнеса. Критичные бизнес-функции являются важным предметом рассмотрения в Управлении непрерывностью бизнеса, Управлении непрерывностью ИТ-услуг и Управлении доступностью. Single Point of Failure (SPOF) - Любая Конфигурационная единица, которая может быть причиной Инцидента во время ее отказа, и для которой нет внедренной Контрмеры. SPOF Может быть сотрудником, или шагом в Процессе или Деятельности, также как и Компонент ИТ-инфраструктуры. Business Continuity Plan (BCP) - План определяет шаги, необходимые для Восстановления Бизнес- процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его Инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п. Планы обеспечения непрерывности ИТ-услуг являются значимой частью Планов обеспечения непрерывности бизнеса. ========================================================== (...123...)

    • Игорь Авдасев Игорь
      Рейтинг: 10
      HD LED TECH
      Директор по развитию ИТ
      31.08.2012 16:08

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

  • 20.06.2012 15:01

    Уважаемые коллеги! Я посмотрю на SD из другой плоскости. Меня интересует проблема аутентификации Заявителя. В существующих реалиях SD используется и для решения многочисленных проблем информационной безопасности. Самый наглядный пример - работника не пускает Система. В этом случае, обычно следует заявка в SD о смене пароля (других аутентификационных объектов (данных)). Как надежно идентифицировать Заявителя? И сделать это во всех многочисленных возможностях подачи заявки.

    • Игорь Клопотов
      Рейтинг: 140
      СКБ ЛАБ, ООО
      ведущий архитектор проектов
      20.06.2012 19:14

      А что Вы вкладываете в понятие "надежно"?

      Доменной аутентификации вполне должно хватать (логин на сервер SD из браузера автоматический под аккаунтом доменного пользователя). Если речь про телефонную точку контакта, то опять же, IP телефония однозначно идентифицирует рабочее место (аппарат/порт). Если же нужно именно идентифицировать Заявителя, то можно задействовать все известные методы и инструменты многофакторной аутентификации (включая карточки, используемые и в системе пропусков, личные кодовые слова, анкетные данные, данные паспорта и иных персональных документов). Нужна действительно многофакторная система - переменные коды на персональные коммуникаторы и т.п. подходы из практики ДБО. Еще можете посмотреть продукцию отечественной фирмы wentor software, на их библиотеках вполне реально сделать анализ голоса...

      Это не проблема методологии SD, как мне кажется.

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

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

      Если же речь про пароль доступа в корпоративную сеть/AD (как-бы мастер пароль), то эти вопросы решаются только так: новые регистрационные данные предоставляются начальнику сотрудника по независимому каналу. И пусть они уже между собой разбираются с "взысканиями за забывчивость".

      • Владимир Дорин Игорь
        Рейтинг: 10
        Газпром нефть шельф, ООО
        Начальник отдела развития информационных систем
        10.08.2012 15:34

        Коллега, а Вы не считаете, что уровень зрелости SD зависит от уровня зрелости самой компании? К тому же отрасль имеет значение. Вот, например, возьмите нашу отрасль, где все-таки проявляются издержки.

        • Игорь Клопотов Владимир
          Рейтинг: 140
          СКБ ЛАБ, ООО
          ведущий архитектор проектов
          10.08.2012 15:45

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

          • Ильгизар Талипов Игорь
            Рейтинг: 20
            Когнитивная бизнес модель
            ИТ архитектор
            05.09.2015 09:24

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

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

    • 14.09.2012 13:57

      Здравствуйте! Хочу порекомендовать вариант выдачи временного пароля руководителю сотрудника, у которого произошел инцидент. Руководителю временный пароль высылается по электронной почте и он передает его своему сотруднику, который при первом входе производит его смену. В случае отсутствия руководителя, это может выполнить лицо, его замещающее или на крайний случай коллега. Если система SD позволяет, то можно придумать (что в принципе давно используется в других компаниях и сферах деятельности) кодовое слово, которое можно запрашивать у обратившегося, для авторизации, в случае передачи конфиденциальной или коммерческой информации. Спасибо.

  • Павел Тойменцев
    Рейтинг: 221
    Цифроздрав
    Технический директор
    25.06.2012 11:01

    Определяющими являются ориентация на результат и квалификация сотрудников предприятия (Вар. 2-4).

    • Игорь Клопотов Павел
      Рейтинг: 140
      СКБ ЛАБ, ООО
      ведущий архитектор проектов
      25.06.2012 14:00

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

      • Дмитрий Бацюро Игорь
        Рейтинг: 10
        Ситилинк (ГК Мерлион)
        Старший ИТ-бизнес-партнёр
        25.06.2012 14:51

        Мне кажется, это большая проблема - найти разумный баланс "продвинутости" сотруников 1-й линии, при котором они будут достаточно квалифицированно консультировать по большому количеству вопросов, не загружая при этом 2-ю линию, но при этом их амбиции не будут требовать массового повышения им з/п, карьерного продвижения и т.п. ("Массового" - потому что не исключаю наличие в 1-й линии отдельных звезд, которых нужно и можно продвигать выше.) Вопрос: как это сделать? Часто приходится сталкиваться при звонке в некоторые организации с тем, что 1-я линия не способна решить большую часть вопросов, и после выслушивания меня переключают на более квалифицированного специалиста, которому заново приходится излагать суть вопроса. Такой вариант SD отнюдь не идет на пользу компании: цикл обслуживания удлиняется, удорожается, клиент раздражается.

        • Игорь Клопотов Дмитрий
          Рейтинг: 140
          СКБ ЛАБ, ООО
          ведущий архитектор проектов
          25.06.2012 15:10

          Конечно проблема!
          Тут ведь "палка о двух концах". Если мы начинаем привыкать к тому, что на 1-ой линии достаточно высоко квалифицированные в предметной области сотрудники мы рискуем:
          - не справиться с пиком обращений (сезонность, крупные изменения)
          - теряем гибкость и устойчивость организации 1-ой линии (некем быстро заменить людей при реорганизации, выбытии)
          - постепенным снижением уровня коммуникативных требований в пользу профессиональных знаний

          Решения у такого рода проблем конечно же есть. И наиболее продуктивными, на мой взгляд, является подходы, связанные с "переносом опыта эксперта на уровень оператора". Это будут уже не интерактивные скрипты, а полноценная организация базы знаний. Когда оператор 1-ой линии работает в живую и со скриптом и с предметно-ориентированной поисковой системой, опирающейся на актуализируемые сотрудниками 2-ой линии и аналитиками статьи базы знаний.

          Построение структуры и создание инструментов работы со "знаниями" - это отдельная сложная и обширная тема ...

          • Дмитрий Бацюро Игорь
            Рейтинг: 10
            Ситилинк (ГК Мерлион)
            Старший ИТ-бизнес-партнёр
            25.06.2012 18:31

            Очень интересно было бы обсудить тему - кто как строит у себя работу со знаниями и, в особенности, со знаниями, требуемыми для качественной работы SD. Может быть, раз эти темы связаны, здесь и обсудим?

        • Андрей Федоров Дмитрий
          Рейтинг: 10
          Эван
          ИТ менеджер
          05.07.2012 10:47

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

          • Игорь Клопотов Андрей
            Рейтинг: 140
            СКБ ЛАБ, ООО
            ведущий архитектор проектов
            06.07.2012 06:23

            Скажу больше -в РФ у Ростелекома сейчас 3 линии поддержки: 1 я линия - "скриптовики" 2 я линия - "молодые специалисты" 3 я линия - "ассенизаторы" И количество висяков, эскалируемых на 3-ю линию постоянно растет (это я не придумал, это вывод из общения с руководителем соответствующего регионального подразделения). Такими темпами им придется порождать 4-ю линию ... а страдаем то мы - клиенты. В противовес могу привести (на основе личного опыта) организацию службы SD у провайдера ЗАО "Ин-Солв": - за несколько лет ни разу не удалось пробиться на 2-ю линию, так как все вопросы закрывались (конечно в разные сроки) на 1-ой линии.

            • Дмитрий Бацюро Игорь
              Рейтинг: 10
              Ситилинк (ГК Мерлион)
              Старший ИТ-бизнес-партнёр
              06.07.2012 10:20

              Может быть, у ЗАО "Ин-Солв" SD состоит только из 1-й линии, а как таковой 2-й линии нет, у спецов с 1-й линии есть только возможность консультироваться с какими-то более глубокими специалистами, не объединенными формально во 2-ю - поэтому все вопросы и закрываются в разные сроки, но на 1-й линии? :-) Такая организация работы, мне кажется, тоже имеет право на жизнь, особенно в относительно небольших организациях или ИТ-подразделениях.

      • Павел Тойменцев Игорь
        Рейтинг: 221
        Цифроздрав
        Технический директор
        25.06.2012 15:26

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

  • 26.06.2012 22:00

    В Сбербанке давно и успешно работает ServiceDesk (от НР). Учитывая размеры организации и объем IT-инфраструктуры, SD - это единственный способ не дать скатиться этой сфере в полный хаос (это как бы ответ на второй вопрос - о "ключевых факторах успеха при внедрении" ;)) Причём (возвращаясь к размерам организации) SD не един по всему Сбербанку, а разделен по числу территориальных банков (порядка 17 штук) + свой SD на Центральный аппарат. В случае необходимости специальные запросы выставляются на диспетчеров SD тербанка для того, чтобы те выставили запрос на SD Центрального аппарата. Но 95% запросов на обслуживание (ЗНО) решаются в рамках тербанка. Кроме ЗНО активно используются такие функции, как "Задания на доработку ", "Управление проблемами", реализованы SLA по подразделениям с описаниями и мн. др. В общем, неподготовленному человеку можно легко погрязнуть даже в SD любого отдельного тербанка, не говоря уже о представлении об объёмах и функциях всего парка SD Сбербанка...

    • Игорь Клопотов
      Рейтинг: 140
      СКБ ЛАБ, ООО
      ведущий архитектор проектов
      27.06.2012 06:22

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

      Реализовано ли в Сбербанке управление конфигурациями, управление проблемами? В какой мере?
      Реализован ли SPOC?
      1-я линия квалифицированная в предметной области или нет?
      Реализовано ли наполнение и использование базы знаний?
      Реализован ли принцип: "Управление инцидентами должно быть направлено на сокращение времени решения инцидентов, а управление проблемами – на увеличение времени бесперебойной работы"?
      SD ориентирован на IT вопросы, или в т.ч. решает задачу поддержки бизнес-процессов?

      У нас тоже банк не маленький, правда территориальных центров поддержки не 17, а всего 4, но работа служб SD (технически реализована на базе LANDesk SD), в ее "методологической чистоте" пока очень далека от совершенства. Конечно, это субъективное мнение. Для того и обсуждаем, делимся опытом и мнениями.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.