Продолжаем смотреть, как решаются ИТСМ-проблемы, если принять, что ИТ-сервис это стандартные действия, которые совершают ИТ-система и ИТ-сотрудники в ответ на запросы потребителя, и почти всегда ИТ-система настолько сложная, что проще не перечислять и не детализировать эти действия, а назвать их все вместе одним словом — названием системы, например.
Проблема 5
В Айтилях третьей версии ИТ-сервис — это «сервис, оказываемый поставщиком ИТ-сервисов». А поставщик ИТ-сервисов — это «поставщик сервисов, который поставляет ИТ-сервисы». Круг замкнулся. При этом логично было бы, если бы ИТ-сервисы были определены, как «сервисы, которые про ИТ». И объяснение, что такое сервис вообще, нерабочее. Если считаете, что рабочее, объясните, почему его не взяли в 4-ю версию.
Решение
Отношения ИТ-сервисов и вообще сервисов могут быть только такими: ИТ-сервисы это подмножество всех сервисов. От «не ИТ» сервисов ИТ-сервисы отличаются тем, что они имеют отношение к ИТ.
Добавлю, что «имеют отношение к ИТ» — понятие очень широкое и допускающее дискуссии. Например, перевод денег через интернет-банк очень похож на отправку письма по электронной почте, но почту принято считать ИТ-услугой, а перевод денег, хотя там ИТ-систем, может быть, задействовано и побольше, чем в иной почте, услуга скорее финансовая. Считаю, что тут ценность не в определении границы между ИТ-сервисами и не ИТ, а в том, что признание сервиса ИТ-сервисом разрешает применять к нему Айтил, Кобит и другие стандарты и лучшие практики.
Проблема 6
Ведущий, самый лучший поставщик ИТСМ-обучения, в курсе «Основы ITIL» на слайде «Что такое ИТ-сервис» в качестве примера приводит «горячее водоснабжение». Люди 10 лет работают, а когда надо пример ИТ-сервиса привести, могут только горячую воду вспомнить. И это не оговорка лектора в момент секундного замешательства, это на слайде написано, т.е. компания готовилась к проведению курсов, обдумывала, и вот надумала.
Решение
Ну, выбрали плохой пример, бывает.
Проблема 7
Говорят, почти состоялось выступление по теме «Я 15 лет делаю ИТСМ-проекты, и вот начинаю понимать, что такое ИТ-сервис».
Решение
Тут меня поправляют, не «что такое ИТ-сервис», а «что такое ИТСМ», и даже презентацию помогли найти. Разберу отдельно.
Проблема 8
«Бизнес компании – розничные продажи, включает сети магазинов разной площади и корпоративный центр. ИТ-инфраструктура распределенная, есть сервера в магазинах и в корпоративном центре. Часть ИТ-сервисов работают автономно при сбое в работе каналов или общекорпоративных сервисов. Информационные сервисы предоставляются ИТ-службой по заключенным с бизнес-единицами SLA. Заказчик использует системы мониторинга ИТ-ресурсов. ИТ-служба приступает к внедрению системы Service Desk для регистрации инцидентов. Нет понимания, к каким SLA и конфигурационным единицам привязывать регистрируемые инциденты при массовых сбоях, влияющих на несколько сервисов.»
Решение
Пояснение: в магазине есть сервер, на котором крутятся 2 системы, и без сервера они не работают. На работу систем есть СЛА. Если сломался сервис, какие инциденты регистрировать: на сервер, на системы, на пользователя?
Ответ: инцидент это когда сервис не оказан. А сервис это или действия в ответ на запрос пользователя или объект, которым дали попользоваться.
Конечный пользователь получает сервис в ответ на свой запрос, и для него инцидент это «нажал „Напечатать”, а оно не напечаталось» или «хотел сделать складской ордер, а она зависла». Такие «инциденты конечного пользователя» нужно привязывать к СЛА на работу бизнес-системы, а в качестве конфигурационной единицы выбирать одну из функций системы.
Для тех же, кому сервис предоставляется в виде работающего сервера, инциденты надо определять с помощью системы мониторинга, связывать их с СЛА на работу сервера и в качестве КЕ выбирать сервер.
Делать выводы, что раз не работал сервер, то работающие на нём системы работать тоже не могли, и поэтому с ними были инциденты, не нужно. Если сервер не работал, но пользователи этого не заметили, потому что им не пользовались в этот момент, то никаких инцидентов не было, и нарушения СЛА тоже не было. Тем, кто изучает ИТСМ на горячей воде: если её подача прекращалась в 3 часа ночи, но не было желающих помыться, то инцидентов не было.
Проблема 9
ИТ-руководитель банка говорит: «У нас нет сервисов, у нас системы». Банк работает, системы работают, деньги движутся, всё в порядке. Если всё в порядке, и сервисов нет, зачем тогда всё? Всё: Айтили, ИСО 20 000, книги, курсы, семинары, международный форум?
Решение
ИТ-руководитель прав в том, что у него есть системы. Он их видит и может потрогать. А признавать, что у него есть сервисы, он не хочет, потому что это что-то сложное («способ предоставления ценности заказчику без владения связанными затратами…») и пользы в этом он не видит. А польза в том, что если признать наличие сервисов, то можно использовать придуманные для сервисов модели, стандарты, техники и т.д., например, Айтиль.
Проблема 10
Поиск, естественно, за деньги, разницы между услугой и сервисом. Некоторые находят. Уверен, они нашли бы разницу между отелем и гостиницей.
Решение
Нет между ними разницы.
Проблема 11
Предоставление услуги «Ремонт принтера» вместо запрошенной и оплаченной услуги «Принтер», то есть подмена и обман. Отвал головы при попытке сформулировать, что такое доступность услуги «Ремонт принтера» из-за этой подмены.
Решение
Услуга «Принтер» (услуга печати) это когда в ответ на запрос «контрол-П, энтер» принтер выдаёт страницу текста. Инцидент при её предоставлении это когда страница не напечаталась. Запрос на изменение: вот вы сейчас только ч/б печатаете, а я цветное хочу. Доступность удобно измерить как отношение количества напечатанных страниц к количеству отправленных на печать.
Услуга «ремонт принтера» это когда в ответ на запрос «вот мой принтер, он сломался» принтер чинят. Инцидент для этой услуги: ремонтник не может починить принтер, например у него нет нужных запчастей для ремонта. Запрос на изменение: вы принимаете принтеры в ремонт с 10 до 18, а я хочу, чтобы было круглосуточно. Доступность: отношение количества успешно починенных принтеров к количеству попыток сдать их в ремонт, т.е. если я принёс принтер, а мастерская закрыта, то услуга недоступна.
С небольшим годовым опозданием, которое нам ещё в 1969 году объяснил Фредерик Брукс, прокомментирую статью Елены Швец. Статья была под номером 4 в списке проблем в первой заметке серии.
"Кто об чем, а она все об нем". О сервисном подходе, в общем :-).
Есть некоторая путаница в вопросе того что такое "Каталог ИТ-услуг". Состоит она из 2 видов непонимания. Я сегодня напишу про первый вид, т.к. он совсем простой, но распространенный. А завтра про второй, там позаковырестей нюанс.
Итак.
Начнем с очевидного: в английском языке существует только слово "Service", которое переводится на русский и как "Сервис" и как "Услуга". Так что если вам кто-то говорит, что услуга и сервис это разные вещи - скажите 3 раза "ха" ему поперек плеча.
Дальше нужно осознать, что типовой запрос в рамках услуги, и сама услуга - это совершенно разные вещи.
Вот здесь начинается то, что можно улучшить. Елена считает, что в услуге есть выполнение запросов и что-то ещё. Что это? А ничего там нет, услуга состоит только из выполнения запросов. Даже если услуга это объект, которым дали попользоваться, этот объект нужен только потому что он выполняет действия в ответ на запросы. То есть всё сводится к запросам.
Вот пример: вы покупаете карту в фитнес-клуб. Эта карта дает вам возможность зайти в клуб, свободно пользоваться тренажерами, басиком и хамамом.
Это что-то вроде услуги "Автоматизация логистики". Можно заходить в систему в любое время, кроме периодов, когда она закрыта, ведь не каждый фитнес-клуб круглосуточный. Можно плескаться от души в прилагающейся системе отчетности, и парится в модуле планирования поставок хоть целый день!
Это услуга. Платить за нее надо за период времени. Будете вы ей пользоваться или нет - дело ваше, вы платите за возможность. Услуга - это возможность чем-то пользоваться.
Услуга это не возможность чем-то пользоваться. Услуга это когда вы чем-то воспользовались. И то, что карта даёт неограниченный доступ в бассейн и хамам, означает только то, что владелец клуба не придумал способа, как оценить ваше пребывание в бассейне и хамаме. Мог бы по времени. Мог бы дистанции, которую вы в бассейне проплыли. Мог бы по объёму тела. Мог бы, но не стал. Возможно, у него нет технической возможности. Но скорее, нет желания: я был в хамаме, где всё записывают, а в конце подсчитывают. Впрочем, ещё вероятнее, что дело не в желании, а в бизнес модели: предположу, что прибыль делается на том, что покупатель годовой карты ходит в клуб пару месяцев, а потом ему некогда.
А теперь давайте посмотрим что есть типовой запрос в рамках этой услуги.
Купив карту, вы имеете право без доп платы посещать неограниченное количество групповых занятий. Йога, аэробика и тэдэ. Но, только по расписанию. Если вас не устраивает расписание - вэлкам, заказываете индивидуалочку, но уже за деньги. Или вообще есть какие-то вещи, которые можно заказать только за деньги, типа сеанса массажа. Т.е. в рамках услуги "Автоматизация логистики", вы имеете бесплатный доступ к отчетам стат анализа, формируемым раз неделю по пятницам в 12-00. На этой неделе приспичило получить аналитику в среду? Фигня вопрос - 100 баксов и сделаем точечно в эту среду доп анализ.
Консультация? Бесплатно с 9-00 до 18-00 пн-пт. Надо в воскресенье? Тоже можем, но за 5 баксов в минуту. И закажите заранее.
Это опять решение владельца о том, как брать деньги. Нет ничего, что запрещает брать деньги за групповые занятия. А можно продавать такие карты, где будет неограниченное число индивидуальных занятий с тренером и массажей. Это способ взятия денег, это не имеет отношения к «устройству» услуги. Она всё равно состит за выполнения запросов, и массаж, и занятие с тренером, это точно такие же запросы, как и «хамам».
И все эти запросы — типовые, потому что нетиповых запросов в услуге быть не может. И даже дополнительная аналитика за 100 долларов в среду это типовой запрос, потому что у поставщика есть понимание, как его выполнить, ресурсы, чтобы его выполнить (то есть обученный сотрдуник), и готовность его выполнить. Нетиповой запрос это «Дайте мне хамам!» в клубе, где хамама нет.
Короче, если вы как поставщик, не хотите иметь проблем - на каждую услугу сделайте каталог типовых запросов с ограничениями и баблом. Прям сразу сделаете, прямо когда формулируете услугу для бизнеса. Заказчику услуга в вакууме не понятна, а с набором запросов с баблом за каждый - уже норм.
А вот тут я согласен. На каждую услугу надо создать каталог типовых запросов. Потому что это единственный способ описать услугу. А вот с «баблом за каждый» не согласен. Можно как в клубе, брать за время. Можно брать за каждый запрос. Можно придумать какую угодно единицу измерения количества оказанной услуги, и брать деньги по этой мере. Например, те же отчёты стат анализа, которые сейчас бесплатны, могут стоить рубль за строку, а «париться в модуле планирования поставок» будет стоить рубль в минуту, или по 100 рублей за каждый рассчитанный и сохранённый (или что там в этом модуле делают) план.
Итого - каталог услуг и Каталог типовых запросов - разные вещи. На портале для пользователей вы показываете именно каталог типовых запросов.
Ну как бы да, формально. Но одно состоит из другого, как яблоко из долек. Удобно понимать, что кроме типовых запросов, в услуге ничего нет: тогда автоматически решаются вопросы, что такое инцидент, что такое запрос на изменение, что такое доступность и как её измерить и т.д.
И последнее. Вообще все запросы всегда принадлежат только одной услуге. Т.е. Запрос m:1 Услуга.
Кроме бандлов. Пример - "Новый сотрудник" = бандл из 10-15 типовых запросов на подключение к разным услугам, в зависимости от роли сотрудника. Или "Все в ружье" = бандл из 5 типовых запросов на дежурство консультантов по разным системам рядом с бухгалтером, пока он закрывает год.
Хорваты вперед!
Ps: 1Если вы понимаете, что у вас есть услуга, доступ к которой бесплатный - все запросы в рамках этой услуги должны быть платными. Как в парикмахерской. На крайняк, бесплатно только первая консультация, как у юристов или косметологов. 2. Ошибка думать, что типизация запросов - это какая-то второстепенная задача в рамках request fulfillment. Если service owner будет сидеть и ждать пока в другом процессе сформулирую за него его типовые запросы к его услуге, он не дождется. Надо дать ему возможность пинать. И обязанность контролировать.
Итого. Услуга состоит из типовых запросов, которые поставщик выполняет руками специалистов или с помощью системы. Не сказав, что это за запросы, нельзя сказать, о какой услуге идёт речь. Деньги за услугу можно брать как угодно, как за эти запросы, так и на основе других драйверов: за количество пользователей, за объём обработанных данных, за время, проведённое пользователем в системе или за время вообще.
Как понимание того, что сервис это действия поставщика услуги плюс система, которой дали попользоваться, помогает решать распространённые проблемы нашего времени. Список проблем был в первой заметке серии.
Проблема 1. Система или нет
Во второй версии ITIL в одном абзаце было написано, что айтишники часто путают сервис и ИТ-систему (то есть, что сервис это не ИТ-система), а в следующем, что сервис — это одна или несколько ИТ-систем, нужных для работы бизнес-процесса (то есть, что сервис это ИТ-система).
Решение
Сервис это действия.
Нужные пользователю действия это такие, которые помогают выполнению бизнес-процесса или даже просто необходимы для его работы.
Эти действия выполняет ИТ-система. Или несколько ИТ-систем вместе. Тут можно по-всякому говорить, потому что любую систему можно разбить на несколько систем, а несколько систем объединить в одну, поэтому одна или несколько систем — не так важно.
Поэтому сервис это «одна или несколько ИТ-систем, нужных для работы бизнес-процесса».
Путаница возникает только когда забывают, что система, которой кому-то дали попользоваться, всё ещё принадлежит владельцу, а не пользователю.
Проблема 2. Они же материальные
Компьютер это сервис? Виндоуз это сервис? Стол это сервис? Они же материальные.
Решение
Компьютер это товар, если его продали, то есть за денежную компенсацию навсегда передали право собственности. Компьютер это сервис, если его отдали в пользование.
Виндоуз это товар, если его продали, то есть за денежную компенсацию навсегда передали право собственности. Виндоуз это сервис, если его отдали в пользование.
Стол это товар, если его продали, то есть за денежную компенсацию навсегда передали право собственности. Стол это сервис, если его отдали в пользование.
Что угодно это товар, если его продали, то есть за денежную компенсацию навсегда передали право собственности. Что угодно это сервис, если его отдали в пользование.
Проблема 3. Как оценивать предоставление услуг
Наши дни, почти любая компания. Каталог сервисов есть, соглашения об уровне услуг есть, услуги оказываются, но: за услуги выдаётся поддержка, и услуга оценивается по работе поддержки. Это как оценивать работу авиакомпании по количеству найденного пропавшего багажа. Проблема в том, что если багаж не терялся, оценивать нечего, и услуги как бы и не было.
Решение
Услуга это выполнение запросов, оценивайте услугу по тому, как эти запросы выполнены.
Например, система «Галактика» умеет, помимо прочего, по запросу пользователя создавать счета, накладные и складские ордера. Или делать проводки на основании информации из какого-то документа, например, накладной. Попросил пользователь сделать проводки, система сделала — услуга оказана.
Например, система «Компьютер» умеет включаться, если нажать кнопку Power. Как вы догадываетесь, последовательность та же, что у «Галактики»: нажал, включился, оказана.
Иногда, когда покупаешь сервис, получаешь в итоге в вечное пользование некий предмет. Этот предмет может быть сильно похож на то, что продаётся в магазине, или вообще не отличаться от магазинного.
Например, я могу попросить ювелира сделать точно такое же кольцо, которое сделали на заводе и продают в магазине. Кольца неотличимые, но ювелир оказал услугу, а фабрика делает товары.
Или в автобусе сломалась коробка передач. Отдаём его в ремонт, и на выходе получаем точно такой же автобус, как с завода. Ремонт — услуга, но завод производит товары.
Видим, как на фабрике пришивают пуговицу на рубашку — смотрим на производство товара. Через полгода эта пуговица оторвалась, и мы смотрим, как в ателье её пришивают обратно к той же рубашке — но теперь мы видим оказание услуги.
Всё потому, что услуга — это выполнение стандартных запросов от потребителя. Потребитель попросил сделать кольцо, поэтому это услуга. Нет потребителя, и вы делаете кольцо в надежде его потом продать — производите товар.
Несколько дополнительных соображений для лучшего усвоения материала.
Предметы, объекты или системы можно продавать как товар или как сервис. Чтобы продать как товар, владелец берёт с покупателя деньги и навсегда отдаёт ему предмет. Чтобы продать как сервис, предмет отдают на время.
Вы можете сначала сделать нечто, а потом уже решать, продавать это как товар или как сервис. Две «Киа Элантры», одна из которых отправится в таксопарк, а вторая в автосалон, на конвейере выглядят одинаково. «Микрософт Ворд» продают в магазине как товар, а на сайте Office360 — как услугу.
Смысл сервиса в действии. Если система продаётся как сервис, это значит, что покупатель получит от неё какие-то действия, то есть пользу, но не станет её владельцем. Например, если я купил дрель как сервис, я надеюсь ей посверлить, а потом я верну её обратно. Можно при продаже сервиса сфокусироваться на действии, а не на системе. В случае с дрелью это будет «купил услугу сверления дырок», и для такого варианта я бы подозревал, что вместе с дрелью мне дадут того, кто будет сверлить. Полагаю, разница между сервисами, где систему дают без оператора, и где с оператором, не только понятна, но уже и в языке закрепилась. Мы не называем такси «каршерингом с водителем».
Сервис это исполнение стандартных запросов. Если покупатель сервис купил, а запросов не подаёт, получил ли он сервис? Ответ — как стороны договорятся.
В следующей заметке будет решение проблем из первой части.
Сервис это или система, которую поставщик предоставил потребителю в пользование, или действия, которые поставщик выполняет в интересах или по запросу потребителя, или такая система и такие действия вместе.
С «действия, которые» спорить сложно, это определение сервиса из Гражданского кодекса РФ. С «системой, которая» можно попытаться поспорить: известно, что сервис нематериальный и неосязаемый, а значит, материальная и осязаемая система — не сервис. Но мою правоту подтвердят два аргумента.
Аргумент I. Для предоставления сервиса всегда нужна какая-то система, и замена этой системы меняет сервис
Из ГК РФ мы знаем, что сервис это действия поставщика в интересах или по запросу получателя. Чтобы эти действия выполнить, поставщик использует какую-то систему (инструмент, оборудование, помещение, …): чтобы забить для заказчика гвоздь, строитель возьмёт молоток, а чтобы доставить пассажира в другой город, авиакомпании нужен самолёт. Без системы сервиса не будет.
Замена системы меняет сервис, даже если действия в рамках сервиса остаются теми же самыми. Бизнес-класс в самолёте отличается от экономического не тем, что летит быстрее, выше или дальше, а такси «Майбах» стоит дороже, чем «Киа» не потому, что водитель «Майбаха» больше крутит руль или сильнее смотрит на дорогу. Действия те же, но система другая — значит, сервис другой.
Вывод: система, которую поставщик использует для предоставления сервиса, это неотъемлемая часть предоставляемого сервиса. Вторая часть сервиса это действия поставщика — про них можно говорить, что их исполняет он при помощи системы или что их исполняет система под его управлением, это одно и то же.
Аргумент II. Покупая систему в пользование, потребитель получает не систему, а сервис
Это вроде бы очевидно: покупатель «инфраструктуры как услуги» покупает услугу, инфраструктура остаётся у владельца. Так же и человек, взявший в каршеринге «Мерседес» на час, купил услугу, а не машину. Машину продают в другом месте и за другие деньги.
—×—
Вот, собственно, и всё. Вы только что вошли в топ-1% ИТСМ-специалистов, знаете простое и понятное определение сервиса (привет вам, Айтили 3, 2007 и 2011), которое согласуется с определениями из ИСО 9000, всех версий Айтиля, из книги Котлера и ГК РФ, но в отличие от них, оно ещё и практичное.
Во-первых, теперь очень легко построить каталог ИТ-услуг. Нужно перечислить, какие ИТ-системы вы передаёте в пользование и какие действия вы будете (сами руками, с помощью этих систем, силами этих систем, в отношении этих систем) выполнять. Каталог готов.
Во-вторых, это определение решает все ИТСМ-проблемы, перечисленные в первой заметке. Но об этом я отдельно напишу, следите за обновлениями.
Напоследок парочка соображений
Система не обязана быть сложной. Например, фитнес-клуб может вынести на улицу гантель неразборную 1 шт., давать прохожим ей пользоваться за 5 рублей в минуту, и это будет сервис.
Перечислить все действия сложных систем трудно, потому что их много. Что умеет ноутбук? Что умеет 1С? Много чего. Как справляться: то, что система умеет, описано в инструкции пользователя. Бывает ещё вариант: что система умеет, и так все знают — штанга в фитнес-клубе умеет только одну вещь, давить на того, кто её держит, с силой 9,8×m ньютонов, где m — масса штанги в килограммах. И это все знают.
Действия в рамках сервиса выполняются, когда потребитель попросит. Железная дорога не ловит прохожих на улице, чтобы неожиданно сделать их пассажирами поезда «Москва—Йошкар-Ола». Человек должен придти к ЖД и купить билет, тогда он становится пассажиром. Электронная почта не отправит письмо, пока ей не приказать. Нет запроса — нет сервиса.
Действия в рамках сервиса заранее понятны. Электронная почта не сформирует оборотную ведомость по 68 счёту за первый квартал, а 1С не проверит на спам сообщения, присланные на ваш электронный адрес. То же верно и для выполняемых руками сервисов: поставщик и потребитель уверенно отличают уборку от ремонта.
Сложим 3 и 4: все действия в рамках предоставления сервиса это выполнение стандартных запросов. Нестандартных запросов не бывает.
Система обычно состоит из подсистем и входит в более крупную систему. Действия легко делятся на более мелкие и объединяются в более крупные. Каталог услуг — это фрактал.
Дочитывал ITIL 4, и с каждой прочитанной страницей таяла надежда. На 3/4 текста терпение кончилось и остаток пролистал поиском. Ребята, это катастрофа. Двадцать лет усилий российского ИТСМ-сообщества пропали даром. Конференции, выступления, статьи, книги, форумы, онлайн-курсы — ничего не помогло, результат нулевой.
Главное изобретение российского ИТСМа, «сервисный подход», упоминается в ITIL 4 ноль раз.
Популярная среди российских ИТСМ-экспертов «сервисно-ресурсная модель» упоминается в ITIL 4 тоже ноль раз. Столько же раз упомянута её сестра «ресурсно-сервисная модель».
Высшая точка российской ИТСМ-философии, разделение и противопоставление друг другу услуг и сервисов, упомянута в ITIL 4 ноль раз. Кажется, там не поняли, в чём различие между service и service.
Председателю ИТСМ-форума в приветственной речи на открытии следующего форума уместно было бы почтить память потраченных человеко-лет.
Вышла четвёртая версия ITIL, а в ней новое и плохое объяснение, что такое сервис. До этого такое было в обеих третьих версиях (ITIL 2007, ITIL 2011), а до них — во второй. Объяснения плохие, потому что они порождают проблемы, ниже десяток примеров. Я делаю ИТСМ-проекты с 1998 года, и придумал хорошее объяснение, что такое сервис, и то, что получилось, решило все проблемы, которые мне попадались.
Что за проблемы?
Пример проблемы 1. Во второй версии ITIL в одном абзаце было написано, что айтишники часто путают сервис и ИТ-систему (то есть, что сервис это не ИТ-система), а в следующем, что сервис — это одна или несколько ИТ-систем, нужных для работы бизнес-процесса (то есть, что сервис это ИТ-система). Мозголомно, нелогично. В результате, что такое ИТ-сервис, никто сказать не мог.
1а. Ремарка. Обратите внимание, что вторая версия Айтиля не делала различий между ИТ-сервисом и сервисом вообще.
1б. Важная ремарка. Из ИСО 9000 и книги Котлера, а также из других источников мы знали, что сервис нематериален.
Пример проблемы 2. В 2003 году на моём «Евразийском форуме по управлению ИТ-сервисами» тогдашние специалисты в вопросе пробовали создать пример каталога ИТ-сервисов, и не смогли. Споткнулись на вопросах: компьютер это сервис? виндоуз это сервис? стол это сервис? Они же материальные. А одних нематериальных было мало, и каталог сервисов не получился.
Пример проблемы 3. Наши дни, почти любая компания. Каталог сервисов есть, соглашения об уровне услуг есть, услуги оказываются, но: за услуги выдаётся поддержка, и услуга оценивается по работе поддержки. Это как оценивать работу авиакомпании по количеству найденного пропавшего багажа. Проблема в том, что если багаж не терялся, оценивать нечего, и услуги как бы и не было.
Пример проблемы 4. В статье Елены Швец www.facebook.com/elena.shvets.9/posts/1938009972918361 сначала всё хорошо, но потом услуга разделяется на услугу и запросы в её рамках. X не может быть равен Х плюс ещё-что то! Вот статья целиком, не ходите на ФБ:
"Кто об чем, а она все об нем". О сервисном подходе, в общем :-).
Есть некоторая путаница в вопросе того что такое "Каталог ИТ-услуг". Состоит она из 2 видов непонимания. Я сегодня напишу про первый вид, т.к. он совсем простой, но распространенный. А завтра про второй, там позаковырестей нюанс.
Итак.
Начнем с очевидного: в английском языке существует только слово "Service", которое переводится на русский и как "Сервис" и как "Услуга". Так что если вам кто-то говорит, что услуга и сервис это разные вещи - скажите 3 раза "ха" ему поперек плеча.
Дальше нужно осознать, что типовой запрос в рамках услуги, и сама услуга - это совершенно разные вещи.
Вот пример: вы покупаете карту в фитнес-клуб. Эта карта дает вам возможность зайти в клуб, свободно пользоваться тренажерами, басиком и хамамом.
Это что-то вроде услуги "Автоматизация логистики". Можно заходить в систему в любое время, кроме периодов, когда она закрыта, ведь не каждый фитнес-клуб круглосуточный. Можно плескаться от души в прилагающейся системе отчетности, и парится в модуле планирования поставок хоть целый день!
Это услуга. Платить за нее надо за период времени. Будете вы ей пользоваться или нет - дело ваше, вы платите за возможность. Услуга - это возможность чем-то пользоваться.
А теперь давайте посмотрим что есть типовой запрос в рамках этой услуги.
Купив карту, вы имеете право без доп платы посещать неограниченное количество групповых занятий. Йога, аэробика и тэдэ. Но, только по расписанию. Если вас не устраивает расписание - вэлкам, заказываете индивидуалочку, но уже за деньги. Или вообще есть какие-то вещи, которые можно заказать только за деньги, типа сеанса массажа. Т.е. в рамках услуги "Автоматизация логистики", вы имеете бесплатный доступ к отчетам стат анализа, формируемым раз неделю по пятницам в 12-00. На этой неделе приспичило получить аналитику в среду? Фигня вопрос - 100 баксов и сделаем точечно в эту среду доп анализ.
Консультация? Бесплатно с 9-00 до 18-00 пн-пт. Надо в воскресенье? Тоже можем, но за 5 баксов в минуту. И закажите заранее.
Короче, если вы как поставщик, не хотите иметь проблем - на каждую услугу сделайте каталог типовых запросов с ограничениями и баблом. Прям сразу сделаете, прямо когда формулируете услугу для бизнеса. Заказчику услуга в вакууме не понятна, а с набором запросов с баблом за каждый - уже норм.
Итого - каталог услуг и Каталог типовых запросов - разные вещи. На портале для пользователей вы показываете именно каталог типовых запросов.
И последнее. Вообще все запросы всегда принадлежат только одной услуге. Т.е. Запрос m:1 Услуга.
Кроме бандлов. Пример - "Новый сотрудник" = бандл из 10-15 типовых запросов на подключение к разным услугам, в зависимости от роли сотрудника. Или "Все в ружье" = бандл из 5 типовых запросов на дежурство консультантов по разным системам рядом с бухгалтером, пока он закрывает год.
Хорваты вперед!
Ps: 1Если вы понимаете, что у вас есть услуга, доступ к которой бесплатный - все запросы в рамках этой услуги должны быть платными. Как в парикмахерской. На крайняк, бесплатно только первая консультация, как у юристов или косметологов. 2. Ошибка думать, что типизация запросов - это какая-то второстепенная задача в рамках request fulfillment. Если service owner будет сидеть и ждать пока в другом процессе сформулирую за него его типовые запросы к его услуге, он не дождется. Надо дать ему возможность пинать. И обязанность контролировать.
Пример проблемы 5. В Айтилях третьей версии ИТ-сервис это сервис, оказываемый поставщиком ИТ-сервисов. А поставщик ИТ-сервисов это поставщик сервисов, который поставляет ИТ-сервисы. Вы платите 60 фунтов за книгу, а там такое. Объяснение, что такое сервис вообще, не ИТ-, здесь такое, что его нельзя ни понять, ни применить.
Пример проблемы 6. Ведущий, самый лучший поставщик ИТСМ-обучения, в курсе «Основы ITIL» на слайде «Что такое ИТ-сервис» в качестве примера приводит «горячее водоснабжение». Люди 10 лет работают, а примера ИТ-сервиса привести не могут. Что может быть страшнее? А вот что:
Пример проблемы 7. Говорят, почти состоялось выступение по теме «Я 15 лет делаю ИТСМ-проекты, и вот начинаю понимать, что такое ИТ-сервис».
Пример проблемы 8. «Бизнес компании – розничные продажи, включает сети магазинов разной площади и корпоративный центр. ИТ-инфраструктура распределенная, есть сервера в магазинах и в корпоративном центре. Часть ИТ-сервисов работают автономно при сбое в работе каналов или общекорпоративных сервисов. Информационные сервисы предоставляются ИТ-службой по заключенным с бизнес-единицами SLA. Заказчик использует системы мониторинга ИТ-ресурсов. ИТ-служба приступает к внедрению системы Service Desk для регистрации инцидентов. Нет понимания, к каким SLA и конфигурационным единицам привязывать регистрируемые инциденты при массовых сбоях, влияющих на несколько сервисов.» Всё есть, СЛА есть, сервис-деск есть, каталог услуг есть. Но как дошло до дела — кого конкретно наказать, когда ничего не работает — ничего не понятно.
Пример проблемы 9. ИТ-руководитель банка говорит: «У нас нет сервисов, у нас системы». Банк работает, системы работают, деньги движутся, всё в порядке. Если всё в порядке, и сервисов нет, зачем тогда всё? Всё: Айтили, ИСО 20 000, книги, курсы, семинары, международный форум? ннз
Пример проблемы 10. Поиск, естественно, за деньги, разницы между услугой и сервисом. Некоторые находят. Уверен, они нашли бы разницу между отелем и гостиницей.
Пример проблемы 11. Предоставление услуги «Ремонт принтера» вместо запрошенной и оплаченной услуги «Принтер», то есть подмена и обман. Отвал головы при попытке сформулировать, что такое доступность услуги «Ремонт принтера» из-за этой подмены.
Читаю документ, в нём автор от SaaS и PaaS дошла до «Техническая поддержка как сервис». Е. Г-а (это зашифрованное обращение к автору), а как что ещё техническая поддержка может быть? Академический интерес.
