Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Основная цель внедрения гибких практик в разработке ПО - достижение кратного увеличения скорости поставки решений. Это связано с тем, что бизнес работает в конкурентной среде с высокой неопределенностью, где быстрое получение новых возможностей от собственного ИТ является вопросом выживания. При этом гибкие практики направлены именно на кратное ускорение (а не на прибавку в 10-50 процентов), так как преобразования на сложном ИТ-ландшафте стоят очень дорого и без кратного ускорения не окупаются.
Автоматизация позволяет ускорить обработку типовых запросов, минимизировать человеческий фактор и сократить время выполнения задач. Автоматически собираемая информация упрощает взаимодействие с пользователями, а роботы берут на себя рутинные операции. Это освобождает сотрудников от репетитивных задач, позволив сосредоточиться на сложных случаях и улучшении процессов. Примером может служить автоматическая установка приложений, предоставление информации или обработка стандартных запросов, что снижает нагрузку на эксплуатационные команды и повышает удовлетворённость пользователей.
Полный цикл SIP включает следующие этапы: выявление потребности заказчика, проведение анализа, вынесение вопроса на обсуждение, принятие решения (делается/не делается по какой-либо причине), назначение ответственного за задачу, регулярный контроль прогресса выполнения задач и сложностей, реализация изменений с использованием различных организационных инструментов (например, механизмов HR-службы, проектного офиса). После этого цикл повторяется, формируя процесс постоянного улучшения услуг.
Сочетание ролевой модели управления доступом с системой запросов прав доступа дает несколько преимуществ: 1) Возможность автоматической обработки кадровых событий через связь с кадровой системой, что позволяет автоматически назначать или отзывать роли при приеме, увольнении, переводе сотрудников и других событиях. 2) Возможность определения разумного минимума ролей, которые целесообразно поддерживать, вместо попыток охватить все возможные права в ролях. 3) Закрытие временных потребностей в доступе прав, которые не предусмотрены текущим набором ролей. 4) Выявление часто повторяющихся запросов на доступ, что может стать основой для создания новых ролей и оптимизации системы управления доступом.
Аудит CMDB должен проводиться независимыми специалистами из разных технических областей (серверы, сетевое оборудование, рабочие станции), которые понимают предметную область проверки, но не отвечают за актуальность данных CMDB и выполнение процессов изменений. Эти специалисты должны обладать технической экспертизой в своей области, чтобы оценивать корректность данных, но не иметь конфликта интересов, связанного с непосредственной ответственностью за внесение изменений в инфраструктуру. Ответственные стейкхолдеры каждой конфигурационной области должны предоставить экспертов для участия в аудите, гарантируя независимость оценки.
Инструменты Role mining автоматизируют процесс сбора информации о текущих правах сотрудников в информационных системах, анализируют повторяемость этих прав у сотрудников с одинаковыми атрибутами, объединяют права в роли и формируют базовую ролевую модель. Это существенно ускоряет начальный этап построения актуальной ролевой модели, которая отражает текущее состояние системы доступа, уменьшая время разработки с месяцев или лет до более коротких сроков.
Ключевые индикаторы успешного аутсорсинга: 1. Наличие коммерчески ориентированного руководителя, а не ИТ-директора из материнской компании. 2. Система оплаты руководителя, где отсутствие успехов на открытом рынке приводит к снижению зарплаты ниже рыночной, а успешная коммерческая деятельность обеспечивает значительный доход. 3. Аутсорсинг услуг, имеющих альтернативный спрос и предложение на рынке. 4. Наличие четкого бизнес-плана с перспективами коммерческой деятельности на открытом рынке. 5. Разрешение на извлечение прибыли при оказании услуг материнской компании без чрезмерного влияния на доходы руководства аутсорсера.
Для определения владельца сквозного процесса необходимо проанализировать обязательные обязанности этой роли по каждому пункту из выбранного источника (например, ITIL), затем оценить степень критичности каждой обязанности для конкретной организации и процесса, используя, например, десятибалльную шкалу. Где 10 баллов означает, что процесс без выполнения этой обязанности 'не выживет' или уже вызывает проблемы. Полученный приоритизированный список требований покажет, какие полномочия и возможности должны быть у владельца процесса в данной организации. Важно учитывать, что для разных процессов и организаций эти требования могут существенно отличаться в зависимости от критичности процесса, уровня сложности, организационной структуры и культурных особенностей. Например, в организациях, только начинающих внедрять процессный подход, владельец часто должен обладать широкими полномочиями, охватывающими все задействованные подразделения.
Переход к непрерывной поставке ценности позволяет сделать поставку для бизнеса более равномерной и доносить больше ценности в короткий период времени, что ускоряет общий поток создания ценности. Непрерывная поставка устраняет задержки, связанные с ожиданием формирования релизного пакета, и позволяет быстрее отвечать на изменения рынка и потребностей пользователей. Это дает возможность немедленно получать обратную связь от бизнеса, лучше оценивать пропускную способность разработки и более точно прогнозировать сроки реализации требований. Кроме того, непрерывная поставка способствует улучшению качества продукта за счет частого обнаружения и исправления ошибок, а также снижает риск крупных сбоев, которые могут возникнуть при редких, но масштабных релизах.
Наиболее частые ошибки при внедрении систем управления конфигурациями включают: чрезмерный фокус на самом процессе и инструменте, а не на создании ценности для конечных пользователей; попытки собрать слишком много информации без чёткого понимания, кто и как будет её использовать; недостаточное внимание к поддержанию актуальности данных; отсутствие коммуникации и обучения для пользователей о том, как и зачем использовать систему; игнорирование обратной связи от пользователей. Эти ошибки приводят к тому, что CMDB превращается в «базу только для записи», которую никто не использует, и инвестиции в систему не окупаются.