Рестарт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой адрес - KZ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

myITSMF (1)

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

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

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

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

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

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

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

Рекомендации по метрикам управления знаниями

Очень внимательно по случаю перечитывал KCS (Knowledge-Centered Support). Рекомендации по организации процесса управления знаниями (knowledge management). С первого прочтения было ясно, что эту штуку неглупые люди писали.

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

Верноориентированных целей. Ребята открывают и закрывают тему для управления знаниями буквально в паре абзацев:

Our first important concept distinguishes between activities and outcomes. If we put goals on leading indicators (activities), we will get what we ask for. Unfortunately, the activity by itself is not an indicator of value. For example, if we set a goal for each support analyst to create 10 solutions per month, we will get 10 solutions a month. However, if we are paying attention we will notice these solutions are often created on the last few days of the month and they contain little or no valuable information (things like “fixed the customer problem”). Goals on activities do not generate the desired outcome. In fact, in a knowledge management environment, goals based on activity will corrupt the knowledge base.

Что сказать? Неоднократно рекомендовал и буду рекомендовать для строящих процесс knowledge management разок глянуть в ITIL v3, а затем много раз смотреть в KCS, благо для частных интересующихся оно бесплатное и доступное. Спасибо Сергею Осадчему за нахождение и рекомендацию KCS пару лет назад, пользовал с тех пор неоднократно.