Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
При расчете веса инцидента учитывается его уровень влияния, который определяет степень значимости инцидента для бизнес-процессов. Например, уровень влияния может варьироваться от "Критичного" до "Низкого". Вес инцидента напрямую зависит от этого уровня, и суммарный вес всех инцидентов, привязанных к проблеме, определяет её приоритет.
Основные риски для внутреннего ИТ-провайдера в контексте портфеля услуг включают возможную замену на внешних провайдеров для части услуг, что может привести к сокращению бюджета и влияния ИТ-отдела. Также существует риск недостаточного понимания бизнес-ценностей услуг со стороны руководства, что затрудняет обоснование затрат. Ещё один риск - чрезмерное усиление позиции "безальтернативности", что может привести к снижению качества услуг из-за отсутствия конкуренции и стимулов к улучшению.
Классификация обращений по ИТ-услугам необходима для правильного вычисления сроков выполнения по соглашениям об уровне обслуживания, определения ответственных сотрудников, корректного формирования отчетности по ИТ-услугам и принятия управленческих решений по совершенствованию процессов. Некорректная классификация может негативно повлиять на отчетность, качество улучшения процессов и взаимодействие с бизнес-подразделениями, что в конечном итоге ухудшает качество обслуживания и снижает эффективность работы ИТ-отдела.
Для достижения требуемых показателей скорости изменения продукта необходимо выполнение двух условий. Во-первых, команда как черный ящик должна быть внутренне устроена корректно: уметь работать с потоком обрабатываемых объектов, иметь сбалансированную пропускную способность на всех этапах обработки. Во-вторых, команда должна иметь возможность управлять входом поступающих объектов: объекты должны иметь строгие границы для осознания и работы с ними, должны обладать определенной общностью в "размерах" (трудоемкость не должна сильно варьироваться), и команда должна управлять лимитом на количество объектов, обрабатываемых на первом этапе конвейера. Менее входящих объектов означает более быструю обработку каждого из них.
Человеческий фактор является красной нитью через большинство рисков в области информационной безопасности. Основное проявление — уязвимость перед фишинговыми атаками, когда сотрудники, не получившие должного обучения, могут отсылать свои учетные данные по электронной почте, переходить по вредоносным ссылкам или открывать зараженные вложения. Это делает технические меры безопасности менее эффективными. Также человеческий фактор проявляется в ошибках при выполнении стандартных операций, таких как установка обновлений или создание резервных копий, что может привести к потере данных и перебоям в работе ИТ-услуг.
Модель изменений должна настраивать параметры, связанные с порядком обработки и спецификой применения. Во-первых, необходимо определить порядок обработки изменения — через какие этапы оно проходит, на каких этапах требуется согласование, необходимо ли включение в релиз и другие регламентированные действия. Для некоторых направлений возможно предусмотреть опциональные этапы, например, работы по ИТ-инфраструктуре, которые можно выполнять только в рабочей среде. Также может существовать общий мастер-порядок для всех информационных систем, включающий обязательное приёмочное тестирование в выделенной среде. Во-вторых, необходимо задать параметры, которые модель должна учитывать при применении одного и того же порядка обработки к различным информационным системам или направлениям в ИТ-инфраструктуре. Это могут быть: - лица, ответственные за координацию изменений данной категории или направления, - лица, уполномоченные на согласование этапов, - конкретные результаты, ожидаемые на выходе определённых этапов (например, документы). Структура классификатора для таких параметров будет матрично-иерархической, где для групп систем или направлений определены типовые порядки обработки и соответствующие наборы параметров.
Проблема - это причина или потенциальная причина инцидента или инцидентов (произошедших, текущих или будущих). Это не само неприятное событие, а именно его корневая причина. Управление проблемами направлено на идентификацию фактических и потенциальных причин возникновения инцидентов и управление обходными решениями и известными ошибками для уменьшения вероятности и влияния инцидентов.
Руководителям рекомендуется следовать трём основным правилам при работе с RACI-матрицами: 1. Если в строке стоит символ A (Accountable), необходимо определить, какими инструментами и с чьей помощью будет обеспечен контроль исполнения функции, так как ответственность предполагает не только полномочия, но и механизмы контроля. При необходимости можно потребовать от консультантов предоставления соответствующих инструментов. 2. Если в строке стоит символ R (Responsible), следует подумать о том, кому можно делегировать эту работу - полностью или частично, так как время руководителя ограничено и его нужно тратить максимально эффективно. 3. Если в строке несколько R (то есть работу выполняет не только руководитель, но и другие люди), необходимо уточнить, кто именно отвечает за организацию работы (это может быть не ответственный за конечную результат), а кто просто участвует в исполнении. Это удобно фиксировать в расширенной RASCI-матрице, где S (Supports) означает тех, кто участвует в исполнении. Если вы находитесь в позиции S, рекомендуется делегировать непосредственное исполнение, сохранив за собой роль в контроле процесса (Informed/Consulted), чтобы избежать выполнения работы под чужим руководством без вашего контроля.
Для выполнения задачи недостаточно просто сообщить о ней сотруднику. Необходимо четко описать требуемый результат, указать зачем, кому и почему это нужно, определить сроки и обеспечить контроль. Четкая формулировка задачи предотвращает недопонимание, повышает вероятность успешного выполнения и позволяет избежать ситуаций, когда сотрудник неверно трактует приоритеты или забывает о поставленной задаче. Это особенно важно как для исполнителей, так и для менеджеров любого уровня.
В управлении уровнями обслуживания важно учитывать как полезность, так и гарантию, потому что только комбинация этих характеристик позволяет достичь максимального уровня ценности для потребителя. Полезность определяет, что услуга делает и насколько она удовлетворяет потребности, а гарантия определяет, как услуга предоставляется и соответствует ли она ожиданиям по доступности, скорости и другим параметрам. Игнорирование одной из этих характеристик может привести к неполному удовлетворению потребностей заказчика.