Strict Standards: Non-static method Paginator::paginate() should not be called statically in /var/www/www-root/data/www/youcapital.ru/engine/modules/files/files_read.php on line 74 OZON.ru: История успешного интернет-бизнеса в России (Экслер Алекс) скачать книгу бесплатно
Главная » Библиотека » OZON.ru: История успешного интернет-бизнеса в России (Экслер Алекс)
{sort}

OZON.ru: История успешного интернет-бизнеса в России (Экслер Алекс)

Настройки отображения Выбрать главу(122)
Перейти на    1 2 ... 14 15 16 17 18 ... 37 38

The IT Crowd

У IT-отдела между тем шла очень горячая пора. Решение о том, что весь механизм будет создаваться собственными силами с нуля, а негативный опыт с Axapta спишется в издержки производства, было принято в июне 2001 года. Руководство IT-отдела брало на себя серьезную ответственность: если в случае адаптации каких-то готовых решений, вроде Axapta, часть проблем можно было списать на невозможность реализации той или иной функциональности в рамках данной системы, то в случае собственной разработки никаких отговорок уже быть не могло.

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

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

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

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

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

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

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

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

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

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

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

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

После заметного увеличения процента исполняемости заказов в полный рост встал следующий вопрос: сокращение сроков доставки. А этот параметр зависит от ряда самых разнообразных факторов: скорости работы поставщиков, работы склада, комплектовщиков, курьерской службы. Начать было решено с самого начала, просим прощения за тавтологию, то есть с поставщиков. Потому что, разобравшись с партнерами с точки зрения выполнения их обязательств по ассортименту, необходимо было выделить таких, которые не просто выполняют заявки, но делают это в срок. А поставщики на тот момент делились на две большие категории. Первая – это фирмы с четко налаженной системой. Вторые, и их было намного больше, – фирмы с бардаком вместо системы. Особенно сложно тогда было с рынком видео и аудио, на котором работали с большим количеством «черного нала»: когда к такому поставщику приходил человек с мешком наличных денег, ему отдавали товар, предназначенный для OZON.ru.

Требовалось в корне менять общую схему работы с поставщиками. Когда OZON.ru был маленький – он сразу оплачивал заказываемый товар. Однако с наращиванием оборотов работать по этой схеме стало уже невозможно: иначе бы приходилось закачивать в закупку товара огромную денежную массу. В результате OZON.ru стал работать с поставщиками по схеме отсроченных платежей. И тут в полный рост встала проблема оборачиваемости склада, потому что чем дольше товары лежат на складе, тем больше денег повисает в воздухе: товар оплачен OZON.ru, но не доставлен клиенту, и, соответственно, за него не получены деньги.

С переходом на систему отсроченных платежей и принятием товаров на реализацию пришлось довольно серьезно редактировать некоторые модули складской системы, поскольку вначале даже возникли определенные проблемы: товар стал оборачиваться не за 22–23 дня, а за 27–28 и даже 30 дней. Стали разбираться – оказалось, что система просто не понимает, что такое «товар сегодня – деньги когда-нибудь», потому что раньше работали совершенно по-другому.

Перейти на    1 2 ... 14 15 16 17 18 ... 37 38