В процессе чтения.
Ну что сказать? Все на картинке.
понедельник, 19 октября 2009 г.
понедельник, 12 октября 2009 г.
Снова об ITILv3, функции и процессы
Тут в комментариях Георгий просил еще статей из почившей серии ITEMS откомментировать. Комментирую. Лучшая статья: вот здесь Роман Журавлев рассуждает о понимании функций и процессов в ITIL v3. Кто интересуется темой и не читал - читать в обязательном порядке.
Самое важное:
- Процессы структурируют деятельность для достижения целей.
- Функции структурируют возможности и ресурсы для обеспечения работы процессов.
То есть, "Процессы направляют усилия к цели. Функции управляют возможностями" (с) Здесь подписываюсь, как под своим.
И еще, Роман отмечает: "Между прочим, с этой точки зрения возникают большие сомнения в процессной природе таких явлений, как управление доступом и управление событиями (которое в оригинале event management)". За управление доступом ручаться не готов, а вот Управление Событиями - это явно не есть процессная структура. Правда, я там дальше по толкованию не согласен, но суть вопроса Роман раскрыл очень четко. Пожалуй, статья о "Полезность и гарантия" от Олега плюс вот эта статья от Романа - лучшее, что было в ITEMS.
Остальные как-то полемического задора не вызывают. Скучноватые комментарии к ITIL, ах этот Портфель услуг это не совсем каталог услуг, ах процессом нужно управлять и это должен делать менеджер. Разве что еще статья "Переход на ITIL - это куда?" заслуживает поощрения за прекрасное полуцензурное название в стиле поручика Ржевского, ну и за эпиграф.
MS Service Desk == MS SCSM, есть русскоязычный блог по продукту!
Полку Service Manager'ов прибыло - любим говорить мы о сертифицированных ITSM специалистах. Теперь можно и о ПО аналогичным образом. К известному HP Service Manager вскоре добавится MS SC Service Manager. Выпущена бета №2, и шансы на релиз-кандидат высоки, крайне высоки. А вот здесь доступен самый настоящий русскоязычный блог по MS SCSM от Владимира Бахметьева, program manager'а данного продукта!
пятница, 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 прошу ответить на простой вопрос: параметры качества процессов управление инцидентами и проблемами, поддерживающих искомый сервис, это гарантия или не гарантия?
И помните - "истинно лишь то, что отвечает практической успешности действия" (с) Уильям Джеймс.
вторник, 6 октября 2009 г.
"Прекрасное" (с)
Половина британских компаний считает, что использование рекомендаций ITIL не приносит конкурентных преимуществ. По данным Vanson Bourne, лишь четверть их ИТ-персонала проходила тренинги по какой-либо из версий ITIL. Главной причиной этого стало отсутствие очевидных бизнес-эффектов от подобных курсов повышения квалификации. Другим озвученным фактором является высокая стоимость обучения. С учетом нынешних бюджетных ограничений, он также играет важную роль. (с)
Прекрасное пришло вот отсюда: новость на osp.ru
пятница, 2 октября 2009 г.
Забудьте о KPI ! (часть 1, или простые ошибки)
Забудьте о KPI !
Навсегда забудьте о KPI! Стройте и улучшайте процессы управления ИТ с четко поставленными целями. Тогда создавать KPI в творческих муках просто не будет необходимости. Показатели и так будут у вас под рукой. Парадокс? Давайте попробуем разобраться.
Ситуация в большинство ИТ-отделов с практикой создания и использования процессных метрик действительно удручает. Фразу "если не измеряешь, значит не управляешь" многие компании выучили наизусть, и ошибка номер раз – полное отсутствие измерения ИТ процесса – постепенно вымирает на просторах отечественного ИТ. Хоть что-нибудь, но померяем. Качественно ли измерим, то ли измерим, что нужно – второй вопрос. Средняя температура известна. И после шага один становится немного сложнее. Дальше нас подстерегают интересные, познавательные грабли.
До сих пор во многих известных и уважаемых компаниях наиболее используемым отчетом Service Desk все еще остается простой реестр инцидентов с главным показателем – количество инцидентов. Это хороший KPI процесса управления инцидентами? Прошу вас, после чтения этой статьи – взгляните на этот простой вопрос и ответьте на него еще раз.
Основные ошибки.
Попробуем типизировать наиболее распространенные ошибки создания и внедрения показателей:
1) Не измеряем вообще.
2) Набор показателей формируем на основе списка, взятого из литературы, системы, уже реализованного проекта или просто придуманного человеком, в глаза не видевшего измеряемого процесса.
3) Ключевых показателей формируем столько, сколько это возможно в принципе – чем больше, тем лучше.
Номер раз обсуждать не будем – ясно без микроскопа.
Ошибка номер два наиболее логично вытекает из нашей любимой библиотеки ITIL. Там со времен второй версии к KPI относились так, что иногда становилось жутко. Как тонко подметил когда-то один коллега: берем аналогию процесса с автомобилем, где ключевые показатели – спидометр, тахометр и пр. Тогда KPI, приведенные в ITIL v2 – это намек на прибор, измеряющий обороты двигателя в милях, скорость в фаренгейтах и температуру двигателя в градусах. Цельсия или угловых градусах – изволь читающий угадать сам. А еще разработчики ITIL любят давать по несколько штук таких приборов, дублирующих показания в разных шкалах.
О чем говорят эти метрики? Общее количество чего – зарегистрированных, закрытых, открытых за период, или всего в системе? Каким средне- или долгосрочным целям соответствуют метрики? Каковы пороги "удовлетворительно – нормально – хорошо – отлично" для этих метрик? А что делать, если неудовлетворительно, если инциденты сваливаются в backlog мы их закрываем медленнее, чем регистрируем? Количество инцидентов вдруг сократилось на 20%, а потом еще на 30%? Это как, хорошо или плохо? Если хорошо – мы проактивны! Если плохо – чем же мы будем заниматься?
Ну ладно, бог с ITIL'ом. Наша любимая библиотека никогда не акцентировалась особенно на шаге измерения. Спасибо и за цикл Деминга, положенный в основу процессной модели. Возьмем разработанные системы Helpdesk. Их разработчики (о боже!) тоже читали ITIL и умеют фантазировать на тему KPI. Возьмем оттуда, ведь эта система была выбрана нами, а значит там должно быть большинство необходимых отчетов для подсчета KPI. На семинарах часто наблюдаю одна и та же забавную картину, где рабочая группа приступает к проектированию KPI. Процесс спроектирован, теперь его нужно как-то измерять. Хорошо, если в наличии шаблоны реализованных проектов. А давайте посмотрим на существующие наборы KPI? Те, что понравятся – оставим, а остальные додумаем уже потом. Я не то, чтобы против "посмотреть", однако в большинстве случаев такое "посмотрим" приводит к бездумному копированию чужих измерителей эффективности и результативности процесса на свой собственный.
Копирование возможно только в одном случае – если копируемый процесс соответствует поставленным целям, содержит качественные, опробованные KPI и он копируется целиком!
Ошибка номер три, пожалуй, самая известная и распространенная при пользовании ИТ вообще – обусловленная кажущейся легкостью получения данных, годных для отчетности в информационных системах. В момент, когда мы перестаем различать просто данные и информацию (данные, годные для анализа с целью принятия решений), обычно стартует ошибка номер три. "Мы пока сами не знаем, какая именно информацию нам понадобится" – а поэтому давайте разработаем как можно больше отчетности, избыточной, дублирующей друг друга. Отчеты – это же так просто! "Пусть их будет как можно больше, а уж мы точно разберемся, какие использовать" – обычная для многих проектов формулировка. И заказчики процессов управления ИТ стараются не отставать: сколько у вас KPI для процесса? Всего двадцать?! Да вы что, в гроб меня загнать хотите. Конечно нужно больше! И пошла-поехала генерация любых показателей, выдаваемых за KPI.
Ценная информация быстро тонет в бесконечном, фрагментарно обрабатываемом потоке данных. Отсутствует любая, хотя бы самая простая технология проектирования KPI.
Далее, в следующих разделах:
Определим терминологию и типы показателей
Несколько простейших советов, как избежать простых ошибок
Каким образом формировать цели для внедряемого процесса?
Если процесс уже функционирует, нужна ли ему цель?
Наброски к будущей технологии проектирования KPI
Эксперимент - статья на блоге, онлайн
В загашнике давно лежит структура и начало статьи о наболевшем - хорошие практики проектирования KPI (метрик, показателей эффективности, KGI и иже с ними). Тема старая и очень интересная. Есть мысли о том, чтобы сделать простую, работоспособную технологию проектирования KPI.
Увы, но статья эта пишется не в одиночку и делит мои временные ресурсы по остаточному принципу. То есть движения текста за полгода практически никакого. Было принято волевое решение: пишу статью на блоге онлайн, для чего будет заведен специальный тег "article-online" - которым можно будет отделить онлайн-статью от других записей. Ну, или несколько онлайн-статей в будущем, если эксперимент покажет себя успешно.
Поехали: Забудьте о KPI! Часть 1, или основные ошибки.
понедельник, 21 сентября 2009 г.
Что HP может рассказать о Lean-технологиях в ИТ?
Без формата, товарищи, никуда. Все в мире имеет формат. Выступление HP о Lean-технологиях имеет жесткий формат. Текст моих личных отзывов тоже четко заформатирован: не могу материться. А иногда очень хочется, правда.
Искомый доклад HP вел Илья Хает. Для тех, кто не в курсе – Хает один из лучших презентаторов, по крайней мере в области ITSM точно. С ходу Илья продемонстрировал стандартный набор фирменных приемов: и аудиторию аккуратно держал, и обратную связь от аудитории зацепил в самом начале выступления, снискал множество дополнительных вопросов. Видимо поэтому Илью и попросили здесь выступить. Для тех, кто не понял – это я хвалю талант докладчика. Больше-то хвалить нечего, дальше только ругань.
Читать далее..
четверг, 17 сентября 2009 г.
Отличный текст о Lean
Бережливое производство не равно Lean production, от Елены Маркушевой. Ссылки по тексту читать в обязательном порядке - тем, кто не знаком.
вторник, 15 сентября 2009 г.
Почему я пойду на конференцию itSMF?
Вот на этой конференции, в пятницу 18 сентября Илья Хает обещается рассказать об опыте проектов с применением Lean IT (30-минутный доклад, "Об особенностях внедрения решений с использований методик ЛИН для ИТ").
Мне эта тема близка и любопытна настолько, что приду обязательно. И вопросы задам обязательно. В том числе и неудобные. Если будут.
четверг, 27 августа 2009 г.
Очередная ошибка в ITILv3
Скептик неспешно читает ITILv3 Service Operation.
... и неожиданно обнаруживает, что в процедурах Управления Инцидентами нет сопоставления Услуги Инциденту. А значит, нет и сопоставления SLA. Интересно, а чего он ожидал?
Кто не верит - смотрите в процедуру 4.2.5.2 Incident logging (а потом все прочие) и попробуйте найти там явно упомянутое поле Service или SLA. Соответственно, никакого анализа воздействия на услугу в Управлении Инцидентами тоже провести не получится. Ну и Каталога Услуг, по-видимому, тоже нет.
Об управлении изменениями, релизами и модном нынче lean
Зафиксировать ключевые принципы базового управления изменениями довольно-таки просто:
- все изменения регистрируются и оцениваются;
- не все изменения реализуются;
- все реализованные изменения проверяются.
Теперь о релизах. Тут сложнее и интереснее. В соответствие с одним из принципов lean (вытягивание) нам нужно серьезно менять подход к управлению релизами.
Стандартный процесс управления релизами обязательно будет накапливать некоторое буферное число изменения, подготовленных к запуску в промышленной эксплуатации. А это обычно означает, что некоторую часть времени изменение будет лежать на полочке, красиво упакованное и подготовленное для внедрения. Но не внедряемое. Почему? Обычно потому что в регламенте устранения релизами кто-то когда-то записал: периодичность полного релиза для систем типа Х-Альфа не более 6 раз в год. Точка.
Надеюсь, получится исследовать данный вопрос.
среда, 26 августа 2009 г.
Следующая статья для перевода
На сайт itSMF до 23 августа можно было выбрать следующую статью, которая будет переведена на русский язык. На выбор предлагалось:
- распространение практики Service Desk на все запросы компании;
- опыт внедрения SLM;
- семишаговый совет о внедрение ITSM.
Любопытно. Посмотрим на статистику интересующихся в русскоязычном сегменте.
вторник, 25 августа 2009 г.
Заметка Ильи Шутова о мониторинге
Интересная короткая заметка о "системах мониторинга ИТ" в формате вопрос-ответ, за авторством Ильи Шутова (из его блога). Неплохо, а местами прекрасно!
"4. Необходимо, чтобы решение осуществляло мониторинг приложения X. Ваше умеет?
Когда речь идет о мониторинге приложений, сразу возникает несколько десятков альтернатив. Что значит, осуществлять мониторинг? Следить за лог-файлами? Следить за состоянием процессов? Получать сообщения? Осуществлять проактивный мониторинг с помощью тестовых функций? Проверять выполнение бизнес-логики? Отслеживать утечки памяти?" (с)
Кстати, применимо не только к мониторингу. Сколько раз уже сталкивался с завороженностью заказчика словом "интеграция", в общем смысле, без какой-либо конкретизации.
Роб Ингланд препарирует "соответствие ITIL"
На itSMF переведена статья ИТ-скептика, повествующая о нелегкой доле поставщиков ПО ITSM, вынужденных ставить ярлыки соответствует ITIL на что угодно - хоть на стикеры.
Роб Ингланд в обычной, полусаркаcтической манере формирует ряд вопросов к понятию соответствия ITIL. Например, вопрос №9:
"Поддерживает ли инструмент работу с процессами (workflow)? Довольно странно, если в процессно-ориентированном инструменте этого нет. Входят ли в «коробочный» вариант продукта стандартные процессы ITIL, описанные в красной и синей книгах? Например, поддерживает ли он ветвление процесса для важных и незначительных изменений? А для запросов и инцидентов? Каким образом обосновывается в документации внедрение продукта для поддержки процессов в соответствии с ITIL? Подавляющее большинство крупных поставщиков предлагают внедрять продукт, используя практики ITIL. Проверьте, есть ли расхождения между продуктом и документацией. Если в документации с трудом можно отыскать упоминание об ITIL, тогда надо понимать, что вам пытаются выдать желаемое за действительное." (с)
Кстати, господа - MS Excel абсолютно соответствует ITIL!
понедельник, 24 августа 2009 г.
Серьезно обновился Altiris Service Desk
Вот здесь пресс-релиз о выпуске новой версии Symantec (Altiris) Workflow 7.0 и ServiceDesk 7.0
Месяца два назад коллеги показывали бета-версии ServiceDesk 7.0, впечатления по сравнению с 6.0 положительные: добавлены slm, более строго разделены процессы. Плохо одно, каких-либо стратегических инноваций замечено не было - т.е. в бета-версии не заметил вещей, существующих только в Symantec\Altiris ServiceDesk 7.0. Подождем до официальной версии.
Что нового в комитете публикаций itSMF?
Мы с коллегами в прошлом году при комитете публикаций в itSMF собрали команду экспертов и сделали перевод глоссария ITILv3. Оценивать проект можно по разному. Качество перевода глоссария (на мой взгляд) все еще далеко от совершенства.
Однако, факт остается фактом: глоссарий признан itSMF официальным переводом на русский язык. Для повышения качества запустили сопровождение глоссария (и оно работает, скоро будет очередная версия с улучшениями).
В этом году бразды правления комитетом публикаций при itSMF взяла на себя Саша Сарычева. В планах значатся: перевод ISO2k, перевод ITILv3 (если будут найдены спонсоры), перевод интересных статей (первая русскоязычная статьи от ИТ-Скептика уже готова!), улучшение глоссария и еще много вкусного и интересного.
Вот, кто уже в команде. Не будет секретом, если поделюсь - нам нужны люди. Причем те, которые умеют и любят работать над интересными задачи без бюрократических проволочек. Можете организовать работу команды экспертов с тысячей мнений? Умеете написать или перевести статью в itsm-тематике или сопряженной? Есть в загашнике гениальная идея для itSMF RU, которую можете реализовать? Пишите Саше Сарычевой или мне.
А вот те, кто любит перекладывать бумаги и регламенты с места на место, или там долго-обстоятельно поговорить - не пишите. Кстати, защиту от бюрократии по традиции берет на себя руководитель комитета публикаций :)
четверг, 20 августа 2009 г.
Не могу молчать
Это было год назад. Шел не самый легкий, в достаточной мере интересный проект. И как-то вечером, читая материалы аудита - сделанный до нас, в 16 веке - натыкаюсь где-то на странице 150-той крутого трехсотстраничного отчета у коллег на редчайшей красоты фразу.
"Кроме того, вывод о том, что использование логистической модели будет существенно эффективнее, является только предположенияем, не подкрепленным расчетными данными. Данный прогноз может с равной степенью вероятности оказаться как верным, так и ошибочным." (с) Автор, к сожалению, неизвестен.
Грех это, товарищи, писать отчеты аудита по триста страниц.
Из дальних странствий
На пару месяцев активное пополнение блога было приостановлено. За это время был завершен наиболее странный из всех реализованных мною itsm-проектов, переосмыслено несколько старинных концепций, глобальным усилием воли удалось выкроить время для небольшого отпуска.
В ближайшее время ждите: свежие материалы, мысли, критику и переосмысление устаревших концепций.
вторник, 26 мая 2009 г.
Миграция с Service Desk
В сентябре 2008 года я уже писал о новом софте Omnitracker класса Service Desk, у которого есть полноценная миграция c HP Service Desk.
Не прошло и года, как мы сделали первый в России проект миграции HP Service Desk - OMNINET Omnitracker для компании "Альфастрахование". При этом не перенастраивая процессы, а просто перетащив логику и данные в новую систему. Русскоязычное описание программы миграции совершенно свободно можно скачать на сайте или взять у меня.
А вообще, абстрактно, программа "как бы" миграции HP с Service Desk на HP Service Manager для меня является удивительным парадоксом. Обещая миграцию, нужно обещать перенос структуры данных, экранных форм, процессной логики, ну и собственно данных. Практически все это перенести c HP SD на HP SM невозможно. А то, что возможно - крайне трудоемко. Я об этих маркетинговых околомиграциях еще обязательно напишу.
Подписаться на:
Сообщения (Atom)
