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

ВЖУХ, управление рисками и ITSM

То, что DevOps не является "серебряной пулей" наверное уже ни для кого не секрет. Применение гибких практик разработки и эксплуатации продуктов существенно отличается от общеизвестных практик управления услугами своей выраженной ориентацией на ценность здесь и сейчас. Многолетний мир ITSM, в первую очередь, ориентирован на рациональность с акцентом на минимизацию затрат, рисков и ущерба. Многие могут это оспаривать, опираясь на первоисточники, не без оснований говорить, что библиотеки говорят о необходимости баланса между гибкостью и защищенностью, рисков и выгод. Да, это так, но всё же управление услугами не о том, как быть бизнесом, а о том как бизнесу помогать, а это "две большие разницы".

Agile не отделяет ИТ от бизнеса, т.к. без ИТ этот бизнес перестает существовать как сущность, как машина без двигателя, своего сердца. Именно по этой причине DevOps ориентирован на получение максимального результата в максимально короткие сроки. Деньги не проблема, если ты их печатаешь.

"Fail Fast!", подумали ракетостроители и сноровисто, отточенными движениями приварили к конструкции ещё пару твердотопливных ускорителей.

Взглянем на настоящую организацию, в которой мы работаем. С высокой вероятностью мы увидим, что в нашей организации нам потребуется совмещать эти разные способы производства. Если это средний или крупный бизнес, то кроме наших ключевых бизнес-приложений, где мы пусть успешно удовлетворяем требования бизнеса наиболее быстрым способом, у нас есть и более "медленные" подразделения. Это управление кадрами, со системами которых мы интегрируемся, информационная безопасность, требования которой мы не можем игнорировать. Пусть у нас есть ещё защищенная real-time система управления техническими процессами производства, сбои в которой чреваты человеческими жертвами или физическим разрушением производства, релизы в ней редки, но они проходят колоссальную по свой тщательности проверку и тестирование.

Совместное существование этих существенно различных, но взаимодействующих друг с другом, областей инфраструктуры требуют согласования правил и политик взаимодействия. Это потребует от более "гибких" братьев учитывать те ограничения, в которых им необходимо будет работать: согласовывать внесение изменений в интеграционные сервисы, закладывать вспомогательные ресурсы/бюджеты на обеспечение защиты персональных данных, учитывать графики релизов проектных коллег и графики поставок и т.д.

Нельзя не учитывать существенный риск непрерывности бизнеса в лице колоссальной зависимости бизнеса от команды развивающей продукт и входящих в неё людей. Необходимо защищать себя от риска ухода команды, увольнения ключевых сотрудников, утечки данных или технологий, а это означает сохранение знаний, детальное документирование. То есть именно то, что тратит дорогие ресурсы и уменьшает возможности команды по "delivery" в рамках производственного цикла.

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

Мы здесь надолго, поэтому нам нужно уже сейчас учиться его решать, разделять ресурсы, управлять и продолжать доносить ценность.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 6

  • Тот-Кого-Нельзя-Называть

    Расскажу как мы гибко оцифровали риски. А дело было так.

    Лето 2015. У активной группы заказчиков появилась идея сделать учет рисков самым что ни на есть автоматизированным. Раньше это делалось в Bitrix и доставалось в Excel по звонку. Удобно работает но ни разу не гибко. Потому пришло решение сделать на той же платформе, что и управление операционными процессами модуль для регистрации, обработки и контроля всех видов рисков которые известны в компании. Проблем было несколько и самая большая – это отсутствие четкого  процесса. Тут очень помогли практики ITSM — мы подумали, что вся эта «рисковая» кухня очень напоминает нам типовой операционный процесс: регистрация, согласования, обработка, контроль и т.п. Но надо делать гибко сказали мы и заказчик всячески этому был рад… Когда все, и заказчики и мы, обоюдно пришли в себя после  серии ДевОпс упражнений, выяснилось, что перебрали план трудозатрат на 120 часов. Зато заказчик был доволен, а так соглашусь. Agile интересен…

  • Андрей другой

    Вот с этим я принципиально не согласен: "... но всё же управление услугами не о том, как быть бизнесом, а о том как бизнесу помогать, а это "две большие разницы"."

    Я продолжаю настаивать, что ИТ — это такая же область производства, как и все прочие. Производство, в котором ИТ услуги — продукция. ИТ очень похожи на энергетику. Электричество тоже необходимо для обеспечения бизнеса — обспечения технологических процессов. Но что-то я не слышал, чтобы производство и поставка энергии не считались бизнесом. Отношение к ИТ как к бизнесу означает применение бизнес методов управления — затраты, себестоимость, прибыль, эффективность. Бизнесу нужна помощь ИТ, но не любой ценой.

    • Энергетика хороший пример деятельности, которая на все 100% поддерживает или обеспечивает бизнес. Посыл в том, что в ряде случаев ИТ может не только поддерживать «помогая»,  но и существенно преобразовывать и развивать, становясь драйвером бизнеса. Будут наблюдаться существенные различия в том, какие цели будет ставить перед собой ИТ, как их достижение будет измеряться.

      С остальным согласен: производство, экономика, обеспечение техпроцессов, внутренная организация.Да.

  • Андрей

    А какой посыл? Помимо того, что большиен ИТ проекты должны учитывать еще и бизнес и регуляторов и тд...?

    • Не совсем, то что большие проекты, подчеркну проекты, это должны учитывать и учитывают уже сейчас — не новость. Особенно, если посмотреть на работу проектных центров под госуправлением или в крупном бизнесе.

      Посыл в том, что «быстрые» разработчики тоже должны все это учитывать. Многие любят подчеркивать блеск своего agile величия, демонстрируя его на сравнительно небольших (и на самом деле не очень сложных) standalone приложениях, но мало кто говорит об успехах применения на действительно сложных, гетерогенных, зарегулированных средах. Возьмем к примеру кредитные конвейеры как продукт. В него включены такие составные части как часть (не целиком) АБС, обеспечивающая транзации, блок подготовки данных внутренней отчетности, экспорт данных для регламентированной отчетности, API для контрагентов, модуль проверки юридической чистоты, модуль выявления подозрительных транзакций и противодействия противоправной деятельности, что-то обепеспечивающее налоговый и бухгалтерский учет продаж, интерфейс для менеджеров кредитных линий. Прекрасная бизнес услуга.

      Кто-то может похвастаться успехами на схожем по сложности объекте? Как решаются вопросы контроля архитектуры, зависимости от конкретных разработчиков, вопросы ресурсного обеспечения? Что про все это думают scrum мастеры и владельцы продуктов?

      Но реальная жизнь ещё сложнее. Пусть там будет ещё один продукт в виде розничных продаж со своей командой бизнес-развития. Сразу начинают играть разделяемые ресурсы в виде той же АБС, и т.д. 

      • Андрей

        Ясно, было быб интересно послушать, что об этом говорят скрам мастеры. Самомму любопытно, как гибкие технологие используются в сбербанке. Греф постоянно об этом говорит, но у меня в голове не укладывается. Разве что митинги каждое утро...)


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT