Digital Enterprise

Что и зачем можно измерять в системе управления ИТ

У меня сложилась простая, полная и непротиворечивая картина мира. Опять. На этот раз – мира оценки процессов. Посмотрим, сколько продержится. Вот она. Оценка процессов выполняется для того, чтобы получить представление либо о потенциале процессов (что они могут), либо о фактической успешности (что они смогли). Потенциал оценивается с двух точек зрения – функциональных возможностей и уровня организации, соответственно capability и maturity. Проекты "внедрения процессов" направлены именно на формирование этого потенциала. В дальнейшем он может развиваться в результате работы механизмов оценки и совершенствования, причем сами эти механизмы – тоже частный случай capability, свойственной определенному уровняю maturity. Оценку Capability и Maturity можно выполнять…

Роман Журавлёв, 29 ноября 2011, последний комментарий 6 декабря 2011

Маркировка с использованием RFID

Недавно наткнулся на презентацию одного из заказчиков, в которой описывалось тестирование RFID для использования в рамках процесса управления конфигурациями. Что можно сказать: 1. Использование активных меток отпадает сразу же, ибо такое решение будет стоить, как чугунный мост (стоимость активных меток, если не ошибаюсь, начинается где-то от 20 USD за штуку). Да и не сильно удобно в обслуживании – бегать батарейки менять. Это если учитывать объемы в тысячах конфигурационных единиц / активов. Если же конфигурационных единиц три штуки – возможно, это наш метод . 2. Использование пассивных меток более приятно по цене, но также имеет массу ограничений: некоторые нельзя клеить…

Михаил Тобурдановский, 28 ноября 2011, последний комментарий 12 декабря 2011

Нетехнические проблемы

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

Дмитрий Исайченко, 26 ноября 2011, последний комментарий 13 мая 2015

День благодарения на сайте ИТ-скептика

Роб Ингланд (ИТ-скептик), присоединяется к своим друзьям из США, и по традиции этого дня выражает благодарность всем, кто связан с его блогом: Я благодарен: Моим друзьям за их идеи, советы и исправления. Моей терпеливой семье, которая смирилась с этим блогом. Клиентам, которые в меня верят. Всем тем, кто приложил усилия к сводам знаний по ИТ, которыми я пользуюсь, гигантам, на чьих плечах я стою: COBIT, ITIL, USMBOK и других. Интернету – за то, что мир стал достаточно маленьким, чтобы услышать представителя Новой Зеландии. Интернету – который позволяет любому дотянуться до всех знаний, накопленных человечеством. Лагерю ITIL – за постоянный поток…

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

Голова пошла кругом от PAM, CMMI и прочих моделей. Чтобы вернуться в реальность, я попытался честно ответить себе на вопрос – зачем вообще повышать зрелость процессов? Решил поделиться ответом с вами =) Я вижу всего 4 последовательных и значимых уровня зрелости ИТ-процессов: Не-процесс. Когда работа просто выполняется. Документации нет или её мало или она устарела. Отчётность составляется от случая к случаю, для "разбора полётов". Автоматизация лоскутная, возможно, дорогими "микроскопами". Такой "процесс" есть у всех: работа просто выполняется. Дорогой процесс. За него мы платим экспертам "на зарплате", внешним консультантам или вендорам. Есть вся документация и формы отчётов, за которые заплатили. Причём…

Константин Нарыжный, 23 ноября 2011, последний комментарий 29 ноября 2011

Back2ITSM: призыв к добровольцам

Летом этого года Стивен Манн опубликовал принципы нового движения среди профессионалов в области управления услугами – Back2ITSM ("Назад к ITSM"). Стивен декларировал следующие принципы: Признать, что мы профессиональное сообщество, участники которого преодолевают одни и те же трудности (например, использование ITIL) Выделить немного времени на помощь другим (а может быть – и самим себе) Определить область для приложения усилий (например, создать систему универсальных метрик ITSM). Выполнять обещания, данные сообществу ITSM Не оставлять попыток улучшить наши общие способности и качество ИТ и бизнес-услуг. Примерно тем же занимаются и юристы, которые работают pro bono (от латинского pro bono public – "ради общественного блага")….

Новостной поток, 22 ноября 2011, последний комментарий 29 ноября 2011

Презентации ITSMFUK’11

Организаторы недавно завершившейся конференции itSMF Великобритании любезно опубликовали все презентации конференции на своём портале. Представлены слайды выступлений Криса Данси, Стивена Манна, Айвора Макфарлейна и многих других. Знаниями делятся такие компании, как HP, Heineken, G2G3, Барклайс Банк. Всего в списке около 50 презентаций (еще не все выступления выложены) на самые разные темы. Для ознакомления достаточно базовых знаний английского языка. Рекомендуем. Нам бы так.

Зачем бизнесу SLA?

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

Дмитрий Исайченко, 18 ноября 2011, последний комментарий 24 ноября 2011

Управление спросом

У меня родился типично-пятничный пост. В одном из недавних проектов столкнулись с чисто технической проблемой – нежеланием Internet Explorer 6 работать в своем основном качестве (в качестве браузера). Начали разбираться, оказалось, что версия давно уже признана неудачной даже самим производителем. И, видимо, для того чтобы снизить поток обращений за поддержкой, а так же очистить свою карму от проклятий, производитель запустил удивительный сайт "The Internet Explorer 6 Countdown" со слоганом "Moving the world off Internet Explorer 6". На сайте есть даже колонка стран-чемпионов, которые смогли почти полностью отказаться от продукта. Думаете, это чья-то шутка? Домен зарегистрирован на компанию microsoft. Вот выдержка…

Евгений Шилов, 17 ноября 2011, последний комментарий 17 ноября 2011

Про новый процесс в ITIL 2011

Старший консультант канадской компании Thought Rock Грехем Фернис опубликовал своё мнение по поводу нового процесса в ITIL 2011 – Координация проектирования (Design coordination). Этот процесс определён в ITIL на фазе проектирования услуг (Service Design) как "отвечающий за координацию всех действий, процессов и ресурсов, необходимых для проектирования услуг. Координация проектирования обеспечивает целостное и эффективное проектирование новых или изменяемых ИТ-услуг, систем управления услугами, архитектур, технологий, процессов и метрик". Путём приоритезации и составления расписаний, процесс координирует ресурсы с целью сбалансировать спрос на них со стороны множества проектов и изменений. На более высоком уровне, Координация Проектирования создаёт политики, регламенты, бюджеты и модели, которые будут…

Новостной поток, 17 ноября 2011, последний комментарий 18 ноября 2011

Предъявите “чек”!

Джон Рив в авторской колонке на портале itsmportal.com опубликовал свой взгляд на один из шагов цикла Деминга – Проверку (Check): Цикл Plan-Do-Check-Act все уважают, потому что он вполне разумен и проще уж не получится. И всё же, хотя собственных недостатков у него нет, он провоцирует ошибки. Каждый из четырёх шагов отлично выполняется при запуске проекта, или при выполнении значительного изменения. Однако, после успешного выполнения первого оборота этого цикла, внимание к этапам процесса немедленно спадает, и PDCA становится BAU (Business as usual, рутинным выполнением работы) Выполнению проверок уделяется мало усилий. Планирование всегда делается качественно, потому что это действительно интересное занятие, которое…

Портал №1 по управлению цифровымии информационными технологиями

Портал №1 по управлению цифровыми
и информационными технологиями