Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Если руководителю в RACI-матрице закреплено несколько задач с пометкой R (Responsible - непосредственный исполнитель), следует предпринять следующие действия: первоначально рассмотреть возможность делегирования этих задач другим сотрудникам, полностью или частично. Так как время руководителя ограничено и должно использоваться максимально продуктивно, все задачи, которые могут быть выполнены другими сотрудниками, стоит делегировать как можно быстрее. Если после попыток делегирования все еще остается несколько R-позиций, необходимо четко определить, кто именно отвечает за организацию процесса выполнения работы (это может быть не только руководитель), а кто просто участвует в реализации задачи. Это помогает избежать путаницы и наложить ответственность за разные аспекты работы на разных людей, что повышает эффективность выполнения задач.
RFID-ворота не всегда обеспечивают полную автоматизацию учета оборудования из-за физических особенностей считывания. Элементы, расположенные по краям тележки, могут легко считываться, тогда как оборудование, размещённое в глубине или экранированное другими предметами, может проходить незамеченным. Это связано с тем, что сигнал RFID-меток ослабляется, если между меткой и сканером находятся препятствия, особенно содержащие металл. Такие ситуации приводят к ошибкам в учете, делая систему менее надежной по сравнению с ожидаемым уровнем автоматизации.
Из провала проекта можно извлечь несколько важных уроков: важно своевременно проводить ретроспективы и выделять пункты для улучшения по таким аспектам, как коммуникация, распределение ролей, взаимодействие и отчетность. Необходимо вовремя задавать уточняющие вопросы заказчику, чтобы понимать его реальные потребности. Также важно не откладывать кардинальные изменения до последнего момента и быть готовым к оперативной адаптации планов. Ключевым уроком является то, что даже самый безнадежный проект можно спасти при наличии воли ключевых участников и слаженной работы всей команды.
Структура IT4IT первого уровня (Level 1) представлена через призму потоков создания ценности (Value Streams), где все элементы модели выстроены вокруг сервисной модели (Service Backbone) как основы. Это создает более явную и структурированную картину того, как различный ИТ-активы взаимодействуют для создания ценности. В ITIL v3 структура основана на жизненном цикле услуги (Service Lifecycle), представленном как последовательность фаз: стратегия, дизайн, переход к эксплуатации, эксплуатация и непрерывное улучшение. В то время как ITIL v3 фокусируется на том, что происходит с услугей на разных этапах ее жизни, IT4IT Level 1 делает акцент на том, как потоки работы проходят через организацию для создания этой услуги. IT4IT Level 1 предоставляет более явные связи между бизнес-потребностями и ИТ-реализацией через Value Streams, тогда как ITIL v3 предоставляет более детализированный взгляд на управление самой услугой на разных этапах ее жизненного цикла.
Важно получать обратную связь от пользователей с умеренной удовлетворенностью, так как именно они составляют большую часть аудитории и их опыт наиболее близок к среднему уровню качества обслуживания. Если система обратной связи настроена так, что собирает только крайние оценки (очень довольные или очень недовольные), организация не сможет понять, насколько ее услуги удовлетворяют основную массу клиентов. Это приведет к искаженной картине и неправильным решениям при улучшении услуг. Баланс всех типов отзывов дает более полное представление о реальном состоянии дел.
Периодическая смена ролей внутри компании, например, когда менеджеры временно работают в роли сотрудников линии фронта или самих клиентов, способствует развитию эмпатии, так как позволяет по-настоящему почувствовать, что переживают другие. Такой подход дает возможность увидеть процессы и взаимодействия с новой стороны, понять сложности и потребности тех, кто находится «на острие» контакта с клиентами или сам является клиентом. Это помогает менеджерам лучше понять, какие улучшения необходимы в процессах обслуживания, а также формирует у сотрудников более глубокую связь с реальными проблемами и потребностями клиентов. Периодическая смена ролей также способствует укреплению командной работы, так как все члены команды лучше понимают задачи и сложности друг друга, что создает более дружелюбную и поддерживающую атмосферу внутри компании.
Бывшие руководители могут занять роли, где их знание предметной области и особенностей компании будет использоваться наиболее эффективно. Например, они могут стать экспертами в определённых областях, консультантами для новых команд или заниматься межкомандной координацией. Некоторые могут взять на себя роль наставников для новых участников, помогая им адаптироваться в компании и понять контекст её работы. Также возможно использование их опыта для создания обучающих программ или документирования знаний, которые ранее не были фиксированы. Однако важно избегать создания искусственных должностей, чтобы не увеличивать издержки компании, сохраняя при этом ценность их знаний.
ITIL 4 изменяет традиционное понимание управления услугами, представляя ценность как результат совместного создания поставщиком и потребителем, а не как одностороннюю поставку от организации к клиенту. В отличие от предыдущих версий, где фокус был преимущественно на внутренних процессах организации, ITIL 4 подчеркивает необходимость учета роли потребителя в создании ценности. Это выражается в четком разделении деятельности на предоставление (service provision) и потребление услуг (service consumption), признании что обе эти деятельности необходимы для достижения результата. Такой подход требует пересмотра традиционных моделей ИТ-управления и интеграции пользовательского опыта в основные процессы.
Формирование плановой стоимости ИТ-услуг включает несколько важных этапов. Первый этап – идентификация всех услуг, предоставляемых ИТ-отделом, и определение целевых потребителей каждой услуги. Второй этап – сбор данных об используемых ресурсах для каждой услуги, включая прямые затраты (зарплаты, оборудование, лицензии) и косвенные издержки (управленческие расходы, аренда). Третий этап – выбор методологии распределения косвенных издержек, которая может быть основана на трудозатратах, использовании мощности или других показателях. Четвертый этап – определение структуры стоимости с выделением фиксированной и переменной составляющих. Пятый этап – калибровка плановых значений на основе бизнес-планов и прогнозов потребления услуг, что позволяет учитывать изменения в масштабах бизнеса и требованиях к качеству услуг.
После этапа, когда работа считается завершенной после подтверждения тестировщиком, следующим этапом в эволюции Definition of Done является Agile-подход, при котором работа считается завершенной после того, как владелец продукта принял результат разработки. В соответствии с подходами, такими как SAFe, владелец продукта является единственным членом команды, который может принимать истории как выполненные, что включает проверку соответствия критериям Definition of Done. Для больших организаций этот процесс усложняется дополнительными уровнями приемки: на уровне команды, системы, решения и релиза.