Постоянное улучшение Archives – Страница 16 из 36

Cleverics ищет нового тренера

С понедельника этой недели в Cleverics открыта вакансия тренера по ITIL/ITSM. Такие события время от времени происходят: страничка на сайте с описаниями наших вакансий была размещена ещё в 2010, если я правильно помню, году, и с тех пор своей актуальности не теряет. Собственно, стандартные способы поиска вроде HeadHunter уже задействованы, и у нас даже есть очень интересные кандидаты. Но я подумал: было бы неправильно не сообщить о возможности трудоустройства в нашу компанию читателям нашего же портала. Действительно, аудитория широкая, исключительно предметная, да что там говорить – любимая! Поэтому сообщаю: желающие влиться в дружный коллектив, получить неизмеримое количество знаний, дойти до ITIL Expert (если ещё нет) и даже дальше могут обращаться напрямую ко мне….

ITSM, DevOps, и почему трехуровневая поддержка должна быть заменена на Swarming

DevOps приходит в ИТ-организации, независимо от того, готовы они к нему или нет. Автор этой статьи утверждает, что существующая организационная структура подавляющего большинства служб ИТ-поддержки в корне неверна. Недостатки организационной структуры затрудняют или делают невозможным для этих предприятий успешную интеграцию зарождающихся практик DevOps с уже существующими структурами технической поддержки. По мнению автора, развивающийся в настоящее время подход под названием Swarming[1] идеально подходит в качестве методологии организации технической поддержки в эру DevOps. Предыстория: ортодоксальная трёхуровневая поддержка Начнём с краткого обзора структуры управления, которая лежит в основе большинства функций ИТ-поддержки крупных предприятий. Классической организационной структурой управления ИТ-услугами является трёхуровневая иерархия поддержки: Уровень…

Новостной поток, 4 сентября 2017, последний комментарий 19 января 2022

Высокоэффективные ИТ-команды – ключ к достижению успеха

Те, кто был знаком со мной в тот период, когда я только пришел в ИТ-подразделение Warehouse (TWL), прекрасно помнят, насколько уныло все было в самом начале. Я перешёл в TWL из Deloitte с надеждой на то, что моя роль ИТ-директора будет заключаться в том, чтобы возглавить команду, которая будет применять ИТ для обеспечения конкурентных преимуществ и создания ценности. Однако меня встретили хаос в подразделении и недовольство со стороны бизнеса. Есть талант, но нет времени для стратегии У меня есть множество способов проиллюстрировать это, однако моим излюбленным примером является следующий: у нас произошло 62 инцидента высшего приоритета за первые 60 дней…

Ловушка зрелости для DevOps

Автор: Чарльз Арауджо (Charles Araujo), оригинал заметки: Is DevOps Falling into the Maturity Trap? Я увидел это не так давно на конференции. Менеджер по развитию одного крупного предприятия объяснял, как они придумали модель зрелости DevOps на основе CMMI. Он говорил о текущем состоянии зрелости и плане по достижению «полной зрелости» в ближайшие три года; рассказывал, как они представляли этот план руководству и получили одобрение на создание новой «DevOps команды». Многие организации сейчас действительно ищут какую-нибудь «линейку» для DevOps, чтобы откалибровать свой прогресс и свериться с рынком. Однако, поскольку крупные предприятия зачастую спешат с принятием всего нового и модного, минуя стадию экспериментирования…

Новостной поток, 6 августа 2017, последний комментарий 4 октября 2017

Сопротивление организационным изменениям – миф

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

Олег Скрынник, 2 августа 2017, последний комментарий 15 августа 2018

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

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

Новостной поток, 17 июля 2017, последний комментарий 17 июля 2017

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

Оригинал заметки 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. Но сброс пароля всё-таки относительная простая и быстрая операция, поэтому давайте оценим его в половину стоимости: $…

Новостной поток, 7 июля 2017, последний комментарий 12 июля 2017

Когда верхи сражаются, а низам – всё равно…

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

Елена Колбей, 2 июля 2017, последний комментарий 3 июля 2017

DevOps в динамике – 2. Метрики

Продолжение заметки "DevOps в динамике". Одни из ключевых вопросов, которые стоят перед теми, кто строит карту показателей процесса, системы менеджмента или любого другого объекта управления: как убедиться в необходимости и достаточности набора метрик? как получить набор метрик, который даст наиболее точное представление о состоянии объекта управления? Коллеги Дмитрий Исайченко и Роман Журавлев в книге «ITSM. Руководство по измерению» в части разработки процессных метрик предлагают следующий подход: Установить назначение процесса Разработать метрики соответствия назначению Установить ключевые практики Разработать метрики ключевых практик … Назначения процессов широко известны, поэтому шаги 1-2 обычно не вызывают трудностей – что должны показывать метрики понятно, вопрос только в выборе правильной…

Павел Дёмин, 22 мая 2017, последний комментарий 30 мая 2017

Definition of Done

Одно из важных концептуальных понятий DevOps – определение завершения (англ. – Definition of Done). Как и многие другие важные концептуальные понятия DevOps, оно появилось и сформировалось задолго до возникновения этого самого DevOps. Однако именно в DevOps определение завершения развили, продолжили и наполнили дополнительным смыслом. Давайте разберёмся, каким. О чём, собственно, речь? Умные ребята говорят, что неплохо бы договориться о том, когда работа считается выполненной. Очень важно, говорят, одинаково понимать, что это означает – работа выполнена. Посмотрим на эволюцию такого понимания. Первая ступень под кодовым названием "совсем, совсем плохо" такова: завершено тогда, когда разработчик сказал, что всё работает. Очень понятно почему это плохо…

Олег Скрынник, 14 мая 2017, последний комментарий 15 мая 2017

Терпение, эволюция, политики и полномочия

Роб Ингланд (Rob England) о ключевых уроках DevOps-преобразований, интервью организаторам DevOps Enterprise Summit (DOES17) в Лондоне. Роб Ингланд (Rob England) – независимый консультант по управлению ИТ, тренер и автор публикаций, управляющий директор Two Hills Ltd., которая предлагает услуги ИТ-консалтинга и обучения широкому кругу компаний – государственных и коммерческих. Роб также является автором блога IT Skeptic и целого ряда ценных идей в сфере DevOps и управления ИТ. Каковы основные проблемы и вызовы, которые ждут идущих по пути DevOps-преобразований? Вызов номер один – это консервативная культура. Вы слышите следующие возражения: «это не будет работать здесь», «у нас нет ресурсов», «это слишком рискованно»,…

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

Постоянное улучшение

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