пятница, 9 октября 2009 г.

Полезность и гарантия – странное враг хорошего

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

Осенью 2008 года стартовал проект ITEMS (публикация коротких статей с пояснениями и комментариями относительно идей ITIL). Проект делался в явно маркетинговых целях, но основная идея была очень правильная. Ибо публичных комментариев практиков не хватает. ITEMS успешно стартовал, чтобы в феврале 2009 благополучно свернуться, да и автор статьи уже работает вовсе не там.

Ну не суть. В наборе одна из статей сразу привлекла внимание: "Полезность и гарантия – глупость или гениальная идея?" от Олега Скрынника. Внимательно прочел. Давно хотел по поводу полезностей и гарантий письменно подискутировать, жаль руки не доходили. Комментарий Олега – повод прекрасный. Кстати, кому интересно узнать мою версию ответа на вопрос "глупость или гениальная идея", те могут подсмотреть смело в окончание поста, там все есть.

Разделение понимания ценности сервиса на полезность и гарантию – это то, что сразу заинтересовало в первых чтениях ITIL v3, и при попытках внятного перевода этих понятий на русский. С коллегами очень долго раздумывали, прикладывали так и так к практическим работам, размышляли как использовать в проектах. В результате плюнули, добавили понятие в курс и забыли до времени. Спустя некоторое время возникла возможность на курсах задать вопрос консультанту Getroniсs, а зачем новое понятие введено в текст, какие задачи оно решает? Так как консультант увидел меня минут 15 назад, то он с ответом замялся, но выудил ответ из общих соображений. Но так как консультант был изрядно подкован многими проектами, а не просто голой теорией – то через два дня знакомства он признался, что если бы авторы ITIL v3 меньше сочиняли новых понятий, текст был бы значительно яснее и проще.

О чем пишет Олег в своей статье. Первое – описывает и комментирует определения полезности, гарантии из третьей версии нашей любимой библиотеки передового опыта. В результате приходит к выводу, что полезность-гарантия скорее нужна, чем нет. Варианты переводов терминов "Полезность сервиса", "Гарантия сервиса" на русский язык можно посмотреть в официальном глоссарии ITIL v3, ну или у в статье Олега (определения почти одинаковы). Я же так долго о воздушных терминах распинаться не буду. Определим проще, по-крестьянски.

Полезность сервиса, это "что сервис делает", какие требования закрывает, какой функционал предоставляет. Вообще, сия полезность известная под агентурной кличкой "функциональность".

Гарантия сервиса еще проще – "как сервис делает", т.е. формализованное обещание обеспечить параметры уровня собственно сервиса, нужный уровень безопасности и прочее, и прочее. Это то, что всю жизнь называлось уровнем качества услуги, уровнем сервиса.

Вы видите в этих понятиях что-то концептуально новое? Я лично – нет. Все разрабатываемые соглашения об уровне услуги (SLA) так или иначе делятся на два раздела: функционала сервиса и параметров уровня качества сервиса. Что представляет услуга "Почта" с точки зрения функционала: отправка \ прием почтовых сообщений, уведомления о вручении, актуальная книга контактов в компании, адресные рассылка по компании. Что представляет "Почта" с точки зрения уровня качества: доступность 98%, часы поддержки 9.00 – 18.00, время устранения критического инцидента 2 часа, восстановление из бэкапа истории переписки за полгода, условия безопасности, етц. Не припомню нужды в разделении. А что даст надпись к ряду параметров подраздела Полезность, а к другому Гарантия? (еще попробуйте написать "гарантия" в юридически значимый SLA, хлопот не оберетесь).

Если вы думаете, что данное понятие было введено для структуризации текста – вы ошибаетесь. Понятие полезности - гарантии в верном контексте упоминается, кроме Service Strategy в прочих книгах ITIL порядка 12 раз, из них SO – 0!!! раз, SD – 4 раза (не считая глоссария и заголовков), в ST чаще всего – 8 раз (если считать упоминания рядом за одно), и в CSI – 0!! раз. Нормально? Если это простая несогласованность планов выпуска, то можно только аплодировать архитектуре библиотеки.

Так все-таки, полезность и гарантия – глупость или гениальная идея? Мы с бритвой Оккама и принципом МЕСЕ считаем, что это лишнее звено эволюции: непригодное для практического применения, громоздкое, ненужное определение. В общем, типичная производная air management. Ничего не проясняющее и не поясняющее. На языке кайдзен это именуется короче – му'да (извините за прямую цитату).

Внесены разработчиками ITIL новые определения, разумеется, с наилучшими побуждениями. Нагнать тексту и сделать структуру понятий более запутанной и непрозрачной. А любителей мистического прочтения второй, третьего и n-ного слоя ITIL прошу ответить на простой вопрос: параметры качества процессов управление инцидентами и проблемами, поддерживающих искомый сервис, это гарантия или не гарантия?

И помните - "истинно лишь то, что отвечает практической успешности действия" (с) Уильям Джеймс.

16 комментариев:

Анонимный комментирует...

Мысли в основном поддерживаю. Если подходить прагматично, то толку в этих определениях нет. Что можно предположить:
1. Задел на некое счастливое будущее
2. Попытка структуризировать эти самые понятия "функциональность" и "уровень"

Но оба этих предположения страдают врожденной убогостью :)

P.S. Остальные статьи ITEMS будешь комментить? ;)

Alexander Zhilinsky комментирует...

Пусть лучше это будет задел. Посмотрим, что за изменения будут внесены в результате обновления itil3, может быть определения в структуре появятся?

А какую нужно? :) Там остальные вроде не такие интересные на предмет поспорить.

Oleg Skrynnik комментирует...

Саша, читать твой блог очень забавно :) Не думал, что можно найти столько интересного в заметке ITEMS полуторагодовой давности, особенно если вспомнить как и для чего она была написана.

А написана она была, собственно говоря, с одной целью - показать коллегам по IT Expert что именно требуется изготавливать в проекте ITEMS: формат, стиль, объём, шаблон, если угодно. Больших изысканий на тему полезностей и гарантий в ней нет, что, наверное, видно невооружённым глазом :)

Alexander Zhilinsky комментирует...

А по-моему, очень интересный информационный повод :) Потому что, кроме тебя в ITEMS, Олег - про полезность и гарантию никто не написал вообще. А ведь кардинальное понятие тома SS.

Выложил текст - ожидай того, что он начнет жить своей жизнью ! .. 8)

Unknown комментирует...

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

Анонимный комментирует...

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

Unknown комментирует...

Мне тоже :-)
Как раз квалификация, опыт и количество бегающих человеков будут соответствовать уровню предоставления услуги, т.е. гарантии. А возможность удовлетворить желание постричься или покушать, точнее своевременность (время и место), соответсвует полезности.
ITIL только даёт общие рекомендации, как всё это легче организовать.

Alexander Zhilinsky комментирует...

А Олег по-моему и не отказывался?!

Функциональность (полезность) это скорее даже не своевременность подстричь. А это возможность, кроме собственно подстричь: покраски, сушки, етц.

Unknown комментирует...

"отказ" Олега я усмотрел в том, что он не стал настаивать на том, что полезность, это не есть функциональность! С гарантией немного сложнее, уж больно с уровнем сервиса пересекается. Я бы предложил идею введения термина "гарантия" как формализацию или структуризацию, если хотите. А вот полезность... Если консультант сможет продемонстрировать полезность услуги для бизнеса, это намного больше, чем разъяснить функциональнсть сервиса!

Alexander Zhilinsky комментирует...

2anatoly
В каком смысле, пересекается с уровнем сервиса? Это и есть нефункциональные характеристики, т.е. уровень сервиса \ качество услуги. Просто туда ряд требований не добавлены.

А в чем, на ваш взгляд, отличия полезности и функциональности? Будет еще одно мнение.

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

Unknown комментирует...

2Alexander Zhilinsky
;-) не совсем честно отправлять к первоисточникам, если принято решение определять "по-крестьянски". И даже на ITEMS написано, что "Данная заметка отражает мнение автора, которое может не совпадать с уважаемыми первоисточниками (ITIL v2, ITIL v3, COBIT, MOF и проч.)."
Скажу сразу, что не буду дальше спорить, не планировалось :-)
По поводу терминологии могу посоветовать перешерстить Utility по словарям. Мне кажется хорошей ссылкой: http://www.yourdictionary.com/business/utility/

Alexander Zhilinsky комментирует...

Ссылка открывается на страницу 404..

Погодите, Анатолий, ну словарь-то ITIL нам прямо говорит следующее:

(Service Strategy) Functionality offered by a Product or Service to meet a particular need. Utility is often summarised as "what it does".

Так что разночтения пока невозможны? 8) До выпуска следующих редакций \ версий ITIL.

Unknown комментирует...
Этот комментарий был удален автором.
Unknown комментирует...

правил, описок много
да, блин, как-то криво линки на этом сайте... надо походить по сайту. Я хотел показать на примере этого сайта, что существует достаточно много толкований слова Utulity в английском языке. Возможно, создатели немного погорячились, не дав прецезионного толкования. Для меня ключевыми словами есть "business value" в определении для "Service Utility". Ну а для value даже существует отдельная методология у ITGI
(IT Governance Institute, Val IT 2.0 Edition, USA, 2008, www.itgi.org)

Alexander Zhilinsky комментирует...

Понял, будем почитать!

Alexander Tsimbalistov комментирует...

Про бритву Оккама это в десятку! Прекрасно!

 
скрипт счетчика посещений
статистика сайта