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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ITIL Expert (bridge)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CobiT v5

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

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

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

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

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

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

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

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

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

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

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

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

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

Real ITSM

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

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

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

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

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

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

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

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

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