Очевидность неочевидных решений…

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

Краткая история про бизнес-процесс: когда наш средне-статистический интернет-магазин получает свой средне-статистический интернет-заказ, то Система_1 отправляет информацию комплектовщику о необходимости сбора товара, одновременно с этим Система_1 отправляет в Систему_2 информацию о необходимости создания накладной на перемещение товара. И вот наш комплектовщик, собрав свой заказ, идёт к компьютеру за соседним столом проверять наличие созданной в Системе_2 накладной. И при отсутствии последней садится на стул рядом и ждёт 5, 10, 40 минут пока Система_1 пробьет оборону и в Системе_2 будет создан документ. Комплектовщик не может отправить заказ в доставку, не может взять на сборку следующий. К слову сказать бывает так не всегда, но и не так уж редко, что бы не обратить на это внимание.

Для решения этой проблемы привлекаются разработчики, ставится задача: наладить связь без временных задержек. А дальше все по канону: работа—>совещания—>работа—>переключение на более приоритетные задачи—>обмен опытом—>работа—>обсуждение проблем и результат: временные задержки — есть.

И тут мы неожиданно подходим к главному вопросу: «А проблема ли — задержка связи?», вероятно да, но не такая критичная, как ее следствие — простой работы комплектовщиков.

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

Итог: скорость сбора заказов повышена в 4 раза.