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

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

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

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

Контролировать нельзя доверять

В прошедшую пятницу говорили на корпоративном курсе про контроль как инструмент ИТ-менеджера. Книжки определяют management control примерно так: Функция управления, обеспечивающая достижение определенных целей в согласованных условиях (время, стоимость, качество). Обычно включает в себя (1) определение стандартов, (2) измерение фактических достижений и (3) корректирующие действия.  В ITIL контроль описыватся очень похоже:  Деятельность по управлению использованием или работой устройства, системы или услуги Действия по контролю направлены на обеспечение соответствия результатов использования или работы предопределенным нормам Условия для выполнения действий по контролю определены, понятны и подтверждены Содержание действий по контролю определено, утверждено и соответствует условиям Есть определения, в которых шаги контроля перечисляются…

Экономическая эффективность headcount-лимитов

Последний год возраст еще позволяет мне «сморозить глупость», и я поспешу этим воспользоваться. А вопрос мой будет про то, насколько экономически обоснованно введение жёстких headcount-лимитов. Сразу оговорюсь: я полностью понимаю и поддерживаю идею разумного ограничения численности персонала. Персонал – это затраты на найм, оплату труда, управление, площади и рабочие места, это риски и сложности при расставании. Разумеется, эти затраты и риски требуют аккуратного отношения и по возможности сокращения. Разумеется, это означает, что найм новых сотрудников всегда должен проходить ту или иную процедуру обоснования. То есть ограничения в этой области необходимы. Но ограничения эти должны быть преодолимы должным экономическим обоснованием, в…

Мотивация персонала: так ли важен великий смысл?

​Вы наверняка слышали эту притчу: один монах то ли смотрел, то ли руководил постройкой то ли собора, то ли храма. И спросил у трёх каменщиков, занятых той же стройкой, что они делают. Первый отвечал: "Я делаю из каменных глыб ровные камни". Второй сказал: "Я зарабатываю деньги для своей семьи". Третий же выступил зачётно: "Я строю храм", сказал он. Слушающему эту байку предлагается сделать вывод о том, что великая цель важна для любой, даже самой "низкой" по иерархии работы. Есть более вольный вариант той же притчи про уборщика мусора на космодроме, который на самом-то деле корабли в космос запускает. В ещё одной…

Серый, дешёвый, злой…

Пройдя обучение на этом тренинге, вы будете уметь:  обосновывать необходимость внедрения и совершенствования процессов управления службой технической поддержки по методике, описанной в «IT Infrastructure Library»;  формализовать процессы управления службой технической поддержки;  описывать назначение, процесс внедрения и ключевые показатели эффективности основных процессов и функций управления; Это не я придумал. Это так продавцы курса отвечают на ими же заданный вопрос "Что я буду уметь, если пройду этот курс?". Понимаете, вы идёте на курс, и там вас за три дня и примерно 25 тысяч рублей учат обосновывать необходимость внедрения процессов. Курс, кстати, "Основы ITIL", точнее, "ИТ менеджмент ITIL v.3".  То есть очень красивая landing…

Почему HR-бизнес партнёрство не работает и причём тут ITSM

Неделю назад я случайно наткнулся на заметку в ЖЖ Алексея Каптерева – известного мастера презентаций, автора мегапопулярной презентации Death by Powerpoint и книги "Мастерство презентации", тоже весьма популярной. Заметка называется "Почему HR-бизнес партнёрство не работает". Я тогда несколько обалдел от того, насколько мысли автора про место HR в бизнесе совпадают с нашими собственными размышлениями о месте в этом бизнесе ИТ-службы и сложностях партнерской составляющей сервисного подхода. Судя по числу репостов и лайков моей ссылки на статью Алексея, параллель показалась явной и важной многим, поэтому делюсь этой ссылкой и с читателями портала. Если у нас есть еще что аутсорсить — надо это…

DevOps не только для стартапов

Редкое ITSM событие проходит сейчас без упоминания концепции DevOps. Считается, что она хорошо подходит для Интернет-компаний, которые изначально использовали DevOps и не имеют унаследованных систем. Для компаний сферы финансов, производства или здравоохранения, где требования безопасности критичны для обеспечения конфиденциальности, целостности и доступности информации такой подход неприменим. Известный эксперт и соавтор книг ITIL, Стюарт Рэнс высказал свою точку зрения по данному вопросу. Все ИТ-системы организации можно классифицировать по трем уровням (согласно модели Gartner Pace Layered Application Strategy – PLAS): Учётные системы (systems of record), которые поддерживают основные транзакции и критические данные. Такие системы обычно редко меняются и регулируются нормативными требованиями. Дифференцированные…

