Записки ITSM консультанта

Рестарт

2011-12-24T19:24:00.001+04:00

Чтобы не возобновлять блог с 1 января нового года, оживлю его прямо сейчас.

За эти месяцы - организация аутсорсинга, удачные консалтинговые проекты на HP Service Manager (кто знает, тот присвистнет), Problem Advisory Board, построение системы Service Engine c нуля (helpdesk уже работает) и..

Несомненная жемчужина года - вчера команда в составе нескольких человек: 1. спроектировала и 2. сконфигурировала в автоматизированной системе процесс configuration management в стиле agile за 85 минут ровно. По-моему, это мировой рекорд.

Хороший пример lean

2011-04-24T21:00:00.001+04:00

Неплохая ссылка (просто, понятно) по lean, в стиле "делай раз, делай два", на примере. Пример очень тривиальный, и для интернет-разработчика, но сути дела не меняет.

Сложности организации систем метрик

2011-04-24T15:36:00.002+04:00

Написал о сложностях построения многоуровневых систем метрик. Необходимость в такой системе возникает обычно у крупных заказчиков: например, нужно сравнить эффективность вклада различных подразделений, направлений деятельности ИТ - в процесс.

(мой комментарий на исходные размышления Дмитрия Исайченко)

Навскидку вижу три сложности в такой системе.
Первое — она системно непрозрачна в силу расставления коэффициентов-весов (по опыту любая аналогичная система тяжело объясняется, тяжело запускается и легко оспаривается недовольными вовлеченными сторонами, что подменяет задачу на цифру и провоцирует большое количество ненужных споров вместо совместных усилий).
Второе — не определена цель функции. Помню на эту тему текст Романа Журавлева о функциях и процессах. Ок. Предположим, целью является предоставление качественных ресурсов для процессов. Но ведь это далеко не равнозначно качественному выполнению обязанностей функциональных ресурсов в процессах (что и меряют процессные метрики, разделенные по подразделениям).
И третье — а зачем, собственно, мерять вклад подразделения (функции, или любой другой непроцессной единицы в процесс)? К примеру, это противоречит тезисам Деминга. Я без робости вообще ко всем авторитетам, но здесь скорее придерживаюсь его мнения. Это система метрик в стиле «разделяй, оценивай и властвуй». И, особенно в наших условиях, будет поощрять политическую борьбу подразделений.

А вот полное обсуждение.

Несколько интересных обсуждений

2011-04-24T15:23:00.002+04:00

