Итого, прочтен Real ITSM на русском. Чертовски очаровательное произведение сложного жанра сатиры ИТ. Кое-где хочется смеяться, кое-где скорее плакать навзрыд горючими слезьми, с тоской вспоминая действительность управления ИТ. Цитата книги: "аналогично внедрение ITIL, начиная со Стратегии сервисов может привести к непрерывному непрекращающемуся страданию".
Ну и еще несколько цитат навскидку:
"Другая лучшая стратегия – купить готовую CMDB. Разумеется, никто не может продать вам её. CMDB это абстрактное понятие, вроде святости или честности.
То, что нам пытаются всучить вендоры, это базы активов с прикрученными звоночками, или средства мониторинга сети со свистками, или средства управления дескстопами, на которые подвешены плюшевые игральные кости."
"Это как если бы пожарные сказали, что пожар пятой категории сложности они потушат за десять минут, а вот траву на пустыре будут тушить до завтра. Это трижды абсурдно: тушение пожара требует столько времени, сколько требует; большие пожары тушатся дольше; завтра утром трава, горящая на пустыре, уже не покажется такой уж незначительной."
В общем: читать, смеяться и плакать.
понедельник, 18 января 2010 г.
Real ITSM
Статья о выборе софта от Димы Исайченко и вопрос к читателям
Интересующимся вопросами сравнения и выбора ПО – читать вот эту статью от Дмитрия Исайченко. Кратко проанализировано 4 лидирующих софта: HP Service Manager, Axios Assyst, Omninet OmniTracker, BMC Remedy. Ответ на вопрос "что лучше?" автор хитроумно умалчивает, предлагая выбирать самим.
Подход, конечно, верный и политкорректный. Но хочется иногда и врезать правду-матку. Чтобы вендорам неповадно было петь только хвалебные песни, чтобы разработчики и продавцы научились более правильно оценивать творения своей компании.
В прошлом году я участвовал в проекте, где всё от начала до конца было сделано так плохо, как только можно себе представить – начиная как раз от выбора процессного инструмента. И еще тогда возникла мысль написать об этом проекте мини-мемуары, где изменить все имена и события, но оставить канву. Товарищи читатели (я знаю, чтобы вы есть) – было бы интересно читать о таком проекте? Или есть более важные темы для обсуждения? Вендору там пришлось несладко.
четверг, 14 января 2010 г.
Куча новостей itSMF Ru: перевод ISO 20000, скоро обновленный глоссарий и ITILv3!
Абсолютно бесплатно можно скачать проект перевода ISO 20000, адаптированный моими коллегами к суровой реальности общепринятой терминологии. Саше Сарычевой, Кириллу Иванову и Диме Салову - собственно, браво! По итогам этого дела немного обновился и сам глоссарий, свежая версия будет выложена ближайшее время.
И (барабанная дробь), бинго! Стартовал проект перевода ITILv3 на русский язык! О книге Service Strategy и общей реалистичности сроков позвольте скромно умолчать. Думаю, к концу года (оптимистично - к концу лета) у сообщества есть шансы потрогать первую напечатанную книжку.
Real ITSM хохмит теперь на русском
Коллеги из Cleverics (Роман Журавлев и Олег Скрынник) перевели вот такую смешную книжку от высокоскептичного товарища и брата нашего Роба Ингланда (aka IT Skeptic). В воскресенье перевод будет оценен. Содержание смешное, тем кто разбирается в темах - час веселья при чтении книги гарантирован.
среда, 13 января 2010 г.
Подведем итоги и планы (2009-2010)
С одной стороны, как-то не получается занести этот год в актив – из запланированного сделано было мало, поделиться удалось не всем, чего наработали. С другой стороны, наработано в консалтинговых проектах достаточно много интересного. Да и общественно-полезные проекты стартуют в ближайшие месяцы. Что радует.
TQM, TOC, LEAN. Снова окунулся в Project Management, задвинутый когда-то в угоду ITSM к задворкам сознания. Прочитано более 15 книг за год (треть из них полезны зело – очень неплохой показатель). Еще десяток книг уже ждут своего часа в 2readlist. Блог года – "Лабораторный журнал" от Анатолия Левенчука http://ailev.livejournal.com/, без сомнения (читается назад во времени взахлеб, когда есть возможность). Приятно осознавать, что разделяешь один временной промежуток с гением.
За прошлый 2009 в блог попало 48 записей, что ровно в 2,4 раза больше, чем в позапрошлый 2008. Планы на 2010 год не формулируются в количестве записей – надеюсь, этот блог станет более интересным, и треть содержания будет постепенно склоняться к очень практической направленности. Тренируемся в растягивании времени, запускаем совершенно новый проект под крылом itSMF Ru. Всех с праздниками, товарищи коллеги!
суббота, 19 декабря 2009 г.
Выбор системы автоматизации
Пару месяцев назад написал короткую заметку о принципах выбора системы автоматизации. На примере системы Service Desk, разумеется. Читать здесь: OmniWay.ru. Это, по сути, синопсис будущего цикла статей о выборе систем автоматизации вообще и Service Desk, в частности. Цикл запланирован на 2010 год. Там будет общая статья, поясняющая тему выбора и подходы. Будет статья с описанием методики выбора. Ну и конечно отдельно напишу завершающую цикл статью на конкретных примерах вендоров и самых распространенных в России систем (HP, Naumen, Itilium - берегись!). И о новых, наступающих. Так как последняя статьи будет ближе к концу 2010, решение от MS тоже имеет шансы туда попасть. Аминь. Главное, чтобы времени и сил хватило.
Очень часто меня упрекают: вот вы внедряете конкретную систему и ее, мол, активно пиарите. Чтобы не повторяться, запишу здесь - товарищи, никогда не путайте причину и следствие. Причина здесь в том, что OmniTracker была выбрана основным решением на основе тестирования нескольких лучших и опыта работы с лихим десятком систем. Причина в том, что OmniTracker наиболее хорошо подходит под нашу методику внедрения. А следствие уже рассказ про выбранную систему. Какая она чертовски гибкая и кастомизируемая на три девятки!
Кстати, про OmniTracker рассказывать очень тяжело. То, что у многих других - маркетинговое фуфло, в нем запросто реализуемая ценность. Ну кто тебе поверит в неограниченно создаваемые и настраиваемые объекты управления? Приходится молчать, давать слово заказчику. Или рисовать видео-уроки, типа "простой процесс за 2 минуты 46 секунд".
А вообще, нужно быть гибким и внедрять любые системы. Вот будет Service Desk от MS охрененным решением - обязательно включай его в свой каталог продуктов и "внедряй" (с).
четверг, 17 декабря 2009 г.
Переводы Голдратта
Кстати, вот здесь http://zhurnal.lib.ru/s/stepenko_a_o/ в свободном доступе несколько переводов Голдратта. Та самая цель, Теория ограничений, Синдром стога сена. Читать в обязательном порядке, начинать с "Та самая цель", потом "Синдром стога сена".
По случаю попалась в руки Цель-3 "Необходимо, но не достаточно", дочитываю.
Вспоминаю свои впечатления после первого прочтения Голдратта. Тоже было дело случая.
http://itsmnotes.blogspot.com/2008/03/blog-post.html
Не думал, что в жизни еще раз встретятся книги, хотя бы немного изменяющие мировоззрение целиком. Книги, полезные не только десятком строк из сотен страниц. Однако именно такая книги по случайному совпадению была прочитана в недавней командировке. Вообще не относящаяся к ИТ, слегка относящаяся к финансовому учету, и совсем немного относящаяся к консультированию, эти книги и теории в них заставила мысленно побегать "по потолку" пару дней. Это Элияху Голдратт, книга "Синдром иголки в стоге сена", а также "Цель. Процесс непрерывных улучшений", "Цель. Дело не в везении". Пока слишком ошеломлен, чтобы делать выводы, ищу другие книги того же автора
Игра в ассоциации
Последние две недели выдались такими, что вздохнуть некогда - не то что в блог писать. А написать о многом нужно - о проектном и процессном управление, практике использования bpmn 1.1 чуть-чуть, почти дописана обзорная статья по финансам ИТ, и пр. и пр.
А пока: результат игры в ассоциации. По одному из плакатов - не смог удержаться, ниже ассоциация на пословицу. Внедренцам софта hp и прочим понимающим ржать полчаса.
(с) Авторство известно, но не раскрываемо.
Что же это?!
понедельник, 7 декабря 2009 г.
Интересная цитата
"Чтобы не содержать дорогостоящих специалистов, занятых только обслуживанием инструментария Service Desk, и не обращаться к услугам внешних интеграторов, решено было внедрять коробочное решение" (с)
На этой цитате я пресс-релизом заинтересовался. Вообще редко кто понимает внедрять коробочное решение правильно: поэтому число провальных по срокам проектов внедрения SAP так велико. Стал читать дальше - еще круче, исполнительный директор оперирует понятиями ITIL, CMDB. Подумал было, что статью написал itil-падаван, ан нет - Алексей Артюхов со знанием дела и довольно интересно рассказывает о том, как внедряли различные IncM's в копейке, и не только для ИТ. Умудрившись при этом ни разу не упомянуть имя вендора!
А я упомяну. Axios софт очень специфический, на любителя. Именно что коробочный - используй, что дают и не лезь вправо-влево. Я этот софт лично смотрел на стенде - когда начинался наш внутренний мини-тендер на самого успешного заместителя HP Service Desk 4.5 для консалтинговых проектов. Приехавший консультант продал все так внятно и так грамотно, что я просто диву давался. Но первый же пяток сформулированных ключевых вопросов поддержке по итогам двухдневного тестирования показал - дело швах.
Ответ на четыре штуки - нет, на один - возможно, но очень дорого. Это для человека, нуждающегося в легкости и мощности кастомизации - было слишком. Да и вопросы были не очень сложные, признаться. На Axios была поставлена печать "жесткая коробка", и больше я его года полтора в глаза не видел.
А Копейка вон смотри-ка внедряет. Правда, совсем уж не обратиться к услугам внешних интеграторов - это отчасти, по-видимому, лукавство.
Сертификационная схема ITILv3 спроектирована
Не прошло и трёх лет, как APMG доработала сертификационную схему до (ранее неизвестного) уровня ITILv3 Master, который будет много круче красного ромба ITILv2. Вот здесь об этом официальная новость, а вот здесь перевод и неофициальный комментарий от Романа Журавлева.
Жаль, не успел поглумиться, коллеги опередили. Кратко, что этот диплом выделяет - неясно абсолютно. Пока есть ощущение, что защита реализованного проекта сложностью 100 и защита полувыдуманного проекта сложностью 0,1 одинаково зачтется к диплому. Нужно бы успеть сдать ITIL Bridge, чтобы застать все веселье в первых рядах.
пятница, 27 ноября 2009 г.
Работаем с метриками
В одном известной российском банке ввели систему измерения удовлетворенности пользователей услуг. Билет электронной очереди можно опустить при выходе в синюю коробочку (хорошо) или в красную (нехорошо). Коробочки я заметил не сразу, а только когда пристально вгляделся в текст на них.
Вроде разумно и просто?
Встретил уже двух кассиров, которые просят пользователей сдавать им билеты электронной очереди. Большинство пользователей, конечно же, сдают. Вопрос - что нужно поменять в системе сбора показателей, или в самих показателях, чтобы исключить ловкость рук кассиров-коллекционеров?
Оффтопик между строк
Из нерабочего: больше половины ноября съел какой-то вирус, подкравшийся незаметно. Полторы недели не читал почты, статей, ничего. Потом еще неделю отходил.
Поднимает настроение текущий проект - один из самых интересных за все время. Сформулированы уже две забавные системные задачи. И не факт, что они решаемы: тем интереснее!
Сменил рабочий ноутбук на asus ul50vg. Машинка на батарее выдерживает 8 часов, что прелестно. Обычно предпочитаю "предпоследнюю" версию Windows, но в связи с заменой ноутбука перешел на Windows 7 + Office 2007. На удивление просто. Две недели - полет нормальный!
четверг, 29 октября 2009 г.
И снова прекрасное
Идет семинар по некоей платформе, весьма отдаленно касающейся процессов поддержки. На этой платформе презентуется новейший workflow-продукт, позволяющий настроить гибкий процесс управления изменениями.
И тут неизвестный герой (НГ) поднимается с места и речёт сокровенным тоном. А знаете ли вы, заходит наш НГ издалека. Знаете ли вы, потрясает он перстами, что Управление Изменениями - всего лишь ЕДИНСТВЕННЫЙ процесс из 26 (двадцати шести), описанных в ITILv3.
В самом ITILv3, вы подумайте! 26 штук!
среда, 21 октября 2009 г.
Процесс Управления Работами (workorder management, task management)
Общение на форуме в очередной раз подтолкнуло к вопросу о процессе Управления Работами (нарядами, задачами, заданиями, операциями и т.д.). Наверное, он появился благодаря софтовым решениям класса Service Desk, где периодически вспыхивали процессы workorder management, task management, activity management. Там же он появился благодаря тем службам ИТ, которые нуждались в таком процессе. Мы его уже проектировали, внедряли - и каждый раз с новыми, отличными от предыдущих акцентами в процессе. Здесь - для одной цели, тут - для другой, а тут - просто чтобы прибить под управление инцидентами и управление изменениями.
Когда возникает необходимость в подобном процессе управления? Симптомы следующие: проблемы при оперативных координации работ для разных исполнителей в рамках одного запроса на обслуживание, инцидента или изменения. Необходимость получения отчетности выполненной работы в инцидентах, запросах на обслуживание, изменениях в разрезе исполнителей, рабочих групп, департаментов. Нужно учитывать и контролировать исполнение регламентных работ. Нужно учитывать ресурсы и рабочее время в разрезе типов выполняемой деятельности.
Похвастаюсь немного. Ну и публичное упоминание будет, для последующих патентов. Неделю назад мой коллега, Саша Цимбалистов выдвинул гениальную идею в части способа расчета и корректировки нормативов на выполняемые работы. Разговоры о нормах на выполнение работ возникают то тут, то там постоянно. Есть вопрос конечного заказчика - почему под эту работу отведено именно столько времени, нельзя ли быстрее? На этот вопрос едва ли ответит даже утвержденный ГОСТ\ТУ (которых нет с 98 года).Каждый, кто сталкивается, более или менее успешно старыми тропинками пытается разрешить вопрос с нормами. Увы, гораздо чаще - менее успешно.
А наша идея абсолютно новая (насколько мне известно, сейчас в ИТ по России никто так не делает, на Западе - судя по публикациям, тоже). Мы сейчас эту идею попробуем сразу практически реализовать в проекте. По результатам посмотрим.
ITIL ChangeLog
В связи с планируемым выходом новых редакций ITIL v3 (заметка-перевод "Не путайте версии с редакциями" от Романа Журавлева) актуальным становится официальный ChangeLog. Доступен вот здесь: http://www.best-management-practice.com/changeLog/ (открытый доступ, нужна регистрация).
Наиболее же известный неофициальный ErrorLog ведется на сайте ИТ скептика, BOKKED. Краткий свод наиболее критичных, интересных ошибок (26 штук) можно посмотреть в этой заметке.
понедельник, 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
