OZON.ru: История успешного интернет-бизнеса в России
Шрифт:
В 2001 году почта в очередной раз пересмотрела тарифы на доставку книг за границу, в результате чего весь этот бизнес практически рухнул: если до этого у OZON.ru около 40 процентов по заказу был экспорт, то после этого экспорт упал до 10 процентов.
Работа генерального директора
Компания росла, и генеральный директор Владимир Гришкин прикладывал много усилий для того, чтобы организационная структура работала более четко и часть проблем решалась на уровне соответствующего начальника отдела, а не на уровне генерального или технического директора. Для этого примерно раз в неделю проводились менеджмент-митинги.
Тем не менее в то время «ручного» управления избежать было невозможно: Владимир Гришкин и Владимир Долгов ежедневно совершали обход
Еще одна функция генерального директора на тот момент заключалась в выбивании денег. OZON.ru перешел на финансирование от месяца к месяцу, поэтому каждый месяц Владимир Гришкин приезжал на совет директоров и утверждал план финансирования: сначала на зарплату и поставщиков, а затем фактически только на зарплату, потому что обороты магазина увеличивались, так что оставались деньги на закупки.
Регулярно повышалась наценка на товары: в противном случае магазин мог и не выжить. В конце 2001 года наценка на книги была повышена до 75 процентов (заметим, что в обычных магазинах наценка была или такая же, или несколько выше), а на видео наценка составляла 100 процентов или даже больше.
Оборот магазина в тот период от месяца к месяцу рос примерно на 20 процентов.
The IT Crowd
У IT-отдела между тем шла очень горячая пора. Решение о том, что весь механизм будет создаваться собственными силами с нуля, а негативный опыт с Axapta спишется в издержки производства, было принято в июне 2001 года. Руководство IT-отдела брало на себя серьезную ответственность: если в случае адаптации каких-то готовых решений, вроде Axapta, часть проблем можно было списать на невозможность реализации той или иной функциональности в рамках данной системы, то в случае собственной разработки никаких отговорок уже быть не могло.
Однако компания, из которой был создан новый IT-отдел OZON.ru, до этого практически десять лет занималась разработкой и внедрением различных систем, в том числе финансовых и складских, поэтому руководство отдела посчитало, что они все-таки справятся.
Для решения этой задачи группа IT-разработчиков была поделена на две части: бэк-офис и веб. К бэк-офису относилась финансовая часть и складская логистика, а к вебу – интернет-витрина и прием заказов.
В первую очередь предстояло разделить бэк-офис и веб. Бэк-офис предстояло срочно перенести на отдельный сервер, а витрину решили временно оставить в старой архитектуре с поддержкой «Рексофта». Тем не менее группа веб-разработки начала заниматься созданием новой витрины на Java Server Pages и веб-сервере Apache под управлением операционной системы FreeBSD, потому что следующий этап плана предусматривал переход веб-витрины в ведение IT-отдела и перенос ее в Москву. У «Рексофта» витрина работала на ColdFusion [10] под Microsoft Windows, а потому планировалась полная смена платформы. [11]
10
Этот язык программирования позволял одновременно работать с базами данных и динамически создавать веб-страницы.
11
Под платформой подразумевается операционная система, например Windows или FreeBSD. Программы для пользователей, например Word или Excel, создаются с расчетом на работу в определенной системе и без соответствующих изменений не могут работать в других системах. Еще более жесткие условия существуют для серверных систем: смена платформы зачастую означает замену вообще всех программ.
Команда IT-отдела OZON.ru в свое время разрабатывала фактически с нуля движок для магазина XXL.ru, поэтому новый механизм создавался все-таки не на пустом месте: специалисты использовали имеющийся опыт и кое-какие наработки.
Разработка фундамента новой системы
При разработке нового бэк-офиса пришлось решать массу всяких задач, которые зачастую были связаны не только с программированием как таковым. Бэк-офис –
В связи с этим весьма примечательна история с системой прогнозирования закупок. Прогнозирование закупок – задача крайне сложная и важная: закажешь меньше, чем нужно, – не сможешь вовремя выполнить заказы клиентов; закажешь больше – забьешь склад ненужным товаром, в результате чего не останется места для нужного.
Тогда формулу, по которой работала автоматизированная система закупок, на одном из совещаний с руководством IT-отдела нарисовал директор Владимир Долгов. Выглядела эта формула очень просто и даже нелепо, но ее много раз проверяли – и практика доказала ее эффективность.
В основу расчетов была положена идея, что каждому из поставщиков требуется некоторое время на обработку заказов, которое отсчитывается с момента поступления заявки до момента доставки. Причем это время зависит от нескольких различных факторов: организации работы у данного поставщика, расстояния до Москвы и так далее. Формула учитывала имеющиеся заказы, гипотетические заказы, которые могли быть сделаны за время обработки, а также предусматривала некий страховой запас, который учитывал несоответствие между реальной ситуацией на складах поставщиков и предоставляемыми данными.
При всей своей простоте формула действительно работала. Ее много раз проверяли по принципу «Ну и что ты тут нам назаказывала? Ведь столько не нужно – товары будут на складе валяться!». Тем не менее все уходило вовремя – система работала. Конечно, она не могла учитывать ажиотажный спрос, однако при стабильном поступлении заказов, без особых пиков, работала железно.
Во время внедрения формулы в бэк-офисный модуль складывались и забавные ситуации. Когда раздел прогнозирования закупок вчерне был готов, главный разработчик Александр Алехин демонстрировал его работу Владимиру Долгову. Для проверки работы модуля было решено сгенерировать один и тот же заказ у самого крупного поставщика (тогда это была фирма «Топ-книга») по двум алгоритмам: по старому, который просто учитывал имеющиеся заказы, и по новой формуле. Разница оказалась огромной: старый алгоритм давал примерно тысячу книг, а новый – порядка восьми тысяч. Тогда Долгов сказал Алехину: «Если модуль работает правильно, тогда мы эти книги отгрузим. Но если в модуле ошибка, тогда у нас останется несколько тысяч лишних книг. Мы не будем вычитать у тебя из зарплаты. Ты эти книги просто заберешь к себе домой». Алехин подумал и решил сначала еще раз проверить работу модуля. Там оказалась ошибка, в результате чего данные завышались раза в четыре.
Работа с поставщиками
После заметного увеличения процента исполняемости заказов в полный рост встал следующий вопрос: сокращение сроков доставки. А этот параметр зависит от ряда самых разнообразных факторов: скорости работы поставщиков, работы склада, комплектовщиков, курьерской службы. Начать было решено с самого начала, просим прощения за тавтологию, то есть с поставщиков. Потому что, разобравшись с партнерами с точки зрения выполнения их обязательств по ассортименту, необходимо было выделить таких, которые не просто выполняют заявки, но делают это в срок. А поставщики на тот момент делились на две большие категории. Первая – это фирмы с четко налаженной системой. Вторые, и их было намного больше, – фирмы с бардаком вместо системы. Особенно сложно тогда было с рынком видео и аудио, на котором работали с большим количеством «черного нала»: когда к такому поставщику приходил человек с мешком наличных денег, ему отдавали товар, предназначенный для OZON.ru.
Требовалось в корне менять общую схему работы с поставщиками. Когда OZON.ru был маленький – он сразу оплачивал заказываемый товар. Однако с наращиванием оборотов работать по этой схеме стало уже невозможно: иначе бы приходилось закачивать в закупку товара огромную денежную массу. В результате OZON.ru стал работать с поставщиками по схеме отсроченных платежей. И тут в полный рост встала проблема оборачиваемости склада, потому что чем дольше товары лежат на складе, тем больше денег повисает в воздухе: товар оплачен OZON.ru, но не доставлен клиенту, и, соответственно, за него не получены деньги.