Так получилось, что за пару месяцев труднодоступности сервиса \blogspot.com "немного писал и немного читал" у коллег на realitsm, вот подборка интересных обсуждений:
- Дима очень четко и абсолютно правильно про обоснование проектов ITSM
я полностью согласен, могу только дополнить немного:
Чем дальше любые процессы (не только ИТ) от бизнеса (финансов), тем менее связаны любые действия по реорганизации с прибылью. И чем ближе процессы, тем проще связать их с прибылью, и соответственно, вменяемо финансово обосновать.
- коробочные решения в консалтинге (в обсуждении Дима Исайченко категоричен, Роман Журавлев системен, как обычно)
- процедура PIR в управлении изменениями (у меня достаточно отличный от itil'овских рекомендаций подход к PIR, в комментариях привел пару примеров)
- тема души сервисного подхода очень старая и заезженная (однако в комментариях таки появились интересные критерии сервисного подхода)

Несколько книг профессиональной литературы

2011-04-23T09:49:00.023+04:00

Мнения по книгам профессиональной литературы одной строкой. Не добавлял уже полгода, то есть фактически выборка понравившегося за 2009-2010 годы. Приведены в случайном порядке.

Итан Расиел "Метод McKinsey" - любой консультант обязан прочесть, к системному мышлению
Элияху Голдратт "Цель, процесс непрерывных улучшений", "Цель-2, дело не в везении", "Поиск иголки в стоге сена" - гениально
Эдуард Деминг "Выход из кризиса" – целая вселенная под боком. очень поздно прочитано, обязательно нужно было прочесть лет 15 назад
Гарри Нив "Организация как система" - полезно для тех, кто с трудом читает тексты самого Деминга, но разделяет идеи
Добровольский и компания "Бюджетирование шаг за шагом" - подробное практическое руководство по бюджетированию, но очень тяжело построен текст
Том Демарко "Deadline. Управление проектами" - восхительно легко о непопулярных темах в управлении проектами разработки ПО
Питер Брукс "Метрики для управления ИТ-услугами" - слабо, есть страниц 10 системного опыта (но хоть что-то)
Ицхак Азизес "На пути к расцвету" - о жизненном цикле организаций, наукоподобно, слабовато, в концовке книги (приложения) присутствуют свежие идеи
Элияху Голдратт "Критическая цепь" – отлично для интересующегося оптимизацией управления проектами в проектных компаниях
Итан Расиел, Пол Фрига "Инструменты McKinsey" - дополнение к Методу, больше воды, читать необязательно
Дэвид Майстер "Управление фирмой, оказывающей профессиональные услуги" - системно о внутренностях компаний, организованных на принципах партнерства (к концу текст хуже, так как книга собрана из статей)

Небольшой оффтопик

2011-04-22T18:38:00.003+04:00

Наконец-таки справился с "трудноформализуемыми проблемами доступа к движку блога", которые были последние месяца два. Последние пару месяцев я мог постить и читать блог только с 3g-модема. Баг на стороне google-провайдер отловлен: пришлось вспомнить молодость и подправить файлик hosts. Заодно сменил логотип в блоге.

За это время "немного писал и немного читал" у коллег на realitsm, так что сделаю на выходных сводку.

Пример концепции каталога бизнес-услуг

2011-04-22T11:25:00.004+04:00

Просто, доходчиво и тупо. На выходе с такой концепцией, кстати, получается достаточно сложный бизнес-каталог. Обладающий определенными минусами, кстати (о них как-нибудь потом).

Ситуация: потоки деятельности ИТ по обслуживанию потребностей бизнеса – сложные и часто пересекаются. Т.е. банально трудно выяснить, к какому направлению в бизнесе относится вот это конкретное действие в эксплуатации.

Каталог услуг должен позволять:
- описать всю деятельность по обслуживанию в терминах бизнеса;
- любую деятельность ИТ отнести к той или иной бизнес-услуге (направлению деятельности бизнеса);
- реализовать механизм для назначения и управления бизнес-приоритетами деятельностей.

Мой адрес - KZ

2011-04-04T20:38:00.000+04:00

Как-то не получается писать о текущих делах обычно. Кто-то в курсе, для кого-то новость: весной прошлого, 2010 года я покинул практику Inline Group и почти год посвятил фрилансу. Получилось интересно и неплохо: поучаствовал в 3 проектах и один проект сделал лично почти с нуля: для интереснейшего заказчика с интереснейшими результатами. Проведенных тренингов не считал. Надеюсь, мои заказчики и слушатели тоже довольны (особенно те слушатели, которые сертифицировались на красный значок it service manager). Многое переосмыслил, просматривая сделанные проекты.

А с марта нынешнего, 2011 года я живу и занимаюсь развитием консалтинга в Казахстане. Разумеется, мы будем делать лучшей командой лучшие проекты ИТ.

itSMF.kz будет жить вот здесь: http://www.itsmf.kz. Принципы itSMF-agile я описывал несколькими постами ниже. Прямо на интернет-форуме будем проектировать процессы с открытым кодом (itsm 2.0) и прочее интересное.

Каталоги услуг и систем

2011-03-27T17:53:00.000+04:00

Можете забрасывать меня камнями — но я не вижу для большинства организаций в РФ, находящихся на начальном уровне развития (читай базовые процессы — inc, req, chg), так вот — не вижу никакой проблемы в бизнес-каталоге ИТ-услуг, сформированном на основании систем ИТ. Гораздо больше проблем появляется, когда такой организации начинают «по книжке» в глотку запихивать каталог услуг ИТ, с девизом «авось, переварится».

Вперед, к вершинам

2011-02-13T15:57:00.000+03:00

Переход из года в год выдался на удивление - вздохнуть некогда, не то что в блог написать .

Статьи, новости и материалы последуют в ближайшее время.

Лучшая ссылка за это время: http://www.itskeptic.org/itil-configuration-guinea-pig-wanted. Если кратко, Скептик делает открытый проект на Configuration Management. Мне эта идея очень нравится, в немного другой реализации я ее задумал два месяца назад. Скоро на экранах.

Практика настоящего цикла Деминга-Шухарта (как посчитать SLA)

2010-12-20T11:08:00.002+03:00

Мой бывший коллега Саша Цимбалистов написал-таки отличную статью.

Я уже миллион раз слышал вопросы - а как рассчитать показатели SLA? Что делать с инцидентами, которые не укладываются в плановые сроки? А что будет, если мы больше половины инцидентов решать вовремя не будем?

Ответы на все эти вопросы ищите во второй части (статистический анализ инцидентов на реальных данных Service Desk). И это настоящая практика цикла Деминга-Шухарта, а не бла-бла о совершенствовании и девятишаговых процессах в пустоте. Краткий пересказ нужных разделов теории качества, чтобы не путаться в понятиях - в первой части. Кому нужен подробный, читайте библию теории качества (о картах Шухарта в основном) - о литературе я тоже писал.

ps. еще обязательно напишу об этом, со временем только туго пока.

myITSMF(2) меморандум для меня самого

2010-12-04T15:16:00.001+03:00

Начальный плач по поводу текущего состояния дел в российском itSMF смотреть здесь.

На мой взгляд, системная ошибка организации российского itSMF содержится как раз в правильном для ведения бизнес-проектов, но абсолютно не правильном для некоммерческих проектов подходе: СНАЧАЛА поднабьем ДЕНЕГ В БЮДЖЕТ, а уж ПОТОМ будем думать, как его поТРАТИТЬ - глядишь, и интересные люди подтянуться.

Отсюда - сначала взносы, потом стулья. Сначала ищем спонсоров, потом продумываем систему докладов. Сначала ищем денег на административную часть, потом делаем форум-угробище. Сначала нагоним аудиторию побольше и пошире (смотри пункт "спонсоры"), а потом будем думать, чем таким интересным повысить их лояльность к itSMF и заставить ходить на полуформальные мероприятия.

Нет, не так. То, что работает при организации разных элитных клубов ит-директоров, не будет работать здесь. Цели быстро и четко подменяются, только сказать это вслух никто не может.
itSMF с таким подходом никогда не станет тусовкой для обмена знаниями, никогда. Любая организация с таким подходом будет тусовкой для обмена связями. Тусовкой для окучивания вендоров. Как и любой клуб ит-директоров. Это совсем другое. Это нужно участникам сообщества? И не подумайте, что я против связей - полезная и нужная штука. Но еще раз: только ли это нужно участникам сообщества?

1. Моему itSMF наплевать на официальный статус.

Даже статус chapter не является целью - целью является организация удобной обстановки для обмена знаниями в узкоспециализированной теме. Официальный статус организации не является целью - цель все та же, изложена выше. Что нужно? Банально - известность для потенциальных участников, минимальная начинка в интернете и помещение для встреч.

2. Моему itSMF в первые пять лет наплевать на прибыль и вообще коммерческую составляющую.

Деньги, коммерческая составляющая сами по себе не нужны и даже вредны организации. Пример десятков людей вокруг меня показывает, что люди делают самые охренительные вещи в некоммерческих проектах. Да, эти проекты при успехе можно монетизировать, и это будут люди совсем другого толка (и их сразу нужно держать по возможности дальше от первых). Но первичен - инкубатор интересных проектов, а не коммерческая заинтересованность. Пусть из них без денег выживет один из ста, интересный участникам. Это лучше, чем искусственно вскормленный уродец, интересный спосорам.

3. Вся среда для моего itSMF будут делаться так, как она делается в маленьких, только образованных гибких и быстрых компаниях.

Сайт и форум? Быстро и просто на шаблонах. Комитеты и ответственность? К черту форально определенные структуры, живущие одинаково из года в год. Первичны только интересные участникам проекты и интересные участникам работы - а не структуры и не ответственные руководители. Не интересно участникам? К черту, даже если интересно рынку. Завоевывать аудиторию будем результатами.

Все это лежит и ждет своего часа.

Немного новых ссылок

2010-12-03T13:26:00.001+03:00

Во-первых, Павел Солопов уже давно завел блог - и я его уже давно включил в реестр ссылок, читать вот тут: http://pasol-711.livejournal.com/. Я так понимаю, там будет про ISO20000, размышления об ИТ, жизни и всем остальном.

Во-вторых, создано коммьюнити ЖЖивой журнал (вроде бы, открытое), куда сейчас в основном пишут ITSM-собратья из ИТ-эксперта. В читателях и писателях коммьюнити интересные люди. Я, например, с удовольствием прочел http://maximgrigoriev.livejournal.com/, а то Максим Григорьев (с его большими, интересными проектами) уж очень закрыт для публики. Кто знаком с моей позицией по Service Strategy - читайте для полноты "Полет на Луну на одной заправке (Часть 3)" от Максима, абсолютно зеркальное мнение! А вот тут просто зажигают, в комментариях к записи о принятии решений.

Добавил во-первых и во-вторых к реестру русскоязычных ITSM-блогов.

И в-третьих, наткнулся на сайт Евгения Калинина (митрич.ру), сайт будет очень интересен тем, кто интересуется аутсорсингом в средних и малых компаниях. Там кстати книжка с советами, куча вебинаров и семинаров по разным темам: от финансов в аутсорсинговой компании, выбора софта Service Desk, каталога услуг и просто создания с нуля аутсорсингового стартапа. Интересно, авто близок к практике и изъясняется простым понятным рабоче-крестьянским (одобряю и первое, и второе).

Первый ITIL Expert по основному пути сертификации

2010-11-30T09:30:00.001+03:00

Случилось! Последнюю фразу из зловещей статьи о сертификации, будущем крахе ITIL и проч. и проч. можно считать почти недействительной: "Насколько мне известно, в России людей, сдавших экзамен ITIL Expert напрямую, по основной схеме сертификации ITIL v3, пока нет вообще. Дождемся первых героев."

Антон Серов (Украина, правда) мужественно преодолел все невзгоды и сдал экзамен ITIL Expert через основной путь сертификации - по схеме Lifecycle. Наши поздравления первому герою!

Экзамены foundation на русском языке

2010-11-29T09:19:00.000+03:00

Новости комитета по переводам и публикациям itSMF: с декабря 2010 официально доступны экзамены ITIL Foundation v3 на русском языке.

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

А вот интересное: так как я лично некоторым образом имею отношение к комитету по переводам и публикациям того самого itSMF ru, то все замечания, комментарии и недовольства по переводу экзаменов можно обращать напрямую мне. А я постараюсь донести до кого следует.

Иллюстрация (no air management)

2010-11-19T21:40:00.000+03:00

Я бы нарисовал немного другую, но времени нужно много (ибо умею слабо). А вот Олег Скрынник сел и наваял.

Правильно развиваем софт Service Desk

2010-11-18T14:01:00.000+03:00

Вот, пожалуйста. Аналогичная идея нами обдумывалась еще в команде будущего Итилиума, но там пошли по другому пути: активно вкладывались в форум, привлекали туда комптетентных специалистов заказчика, что в конце концов привело к формированию закрытой группе на клиентском форуме, которые могут влиять на функционал будущих версий Service Desk.

OmniTracker сделал проще, но интереснее - всем заказчикам даются очки (points), пропорционально лицензионному набору, и дается доступ к списку планируемых к реализации изменений (RFC), а дальше можно проголосовать, за одно или несколько изменений. Так что все, у кого есть действующих контракт на поддержку - вперед. А вот здесь можно посмотреть roadmap OmniTracker: планы ближайшего развития. Меня лично больше всего интригует combined forms for windows and web client, вполне возможно это то, чего многие ждут с момента знакомства с этой системой.

Блог об ИТ в небольшой в неИТ компании

2010-11-05T23:08:00.000+03:00

Я начал читать, показалось сначала скучновато. Потом завлекся на фразу "Больший горизонт планирования (3-5 лет) в условиях российской действительности практически нецелесообразная штука" (одобряю). Потом последний пост показал, что все делается разумно, дешево и с прицелом на будущее. Это мне всегда нравилось.

Виктор Таланов, ИТ-руководитель, ведет блог в реальном времени http://smartsourcing.ru/blog/17.

В общем, кому интересно об ИТ в небольших компаниях - читаем на свой страх и риск. Кстати, ITSM там вовсе не гарантируется.

myITSMF (1)

2010-10-12T16:32:00.001+04:00

Пару недель назад состоялась встреча с Ильей Хаетом, он единственный кандидат на пост председателя itSMF Россия в будущем году. Я выкроил время и посидел на заседании. Илья формулировал свои взгляды (судя по бумажке - взгляды в правильную сторону, на мой вкус) остроумно и расплывчато отвечал на удобные, неудобные, а также просто непонятные вопросы. В общем, все как всегда. Бумажка и аудиозапись вот здесь, кому интересно.

Обычно я на аналогичных заседаниях itSMF пишу протоколы или разбираю накопившиеся административные дела. А в этот раз я сидел и размышлял. По-моему, itSMF Россия уже провалился. Из всех направлений деятельности толково реализовано одно - конференции. За пять-то лет. Для этого создавался itSMF?

Брошюр, практических статей, интересных профессионалам ITSM - нет.
Переводов книг ITIL - в ближайшее время не ждите.
Некоммерческих мини-проектов - 3,5 сделано за те же пять (5) лет. Негусто.
Большого проекта (перевод стандарта, книги, разработки каких-то общих для рынка методик, т.е. то, что я могу отнести к большим проектам) - 0 ровно.

Что ни говори, а у руля стоят Подрядчики и еще раз Подрядчики. Заказчикам неинтересно в массе своей. Тем, кому интересно - или некогда, или постепенно отходят от темы (уже не работают "в itsm-поле").

Игорь Баринов неоднократно вопрошал - как будем зарабатывать деньги? Я понимаю, вопрос серьезный (иначе оплачиваемые инициативы, да те же проекты просто не покатятся), но во-первых он является условием необходимым. А достаточным условием является ответ на вопрос "зачем". Зачем зарабатывать деньги?!

Я же, задавая вопросы Илье, неоднократно цитировал Георгия Ованесяна (Крок) - зачем мне или моим ребятам идти в itSMF?

Но особенности моего критически-позитивного мышления не дают успокоиться. И я-то знаю, каким должен быть myITSMF (гибким, маленьким, недорогим,креативным в первые 5 лет). Это нужно расписать, возможно пригодится прямо в ближайшее время.

Большая конференция ITSM, 8 сентября

2010-08-28T00:16:00.000+04:00

Отложенная по причинам вулканического форс-мажора конференция все-таки неотвратимо приближается, планируемая дата 8 сентября 2010 года. Программа большая, много известных лиц, в том числе европейских itSMF-гостей.

Пойду ли я? Пойду. Ожидаю ли слишком много? Да нет, не ожидаю. На конференции будут два человека, которых лично мне ОЧЕНЬ интересно послушать (хорошо рассказывают, и говорят при этом незаезженные, разумные вещи) - это Евгений Аксенов (уже писал о нем здесь: http://itsmnotes.blogspot.com/2009/04/itsmf.html) и Александр Левинсон (аналогично http://itsmnotes.blogspot.com/2008/04/blog-post.html).

Горжусь орлами!

2010-08-26T13:28:00.002+04:00

В этом году первый, и видимо, единственный раз вел подготовку к сертификации Service Manager v2. Для меня это был вызов и любопытная задача. Неделю назад приехали результаты - трое из четырех сертифицированы с первого раза, из 8 экзаменов (кто в курсе, там сдается два трехчасовых письменных экзамена) мои ребята сдали 7, что можно считать вполне неплохим результатом: 87,5% успешно сданных экзаменов с первого раза. Горжусь орлами, а себе ставлю галочку в зачетку.

Помню, как пару лет назад я сам сдавал экзамены Service Manager: нашей практике понадобился сертификат для подтверждения знаний и опыта - для формального участия в тендерах, для воздействия на окрепшие умы Заказчиков, и прочей внешней атрибутики. А на сертификат Service Manager v2 без обучения сдавать нельзя в принципе. Нужно идти учиться! Как бы подразумевалось, что есть возможность получить недостающие или типа "систематизировать имеющиеся" знания. Просто "систематизация" формулировка уж очень расхожая: часто слышу на тренингах, если больше сказать нечего. А в результате отлично (и, неожиданно для себя, с пользой!) провел две недели курсов: идеи о месте управления рисками как отдельном операционном процессе, забавные идеи к управлению изменениями и работами, все в общем, зародилось там - благо, что тренеры попались не просто молодцы, а "молодцы-молодцы": Роман Журавлев и Олег Скрынник.

Сертификация v3, снова о печальном

2010-08-18T23:14:00.000+04:00

Два месяца с момента публикации и месяц с моменты выкладки на сайте журнала прошли, выложили авторскую версию очередных заметок на полях ITILv3. Авторская версия статьи о сертификации на itsmforum-ru: Сертификация как фундамент ITIL, последние дни Помпей.

Ушел Хает, закончилась эпоха

2010-08-17T13:28:00.000+04:00

Илья Хает больше не работает в HP - перешел в известную компанию-интегратор. Все, кто в курсе, что означают друг для друга бренды IH и HP - не просто удивились, а были сражены и поражены.

Для тех, кто не в теме - Илья Хает, бессменный (много-много лет) консультант и руководитель itsm-практики компании HP, неформально считается одним из лучших презентаторов в РФ. Навыки презентации и коммуникации отточены на таком глубоком уровне, что для удержания аудитории, обратной связи и прочего-прочего, чему бедные консультанты вынуждены учиться годами, Илье не приходится даже прилагать больших усилий. И если даже контекст выступления скучен (ну сколько можно про itsm-в-каждый-дом снова и снова?), я всегда с интересом слежу как Илья работает с аудиторией. Всегда есть, чему поучиться. И это только одна из мелочей.

Удачи!

Коллективно завидуем известной компании-интегратору. Коллективно же (не в первый раз) удивляемся процессам, происходящим в недрах компании HP.

ps. информация гуляет по рынку давно, но сейчас появилась в официальных источниках :) (itSMForum, список сервис-менеджеров)

Разговоры о каталогах (1)

2010-08-15T00:35:00.013+04:00

Вот здесь начался разговор о каталогах. Начался он с того, что я посетовал - как много людей ищут примеры, вместо того, чтобы сесть и сделать. Были отзывы и обсуждения, понятно, что тема сейчас востребована. Мы с коллегами как-то считали внедренные процессы во всех проектах, и выходило, что два наиболее популярных - управление инцидентами (куда же без него) и каталог услуг как наиболее часто создаваемый артефакт (процесс актуализации к нему, чтобы там кто не говорил - обычно простейший).

Я, кстати, давно уже использую слово артефакт (приехало из родственных моделей) для обозначения совокупности баз управления, документов и объектов: план доступности, база конфигураций, модель ценообразования, методика управления рисками и т.д и т.п. Общо и просто.

Так вот, каталог услуг ИТ сейчас важнейший артефакт. Почему? Объясняю - технического уровня организации сервиса почти все наелись, внедрением самостоятельным или даже консультантским процессов управления заявками, запросами, инцидентами и прочим совершенно не удивишь - это уже становится настоящем коробкой. Такие уже сейчас клепают десятками, а через год-два-три каждый интегратор будет уметь делать это накопленным опытом и силами вчерашних студентов. Коробки с автоматизацией, правда, разные очень, но это не беда. А вот с тактическим уровнем организации сервиса (да той же поддержки) до сих пор беда: SLM в полноценном виде делают и, главное, хотят делать до сих пор не десятки, а единицы: результат интереснее, но и ответственность выше. Каталог же определенно хорош для старта, для создания базы, на которой можно легко достроить SLM, да и самим процессам поддержки каталог ИТ далеко лишним не будет.

Конкретизирует деятельность? Да. Отвечает на вопрос что мы делаем? Да. Позволяет привнести порядка в процесс заказа услуг ИТ? Да. Формулирует подходы к организации деятельности? Тоже возможно. В общем, благолепие и красота со всех сторон.

А вот что некрасиво - нередко консультанты продвигают заказчику в голову идеи о избранности, возвышенности и "серебряннопулейности" каталога услуг. Мол, если сделать (подмигивают: а дело это непростое, без внешней помощи не обойтись), тогда быстро наступит благорастворение воздусей и счастье всемирного единения заказчика (Бизнес) и подрядчика (ИТ). Да не наступит. И вообще, хватит сакральных таинственных знаний о неведомо чем - в большинстве случаев, говоря о каталоге услуг ИТ, мы банально ведем речь о классификаторе.
Давайте определимся для начала, бывает ли это не так.

Первый каталог услуг, который я увидел в своей жизни - принадлежал аутсорсинговой западной компании, материнские заказчики которой умеют строить в том числе и поезда.
Крупной компании - крупный каталог, страниц на пятьсот, с описаниями архитектуры услуг, схемами поддержки, с выдержками об условиях оказания, ценами на услуги, перечнем услуг, детально описанным уровнями сервиса и прочее, и прочее. Ого, подумал я тогда, в ITIL как-то все проще выглядело. Второй каталог, который я увидел, был тоненькой симпатичной книжицей страниц на десять, в которой был дан перечень услуг, ну и краткие описания. И все. ОГО, подумал я тогда, в ITIL как-то посложнее все выглядело. А третий каталог услуг мы уже сделали сами. И как вы догадались - это было нечто среднее между вариантами один и два.

Какие бывают каталоги?

1. Классификатор внешних услуг (вариант "меню блюд в ресторане"). Перечень услуг, которые продаются Заказчику с кратким описанием, может быть ссылками на соглашения.
Об этом варианте речь идет наиболее часто.
2. Классификатор внутренних и внешних услуг (вариант "рецептура блюд", но и меню тоже присутствует - либо в самом начале, либо в одном из приложений). Перечень внешних услуг, перечень внутренних услуг, архитектура, ответственные, схемы поддержки - тут уже наполненность выше, да и внутренних услуг обычно больше.
Примерно плюс-минус пятьдесят страниц об этом пишет ITILv3 - бизнес-каталог ("меню") дополнен технологическим каталогом ("составляющие блюд"), а там уже и до настоящей "рецептуры" недалеко.
3. Различные начинки к первым двух блюдам - в основном технологические (как построить? как сделать, чтобы не развалилось?), финансовые (как узнать стоимость? как продать?) ну и другие возможны.

И, в общем-то, на этом все. По сути дела - речь всегда идет о классификаторе той или иной степени дополненности околостоящим материалом. ВСЕ. Никаких сакральных знаний тут нет, и артефакт каталог услуг свое качество показывает банально на практике, все ли деятельности учли в каталоге? Построен ли он и автоматизирован настолько гибко, чтобы при изменении структуры услуг, его можно легко менять? Легко ли использовать для расчёта модели стоимости? И т.д. и т.п.

Я уже писал в комментариях к предыдущей заметке, что мне не очень интересно думать на тему - как сделать каталог услуг в конкретной ситуации для конкретных условий. Садись и делай - в любом случае получится более или менее удачно, следующий всяко уже удачнее будет, чем предыдущий. Более интересно понять, кто вообще может быть заинтересован в каталоге?

Давайте попробуем собрать все роли и варианты использования в список:

1. Кто: заказчик. Как: заказывает существующие услуги по классификатору с выбором параметров услуги: объем, качество, место.
2. Кто: заказчик. Как: формирует бюджет, в разрезе внутренних потребителей и классификатора.
3. Кто: подрядчик. Как: определяет, что заказано, а что нет конкретному пользователю вот этого заказчика в ходе поддержки услуг.
4. Кто: подрядчик. Как: классифицирует свою деятельность ИТ в ходе поддержки.
5. Кто: подрядчик. Как: определяет себестоимость услуг в разрезе классификатора.
6. Кто: пользователь. Как: никак, пользователю каталог услуг только мешает 8)

Какие из ключевых ролей и действий забыл?

Начало разговоров о каталогах.

Полезные ссылки:
Практический пример создания каталога услуг ИТ "своими руками" от itil-ist
Анатолий Левенчук о каталогизации вообще (кому интересно - ищите дальнейшие ссылки по ключевым словам в его ЖЖ)

Маленькая забавная книжка для процессников

2010-08-14T17:22:00.000+04:00

Aris коммьюнити подбрасывает периодически интересные инструменты или материалы. А в этот раз небольшую книжку о том, как делать процессы более эффективными. Книжка доступна бесплатно (для этого нужно будет зарегистрироваться) вот по этой ссылке: http://www.softwareag.com/corporate/res/books/pi/default.asp

Сlaim management такой claim management..

2010-08-13T16:08:00.002+04:00

Мы не рассматриваем претензии, высказанные по телефону, либо отправленные по электронной почте. Любая претензия должна быть оформлена в письменном виде и отправлена по адресу, указанному ниже.

(c) Официальный публичный документ одной авиакомпании.

Почему-то очень часто при разговорах со службами сервиса, поддержки компаний, которые считают своим долгом максимально огородиться от потребителя вот таким или подобным образом, возникают в голове бессмертные строки от Дугласа Адамса.

---

– Вы имели возможность подавать заявления и жалобы в надлежащее время.

– В надлежащее время? – возмутился Артур. – В надлежащее время?! Впервые я услышал об этом, когда пришел рабочий. Замечу: это было вчера. Я решил, что он пришел вымыть окна, а он сказал, что пришел снести мой дом. Но он не сразу мне так сказал, нет! Сперва он протер пару окон и содрал с меня пятерку. И только потом сказал.

– Однако, мистер Дент, маршрут был выставлен для всеобщего ознакомления в местном бюро планирования и висел там девять месяцев.

– Ага, как только я узнал, то сразу же помчался прямо в бюро. Это было вчера в полдень. Вы ведь не особенно утруждали себя предупреждениями? Я имею в виду: никому ни слова, ни одной душе, правда?

– Но маршрут был обнародован для…

– Обнародован? В конце концов мне пришлось спуститься в подвал, чтобы отыскать его!

– Верно, там у нас находится отдел информации.

– С фонариком!

– Наверное, света не было.

– И ступенек тоже!

– Но послушайте, вы ведь нашли план!

– Да, – сказал Артур, – нашел. На дне запертого шкафа в заколоченном туалете. А на двери табличка висела: «Осторожно, леопард!»

---

– Сейчас бесполезно прикидываться дурачками. Проекты трассы и планы взрывных работ были выставлены для всеобщего ознакомления в местном Отделе планирования на Альфе Центавра еще пятьдесят земных лет назад – достаточный срок, чтобы подать жалобу по надлежащим каналам.

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

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

– Что значит «не были на Альфе Центавра»? Помилуй Бог, туда всего-то четыре световых года, рукой подать! Если вы настолько не интересуетесь общественной жизнью, то это ваше личное дело!.. Включить подрывные лучи!

---

Сайт про аутсорсинг

2010-07-29T01:58:00.002+04:00

Ребята из Naumen сделали вот такой сайт: smartsourcing.ru. Пока я там ничего супер-нового на обнаружил, но в закладки на всякий случай занес.

ps. кстати, заодно добавил личный блог Романа Чернина в перечень русскоязычных itsm-блогов.

Что такое хороший сервис?

2010-07-25T16:09:00.000+04:00

Столетняя война красной, белой и еще тысячи оттенков роз еще не закончена. Мы так и не можем определить услугу (сервис) - работы это, результат ли, просто владение специфическими ИТ-рисками, или вообще сервиса нет с точки зрения планово-ремонтного подхода. А что от этого, по большому счету поменяется, кроме названий услуг в каталоге? Совершенно нормально в каждом конкретном проекте, а то и в каждом конкретном случае делать выбор в пользу того или иного варианта определения сервиса.

По случаю общался со службами поддержки дистрибьютора asus, хотлайном самого asus, а потом Microsoft. Майкрософты очень вежливые, ну прямо вот очень, до приторности. И процессы в наличии. Кстати, фио и номер мобильника как id внесли в свою внутреннюю базу - теперь меня будут узнавать. Но мы-то пессимисты, знаем: в общем, жду телефонного спама. Asus же, при всем уважении к ноутбукам (пользуюсь уже полгода и буду еще пару лет) - в части сервиса производит впечатление шараги, которая на пару лет открылась.

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

Хороший сервис есть умение понять задачу клиента. А оттуда и до решения уже недалеко. Владением рисками, результатом или работами? Потребителю, в общем-то, без разницы.

Срочно в номер!

2010-07-04T23:32:00.000+04:00

На официальном сайте опубликованы критерии оценки соответствия ПО (ITIL Software Scheme Mandatory Assessment Criteria): качаем и читаем вот тут - http://www.itil-officialsite.com/News/ITIL_Software_Scheme_Mandatory_Assessment_Criteria.

Статья в Открытые системы №5 о сертификации версии три

2010-07-02T00:56:00.001+04:00

Когда-то Олег Скрынник написал вот эту интересную статью - где, в частности, сравнил варианты прохождения экзаменов ITIL Expert.

По итогам сдачи ITIL Expert, и сообразно глобального пессимизма в сторону всеобщей коммерциализации ITIL и не только, я написал статью-ответ, статью-дополнение.

Читайте в Открытые системы №5, статья "Сертификация ITIL v3, есть ли свет в конце туннеля?"

Вчера я сдал экзамен на уровень ITIL v3 Expert. Это первый сертификат, который не принес мне абсолютно ничего полезного – ни новых знаний, ни возможности для очередной систематизации опыта. Только умение "натаскивания на правильные ответы". И статья Олега Скрынника ("Заветный сертификат ITIL Expert") явилась отправной точкой для изложения мыслей, которые зрели уже не один месяц.
...
Рассказываю по недавнему опыту, чем вынужден заниматься соискатель, который готовится сдавать экзамен ITIL Expert: на память рисовать порядка десятка концептуальных рисунков, на память знать порядка сорока определений, списков или просто некоторых отрывков из пятикнижия ITIL v3, полюбившихся по каким-то причинам разработчикам сертификации. Все остальное время он посвятит методологии натаскивания: будет просматривать предварительные варианты вопросов, пытаясь разобраться в логике ответов и формулируя для себя принципы "думай, как ITIL". Выброси два точно неподходящих вопроса, а дальше логически анализируй. Где же практика? А практика для формального подтверждения никому не интересна, парадокс.

Ну, как-то так. После выкладки онлайн-версии на сайте журнала авторская редакция будет доступна на itSMF, как обычно.

Как не стоит делать ITSM-проект, на примере.

2010-07-01T13:31:00.001+04:00

Безусловно, все события и персонажи в данном околохудожественном произведении вымышлены.
Любые совпадения с реальностью случайны.

Случаются проекты удачные и неудачные. С точки зрения заказчика или консультанта. Бывают даже провальные. А бывают проекты, которые не стоит делать изначально - они обречены.

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

Тут нужно пояснить, что месяц назад я вылез из двух сложнейших, неформатных для нас сверхинтересных проектов, в которых опыта набрано было на ближайшие два года. И пребывал в таком расслабленно-исследовательском состоянии духа - ожидая с небес только интересных и новых задач.

