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

Business Agility, DevOps, ITIL, ITSM, COBIT, PRINCE2, TOGAF, Kanban...

14 лет в эфире. 3 000 записей. 10 000+ постоянных подписчиков.

 

 

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

Цифровое рабочее место – трансформация современного предприятия

Цифровая трансформация – горячая тема для многих предприятий. Это больше, чем просто внедрение новых технологий для рабочего места, и зачастую, следовать ей необходимо, чтобы оставаться конкурентоспособными в быстроменяющемся мире. Переход к цифровому рабочему месту – важный шаг для современного бизнеса. Новые исследования, посвященные тому, как организации проходят путь от традиционной офисной среды к цифровому рабочему месту, показывают, что получение конкурентных преимуществ и совершенствование бизнес-процессов являются главными целями их стратегий цифровой трансформации. Так считают 40% опрошенных  из 800 компаний из 15 стран на пяти континентах, согласно опубликованному на днях отчёту Digital Workplace Report: Transforming Your Business. Ещё одно открытие этого отчёта состоит в том,…

Кто бреет брадобрея?

Рассмотрим два из трёх принципов, которые, по мнению Gene Kim, определяют DevOps. Они сформулированы в его статье «Три пути: Принципы, поддерживающие DevOps» («The Three Ways: The Principles Underpinning DevOps») и подробно описаны им в книге «The DevOps Handbook». Так называемые второй и третий пути DevOps: создание постоянного быстрого потока обратной связи, что позволяет максимально рано выявлять проблемы и устранять их максимально быстро, не допуская передачи дефекта по потоку создания ценности (в сторону эксплуатации/потребления) и предотвращая повторения проблем (рис.1 [с сайта itrevolution.com, Copyright © 2017 IT Revolution]) создание креативной культуры высокого доверия, поддерживающей экспериментирование и извлечение уроков как из успеха, так…

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос: Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Как мотивировать пользователей подавать заявки в Service Desk через портал?

В редакцию портала поступил вопрос: Приветствую, коллеги! Возникла следующая дилемма. Есть три способа подачи заявок в ServiceDesk: Веб-портал (где пользователь сам выбирает сервис ИТ). Письмо по электронной почте (тогда все заявки сваливаются на первую линию и их категорирует один из сотрудников первой линии). По телефону (только в случае невозможности первых двух способов. Самый эффективный способ с точки зрения руководителя ServiceDesk — первый. В этом случае, во-первых, значительная работа по категоризации заявки проводится самим пользователем (он сам выбирает тип заявки (инцидент, ЗНО, ЗНИ) и сервис ИТ). Во-вторых, по некоторым сервисам (которые первая линия всегда эскалирует на вторые) заявка сразу попадает на вторые линии, специалисты которых выставляют лишь срочность…

Shift Left и трансформация службы поддержки

Интересными наблюдениями и рекомендациями, по результатам двухлетнего проекта трансформации службы поддержки, делится Ричард Сикора (Richard Sykora) (оригинал статьи A Support Center Transformation to Shift Left). Основная цель проекта была обеспечить «shift left» организации поддержки. Ричард пишет: "Cтратегия сдвига влево, на самом деле, очень проста. В левой части спектра у вас есть наименее затратная модель поддержки ваших конечных пользователей. В ней обычно нет людей, которые помогают пользователям, он широко известен, как нулевой уровень или самообслуживание. В центре спектра у вас может быть вспомогательный персонал, однако, это скорее сценарий «много-к-одному», например, чат. Дальше вправо по спектру соотношение уже «один-к-одному» между конечными пользователями…

12 «лучших практик» в ИТ, которых следует избегать любой ценой

Начиная от слов «вы – наши заказчики» и заканчивая «облачной» стратегией – эти «лучшие практики отрасли» погубят вас. В чем причина неудач ИТ-компаний? Очень часто – это использование так называемых «лучших практик», описанных людьми, которые могли бы знать побольше о предмете, но не знают, возможно, потому, что никогда этим не занимались. Начиная от определения «внутренних заказчиков», и заканчивая внедрением практики внутреннего выставления счетов для обеспечения рентабельности инвестиций. Большинство этих советов внушают доверие с расстояния более ста километров. Однако стоит стереть верхний слой и вы поймете, что многие из них на самом деле – верный путь к провалу. 1. Все вокруг…

Шесть правил построения модели аллокации ИТ-затрат

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

“… многоликий Вы наш”

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

Адаптивные модели изменений

"Жизнь многообразна, бумага не бесконечна!" )) "Ну хорошо, а сколько их нужно сделать?" Этот весьма насущный вопрос возникает, когда начинаешь проектировать модели изменений. Мы уже делились на нашем портале разными мыслями по поводу моделей изменений. Например, здесь и здесь. А здесь даже лежит вебинар по данной теме. Но если мы говорим, что модели позволяют учесть различную специфику проведения изменений в зависимости от того, как это изменение классифицировано, то каков должен быть масштаб проработки этой специфики? Какова должна быть детализация того самого классификатора? И какие конкретно параметры изменений должна настраивать модель? Как обычно, следует искать рациональный баланс. Чётко прописать всю специфику вплоть до…

Продаём DevOps высшему руководству

В последние месяцы в общении с коллегами, клиентами и партнёрами регулярно наблюдаю примерно такой диалог: — Эх, всё так стремительно меняется! Конкуренты запускают новые продукты, клиенты становятся всё более придирчивыми и продвинутыми. Прямо чувствуется, как мы всё больше и больше отстаём. — Что же мешает вам двигаться быстрее? Есть же новые подходы, успешно применяемые в разных организациях. Тот же DevOps, к примеру. — Это да, было бы круто. Но это же большая перестройка! — Разумеется. Но ведь дорогу осилит идущий. С чего-то надо начинать. — Нет, у нас не выйдет, руководство не поддержит. То, которое в бизнесе. Ведь им тоже…

Давайте будем осторожны, когда тратим деньги, и другие мифы о технической поддержке

Оригинал заметки Let’s Be Careful How We Spend Our Money: And Other Tech Support Myths, автор Рой Аткинсон (Roy Atkinson) Не так давно у меня был разговор с человеком из очень большой компании, очень-очень большой компании с сотнями тысяч сотрудников. Они сбрасывают пароли вручную. За прошлый год их служба технической поддержки проделала это 600 000 раз. Давайте быстро и, не сильно вдаваясь в детали, посчитаем. Средняя стоимость каждого тикета, если верить отчету HDI 2016 Technical Support Practices & Salary Report составляет $ 18,50. Но сброс пароля всё-таки относительная простая и быстрая операция, поэтому давайте оценим его в половину стоимости: $…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM