Очень внимательно по случаю перечитывал KCS (Knowledge-Centered Support). Рекомендации по организации процесса управления знаниями (knowledge management). С первого прочтения было ясно, что эту штуку неглупые люди писали.
Но местами они просто "молодцы-молодцы" (с). Я уже сто лет акцентирую внимание на осознанном выборе (технология проектирования) показателей процесса, от целей.
Верноориентированных целей. Ребята открывают и закрывают тему для управления знаниями буквально в паре абзацев:
Our first important concept distinguishes between activities and outcomes. If we put goals on leading indicators (activities), we will get what we ask for. Unfortunately, the activity by itself is not an indicator of value. For example, if we set a goal for each support analyst to create 10 solutions per month, we will get 10 solutions a month. However, if we are paying attention we will notice these solutions are often created on the last few days of the month and they contain little or no valuable information (things like “fixed the customer problem”). Goals on activities do not generate the desired outcome. In fact, in a knowledge management environment, goals based on activity will corrupt the knowledge base.
Что сказать? Неоднократно рекомендовал и буду рекомендовать для строящих процесс knowledge management разок глянуть в ITIL v3, а затем много раз смотреть в KCS, благо для частных интересующихся оно бесплатное и доступное. Спасибо Сергею Осадчему за нахождение и рекомендацию KCS пару лет назад, пользовал с тех пор неоднократно.
воскресенье, 5 сентября 2010 г.
Рекомендации по метрикам управления знаниями
суббота, 28 августа 2010 г.
Большая конференция ITSM, 8 сентября
Отложенная по причинам вулканического форс-мажора конференция все-таки неотвратимо приближается, планируемая дата 8 сентября 2010 года. Программа большая, много известных лиц, в том числе европейских itSMF-гостей.
Пойду ли я? Пойду. Ожидаю ли слишком много? Да нет, не ожидаю. На конференции будут два человека, которых лично мне ОЧЕНЬ интересно послушать (хорошо рассказывают, и говорят при этом незаезженные, разумные вещи) - это Евгений Аксенов (уже писал о нем здесь: http://itsmnotes.blogspot.com/2009/04/itsmf.html) и Александр Левинсон (аналогично http://itsmnotes.blogspot.com/2008/04/blog-post.html).
четверг, 26 августа 2010 г.
Горжусь орлами!
В этом году первый, и видимо, единственный раз вел подготовку к сертификации Service Manager v2. Для меня это был вызов и любопытная задача. Неделю назад приехали результаты - трое из четырех сертифицированы с первого раза, из 8 экзаменов (кто в курсе, там сдается два трехчасовых письменных экзамена) мои ребята сдали 7, что можно считать вполне неплохим результатом: 87,5% успешно сданных экзаменов с первого раза. Горжусь орлами, а себе ставлю галочку в зачетку.
Помню, как пару лет назад я сам сдавал экзамены Service Manager: нашей практике понадобился сертификат для подтверждения знаний и опыта - для формального участия в тендерах, для воздействия на окрепшие умы Заказчиков, и прочей внешней атрибутики. А на сертификат Service Manager v2 без обучения сдавать нельзя в принципе. Нужно идти учиться! Как бы подразумевалось, что есть возможность получить недостающие или типа "систематизировать имеющиеся" знания. Просто "систематизация" формулировка уж очень расхожая: часто слышу на тренингах, если больше сказать нечего. А в результате отлично (и, неожиданно для себя, с пользой!) провел две недели курсов: идеи о месте управления рисками как отдельном операционном процессе, забавные идеи к управлению изменениями и работами, все в общем, зародилось там - благо, что тренеры попались не просто молодцы, а "молодцы-молодцы": Роман Журавлев и Олег Скрынник.
среда, 18 августа 2010 г.
Сертификация v3, снова о печальном
Два месяца с момента публикации и месяц с моменты выкладки на сайте журнала прошли, выложили авторскую версию очередных заметок на полях ITILv3. Авторская версия статьи о сертификации на itsmforum-ru: Сертификация как фундамент ITIL, последние дни Помпей.
вторник, 17 августа 2010 г.
Ушел Хает, закончилась эпоха
Илья Хает больше не работает в HP - перешел в известную компанию-интегратор. Все, кто в курсе, что означают друг для друга бренды IH и HP - не просто удивились, а были сражены и поражены.
Для тех, кто не в теме - Илья Хает, бессменный (много-много лет) консультант и руководитель itsm-практики компании HP, неформально считается одним из лучших презентаторов в РФ. Навыки презентации и коммуникации отточены на таком глубоком уровне, что для удержания аудитории, обратной связи и прочего-прочего, чему бедные консультанты вынуждены учиться годами, Илье не приходится даже прилагать больших усилий. И если даже контекст выступления скучен (ну сколько можно про itsm-в-каждый-дом снова и снова?), я всегда с интересом слежу как Илья работает с аудиторией. Всегда есть, чему поучиться. И это только одна из мелочей.
Удачи!
Коллективно завидуем известной компании-интегратору. Коллективно же (не в первый раз) удивляемся процессам, происходящим в недрах компании HP.
ps. информация гуляет по рынку давно, но сейчас появилась в официальных источниках :) (itSMForum, список сервис-менеджеров)
воскресенье, 15 августа 2010 г.
Разговоры о каталогах (1)
Вот здесь начался разговор о каталогах. Начался он с того, что я посетовал - как много людей ищут примеры, вместо того, чтобы сесть и сделать. Были отзывы и обсуждения, понятно, что тема сейчас востребована. Мы с коллегами как-то считали внедренные процессы во всех проектах, и выходило, что два наиболее популярных - управление инцидентами (куда же без него) и каталог услуг как наиболее часто создаваемый артефакт (процесс актуализации к нему, чтобы там кто не говорил - обычно простейший).
Я, кстати, давно уже использую слово артефакт (приехало из родственных моделей) для обозначения совокупности баз управления, документов и объектов: план доступности, база конфигураций, модель ценообразования, методика управления рисками и т.д и т.п. Общо и просто.
Так вот, каталог услуг ИТ сейчас важнейший артефакт. Почему? Объясняю - технического уровня организации сервиса почти все наелись, внедрением самостоятельным или даже консультантским процессов управления заявками, запросами, инцидентами и прочим совершенно не удивишь - это уже становится настоящем коробкой. Такие уже сейчас клепают десятками, а через год-два-три каждый интегратор будет уметь делать это накопленным опытом и силами вчерашних студентов. Коробки с автоматизацией, правда, разные очень, но это не беда. А вот с тактическим уровнем организации сервиса (да той же поддержки) до сих пор беда: SLM в полноценном виде делают и, главное, хотят делать до сих пор не десятки, а единицы: результат интереснее, но и ответственность выше. Каталог же определенно хорош для старта, для создания базы, на которой можно легко достроить SLM, да и самим процессам поддержки каталог ИТ далеко лишним не будет.
Конкретизирует деятельность? Да. Отвечает на вопрос что мы делаем? Да. Позволяет привнести порядка в процесс заказа услуг ИТ? Да. Формулирует подходы к организации деятельности? Тоже возможно. В общем, благолепие и красота со всех сторон.
А вот что некрасиво - нередко консультанты продвигают заказчику в голову идеи о избранности, возвышенности и "серебряннопулейности" каталога услуг. Мол, если сделать (подмигивают: а дело это непростое, без внешней помощи не обойтись), тогда быстро наступит благорастворение воздусей и счастье всемирного единения заказчика (Бизнес) и подрядчика (ИТ). Да не наступит. И вообще, хватит сакральных таинственных знаний о неведомо чем - в большинстве случаев, говоря о каталоге услуг ИТ, мы банально ведем речь о классификаторе.
Давайте определимся для начала, бывает ли это не так.
Первый каталог услуг, который я увидел в своей жизни - принадлежал аутсорсинговой западной компании, материнские заказчики которой умеют строить в том числе и поезда.
Крупной компании - крупный каталог, страниц на пятьсот, с описаниями архитектуры услуг, схемами поддержки, с выдержками об условиях оказания, ценами на услуги, перечнем услуг, детально описанным уровнями сервиса и прочее, и прочее. Ого, подумал я тогда, в ITIL как-то все проще выглядело. Второй каталог, который я увидел, был тоненькой симпатичной книжицей страниц на десять, в которой был дан перечень услуг, ну и краткие описания. И все. ОГО, подумал я тогда, в ITIL как-то посложнее все выглядело. А третий каталог услуг мы уже сделали сами. И как вы догадались - это было нечто среднее между вариантами один и два.
Какие бывают каталоги?
1. Классификатор внешних услуг (вариант "меню блюд в ресторане"). Перечень услуг, которые продаются Заказчику с кратким описанием, может быть ссылками на соглашения.
Об этом варианте речь идет наиболее часто.
2. Классификатор внутренних и внешних услуг (вариант "рецептура блюд", но и меню тоже присутствует - либо в самом начале, либо в одном из приложений). Перечень внешних услуг, перечень внутренних услуг, архитектура, ответственные, схемы поддержки - тут уже наполненность выше, да и внутренних услуг обычно больше.
Примерно плюс-минус пятьдесят страниц об этом пишет ITILv3 - бизнес-каталог ("меню") дополнен технологическим каталогом ("составляющие блюд"), а там уже и до настоящей "рецептуры" недалеко.
3. Различные начинки к первым двух блюдам - в основном технологические (как построить? как сделать, чтобы не развалилось?), финансовые (как узнать стоимость? как продать?) ну и другие возможны.
И, в общем-то, на этом все. По сути дела - речь всегда идет о классификаторе той или иной степени дополненности околостоящим материалом. ВСЕ. Никаких сакральных знаний тут нет, и артефакт каталог услуг свое качество показывает банально на практике, все ли деятельности учли в каталоге? Построен ли он и автоматизирован настолько гибко, чтобы при изменении структуры услуг, его можно легко менять? Легко ли использовать для расчёта модели стоимости? И т.д. и т.п.
Я уже писал в комментариях к предыдущей заметке, что мне не очень интересно думать на тему - как сделать каталог услуг в конкретной ситуации для конкретных условий. Садись и делай - в любом случае получится более или менее удачно, следующий всяко уже удачнее будет, чем предыдущий. Более интересно понять, кто вообще может быть заинтересован в каталоге?
Давайте попробуем собрать все роли и варианты использования в список:
1. Кто: заказчик. Как: заказывает существующие услуги по классификатору с выбором параметров услуги: объем, качество, место.
2. Кто: заказчик. Как: формирует бюджет, в разрезе внутренних потребителей и классификатора.
3. Кто: подрядчик. Как: определяет, что заказано, а что нет конкретному пользователю вот этого заказчика в ходе поддержки услуг.
4. Кто: подрядчик. Как: классифицирует свою деятельность ИТ в ходе поддержки.
5. Кто: подрядчик. Как: определяет себестоимость услуг в разрезе классификатора.
6. Кто: пользователь. Как: никак, пользователю каталог услуг только мешает 8)
Какие из ключевых ролей и действий забыл?
Начало разговоров о каталогах.
Полезные ссылки:
Практический пример создания каталога услуг ИТ "своими руками" от itil-ist
Анатолий Левенчук о каталогизации вообще (кому интересно - ищите дальнейшие ссылки по ключевым словам в его ЖЖ)
суббота, 14 августа 2010 г.
Маленькая забавная книжка для процессников
Aris коммьюнити подбрасывает периодически интересные инструменты или материалы. А в этот раз небольшую книжку о том, как делать процессы более эффективными. Книжка доступна бесплатно (для этого нужно будет зарегистрироваться) вот по этой ссылке: http://www.softwareag.com/corporate/res/books/pi/default.asp
пятница, 13 августа 2010 г.
Сlaim management такой claim management..
Мы не рассматриваем претензии, высказанные по телефону, либо отправленные по электронной почте. Любая претензия должна быть оформлена в письменном виде и отправлена по адресу, указанному ниже.
(c) Официальный публичный документ одной авиакомпании.
Почему-то очень часто при разговорах со службами сервиса, поддержки компаний, которые считают своим долгом максимально огородиться от потребителя вот таким или подобным образом, возникают в голове бессмертные строки от Дугласа Адамса.
---
четверг, 29 июля 2010 г.
Сайт про аутсорсинг
Ребята из Naumen сделали вот такой сайт: smartsourcing.ru. Пока я там ничего супер-нового на обнаружил, но в закладки на всякий случай занес.
ps. кстати, заодно добавил личный блог Романа Чернина в перечень русскоязычных itsm-блогов.
воскресенье, 25 июля 2010 г.
Что такое хороший сервис?
Столетняя война красной, белой и еще тысячи оттенков роз еще не закончена. Мы так и не можем определить услугу (сервис) - работы это, результат ли, просто владение специфическими ИТ-рисками, или вообще сервиса нет с точки зрения планово-ремонтного подхода. А что от этого, по большому счету поменяется, кроме названий услуг в каталоге? Совершенно нормально в каждом конкретном проекте, а то и в каждом конкретном случае делать выбор в пользу того или иного варианта определения сервиса.
По случаю общался со службами поддержки дистрибьютора asus, хотлайном самого asus, а потом Microsoft. Майкрософты очень вежливые, ну прямо вот очень, до приторности. И процессы в наличии. Кстати, фио и номер мобильника как id внесли в свою внутреннюю базу - теперь меня будут узнавать. Но мы-то пессимисты, знаем: в общем, жду телефонного спама. Asus же, при всем уважении к ноутбукам (пользуюсь уже полгода и буду еще пару лет) - в части сервиса производит впечатление шараги, которая на пару лет открылась.
Но ни первые, по которым технологии ударили так сильно, что они пару слов вне техники и связать не могут; ни вторые, которые огородились барьерами от всех возможных нестандартных ситуаций и считают это хорошим сервисом; ни третьи, тренированно-вежливо улыбающиеся клиенту в телефон - никто не может сделать простой и единственно нужной вещи при оказании сервиса. Встать на сторону клиента. Всего лишь.
Хороший сервис есть умение понять задачу клиента. А оттуда и до решения уже недалеко. Владением рисками, результатом или работами? Потребителю, в общем-то, без разницы.
воскресенье, 4 июля 2010 г.
Срочно в номер!
На официальном сайте опубликованы критерии оценки соответствия ПО (ITIL Software Scheme Mandatory Assessment Criteria): качаем и читаем вот тут - http://www.itil-officialsite.com/News/ITIL_Software_Scheme_Mandatory_Assessment_Criteria.
пятница, 2 июля 2010 г.
Статья в Открытые системы №5 о сертификации версии три
Когда-то Олег Скрынник написал вот эту интересную статью - где, в частности, сравнил варианты прохождения экзаменов ITIL Expert.
По итогам сдачи ITIL Expert, и сообразно глобального пессимизма в сторону всеобщей коммерциализации ITIL и не только, я написал статью-ответ, статью-дополнение.
Читайте в Открытые системы №5, статья "Сертификация ITIL v3, есть ли свет в конце туннеля?"
Вчера я сдал экзамен на уровень ITIL v3 Expert. Это первый сертификат, который не принес мне абсолютно ничего полезного – ни новых знаний, ни возможности для очередной систематизации опыта. Только умение "натаскивания на правильные ответы". И статья Олега Скрынника ("Заветный сертификат ITIL Expert") явилась отправной точкой для изложения мыслей, которые зрели уже не один месяц.
...
Рассказываю по недавнему опыту, чем вынужден заниматься соискатель, который готовится сдавать экзамен ITIL Expert: на память рисовать порядка десятка концептуальных рисунков, на память знать порядка сорока определений, списков или просто некоторых отрывков из пятикнижия ITIL v3, полюбившихся по каким-то причинам разработчикам сертификации. Все остальное время он посвятит методологии натаскивания: будет просматривать предварительные варианты вопросов, пытаясь разобраться в логике ответов и формулируя для себя принципы "думай, как ITIL". Выброси два точно неподходящих вопроса, а дальше логически анализируй. Где же практика? А практика для формального подтверждения никому не интересна, парадокс.
Ну, как-то так. После выкладки онлайн-версии на сайте журнала авторская редакция будет доступна на itSMF, как обычно.
четверг, 1 июля 2010 г.
Как не стоит делать ITSM-проект, на примере.
Любые совпадения с реальностью случайны.
Случаются проекты удачные и неудачные. С точки зрения заказчика или консультанта. Бывают даже провальные. А бывают проекты, которые не стоит делать изначально - они обречены.
Тут можно написать, что эта история началась прекрасным декабрьским утром, для контраста. Не стану - был совершенно обычный день. Меня попросили посмотреть странный набор документации, на предмет подумать над возможной реализацией проекта. Мы там будем помощники субподрядчика у субподрядчика, ну не суть важно. Поинтересовался только, а что собственно делать? Помочь нужно, туманно ответил старший брат и наставник, у них там заказчики "хотят какого-нибудь процессника", чтобы красиво разговаривал с заказчиком и объяснял технологам, где что прибивать, как-то так. А процессы, кстати, уже разработаны и описаны, добавил старший брат. И улыбнулся. Вот тут я напрягся в первый раз. Ибо старший брат и наставник туманно разговаривать не любит и вообще .. так туманно на моей памяти говорил первый раз.
Тут нужно пояснить, что месяц назад я вылез из двух сложнейших, неформатных для нас сверхинтересных проектов, в которых опыта набрано было на ближайшие два года. И пребывал в таком расслабленно-исследовательском состоянии духа - ожидая с небес только интересных и новых задач.
Документы, документы. Какие-то странные описания пера Босха, с выдерганным цитатами явно напрямую из ITIL, с раздробленными не совпадающими процессными диаграммами, неотрецензированные. И, главное, странно знакомые куски текста. Что это? - жалобно вопросил я. О, сказал старший брат, именно так - ООО! И поднял указующий перст к небесам. Откуда это? Тут старший брат нахмурился - а это шаблоны процессные, спертые в компании DW лет десять назад. Но, видимо, творчески доработанные. Местами. Через месяц, просматривая интерфейсы, я загляну в часть не айтишных процессов. И ужаснусь.
Через два месяца я случайно прознаю, что пакет разработанных процессов, включая и вот эту макулатуру стоил заказчику в районе миллиона вечнозеленых листков.
Что в пресейле выигрыла компания, которое предложила самое недорогое технологическое решение. Истинно говорят - чаще всего заказной проект по-настоящему заваливается именно на стадии пресейла. И что у вендора свои методы зарабатывания на сопутствующих товарах, которые позволяют предложить решение практически за ноль копеек. Что в тендере участвовал старший брат как субподрядчик процессной части у двух разных компаний - вендоров. Смешно, сам был в такой ситуации - но здесь это было явный знак небес. В понедельник - с первым софтом, в среду - уже с другим софтом и другим вендором.
И главное. Что никто, абсолютно никто - ни подрядчик, ни заказчик, ни все субподрядчики еще не понимают, в какую полную, откровенную лужу дерьма мы вляпываемся в этом проекте.
[продолжение следует]
среда, 30 июня 2010 г.
Аудит ISO20000 по-настоящему, без прикрас
Вдруг кто пропустил - коллеги, связанные со стандартизацией и аудитом вот здесь отчаянно зажигают в комментариях. Очень жаль, что Олег Скрынник эту дискуссию прикрыл. По мне, так вполне интересно было, а главное - живо так. Именно в таких багровых тонах я себе и представляю настоящую секцию itSMF.
пятница, 25 июня 2010 г.
Сбербанк - отлично!
Просто невероятно, товарищи!
Ну правда, лет пять назад не ожидал такого увидеть в своей жизни в нашем Сбербанке. Рад, что не разучился удивляться!
О моделях, сообществах и коммерциализации
Абсолютно случайный разговор с коллегой-процессником, слушавшим курсы по "одной известной модельке процессной" (с) от Карнеги-Меллон. И в разговоре среди обсуждения моделей, наборов процессов, недоработок этих моделей и персоналий, любящих на это закрывать глаза всплывает тема коммерциализации и связанной с этим постепенной деградации модели.
И тут я залип в размышлениях. А почему, собственно, явное ухудшение самой модели ITIL v3 и опутывающих его процессов (сертификация софта, сертификация людей) я рассматриваю как случайность, как ошибку конкретного персонала itSMF, OGC, APMG? Возможно, это системный принцип. Пока некоммерческое сообщество (делающее модель, набор практик, проект стандарта) действительно не ставят перед собой вопросов получения прибыли - модель развивается. Но рано или поздно вопрос монетизации всплывает - и определенные люди уходят, приходят другие - они успешно справляются с задачей монетизации, но модель-то уже того. Начинает постепенно сползать в яму, а затем и в ямищу. Много и абстрактно-бесполезно думал. А вообще - очень красивая гипотеза.
ps. Может, у кого-то есть подтверждающие, обратные примеры на основе сообществ и моделей 5-15 летней давности?
среда, 2 июня 2010 г.
Ух ты, GM Автоваз внедрило HP Service Manager 7.11!
Вот здесь пресс-релиз. И это не шутки - Автоваз внедряет Service Manager 7.11. В заголовке миграция, и в тексте миграция (данных)! Наконец-то первая миграция данных с HPOVSD45 на HPSM71. Хотелось бы посмотреть на это внедрение в какой-либо конференции, и позадавать вопросы, чтобы уточнить объемы миграции. Ну и главное, как логику переносили, интересно.
четверг, 27 мая 2010 г.
Сколько процессов в ITILv3?
"Прекрасное" (с) от Олега Скрынника на старую хохму с количеством процессов в ITILv3.
Сколько процессов описано в ITIL v3?
A. 24
B. 26
C. 26 или 27
Правильный ответ читаем здесь!
Концептуально новая версия "Итилиум"
Ребята из команды "Итилиум" (к которой я уже несколько лет не имею никакого отношения, а когда-то имел и очень даже непосредственное) – выпустили новую версию "Итилиум 4". Дело обычное, версии каждый год выходят. Однако вот именно эта версии отличается двумя кардинально новыми вещами:
- собственно новая платформа разработки "1С:Предприятие 8.2", в которой на уровне движка заявлены во множестве поддержка оракла, кластера серверов приложений, линуксов, блэкджека и пр;
- заявлен полнофункциональный web-клиент, что впечатляет, ибо это было узким местом решения с самого начала разработки.
Надо бы посмотреть. Этакое "двадцать лет спустя".
среда, 26 мая 2010 г.
Русскоязычные блоги ITSM-тематики
1. Блог Руслана Акмеева ("Управление и контроль в ИТ", http://www.akmeev.ru/): если я ничего не путаю, первый блог* itsm-направления в рунете, рассказы о процессах, продуктах и проектах (реже) компании Microsoft;
2. Блог вашего покорного слуги т-ща Жилинского ("Записки ITSM-консультанта", http://itsmnotes.blogspot.com): заметки об itsm, по обыкновению пессимистичны;
3. Блог Сергея Конакова ("Процесс и результат", http://konakov.biz/news/ ), о процессах, иногда про ITIL;
4. Блог Владимира Бахметьева ("SCSM по-русски", http://blogs.technet.com/b/scsmru/), наш человек в Штатах пишет из самого сердца Microsoft о разработке MS Service Desk (точнее MS SCSM);
5. Блог Дениса Пашкова ("ИТ менеджмент по-другому", http://it-mg.blogspot.com/) пишет разное, в основном заметки о результатах размышлений в управлении ИТ;
6. Блог Андрея Косыгина ("Заметки начинающего ITSM практика", http://itil-ist.livejournal.com/), судя по описанию будет в основном о конкретном проекте, обещаются и переводы;
7. Целая россыпь блогов известнейших в ITSM личностей на одной площадке - Олег Скрынник, Роман Журавлев, Дмитрий Исайченко (отличное фото, Дима!) и Евгений Шилов ("Реальный ITSM", http://www.realitsm.ru/), писать только начали и, видимо, будут отчаянно жечь глаголом между рассказами.
8. Заметки об ITSM трех человек из Москвы, Киева и Мюнхена (http://www.bsmblog.com/), о продуктах, конференция и новостях ITSM.
9. Блог Романа Чернина, из компании Naumen (http://rchernin.livejournal.com/), о продуктах, itsm и аутсорсинге.
10. Блог Павла Солопова, активного популяризатора идей ITIL (http://pasol-711.livejournal.com/). Про ISO20000, размышления об ИТ, жизни и всем остальном. Вот здесь (http://it-managements.livejournal.com/) Павел и коллеги собирают новости и ссылки на статьи.
11. Коммьюнити ЖЖивой журнал (http://community.livejournal.com/itsm_ru/), открытое для чтения и подключения в писательство.
В блоге "ИТ с высоты птичьего полета", http://sorlik.blogspot.com/ Сергей Орлик пишет об архитектуре ИТ, иногда ITSM.
Иногда про ITSM пишут Максим Тарадин (http://maxtar.livejournal.com/), Илья Шутов (http://ishutov.blogspot.com/, он специализируется на средствах мониторинга), Георгий Ованесян (http://georgehoha.livejournal.com/) в личных блогах.
Сергей Гузик начал http://gsvcons.blogspot.com/ и, к сожалению, быстро забросил это нелегкое дело.
В сообществе http://smartsourcing.ru/ (http://smartsourcing.livejournal.com), посвященному аутсорсингу ИТ довольно часто обсуждается тематика ITSM.
Вроде бы все? Если кого-то забыл, коллеги - добавляйте в комментариях, я буду апдейтить именно эту запись.
---
* - именно блог, а не сайт - например, старый сайт Евгения Крылова, где он публиковал любопытные заметки.