Документы, документы. Какие-то странные описания пера Босха, с выдерганным цитатами явно напрямую из ITIL, с раздробленными не совпадающими процессными диаграммами, неотрецензированные. И, главное, странно знакомые куски текста. Что это? - жалобно вопросил я. О, сказал старший брат, именно так - ООО! И поднял указующий перст к небесам. Откуда это? Тут старший брат нахмурился - а это шаблоны процессные, спертые в компании DW лет десять назад. Но, видимо, творчески доработанные. Местами. Через месяц, просматривая интерфейсы, я загляну в часть не айтишных процессов. И ужаснусь.

Через два месяца я случайно прознаю, что пакет разработанных процессов, включая и вот эту макулатуру стоил заказчику в районе миллиона вечнозеленых листков.

Что в пресейле выигрыла компания, которое предложила самое недорогое технологическое решение. Истинно говорят - чаще всего заказной проект по-настоящему заваливается именно на стадии пресейла. И что у вендора свои методы зарабатывания на сопутствующих товарах, которые позволяют предложить решение практически за ноль копеек. Что в тендере участвовал старший брат как субподрядчик процессной части у двух разных компаний - вендоров. Смешно, сам был в такой ситуации - но здесь это было явный знак небес. В понедельник - с первым софтом, в среду - уже с другим софтом и другим вендором.

И главное. Что никто, абсолютно никто - ни подрядчик, ни заказчик, ни все субподрядчики еще не понимают, в какую полную, откровенную лужу дерьма мы вляпываемся в этом проекте.

[продолжение следует]

Аудит ISO20000 по-настоящему, без прикрас

2010-06-30T16:46:00.000+04:00

Вдруг кто пропустил - коллеги, связанные со стандартизацией и аудитом вот здесь отчаянно зажигают в комментариях. Очень жаль, что Олег Скрынник эту дискуссию прикрыл. По мне, так вполне интересно было, а главное - живо так. Именно в таких багровых тонах я себе и представляю настоящую секцию itSMF.

Сбербанк - отлично!

2010-06-25T17:32:00.000+04:00

Просто невероятно, товарищи!

Вот такую картину я узрел на неделе в одном из филиалов Сбербанка. И совершенно не центральном. Что в сочетании с нормально работающей электронной очередью, вменяемым парнем-консультантом (в этом отделении), работающим интернет-клиентом (редко, но пользуюсь) переводит полезные изменения в Сбере из умозрительных в реальные.

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

О моделях, сообществах и коммерциализации

2010-06-25T17:23:00.000+04:00

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

И тут я залип в размышлениях. А почему, собственно, явное ухудшение самой модели ITIL v3 и опутывающих его процессов (сертификация софта, сертификация людей) я рассматриваю как случайность, как ошибку конкретного персонала itSMF, OGC, APMG? Возможно, это системный принцип. Пока некоммерческое сообщество (делающее модель, набор практик, проект стандарта) действительно не ставят перед собой вопросов получения прибыли - модель развивается. Но рано или поздно вопрос монетизации всплывает - и определенные люди уходят, приходят другие - они успешно справляются с задачей монетизации, но модель-то уже того. Начинает постепенно сползать в яму, а затем и в ямищу. Много и абстрактно-бесполезно думал. А вообще - очень красивая гипотеза.

ps. Может, у кого-то есть подтверждающие, обратные примеры на основе сообществ и моделей 5-15 летней давности?

Ух ты, GM Автоваз внедрило HP Service Manager 7.11!

2010-06-02T21:09:00.001+04:00

Вот здесь пресс-релиз. И это не шутки - Автоваз внедряет Service Manager 7.11. В заголовке миграция, и в тексте миграция (данных)! Наконец-то первая миграция данных с HPOVSD45 на HPSM71. Хотелось бы посмотреть на это внедрение в какой-либо конференции, и позадавать вопросы, чтобы уточнить объемы миграции. Ну и главное, как логику переносили, интересно.

Сколько процессов в ITILv3?

2010-05-27T22:50:00.000+04:00

"Прекрасное" (с) от Олега Скрынника на старую хохму с количеством процессов в ITILv3.

Сколько процессов описано в ITIL v3?
A. 24
B. 26
C. 26 или 27

Правильный ответ читаем здесь!

Концептуально новая версия "Итилиум"

2010-05-27T10:55:00.009+04:00

Ребята из команды "Итилиум" (к которой я уже несколько лет не имею никакого отношения, а когда-то имел и очень даже непосредственное) – выпустили новую версию "Итилиум 4". Дело обычное, версии каждый год выходят. Однако вот именно эта версии отличается двумя кардинально новыми вещами:
- собственно новая платформа разработки "1С:Предприятие 8.2", в которой на уровне движка заявлены во множестве поддержка оракла, кластера серверов приложений, линуксов, блэкджека и пр;
- заявлен полнофункциональный web-клиент, что впечатляет, ибо это было узким местом решения с самого начала разработки.

Надо бы посмотреть. Этакое "двадцать лет спустя".

Русскоязычные блоги ITSM-тематики

2010-05-26T23:35:00.010+04:00

Пора, что-ли, свести русскоязычные профессиональные блоги 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.

Вроде бы все? Если кого-то забыл, коллеги - добавляйте в комментариях, я буду апдейтить именно эту запись.

---
* - именно блог, а не сайт - например, старый сайт Евгения Крылова, где он публиковал любопытные заметки.

Новый блог itsm-тематики

2010-05-21T23:01:00.000+04:00

Совершенно случайно наткнулся на новый блог, посвященный ИТ-управлению: "ИТ-менеджмент по-другому". Ведет мой бывший коллега, Денис Пашков. А вот здесь он переводит заметочку Скептика (по этой заметке я, собственно, блог и нашел).

Удачи, Денис! Больше русскоязычных ресурсов itsm, хороших и разных.

ITIL Expert (bridge)

2010-05-20T21:28:00.004+04:00

Отмучался сегодня. Наконец-то. Ни удовольствия, ни новых знаний после сдачи – ничего.

Этот блог не должен содержать матерщины, но ей-богу, сегодня было наивысшее желание этот формат нарушить. Не экзамен, а просто страсти господни. О том, как я его сдавал – можно целую книгу написать. Не для слабонервных. Начать с того, что я его сдал не с первого раза. Начать с того, что это первый подобный экзамен лет за десять, который я сдал не с первого раза.

В вопросах ITIL Expert (bridge) проверяется буквальное знание текста книги (путем похожих и расплывчатых формулировок в ответах). Далеко за примерами ходить не нужно – дана картинка ITIL, и "бла-бла на три абзаца", как бы сценарий. Который обычно и читать-то не стоит, потому что ценной информации в нем ноль. Но иногда – случается информация! Бинго! И тут фокус: сценарий англоязычный, а положенные по регламенту дополнительные полчаса (под ненативных сертификуемых) вам скорее всего не дадут. Читайте-читайте. Ладно, проехали и это.

Ну кто мог додуматься до такого вопроса? Любые совпадения с действительностью просьба считать вымыслом автора. В картинке и бла-бла написано о Business Unit. А дальше – четыре варианта (фраза с перечислением типа "capabilities control, coordinate and deploy resources to create value"), и что наиболее к Business Unit подходит. И даже переводить бессмысленно. Потому что русского перевода ITIL нет, а если этот текст не впечатать в голову, хрен вспомнишь о чем там на странице 756, прелестного тома №Х написано. Иногда кажется, что разработчики сертификации держат нас за савантов.

Но обидно не это! Обидно другое. Я готовился целенаправленно, уже зная и предполагая такие подставы в половине, как минимум, вопросов. Так и вышло, кстати. С десяток вопросов был на определение, еще штук пять на определение с картинками, несколько на понимание новых терминов. И, вуаля, единственный в чистом виде практический вопрос. Единственный за весь менеджерский, между прочим экзамен! Один-единственный, для которого ни знания книги, ни умения "думать, как ITIL" не нужно. Единственный вопрос по операционному процессу, без всех этих стратегически-непрерывно улучшательных навесок. Один! Вопрос! И я его провалил, судя по всему.

Вот что обидно. Времени для единственного на весь экзамен практического вопроса, черт возьми, не хватило нормально подумать.

Как создать каталог ИТ услуг?

2010-05-06T21:05:00.001+04:00

Ненароком выдался свободный час – перечитал самые интересные статьи и заметки последнего месяца, проглядел форумы. И в очередной раз поразился типовому вопросу на форуме: "дали задание сделать каталог услуг, помогите создать". Обычно через пару строк (если будут общие ответы) следует замечание, что в РФ каталоги услуг и подходы к созданию являются закрытой информацией консалтинга. Закрытая-то она закрытая, но особенного толку от примеров каталогов не было и не будет никогда.

Это я усвоил много лет назад, участвуя в одном из первых проектов создания "истинного каталога услуг" (с SLA, блэкджеком и прочим финансово-сервисно-ориентированным добром). Максимум, что можно взять из реальных примеров – варианты подходов к созданию каталага. Но это вам объяснит на пальцах любой человек, который сделал хотя бы пару штук и питает склонность к системным обобщениям. Для этого пересматривать много брошюрок бизнес-каталогов и немного толстенных технологических каталогов не нужно. "Бери и делай", чего уж там вопросы на форуме задавать. Кто прочтет разделы ITIL о каталоге – аплодисменты. Ну, или на тренинг сходит. У кого есть возможность перелопатить с пару десятков интересных западных статей по каталогам – так вообще рай. Рано или поздно, кстати, интересующийся доберется путем святого гугла и до англоязычных примеров, благо их накидано. И с этой точки зрения, и с такой.

Для начала работы ответить нужно на несколько простых, но очень важных вопросов:
- Кто будет использовать каталог?
- Как он будет его пользовать? (пользователи – для наездов на ИТ; заказчики для того, чтобы грамотно резать косты; финансисты для того, чтобы классифицировать косты; ИТ - чтобы отбиваться от всех вышеперечисленных, etc)
- Что нужно сделать в каталоге, чтобы для вышеперечисленных "Кто" эти (варианты использования) "как" производилось наиболее легко и удобно?

ps. в процессе разработки следует помнить только об одном - серебрянной пули каталогизации пока что не изобрели.

Описание процесса

2010-04-22T21:38:00.003+04:00

По случаю наблюдал за работой одного талантливого менеджера процесса. Из описания процесса (35 страниц текста) он сделал для участников краткую рабочую инструкцию в стиле "Делай так" (3 слайда в презентации). При этом могу заметить, что описание процесса изначально не было чересчур подробным, усложненным или перенасыщенным. Ну, простенькое и доступное такое описание. Процесс разработан при активнейшем участии заказчика. Однако, что несмотря на два года работы процесса – прочесть полную актуальную версию документа осилили человек пять (из них три менеджера, один инженер службы качества и один аудитор).

Это подтолкнуло формулировать проблему, которая крутится на подсознании уже год или больше: ведь не читают же, НЕ ЧИТАЮТ – хоть что придумывай! Для кого разрабатывается описание процесса? Для участников? Как бы не так. Один из вариантов таков. Описание процесса – для менеджеров, или для интересующихся, которые хотят знать "почему именно так" (чаще всего с желанием это "почему" и "так" поменять, или системно развивать). Для всех прочих участников краткая методичка по эксплуатации конкретного процесса, излагающая войну, мир и поручика ржевского в трех слайдах.

Сертификация ITSM

2010-03-28T19:52:00.001+04:00

Очень подробная и с массой не описанных ранее нюансов обзорная статья от Романа Журавлева "Профессиональная сертификация ITSM. Взгляд изнутри".

Взгляд не то чтобы, совсем уж изнутри - у APMG взгляд более алчущий и капиталистический, как мне кажется. Это взгляд изнутри осведомленного тренинг-провайдера. Статья очень интересная и любопытная, рекомендую к прочтению.

