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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Общие вопросы менеджмента

Вопросы, методики, инструменты, находки в менеджменте, не обязательно относящиеся к управлению информационными технологиями

Начальник и ITSM

Довелось тут тренировать команду руководителей среднего звена в ИТ-службе в крупном банке. Как обычно, очень приятно было общаться с коллегами, которые пытаются сварить кашу из топора сами, без проходящих мимо солдат.  Заказчику вводного курса  (руководителю службы поддержки пользователей) хотелось, чтобы руководители других ИТ-подразделений (разработка ПО, администрирование и т.д.) тоже участвовали в приготовлении еды. Вот я и рассказывал им про основы управления ИТ-услугами. Ближе к концу тренинга, воодушевившись не только операционными процессами, но и деятельностью по проектированию и внедрению услуг, заказчик придумал следующее: так хорошо бы то же самое рассказать и всем остальным сотрудникам – системным администраторам, аналитикам, специалистам! Пусть тоже узнают о светлом…

ИТ-скептик про склонность к риску

Наш друг Роб Ингланд, пребывает в меланхолии. Видимо, готовится к ITSM-марафону. За последние десятилетия компании стали более склонным к риску, чтобы, вслед веяниям моды, стать гибче, мобильнее и конкурентоспособнее. А значит – прибыльнее. Эксперты считают, что рисками можно управлять, снижать их и страховаться. Все мы знаем, чем эти приёмы закончились в финансовом секторе в 1980ых, затем в 1990ых, и снова в 2000ых. Давайте уже извлечём уроки? Неприятная правда про высокую степень склонности к риску: рано или поздно вы проиграете. Если сегодня повезло – не значит, что повезёт завтра. Все мы хихикаем над неудачами саблезубых банкиров, а сами делаем те же…

Первый шаг Джона Коттера

Вчера на вебинаре Константин рассказывал, среди прочего, про замечательную модель Джона Коттера. Наверняка о ней все слышали, а многие даже применяют. Мы вот используем её в больших задачах, так что могу ответственно заявить – модель работает. Напомню кратко те восемь шагов, которые автор, он же Джон Коттер, считает критически важными для любого крупного изменения: Создание ощущения срочности Создание коалиции Разработка видения и стратегии Коммуницирование видения Старт преобразований на всех фронтах Создание быстрых побед Консолидация и усиление изменений Закрепление изменений Особенно мне симпатичен шаг номер один. Мой опыт показывает, что он является чуть ли не самым основным – в том смысле,…

Концентрируйся или …?

Бог дал человеку все, кроме времени. Дина Рубина, "На солнечной стороне улицы". В последнее время почему-то часто возникают разговоры на тему тайм-менеджмента. В том числе у нас на портале. Это действительно важно, но, как правило, эти разговоры упускают из виду один принципиальный вопрос: как сделать так, чтобы отведенное на задачу время было потрачено максимально эффективно? Любой человек, который работает или работал в условиях многозадачности, знает, что ключевым условием здесь является навык концентрации. Концентрироваться сложно всем, хотя и в разной степени. Тем сложнее, чем больше задач и соответственно необходимости переключений между ними. Тем не менее, это навык, который можно и нужно развивать…

Почему организационные изменения настолько трудны?

Любое масштабное мероприятие, связанное с улучшением эффективности работы компании, является организационным изменением. Небольшие улучшения (к примеру, "давайте добавим ещё один способ взаимодействия с нашим Service Desk") реализовать на практике, как правило, не очень сложно. Более масштабные инициативы даются во многих случаях непросто. Почему? Крупное организационное изменение от небольшого отличается тем, что влияет на всю организацию или её существенную часть, а также в большинстве случаев серьёзно затрагивает и внешних контрагентов. Для традиционного ИТ-подразделения это означает, что более половины ИТ-сотрудников должны будут так или иначе изменить привычный способ выполнения работы, да и сотрудники бизнес-подразделений, взаимодействующие с ИТ-отделом или зависимые от него, получат…

Много работаешь – не обязательно молодец

Эта проблема знакома многим. "Как мы выделим ресурс на менеджера процесса, если у нас все люди полностью загружены?", – говорят нам клиенты. "Откуда мы возьмём людей на первую линию, ведь все инженеры бегают по заявкам?", – говорят нам назначенные руководители Service Desk. "Да, я не подготовил ежемесячный отчёт о работе процесса, потому что я перегружен другой работой", – говорит нам свеженазначенный менеджер процесса. Чего греха таить, мы и в своей организации постоянно слышим подобное. Ресурсов мало, они ценны, они планово используются на 100%, а то и больше. Но вот беда – очень многие путают интенсивность труда с производительностью. Производительность труда…

Лидер и менеджер – совсем не одно и то же

В прошедшее воскресенье я получил удивительный и интересный опыт, проведя деловую игру "The Challenge of Egypt" для группы студентов летней научно-образовательной школы «Лифт в будущее – 2012». Поясню сразу – студентам было от 11 до 15 лет, в среднем – 14-15. Их отбирают сложными процедурами по всей стране, лучших свозят в летний лагерь и учат разным премудростям, включая самое настоящее проектное управление. Лучших из лучших, двенадцать человек, отправили ко мне на игру. Это очень интересная программа поддержки талантливых ребят и девчат нашей большой страны, за которой, насколько я понимаю, стоит АФК "Система". Позже, когда будут фото-видео материалы, я напишу подробнее…

Вопрос из зала: что почитать?

Наши друзья и коллеги часто спрашивают у нас, где найти литературу: Про управление ИТ-услугами Про международные стандарты в области ИТ Про управление проектами Желательно – не только фундаментальные труды, но и периодику. Хорошо бы еще и на правильном русском языке. Мы своими советами делимся охотно.  А что порекомендуете вы?

Процессная математика. Tension-метрики

Итак, задача. Есть две tension-метрики, из них необходимо сделать один общий KPI, который показывал бы, насколько удаётся исполнителю обеспечить баланс. Для примера возьмём предложенные метрики процесса управления инцидентами по своевременности (https://realitsm.ru/2011/12/measuring-incident-management) и результативности (https://realitsm.ru/2012/02/measuring-incident-management-2). О каком балансе речь? Можно иметь неплохие показатели своевременности, если сразу перекидывать входящие обращения на смежников (а там жизнь покажет, можно в фоне поразбираться, вдруг и правда вопрос к нам). Однако в этом случае обращения будут возвращаться и требовать повторной обработки. Можно, напротив, разбираться «от и до», не передавать обращения (не отмечать выполнение), пока не будет 100%-ной уверенности в том, что найдено лучшее решение и оно…

Как сделать любое совещание бесконечным и бессмысленным

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM