Работа генерального директора
Компания росла, и генеральный директор Владимир Гришкин прикладывал много усилий для того, чтобы организационная структура работала более четко и часть проблем решалась на уровне соответствующего начальника отдела, а не на уровне генерального или технического директора. Для этого примерно раз в неделю проводились менеджмент‑митинги.
Тем не менее в то время «ручного» управления избежать было невозможно: Владимир Гришкин и Владимир Долгов ежедневно совершали обход подразделений и проверяли, как все работает.
Еще одна функция генерального директора на тот момент заключалась в выбивании денег. 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]
|
|
|
Команда IT‑отдела OZON.ru в свое время разрабатывала фактически с нуля движок для магазина XXL.ru, поэтому новый механизм создавался все‑таки не на пустом месте: специалисты использовали имеющийся опыт и кое‑какие наработки.
Разработка фундамента новой системы
При разработке нового бэк‑офиса пришлось решать массу всяких задач, которые зачастую были связаны не только с программированием как таковым. Бэк‑офис – это система, в которой смоделировано и автоматизировано большинство бизнес‑процессов фирмы. А что делать, если механизм этого процесса не существует еще даже в теории?
В связи с этим весьма примечательна история с системой прогнозирования закупок. Прогнозирование закупок – задача крайне сложная и важная: закажешь меньше, чем нужно, – не сможешь вовремя выполнить заказы клиентов; закажешь больше – забьешь склад ненужным товаром, в результате чего не останется места для нужного.
|
|
|
Тогда формулу, по которой работала автоматизированная система закупок, на одном из совещаний с руководством IT‑отдела нарисовал директор Владимир Долгов. Выглядела эта формула очень просто и даже нелепо, но ее много раз проверяли – и практика доказала ее эффективность.
В основу расчетов была положена идея, что каждому из поставщиков требуется некоторое время на обработку заказов, которое отсчитывается с момента поступления заявки до момента доставки. Причем это время зависит от нескольких различных факторов: организации работы у данного поставщика, расстояния до Москвы и так далее. Формула учитывала имеющиеся заказы, гипотетические заказы, которые могли быть сделаны за время обработки, а также предусматривала некий страховой запас, который учитывал несоответствие между реальной ситуацией на складах поставщиков и предоставляемыми данными.
При всей своей простоте формула действительно работала. Ее много раз проверяли по принципу «Ну и что ты тут нам назаказывала? Ведь столько не нужно – товары будут на складе валяться!». Тем не менее все уходило вовремя – система работала. Конечно, она не могла учитывать ажиотажный спрос, однако при стабильном поступлении заказов, без особых пиков, работала железно.
|
|
|
Во время внедрения формулы в бэк‑офисный модуль складывались и забавные ситуации. Когда раздел прогнозирования закупок вчерне был готов, главный разработчик Александр Алехин демонстрировал его работу Владимиру Долгову. Для проверки работы модуля было решено сгенерировать один и тот же заказ у самого крупного поставщика (тогда это была фирма «Топ‑книга») по двум алгоритмам: по старому, который просто учитывал имеющиеся заказы, и по новой формуле. Разница оказалась огромной: старый алгоритм давал примерно тысячу книг, а новый – порядка восьми тысяч. Тогда Долгов сказал Алехину: «Если модуль работает правильно, тогда мы эти книги отгрузим. Но если в модуле ошибка, тогда у нас останется несколько тысяч лишних книг. Мы не будем вычитать у тебя из зарплаты. Ты эти книги просто заберешь к себе домой». Алехин подумал и решил сначала еще раз проверить работу модуля. Там оказалась ошибка, в результате чего данные завышались раза в четыре.
Работа с поставщиками
После заметного увеличения процента исполняемости заказов в полный рост встал следующий вопрос: сокращение сроков доставки. А этот параметр зависит от ряда самых разнообразных факторов: скорости работы поставщиков, работы склада, комплектовщиков, курьерской службы. Начать было решено с самого начала, просим прощения за тавтологию, то есть с поставщиков. Потому что, разобравшись с партнерами с точки зрения выполнения их обязательств по ассортименту, необходимо было выделить таких, которые не просто выполняют заявки, но делают это в срок. А поставщики на тот момент делились на две большие категории. Первая – это фирмы с четко налаженной системой. Вторые, и их было намного больше, – фирмы с бардаком вместо системы. Особенно сложно тогда было с рынком видео и аудио, на котором работали с большим количеством «черного нала»: когда к такому поставщику приходил человек с мешком наличных денег, ему отдавали товар, предназначенный для OZON.ru.
Требовалось в корне менять общую схему работы с поставщиками. Когда OZON.ru был маленький – он сразу оплачивал заказываемый товар. Однако с наращиванием оборотов работать по этой схеме стало уже невозможно: иначе бы приходилось закачивать в закупку товара огромную денежную массу. В результате OZON.ru стал работать с поставщиками по схеме отсроченных платежей. И тут в полный рост встала проблема оборачиваемости склада, потому что чем дольше товары лежат на складе, тем больше денег повисает в воздухе: товар оплачен OZON.ru, но не доставлен клиенту, и, соответственно, за него не получены деньги.
С переходом на систему отсроченных платежей и принятием товаров на реализацию пришлось довольно серьезно редактировать некоторые модули складской системы, поскольку вначале даже возникли определенные проблемы: товар стал оборачиваться не за 22–23 дня, а за 27–28 и даже 30 дней. Стали разбираться – оказалось, что система просто не понимает, что такое «товар сегодня – деньги когда‑нибудь», потому что раньше работали совершенно по‑другому.
Особенности приема заказов
Учитывая специфику работы интернет‑магазина в России, когда товар оплачивается практически только по получении, очень многие заказы приходилось отслеживать вручную. Конечно, все заказы просматривать было невозможно, но существовала целая система признаков, которые сигнализировали руководству (Владимиру Гришкину и Владимиру Долгову) о том, что определенные заказы нужно проконтролировать. У них был даже некий утренний ритуал, во время которого просматривалось, сколько заказов и на какую сумму попало в систему. И если сумма или количество превышали определенные средние значения, с этим сразу приходилось разбираться.
Но жестких критериев не было, потому что приходилось учитывать сразу целый комплекс различных параметров: регион, количество товара, вид товара, форма оплаты, история клиента. Заказ старым клиентом товара с оплатой по доставке в Москве особых вопросов не вызывал, даже если был на приличную сумму. А заказ от нового клиента сразу пары сотен DVD в Азербайджан или Казахстан, независимо от вида оплаты, сразу ставился на контроль, и соответствующие сотрудники пытались созвониться с заказчиком и выяснить все детали.
Особое внимание в то время вызывали заказы с предварительной оплатой по кредитной карте, потому что было немало случаев использования ворованных карточек. Заказы за границу по кредитке особых вопросов не вызывали, потому что клиенты из Европы, Америки, Израиля обычно так и платили, а вот оплата по кредитке в страны бывшего СССР обычно выглядела подозрительно, причем в большинстве случаев оказывалось, что это все попытки мошенничества.
С проверкой кредиток вообще было много сложностей. Почти невозможно было сразу понять, ворованная это кредитка или нет, за исключением случаев, когда жулик при оплате заказа перебирал несколько номеров уже недействительных карточек – вот это уже сразу было признаком мошенничества.
В OZON.ru выясняли подлинность кредитных карт различными способами. Сначала смотрели, соответствуют ли данные карточки региону проживания. То есть если человек с Украины, а карточка у него американская или австралийская – это сразу вызывало серьезные подозрения. Затем клиента, если у него это был первый заказ, просили прислать скан паспорта и скан кредитки с заклеенными номерами для подтверждения того, что карточка действительно выписана на него.
В какой‑то момент появилась идея ставить в черные списки или даже штрафовать так называемых отказников – людей, которые сделали заказ с оплатой при получении, а в момент доставки отказались от заказа. (Магазин при этом, разумеется, нес довольно заметные затраты.) Но потом решили этого не делать: все‑таки мало ли какие у людей ситуации бывают…
Особенности отправки заказов
Упаковка заказов на складе производилась по‑разному, в зависимости от типа доставки и направления. Для заказов, доставляемых курьерами, перестали использовать дорогие коробки, заменив их полиэтиленовыми пакетами, которые, во‑первых, были заметно дешевле, а во‑вторых, еще и не намокали в дождь.
А вот с посылками, которые составляли примерно половину всех заказов, все было значительно сложнее. Упаковка там зависела от размеров. Некоторые российские посылки для соответствия стандартам приходилось обшивать бязью и запечатывать сургучом: таково было требование почты.
Когда акционерам демонстрировали обшитые бязью и запечатанные сургучом почтовые посылки, они очень радовались, потому что в памяти сразу возникали всякие колониальные товары: кофе, рис, чай и тому подобное.
Под собранные посылки было выделено отдельное помещение – некий склад готовой продукции. Там лежали посылки, рассортированные по статусам: «почта – за рубеж», «почта – Россия», «почта – до востребования», «посылки для курьерской службы». Таким образом нащупывалась схема функционирования всей системы.
Вторая новогодняя продажа
Предновогодние продажи – это, как всегда, самая горячая пора. В OZON.ru учли опыт прошлого года и постарались должным образом подготовиться к предстоящему ажиотажу.
Был открыт отдел специальных новогодних подарков, причем для удобства покупателей товары объединили в тематические подборки: «для Нее», «для Него», «для начальника», «для подчиненного», «для любителей японской экзотики», «для тещи» и так далее.
Разумеется, не обошлось без традиционных рождественских скидок – магазин на три недели декабря аж на 25 процентов снизил цены на музыкальные CD и DVD.
Ну и последнее нововведение: OZON.ru сам начал производить товары. Первыми ласточками стали серийные футболки «Правила Эраста Фандорина», эскиз которых нарисовал сам Борис Акунин. Впрочем, впоследствии производство собственных товаров у OZON.ru носило весьма эпизодический характер.
2002 год. Новая витрина и бэк‑офис, объединение с «PPE‑Групп»
Весна 2002 года прошла под знаком серьезного недовольства со стороны начальства и инвесторов работой IT‑отдела, точнее группой веб‑разработки. Эта тема даже неоднократно обсуждалась на совете директоров, и, как говорили в IT‑отделе, в воздухе явственно запахло конкретными увольнениями.
IT‑страдания
Проблема заключалась в том, что выявился очень большой разрыв между относительными успехами группы, занимавшейся бэк‑офисом, и фактически полным фиаско у группы, разрабатывавшей новую веб‑витрину.
В бэк‑офисе постепенно внедрялись новые модули, и соответствующая группа планомерно переходила на собственные технологии, не вызывая у OZON.ru никаких потрясений. А вот у группы разработки веб‑витрины работа не ладилась. Причем все это происходило в тот момент, когда старая веб‑витрина уже совершенно не справлялась с нагрузками: там давно был достигнут технологический предел. Витрина не в состоянии была справиться с более чем сотней одновременных (в пределах 15 минут) посещений, в то время как на сайт магазина часто приходило значительно больше народу; а уж поиск, который чисто технологически не выдерживал более пары одновременных запросов, постоянно вводил сервер в клинч. На этом фоне новая веб‑витрина нужна была как воздух, и проблемы с ее разработкой серьезно нивелировали успехи развития нового бэк‑офиса.
При этом сроки запуска новой витрины все время отодвигались. Конец 2001 года, январь 2002‑го, февраль – но при этом ничего так и не было готово хотя бы предварительно. По словам экспертов, основная проблема группы веб‑разработки заключалась в недостаточном опыте управления проектами. У них не получилось эффективно спланировать работу и расставить соответствующие приоритеты, в результате чего группа залезла в дебри каких‑то малозначащих деталей, которыми можно было заниматься годами. Разработчикам было интересно копаться в мелочах, но проект практически не двигался, и в совете директоров уже теряли терпение.
В марте ощутимо запахло жареным: руководство было страшно недовольно IT‑отделом, а в самом IT‑отделе волком смотрели на четырех человек группы веб‑разработки, из‑за которых был весь сыр‑бор.
Тогда один из сотрудников группы бэк‑офиса начал рыться в Интернете, знакомясь с новыми технологиями веб‑разработки, и наткнулся на описание майкрософтовской среды программирования ASP.NET, которой в корпорации прочили большое будущее. Причем это была еще бета‑версия, которая только готовилась к официальному выпуску. Сотрудник посмотрел примеры того, что можно сделать с помощью данного средства разработки, – и поразился тому, какая широкая функциональность в нем изначально заложена. Безо всякой документации, буквально на основе выложенных примеров он за пару дней сделал несколько функциональных модулей веб‑витрины, которые группа веб‑витрины разрабатывала несколько месяцев, причем так и не довела их до ума.
Новые модули были распространены среди группы разработки бэк‑офиса, и сотрудники были просто поражены тем, насколько с помощью этой технологии все получается быстро и красиво. Вот тогда‑то и зазвучали сначала робкие, а потом все более громкие предложения, что, может, ну ее к черту, эту Java Server Pages под Linux/FreeBSD, а сделать все на ASP/ASP.NET под Microsoft SQL Server.[12] Нужно было срочно принимать решение: времени на раздумья уже не было, ситуация была критическая и могла привести к расформированию всего отдела!
Решили просто сравнить оба технических решения. Специалисты группы бэк‑офиса буквально за неделю разработали на ASP.NET макет веб‑витрины с ключевой функциональностью (корзина, списки, деталировка товара), после чего запустили сравнительное тестирование. Стресс‑тесты показали, что механизм на Java проигрывает по всем статьям.
Нужно отметить, что данная ситуация вовсе не является примером того, что Java Server Pages безусловно проигрывает ASP.NET. Очень многое зависит и от разработчиков, и от принятой стратегии, и от механизмов реализации. Просто в данном случае группа, работавшая на Java Server Pages, не смогла решить задачу, а группа, применившая ASP.NET, показала быстрые и впечатляющие результаты. В общем‑то, могло быть и все наоборот – прецеденты были неоднократно.
Группа веб‑разработки, увидев результаты тестов, пыталась оптимизировать свои модули, однако у них, по словам руководства IT‑отдела, даже сам движок еще был весь разобран, как ворота из «12 стульев», поэтому не было никаких надежд на то, что веб‑витрина, во‑первых, будет сделана в обозримые сроки, а во‑вторых, что она покажет нужную производительность, без которой ее разработка вообще не имела никакого смысла.
В конце апреля 2002 года было принято второе крайне тяжелое, но необходимое решение: группа веб‑разработки увольняется в полном составе, их работа в течение почти года считается полной потерей времени и денег, а на IT‑отдел ложится задача с помощью ASP.NET опять с нуля написать качественную веб‑витрину, которая любой ценой должна быть запущена до начала следующего сезона, то есть до сентября 2002 года.
Это было жуткое, хотя и закономерное решение. IT‑отдел, который со своими задачами, в общем‑то, вполне справлялся, был поставлен в ситуацию, когда он был вынужден в крайне сжатые сроки и в очень нервной обстановке с нуля сделать то, с чем не справилась другая группа разработчиков. Руководство OZON.ru, разумеется, уже не желало и слышать никаких оправданий. К сентябрю должна быть новая веб‑витрина – точка. Самый крайний срок – конец сентября. В противном случае IT‑отдел считается не справившимся с оказанным ему высоким доверием – со всеми вытекающими последствиями.
Вполне понятно, что в IT‑отделе приняли данную ситуацию безо всяких восторгов. С одной стороны, люди не так давно, год назад, пришли на новую работу, и им вовсе не хотелось ее менять. С другой стороны, задача перед ними была поставлена, мягко говоря, крайне сложная. Но, вместе с тем, у разработчиков вспыхнула некая здоровая злость: терять им было уже нечего, а сложная задача бросала вызов их профессионализму. Энтузиазм, как потом рассказывали в отделе, был необыкновенный. На разработку веб‑витрины были брошены все силы, люди работали очень слаженно, быстро и эффективно.
Это кажется невероятным, но в ночь с воскресенья на понедельник, с 25 на 26 августа, OZON.ru перешел на новую веб‑витрину. Она была полностью написана и отлажена за четыре месяца.
Дата добавления: 2018-10-26; просмотров: 224; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!