Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Частые ошибки при организации контроля: отсутствие четкой фиксации задач и решений, что приводит к потере информации; избыточная бюрократизация системы контроля, делающая ее непрактичной; нерегулярное проведение контрольных точек или игнорирование установленного графика; отсутствие обратной связи при выявлении отклонений; слишком жесткий контроль даже для ответственных сотрудников, что снижает мотивацию; чрезмерная зависимость от одного канала коммуникации или инструмента для контроля без резервных вариантов.
При попытке сохранить традиционных руководителей в новых организационных структурах возникают несколько ключевых проблем. Прежние руководители часто не обладают нужными навыками для новых ролей, связанных с самоорганизующимися командами. От них требуются не только управленческие навыки, но и готовность экспериментировать, умение создавать новую культуру работы и временные ограничения своей роли. Простое переименование руководителей в тим-лиды без глубокого изменения подхода приводит к сохранению старых практик и неэффективности. Кроме того, высокие зарплаты и бонусы прежних руководителей становятся экономической проблемой, если их непосредственный вклад в результат сокращается.
В ИТ-сфере преобладает культура, ориентированная на инновации и быстрые результаты. Работа по плановому совершенствованию не приносит таких ярких побед и видимых достижений, как разработка новых продуктов или решение сложных задач. Поэтому она менее заметна и не получает должного признания. Кроме того, система поощрений и карьерного роста часто ориентирована на проектные успехи, что делает работу по улучшению существующих процессов менее привлекательной с точки зрения карьеры и финансового вознаграждения.
Cj и Sj связаны между собой через операнд Nj, который определяется как сумма этих величин: Nj = Cj + Sj. Здесь Cj — количество обращений, обработанных j-той группой и закрытых без рекламаций, а Sj — количество возвратов на доработку в эту группу. Эти два показателя вместе формируют полную картину обработанных обращений, участвующих в расчёте метрики First Time Resolution (FTR), и позволяют корректно отразить качество работы группы.
Правильный подход к приоритизации задач должен учитывать, что при повышении приоритета одной задачи происходит автоматическое понижение приоритета всех остальных задач. Нужно осознавать, что ресурсы на другие задачи будут снижены, и к ним приступят позже. Следует оценивать, согласны ли заинтересованные лица по остальным задачам с таким решением, и какие последствия это может иметь. Также важно понимать, что частая смена приоритетов создает системные потери и замедляет выполнение всех задач. Правильная приоритизация требует фиксации приоритетов и работы над задачами без их пересмотра, как только работа над ними началась. Важно формировать портфель задач так, чтобы можно было прогнозировать ритм и время выполнения с учетом стабильной скорости работы.
В крупных компаниях регламентация активности необходима для обеспечения стабильности и предсказуемости в операционной деятельности. Без чётких процессов и правил сложно организовать работу большого числа сотрудников, так как каждый может выполнять задачи своими способами. Регламентация помогает устранить хаос, минимизировать ошибки и сделать работу компании более эффективной в долгосрочной перспективе.
Наличие документа об архитектурных и технологических стандартах является признаком зрелости ИТ-управления компании потому, что такие документы создаются у единичных, обычно крупных и наиболее зрелых в вопросах регламентирования деятельности компаний. Реализация единой архитектурной политики требует высокого уровня организации ИТ-процессов, понимания долгосрочных целей развития инфраструктуры и наличия компетенций в области ИТ-архитектуры. Такой документ определяет допустимые языки и среды разработки, используемые платформы и СУБД, механизмы развёртывания и настройки локаторов прикладных серверов и middleware, требования к интерфейсам, резервированию, мониторингу и журналированию. Наличие чётко прописанной технологической и архитектурной политики свидетельствует о том, что компания стремится к стандартизации и унификации своих ИТ-решений, что снижает операционные риски и затраты на сопровождение, повышает качество и безопасность разрабатываемых и эксплуатируемых систем.
Структура фактора влияния COBIT 5 позволяет организовать систему измерений и оценки процесса управления изменениями через четыре ключевых аспекта: заинтересованные стороны, цели (с разделением на прямое и контекстуальное качество), хорошие практики и жизненный цикл. Для каждого аспекта можно определить соответствующие метрики: для прямого качества - своевременность изменений и удовлетворенность пользователей, для контекстуального - долю стандартных и экстренных изменений, для практик - полноту реализации ключевых практик COBIT, для жизненного цикла - полноту выполнения этапов PDCA. Такой системный подход помогает избежать несоответствия измерений и целей процесса, а также определить конкретные области для улучшения.
После завершения деловой игры важно обсудить следующие вопросы: насколько эффективно взаимодействовали участники разных ролей, какие сложные проблемы пришлось решать по пути к цели, что можно было сделать лучше, и какие выводы можно применить в реальной работе. Также необходимо проанализировать, действительно ли достигнутый результат отражает качественное выполнение задач или связан со случайными факторами. Эти вопросы помогут сформулировать конкретные рекомендации для улучшения будущей деятельности.
Существует несколько альтернативных вариантов организации управления доступностью. Один из наиболее распространенных — объединение с управлением непрерывностью, как это предусмотрено в ISO/IEC 20000. Также управление доступностью может быть частью управления мощностями (COBIT5, CMMI для сервисов) или включено в функцию надежности (MOF). В некоторых подходах, например, ISM Method, управление доступностью рассматривается как компонент управления качеством. В реальной практике управление доступностью может быть распределено между разными командами и процессами в зависимости от организационной структуры и выбранной методологии.