Ознакомительная версия.
Первоначально все курьеры были пешими, без машин. У OZON.ru было несколько автомобилей, на которых доставлялись товары от поставщиков, и их привлекали в тех случаях, когда курьерам приходилось доставлять неподъемные тяжести.
Например, у OZON.ru был один любимый клиент, который в подвале своей фирмы создавал библиотеку. Он постоянно заказывал целые собрания сочинений и какие-то серийные издания. Подбирал их чуть ли не по цвету. Вот ему заказы приходилось доставлять на машине: два-три собрания сочинений в руках привезти было просто нереально.
Одновременно шла работа над расширением географии охвата клиентов курьерской службой. OZON.ru начал осуществлять доставку по Подмосковью и стал первым в России интернет-магазином, осуществляющим курьерскую доставку по Израилю.
Кроме того, значительные усилия предпринимались для совершенствования механизмов удаленной доставки. OZON.ru заключил договор с курьерской компанией СПСР, в результате чего заказы стали доставляться в более чем четыреста городов страны. Новый сервис позволял оперативно получить заказ в любом регионе страны, не прибегая к услугам почты, что существенно упростило для пользователей процесс приобретения товаров через Интернет.
Суть сервиса заключалась в следующем: заказ поступал в выбранное покупателем отделение СПСР, где его можно было получить, расплатившись наличными. Это было уникальное предложение на российском рынке электронной коммерции, создающее для пользователей из отдаленных регионов возможности, сравнимые по своим показателям с возможностями клиентов из Москвы и Санкт-Петербурга.
Услуги СПСР обходились клиентам магазина практически в два раза дешевле, чем услуги авиапочты, а кроме того, они могли следить за состоянием своего заказа в реальном времени на сайте службы.
В 2001 году почта в очередной раз пересмотрела тарифы на доставку книг за границу, в результате чего весь этот бизнес практически рухнул: если до этого у OZON.ru около 40 процентов по заказу был экспорт, то после этого экспорт упал до 10 процентов.
Работа генерального директора
Компания росла, и генеральный директор Владимир Гришкин прикладывал много усилий для того, чтобы организационная структура работала более четко и часть проблем решалась на уровне соответствующего начальника отдела, а не на уровне генерального или технического директора. Для этого примерно раз в неделю проводились менеджмент-митинги.
Тем не менее в то время «ручного» управления избежать было невозможно: Владимир Гришкин и Владимир Долгов ежедневно совершали обход подразделений и проверяли, как все работает.
Еще одна функция генерального директора на тот момент заключалась в выбивании денег. OZON.ru перешел на финансирование от месяца к месяцу, поэтому каждый месяц Владимир Гришкин приезжал на совет директоров и утверждал план финансирования: сначала на зарплату и поставщиков, а затем фактически только на зарплату, потому что обороты магазина увеличивались, так что оставались деньги на закупки.
Регулярно повышалась наценка на товары: в противном случае магазин мог и не выжить. В конце 2001 года наценка на книги была повышена до 75 процентов (заметим, что в обычных магазинах наценка была или такая же, или несколько выше), а на видео наценка составляла 100 процентов или даже больше.
Оборот магазина в тот период от месяца к месяцу рос примерно на 20 процентов.
У 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-отдела нарисовал директор Владимир Долгов. Выглядела эта формула очень просто и даже нелепо, но ее много раз проверяли – и практика доказала ее эффективность.
В основу расчетов была положена идея, что каждому из поставщиков требуется некоторое время на обработку заказов, которое отсчитывается с момента поступления заявки до момента доставки. Причем это время зависит от нескольких различных факторов: организации работы у данного поставщика, расстояния до Москвы и так далее. Формула учитывала имеющиеся заказы, гипотетические заказы, которые могли быть сделаны за время обработки, а также предусматривала некий страховой запас, который учитывал несоответствие между реальной ситуацией на складах поставщиков и предоставляемыми данными.
Ознакомительная версия.
