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

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

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

ITIL для небольших ИТ-служб и компаний

ITIL для небольших ИТ-служб и компаний

Введение

Взрыв интереса к теме ITSM/ITIL в России пришелся на первую половину двухтысячных годов. Уже в середине нулевых не "внедрять" ITSM подход для руководителя ИТ-службы считалось признаком дурного тона. Проекты были разные — начиная от самостоятельных попыток внедрить лучшие практики ITIL (что было характерно для небольших ИТ-служб), заканчивая многомиллионными проектами с участием именитых дорогостоящих (а иногда просто дорогостоящих) консультантов и интеграторов. И, надо признать, в большинстве случаев подход был одинаковый (вне зависимости от специфики и размеров организации). Брали книжку "про ITIL", читали её (если речь о многомиллионном проекте — то нанимали консультантов, которые уже прочитали эту книжку). После разрабатывали каталог ИТ-сервисов, рисовали детальные схемы процессов, писали ролевые инструкции, внедряли Service Desk систему. И ждали счастья.

Счастье приходило?

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

Пик "моды" на ITIL, похоже, пройден. А значит, можно ожидать больше реалистичных подходов в проектах по внедрению ITSM подхода. Давайте попробуем разобраться, в чем разница между подходами для больших и небольших компаний.

В же чем дело?

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

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

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

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

— Эй, Вася, у пользователя телефон не работает, разберешься?

— Ок!

Вместо сухого: «Примите запрос в ответственность группы телефонии, прошу согласовать принятие запроса и назначить ответственного внутри отдела или отклонить его с возвратом оператору в течение одного часа».

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

Что делать?

Из этого можно сделать вывод, что тот факт, что большие организации могут позволить себе внедрение ITSM\ITIL по полной программе – это не преимущество перед небольшими, а необходимость. Внедряя процесс "по полной программе" с детальными инструкциями, метриками и регламентами, большие организации не повышают свою эффективность по сравнению с небольшими. Они пытаются довести свой уровень эффективности и управляемости до них – как раз до того уровня, когда принятие решения о действиях в ходе процесса можно будет отдать на откуп конкретным людям (это касается и согласования бюджета, и управления проектом и решения инцидентов и чего угодно). В связи со всем вышесказанным, мелким компаниям не стоит бездумно детализировать и регламентировать процессы. Регламентируйте там, где это действительно необходимо. Детализируйте настолько, насколько это действительно нужно.

Клиенты у небольших ИТ-служб — компании из сегмента среднего и малого бизнеса (СМБ). По мнению известного ITSM-обозревателя Роба Ингланда (Rob England), которое он изложил в своей статье "Tripping Out On Small-Business ITIL", одной из важнейших забот небольших компаний является снижение расхода вообще, и на ИТ в частности. Поэтому, небольшим ИТ-службам просто необходимо быть "гибкими" (это требование актуально и для больших, но для малых  это "бизнес-критикал"). Детальные инструкции, регламентирующие каждый шаг — это не гибкость. Вы потратите уйму времени на их создание, а они станут неактуальными до того, как к ним привыкнет персонал.

В больших компаниях все регламентировано. Качество работы внутренней ИТ-службы оценивают люди высокого уровня. И качество ИТ-сервисов они оценивают по отчетам с большим количеством цифр. А в SLA зафиксировано, что считать хорошей цифрой, а что нет. Поэтому для больших компаний в SLA прописано много метрик, за которыми со стороны потребителя сервисов пристально следят. В небольших компаниях качество ИТ-службы оценивается по личным ощущениям. Поэтому, какие бы вы метрики не зафиксировали в SLA, решение в отношении качества сервисов, которые поставляет ИТ-служба, будет приниматься субъективно. А значит, важнее донести до потребителя, что именно он будет получать, а не как мы будем это измерять. И, конечно, сосредоточиться на удовлетворении потребностей бизнес-заказчика, а не на формальном достижении указанных в соглашении метрик. Кстати, Роб Ингланд в упомянутой выше статье, предпочел называть SLA в СМБ компаниях как SLD (Service Level Defenitions).

Очень важно для небольших ИТ-служб обеспечить хорошее взаимодействие с потребителями ИТ-сервисов. Речь идет не только об операционной деятельности и работе службы Service Desk. Важно, чтобы клиенты понимали, какие имено услуги и в каком объеме они получают. Поэтому, нужно делать понятный и подробный каталог ИТ-сервисов. Для заказчика важно понимать структуру цены сервиса. Любой руководитель компании будет очень рад, если ему принесут каталог ИТ-сервисов, понятный для него (понятный с точки зрения ценности для его организации) с прозрачной структурой стоимости и зависимости цены сервиса от параметров его предоставления. Это позволит ему принимать решения по планированию бюджета и выбирать тот уровень сервиса, который ему нужен — а это, в том числе, означает и гибкость.

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

Так же рекомендую вам подходящие под тематику материалы:

И немного юмора на тему:

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

  • Аватар

    Бычков Валерий [vbychkov], 10 февраля 2011, 13:52

    0
    Как раз в ИТ-службе из 10 человек уже видна специализация. Это не 2-3 человека, где каждый занимается всем. Из 10 человек один руководит (как минимум в роли играющего тренера), пара специализируется на определенных серверах, еще пара на тех. поддержке и т.д. И вот тут то, как раз ITSM может помочь сделать эту организацию более четкой и прозрачной и для внутреннего применения и для того, чтобы бизнесу было понятно.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 10 февраля 2011, 13:55

      0
      Разве я написал, что принципы ITSM не применимы? Я тут больше по процессам прошелся. Они то в детализации на 10 человек как раз и не нужны.
  • Аватар

    Солопов Павел [PaSol], 16 февраля 2011, 14:20

    0
    на первую половину двухтысячных годов

    Это с 2000 по 2500? :-)
    Да уж, к 2500 надеюсь наконец как-то систематизируется эта область знаний. :-)
  • Аватар

    Солопов Павел [PaSol], 16 февраля 2011, 14:30

    0

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

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

    Но большая себе может позволить не замечать этого, у неё людей много, все по чуть-чуть поработают и хорошо.

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