Business Agility, DevOps, ITIL, ITSM, COBIT, PRINCE2, TOGAF, Kanban...
14 лет в эфире. 3 000 записей. 10 000+ постоянных подписчиков.
В редакцию портала поступил вопрос: Разрабатываю документ с описанием процесса управления изменениями и попутно разрабатываю сам процесс. Вопрос: у кого-нибудь в компании есть учет изменений кроме как в системе управления заявками и проводятся ли их одобрения CAB или чем-то подобным? Если есть описания этого процесса, то просьба, хотя бы кратко, привести в ответах. Спасибо!
В редакцию портала поступил вопрос: Вопрос про конвеер заявок. Допустим поступает 5 заявок на 4х сотрудников. 4 раздаются автоматом, а как бысть с 5й? Варианты: 1) Заявка висит в очереди, пока кто-то не освободится и не закроет свою, а после этого назначается на первого освободившегося. 2) 5 заявка назначается сотруднику 1, 6-я — сотруднику 2. В итоге сотрудники уже имеют в работе по 2 заявки одновременно. Но тогда появляется ситуация, что OLA (расчетное время выполнения одной задачи) посчитано по одной заявке, а время идёт сразу по двум (т.е. получаем что либо сотрудник должен в два раза быстрее теперь справиться, либо…
Прочитал на днях записки одного бизнесмена. В них он описывает стадии развития своей компании. По его мнению, таких стадий три (я думаю, что только ими весь генез не исчерпывается, но это текущее мироощущение автора тех записок). Краткий пересказ. Стадия 1. “Я лидер, я сказал!”. На этой стадии самый “умный” – лидер. Остальные – его “слуги”. Лидер говорит, что им делать, они выполняют. Задача лидера на данной стадии развития компании – говорить, что именно, и кому делать. Стадия 2. “Бюрократия”. Описаны процессы, прописаны регламенты. Внедрены штрафы. Система! Всё крутится, работает ровно, но ошибки всё равно возникают. Ищут виновных, потом наказывают, штрафуют….
Вокруг любого управленческого подхода со временем выстраивается огромное количество заблуждений и мифов. Это обусловленно особенностью людей по-разному понимать одни и те же вещи и желанием интерпретировать факты в своих интересах. Канбан, как метод определения, управления и совершенствования сервисов, при разработке интеллектуальных продуктов, сравнительно молод, но уже успел обзавестись своей мифологией. Разработчики Kanban Tool (инструмента для визуализации потока) в своем блоге постарались разобрать наиболее распространенные мифы, возникшие из-за неправильного понимания принципов Канбан. «Канбан на самом деле не метод организации рабочего процесса, а инструмент улучшения рабочего процесса.» Часто говорят, что Канбан – это инструмент для создания знаний, а не метод управления рабочим…
Такую фразу довольно часто можно услышать или прочитать в обсуждении новой версии ITIL® 4. Корректно ли это утверждение? Насколько «вместо»? Есть ли разница между процессами и практиками? Действительно, существенную часть объёма книги составляет раздел, в котором для тех, кто знаком с предыдущими версиями ITIL, очень много знакомых названий: «Управление инцидентами», «Управление проблемами», «Управление доступностью», «Управление уровнем услуг», «Управление поставщиками» и т.д.Только теперь это названия не процессов (process), а практик (practices).Понятие «процесс» в ITIL 4, конечно же, есть. Определение его стандартное (в том смысле, что оно совпадает с аналогичным определением в ISO/ГОСТ): «Набор взаимосвязанных или взаимодействующих видов деятельности, который преобразует входы…
В редакцию портала поступил вопрос: Доброго дня! посмотрела видео с запуска ITIL 4 – спасибо! В списке практик искала Event management – не нашла, но удовлетворилась пояснением, что практики могут содержать несколько процессов и, вероятнее всего, event management не будет потерян и забыт. Затем решила проверить, а сдам ли я ITIL 4 foundation и скачала Sample paper с вопросами. На третьем вопросе возникла коллизия: “Which is the purpose of the ‘monitoring and event management’ practice?” Да, на него можно ответить, зная ITIL v3, но… ведь практики-то такой нет формально. Или я чего-то недопоняла, пожалуйста, поясните.
Компании, которые выстраивают свой конфигурационный учет впервые всегда сталкиваются с вопросом: “Как нам учитывать приложения при построении моделей конфигурации наших ИТ-услуг”. Для иллюстрации приведем абстрактный пример: в компании есть некоторая многофункциональная информационная система. Пользователи используют ее для осуществления своих рабочих обязанностей, потребляя какие-то ресурсы: лицензии, подключения, мощности хранения и/или производительности. Система размещена на пуле виртуализированной вычислительной архитектуры и мощностях хранения данных, использует сетевые возможности и каналы связи для работы на различных площадках. Компания хочет уметь рассчитывать себестоимость ИТ-услуг, а также уметь оценивать влияние сбоев и изменений в инфраструктуре и приложениях. Схема, изображенная на рисунке выше, хороша только для того, чтобы…
В своей свежей статье Paul Wilkinson делится с нами немного юмористическим “классификатором компаний”, прокладывающих свой путь к “состоянию DevOps” или только планирующих в него перейти. Кто хочет стать “единорогом“? Найдите себя (текущего или будущего) в этом списке. И постарайтесь быть объективными. Классификация, предложенная автором, появилась не случайно. На её создание автора натолкнули вопросы, стоящие перед компаниями, представители которых принимали участие в бизнес-симуляции “Проект Феникс – DevOps на практике“. Многие из них пытались оценить текущий или перспективный уровень своих DevOps-практик, опираясь на какую-то понятную классификацию. Итак, вот она! Работает “по запросу” Движется наугад Цель не ясна Слепо следует рекомендациям “хороших практик”…
В каком случае изменения могут быть стандартизованы и выполняться, как запросы на обслуживание? Вопрос, безусловно, уже с бородой. Однако он по-прежнему не теряет своей актуальности. Во всяком случае, слушатели курса ITIL RCV задают его снова и снова. Одним из тезисов, вносящих некоторую путаницу в понимание, является следующий: стандартные изменения являются “заранее авторизованными”. На самом деле это вовсе не означает, что стандартные изменения не требуют никакой авторизации. Давайте вспомним, что сказано про стандартные изменения в ITIL V3 (перевод текста источника здесь и далее выполнен автором заметки): Стандартное изменение – это изменение услуги или другой конфигурационной единицы, для которого управлением изменениями заранее…
ИТ-системы продолжают расти в количестве, масштабах и важности для бизнеса. Мы иногда упускаем из виду, что для каждой системы, которую ИТ внедряет в бизнес, существует сообщество пользователей, полагающихся на эти системы, выполняя свои повседневные задачи. Эта зависимость все больше возрастает, и теперь каждый бизнес в большей степени полагается на технологии для выполнения важных повседневных задач, не зависимо от размера организации. Это означает, что мы, ИТ-специалисты, должны тратить больше времени, энергии и сосредоточиться на удобстве работы пользователей. Пользователь может быть внутренним сотрудником, партнером по бизнесу, посредником, консультантом или иным ценным клиентом. И каждый из них нуждается в удобном пользовательском интерфейсе. Системами…
9 апреля в Москве пройдёт AI Conference — конференция для предпринимателей о применении искусственного интеллекта в бизнесе. Доклады конференции делятся на три блока: ИИ для компаний. Примеры эффективной автоматизации бизнес-процессов: логистики, производства, закупок и других. ИИ для клиентов. Спикеры расскажут, как персонализировать коммуникацию с клиентами до того, как они уйдут к конкурентам. ИИ для государства. Вызовы индустрии, роль государства в ее развитии, стандартизация — и как все это повлияет на бизнес. В каждом блоке будут свои кейсы — спикеры разберут их по схеме «проблема — решение — результат». В рамках конференции будет работать демозона. AI Conference пройдет в «Технополисе «Москва»…