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

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

25
авторов

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

100%
оригинальный контент
Управление рисками требует оценки не только вероятности возникновения проблем, но и их потенциального влияния на бизнес-результаты. Например, проблема с системой резервного копирования может иметь низкую вероятность проявления, но если при сбое данные будут потеряны, это может привести к остановке производства и убыткам. Понимание этого влияния позволяет выделить больше ресурсов на предотвращение таких проблем, даже если они технически сложны в решении, что снижает общий уровень риска для бизнеса.
Чтобы избежать сопротивления при внедрении процесса управления изменениями, необходимо постепенно формировать культуру соблюдения регламентов без излишнего усложнения терминов. Начните с малого: опишите существующие неформальные процедуры и постепенно упорядочивайте их. Вовлекайте сотрудников в обсуждение, показывая, как новые правила упростят их работу. Акцентируйте внимание на личной выгоде: сокращение авралов, четкие сроки задач и снижение ошибок. Также важно демонстрировать быстрые успехи на первых этапах, чтобы доказать эффективность изменений.
Выделенный ИТ-представитель (BRM) обеспечивает единую точку контакта для бизнес-заказчиков при направлении требований к ИТ-услугам, помогает им формулировать и оформлять запросы, определяет, является ли запрос кандидатом для крупного изменения и требует ли создания Change proposal. BRM также контролирует процесс подготовки и согласования Change proposal, гарантируя соответствие бизнес-требованиям.
Смешивание инцидентов и запросов на обслуживание искажает оценку эффективности работы сервис-деска, так как эти категории имеют разную срочность и сложность. Запросы на обслуживание, как правило, проще, предсказуемы и легко решаются в установленные сроки, что положительно влияет на общий показатель выполнения задач. Инциденты же требуют срочного решения и часто сложнее в устранении, что может привести к превышению сроков. При совместном учете успешное выполнение запросов на обслуживание компенсирует низкую эффективность в решении инцидентов, скрывая реальные проблемы в операционной деятельности и снижая объективность оценки качества работы сервис-деска.
Практическую пользу от использования CMDB можно обеспечить, сначала определив, какие именно данные необходимы сотрудникам для их повседневной работы. Это требует общения с заинтересованными сторонами для понимания их потребностей и рабочих процессов. После этого необходимо настроить CMDB так, чтобы она предоставляла именно ту информацию, которая упрощает работу сотрудников. Важно также провести обучение, чтобы показать, как использовать систему для решения конкретных задач, и внедрить механизмы мониторинга использования, чтобы регулярно улучшать качество и релевантность данных. Регулярная демонстрация успешных кейсов использования CMDB также способствует повышению её ценности.
Для сверки финансовой информации между различными информационными системами можно применять следующие методы: создание автоматизированных сверочных отчётов, которые выявляют расхождения между данными в CMDB и исходными системами, ручную проверку данных в случаях, когда автоматизация затруднена (например, при работе с договорами в иностранной валюте), регулярный контроль соответствия данных в системах на основе чётко прописанных алгоритмов сверки, разработку специализированных скриптов и инструментов для обработки данных, учитывающих особенности учёта в каждой системе (например, конвертацию валюты или обработку текстовых примечаний).
Пороги производительности — это установленные временные или количественные рамки, превышение которых расценивается как недоступность услуги. Например, для электронной почты порогом может быть время задержки при отправке или получении писем, выходящее за определенный временной интервал. Если сервис работает, но время ответа превышает установленный порог, это учитывается как период недоступности в расчетах уровня доступности.
При анализе рисков учитываются три уровня вероятности: 1) Вероятность появления источника риска или угрозы, которая определяется внешними факторами и средой, в которой функционирует организация. 2) Вероятность того, что появление угрозы приведет к наступлению нежелательного события, что зависит от уровня уязвимости системы. 3) Вероятность того, что произошедшее событие вызовет конкретные негативные последствия для организации, что может варьироваться в зависимости от эффективности системы реагирования и других внутренних факторов. Каждый уровень требует отдельной оценки для формирования комплексной картины риска.
Термин 'бизнес' часто используется как общее обозначение для подразделений, которые ставят задачи ИТ, но он может быть неточным. Не все подразделения, выступающие в роли заказчиков для ИТ, относятся к основному бизнесу компании. Например, бухгалтерия, являясь заказчиком для ИТ, сама по себе является поддерживающей функцией и не создает непосредственной ценности для внешних клиентов компании. Поэтому вместо общего термина 'бизнес' точнее использовать термин 'заказчик', который более четко определяет роль подразделения в отношениях с ИТ-службой.
По мнению текста, научно обоснованными из всего исследования являются только два вывода: что более объективной самооценке можно научиться и что эксперты оценивают свои навыки точнее, чем неэксперты. Все остальные популярные интерпретации, такие как кривая, на которой люди с низкой компетентностью имеют самую высокую самооценку, а затем, по мере роста знаний, самооценка снижается, а потом снова растет, основываются на математических ошибках в оригинальной работе и последующих публикациях.