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

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

25
авторов

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

100%
оригинальный контент
Успешность сервисного подхода в ИТ можно измерить через удовлетворенность бизнеса, скорость решения бизнес-задач, качество взаимодействия между ИТ и бизнес-подразделениями, количество и качество получаемой обратной связи от бизнеса, успешное выполнение проектов и инициатив, которые напрямую влияют на бизнес-результаты. Также можно отслеживать, насколько ИТ понимает и предвосхищает потребности бизнеса, насколько оперативно реагирует на запросы, и какие реальные улучшения в бизнес-процессах произошли благодаря ИТ. Формальные показатели SLA не всегда отражают истинное качество сервиса.
Какие аспекты следует учитывать при разработке требований к системе управления конфигурациями (CMS)?
При разработке требований к системе управления конфигурациями (CMS) необходимо учитывать следующие аспекты: требования к структуре ответственности (кто и за что отвечает в процессе обновления данных), возможности отслеживания изменений (журналирование изменений, история версий), формирование аудиторского следа (возможность проверки соответствия данных реальному состоянию), поддержку различных типов конфигурационных единиц, интеграцию с другими системами ИТ-управления (например, системами управления изменениями и инцидентами), требования к производительности и масштабируемости. Также важно учитывать необходимость поддержки жизненных циклов различных типов конфигурационных объектов, от их создания до списания.
Игнорирование управления ИТ-архитектурой при создании системы управления задачами приводит к критическим пробелам в процессе управления. Принятие решений по архитектуре, её документирование и развитие имеют непосредственное отношение к созданию эффективной системы управления задачами. Без чёткой архитектурной стратегии становится невозможно определить, как принимать решения по архитектурным изменениям, как документировать их и как поддерживать качество архитектуры в долгосрочной перспективе. Это приводит к несогласованности процессов, увеличивает риски возникновения ошибок и снижает производительность всей системы управления задачами. Следовательно, необходимо интегрировать управление архитектурой в процесс создания системы управления задачами для обеспечения её надёжности и эффективности.
Менеджер услуг в ИТ-сфере сосредоточен на поддержании и постепенном улучшении уже существующих сервисов, решении текущих проблем и создании комфортных условий для пользователей. Его работа требует терпения, внимания к деталям и удовлетворения от постепенного совершенствования процессов. Проектный менеджер, напротив, работает над конкретными временными проектами с четкими целями и сроками. Он получает удовлетворение от быстрых результатов и новых достижений. Его основная задача - завершить проект в срок и в рамках бюджета, после чего он может перейти к новому проекту.
Потоки создания ценности и ресурсы взаимодействуют как основные и вспомогательные элементы системы управления компанией. Компания имеет один или несколько потоков создания ценности, формирующих конечную ценность для потребителя. Это потоки прямого потребления, конечными результатами которых является прямая потребительская ценность. Компания также имеет потоки создания ценности, направленные на развитие или качественное улучшение, примеры которых встречаются в литературе по современному ИТ-менеджменту, и чьи конечные результаты представляют собой добавочную потребительскую ценность. Работы, которые не укладываются в эти потоки, описываются как измеримые ресурсы. Эти ресурсы служат основой, поддерживающей основные потоки. Например, ресурсы по compliance позволяют корректно регистрировать договоры страхования, а ресурсы надежности ИТ-систем обеспечивают их готовность к эксплуатации. Ключевой принцип заключается в том, что ресурсы должны быть явно определены, измеримы и интегрированы в общее описание потоков предоставления ценности, так чтобы не возникало излишков и чтобы ресурсы всегда были доступны тогда, когда они нужны основным потокам.
Основные проблемы включают отсутствие прозрачных данных, преувеличение результатов в маркетинговых материалах и недостаток независимых исследований. Часто компании не публикуют полные данные о результатах внедрения, что затрудняет формирование объективной картины эффективности ITIL и других методологий управления ИТ.
В условиях отсутствия конкуренции клиенты вынуждены принимать имеющиеся условия, даже если качество сервиса низкое. Они не могут выбирать между альтернативами, поэтому их основной мотив — решить задачу (арендовать машину, пообедать в кафе), а не получить превосходное обслуживание. Негативный опыт не приводит к массовому уходу из компании, так как альтернативы отсутствуют. Клиенты адаптируются к низким стандартам, что ослабляет их требования и поддерживает статус-кво, когда компании не стремятся улучшать качество услуг.
Современные подходы ITIL 4 рассматривают приоритизацию не как однократную операцию, проведенную на начальном этапе, а как динамический, сквозной процесс, который может повторяться на протяжении всего жизненного цикла инцидента. ITIL 4 также предлагает применять единые схемы приоритизации не только для инцидентов, но и для других типов работ в управлении ИТ-услугами, чтобы при ограниченности ресурсов можно было оптимально распределять задачи разных типов. Это расширенное понимание приоритизации позволяет более гибко реагировать на изменяющиеся условия и принимать обоснованные решения о порядке выполнения задач с учетом общей ценности для бизнеса.
Эмоциональная связь с клиентом через ИТ-сервис создаётся за счёт персонализированного подхода, демонстрации заботы и внимания к деталям. Например, регулярные проверки состояния системы клиента с предложением рекомендаций по оптимизации, поздравления с профессиональными праздниками с персонализированным сообщением, внедрение неожиданных бонусов, таких как расширенный пробный период или доступ к эксклюзивным материалам. Важно, чтобы клиент чувствовал, что компания понимает его потребности и готова идти навстречу даже в мелочах.
Чаще всего команды в условиях деловой игры совершают ошибки, связанные с излишней фокусировкой на достижении показателей KPI вместо обучения, что приводит к следованию шаблонам без экспериментов. Также распространены ситуации, когда участники переносят ожидания чётких правил из настольных игр на менеджерские процессы, что ведёт к поиску виноватых во внешних факторах после неудач. Другая ошибка — предположение, что опыт реальной работы достаточно точно отражает то, как вести себя в игре, в то время как игра как раз призвана выявить и улучшить эти привычные модели.