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

Вопрос из зала про каталог услуг: что улучшить?

Опубликовано 20 апреля 2012
Рубрики: SLA, SLM, BRM, Вопрос из зала, Инструменты
Комментарии

Максим спрашивает:

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

С разрешения автора, публикуем этот документ.

Ваши рекомендации, коллеги?

Также по теме:

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Peshkov Alexander

    Основные сведения:

    — наименование услуги

    — ответственный

    — владелец

    — связный бизнес-процесс

    — ссылка на спецификацию

    — ссылка на сла

    Хорошо бы это вынести в каталог,

    может быть, что-то еще, по-необходимости

    Одно не совсем понятно — это каталог услуг или каталог систем?

    • Максим Никитин

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

      Вопросы по сути:

      — «владелец» и «ответственный» — чем они отличаются?

      — «связный бизнес-процесс» — это бизнес-процесс заказчика в котором услуга востребована или бизнес-процесс, который реализует эту услугу в ИТ?

      — «ссылка на спецификацию» — спецификация чего?

  • Волков Николай

    Стоит ли разделять «услуги», «системы», «продукты»? Изначально в Каталоге должно быть «Видеоконференция», «Рабочее место», «1С-Бухгалтерия». Расписывать более подробно может просто не потребоваться.

    • Максим Никитин

      Я рассматриваю услугу — как набор действий (бизнес-деятельность). Действия должны быть приложены к чему-то. «Предметом» приложения действия является «Продукт». Это, на мой взгляд, будет понятно бизнес-пользователю: они получают услугу «функционирование продукта» по продукту «электронная почта». Система — это больше наше, ИТ-шное понятие. Оно призвано помочь определить границы предмета. Например, инцидент «У меня не работает электронная почта в Firebird» может быть признан нелегитимным по причине, что в продукт входят системы «Exchange» и «Outlook».

      Второй сценарий применения «системы» является разруливание ситуаций с интеграционной обработкой — приложением, которое осуществляет обмен данными между двумя системами. Приходит инцидент по Продукту: «Я в системе А не вижу данных из системы Б». Мы должны проверять работоспособность обмена данными на стороне системы Б или ограничиться только проверкой работоспособности обмена данными на стороне А? Ответ на этот вопрос позволяет получить деление Продуктов на Системы, где интеграционная обработка является полноценной Системой.

      • Вадим

        а разве обмен во втором случае не операционный сервис (услуга операционного уровня)?

        и проверять IMHO надо именно соответствующий интерфейс между системами А и Б + посмотреть наличие данных в системе А (ведь она может работать автономно от системы Б).

        Что при этом будет вашим продуктом совершенно неочевидно.

        • Максим Никитин

          Допустим, есть системы:

          С1. Exchange

          С2. Outlook

          С3. Project Server

          С4. Project professional

          С5. Модуль интеграции Project Server и Exchange для отправки уведомлений из Projet Server

          Есть продукты:

          Пр1: «Электронная почта» — состоит из С1 и С2

          Пр2: «Персональное планирование» — состоит из С4.

          Пр3: «Командное планирование» — состоит из С1, С3, С4, С5,

          Есть одна услуга: «У1. Функционирование Продукта».

          Подразделение1 заказывает (потребляет) услугу У1 по Пр1 (SLA1)

          Подразделение2 заказывает (потребляет) услугу У1 по Пр2 (SLA2)

          Подразделение3 заказывает (потребляет) услугу У1 по Пр3 (SLA3)

          Это нам позволяет в рамках одной услуги «чинить» Excange с разным SLA. Позволяет «добраться» до Exchange, а не остановиться на этапе «модуль интеграции отработал, а что там дальше меня не волнует». И наоборот — отсечь деятельность по организации уведомлений для пользователей Подразделения 2.

          • Вадим

            в приведенном вариант у вас нет одной услуги У1 для одного, второго, третьего. у вас есть три услуги с похожим названием и чем-то похожим содержанием. при этом услуги реально соответствуют тем вашим продуктам, а системы — операционным сервисам.

            получается термин «продукт» лишний (для этой схемы, конечно).

            насчет «разных» SLA.

            у вас, безусловно, могут быть разные OLA для одних и тех же ОС, входящих в состав разных услуг (обслуживаемых с разными SLA). но оно вам надо???

            если да — дерзайте, только не запутайтесь, когда и кому (какой услуге) какие параметры OLA обеспечивать

        • Максим Никитин

          "а разве обмен во втором случае не операционный сервис (услуга операционного уровня)? "

          Чувствую, пробел в своих знаниях 🙂 Что почитать на эту тему?

          • Вадим

            ITIL )))

          • Вадим

            на самом деле это такая же услуга только более близкая «к земле»

            • Максим Никитин

              Вадим, а кому в таком случае оказывается услуга операционного уровня?

              • Вадим

                одно внутреннее подразделение другому.

                это может быть и внешний поставщик услуг.

                разница в том, что с внешним поставщиком есть формальный контракт (Underpinning Contract — UC), а с внутренним поставщиком — менее формальное OLA

                • Максим Никитин

                  Давайте предположим, что у нас есть всего одно подразделение, состоящее из одного человека. Он оказывает, как Вы и говорили, три услуги — «с похожим названием и чем-то похожим содержанием» — У1, У2, У3. Оказывает он их разным бизнес-подразделениям, соответственно, П1, П2, П3. Правильно я понимаю, что для каждого бизнес-подразделения мы заключим именно SLA?

                  • Вадим

                    IMHO, да должны будем заключить

                    например, юристам — консультант, бухгалтерии — 1с, сейлзам — поверпойнт

                    • Максим Никитин

                      Тогда не понятно, откуда появилось OLA в Вашем ответе выше:

                      «у вас, безусловно, могут быть разные OLA для одних и тех же ОС, входящих в состав разных услуг (обслуживаемых с разными SLA). но оно вам надо??? если да — дерзайте, только не запутайтесь, когда и кому (какой услуге) какие параметры OLA обеспечивать»

                    • Вадим

                      OLA будет, например, на услугу (операционный сервис) обслуживание БД: для MS SQL — одно OLA, для Oracle — другое

  • Peshkov Alexander

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

    По вопросам:

    — владелец — это бизнес-менеджер, Заказчик услуги

    — ответственный — это айтишник, сервис-менеджер

    — бизнес-процесс — это процесс Заказчика, который поддерживается услугой

    — спецификация — совокупность функциональных, объемных и временных характеристик услуги

    Внешняя спецификация содержит только то, что может быть интересно бизнесу. SLA — это то, что бизнес заказал из внешней спецификации )

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

    • Максим Никитин

      Александр, спасибо, но у меня теперь еще больше вопросов 🙂

      "Услуга, по-определению, содержит внутри себя систему (инфраструктура + бизнес-приложение/продукт), "

      Не очень понятно.

      1. Если мы разрабатываем новый продукт? То услуга не может в себе содержать продукта — его еще пока нет.

      2. Давайте представим, что у нас в каталоге одна услуга «Функционирование принтеров». Продукт — принтер, система — принтеры конкретной марки. Правильно я понимаю, что по Вашему должны быть услуги «Функционирование принтеров марки А», «Функционирование принтеров марки Б» и т.п.? И получение нового вида принтеров должно привести к новой услгуе «Функционирование принтеров марки С»?

      «Например, услуга «бухгалтерия и налоговый учет» не то же самое, что «1С-бухгалтерия». Может быть там внутри САП — зачем это пользователю-то?»

      Это нужно, чтобы можно было сказать: «Проблемы с бухгалтерией на „Парусе“? Это не к нам, а на САП к нам.». Тем более, что выше Вы пишете "Услуга, по-определению, содержит внутри себя систему " — значит, пользователю нужно знать какая система входит в услугу, а какая нет?

      «— владелец — это бизнес-менеджер, Заказчик услуги» — разве это регламентируется в катклоге услуг? А не в сервисном договоре? Ведь одну и ту же услугу могут заказывать разные заказчики. И SLA с каждым из них будет разным: электронная почта одному подразделению нужна круглосуточно, а другому только с 9 до 18.

      • Вадим

        «ууууу, как все запущено...» ©

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

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

      • Peshkov Alexander

        Золотые слова! Причем, «обеспечение функционирования» — это тоже такая оккультная терминология. «Печать и копирование документов» — звучит куда более естественно и понятно.

        Тогда действительно совершенно неважно, что внутри такого сервиса, Принтер А и Принтер Б или Хпукс или Шорька — главное, чтобы сервис оказывался. По сути речь о том, что пользователь может принменять ИТ для повышения своей производительности. Понятно, что это терминологический вопрос, и тем не менее. Пользователь получает интерфейсы, которые ему выдает ИТ-сервис провайдер в соответствии со спецификацией. Эти интерфейсы работают с качеством, которое было согласовано ранее с учетом стоимости.

        Информация о том, какие «веревки» внутри эих интерфейсов — нужна командам поддержки в виде РСМ, регламентов, соглашений операционного уровня и тп.

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

        • Максим Никитин

          Хорошо, у меня есть услуга, которая называется «Печать и копирование документов». Приходит пользователь и говорит: «Я не могу со своего домашнего айпада ничего распечатать». Я могу его послать с формулировкой «Данная услуга доступна только с рабочих компов под управлением винды»? Если могу, то где эти ограничения прописываются?

          • Вадим

            в SLA

            P.S. странно что с айпада не может, айпад — он же такой всемогущий))))

            • Максим Никитин

              Вадим, с учетом Вашего ответ на другой вопрос ниже, я делаю вывод о том, что «рабочий компьютер» и «винда» — конфигурационные единицы. Получается, что в SLA прописывается конфигурация? Насколько я понимаю, там только услуги и парамтры услуг (типа, времени реакции, времени исправления и т.п.).

              • Вадим

                все может быть и так и не так

                рабочий компьютер сам по себе может быть услугой.

                винда...?.. теоретически тоже, но обычно в составе компьютера.

                Сдается мне, Вы что-то с чем-то постоянно путаете.

                Еще раз: КЕ — некоторые (порой условные) учетные (!) элементы.

                а SLA прописываются параметры услуги, а не конфигурационных единиц. возвращаясь к услуге печати, например, печать 1000 листов в день. при этом принтер, драйвер принтера, картридж могут быть отдельными КЕ, а могут быть одной — в зависимости от того, что вы хотите учитывать. Если вдруг Вам интересен вопрос как часто нужно менять (и заказывать!) картридж — его можно сделать отдельной КЕ и по базе обращений, вследствие которых производилась замена картриджа, Вы сможете спланировать расход, резерв и закупки конкретных картриджей. На услугу это, безусловно, влияет, но маловероятно, что в определение услуги войдет «замена 30 картриджей в год», а войдет скорее «замена картриджа выполняется не более, чем за час»

                почитайте все-таки ITIL, часть вопросов отпадет

  • Волков Николай

    Я вижу так, что каталог пишется для пользователя. И у пользователя не работает, как правило, «Видеоконференция», но «не предоставление доступа к серверу видеоконференций». В дальнейшем, да, может потребоваться деление и в услуге «Видеоконференция» на: камера, микрофон, канал связи, счёт в Sk*pe. Но начать стоит именно с такого уровня.

    • Максим Никитин

      "у пользователя не работает, как правило, «Видеоконференция», но «не предоставление доступа к серверу видеоконференций». "

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

      «деление и в услуге «Видеоконференция» на: камера, микрофон...». Я в концепции давал определение всем терминам. Скажите, то, что получается в результате деления — что за сущности? Другие услуги? Но бизнесу явно не нужна услуга «работающий микрофон» при неработающем сервере 🙂

      • Вадим

        Если услугу ВКС вы не делите на сущности (сущности — это, кстати, КЕ), то почему принтеры делите?

        • Максим Никитин

          Вадим, я как раз не делю — в комментарии выше это попытка переложить комментарий Александра на конкретный пример. Вы не ответили на мой вопрос: «То, что получается в результате деления — что за сущности?».

          • Вадим

            ответил, читайте внимательнее )))) «сущности — это КЕ»

            КЕ — это конфигурационные единицы, иногда используют термин «объекты обслуживания»

            • Максим Никитин

              Ага, получается, услуга оказывается для конкретной конфигурации, состоящей из КЕ, правильно? И если пользователя другая конфигурация, то услуга не может быть оказана?

              • Вадим

                чуть-чуть не так.

                услуга действительно предоставляется с использованием определенной конфигурации и состава КЕ. подвох в том, что это «взгляд изнутри». потребитель обычно не видит «внутренности» услуги (не всегда и не все: положим, принтер видит, и если откроет, то и картридж увидит, если захочет — драйвер увидит).

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

                • Максим Никитин

                  «услуга — это розетка определенной конфигурации, пользователь — вилка. если вилка (айпад) не подойдет в розетку (услуга печати), то пользователь ничего не получит»

                  А Вы не считаете, что метод «проб и ошибок» достаточно дорогой? В Вашем случае, пока пользователь не включит свой прибор, рассчитанный на 120В в розетку на 220В, он не сможет узнать, что в розетке именно 220В 🙂 Мне кажется, что определенный уровень «внутренностей» должны быть видны пользователю, но не на уровне SLA (он более юридический), а на уровне описания услуги. Значит, мы должны иметь сущность, которая связывает КЕ и Услугу. Такой сущностью я называю Продукт. Не логично?

                  • Вадим

                    вы всего лишь очень буквально пытаетесь меня понять (если пытаетесь, конечно)

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

                    — как пользователь видит «свою розетку», т.е. услугу

                    — какой результат от нее и в каком виде он получает

                    — как он может ее использовать

                    — что ему делать, если что-то не так.

                    сущность, которая связывает КЕ и SLA, называется OLA. ведь по сути конечная услуга из операционных сервисов состоит.

                    а пользователь КЕ видит лишь в виде принтеров, компьютеров, телефонов и того что у них на экране написаны, максимум провод до розетки.

                    вы же как пассажир в каком-нибудь виде транспорта не лезете смотреть что за двигатель под капотом и что налито в бензобак. или когда в банк приходите — вам же неважно какие там компьютеры и сервера, главное, чтобы очередь шла быстро, нет?

                    так зачем пользователю что-то знать про КЕ? для уверенности что его не накалывают? и не берут деньги за то чего нет?

                    но ведь от этого рынок конкурирующих услуг спасает, а не видимые пользователю КЕ

  • Vladimir Lyaleko

    Максим, ниже ссылка на альманах форума.

    Там есть статья «Опыт построения каталога услуг».

    Многие идеи в статье пересекаются с вашими, плюс раскрываются некоторые моменты вроде инфраструктурных услуг. Рекомендую.

    itsmforum.ru/reference/al...011_prosmotr.pdf

    • Максим Никитин

      Владимир, спасибо за ссылку. По сути, «Сервисы», которые описаны в статье Александра Огнивцева, есть прямой аналог «Продукту» в моей методике. «Инфраструктурная услуга» = «задание». «Профиль» — связь между услугой и задачей. У меня частично эту функцию выполняет «регламент функционирования». Итого, нужно делать еще один уровень с задачами.

  • Grigory Kornilov

    Более всего мея смущает родукт : Парк Продуктов Комании.

    Справочник продуктов напоминает 'наш' каталог услуг.

    Каталог услуг напоминает 'наш' список стандартных запросов услуг.

    Интересен SLA на «Создание нового Продукта».

    • Максим Никитин

      «Парк продуктов компании» введен для того, чтобы было к чему применять услугу «Создание нового продукта». Мне понравилось разделение на «сервис» и «услуга» из статьи Александра Огнивцева, в этих терминах «Парк продуктов компании» преобразуется в «Каталог сервисов».

      SLA на создание нового продукта будет включать время, на принятие решения «в рамках услуги»\"в рамках нового проекта". Критерием будут являться трудозатраты на создание. Если укладываемся в определенный минимум (тоже будет указан в SLA), то делаем, если нет — то открываем новый проект и должны будем соблюдать сроки, указанные в проекте.

      • Grigory Kornilov

        Более точно, что входит в SLA на :

        Дата, когда скажут «Предоставить в рамках существующей услуги»\"В рамках проекта" и все? Или будет дан ответ о scope\budget\timeline реализации?

        • Максим Никитин

          Если в рамках «Услуги», то параметры уже оговорены в SLA (изменения по Услуге не могут занимать более Х трудозатрат и быть дольше Y дней). А проект под собой понимает и план, и концепцию, и бюджет.

          • Grigory Kornilov

            ok, если не секрет отпишите SLA на «Создание нового Продукта» в том виде, как сейчас у вас он записан\предоставляется\согласован.

  • Станислав Уштей

    Попробуйте развалить услуги, исходя из принципа PDCA для ИТ.

    Возьмите за основу процессы из COBIT

    Тогда вы сможете очень аккуратно нарезать свои Услуги

    Очень поддерживаю ваше желание разнести Продукт и Услуга – действительно все встает на свои места: что потребляют конечные пользователи и (Продукт) и чем занимается ИТ-подразделение (Услуга/Деятельность).

    Реально, даже не столь важно, как в конце концов будут выглядеть термины — лишь бы они несли смысл Продукт/услуга

    • Максим Никитин

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

      • Станислав Уштей

        С моей точки зрения — это очень важно иметь два разведенных каталога:

        Продуктовый для клиента

        и

        Услуг для формализации работ ИТ-подразделения

        Первый вам даст сущности на которые может подписываться конечный пользователь и будут заключаться SLA. При этом вам будет не нужна навороченная CMDB и вы разделите два блока интересов: пользовательский (которому все время что-то нужно) и бизнесовый (который заинтересован в протекании своих бизнес-процессов)

        Второй вам даст основу для выстраивания ИТ-процессов; расчетов численности и компетенций персонала. Также вы получите предмет торга – в плоскости: «сколько людских ресурсов необходимо для поддержания продукта и его пользователей»

  • Станислав Уштей

    Попробуйте развалить услуги, исходя из принципа PDCA для ИТ.

    Возьмите за основу процессы из COBIT

    Тогда вы сможете очень аккуратно нарезать свои Услуги

    Очень поддерживаю ваше желание разнести Продукт и Услуга – действительно все встает на свои места: что потребляют конечные пользователи и (Продукт) и чем занимается ИТ-подразделение (Услуга/Деятельность).

    Реально, даже не столь важно, как в конце концов будут выглядеть термины — лишь бы они несли смысл Продукт/услуга

  • Олег Скрынник

    Не сочтите за рекламу, но скоро Роман Журавлёв будет проводить бесплатный вебинар про формирование каталога ИТ-услуг.

    Места пока есть.

    Регистрация: my.comdi.com/event/51847/

    Ближайшие вебинары: www.cleverics.ru/subject- ...ebinars#schedule

    • Максим Никитин

      Да, я уже зарегистрировался, спасибо!

    • Вадим

      обязательно посоветую коллегам

      опубликуете потом?

      • Олег Скрынник

        Конечно, как и все предыдущие.

        • Grigory Kornilov

          Мой коллега 'посетил' ваш вебинар по PM и есть 2 'пожелания' к проведению:

          1. Уточнять уровень посетителей, на который будет расчитано мероприятие (Знакомство с ITSM Foundation ...)

          2. Четче модерировать тематику (по его описанию — 'много времени ушло на обсуждение вопросов инцидент менежмента')

          • Олег Скрынник

            Григорий, спасибо за обратную связь.

            По поводу уровня мероприятий мы придумали отмечать уровень сложности прямо в расписании: www.cleverics.ru/subject- ...ebinars#schedule

            1 звезда — для начинающих

            2 звезды — для «продвинутых»

            3 звезды — серьёзные вопросы

            Классификация условна, конечно же.

  • Pavel Solopov

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

    Вам тут коллеги сякого уже наговорили. Даже не знаю, с кем бы я больше поспорил с вами или с ними. 🙂

    Поэтому, я, как буквоед обращу внимание на некоторые нюансы в ваших определениях.

    Вы пишите Услуга не должна зависеть от Продукта

    C другой стороны в качестве услуг, у вас в схеме заявлены: «Обновление версии программного продукта» или «Устранение ошибок в программном продукте».

    Но согласитесь, что обновление Exchange или Lotus Domino могут принципиально отличаться по трудоёмкости и частоте проведения. А следоательно вы не сможете предложить одно и тоже значение параметра услуги для этих разных Продуктов. Можно ли в этом случае говорить о незаисимости?

    Вы пишите: информационная система (программа) C njxrbзрения системотехники, информационная система, всё же может быть шире чем программа. Программа может быть весьма примитивной, в то время как система может состоять из набора взаимосвязанных программ. Я бы не стал здесь ставить знака раенства.

    Программно-аппаратный комплекс, однозначно воспринимаемый

    пользователями как обособленная сущность

    очень скользкое определение (а я, как буквоед, люблю конкретику). Один пользоатель может воспринимать «как обособленную сущность» отдельную программу, а другой всю ИТ-инфраструктуру месте с внешними провайдерами вместе взятую.

    В частности по предложенным Вами услугам:

    Предоставление отчетов об

    исполнении SLA Это примерно тоже самое, как если вам в ресторане в счёт включат распечатку счёта.

    Классификация возникшей

    проблемы Это разве приводит к получению значимого для пользователя результата, как вы говорите в определении? Не ДИТу ли это нужно? Хотя, конечно в некоторых условиях эта услуга может существовать. Когда пользователь о своей проблеме заяляет сам, например в поддержку вендора, но сформулировать суть своей проблемы не может. Но это, как я понимаю, не ваш случай.

    Можно писать ещё, но боюсь и так всех утомил.

    • Максим Никитин

      Павел, спасибо за развернутый комментарий. Отвечу по частям

      «Максим, вы молодец! Вы заслуживаете премии, за стойкость в отстаивании своих взглядов. Вам тут коллеги сякого уже наговорили. Даже не знаю, с кем бы я больше поспорил с вами или с ними.»

      Я знаю единственный способ проверить теорию — попробовать ее отстоять. Я очень признателен всем, кто комментировал, ибо вынес несколько полезных выводов. Основной — определения, понятия и связи отторжения не вызывают, но нужно делить каталог на несколько частей: сам каталог, SLA отдельно, OLA отдельно.

      «Но согласитесь, что обновление Exchange или Lotus Domino могут принципиально отличаться по трудоёмкости и частоте проведения. А следоательно вы не сможете предложить одно и тоже значение параметра услуги для этих разных Продуктов. Можно ли в этом случае говорить о незаисимости?»

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

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

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

      «Предоставление отчетов об исполнении SLA Это примерно тоже самое, как если вам в ресторане в счёт включат распечатку счёта.»

      Не согласен. Я в ресторане не могу отказаться от счета, а бизнес вполне может использовать эту услугу раз в квартал, а не раз в месяц, и тем самым экономить. К тому же, у этой услуги есть явный заказчик, который не равен «все пользователи услуг», а счет в ресторане печатается всем пользователям.

      «Классификация возникшей проблемы Это разве приводит к получению значимого для пользователя результата, как вы говорите в определении?»

      Да, приводит. Эта услуга востребована, когда пользователь не может четко определить инцидент ли его проблема или заявка на изменение. Так же, она нужна для решения проблемы «у меня не работает, но что не работает я не знаю». С точки зрения ИТ — у этой услуги есть отдельный SLA, который позволит обрабатывать в первую очередь инциденты, которые сам пользователь смог классифицировать, как инциденты, а потом уже разбираться с «ой, не работает».

      «Можно писать ещё, но боюсь и так всех утомил»

      Обязательно пишите еще!

      • Pavel Solopov

        «Под «независисмостью» я понимаю такую формулировку названия услуги, которую можно применить к нескольким продуктам.»

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

        И вот это услуга «Организация видеоконференции», не бъётся с этим принципом.

        Я в ресторане не могу отказаться от счета

        Не путайте оплату счёта и счёт, от счёта вы можете отказаться (как от бумажки с цифрами), а от оплаты нет (при некоторых условиях).

        Представьте себе ситуацию, официант приходит и говорит: с вас N-рублей...

        Ого, -думаете Вы, чего это мы такого съели, вроде бы расчитывали на N/2.

        Хотите знать за что платите? ухмыляется официант, тогда ещё будьте добры оплатите услугу «Предоставление счёта».

        Отчётность по SLA должна быть частью неких «договорных» отношений между ИТ и плательщиком (кто там вам платит, не знаю, руководители департаментов, профит центров, директор...), но никак не доп услугой.

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

        Так же, она нужна для решения проблемы «у меня не работает, но что не работает я не знаю»

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

        Вот эти услуги:

        «Прием обращений пользователя»

        «Классификация возникшей проблемы»

        «Предоставление отчетов об исполнении SLA»

        Т.е. может получиться так, что ничего не работает, а заказчик должен вам как земля колхозу:

        Мы же ваши заявки принемали? Принемали! Проблеммы классифицировали? Классифицировали! Отчёты вам предоставляли? предоставляли!

        Оплачивайте!

        Идея сервисного подхода: Заказчик платит за результат!

        • Максим Никитин

          «Идея сервисного подхода: Заказчик платит за результат!»

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

  • Alexander Peshkov

    «За время пути ветка могла подрасти» ©.

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

    Предоставление отчетности — это даже процесс. Поскольку он трудоемкий (я бы даже сказал, страшно-чудовищно трудоемкий, если не автоматизирован нормально), трудозатраты на него так же нужно включать в калькуляцию. Но не выносите как отдельную услугу — это не услуга, это именно процесс!

    Кстати, в любом случае, Вам нужно определиться, каким образом вы будете относить затраты на отчетность и Service Desk — аллокацией, РСМ, РТК? Последний семинар ITSMf на эту тему был достаточно емкий ,)

    • Максим Никитин

      «Прием обращений, и их классификация — это функции службы Service Desk» — да, я много думал про это. Я хочу мотивировать пользователей самостоятельно классифицировать свою проблему — в моем конкретном случае пользователи в большинстве случаев могут самостоятельно это сделать. Мотивация состоит в том, что если пользователь сам определяет, что у него не работает и правильно заполняет заявку на устранение инцедента, то по SLA мы ее выполним за 4 часа, а если поленился собрать нуждные данные, то у нас есть 24 часа, что данные собрать («классифицировать обращение») и 4 часа, чтобы устранить.

      «Предоставление отчетности — это даже процесс» — согласен, это уберу.

      "Кстати, в любом случае, Вам нужно определиться, каким образом вы будете относить затраты на отчетность и Service Desk " — отдельная тема, я буду ее «раскладывать по полочкам» после того, как сделаю каталог. Пока у меня в определениях есть требования, что в услугу должна входить деятельность, «которую можно нормировать и получить бюджет услуги»

      • Pavel Solopov

        «если пользователь сам определяет, что у него не работает и правильно заполняет заявку»

        Я не совсем представляю вашу ситуацию, но выглядит это как-то странно. Если специалистам требуется 24 часа на диагностику (кстати не путайте диагностику с классификацией, это вовсе не одно и то же), то сколько же времени должно потребоваться на диагностику пользователю?

        А в итоге потом вы же ещё и на пользователя свалите все неудачи: Вы не верно диагностировали!

        «которую можно нормировать»

        Можно нормировать любую деятельность (кто же вам запретит). Но это не значит что её возможно нормировать в имеющихся условиях.

        • Alexander Peshkov

          Подписаться под каждым словом!

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

          • Максим Никитин

            «придется использовать как Ресурсно-сервисную модель, так и Рассчетно-технологические карты» — спасибо, я почитаю про эти сущности.

        • Максим Никитин

          Давайте вместе читать внимательней исходный документ. Услуга, про которую мы говорим, называется «Классификация возникшей проблемы». Изначально она была направлена на «Возможность использовать ServiceDesk, для помощи пользователю в классификации проблемы (инцидент, заявка на обслуживание, заявка на изменение).». Я некорректно выразился в предыдущем ответе — под «сам определяет, что у него не работает» я имел ввиду не поиск корневой проблемы инцидента, а определение инцидент это или заявка на изменение.

          Просто работа над этой темой внутри компании привела к пониманию, что с помощью данной услуги можно не только помогать в определении классификации, но и «бороться» с теми, кто не хочет думать и правильно заполнять заявки. 24 часа нужно не на определение проблемы, а, например, для того, чтобы связаться с пользователем, который неверно заполнил заявку на устранение инцидента в 17:55 и ушел домой — с учетом нормированного рабочего дня в 4 часа мы не уложимся никак.

          • Вадим

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

            еще можно на курсы сходить, если еще не были...

            • Максим Никитин

              Вадим, что книжки, что курсы дают общее представление о предмете. Я задаю конкретные вопросы и хочу видеть конкретные ответы. Как Вы предлагаете решать описанную выше проблему, когда пользователь в 17:55 инициировал заявку и свалил домой, а нам для решения инцидента в 4 часа нужны данные от него?

              • Вадим

                два варианта:

                1. Вы можете заказать соответствующую работу (проект) у проверенного консультанта и в ее рамках он(и) ответит на все (или почти на все) Ваши вопросы. но это за деньги.

                2. Если обращение пользователя зарегистрировано за 5 минут до окончания рабочего дня, то этот случай должен быть рассмотрен в процедуре обработки и в SLA.

                Это Вы еще не сталкивались с планом обеспечения непрерывности бизнеса.

                И потом... почему считается, что ИТишники могут работать по тому же графику, что и пользователи? Ведь первые должны обеспечивать бесперебойную работу вторых, а не наоборот. Если для этого требуется работать ночью или по выходным — договаривайтесь а) с пользователями, б) с руководством о надлежащих условиях работы и оплаты за нее.

                • Pavel Solopov

                  Как консультанта проверять будем? На поллиграфе?

                • Максим Никитин

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

                  «Если обращение пользователя зарегистрировано за 5 минут до окончания рабочего дня, то этот случай должен быть рассмотрен в процедуре обработки и в SLA» — у меня это решение вызывает негативные ощущения, так как в нем есть изрядная доля субъективизма. Ситуации «я вам звонил 5 раз — да нет, я был на месте» наверняка будут, а решать их сложно. Решение Павла с рабочими часами, на мой взгляд, лучше, но тоже не универсально.

                  «почему считается, что ИТишники могут работать по тому же графику, что и пользователи?» — Влад, не смешивайте, пожалуйста, теплое с мягким. Мы сейчас осуждаем только ситуацию, когда для решения инцидента нужны данные от пользователя. И здесь время работы самой службы не имеет значения.

                  • Вадим

                    Вадим, с Вашего позволения )))

                    По второму вопросу.

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

                    Я думаю, что по обращению, типа, «у меня тут все не работает» далеко не всегда может быть выполнена конкретная работа по устранению причины.

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

                    Так что вопрос целесообразности в общем случае (!) проводить огромный объем работ по «первому чиху» вполне себе открыт. впрочем, ситуации бывают разные... бывают случаи и когда надо...

              • Pavel Solopov

                Вообще есть общепринятое решение считать SLA в рабочих часах.

                Если заявка пришла в 17.55, то крайний срок для неё будет не 21.55, а 12.55 следующего дня. А если заявка пришла в пятницу, то 12.55 понедельника и т.д.

                Конечно работать над тем, чтобы пользователь предоставлял более подробную информацию надо, ни кто не спорит. Но выносить это в отдельный сервис не правильно ( с точки зрения сервисной культуры). Да и потом сложно будет вам обсчитывать, кому какой сервис предоставляли, какой не предоставляли, где SLA выполнили, а где провалили...

                • Максим Никитин

                  "Вообще есть общепринятое решение считать SLA в рабочих часах. " — согласен, это выход, но только в том случае, когда все пользователи работают в одном часовом поясе. У нас пользователи в нескольких часовых поясах, поэтому нам актуальнее астрономические часы.

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

                  • Вадим

                    так у каждого пользователя (или группы пользователей) свои фиксированные рабочие часы. зачем их смешивать в одну кучу?

                    Если пользователь из Владивостока подал заявку за пять минут до окончания своего рабочего времени (а в Вашем поясе это будет другое время), Вы хотите отдать ему решение через (допустим) 4 астрономических часа? Он же дома будет спать в этот момент...

                  • Pavel Solopov

                    «когда все пользователи работают в одном часовом поясе»

                    Ну тут вы уж определитесь, вы для кого SLA пишете для пользователей или для себя, чтобы прикрыться от пользователей.

                    Вадим ниже написал уже про это. В идеале, SLA должен быть в рабочих часах пользователей.

                    Ну а ситуации конфликтов типа «звонили, не дозвонились», конечно всегда будут. Чтобы объективно их избегать, нужно применять различные средства автоматизации, логи звонков и т.д.

                    Ну либо принять как данность, выделить определённую квоту и т.д.

            • Pavel Solopov

              Если у вас есть хоть какой-то порядок в голове, то почитайте глоссарий, его у вас не станет...

              В глоссарии извините такое определение услуги, что по нему ничего в реальной жизни не построишь. У коллеги тоже не самое лучшее определение, но хоть как-то более менее жизненно.

              • Вадим

                специально поискал, но определение услуги в трактовке коллеги не нашел или не понял, что это именно оно.

                с глоссарием на самом деле все не так уж плохо.

                помнится ранее была тема что-то вроде «мне нравится определение услуги в itil» (www.realitsm.ru/2011/09/m...e-uslugi-v-itil/) — Вы там много копий сломали.

                по-моему, дело не глоссарии...

                • Pavel Solopov

                  А Вы где искали? В Прилагающемся документе? И не нашли?! Не верю!

                  А в чём дело если не в глоссарии?

                  • Вадим

                    поискал по веткам в данном топике)))

                    вы вообще какого коллегу имели в виду?

                    • Pavel Solopov

                      Максима Никитина, он я так понимаю автор вопроса и документа, который к вопросу прилагается. Загляните в описание топика, там документ приложен.

                      А то вы в очередь встали, а за чем очередь, за панталонами или за колбасой не выяснили. 🙂

                    • Вадим

                      ну про очередь это лишнее было))) я когда-то уже заглядывал в документ

                      а встрял в нее))) я как раз потому, что мне данная трактовка представляется не очень понятной и недостаточно удобной (впрочем это дело автора: если ему удобно и понятно — ну и пусть).

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

                      впрочем, мы тут не самого автора обсуждаем (и не меня)))) а предлагаемую им трактовку

                • Максим Никитин

                  Вадим, определение услуги в моем документе дано на первой странице, внизу:

                  Бизнес-деятельность ДИТ, приводящая к получению значимого для Потребителя услуги результата. Должна удовлетворять следующим требованиям:

                  1. Услуга не должна зависеть от Продукта или текущего окружения

                  2. Процесс предоставления Услуги должно быть можно разделить на действия, которые можно нормировать и в итоге получить бюджет услуги

                  Готов подискутировать предметно.

                  • Вадим

                    пардон, что немного стормозил и не сразу заглянул в документ.

                    это определение не шибко-то отличается от ITILовского

                    Основное IMHO есть и там и там «услуга — деятельность в интересах потребителя»

                    Требования... Ну раз Вы вводите термин «Продукт», Вы можете определять соотношение услуги и продукта.

                    По поводу второго требования, мне показалось, что ранее обсуждение шло в ракурсе «поддержки услуги», а не «предоставления», но это может объясняться характерными для Вас собственными трактовками известных терминов. Если Вам так проще и понятнее, и, главное, Вы в состоянии объяснить своим пользователям и ИТ-ишникам, что от них требуется — пожалуйста. На мой взгляд, шероховатости в этой формулировке есть, можно с ними работать.

                    Предмет дискуссии непонятен.

        • Максим Никитин

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

          • Вадим

            и про нормирование тоже почитайте )))

            Nothing personal

            • Максим Никитин

              Вадим, у Вас есть конкретные возражения? Вы готовы высказать собственный взгляд на нормирование и отстоять его в дискуссии? Или у нас дуэль на фолиантах — у кого более тяжелый и пыльный, тот и победил?

              • Вадим

                На эту тему лучше подискутировать с Павлом (я с точки зрения использования нормирования с ним согласен)

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

                • Pavel Solopov

                  А какая у меня точка зрения на нормирование? Нормирование нужно, без него очень сложно выполнять точное планирование серьёзного потока работ.

                  Вот только разработать нормы не просто, а готовых, к сожалению не так много.

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

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

                  Не достаточно один раз придумать нормы на десяток другой работ.

                  • Вадим

                    вот именно с этим я и согласен :о))))) кроме фуфла))

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

                    сейчас этого практически нет. известные мне нормативы (от 1998 года) не в полной мере отражают действительность, а принявшего их министерства уже не существует.

                    ранее (в СССР) это все выполнялось вообще на государственном уровне (Госстандартом по-моему), и любая отдельно взятая организация не могла повлиять на эти нормы, а если влияла, то директору доставалось не по-детски. хотя были и положительные примеры...

                    • Pavel Solopov

                      Есть документы и актуальней. Хотя найти их не так просто. Чтобы не искать, я его выложил у себя: pasol-711.livejournal.com/11539.html.

                    • Pavel Solopov

                      Похоже робот забанил моё сообщение.

                      Вобщем я выложил нормативы от 2007 года, кому интересно

                      pasol-711.livejournal.com/11539.html

                    • Вадим

                      СПС

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.