"Второе впечатление от экзамена: несмотря на сценарии, проверяется по-прежнему буквальное знание книг. Более того, сценарий не всегда имеет значение для вопроса и ответа. Поскольку понимаешь это уже после того, как прочитал и перевел его, пользы от этого понимания - никакой, а раздражения по адресу авторов — выше всякой меры." (с)

CobiT v5

2010-03-24T18:12:00.000+03:00

Доступна ссылка с черновым проектом CobiT v5 (Design Paper Exposure Draft), читаем, критикуем - предлагаем.

Глубочайшая мысль

2010-03-17T19:05:00.001+03:00

Добавить к высеченной надписи на флип-чартах всех консультантов: "Усложнять просто, упрощать сложно".

ITIL, это по-нашему

2010-02-10T17:54:00.000+03:00

Максим Тарадин (aka maxtar) у себя в личном блоге популярно и весело излагает концепты ITIL. Аккуратно, по ссылке возможна не совсем нормативная лексика. Кого не пугает - читаем.

"Если немного воспарить в облаках и построить сферического коня в вакууме (чем периодически занимаются фантасты), то выявляется, что каждый человек должен заниматься тем, что ему нравиться и что у него хорошо получается, чтобы это было востребованным обществом, и при этом быть приветливым с коллегами, исполнительным и разбиваться в лепешку, но не подводить окружающих. На практике обезьянья натура лезет наружу и все становится значительно интереснее." (с)

Русскоязычный форум по OmniTracker

2010-02-09T22:25:00.001+03:00

Кто вдруг не знает о решении Service Desk OmniTracker, читать здесь или здесь. На текущий момент единственное решение на российском рынке, удовлетворяющее лично меня в части гибкости процессной автоматизации.

Запускаем русскоязычный форум OmniTracker. До нас был только англоязычный на форуме вендора, но и он только для клиентов. А наш будет а) русскоязычный б) для всех интересующихся. А так как поддерживать его будет самая крупная и компетентная в России команда (без лишней скромности, чего уж там), то искренне надеюсь - сей форум через пару лет превратится в мощный интересный ресурс. Интересующиеся - присоединяйтесь!

Кстати, в блоге скоро появятся ссылки на интересные технологические и процессные задачки, легко решаемые этим инструментом.

Старая тема (полезность и гарантия)

2010-02-09T22:14:00.000+03:00

Очередная попытка разобраться, добро или зло? Полезность или гарантия? Как измерить? Кто виноват, и что делать? На itsmwatch статья "How to Measure ITIL Service Utility and Warranty" от Hank Marquis. Статья рождает какие-то средневековые ассоциации о расчёте ангелов на квадратный нанометр кончика иглы.

Кому интересно о полезности и гарантии - уже писал и давал ссылку на русскоязычную статью, можно смотреть в поиск.

Real ITSM

2010-01-18T23:33:00.000+03:00

Итого, прочтен Real ITSM на русском. Чертовски очаровательное произведение сложного жанра сатиры ИТ. Кое-где хочется смеяться, кое-где скорее плакать навзрыд горючими слезьми, с тоской вспоминая действительность управления ИТ. Цитата книги: "аналогично внедрение ITIL, начиная со Стратегии сервисов может привести к непрерывному непрекращающемуся страданию".

Ну и еще несколько цитат навскидку:

"Другая лучшая стратегия – купить готовую CMDB. Разумеется, никто не может продать вам её. CMDB это абстрактное понятие, вроде святости или честности.
То, что нам пытаются всучить вендоры, это базы активов с прикрученными звоночками, или средства мониторинга сети со свистками, или средства управления дескстопами, на которые подвешены плюшевые игральные кости."

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

В общем: читать, смеяться и плакать.

Статья о выборе софта от Димы Исайченко и вопрос к читателям

2010-01-18T01:22:00.004+03:00

Интересующимся вопросами сравнения и выбора ПО – читать вот эту статью от Дмитрия Исайченко. Кратко проанализировано 4 лидирующих софта: HP Service Manager, Axios Assyst, Omninet OmniTracker, BMC Remedy. Ответ на вопрос "что лучше?" автор хитроумно умалчивает, предлагая выбирать самим.

Подход, конечно, верный и политкорректный. Но хочется иногда и врезать правду-матку. Чтобы вендорам неповадно было петь только хвалебные песни, чтобы разработчики и продавцы научились более правильно оценивать творения своей компании.

В прошлом году я участвовал в проекте, где всё от начала до конца было сделано так плохо, как только можно себе представить – начиная как раз от выбора процессного инструмента. И еще тогда возникла мысль написать об этом проекте мини-мемуары, где изменить все имена и события, но оставить канву. Товарищи читатели (я знаю, чтобы вы есть) – было бы интересно читать о таком проекте? Или есть более важные темы для обсуждения? Вендору там пришлось несладко.

Куча новостей itSMF Ru: перевод ISO 20000, скоро обновленный глоссарий и ITILv3!

2010-01-14T20:44:00.001+03:00

Абсолютно бесплатно можно скачать проект перевода ISO 20000, адаптированный моими коллегами к суровой реальности общепринятой терминологии. Саше Сарычевой, Кириллу Иванову и Диме Салову - собственно, браво! По итогам этого дела немного обновился и сам глоссарий, свежая версия будет выложена ближайшее время.

И (барабанная дробь), бинго! Стартовал проект перевода ITILv3 на русский язык! О книге Service Strategy и общей реалистичности сроков позвольте скромно умолчать. Думаю, к концу года (оптимистично - к концу лета) у сообщества есть шансы потрогать первую напечатанную книжку.

Real ITSM хохмит теперь на русском

2010-01-14T19:26:00.002+03:00

Коллеги из Cleverics (Роман Журавлев и Олег Скрынник) перевели вот такую смешную книжку от высокоскептичного товарища и брата нашего Роба Ингланда (aka IT Skeptic). В воскресенье перевод будет оценен. Содержание смешное, тем кто разбирается в темах - час веселья при чтении книги гарантирован.

Подведем итоги и планы (2009-2010)

2010-01-13T19:16:00.002+03:00

С одной стороны, как-то не получается занести этот год в актив – из запланированного сделано было мало, поделиться удалось не всем, чего наработали. С другой стороны, наработано в консалтинговых проектах достаточно много интересного. Да и общественно-полезные проекты стартуют в ближайшие месяцы. Что радует.

TQM, TOC, LEAN. Снова окунулся в Project Management, задвинутый когда-то в угоду ITSM к задворкам сознания. Прочитано более 15 книг за год (треть из них полезны зело – очень неплохой показатель). Еще десяток книг уже ждут своего часа в 2readlist. Блог года – "Лабораторный журнал" от Анатолия Левенчука http://ailev.livejournal.com/, без сомнения (читается назад во времени взахлеб, когда есть возможность). Приятно осознавать, что разделяешь один временной промежуток с гением.

За прошлый 2009 в блог попало 48 записей, что ровно в 2,4 раза больше, чем в позапрошлый 2008. Планы на 2010 год не формулируются в количестве записей – надеюсь, этот блог станет более интересным, и треть содержания будет постепенно склоняться к очень практической направленности. Тренируемся в растягивании времени, запускаем совершенно новый проект под крылом itSMF Ru. Всех с праздниками, товарищи коллеги!

Выбор системы автоматизации

2009-12-19T21:34:00.003+03:00

Пару месяцев назад написал короткую заметку о принципах выбора системы автоматизации. На примере системы Service Desk, разумеется. Читать здесь: OmniWay.ru. Это, по сути, синопсис будущего цикла статей о выборе систем автоматизации вообще и Service Desk, в частности. Цикл запланирован на 2010 год. Там будет общая статья, поясняющая тему выбора и подходы. Будет статья с описанием методики выбора. Ну и конечно отдельно напишу завершающую цикл статью на конкретных примерах вендоров и самых распространенных в России систем (HP, Naumen, Itilium - берегись!). И о новых, наступающих. Так как последняя статьи будет ближе к концу 2010, решение от MS тоже имеет шансы туда попасть. Аминь. Главное, чтобы времени и сил хватило.

Очень часто меня упрекают: вот вы внедряете конкретную систему и ее, мол, активно пиарите. Чтобы не повторяться, запишу здесь - товарищи, никогда не путайте причину и следствие. Причина здесь в том, что OmniTracker была выбрана основным решением на основе тестирования нескольких лучших и опыта работы с лихим десятком систем. Причина в том, что OmniTracker наиболее хорошо подходит под нашу методику внедрения. А следствие уже рассказ про выбранную систему. Какая она чертовски гибкая и кастомизируемая на три девятки!

Кстати, про OmniTracker рассказывать очень тяжело. То, что у многих других - маркетинговое фуфло, в нем запросто реализуемая ценность. Ну кто тебе поверит в неограниченно создаваемые и настраиваемые объекты управления? Приходится молчать, давать слово заказчику. Или рисовать видео-уроки, типа "простой процесс за 2 минуты 46 секунд".

А вообще, нужно быть гибким и внедрять любые системы. Вот будет Service Desk от MS охрененным решением - обязательно включай его в свой каталог продуктов и "внедряй" (с).

Переводы Голдратта

2009-12-17T08:20:00.001+03:00

Кстати, вот здесь http://zhurnal.lib.ru/s/stepenko_a_o/ в свободном доступе несколько переводов Голдратта. Та самая цель, Теория ограничений, Синдром стога сена. Читать в обязательном порядке, начинать с "Та самая цель", потом "Синдром стога сена".

По случаю попалась в руки Цель-3 "Необходимо, но не достаточно", дочитываю.

Вспоминаю свои впечатления после первого прочтения Голдратта. Тоже было дело случая.

http://itsmnotes.blogspot.com/2008/03/blog-post.html

Не думал, что в жизни еще раз встретятся книги, хотя бы немного изменяющие мировоззрение целиком. Книги, полезные не только десятком строк из сотен страниц. Однако именно такая книги по случайному совпадению была прочитана в недавней командировке. Вообще не относящаяся к ИТ, слегка относящаяся к финансовому учету, и совсем немного относящаяся к консультированию, эти книги и теории в них заставила мысленно побегать "по потолку" пару дней. Это Элияху Голдратт, книга "Синдром иголки в стоге сена", а также "Цель. Процесс непрерывных улучшений", "Цель. Дело не в везении". Пока слишком ошеломлен, чтобы делать выводы, ищу другие книги того же автора

Игра в ассоциации

2009-12-17T08:05:00.001+03:00

Последние две недели выдались такими, что вздохнуть некогда - не то что в блог писать. А написать о многом нужно - о проектном и процессном управление, практике использования bpmn 1.1 чуть-чуть, почти дописана обзорная статья по финансам ИТ, и пр. и пр.

А пока: результат игры в ассоциации. По одному из плакатов - не смог удержаться, ниже ассоциация на пословицу. Внедренцам софта hp и прочим понимающим ржать полчаса.

(с) Авторство известно, но не раскрываемо.

Что же это?!

Интересная цитата

2009-12-07T07:17:00.000+03:00

"Чтобы не содержать дорогостоящих специалистов, занятых только обслуживанием инструментария Service Desk, и не обращаться к услугам внешних интеграторов, решено было внедрять коробочное решение" (с)

На этой цитате я пресс-релизом заинтересовался. Вообще редко кто понимает внедрять коробочное решение правильно: поэтому число провальных по срокам проектов внедрения SAP так велико. Стал читать дальше - еще круче, исполнительный директор оперирует понятиями ITIL, CMDB. Подумал было, что статью написал itil-падаван, ан нет - Алексей Артюхов со знанием дела и довольно интересно рассказывает о том, как внедряли различные IncM's в копейке, и не только для ИТ. Умудрившись при этом ни разу не упомянуть имя вендора!

А я упомяну. Axios софт очень специфический, на любителя. Именно что коробочный - используй, что дают и не лезь вправо-влево. Я этот софт лично смотрел на стенде - когда начинался наш внутренний мини-тендер на самого успешного заместителя HP Service Desk 4.5 для консалтинговых проектов. Приехавший консультант продал все так внятно и так грамотно, что я просто диву давался. Но первый же пяток сформулированных ключевых вопросов поддержке по итогам двухдневного тестирования показал - дело швах.

Ответ на четыре штуки - нет, на один - возможно, но очень дорого. Это для человека, нуждающегося в легкости и мощности кастомизации - было слишком. Да и вопросы были не очень сложные, признаться. На Axios была поставлена печать "жесткая коробка", и больше я его года полтора в глаза не видел.

А Копейка вон смотри-ка внедряет. Правда, совсем уж не обратиться к услугам внешних интеграторов - это отчасти, по-видимому, лукавство.

Сертификационная схема ITILv3 спроектирована

2009-12-07T06:59:00.001+03:00

Не прошло и трёх лет, как APMG доработала сертификационную схему до (ранее неизвестного) уровня ITILv3 Master, который будет много круче красного ромба ITILv2. Вот здесь об этом официальная новость, а вот здесь перевод и неофициальный комментарий от Романа Журавлева.

Жаль, не успел поглумиться, коллеги опередили. Кратко, что этот диплом выделяет - неясно абсолютно. Пока есть ощущение, что защита реализованного проекта сложностью 100 и защита полувыдуманного проекта сложностью 0,1 одинаково зачтется к диплому. Нужно бы успеть сдать ITIL Bridge, чтобы застать все веселье в первых рядах.

Работаем с метриками

2009-11-27T19:53:00.000+03:00

В одном известной российском банке ввели систему измерения удовлетворенности пользователей услуг. Билет электронной очереди можно опустить при выходе в синюю коробочку (хорошо) или в красную (нехорошо). Коробочки я заметил не сразу, а только когда пристально вгляделся в текст на них.

Вроде разумно и просто?

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

Оффтопик между строк

2009-11-27T19:46:00.001+03:00

Из нерабочего: больше половины ноября съел какой-то вирус, подкравшийся незаметно. Полторы недели не читал почты, статей, ничего. Потом еще неделю отходил.

Поднимает настроение текущий проект - один из самых интересных за все время. Сформулированы уже две забавные системные задачи. И не факт, что они решаемы: тем интереснее!

Сменил рабочий ноутбук на asus ul50vg. Машинка на батарее выдерживает 8 часов, что прелестно. Обычно предпочитаю "предпоследнюю" версию Windows, но в связи с заменой ноутбука перешел на Windows 7 + Office 2007. На удивление просто. Две недели - полет нормальный!

И снова прекрасное

2009-10-29T18:58:00.001+03:00

Идет семинар по некоей платформе, весьма отдаленно касающейся процессов поддержки. На этой платформе презентуется новейший workflow-продукт, позволяющий настроить гибкий процесс управления изменениями.

И тут неизвестный герой (НГ) поднимается с места и речёт сокровенным тоном. А знаете ли вы, заходит наш НГ издалека. Знаете ли вы, потрясает он перстами, что Управление Изменениями - всего лишь ЕДИНСТВЕННЫЙ процесс из 26 (двадцати шести), описанных в ITILv3.

В самом ITILv3, вы подумайте! 26 штук!

Процесс Управления Работами (workorder management, task management)

2009-10-21T18:12:00.000+04:00

Общение на форуме в очередной раз подтолкнуло к вопросу о процессе Управления Работами (нарядами, задачами, заданиями, операциями и т.д.). Наверное, он появился благодаря софтовым решениям класса Service Desk, где периодически вспыхивали процессы workorder management, task management, activity management. Там же он появился благодаря тем службам ИТ, которые нуждались в таком процессе. Мы его уже проектировали, внедряли - и каждый раз с новыми, отличными от предыдущих акцентами в процессе. Здесь - для одной цели, тут - для другой, а тут - просто чтобы прибить под управление инцидентами и управление изменениями.

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

Похвастаюсь немного. Ну и публичное упоминание будет, для последующих патентов. Неделю назад мой коллега, Саша Цимбалистов выдвинул гениальную идею в части способа расчета и корректировки нормативов на выполняемые работы. Разговоры о нормах на выполнение работ возникают то тут, то там постоянно. Есть вопрос конечного заказчика - почему под эту работу отведено именно столько времени, нельзя ли быстрее? На этот вопрос едва ли ответит даже утвержденный ГОСТ\ТУ (которых нет с 98 года).Каждый, кто сталкивается, более или менее успешно старыми тропинками пытается разрешить вопрос с нормами. Увы, гораздо чаще - менее успешно.

А наша идея абсолютно новая (насколько мне известно, сейчас в ИТ по России никто так не делает, на Западе - судя по публикациям, тоже). Мы сейчас эту идею попробуем сразу практически реализовать в проекте. По результатам посмотрим.

ITIL ChangeLog

2009-10-21T17:35:00.001+04:00

В связи с планируемым выходом новых редакций ITIL v3 (заметка-перевод "Не путайте версии с редакциями" от Романа Журавлева) актуальным становится официальный ChangeLog. Доступен вот здесь: http://www.best-management-practice.com/changeLog/ (открытый доступ, нужна регистрация).

Наиболее же известный неофициальный ErrorLog ведется на сайте ИТ скептика, BOKKED. Краткий свод наиболее критичных, интересных ошибок (26 штук) можно посмотреть в этой заметке.

Библия качества процессного управления

2009-10-19T22:07:00.007+04:00

В процессе чтения.

Ну что сказать? Все на картинке.

Снова об ITILv3, функции и процессы

2009-10-12T20:03:00.002+04:00

Тут в комментариях Георгий просил еще статей из почившей серии ITEMS откомментировать. Комментирую. Лучшая статья: вот здесь Роман Журавлев рассуждает о понимании функций и процессов в ITIL v3. Кто интересуется темой и не читал - читать в обязательном порядке.

Самое важное:
- Процессы структурируют деятельность для достижения целей.
- Функции структурируют возможности и ресурсы для обеспечения работы процессов.

То есть, "Процессы направляют усилия к цели. Функции управляют возможностями" (с) Здесь подписываюсь, как под своим.

И еще, Роман отмечает: "Между прочим, с этой точки зрения возникают большие сомнения в процессной природе таких явлений, как управление доступом и управление событиями (которое в оригинале event management)". За управление доступом ручаться не готов, а вот Управление Событиями - это явно не есть процессная структура. Правда, я там дальше по толкованию не согласен, но суть вопроса Роман раскрыл очень четко. Пожалуй, статья о "Полезность и гарантия" от Олега плюс вот эта статья от Романа - лучшее, что было в ITEMS.

Остальные как-то полемического задора не вызывают. Скучноватые комментарии к ITIL, ах этот Портфель услуг это не совсем каталог услуг, ах процессом нужно управлять и это должен делать менеджер. Разве что еще статья "Переход на ITIL - это куда?" заслуживает поощрения за прекрасное полуцензурное название в стиле поручика Ржевского, ну и за эпиграф.

MS Service Desk == MS SCSM, есть русскоязычный блог по продукту!

2009-10-12T14:02:00.000+04:00

Полку Service Manager'ов прибыло - любим говорить мы о сертифицированных ITSM специалистах. Теперь можно и о ПО аналогичным образом. К известному HP Service Manager вскоре добавится MS SC Service Manager. Выпущена бета №2, и шансы на релиз-кандидат высоки, крайне высоки. А вот здесь доступен самый настоящий русскоязычный блог по MS SCSM от Владимира Бахметьева, program manager'а данного продукта!

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

2009-10-09T15:21:00.003+04:00

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

Осенью 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 прошу ответить на простой вопрос: параметры качества процессов управление инцидентами и проблемами, поддерживающих искомый сервис, это гарантия или не гарантия?

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

"Прекрасное" (с)

2009-10-06T20:35:00.001+04:00

Половина британских компаний считает, что использование рекомендаций ITIL не приносит конкурентных преимуществ. По данным Vanson Bourne, лишь четверть их ИТ-персонала проходила тренинги по какой-либо из версий ITIL. Главной причиной этого стало отсутствие очевидных бизнес-эффектов от подобных курсов повышения квалификации. Другим озвученным фактором является высокая стоимость обучения. С учетом нынешних бюджетных ограничений, он также играет важную роль. (с)

Прекрасное пришло вот отсюда: новость на osp.ru

Забудьте о KPI ! (часть 1, или простые ошибки)

2009-10-02T19:05:00.001+04:00

Забудьте о 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

Эксперимент - статья на блоге, онлайн

2009-10-02T18:56:00.008+04:00

В загашнике давно лежит структура и начало статьи о наболевшем - хорошие практики проектирования KPI (метрик, показателей эффективности, KGI и иже с ними). Тема старая и очень интересная. Есть мысли о том, чтобы сделать простую, работоспособную технологию проектирования KPI.

Увы, но статья эта пишется не в одиночку и делит мои временные ресурсы по остаточному принципу. То есть движения текста за полгода практически никакого. Было принято волевое решение: пишу статью на блоге онлайн, для чего будет заведен специальный тег "article-online" - которым можно будет отделить онлайн-статью от других записей. Ну, или несколько онлайн-статей в будущем, если эксперимент покажет себя успешно.

Поехали: Забудьте о KPI! Часть 1, или основные ошибки.

Что HP может рассказать о Lean-технологиях в ИТ?

2009-09-21T14:14:00.010+04:00

Без формата, товарищи, никуда. Все в мире имеет формат. Выступление HP о Lean-технологиях имеет жесткий формат. Текст моих личных отзывов тоже четко заформатирован: не могу материться. А иногда очень хочется, правда.

Искомый доклад HP вел Илья Хает. Для тех, кто не в курсе – Хает один из лучших презентаторов, по крайней мере в области ITSM точно. С ходу Илья продемонстрировал стандартный набор фирменных приемов: и аудиторию аккуратно держал, и обратную связь от аудитории зацепил в самом начале выступления, снискал множество дополнительных вопросов. Видимо поэтому Илью и попросили здесь выступить. Для тех, кто не понял – это я хвалю талант докладчика. Больше-то хвалить нечего, дальше только ругань.

Читать далее..

Отличный текст о Lean

2009-09-17T17:50:00.001+04:00

Бережливое производство не равно Lean production, от Елены Маркушевой. Ссылки по тексту читать в обязательном порядке - тем, кто не знаком.

Почему я пойду на конференцию itSMF?

2009-09-15T20:59:00.000+04:00

Вот на этой конференции, в пятницу 18 сентября Илья Хает обещается рассказать об опыте проектов с применением Lean IT (30-минутный доклад, "Об особенностях внедрения решений с использований методик ЛИН для ИТ").

Мне эта тема близка и любопытна настолько, что приду обязательно. И вопросы задам обязательно. В том числе и неудобные. Если будут.

Очередная ошибка в ITILv3

2009-08-27T18:42:00.005+04:00

Скептик неспешно читает ITILv3 Service Operation.

... и неожиданно обнаруживает, что в процедурах Управления Инцидентами нет сопоставления Услуги Инциденту. А значит, нет и сопоставления SLA. Интересно, а чего он ожидал?

Кто не верит - смотрите в процедуру 4.2.5.2 Incident logging (а потом все прочие) и попробуйте найти там явно упомянутое поле Service или SLA. Соответственно, никакого анализа воздействия на услугу в Управлении Инцидентами тоже провести не получится. Ну и Каталога Услуг, по-видимому, тоже нет.

Об управлении изменениями, релизами и модном нынче lean

2009-08-27T18:10:00.003+04:00

Зафиксировать ключевые принципы базового управления изменениями довольно-таки просто:
- все изменения регистрируются и оцениваются;
- не все изменения реализуются;
- все реализованные изменения проверяются.

Теперь о релизах. Тут сложнее и интереснее. В соответствие с одним из принципов lean (вытягивание) нам нужно серьезно менять подход к управлению релизами.

