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

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

Альтернативный метод оценки эффективности потока заключается в проведении практического упражнения: представить поток и для каждого этапа процесса прикинуть, сколько времени задача проводит на этом этапе и сколько времени на ней фактически выполняется работа. Суммируя эти показатели и разделив суммарное время работы на суммарное время всего процесса, можно получить оценку эффективности потока. Хотя это не точный расчет, такие оценки часто удивляют команды, показывая реальный уровень эффективности в 10-25%, в то время как субъективные ощущения предполагают гораздо более высокие показатели (75-80%). Такой подход помогает выявить проблемные зоны, даже не обладая точными данными.

Оценка эффективности потока обычно предполагает экспертное приближение: команды интуитивно или на основе наблюдений определяют, сколько времени задачи проводят в активной работе и сколько времени в ожидании. Точный расчет же требует сбора и анализа конкретных данных по времени каждой задачи. В реальности большинство попыток «точного» расчета Flow Efficiency оказываются упрощенными оценками из-за сложности точного измерения Touch Time и Time in Process. Как правило, результаты оценки дают более реалистичные и полезные для команды показатели (в районе 10-25%), тогда как «точные» расчеты могут приводить к абсурдно высоким значениям (90% и более), не отражающим действительное положение дел.

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

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

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

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

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

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