суббота, 19 декабря 2009 г.

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

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

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

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

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

четверг, 17 декабря 2009 г.

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

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

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

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


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

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

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

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

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




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

Что же это?!

понедельник, 7 декабря 2009 г.

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

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

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

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

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

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

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

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

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

пятница, 27 ноября 2009 г.

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

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

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

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

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

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

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

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

четверг, 29 октября 2009 г.

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

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

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

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

среда, 21 октября 2009 г.

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

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

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

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

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

ITIL ChangeLog

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

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

понедельник, 19 октября 2009 г.

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

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

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


понедельник, 12 октября 2009 г.

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

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

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

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

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

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

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

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

пятница, 9 октября 2009 г.

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

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

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

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

вторник, 6 октября 2009 г.

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

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

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

пятница, 2 октября 2009 г.

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

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

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

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

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

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

понедельник, 21 сентября 2009 г.

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

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

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

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

четверг, 17 сентября 2009 г.

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

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

вторник, 15 сентября 2009 г.

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

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

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

четверг, 27 августа 2009 г.

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

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

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

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

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

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

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

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

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

среда, 26 августа 2009 г.

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

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

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

вторник, 25 августа 2009 г.

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

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

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

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

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

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

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

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

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

понедельник, 24 августа 2009 г.

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

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

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

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

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

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

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

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

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

четверг, 20 августа 2009 г.

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

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

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

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

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

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

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

вторник, 26 мая 2009 г.

Миграция с Service Desk

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

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

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

пятница, 22 мая 2009 г.

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

Итак, долгожданное и обещанное когда-то архитектором 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

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

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

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

понедельник, 18 мая 2009 г.

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

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

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

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

четверг, 14 мая 2009 г.

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

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

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

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

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

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

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

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

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

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


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

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

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

вторник, 12 мая 2009 г.

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

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

четверг, 30 апреля 2009 г.

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

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

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

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

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

вторник, 28 апреля 2009 г.

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

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

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

четверг, 26 марта 2009 г.

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

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

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

вторник, 17 марта 2009 г.

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

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

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

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

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

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

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

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

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

пятница, 13 марта 2009 г.

Вышла CMMI For Services

Тихо и неприметно произошло крайне интересное событие: выпущена модель 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, разнообразные поясняющие материалы.

четверг, 12 марта 2009 г.

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

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

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

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

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

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

пятница, 6 марта 2009 г.

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

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

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

четверг, 5 марта 2009 г.

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

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

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

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

вторник, 3 марта 2009 г.

На itSMF выложен перевод глоссария ITIL v3

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

Глоссарий ITIL v3 мы еще будем совершенствовать, для чего запустили сопровождение: поиск багов и обновление по ходу использования. Текущая версия перевода будет постоянно обновляться.

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

Этот глоссарий послужит основой для перевода одного из томов ITIL v3, планируемого itSMF в этом году.

среда, 4 февраля 2009 г.

О семинаре itSMF "Значение Каталога ИТ-услуг и процесса Управления уровнем сервиса в современных условиях"

Вчера в itSMF состоялся первый семинар 2009 года в новом формате – четыре гостевых спикера защищали свои мнения на условно-коротких выступлениях, объединенных общей темой. Несмотря на совпадение тем, в своих тезисах спикеры совпадали едва-едва, озорно импровизируя с комментариями предыдущих выступлений коллег на ходу.

На мой взгляд, лучшим гостевым спикером оказался Роман Журавлев (IT Expert). "Я-сла в гости-сла внедрять-СЛА. Тосла и Висла шли подписывать-СЛА", "А теперь становится понятно, почему эта девочка-экономист может приходить только из IT Expert'а". Роман активно делился со слушателями накопленными систематизированными знаниями.

Немного жаль, что ожидаемого сражения между Романом Журавлевым и признанным мэтром презентаций Ильей Хаетом (HP) толком не вышло. Илья выступал первым и, по-видимому, не совсем проснулся со старта – только к середине выступления он демонстрировал свои фирменные приемчики и шутки, делился практическим опытом HP. Выступление Грачева Алексея (EМC) мне осталось непонятным – каким образом может заинтересовать неспециализированную аудиторию рассказ о специализированном каталоге систем хранения данных. Последним выступал мой коллега Александр Цимбалистов (INLINE GROUP), и кажется, он единственный уложился в срок – Саша сделал акцент на уровнях каталога в привязке к операционным процессам и ресурсно-сервисной модели.

В итоге, приз зрительских симпатий гостевому спикеру itSMF уходит к Роману Журавлеву, по начисляемым баллам на системность, юмор и общую эстетику подачи материала значительно опередившему всех своих коллег.

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

 
скрипт счетчика посещений
статистика сайта