OZON.ru: История успешного интернет-бизнеса в России

В первую очередь предстояло разделить бэк-офис и веб. Бэк-офис предстояло срочно перенести на отдельный сервер, а витрину решили временно оставить в старой архитектуре с поддержкой «Рексофта». Тем не менее группа веб-разработки начала заниматься созданием новой витрины на Java Server Pages и веб-сервере Apache под управлением операционной системы FreeBSD, потому что следующий этап плана предусматривал переход веб-витрины в ведение IT-отдела и перенос ее в Москву. У «Рексофта» витрина работала на ColdFusion[10] под Microsoft Windows, а потому планировалась полная смена платформы.[11]

Команда IT-отдела OZON.ru в свое время разрабатывала фактически с нуля движок для магазина XXL.ru, поэтому новый механизм создавался все-таки не на пустом месте: специалисты использовали имеющийся опыт и кое-какие наработки.

Разработка фундамента новой системы

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

В связи с этим весьма примечательна история с системой прогнозирования закупок. Прогнозирование закупок – задача крайне сложная и важная: закажешь меньше, чем нужно, – не сможешь вовремя выполнить заказы клиентов; закажешь больше – забьешь склад ненужным товаром, в результате чего не останется места для нужного.

Тогда формулу, по которой работала автоматизированная система закупок, на одном из совещаний с руководством IT-отдела нарисовал директор Владимир Долгов. Выглядела эта формула очень просто и даже нелепо, но ее много раз проверяли – и практика доказала ее эффективность.

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

При всей своей простоте формула действительно работала. Ее много раз проверяли по принципу «Ну и что ты тут нам назаказывала? Ведь столько не нужно – товары будут на складе валяться!». Тем не менее все уходило вовремя – система работала. Конечно, она не могла учитывать ажиотажный спрос, однако при стабильном поступлении заказов, без особых пиков, работала железно.

Во время внедрения формулы в бэк-офисный модуль складывались и забавные ситуации. Когда раздел прогнозирования закупок вчерне был готов, главный разработчик Александр Алехин демонстрировал его работу Владимиру Долгову. Для проверки работы модуля было решено сгенерировать один и тот же заказ у самого крупного поставщика (тогда это была фирма «Топ-книга») по двум алгоритмам: по старому, который просто учитывал имеющиеся заказы, и по новой формуле. Разница оказалась огромной: старый алгоритм давал примерно тысячу книг, а новый – порядка восьми тысяч. Тогда Долгов сказал Алехину: «Если модуль работает правильно, тогда мы эти книги отгрузим. Но если в модуле ошибка, тогда у нас останется несколько тысяч лишних книг. Мы не будем вычитать у тебя из зарплаты. Ты эти книги просто заберешь к себе домой». Алехин подумал и решил сначала еще раз проверить работу модуля. Там оказалась ошибка, в результате чего данные завышались раза в четыре.

Работа с поставщиками