Если жизнь сложится таким образом, что вас заставят (или вдруг сами, по не понятной мне причине, захотите) провести анализ каких-либо данных и помоделировать, то первым пунктом в любой методичке будет что-то такое: "Необходимо определиться с целью проводимого анализа". Ну а потом уже идёт вся соль.
Над первым пунктом не задумываются и сразу переходят к следующему пункту. Сам так делаю. Ведь, по умолчанию, конечная цель очевидна - сделать хорошо, сделать лучше, сделать не так плохо, как есть сейчас.
Кейс Аэропорта Хьюстона круто демонстрирует, почему не стоит пропускать пункт №1. От определения того, с чем именно боремся зависит ой как много.
Аэропорт Хьюстона получал большое количество жалоб о длительном времени ожидания пассажиров возле лент выдачи багажа.
Плюс терзающая неопределенность - долетел чемодан или нет?…
Проблема Хьюстона заключалась в том, что путь от трапа самолета до ленты выдачи составлял 2 минуты. Время ожидания багажа 6 минут.
Решение было блестящим. Маршрут до выдачи багажа, с помощью красной ленты и указателей, увеличили до 6 минут. Время ожидания теперь составляет 2 минуты. Жалобы пропали.
То есть в этом кейсе РЕАЛЬНОЙ проблемой требующей решения было не время багажа в пути до ленты конвейера, а время ожидания багажа пассажирами. На бытовом уровне это не совсем очевидно и контринтуитивно. Но если есть навыки абстрагирования и моделирования, то у нас должно получиться представить эту историю как задачку с управлением скоростью двух потоков. Тогда решение с замедлением скорости одного из потоков будет таким же естественным, как ускорением скорости второго потока.
Но даже моделер в голове не поможет решить вопрос, если вы не определились с Целью. Чего мы хотим добиться, какой результат ожидаем получить, с чем боремся? И вот тут, если целью стоит сокращение срока пребывания человека в аэропорту, задержка скорости потока почти не приходит в голову. Но если целевая характеристика относительная, то тут пространство вариантов значительно возрастает.