Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

С чего начать внедрение ITSM?

С чего начать внедрение ITSM?

Когда появляется желание внедрить ITSM, первый вопрос, на который хочется найти ответ: "С чего начать?". Сейчас не будем обсуждать, что вообще-то начать нужно с вопроса "Зачем?". Хочется поговорить о том, с чего действительно стоит начать в случае нулевой зрелости, чтобы получился хотя-бы какой-то порядок в операционке. Поэтому правильнее было бы назвать данную статью "с чего начать наведение порядка в операционной деятельности службы поддержки пользователей".

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

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

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

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

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

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

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

Автомтизировать можно хоть экселем. А можно (ненавязчивая реклама) с использованием ITSM365 (покрывает 100% процессов, описанных на схеме).

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

Комментарии (28)

  • Аватар

    Яковлев Андрей Михайлович [swtws], 29 ноября 2011, 11:34

    0
    Изящно, но несколько теоретически. То есть, если уровень зрелости нулевой, а менеджмент ни то ни се, то из соображений гуманности лучше от затеи отказаться. Опять таки нужна последовательность реализации - если только не найдутся те, кто сразу на весь проект подпишется. Как следствие потребуется "быстрая победа" с минимумом затрат.
  • Аватар

    Юсов Алексей [alexus], 29 ноября 2011, 20:35

    0
    Уважаемый, Кирилл! Вот пишите, что будем говорить про "операционную поддержку", а сами сюда "пихаете" Change и Configuration. А это уж немного другой блок - Transition. Давайте определимся, господа!
    Второй момент. По моему мнению, внедрение ITSM умрет на создании каталога услуг.
    Схема в принципе хорошая и "как в ITIL". Но если говорить о сабже, т.е. "с чего начать?", то эта схема неподъемная как "начало" хоть с Экселем, хоть со SmartNut-ом.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 30 ноября 2011, 11:53

      0
      Алексей, нету здесь нигде change management-а. И configuration management-а совершенно нет. И я даже названиями книг не оперировал (service operation) :). Вы правы, что все это на первом этапе взорвет голову. Напрочь.

      В посте намерянно расшифровал, что за каждым "квадратиком" скрывается. Например, есть исключительно CMDB в объеме инвентаризации объектов обслуживания (это очень далеко до 100% CMDB), и есть управление изменениями в CMDB, которое расшифровано как "поддержание информации об объектах обслуживания в актуальном состоянии".

      Предлагаю не проводить параллели с официальной терминологией всея ITIL-а. Мы ж не за стандарты, а за здравый смысл :)

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

      Касательно каталога услуг: вопрос в его детализации. Просто перечислить список сервисов (как его видит ИТ-руководитель) без согласования с бизнесом даже (и без указания бизнес-заказчика) вполне сойдет. А можно этого на первом этапе даже и не делат.
  • Аватар

    Скрынник Олег [Олег Скрынник], 05 декабря 2011, 12:14

    0

    Как это - "с чего начать"? С первой линии поддержки, конечно же! :)

    http://www.realitsm.ru/2011/11/service-desk-saved-the-world-again

    (извините за рекламу, если это реклама).

    • Аватар

      Юсов Алексей [alexus], 06 декабря 2011, 15:28

      0
      И строевой песней СД сделать песню Eurythmiks "I saved the wold toda-a-a-y"! Это прекрасный совет (с легкими элементами рекламы)!
  • Аватар

    Горлова Елена [crista79], 05 декабря 2011, 15:38

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

    • Аватар

      Юсов Алексей [alexus], 06 декабря 2011, 15:14

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

    Солопов Павел [PaSol], 10 января 2012, 13:40

    0

    Вообще-то, если вы собираетесь внедрять именно itSm, то надо начинать с каталога сервисов. Поскольку для того, чтобы был Service Management нужно как-то определиться что будет сервисом.

    Ну а если вы внедряете ITsM (буква S тут так по привычке затесалась), то я бы советовал начать с управления работами (всеми), другими словами с внедрения культуры постановки задач исполнителям (в неком формальном виде) и регистрации выполняемых работ. А потом уже делить их на инциденты, изменения и пр. Выделять нужные приоритетами и т.д.

    • Аватар

      Горлова Елена [crista79], 10 января 2012, 16:53

      0
      Ну с формализацией все более-менее понятно, а вот с систематизацией сервисов действительно есть сложности..
       У нас есть понятие "Поддержка программных продуктов" (не клиентов). Поэтому можно говорить о сервисе "Поддержка ПП" (консультации, исправление дефектов); есть сервис "кастомизации" (доработка ПП). Просто когда пытаешься связать это с разработкой ПО начинаются головоломки :)
      • Аватар

        Солопов Павел [PaSol], 10 января 2012, 17:03

        1

        Что-то я не понял вас, Елена, что "ЭТО" вы пытаетесь связывать с разработкой ПО и где и с чем возникают проблемы?

        • Аватар

          Горлова Елена [crista79], 10 января 2012, 18:52

          0
          На самом деле, Павел,  наверное я далеко ушла от темы статьи.
          Есть задача - описание бизнес-процессов компании. Поддержка собственных ПП является одним из таких процессов. Реально, ситуация сейчас такова, что вторым уровнем поддержки являются сами разработчики (и консультируют, и исправляют баги ПП если нужно).  Т.о. предоставление сервиса поддержки тесно связано с разработкой (изменением ПП и выпуском патчей - а это отдельный большой процесс). Описание этих процессов (поддержки ПП и разработки) вызывает сложность, потому что они тесно связаны и у каждого есть много тонкостей. 
          • Аватар

            Солопов Павел [PaSol], 11 января 2012, 10:18

            0

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

            Сложно описать в одном процессе, разбейте на несколько.

            Основной вопрос, тут у меня такой, правда: "Вы с какой целью вообще взялись описывать?".

            Вы хотите описать как есть, чтобы было и на полочке стояло, или вы хотите описать как надо и свою деятельность поменять? 

            • Аватар

              Горлова Елена [crista79], 11 января 2012, 12:16

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

                Солопов Павел [PaSol], 11 января 2012, 12:43

                0

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

                Ну а в остальном у вас, судя по всему, просто уровень зрелости процессов 0 всё выполняется "Ad-hoc", или говоря по простому "как бог на душу положит".

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

              • Аватар

                Солопов Павел [PaSol], 11 января 2012, 12:45

                1

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

                • Аватар

                  Горлова Елена [crista79], 11 января 2012, 14:02

                  0
                  Спасибо за советы, Павел. Будем описывать как есть, посмотрим что получится.
                  • Аватар

                    Солопов Павел [PaSol], 11 января 2012, 14:04

                    0

                    Не за что, Елена! Советы давать, как говорится, не мешки ворочать. :-)

                    • Аватар

                      Ланцев Андрей [Sansey], 12 января 2012, 14:22

                      0
                      Хорошая схема вышла у Кирилла. Также понравились слова Павла о том, что начинать надо с "внедрения культуры постановки задач исполнителям (в неком формальном виде) и регистрации выполняемых работ". Когда начинаешь работать, то клиентов мало (1-2) и все заявки можно в уме держать. Начинаешь расти и автоматически приходишь к мысли, что надо как-то вести учет. Начинаешь с экселя и потом плавно переезжаешь на что-то похожее на Смартнат (либо пишут сами, либо покупают готовое). И только потом, когда связка "пользователь"-"первая линия" отработана начинаешь усложнять систему вводя такие понятия как метрики и инфраструктура. Причем путь этот может затянуться на годы. Например моей компании уже 4 года, но до CMDB мы не доросли. Корявенько это у нас организовано. Не говоря уж про управление изменениями. Но сейчас мы плотно работаем в этом направлении. Разрабатываем софт и стратегии максимально безболезненного внедрения. Поэтому в целом считаю, что статья очень в "кассу", особенно молодым аутсорсерам. Спасибо, Кирилл.

Также рекомендуем