Портал №1 по управлению цифровыми
и информационными технологиями

Взгляд извне на внутренние группы

Обращаюсь к сообществу – вы будете смеяться – с просьбой разъяснить терминологическую путаницу.

В стандарте ISO/IEC 20000-1:2011 появилось определение Internal group (внутренняя группа), следующего вида:

internal group – part of the service provider's organization that enters into a documented agreement with the service provider to contribute to the design, transition, delivery and improvement of a service or services

NOTE The internal group is outside the scope of the service provider's SMS

Мой перевод:

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

ПРИМЕЧАНИЕ Внутренняя группа находится вне охвата системы управления услугами (СМС).

Это определение в тексте стандарта встречается 6 раз (вне глоссария):

  • 2 раза в Governance of processes operated by other parties, где эта внутренняя группа приравнивается к внешним поставщикам услуг или компонентов.
  • 1 раз в Design and transition of new or changed services, где внутренние группы являются источником новых требований к услугам, наряду с заказчиками и внешними поставщиками.
  • 3 раза в требованиях к процессу Service Level Management, где стандарт требует заключения SLA с заказчиками, внешними поставщиками и внутренними группами.

Теперь из глоссария ITIL урожая того же года:

Соглашение операционного уровня (OLA) – Соглашение между поставщиком ИТ-услуг и другой частью той же организации. Это соглашение поддерживает поставщика ИТ-услуг в предоставлении ИТ-услуг заказчикам. Соглашение операционного уровня определяет предоставляемые товары или услуги и ответственность обеих сторон. Например, соглашения операционного уровня могут быть заключены:

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

И там и там фигурирует некая "организация поставщика услуг", зажатая между заказчиком и внешними контрагентами.

Меня интересует ее "часть", которая упоминается в стандарте как internal group, а в ITIL – как субъект, с которым поставщик услуг заключает OLA.

ITIL даёт два варианта ответа: 

  • это организация, частью которой является ИТ-служба (у нас распространена аббревиатура "ДИТ" или "УИТ")
  • это группа внутри оргструктуры поставщика услуг (служба поддержки, группа системного администрирования, департамент разработки)

Стандарт же, насколько я могу трактовать вышеприведённое ПРИМЕЧАНИЕ, от второго варианта отказывается вовсе.

То есть аудитор, который будет сертифицировать СМС организации  на соответствие стандарту ISO 20000 (не важно – по версии 2005 или 2011 года), не будет рассматривать имеющиеся OLA как свидетельства СМС? 

То есть OLA в смысле договорённостей между различными командами\департаментами\отделами поставщика услуг – не нужны?!

То есть вспомогательных услуг не бывает?! (см. занимательную дискуссию у Скептика и, конечно же, у Дмитрия Исайченко – про равенство договаривающихся сторон)

То есть ITIL не прав?!… дальше уж боюсь думать;)

Спасайте в комментариях! =)

