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

Учёт трудозатрат позволяет выявить ключевые статьи расходов и определить направления для оптимизации. Поскольку затраты на персонал составляют значительную долю операционных затрат (40-60%), их анализ помогает ИТ-директору принимать обоснованные решения по сокращению издержек. Без регулярного учёта и анализа трудозатрат невозможно эффективно управлять бюджетом и повышать производительность ИТ-подразделения.

Project Oxygen – это исследовательский проект Google, направленный на изучение роли менеджеров в эффективности работы компании. Проект был запущен в 2008 году и изначально ставил целью доказать, что менеджеры не имеют существенного влияния на результаты работы сотрудников. Однако исследования показали обратное: роль руководителей критически важна для успеха организации. В результате Project Oxygen был разработан перечень из восьми ключевых качеств, которыми должен обладать хороший менеджер, такие как умение быть коучем, эффективное делегирование, интерес к успехам сотрудников и другие. Этот перечень используется в Google для подготовки менеджеров и формирования организационной структуры.

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

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

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

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

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

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

Способ измерения определяет, насколько оперативно и точно можно реагировать на отклонения. Например, автоматизированный расчет доли обращений с повторным документированием позволяет ежедневно анализировать тенденции и оперативно выявлять ухудшение качества. Метрики на основе опросов, требующих анализа, дают более глубокое понимание причин, но с задержкой. Оптимально комбинировать методы: автоматизированные данные — для мониторинга, субъективные — для диагностики проблем.