Организационная структура может существенно повлиять на успех внедрения ИТ-процессов, так как различные типы структур имеют свои особенности в коммуникации, принятии решений и распределении ответственности. Например, в иерархических структурах процессы утверждения решений могут быть более длительными, что требует особого внимания к этапам согласования. В матричных структурах важно учитывать двойное подчинение сотрудников и соответствующим образом настраивать процессы. Некоторые процессы, успешно работающие в одной организационной структуре, могут быть неэффективны в другой. Поэтому при внедрении ИТ-процессов критически важно учитывать особенности организационной структуры, что требует как от консультантов, так и от заказчиков глубокого понимания этой структуры и её влияния на процессы.

Основные проблемы включают избыточное количество уровней интерактивного голосового меню (IVR), приводящее к потере времени клиента; неэффективное распределение вызовов, когда клиент соединяется с оператором, не обладающим необходимыми полномочиями или знаниями; отсутствие передачи информации между уровнями обслуживания, что вынуждает клиента неоднократно повторять запрос; технические сбои, такие как обрывы связи в критический момент; навязчивые просьбы оценить качество обслуживания до фактического завершения взаимодействия; информационные сообщения, не соответствующие ситуации (например, уведомление о переводе на специалиста, когда вызов все ещё находится в очереди).

Ошибка в том, что такие противопоставления игнорируют взаимосвязь процессов и результатов. Процессная работа является фундаментом для достижения устойчивых результатов. Без поддержки процессов даже успешные проекты не дадут долгосрочного эффекта. 'Человек процесса' по сути является 'человеком результата', так как именно его деятельность обеспечивает реализацию стратегических целей организации в долгосрочной перспективе.

При планировании микросервисной архитектуры необходимо учитывать множество аспектов: схему бизнес-логики, обрабатываемые данные, API, сквозные требования к архитектурным элементам (безопасность, надежность, производительность), а также связи с внешними системами. Важно спланировать систему мониторинга, которая сможет отслеживать состояние каждого сервиса и их взаимодействия. Необходимо позаботиться о документировании всех компонентов и их зависимостей, обеспечить процессы управления конфигурациями и проблемами. Также важно предусмотреть обучение сотрудников работе с такой архитектурой, поскольку управление множеством независимых сервисов требует новых навыков и подходов по сравнению с монолитными приложениями.

Управление активами программного обеспечения решает несколько ключевых задач: снижение ИТ-расходов за счет оптимизации закупок и использования лицензий, минимизация рисков соответствия требованиям регуляторов, улучшение управления циклом жизни программного обеспечения, обеспечение прозрачности в использовании ПО и создание системы измеримых показателей эффективности (KPI). Благодаря внедрению SAM организации могут уменьшить ненужные затраты, оптимизировать закупку лицензий и контролировать использование ПО в рамках установленных правил.

С появлением web-порталов электронная почта из основного канала взаимодействия пользователя с Service Desk перешла в разряд дополнительных услуг. Порталы позволяют сразу собирать структурированную информацию от пользователей через специальные формы, классифицируют заявки и направляют их нужным исполнителям, что значительно упрощает и ускоряет обработку запросов. В то время как электронная почта требует ручного вмешательства для классификации и уточнения данных, что увеличивает нагрузку на сотрудников и затягивает время решения проблем.

Чтобы исключить влияние имитации кипучей деятельности на метрику продуктивности, в числитель формулы включаются только проблемы, закрытые с кодом решения из группы 'а' (с явной пользой). В знаменатель попадают проблемы из групп 'а' и 'б', где группа 'б' (закрытые без решения с непродуктивными затратами) снижает значение метрики. Проблемы из группы 'в' (например, дубли) исключаются из расчета полностью, чтобы разовые ошибки не искажали результат.

Техническая поддержка является важным элементом в управлении уровнем услуг, поскольку это «лицо» ИТ-подразделения для конечных пользователей. Она обеспечивает стабильность, удобство и решение проблем, с которыми сталкиваются пользователи при работе с ИТ-решениями. Недовольство пользователей быстро доходит до заказчиков, поэтому работа технической поддержки напрямую влияет на общее восприятие качества ИТ-услуг и удовлетворенность всех заинтересованных сторон.

Релизные циклы часто становятся источником задержек в поставке ценности, потому что они формируют длительную очередь из элементов работы, которые уже завершены, но не могут быть поставлены конечным пользователям. Эта очередь формируется из-за ручного регресс-тестирования, необходимости согласований на выходе, длительной проверки на тестовых группах и других процедур, тормозящих финальную стадию. Это создает ситуацию, когда работа над созданием ценности уже завершена, но ее поставка откладывается, что противоречит принципам непрерывной поставки и снижает ценность продукта для конечных пользователей.

Согласно тексту, окончательное решение о приоритетах ИТ-изменений должно принимать бизнес-заказчик. ИТ-департамент выступает исполнителем, а владелец бизнес-требований несет ответственность за определение того, какие изменения имеют наибольшую ценность для бизнеса и должны быть реализованы в первую очередь. Однако возникает сложность, когда различные бизнес-подразделения конкурируют за одни и те же ИТ-ресурсы, поскольку каждый бизнес-заказчик отстаивает приоритетность своих задач.