Согласно ITIL 4, при формировании сервисного предложения (service offering) используются три типа сущностей: 1. Товары (goods) – то, что передаётся потребителю, после чего сам потребитель отвечает за их использование (например, wifi-маршрутизатор в подарок при подключении домашнего интернета). 2. Доступ к ресурсам – ресурсы, к которым получает доступ потребитель (например, сеть, к которой подключается абонент, или почтовый/прокси/p2p сервер). 3. Сервисные операции (service actions) – деятельность, выполняемая представителями поставщика, потребителя или ими совместно (например, взаимодействие со службой поддержки). Эти три типа сущностей позволяют комплексно описать то, что поставщик услуги предлагает потребителю.

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

Эпики в процессе разработки продукта находятся между инициативами и пользовательскими историями и служат в первую очередь для наглядной иллюстрации и объяснения покрытия общей формулировки инициативы очень частными определениями историй. Эпики не являются объектами обработки для команды, так как они слишком велики, не имеют строгого самостоятельного Definition of Done, который не является просто компиляцией дочерних требований. Они выполняют роль промежуточного уровня детализации между стратегическими инициативами и конкретными историями.

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

Интерес к теме канбана среди участников конференции проявился уже в первой половине дня, когда несколько человек упомянули, что мастер-класс проводится без регистрации и вход свободный. К началу мероприятия более половины мест для активных участников было занято, а также собралась группа из 20-25 наблюдателей, что в сумме составило около 50-55 человек. Некоторые участники даже спрашивали, можно ли присоединиться к мастер-классу в роли наблюдателей. Живой интерес проявлялся также в активной работе групп, задаваемых вопросах и в том, как участники кивали в знак согласия с важными идеями, обсуждаемыми в ходе занятия.

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

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

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

Основная проблема двухдневного формата курса "Основы DevOps" заключалась в том, что весь материал не укладывался в отведённое время. В курсе было предусмотрено около двадцати точек для обсуждения, восемь практических заданий и более сотни слайдов. Все эти элементы было невозможно пройти за два дня, что приводило к недостаточному освоению материала участниками.

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