Если жизнь сложится таким образом, что вас заставят (или вдруг сами, по не понятной мне причине, захотите) провести анализ каких-либо данных и помоделировать, то первым пунктом в любой методичке будет что-то такое: «Необходимо определиться с целью проводимого анализа». Ну, а потом уже идёт вся соль.

Над первым пунктом не задумываются и сразу переходят к следующему пункту. Сам так делаю. Ведь, по умолчанию, конечная цель очевидна — сделать хорошо, сделать лучше, сделать не так плохо, как есть сейчас.

Кейс Аэропорта Хьюстона круто демонстрирует, почему не стоит пропускать пункт № 1. От определения того, с чем именно боремся зависит ой как много.

Аэропорт Хьюстона получал большое количество жалоб о длительном времени ожидания пассажиров возле лент выдачи багажа.
Плюс терзающая неопределенность — долетел чемодан или нет…
Проблема Хьюстона заключалась в том, что путь от трапа самолета до ленты выдачи составлял 2 минуты. Время ожидания багажа 6 минут.
Решение было блестящим. Маршрут до выдачи багажа, с помощью красной ленты и указателей, увеличили до 6 минут. Время ожидания теперь составляет 2 минуты. Жалобы пропали.

То есть в этом кейсе РЕАЛЬНОЙ проблемой требующей решения было не время багажа в пути до ленты конвейера, а время ожидания багажа пассажирами. На бытовом уровне это не совсем очевидно и контринтуитивно. Но если есть навыки абстрагирования и моделирования, то у нас должно получиться представить эту историю как задачку с управлением скоростью двух потоков. Тогда решение с замедлением скорости одного из потоков будет таким же естественным, как ускорением скорости второго потока.

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