Разработка фундамента новой системы
Разработка фундамента новой системы
При разработке нового бэк-офиса пришлось решать массу всяких задач, которые зачастую были связаны не только с программированием как таковым. Бэк-офис – это система, в которой смоделировано и автоматизировано большинство бизнес-процессов фирмы. А что делать, если механизм этого процесса не существует еще даже в теории?
В связи с этим весьма примечательна история с системой прогнозирования закупок. Прогнозирование закупок – задача крайне сложная и важная: закажешь меньше, чем нужно, – не сможешь вовремя выполнить заказы клиентов; закажешь больше – забьешь склад ненужным товаром, в результате чего не останется места для нужного.
Тогда формулу, по которой работала автоматизированная система закупок, на одном из совещаний с руководством IT-отдела нарисовал директор Владимир Долгов. Выглядела эта формула очень просто и даже нелепо, но ее много раз проверяли – и практика доказала ее эффективность.
В основу расчетов была положена идея, что каждому из поставщиков требуется некоторое время на обработку заказов, которое отсчитывается с момента поступления заявки до момента доставки. Причем это время зависит от нескольких различных факторов: организации работы у данного поставщика, расстояния до Москвы и так далее. Формула учитывала имеющиеся заказы, гипотетические заказы, которые могли быть сделаны за время обработки, а также предусматривала некий страховой запас, который учитывал несоответствие между реальной ситуацией на складах поставщиков и предоставляемыми данными.
При всей своей простоте формула действительно работала. Ее много раз проверяли по принципу «Ну и что ты тут нам назаказывала? Ведь столько не нужно – товары будут на складе валяться!». Тем не менее все уходило вовремя – система работала. Конечно, она не могла учитывать ажиотажный спрос, однако при стабильном поступлении заказов, без особых пиков, работала железно.
Во время внедрения формулы в бэк-офисный модуль складывались и забавные ситуации. Когда раздел прогнозирования закупок вчерне был готов, главный разработчик Александр Алехин демонстрировал его работу Владимиру Долгову. Для проверки работы модуля было решено сгенерировать один и тот же заказ у самого крупного поставщика (тогда это была фирма «Топ-книга») по двум алгоритмам: по старому, который просто учитывал имеющиеся заказы, и по новой формуле. Разница оказалась огромной: старый алгоритм давал примерно тысячу книг, а новый – порядка восьми тысяч. Тогда Долгов сказал Алехину: «Если модуль работает правильно, тогда мы эти книги отгрузим. Но если в модуле ошибка, тогда у нас останется несколько тысяч лишних книг. Мы не будем вычитать у тебя из зарплаты. Ты эти книги просто заберешь к себе домой». Алехин подумал и решил сначала еще раз проверить работу модуля. Там оказалась ошибка, в результате чего данные завышались раза в четыре.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Основные направления обеспечения информационной безопасности корпоративной системы как фундамента безопасности карточного бизнеса
Основные направления обеспечения информационной безопасности корпоративной системы как фундамента безопасности карточного бизнеса Основные принципы защиты рабочих станций сотрудников банкаВ зависимости от того, в каких технических условиях проходит работа
Начало новой эры
Начало новой эры 28 февраля 2003 года. С утра было пасмурно. Пока завтракал, выглянуло солнце. Соблазненный его веселыми утренними лучами, заглянувшими через оставшиеся свободными от инея верхние краешки стекол в окне, решил после завтрака прогуляться во дворе.Открыв
Оперативная разработка
Оперативная разработка В процессе оперативной разработки могут использоваться любые из указанных ранее оперативных мероприятий. При этом не исключается существенное нарушение норм действующего законодательства, ущемление конституционных прав и свобод