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

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

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

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

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

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

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

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

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

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