Стандартный процесс управления релизами обязательно будет накапливать некоторое буферное число изменения, подготовленных к запуску в промышленной эксплуатации. А это обычно означает, что некоторую часть времени изменение будет лежать на полочке, красиво упакованное и подготовленное для внедрения. Но не внедряемое. Почему? Обычно потому что в регламенте устранения релизами кто-то когда-то записал: периодичность полного релиза для систем типа Х-Альфа не более 6 раз в год. Точка.

Надеюсь, получится исследовать данный вопрос.

Следующая статья для перевода

2009-08-26T15:41:00.004+04:00

На сайт itSMF до 23 августа можно было выбрать следующую статью, которая будет переведена на русский язык. На выбор предлагалось:
- распространение практики Service Desk на все запросы компании;
- опыт внедрения SLM;
- семишаговый совет о внедрение ITSM.

Любопытно. Посмотрим на статистику интересующихся в русскоязычном сегменте.

Заметка Ильи Шутова о мониторинге

2009-08-25T15:00:00.003+04:00

Интересная короткая заметка о "системах мониторинга ИТ" в формате вопрос-ответ, за авторством Ильи Шутова (из его блога). Неплохо, а местами прекрасно!

"4. Необходимо, чтобы решение осуществляло мониторинг приложения X. Ваше умеет?
Когда речь идет о мониторинге приложений, сразу возникает несколько десятков альтернатив. Что значит, осуществлять мониторинг? Следить за лог-файлами? Следить за состоянием процессов? Получать сообщения? Осуществлять проактивный мониторинг с помощью тестовых функций? Проверять выполнение бизнес-логики? Отслеживать утечки памяти?" (с)

Кстати, применимо не только к мониторингу. Сколько раз уже сталкивался с завороженностью заказчика словом "интеграция", в общем смысле, без какой-либо конкретизации.

Роб Ингланд препарирует "соответствие ITIL"

2009-08-25T13:00:00.004+04:00

На itSMF переведена статья ИТ-скептика, повествующая о нелегкой доле поставщиков ПО ITSM, вынужденных ставить ярлыки соответствует ITIL на что угодно - хоть на стикеры.

Роб Ингланд в обычной, полусаркаcтической манере формирует ряд вопросов к понятию соответствия ITIL. Например, вопрос №9:

"Поддерживает ли инструмент работу с процессами (workflow)? Довольно странно, если в процессно-ориентированном инструменте этого нет. Входят ли в «коробочный» вариант продукта стандартные процессы ITIL, описанные в красной и синей книгах? Например, поддерживает ли он ветвление процесса для важных и незначительных изменений? А для запросов и инцидентов? Каким образом обосновывается в документации внедрение продукта для поддержки процессов в соответствии с ITIL? Подавляющее большинство крупных поставщиков предлагают внедрять продукт, используя практики ITIL. Проверьте, есть ли расхождения между продуктом и документацией. Если в документации с трудом можно отыскать упоминание об ITIL, тогда надо понимать, что вам пытаются выдать желаемое за действительное." (с)

Кстати, господа - MS Excel абсолютно соответствует ITIL!

Серьезно обновился Altiris Service Desk

2009-08-24T18:23:00.003+04:00

Вот здесь пресс-релиз о выпуске новой версии Symantec (Altiris) Workflow 7.0 и ServiceDesk 7.0

Месяца два назад коллеги показывали бета-версии ServiceDesk 7.0, впечатления по сравнению с 6.0 положительные: добавлены slm, более строго разделены процессы. Плохо одно, каких-либо стратегических инноваций замечено не было - т.е. в бета-версии не заметил вещей, существующих только в Symantec\Altiris ServiceDesk 7.0. Подождем до официальной версии.

Что нового в комитете публикаций itSMF?

2009-08-24T17:37:00.003+04:00

Мы с коллегами в прошлом году при комитете публикаций в itSMF собрали команду экспертов и сделали перевод глоссария ITILv3. Оценивать проект можно по разному. Качество перевода глоссария (на мой взгляд) все еще далеко от совершенства.

Однако, факт остается фактом: глоссарий признан itSMF официальным переводом на русский язык. Для повышения качества запустили сопровождение глоссария (и оно работает, скоро будет очередная версия с улучшениями).

В этом году бразды правления комитетом публикаций при itSMF взяла на себя Саша Сарычева. В планах значатся: перевод ISO2k, перевод ITILv3 (если будут найдены спонсоры), перевод интересных статей (первая русскоязычная статьи от ИТ-Скептика уже готова!), улучшение глоссария и еще много вкусного и интересного.

Вот, кто уже в команде. Не будет секретом, если поделюсь - нам нужны люди. Причем те, которые умеют и любят работать над интересными задачи без бюрократических проволочек. Можете организовать работу команды экспертов с тысячей мнений? Умеете написать или перевести статью в itsm-тематике или сопряженной? Есть в загашнике гениальная идея для itSMF RU, которую можете реализовать? Пишите Саше Сарычевой или мне.

А вот те, кто любит перекладывать бумаги и регламенты с места на место, или там долго-обстоятельно поговорить - не пишите. Кстати, защиту от бюрократии по традиции берет на себя руководитель комитета публикаций :)

Не могу молчать

2009-08-20T19:17:00.005+04:00

Это было год назад. Шел не самый легкий, в достаточной мере интересный проект. И как-то вечером, читая материалы аудита - сделанный до нас, в 16 веке - натыкаюсь где-то на странице 150-той крутого трехсотстраничного отчета у коллег на редчайшей красоты фразу.

"Кроме того, вывод о том, что использование логистической модели будет существенно эффективнее, является только предположенияем, не подкрепленным расчетными данными. Данный прогноз может с равной степенью вероятности оказаться как верным, так и ошибочным." (с) Автор, к сожалению, неизвестен.

Грех это, товарищи, писать отчеты аудита по триста страниц.

Из дальних странствий

2009-08-20T19:10:00.004+04:00

На пару месяцев активное пополнение блога было приостановлено. За это время был завершен наиболее странный из всех реализованных мною itsm-проектов, переосмыслено несколько старинных концепций, глобальным усилием воли удалось выкроить время для небольшого отпуска.

В ближайшее время ждите: свежие материалы, мысли, критику и переосмысление устаревших концепций.

Миграция с Service Desk

2009-05-26T17:40:00.005+04:00

В сентябре 2008 года я уже писал о новом софте Omnitracker класса Service Desk, у которого есть полноценная миграция c HP Service Desk.

Не прошло и года, как мы сделали первый в России проект миграции HP Service Desk - OMNINET Omnitracker для компании "Альфастрахование". При этом не перенастраивая процессы, а просто перетащив логику и данные в новую систему. Русскоязычное описание программы миграции совершенно свободно можно скачать на сайте или взять у меня.

А вообще, абстрактно, программа "как бы" миграции HP с Service Desk на HP Service Manager для меня является удивительным парадоксом. Обещая миграцию, нужно обещать перенос структуры данных, экранных форм, процессной логики, ну и собственно данных. Практически все это перенести c HP SD на HP SM невозможно. А то, что возможно - крайне трудоемко. Я об этих маркетинговых околомиграциях еще обязательно напишу.

Свершилось! Работает сертификация ITIL Process Compliant.

2009-05-22T14:58:00.005+04:00

Итак, долгожданное и обещанное когда-то архитектором ITILv3 Шарон Тейлор событие произошло. Выдан первый сертификат "ITIL Process Compliant", который получила компания BMC Software. Подробности в пресс-релизе по ссылке.

Оговорюсь сразу, что я:
1) В принципе, СЧИТАЮ программу сертификации на соответствие позитивным явлением.
2) СЧИТАЮ Remedy одним из лучших софтов на рынке.
3) НЕ СЧИТАЮ, что ITILv3 проработан в части требований к процессному ПО настолько хорошо, чтобы быть основанием для сертификации.
4) НЕ СЧИТАЮ, что дело компании-разработчика рекомендаций (методик, стандартов) затевать коммерческое использование программы сертификации на соответствие.

Внимание, вопрос раз - сколько заплатило Remedy за сертификацию? Внимание, вопрос два - где доступная, подробно расписанная методика тестирования? Ну что за прошлый век, секретная методика тестирования ПО на соответствие.. Внимание, вопрос три - где подробнейшие результаты тестирования Remedy? В сухом остатке мы имеем непрозрачный процесс тестирования на соответствие и результат "соответствует". Как известно, дьявол в нюансах.

Для внимательных читателей обращусь к тексту пресс-релиза. Пропустив за ненадобностью фанфары в честь Remedy "В нынешней экономической среде, ITIL процессы и решения Business Service Managements управление бизнес-услугами, такие как решения BMC, являются главным приоритетом для бизнеса."(с)Шарон Тейлор Давайте посмотрив концовку пресс-релиза. ОГО! "Для получения этого престижного звания «ITIL® Process Compliant», BMC Remedy IT Service Management Suite удачно прошла тщательное тестирование на соответствие ITIL стандартам в сферах Управления Инцидентами и Управления Проблемами."(с)

Просто феерически! Несомненно, ключевая потребность бизнеса - это управление инцидентами и проблемами. Когда-то я уже писал, почему не стоит слепо доверять даже четко прописанным требованиям ITILv3. Да потому, что текст Service Operation построен студенческим приемом copy-paste.

Схема процессов ITIL v3

2009-05-22T14:15:00.003+04:00

Нашлась общая схема процессов ITIL v3. Особую задумчивость вызывает связка [Управление событиями] -> [Управление инцидентами] -> [Управление запросами на обслуживание]. Подойдет для тех, кто желает более четко вникнуть в SLP, SDP и прочие нюансы не самой простой (скажем честно) процессной модели ITIL v3.

Книга об управлении проектами

2009-05-22T14:10:00.005+04:00

Читаю книгу Тома Демарко "Deadline. Роман об управлении проектами". Резюме: увлекательная художественная форме о сути базовых понятий управления проектами разработки ПО. Весело, местами смешно, довольно смело.

О разумности использования матаппарата

2009-05-18T17:40:00.003+04:00

Редчайшая по качеству цитата из книги Генри Нива "Организация как система" (книга о системе качества доктора Деминга).

"Проблема заключается в том, что, как правило, возможность разработки сложной математической аргументации связана с необходимостью введения исходных предположений, чрезмерно идеализированных с точки зрения реального мира" (с)

В цитате речь идет о контрольных картах (Шухарта). Я бы обобщил: чрезмерная математическая подпитка системы управления любыми мягкими (soft) элементами - это очень частая ошибка. Не стоит ради красоты решения вносить в систему множество ненужных идеализированных допущений.

Плохая статья

2009-05-14T22:42:00.002+04:00

Попадаются же статьи, в которых неправильно почти все. Обычно это обзорная статья, написанная по заданию, на злобу дня, на коленке или по советам более сведущих коллег. Ниже последний пример.

Ладно с ней, с этим истрепанным словом методология применительно к ITIL, или выражением внедрение библиотеки ITIL. Припоминаю, когда-то коллеги четко подметили, что внедрить библиотеку ITIL проще простого – нужно купить библиотеку и поставить на полку.

Дальше пару моих комментариев.

Таким образом, финансовый директор, настоявший на внедрении данной методологии [автор имеет ввиду ITIL], убивает сразу двух зайцев – экономит, не теряя при этом в качестве предоставляемых организации IT-услуг.

Так не бывает. Сэкономить, не теряя при этом в качестве всех услуг это бывает только в управленческих сказках. Подтянуть качество набора услуг за счет инновационного решения – трудно, но возможно. Сэкономить значительно, сбросив качество слабовостребованных услуг – пожалуйста. Сэкономить и повысить качество услуг вообще – фантастика на третьем этаже. В смысле - ступайте к Демингу.

Как указывают эксперты журнала «Консультант», нет никакой необходимости в 24-часовом функционировании бухгалтерских программных комплексов. Для работы в обычных обстоятельствах достаточно использовать их в течение 12 часов при 5-дневной трудовой неделе.

Значит, бухгалтерские комплексы работали до кризиса 24х7?

[UPD] Замечание в сторону экспертов журнала «Консультант» снимается, т.к. коллеги очень верно намекнули, что недурно бы ознакомиться с источником - а не с цитированием. Будем почитать.

Еще один хороший способ сэкономить на высоких технологиях – приостановить до лучших времен внедрение различных информационных систем.
Наконец, последний возможный сюжет – это рассмотрение советом директоров или иным руководящим органом фирмы целесообразности использования какой-либо инфосистемы.

Запредельный уровень аналитики и экспертных советов просто потрясает воображение. Т.е. автор нам советует приостановить внедрение ИС (оговариваясь некоей "точкой невозврата" – только не спрашивайте меня, что это). Автор нам советует отказаться от использования нецелесообразной инфосистемы. Не видел таких советов в ITIL. Но причем тут ITIL? И даже больше – причем тут кризис?

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

Как хорошо, что последнее время таких обзорных статей становится все меньше.

Обновили глоссарий

2009-05-12T15:12:00.003+04:00

Обновили русскоязычный перевод глоссария ITILv3 до версии 0.92, подробности по ссылке. Благодарности Кириллу Иванову (IBM), который проделал кропотливую работу по выверке текстов определений.

О семинаре itSMF "Управление финансами"

2009-04-30T13:41:00.002+04:00

Немного о семинаре управления финансами, организованным itSMF. Заявленная тема - управление расходами на ИТ в современных условиях. Заявленные тезисы в первую очередь относились к процессу управления финансами. Выступали Евгений Аксенов (ГВЦ Энергетики), Алексей Севидов(IBS), Кирилл Скрипкин (МГУ) и Сергей Овчинников (ИТСК). Три из четырех спикеров представляли аутсорсинговые компании, что и задало тон обсуждения. Практически все спикеры довольно смело отнеслись к обсуждению тезисов (читай: говорили о финансах, аутсорсинге, сорсинге вообще, пиарили свои компании и идеи - по тезисам мы услышали мало). Впрочем, гораздо лучше меня об этом уже написал Александр Шпер в своей заметке. На мой взгляд, лучшими спикерами были Сергей Овчинников и Евгений Аксенов. Но если Овчинникова до этого я слышал неоднократно и выступление было ожидаемо хорошим (живым, интересным по наполнению, остроумным), то выступление Аксенова оставило неожиданно крайне приятное впечатление. О чем их доклады? Да все о том же - как результативно и эффективно организовать сервис. "Умеют"-то все. А дьявол в нюансах.

Увы, прочие коллеги оставили скорее нейтральное впечатление - Кирилл Скрипкин, на мой личный вкус, чересчур сухо-академичен (сказывается долгий опыт преподавания в МГУ?), а Алексей Севидов очень уж много говорил о неинтересной, "маркетинговой" части практики организации сервиса. Товарищи, маркетинговые лозунги мы все почитать можем легко - достаточно открыть любой журнал ИТ.

В общем, очень понравилось "введение в промышленную сервисологию" (как нарекли его коллеги) от Евгения Аксенова. Очень жалею, что посетить вчерашний семинар itSMF не было времени. Вчера Евгений читал расширенный мастер-класс на эту же тему. В ближайшее время обязательно прослушаю mp3 с записью семинара и посмотрю презентацию.

Вопросы к спикерам, как обычно, содержали много "воды" и пространных личных мнений участников. Однако, если сравнивать с прошлым семинаром, дело явно идет на лад. А вот что понравилось очень и очень: спикеры нашли время ответить на дополнительные вопросы участников онлайн, в специальной ветке форума itSMF.

Интересные новости от itSMF International

2009-04-28T17:50:00.003+04:00

Работа над ITIL продолжается - постоянно идет публикация и создание книг, расширяющих и дополняющих пятитомник "ядра". Мне лично было бы интересно посмотреть на серию Лучшие практики для управления знаниями, инцидентами, изменениями. К примеру, Incident Management Best Practices планируется к выходу летом.

Вот здесь Ян ван Бом и компания комплектуют команды рецензентов и авторов. На русском коллегами переведено и выложено в новостях itSMF.

Управление ИТ-услугами в кризис

2009-03-26T17:57:00.005+03:00

Круглый стол на площадке Intelligent Enterprise, посвященный анализу тенденций управления ИТ в кризис. Участники - Марина Аншина, Игорь Баринов, Владимир Ананьин. Организаторы от IE: Константин Зимин и Денис Легезо.

Мне в материале некоторые моменты показались очень интересными - ваш покорный слуга прокомментировал обсуждения в числе прочих экспертов. Кому лень читать материал целиком по основной ссылке, можно почитать здесь..

Понятно, что в ближайшее время ИТ-директору придется расшивать узкие места операционной деятельности, в первую очередь сокращать затраты без значительного ухудшения качества предоставляемых услуг. В каких‑то организациях это решается через высококачественное управление изменениями, в холдингах и распределенных структурах это будет централизация общекорпоративных услуг. Во многих компаниях до сих пор нет даже простого каталога услуг и примерного понимания их стоимости.

По моему опыту отсутствие грамотного управления необходимыми изменениями — проблема общая. Её решение способно сильно сократить затраты в большинстве российских организаций. Вспомните хотя бы, давно ли вы видели процесс управления изменениями, в котором проводилась бы оценка используемости внедренных изменений, в первую очередь изменений корпоративных приложений. А ведь бюджеты на доработку корпоративных приложений представляют весомую часть ИТ-бюджетов множества компаний. Не умаляя значимости модели ITSM, замечу, что повышение операционной эффективности — это далеко не новейшая задача. И альтернатив для ITSM здесь наработано множество: вспомнить хотя бы фундаментальную теорию качества доктора Деминга или более новые разработки, такие как теория ограничений Голдратта.

Плохо одно: до сих пор, делая попытки антикризисных прогнозов, мы мыслим количественными, а не качественными категориями. Недостаток ликвидности, колебания валютных курсов — это всё глобальные, но количественные изменения. А вот сбой отлаженных логистических цепочек — изменение уже качественное. Что ИТ-отдел должен будет изменить в качественных категориях, пока не очень ясно.

Разработка процессов ITIL

2009-03-17T22:37:00.003+03:00

Простая и понятная, но очень здравая статья о правильной разработке процессов ITIL. Developing Actionable ITIL Processes Mike Tainter и Kristy Smith на itsmwatch. Для процессных консультантов многое тривиально, но вообще полезно. Даны определения Политики, Процесса, Процедуры, Шага, Рабочей инструкции. Аккуратнее, определения не официальны. Даны не догматы лучших практик, а явно крупицы собственного опыта.

Не поверите, но вот такие Haphazard process development процессы действительно бывают! Я их видел, совсем недавно.

А правильная многоуровневая структура процесса отлично иллюстрирована вот здесь Multi-layered process framework. Красота. Даже элементы диаграмм выглядят похожими на используемые нами в работе. Критерии хорошей разработки просты - простота и ясность изложения диаграммы определяется четкостью и непротиворечивостью мысли при проектировании процесса.

Скептично: вендоры, Service Desk'и, соответствие ITIL

2009-03-17T16:42:00.007+03:00

К затронутому когда-то вопросу выбора решения Service Desk. Наш добрый IT-Skeptic прошелся по теме соответствия ITIL решений класса Service Desk, и тому, что говорят об этом вендоры.

"Как вендоры ПО лгут о поддержке ITIL" (itsmwatch, английский) или в двух частях авторский вариант в блоге IT-Skeptic "АБС-столовая" часть 1, "ITIL101 для вендоров ПО" часть 2 (увы, тоже английский).

Избранные цитаты:
- "Слишком много вендров ПО передергивают факты, заявляя о поддержке ITIL в продукте. Скорее всего они попросту не понимают ITIL.";
- "ABC Staff Kitchen Handbook" 8)
- "Этот запрос на коммерческое предложение требует поддержки Управления Финансами. Быстренько, у нас есть Управления Финансами? Ну, мы храним в активе информацию о наименовании поставщика и стоимости покупки.. Скажем, что у нас есть Управление Финансами!".

Очень рекомендую читать в авторском варианте.

Вышла CMMI For Services

2009-03-13T18:31:00.002+03:00

Тихо и неприметно произошло крайне интересное событие: выпущена модель CMMI For Services (CMMI SVC). В компаниях-разработчиках ПО косвенно сталкивался с CMMI DEV, был впечатлен значимостью и полезностью процедур аудита по данной модели.

Что такое CMMI? Capability Maturity Model Integration или Комплексная модель зрелости - это набор элементов лучших практик, которые могут быть использованы для построения, аудита или оптимизации результативных и эффективных процессов. CMMI это нечто в ряду ITIL и CobiT.

CMMI DEV - это для процессов разработки ПО, там известно давно и зарекомендовало, по-моему мнению себя неплохо. CMMI SVC - это для процессов обслуживания, выпущена в феврале 2009 - с пылу с жару буквально.

Итак, выложены собственно сама модель (CMMI SVC, v 1.2) в PDF и DOC, разнообразные поясняющие материалы.

Семинар itSMF 25 марта на тему "Управление финансами"

2009-03-12T15:17:00.004+03:00

25 марта itSMF Россия планирует проведение семинара "Управление расходами на ИТ в современных условиях". Вот здесь можно более подробно ознакомиться с местом проведения, фамилиями гостевых спикеров и тезисами.

Это будет второй семинар itSMF в новом формате, о первом я совсем недавно писал.

Начинаем использовать глоссарий ITIL v3 по-русски

2009-03-12T15:04:00.003+03:00

Вот в первый раз возникла необходимость применить переведенный на русский язык глоссарий ITIL v3. Переводили вопросы для тестирования ITIL v3 Foundation. Что могу сказать - в принципе удобно, пользовался не только для перевода основных терминов, но и заодно старался выдержать перевод дополнительных, косвенно затронутых в глоссарие терминов. За счет этого в тексте появляется связность и логическая четкость. И что очень важно - даже если идет перевод группой в несколько человек, даже если идет перевод нескольких текстов. Удобно.

Не обошлось без найденной логической ошибки. В терминах Workaround (Обходной путь) и Manual Workaround (Ручное обходное решение) ключевое слово переведено разным способом, ай-я-яй, просмотрели на вычитке. Более весомым является перевод термина в Manual Workaround, т.е. Обходное решение. Этот термин проходил через дистанционное голосования экспертов как термин средней критичности. А значит, нужно править все вхождения термина Workaround. Скорее всего, исправим в следующей версии глоссария.

И снова ITIL в небольших компаниях

2009-03-06T09:56:00.003+03:00

Из старенького. Когда-то я прочел мнение IT-Sceptic и кратко черкнул несколько собственных мыслей по этому поводу. Буквально через пару дней поступило предложение пообщаться совместно с коллегами на эту же тему: ITIL для небольших компаний.

Итого, общались в формате интервью для журнала "Директор информационной cлужбы" - Андрей Кабанец (руководитель ИТ-отдела ТД Коломна), Алексей Семидетнов, (директор департамента Digital Design) и ваш покорный слуга.

Каталог авторов и экспертов itSMF Россия

2009-03-05T16:35:00.004+03:00

Товарищи, в itSMF дошли руки организовать каталог авторов и экспертов itSMF Россия.

Зачем эта штука нужна? Да просто надоело вспоминать экспертов по нужной тематике, когда есть необходимость собрать экспертные мнения, подготовить статью или просто журналу требуется участие в тематическом интервью. Как только сей каталог наберет 100+ авторов, будем набирать команды в будущие интересные проекты, пользуясь этим документом.

Если вы или ваша компания в itSMF, интересуетесь ITSM или связанной тематикой - прочтите текст (там есть пример заполнения) и пришлите нам свои данные.