Продолжаем смотреть, как решаются ИТСМ-проблемы, если принять, что ИТ-сервис это стандартные действия, которые совершают ИТ-система и ИТ-сотрудники в ответ на запросы потребителя, и почти всегда ИТ-система настолько сложная, что проще не перечислять и не детализировать эти действия, а назвать их все вместе одним словом — названием системы, например.
Проблема 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, а в ней новое и плохое объяснение, что такое сервис. До этого такое было в обеих третьих версиях (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 дошла до «Техническая поддержка как сервис». Е. Г-а (это зашифрованное обращение к автору), а как что ещё техническая поддержка может быть? Академический интерес.
Некоторые люди считают, что курс «Основы ITIL» необходимо посетить всем сотрудникам ИТ-подразделения или ИТ-компании, в то время как другие говорят, что это курс только для руководителей. Каково ваше мнение?
Инвестируя деньги в обучение сотрудников, организация стремятся 1) сделать сотрудников более полезными для себя и 2) неденежно промотивировать их (т.е. заплатить за работу, но не давая сотруднику денег). При этом нужно 3) не перестараться, не сделать сотрудника слишком квалифицированными для текущей или запланированной должности. Обучение «Основам ITIL» ИТ-менеджеров помогает достичь этих целей, но обучение рядовых сотрудников ИТ по той же программе ведёт к прямо противоположным результатам. В этом эссе будет рассмотрена польза обучения «Основам ITIL» (далее в тексте — «Основы»).
Задачи рядового сотрудника ИТ: программирование, тестирование, документирование, администрирование и поддержка. Курсы по конкретным системам помогут сотруднику выполнять эти задачи лучше, а «Основы» — нет. Например, если с базой данных случился инцидент, знание администратором принципов присваивания приоритетов инцидентам не поможет решить этот инцидент быстрее, а знания и навыки, полученные на курсе администрирования этой конкретной БД как раз должны помочь. То есть посещение «Основ» не делает рядового сотрудника ИТ более ценным для организации. С другой стороны, ИТ-руководитель как раз не должен знать подробностей администрирования БД, но должен уметь организовать распределение задач между исполнителями и установить очерёдность их выполнения. Это в точности то, что преподают на «Основах».
Многие компании рассматривают обучение и сертификацию сотрудников как часть компенсационного пакета. Например, нормой является оплата обучения только сотрудникам, проработавшим в организации не менее определённого срока. Это свидетельство того, что обучение рассматривается не как способ получить сотрудника, способного решать поставленные задачи, а как средство принудить сотрудника оставаться в организации. Для рядового ИТ-сотрудника «Основы» не представляют ценности, как источник знаний и навыков, потому что знания и навыки этого курса рядовому сотруднику применить негде. Курс «Основ» может быть ценен для ИТ-сотрудника только как трёхдневный отпуск. ИТ-менеджеру, наоборот, «Основы»дают немедленно применимые знания и навыки.
Избыточную квалификацию, то есть когда сотрудник знает и умеет больше, чем нужно знать и уметь на занимаемой должности, принято считать проблемой. Такой сотрудник не будет удовлетворён ни решаемыми задачами, ни получаемой оплатой, потому что он знает, что может делать и зарабатывать больше. Рядовой сотрудник ИТ после «Основ» понимает, что работа ИТ-руководителя вполне посильная и он с ней справился бы. Это лишнее знание для рядового сотрудника, делающее его излишне квалифицированным. Напротив, для руководителя в ИТ знания и навыки «Основ» необходимы, без них он недостаточно квалифицирован для своей должности.
Хорошим подтверждением для вышесказанного является программа обучения сотрудников эксплуатации и поддержки от компании «Гугль» — в рассчитанном на полгода обучении ни разу не упоминаются ни ITIL, ни процессный подход, ни жизненный цикл сервиса — этот список можно продолжать долго. «Гугль» однозначно показывает, что рядовому айтишнику это не нужно.
Вывод: курс «Основы ITIL» создан для ИТ-руководителей; посылая на «Основы» рядовых айтишников, организация сама себе вредит.
«Гугль» считает, что система мониторинга, а вместе с ней и администратор, должна следить за 4 категориями сигналов:
Latency
Дословно — задержка, но здесь это «скорость обработки запросов» или «скорость выполнения действий».
Сервис это действия, а людям, когда они имеют дело с компьютером, очень хочется получить всё побыстрее, поэтому сигналы этой категории помогают понять, как пользователь воспримет ваш сервис: «тупит» он или «летает».
Например, это может быть скорость выдачи веб-страницы. Или скорость реакции компьютерной игры на нажатия клавиш. Или время от подачи запроса до момента установки нового ПО на рабочую станцию, то есть скорость выполнения стандартного запроса.
Чтобы узнавать скорость выполнения запросов внутри своих систем, «Гугль» встраивает средства мониторинга внутрь самих систем. Аналог: запуск команд внутри команды time. Для примера я несколько раз скачал главную страницу этого сайта и получил вот такую latency (цифры перед total, в секундах).
Кое-что мне кажется на этой картинке странным, но раз она сделана ради цифр скорости загрузки, прочее не сильно важно, так что если вы тоже заметили странность — я не разбирался, почему так получается.
Traffic
Трафик (вроде эксперты склоняются к одной ф) — сколько работы делает ваш сервис. Если в предыдущем разделе нас интересовала скорость обработки запросов, то теперь мы измеряем их количество.
Rate of errors
Лучшим переводом видится «процент ошибок». Это лучше, чем «количество ошибок», потому что 10 ошибок при 10 запросах и 20 ошибок при 10 000 запросов — это очень разные ситуации, и первая намного хуже второй, хотя количество ошибок в ней вдвое меньше.
Level of saturation
Дословно — уровень насыщения, но вроде у нас все говорят «утилизация» (если нет, в комментах своё слово укажите, пожалуйста) в качестве общего термина, а когда речь о конкретном объекте, термин будет специфический для него: «загрузка процессора», «свободное место на диске».
Один и тот же показатель может быть про трафик, если он сам по себе, и про утилизацию, если мы его сравниваем с максимально возможным. Например: «10 активных подключений к БД» это трафик, а «из 20 возможных подключений к БД активны 10» это утилизация.
Обсуждение прошлой заметки заставляет меня сформулировать мой тезис бо́льшим количеством слов. Я утверждаю, 1) что номер инцидента создаёт удобства поставщику услуг при решении каких-то внутренних проблем, однако из этого не следует, что для пользователя от знания номера тоже есть какие-то удобства; 2) что для пользователя качество сервиса не повысится от того, что он этот номер знает; 3) качественный сервис можно предоставлять, не сообщая пользователю никаких номеров. Отдельно замечу, что если уж невыносимо хочется пользователю какой-то номер инцидента всучить, разумно ограничиться скромным трёхзначным номером, чем самонадеянно рассчитывать, что пользователь захочет посчитать, сколько нолей в вашем INC000000030889.
Один из комментаторов сказал: «Как руководитель подразделения я точно знаю, что сотрудников дисциплинирует понимание, что раз заказчик знает номер, то разгильдяй будет обнаружен». Мне понравилось: пользу для внутрениих дел поставщика продают, как пользу для потребителя. Нет, не нужен мне ваш номер, дайте качественный сервис.
Однако, иногда я бы хотел знать номер инцидента.
Однажды я пытался стать клиентом «Тачбанка». По каким-то причинам приложение Touchbank отказывалось переводить к себе деньги. После нескольких попыток в течение пары недель я даже не стал обращаться в поддержку. Решил, что лучше не связываться: сейчас не работает пополнение, а вдруг потом не сработает снятие? Месяца через три банк обо мне вспомнил и стал требовать 4 доллара за услуги. Я считал, что никаких услуг банк мне не оказал, больше их н ехотел, и просил расторгнуть наш контракт. Первый тачбанкир, которому я сказал об этом, пообещал, что мне позвонит специальный расторгатель контрактов. Наврал. Поддержка на письма сначала не отвечала, а когда их заставили со мной общаться, повела себя не так, как ведут себя люди, собирающиеся помочь. После второго письма ни о чём я попросил сообщить мне номер моего дела, инцидента, обращения или что у них там. Сделали вид, что не понимают, чего я хочу. Тоже поставили наглеца на место, я надеюсь.
О чём я? Нет, не о том, что если бы я знал номер, то мог бы сообщить его директору банка, и тот уволил бы сначала вруна, а потом любителей из поддержки. Внутренние проблемы банка мне не интересны. Не о том, что знай я номер, мой вопрос решился бы быстро и вежливо. Я говорю о том, что если потребитель требует сообщить ему номер инцидента, это звоночек. Он не доверяет поставщику, он уже верит, или, хуже, знает, что тут работают плохо. Велика вероятность, что он скоро уйдёт. Номер инцидента для него, как соломинка для утопающего — последняя, но часто пустая надежда. Уверенный в поставщике потребитель номеру инцидента предпочтёт продолжение хорошего сервиса.
Краткое содержание предыдущей заметки: короткие номера инцидентов лучше длинных, если вы уважаете пользователя.
Краткое содержание сегодняшней заметки: пользователю номера инцидентов не нужны вообще.
Знание идентификатора своего взаимодействия с поставщиком (INC000000030889) не приносит пользователю никакой пользы. Но этот номер приносит пользу поставщику, даже три:
Первая польза — считается, что оператор или инженер могут найти инцидент только по номеру. Ведь номер уникальный, по нему можно найти ровно один инцидент, если он есть, а если номер неправильный или пользователь его не знает или не помнит, то и разговаривать с ним не о чем. Это миф. Если пользователь обращается по поводу какого-то инцидента, то это точно не инцидент десятилетней давности — ИТСМ-системы столько не живут. Это точно не инцидент пятилетней давности — люди сейчас не работают по пять лет на одном месте. Это даже не пятинедельный инцидент, потому что тем, кто за 5 недель не может решить инцидент, уже должны были позвонить из отдела кадров. Посмотрите в ваши регламенты и SLA, там, скорее всего, написано, что со всеми ожиданиями и откладываниями максимальный срок решения инцидента не больше трёх недель. А за три недели в норме пользователь генерирует полтора инцидента. Так что как только вы идентифицировали пользователя, и он звонит по поводу ранее открытого инцидента, в норма вам не нужно спрашивать у пользователя номер, вам нужно только узнать, идёт речь о вчерашнем инциденте, или об инциденте, открытом на прошлой неделе.
Вторая польза — номер нужен для расследований. «Мы просрочили решение INC000000030889 на 130 недель, кто-то должен за это ответить!» Полностью согласен с постановкой вопроса, но хочу заметить, что это внутреннее дело поставщика услуг, и пользователь тут ни при чём, и номер инцидента ему знать ни к чему.
Про третью пользу недавно читал в чьей-то заметке: «Он нам звонит за помощью, а мы ему [вместо помощи]: „А какой номер инцидента?!“ Поставили наглеца на место!»
Большинство транзакций в жизни мы исполняем, не зная их идентификаторов, а если бы и знали, нам это никак не помогло бы. Мы не обращаем внимания на номер чека в магазине, на номер билета в самолёте, не знаем идентификаторы своих звонков и электронных писем. Не ищем на стоянке свою машину, а на улице свой дом по номеру, как-то обходимся без этого. Точно так же отсутствие номера инцидента не мешает его быстрому решению:
Компания, в которой работает Соня, могла бы заставить её отвечать: «Вашему обращению присвоен номер INC000000030889, oбязательно указывайте этот номер при всех последующих обращениях в службу поддержки!», но вместо этого Соня сразу быстро решает инцидент. Вот бы все так делали!
Конечно, у каждого инцидента есть полезный для поставщика идентификатор, и часто не один. Но не всё, что у вас есть, стоит выкладывать клиенту под нос.
Пару лет, а то и больше, я не слышал от сотрудников ИТ-подразделений слова «юзверь». По-моему, это хорошо: тех, кто нам платит за работу, нужно уважать. Следующим шагом в развитии уважения к пользователю может стать отказ от издевательских номеров обращений.
«Ваш инцидент зарегистрирован под номером INC000000030889. Обязательно указывайте этот номер при всех последующих обращениях в службу поддержки!»
Номер INC000000030889 не подходит ни для запоминания, ни для проговаривания вслух. Особенно мешает ряд нулей, их трудно сосчитать. Вот несколько рекомендаций, как улучшить этот номер.
В параллельной вселенной, где именно такая форма и такая длина номера являются оптимальными, я бы улучшил номер, разбив в нём символы на группы по три: INC 000 000 030 889. Или INC_000_000_030_889, если кто-то опасается, что пользователь не поймёт, что это один номер, а не несколько. Впрочем, для фразы «Ваш инцидент зарегистрирован под номером INC 000 000 030 889» риск непонимания отсутствует.
Для организаций, живущих в реальном мире, вполне достаточно будет номера покороче: INC 030 889 хватит для регистрации миллиона обращений. Много это или мало? Если в норме (константа Конакова) один пользователь генерирует 26 обращений в год, и вы планируете пользоваться этой ИТСМ-системой и её номерами 10 лет, то 6-значных номеров хватит для организации, у которой 3846 пользователей.
А если система продержится дольше 10 лет? Ничего страшного. Нумеруйте обращения и инциденты, как счета-фактуры, начиная с 1 с началом каждого года. Тогда шестизначных номеров хватит для 38 461 пользователя. Если же запускать нумерацию обращений с 1 каждый месяц, то трёхзначных номеров (INC 889) хватит для компании с 500 пользователями. Месяц — слишком короткий промежуток, и возникнет путаница: о каком INC 889 идёт речь, о январском, февральском или мартовском? Во всех SLA, которые я видел, крайние сроки решения выражены в единицах и десятках часов, поэтому если февральский INC 889 ещё не закрыт к моменту появления мартовского INC 889, у этой организации проблемы такого масштаба, которые переход к 6-значным номерам точно не решит.
Приставку INC (REQ, CHG, TAS …) требуют устаревшие ИТСМ-системы, чтобы оператор знал, в каком интерфейсе искать запись. Сегодня поиск устроен, как в «Яндексе»: одно поле ввода, ищет везде. Поэтому вместо принадлежности к интерфейсу (INC 889) полезнее в приставке отразить принадлежность запроса к компании. «Тачбанк» мог бы написать так:
«Вашему обращению присвоен номер TBN 889.»
При чём тут этот банк и куда пропала вторая фраза, про «указывайте номер», читайте в следующих заметках.
Три дня боролся с программой rtorrent — начинает качать быстро, но через 4 минуты скорость падает со 11 500 до 200 килобайт в секунду. Чего только не делал: удалял и переустанавливал, ставил новейшую версию, менял настройки и самой программы, и компьютера, и роутера. Ничего не помогало. Конечно, я ни в настройках, ни в сетях особо не разбираюсь, поэтому все советы, которые я пробовал применить, были нагуглены. И что странно, в точности такая ситуация, как у меня, ни разу не попалась. Похожие — да, но другие, что на русском языке, что на английском. Решение я в конце концов нашёл, и в самом обидном месте: в разделе «Известные ошибки» на странице программы rtorrent. Текст дальше для тех, кто столкнётся с такой ситуацией, как у меня.
Симптомы: rtorrent 0.9.6 / 0.13.6 начинает скачивать на максимальной скорости, но после нескольких (у меня примерно после 4) минут работы скорость падает до 200 КБ/сек, и сам rtorrent начинает очень медленно реагировать на команды. Перезапуск rtorrent не помогает, перезагрузка компьютера помогает, но на те же 4 минуты.
Решение: я сохранял скачиваемое на NTFS-раздел, а в первой строчке в списке известных ошибок написано: rtorrent has issues with ntfs partitions. Когда я перенацелил параметр directory на ext4-раздел, проблема была немедленно и полностью решена.
Problem: rtorrent 0.9.6 / 0.13.6 starts at full speed, but after several (about 4) minutes the speed drops to 200 KB/s or even less. Aslo rtorrent became vary unresponsive to keys pressed. Restarting rtorrent doesn't help. Restarting the computer does, but only for another 4 minutes.
Solution: if you're saving the files to an NTFS partition, please be informed, that rtorrent has issues with NTFS partitions. Point 'directory' parameter to an ext4 partition, and the problem will be solved immediately.
Грустная часть: починив качалку, я вознамерился что-нибудь наконец скачать, но понял, что ничего не хочу.