Комментариев: 12

  • Понятие Internal group введено в ISO/IEC 20000:2011 для уточнения определения области охвата сертификации, поскольку позволяет трактовать часть внутренних групп, как поставщиков услуг, на которых сертификация не распространяется. Например, если я сертифицирую услугу “Service Desk”, которая требует ресурсов ЦОД, я могу трактовать ЦОД как услугу вне области сертификации и область охвата проверяемых процессов на управление ЦОДом не распространять.

    Поэтому утверждение “Стандарт же, насколько я могу трактовать вышеприведённое ПРИМЕЧАНИЕ, от второго варианта отказывается вовсе” мне представляется неверным.

    P.S. Шикарная картинка 🙂

    • Иначе говоря, практика, на которую ссылается Скептик…
      (“сертификация Real ITSM следует практике ISO 20000, позволяя кандидатам самим определять границы проверяемой на соответствие области. Так компания может, например, сертифицироваться только в рамках одной страны. Ну, или консультанты могут заказать сертификацию своего костюма и/или ботинок, а не всех своих услуг целиком. Предполагается, что сертифицированные организации (продукты, люди) всегда будут уточнять границы сертифицированной области при указании любых ссылок на свои сертификаты. Вообще-то, мы думаем, вы никогда не будете этого делать, но «предполагается» – отличное слово, чтобы перенести на вас ответственность. “)
      …теперь благодаря короткому комментарию может быть реализована так, что никто не подкопается. То есть в строгом соответствии с буквой стандарта.
      Верно?

      • Конечно.
        Тем более, что некоторые компании ещё в 2010 году взяли эту практику на вооружение, предвидя (видимо) обновление стандарта ISO 20000 в 2011.

        Например, некий ЕвроСтандартРегистр выдал удивительный сертификат: http://www.realitsm.ru/wp-content/uploads/iso20k_itsk.jpg

      • Не знаю, как отвечать – серьёзно или шутя. Тем более глядя на комментарий Олега.
        Позитивное изменение в стандарте 2011 года как раз в том и заключается, что более чётко сформулированы требования к определению области сертификации. В частности пункт 4.5.1 утверждает “The scope shall be defined by the name of the organizational unit providing the services, and the services to be delivered“. Представленный скан сертификата прямо противоречит этому пункту.
        Так что фраза “некоторые компании ещё в 2010 году взяли эту практику на вооружение, предвидя (видимо) обновление стандарта ISO 20000 в 2011”, как и комментарий Романа мне не очень понятны.

        • Ну почему непонятны? Сертификация системы управления одной-двумя услугами в организации, которая не только оказывает этих услуг широчайший спектр – за рамками охвата сертификации – , но ещё и указывает на эту сертификацию как на аргумент при их покупке, оставляет впечатление легкого лукавства, не сказать ещё хужей. Когда возможность такого ограничения охвата закладывается в тексте стандарта, это впечатление усиливается.
          Что и добавляет иронии в мои и, думаю, Олега комментарии.

          Стандарт в редакции 2011 года много лучше, чем в редакции 2005. Но описанную практику сертификации отдельных ботинок он по-прежнему поощряет. Что не добавляет веса сертификатам в глазах аудитории, коей они адресованы. А жаль – и именно потому, что в части требований к системе управления он, повторюсь, стал намного лучше.

          ИМХО, разумеется.

          • Но описанную практику сертификации отдельных ботинок он по-прежнему поощряет

            Честно говоря, не вижу в этом ничего зазорного. Напротив, считаю разумным. ISO 20000 требует реализации довольно серьёзного инструментария, и применять его для управления всеми услугами без разбора может быть просто неоправданно дорого. Почему ты считаешь возможным реализацию управления изменениями в отдельно взятых областях инфраструктуры (там, где это больше всего нужно), но “улыбаешься” над аналогичным подходом к ограничению области применения процессов ITSM, требуемых стандартом ISO 20000?

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

              Кроме того, я верю в неравномерность уровней capability и maturity отдельных процессов в отношении отдельных услуг, но не верю в возможность существования нескольких SMS у одного поставщика, разделенных по охватываемым услугам.

            • +1 к Роману.

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

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

              • “Только давайте быть до конца честными и указывать ту самую область сертификации при любом упоминании своего сертификата”

                А я как раз “за”. Только Роман, как мне кажется, говорит немного не об этом, а о том, допустимо ли сужать область сертификации до управления отдельными услугами.

                И вообще дискуссия ушла в сторону. Приведённый тобой скан – просто это откровенное враньё потребителям (я даже не буду играть в перечёркивания слов). К стандарту ISO 20000 это имеет такое же отношение, как нарисованная мной купюра – к деньгам. И определение области охвата сертификации – по отдельным услугам или по всем услугам – не имеет здесь никакой роли. Просто одни хорошие ребята выдают другим хорошим ребятам за бабло ничего не значащую бумажку, эксплуатируя при этом название стандарта, к которому они никак не относятся. Делать на основании этой истории вывод о том, что стандарт такой подход к сертификации “поощряет”, мне кажется крайне странным.

                Это бы называлось мошенничество (или регистратора, или сертифицированной организации), если бы не одно “но” – наше государство квалифицирует это деяние совсем иначе – как гармонизацию стандартов. “А с минобороны мы ничего сделать не можем”.

              • “эксплуатируя при этом название стандарта, к которому они никак не относятся”

                Добавлю: и похоже не очень понимают (стандарт, имеется ввиду).

    • Дмитрий, а исходя из комментариев Олега и Романа, и моего максималистского предположения что сертифицировать хорошо бы систему менеджмента всех услуг а не отдельного ботинка: тогда OLA остаются или нет?


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM