При использовании разных календарей для разных типов обращений возникает риск просрочки при переклассификации обращения. Например, если обращение изначально классифицировано как 'предоставление прав' (норматив 8 часов по календарю 8х5), а затем переклассифицируется как 'устранение ошибки' (норматив 8 часов по календарю 24х5), пересчет срока по новому календарю может привести к автоматическому нарушению, так как по новому календарю уже прошло больше времени, чем отведено. Это создает несправедливую ситуацию для сотрудника, который обнаружил ошибку в классификации. Такие проблемы подчеркивают важность точной первоначальной классификации и продуманной системы учета календарей.

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

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

В области разработки программного обеспечения из-за искажения восприятия нормы часто наблюдаются следующие неэффективные процессы: заявленный конвейер CI/CD на практике представляет собой раз в неделю сборку кода с последующими ручными операциями, что приводит к развертыванию раз в две-три недели; высокий процент дефектов в продукте (от 50% до 70% бэклога) считается нормальным явлением; полное отсутствие метрик и данных об эффективности разработки, из-за чего никто не может точно ответить на вопрос о скорости выполнения задач. При этом команда уверена, что следует современным стандартам и технологиям.

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

Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.

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

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

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

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