Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Наличие общей цели является ключевым условием для существования именно команды, а не просто рабочей группы. В команде люди ведут себя иначе, чем в индивидуальных коммуникациях – проявляются специфические групповые эффекты, обусловленные человеческой психологией. Общая цель объединяет участников, создает основу для самоорганизации и позволяет эффективно использовать групповые эффекты, такие как синергия идей. Без общей цели участники просто делят между собой задачи, формируя рабочую группу, которая работает иначе и требует иного подхода к управлению. Только наличие общей цели позволяет использовать преимущества командной работы и достигать лучших результатов через взаимодействие и коллективные усилия.
В роль-ориентированном подходе окончательный набор прав пользователя формируется в результате пересечения двух множеств: прав, предоставляемых выбранной ролью, и прав, которые допустимы в текущем контексте согласно атрибутным правилам. Система сначала определяет роль пользователя (или набор ролей), получая базовый набор прав, затем проверяет этот набор против атрибутных правил, отфильтровывая те права, которые запрещены в текущих условиях (например, в определенное время суток или при определенном местоположении). В результате пользователь получает только те права, которые разрешены как его ролью, так и контекстом выполнения операции.
Потребности (Север) в модели Compass Model представляют собой основные причины и цели, по которым потребитель обращается к определённой услуге или продукту. Чтобы определить потребности, следует ответить на вопрос: "Что клиент НЕОБХОДИМО должен получить от этой услуги?" Например, для человека, использующего такси при поездке в командировку, основной потребностью будет: "добраться из аэропорта в пункт назначения". Потребности обычно представляют собой базовые, обязательные к выполнению требования, без которых услуга теряет свой смысл. Они формируют фундаментальные ожидания клиента и определяют, будет ли услуга вообще им восприниматься как полезная.
Игнорирование вариативности приводит к неэффективному распределению ресурсов, снижению качества результатов и постоянным срывам планов. Организации, настаивающие на жестких дедлайнах в условиях неопределенности, часто сталкиваются с перегрузкой сотрудников, накоплением технического долга и недовольством заказчиков. В долгосрочной перспективе это может привести к потере конкурентоспособности.
Чтобы избежать конфликта «это не наша вина», важно четко разграничить зоны ответственности, зафиксировав не только то, за что отвечает каждая группа, но и явно указав сферы, за которые они не отвечают. Также необходимо определить параметры качества выполнения работ, задать принципы передачи задач между группами и внедрить централизованный контроль. Например, фиксация в документации того, что за обновление связей прикладного ПО с серверами отвечают прикладники, которые устанавливают ПО, поможет избежать подобных споров.
Ошибка восприятия канбана как простого списка задач заключается в том, что канбан – это не только визуализация задач, сложенных по статусам ("Надо сделать", "Делаем", "Сделано"), но и инструмент управления потоком работы. Настоящий канбан позволяет выявлять узкие места процесса, устанавливать ограничение на количество задач в работе одновременно (WIP limit) и организовывать вытягивающую систему производства, где следующий этап берёт задачу только после освобождения предыдущего этапа. Простое размещение задач на доске без соблюдения этих принципов не делает процесс настоящим канбаном.
Для улучшения качества обслуживания клиентов в сфере совместного использования автомобилей компании должны: внедрить систему обучения сотрудников первой линии поддержки с упором на решение типовых проблем и правильную маршрутизацию запросов, создать четкие регламенты обработки обращений с присвоением номеров заявок и возможностью их отслеживания, разработать внутренние процессы для оперативного возврата средств при технических сбоях, регулярно информировать клиентов о статусе их обращений, назначить ответственных сотрудников за решение проблем на второй линии поддержки, ввести систему обратной связи после решения проблемы, провести анализ причин возникающих проблем и внедрить меры по их предотвращению, а также регулярно собирать и анализировать отзывы клиентов для постоянного улучшения сервиса. В условиях активно развивающегося рынка с несколькими игроками такие меры помогут выделиться на фоне конкурентов и привлечь новых клиентов.
Для распределения стоимости услуг по потребителям существуют несколько методов. Самый простой метод – пропорциональное распределение на основе количественных показателей потребления, таких как количество пользователей, объем обрабатываемых данных или время использования. Более сложный метод – Activity-Based Costing (ABC), который учитывает различные виды деятельности, необходимые для предоставления услуги, и распределяет издержки на основе реального потребления ресурсов. Также применяется метод распределения по ключевым показателям эффективности (KPI), когда стоимость распределяется в зависимости от важности услуги для достижения стратегических целей бизнеса. Выбор метода зависит от сложности ИТ-инфраструктуры, требований к точности расчетов и уровня зрелости бюджетного процесса в компании.
Совместное создание ценности в сервисных отношениях — это процесс, при котором поставщик и клиент работают вместе для достижения желаемых результатов. Поставщик услуг помогает клиенту достичь его целей, принимая на себя некоторые риски и затраты, которые клиенту пришлось бы нести самостоятельно. Клиент получает ценность через достижение результатов без владения ресурсами и управления рисками, а поставщик получает собственную ценность через оплату, развитие возможностей и укрепление отношений. Обе стороны выигрывают от успешного сервисного отношения.
Продукт-ориентированный подход положительно влияет на устранение дефектов, так как строит отношения между владельцем продукта и командой таким образом, что команда заинтересована в качестве продукта и понимает подразумеваемые требования. В отличие от модели 'заказчик-исполнитель', где исполнитель не обязан думать за заказчика, продуктовый подход создает среду, где команда включает голову и распознает дефекты даже без явного указания в требованиях. Например, команда, работающая в продуктовом подходе, сразу поймет, что баннер не должен загораживать кнопку, без специальной формулировки этого требования. Это уменьшает количество споров и ускоряет процесс устранения дефектов, так как команда более вовлечена в результат.