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

Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Questions and answers
6130+

вопросов и ответов

Authors
25

авторов

Sources
440+

источников

Original
100%

оригинальный контент

Ключевые вопросы: объём поставки уменьшился по сравнению с предыдущими периодами? Количество дефектов и доработок стремится к нулю? Скорость обработки задач удовлетворяет заказчиков? Если ответы отрицательные, необходимо искать корневые причины внутри команды: не хватает ли стандартов работы, есть ли системные риски или блокировки, эффективны ли инструменты. Важно переходить к обсуждению процессов только после оценки результатов поставки.
Agile и гибкие методы разработки ПО DevOps, CI/CD ISO 20000 бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа разработка ПО управление проблемами управление рисками
Светлана Сапегина (источник). Рейтинг вопроса: 423
В статье Gene Kim описаны принципы «Постоянный быстрый поток обратной связи» и «Креативная культура высокого доверия». Первый принцип подразумевает систему, где информация об ошибках передаётся обратно по производственной цепочке как можно быстрее для их оперативного устранения, предотвращая распространение дефектов к конечному потребителю. Второй принцип фокусируется на создании культуры, где поощряется экспериментирование, анализ как успехов, так и неудач, и понимание важности практики и повторения для достижения мастерства.
Agile и гибкие методы разработки ПО DevOps, CI/CD бизнес, ценность, бизнес-заказчик Канбан, WIP-лимиты разработка ПО управление продуктами, продуктовый подход управление процессами, ИТ-процессы
Игорь Гутник (источник). Рейтинг вопроса: 423
Потребители услуг могут извлекать различные побочные ценности помимо основных заявленных выгод. К ним относятся: возможность подсмотренных у поставщика идей организации работы и внедрения лучших практик; новые деловые контакты, полученные через взаимодействие с поставщиком; повышение компетенций собственных сотрудников через обучение у поставщика услуг; улучшение репутации на рынке за счет сотрудничества с известным поставщиком. Эти ценности часто не являются предметом договора и не оплачиваются отдельно, но существенно увеличивают общую пользу от использования услуг и могут влиять на долгосрочные решения о выборе поставщиков.
аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик обучение сотрудников, учебные курсы, тренинги постоянное улучшение, совершенствование, CSI, PDCA управление отношениями, взаимодействие, BRM управление релизами эффективность, оптимизация
Роман Журавлёв (источник). Рейтинг вопроса: 423
В контексте процесса «Управление проблемами» понятие «ошибка» не ограничивается традиционным пониманием бага в программном коде. Ошибка может представлять собой сложное сочетание конфигурационных единиц и условий их эксплуатации, приводящее к возникновению инцидентов. Это может быть конструктивная особенность инфраструктуры или системы, которая при определенных условиях приводит к нежелательным результатам. Таким образом, термин охватывает не только явные дефекты, но и особенности, которые ведут к инцидентам при определенных условиях эксплуатации.
Agile и гибкие методы разработки ПО разработка ПО управление инцидентами управление конфигурациями, CMDB управление проблемами
Игорь Гутник (источник). Рейтинг вопроса: 423
Модель Value network помогает в управлении сложными ИТ-отношениями внутри компании, предоставляя более адекватный фреймворк для описания нелинейных и многомерных взаимодействий между подразделениями. В отличие от линейной модели Value chain, Value network учитывает множественность отношений: подразделения могут быть одновременно и заказчиками, и потребителями услуг; один ИТ-продукт может иметь несколько заказчиков; функции заказчика и плательщика могут быть разделены. Это позволяет более точно моделировать внутренние сервисные отношения, выявлять точки напряжения (такие как проблема разделения заказчика и плательщика), и разрабатывать решения, которые учитывают сложную природу внутренних корпоративных взаимодействий, включая построение четких аллокационных моделей и определение ответственности за различные аспекты ИТ-услуг.
бизнес, ценность, бизнес-заказчик общие вопросы менеджмента управление отношениями, взаимодействие, BRM управление продуктами, продуктовый подход
Дмитрий Исайченко (источник). Рейтинг вопроса: 423
Определение заинтересованных сторон (стейкхолдеров) в коммуникационном процессе включает выявление всех лиц и групп, которые прямо или косвенно участвуют в деятельности проекта или процесса, а также тех, кто заинтересован в его результатах. Это могут быть сотрудники, руководители разных уровней, клиенты, поставщики, внешние партнеры и даже конечные пользователи продукта или услуги. Для каждого выявленного стейкхолдера необходимо определить его потребности в информации, уровень влияния на проект и заинтересованность в его результатах. Важно учитывать, что требования к информации у разных групп стейкхолдеров могут сильно различаться: руководство может нуждаться в обобщенных отчетах по ключевым показателям, а исполнители — в детальных инструкциях по выполнению задач. Процесс выявления стейкхолдеров является постоянным, так как по мере продвижения проекта могут появляться новые заинтересованные стороны.
аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление продуктами, продуктовый подход управление проектами, PRINCE2
Елена Колбей (источник). Рейтинг вопроса: 423
Быстрые победы в организации SLM маловероятны, потому что процесс требует времени для поиска подходящих ответственных людей с обеих сторон, их вовлечения в работу и формирования взаимопонимания. Построение эффективного взаимодействия зависит от личностных качеств участников и требует проведения множества встреч для выравнивания понимания сути услуги и распределения ответственности. Этот процесс не может быть завершен за короткий срок и обычно занимает месяцы.
общие вопросы менеджмента управление отношениями, взаимодействие, BRM управление уровнем услуг, SLM
Дмитрий Исайченко (источник). Рейтинг вопроса: 423
Применение OLA может быть полезным только после серьезного анализа целесообразности. Если планируется внедрение сервисного подхода внутри компании, это не обязательно требует использования OLA. Особенно если речь идет об OLA в пределах ИТ-подразделения. Введение OLA означает включение сервисных отношений внутри ИТ-подразделения, что приводит к изменениям в организационной структуре, процессах и создает риск излишней автономности подразделений. Также появляется задача контроля выполнения обязательств внутренними поставщиками. Однако такие последствия могут как помочь, так и навредить, поэтому решение о применении OLA должно быть обоснованным и приниматься в каждом конкретном случае, а не быть универсальной рекомендацией.
аутсорсинг, интеграция услуг общие вопросы менеджмента управление релизами управление рисками управление уровнем услуг, SLM
Дмитрий Исайченко (источник). Рейтинг вопроса: 423
При реализации изменений через SIP могут быть использованы различные организационные инструменты. Примерами таких инструментов являются механизмы HR-службы (для управления персоналом и вовлеченностью сотрудников), проектного офиса (для контроля выполнения проектов и сроков), а также другие внутренние процессы организации, направленные на управление изменениями. Эти инструменты помогают обеспечить ответственность за выполнение задач, контроль прогресса и решение возникающих сложностей при реализации изменений по улучшению услуг.
общие вопросы менеджмента постоянное улучшение, совершенствование, CSI, PDCA управление изменениями управление проектами, PRINCE2 эффективность, оптимизация
Денис Денисов (источник). Рейтинг вопроса: 423
Длительность тестирования результативности решения проблемы определяется частотой проявления самой проблемы и не поддается стандартной нормировке. Например, если проблема проявляется ежедневно или регулярно, тестирование можно выполнить за короткий период времени (2-3 дня). Однако если проблема связана с квартальной отчетностью и проявляется только раз в квартал, время тестирования может занять до трех месяцев или до следующего начала квартала (в зависимости от того, когда было применено решение). Для проблем, которые проявляются нерегулярно и не имеют предсказуемой периодичности, определение срока тестирования становится еще более сложным и индивидуальным.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды
Дмитрий Исайченко (источник). Рейтинг вопроса: 423
« 1 ... 491 492 493 ... 614 »