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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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