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

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

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

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

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

В управлении конфигурациями основным источником информации об изменениях являются процессы управления изменениями, которые фиксируют обновления конфигурационных элементов. В управлении активами данные поступают из различных систем: бухгалтерского учета, складского учета, данных о затратах и ремонте техники, что создает разнородные потоки информации с разными триггерами обновления.

Предложенная метрика времени реакции на инциденты имеет три важные характеристики: 1) она нормирована в диапазоне от 0 до 1, что позволяет легко сравнивать результаты в разных группах и за разные периоды; 2) расчет рекомендуется проводить не для всего инцидента, а для каждого отдельного назначения в функциональные группы, учитывая возможные множественные обращения к одной и той же группе; 3) наиболее информативным является анализ метрики в разрезе по функциональным группам поддержки, что помогает выявить конкретные группы, требующие оптимизации в части времени реакции.

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

В типичных командах разработки для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания. Для большого количества команд эта цифра еще выше - 95-97%. Это означает, что отношение реального времени работы над задачей (Touch Time) ко времени в системе (System Lead Time), называемое эффективностью потока, находится в диапазоне от 3% до 10% для обычных команд.

Ответственность за авторизацию изменений в процессе управления релизами зависит от выбранной модели: в подходе, где управление релизами осуществляется в подразделении разработки/сопровождения, авторизацию изменений осуществляет сам процесс управления релизами на CAB'е; в подходе, где управление релизами осуществляется в подразделении эксплуатации, за авторизацию изменений отвечает процесс управления изменениями, а управление релизами выступает как инструмент для внедрения уже авторизованных изменений, не участвуя в их авторизации.