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

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

25
авторов

440+
источников

100%
оригинальный контент
Основные стандарты управления бизнес-непрерывностью включают ISO 22301:2012 (Societal security – Business continuity management systems – Requirements), который устанавливает требования к системе управления непрерывностью бизнеса; ISO 22313 (Societal Security – Business continuity management systems – Guidance), содержащий руководство по реализации требований ISO 22301; ISO 27031 (Guidelines for ICT Readiness for Business Continuity), описывающий вопросы управления ИТ-системами, и ГОСТ Р ИСО/МЭК 18044-2007, касающийся менеджмента инцидентов информационной безопасности.
Аллокация стоимости ИТ-услуг - это процесс распределения затрат на предоставление ИТ-услуг между заказчиками или подразделениями компании. Это важно по нескольким причинам: во-первых, позволяет заказчикам видеть реальную стоимость потребляемых услуг и принимать более экономически обоснованные решения; во-вторых, создает основу для возмещения стоимости ИТ-услуг в будущем, что делает сервисные отношения более прозрачными и двусторонними; в-третьих, способствует более ответственному отношению бизнес-подразделений к потреблению ресурсов, так как их руководители начинают отвечать за прибыльность своего направления, включая ИТ-затраты. Однако простое распределение расходов недостаточно - необходимо изменение организационной структуры, чтобы бизнес-подразделения реально отвечали за ИТ-затраты в рамках своей финансовой отчетности.
Основные проблемы при управлении доступом включают высокий уровень инцидентов безопасности из-за нарушения стандартных процедур выдачи прав, длительные сроки предоставления доступа новым сотрудникам (например, выдача прав может занимать несколько дней), постоянные замечания аудиторов по поводу непрозрачности системы предоставления прав (отсутствие записей о том, кто предоставил доступ, на каком основании и почему были внесены изменения). Эти проблемы приводят к уязвимостям в безопасности, замедлению бизнес-процессов и несоответствию требованиям внутреннего и внешнего аудита.
В потоке создания ценности не должно быть этапа 'Отложено', потому что этот этап не добавляет ценность к конечному результату. Задача, находящаяся в состоянии 'Отложено', не приближается к завершению и не генерирует никакой ценности. Кроме того, такой этап приводит к потере фокуса на завершении взятых обязательств, делает поток непредсказуемым по времени выполнения, снижает скорость работы, создает неравномерность течения, вызывает устаревание задачи и потери контекста у команды. В потоке после принятия обязательств команда должна сосредоточиться на скорейшем выполнении задачи, а не на ее откладывании.
Разделение этих понятий помогает сместить фокус от формальных показателей (output) к реальной пользе для заказчика (outcome). Это снижает риск создания продуктов или услуг, которые, хотя и отвечают формальным требованиям, не решают реальные проблемы клиентов. Такой подход способствует повышению удовлетворённости клиентов и выявлению истинной ценности предоставляемых услуг.
Централизованный элемент в модели RBAC (Role-Based Access Control) - это использование ролей. Именно на основания ролях строится вся система управления доступом. Роли представляют собой набор разрешений, которые позволяют пользователям выполнять определенные действия с различными ИТ-ресурсами. В RBAC доступ к ресурсам предоставляется не напрямую пользователям, а через роли, которые затем назначаются пользователям. Это обеспечивает более гибкое и эффективное управление доступом по сравнению с другими моделями.
Role-Based Access Control (RBAC) - это подход к управлению доступом, основанный на назначении пользователей ролям. RBAC состоит из четырех основных компонентов: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро - это обязательный компонент, который определяет минимально необходимый набор элементов (пользователи, роли, права доступа, операции и объекты) и связей для построения системы управления доступом. Оно реализует основную идею RBAC - объединение прав доступа в роли и последующее назначение ролей пользователям вместо прямого назначения прав доступа. Иерархичность добавляет возможности наследования прав между ролями. Статическое и динамическое разделение обязанностей вводят правила ограничений на назначение и совмещение ролей.
Удовлетворённость сотрудников напрямую влияет на формирование лояльности клиентов компании. Лояльный сотрудник это удовлетворённый условиями своей деятельности человек чья профессиональная компетентность и манера исполнения обязанностей определяет качество взаимодействия внутренних подразделений. При этом повышение уровня удовлетворённости сотрудников ведёт к улучшению их отношения к внутренним клиентам что в конечном итоге положительно сказывается на работе всей компании и удержании внешних клиентов.
Основные проблемы реализации «доски аварий» связаны со сложностью точного определения влияния инфраструктурных инцидентов на конечные ИТ-услуги. Например, влияние может быть отложенным или незаметным для пользователей, а простое отображение упавшего сервера без контекста может привести к ложным выводам. Для точной оценки требуется детальный анализ связей между компонентами, что противоречит идее «быстрого и наглядного» отображения. Дополнительная сложность — необходимость тщательного описания связей в CMDB для прогнозирования влияния на услуги.
Понимание разницы между выходами и результатами помогает не просто создавать продукты и отчёты, а действительно достигать целей бизнеса и удовлетворять потребности клиентов. Фокус на результатах вместо выходов позволяет ИТ-службам сфокусироваться на реальной ценности, которую они создают для бизнеса, а не на технических процессах и метриках. Это приводит к более эффективному управлению ИТ-услугами и лучше соответствует целям организации, избегая ситуации, когда технические команды делают работу правильно, но не работают над тем, что действительно важно для бизнеса.