Чтобы избежать дисфункций в команде, связанных с групповыми эффектами, необходимо создать комфортную и безопасную рабочую среду, где участники могут открыто обсуждать свои проблемы и сложности. Важно обеспечить прозрачность процессов и возможность оценивать значимость результатов каждого члена команды, чтобы предотвратить негативное проявление социальной лени. Не стоит пренебрегать мотивацией и вовлеченностью участников в общую цель, так как недостаток этих факторов усиливает дисфункциональные аспекты групповой работы. Избыточная мотивационная накачка тоже вредна, так как может увести в сторону перфекционизма и отрыва от процесса создания ценности. Самоорганизация команды позволяет естественным образом балансировать между разными групповыми эффектами, если менеджер фокусируется на поддержании необходимых условий, а не на контроле людей.

Утверждение «простаивающий ресурс - это потери для бизнеса» может быть ошибочным, потому что простой часто является естественной частью рабочего процесса и может указывать на баланс системы. В системах с последовательными этапами работы небольшие простои на отдельных участках предотвращают перегрузку последующих этапов. Простой может быть сигналом о сбое на предыдущих участках, который нужно изучить, а не маскировать дополнительной работой. Фокус на 100% загрузке ресурсов приводит к перепроизводству и создает заторы в цепочке создания ценности. Таким образом, оптимальная эффективность системы достигается не максимальной загрузкой каждого отдельного ресурса, а сбалансированной работой всей системы.

Альтернативный алгоритм снижает влияние действий других групп путём нормировки не на общее время обработки инцидента Ti, а на установленный срок решения инцидента Ti0. Весовой коэффициент wi для просроченных инцидентов определяется как отношение времени обработки силами данной группы (ti) к сроку решения (Ti0), но не менее 1. Рейтинг ответственности ri рассчитывается по формуле: ri = (ti/Ti0) * (1 - 1/wi) для просроченных инцидентов и ri=0 для решенных в срок. Это позволяет точнее учитывать вклад конкретной группы в просрочку, исключая искажающее влияние задержек на этапах, где данная группа не участвовала.

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

В ABAC проверка филиала и стоимости заказа реализуется через правило, которое сравнивает атрибуты субъекта и объекта. Например, условие «Объект.Филиал = Субъект.Филиал» гарантирует, что менеджер работает только со своим филиалом, а условие «Объект.Стоимость < 1000» ограничивает редактирование заказов суммой до 1000 руб. Эти условия объединяются в логическое выражение, которое проверяется при каждом запросе на доступ.

Процесс архивации статей организован через механизм пересмотра по истечении срока жизни (TTL). Когда срок жизни статьи подходит к концу, эксперт перепроверяет её содержимое и принимает решение: продлить срок её эксплуатации или перевести в архив. Архивированные статьи остаются доступными в отдельном разделе, но помечаются как устаревшие и не рекомендуются к использованию в текущих задачах.

Планирование на 150% загрузки является неэффективным по нескольким причинам. Во-первых, существует высокая вероятность, что запланированная работа не будет выполнена полностью, поскольку физически невозможно работать на 150% своей пропускной способности в течение продолжительного времени. Это приводит к переносам сроков выполнения задач, которые со временем формируют привычку рассматривать задержки как норму. Во-вторых, незавершенные задачи накапливаются, создавая снежный ком задолженностей и просрочек. Такой подход является тупиковым, так как со временем загруженность только увеличивается, а уровень выполнения планов снижается. Более продуктивным является планирование на 90-110% загрузки с акцентом на точное исполнение задач, что позволяет развивать исполнительскую дисциплину и вовремя выявлять реальные проблемы ресурсного обеспечения.

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

Для сбора статистики по трудозатратам на сопровождение CMDB можно применить несколько подходов. Оптимальный подход - ведение полного или выборочного учета трудозатрат, который предполагает 'списание часов' на задачи, выполненные в течение дня. Это позволяет получить точную статистику, на основании которой легко планировать необходимые ресурсы. Если такой учет не поставлен, можно воспользоваться консолидированной статистикой с портала REALITSM.RU, где участники могут делиться своей статистикой и наработками по оценке трудозатрат на сопровождение CMDB. Также можно произвести оценку трудозатрат на основе нормирования отдельных задач сопровождения CMDB в разбивке по группам конфигурационных единиц и ролям специалистов, учитывая требования к компетенциям исполнителя и различную стоимость рабочего времени для разных категорий специалистов.

Стандарты ИТ-управления, такие как ITIL, COBIT и ISO/IEC 20000, предусматривают рекомендации о назначении ответственных за процессы, но не всегда указывают на необходимость выделения отдельной должности. Например, в ITIL говорится о роли Process Owner (Владелец процесса), который отвечает за стратегическое развитие и качество процесса. Однако во многих организациях эта роль совмещается с операционными обязанностями. Стандарты предполагают, что если масштаб процесса достаточно велик, то его управление может стать основной должностью сотрудника. Наличие выделенных менеджеров процессов чаще всего наблюдается в крупных компаниях с высоким уровнем зрелости по моделям, таким как CMMI или ITIL Capability Maturity Model.