ITSM-консультант: личная характеристика и профессиональный кодекс

Всё-таки существенная часть нового-полезного в ITSM-мире создается талантливыми увлеченными одиночками. Возможно, эта часть даже больше, чем та, которую создают корпорации. И уж во всяком случае за их успехами интереснее и проще наблюдать, их можно обсуждать прямо с авторами, и можно быть уверенным, что на обратную связь и вопросы, если их отправить автору, будет дан ответ. Вот лишь несколько имен, иллюстрирующих эти наблюдения: Аале Роос, Роб Ингланд, Ян ван Бон… В прошлом году на конференциях itSMF в Хельсинки и Таллине мне довелось познакомиться и пообщаться с еще одним ITSM-профессионалом, консультантом с двадцатилетним опытом, Барклаем Рэем (Barclay Rae). Возможно, кому-то из читателей нашего…

Мотивация персонала: кто что использует

Одна из моделей зрелости руководителя, имеющая акцент на мотивацию сотрудников, может выглядеть так: уровень зрелости 0: "Я работаю хорошо, и подчинённый у меня всего один – сам себя замотивирует, всё будет ОК" уровень зрелости 1: "Что-то людей стало больше, и работают они не так усердно – но разные премии в зависимости от достижений помогают мне добиться от них результатов" уровень зрелости 2: "Что-то премии стали хуже работать, попробуем нематериальную мотивацию" уровень зрелости 3: "Все способы перепробованы, книжки перечитаны, идеи реализованы. Как же их заставить лучше работать?!" Возможны, конечно, и другие модели, дело не в них. А вот в чём: каждый руководитель неизбежно сталкивается…

Взаимовыручка и кооперация: два плюса и два минуса на примере

Две недели назад проводили с Романом Журавлёвым деловую игру "Управление проектами – Египет бросает вызов" для нашего давнего и любимого клиента, крупной международной компании. Играло одновременно чуть менее сорока человек, разделенных на две команды, занимающихся стройкой пирамид (проектные группы), плюс один общий управляющий комитет (архитекторы, контроль качества, высшее руководство и связь с заказчиком). Каждая игра, конечно же, не похожа на другие, но опыт проведения нескольких десятков игр позволяет выявлять закономерности. Так, одно из моих наблюдений для игры по управлению проектами, особенно когда в неё играют ИТ-специалисты, таково. На игру в корпоративном формате обычно приходят сотрудники одной компании, но разных должностей,…

Кто больший глупец: заказчик или исполнитель?

Вы наверняка уже слышали об этой истории – пару дней назад она промчалась по просторам Интернета, вызвав весьма эмоциональные отклики. Вкратце суть такова. Одна крупная компания решила сыграть конкурс. Точная тема для нас не очень важна; скажем, что речь про ИТ. Даже ещё точнее – про ИБ. Суть конкурса: выбрать исполнителя, который выполнит поставку и внедрение специализированного программного обеспечения, а также окажет услуги технической поддержки решения в первый год эксплуатации. Всё как у нас в ITSM-проектах, только консалтинга особо не подразумевается, чисто софтовая работа. Конкурс играли в два этапа: на первом этапе были презентации, цветы, конфеты, оценка функциональности, нагрузочное тестирование. Цену…

Один за всех: когда гиперактивность вредна

Многим командам это знакомо: один из участников бегает заметно быстрее остальных, стараясь сделать как можно больше работы, спросить у этого, проконтролировать того, подхватить здесь, передать туда, помочь, подсобить, поучаствовать. Иногда такой гиперактивный товарищ даже является руководителем. Обычно остальным членам команды это нравится. Да, есть немножко хаоса, зато часть работы делают за них – приятно же! Но не всегда. Бывает, что пользы от “бегунка” меньше, чем вреда. В каких случаях это происходит? Приведу в качестве иллюстрации мою любимую спортивную игру – волейбол. Недавно мне посчастливилось играть в неё дважды в день по два часа почти две недели подряд (отпуск): как вы понимаете,…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;