Два с половиной года назад появилась необходимость в системе управляющей работой предприятия, в данном случае небольшой сети магазинов. Начали они с какой-то минимальной коробочной программой, но это не была всем известная стандартная двухбуквенная система. Предложил приложить свои усилия, стало интересно написать полностью свою собственную ERP. В общем я приблизительно понимал во что это мне обойдется, работаю на контрактах с 95го года в основном в телекомах, банках, страховых компаниях, но иногда в производстве. Видел достаточно проектов чтобы осознавать масштаб задуманного, но решил что свинья не сьест, подавится, короче принялся за это мероприятие.
Первым делом нужно было поставить нормальное оборудование вместо того что там было, firewall приобрел в Монреале, два сервера заказал в Калифорнии. Заехал за ними из Онтарио (сам переезжаешь границу, налоги на свой риск), в общем L.A., Торонто, Франкфурт, Питер. Железо подбиралось по нескольким параметрам: база данных с возможностью добавления второго процессора, памяти до 96ГБ и до 16 3.5" дисков. 1U программный сервер уже с двумя процессорами и 32ГБ. На программном сервере два жестких диска на RAID1. На БД два жестких диска под RAID1 и два SSD тоже на своем RAID1, все в коробке 2U. Главная база находится на SSD, на жестких дисках стоит OS и туда же идет резервное копирование. Firewall имеет 6 портов в коробке 1/2U, внутри жесткий диск и по желанию Flash карта, сериальный порт, VGA, и наружный электронный монитор здоровья. Потом установка Red Hat, конфигурация серверов, OpenBSD на firewall. Там была веселая история с носками в железных коробках и всей начинкой в ручной клади, но не в этом суть.
Для начала нужно было все это собрать и установить, что и было проделано с помощью неких 'специалистов по металлу' (еще одна веселая история). После этого была экскурсия по магазинам, где и началась собственно разработка. Первым делом нужно было собрать данные из уже существующих систем в одно целое. Для этого была написана система передающая данные через SSL (OpenBSD очень удобно для этого, кроме того мне импонирует Тео). Данные собирались по заданному расписанию, к счастью много думать о том что именно передавалось не было необходимости, все что шло из касс в сервер магазина и все что шло из сервера в кассы ловилось, записывалось в местную простую файловую 'базу' и ожидало времени для следующей передачи. Система делала попытку запустить модем и после этого передавала. Все данные скапливались у виртуального пользователя OS. Каждый магазин получил инструкцию, чтобы не выключали программу (запустить программу как сервис в не профессиональной версии MS Windows не вышло).
Следующий шаг это конечно разобраться в приходящих скапливающихся файлах, обработать и записать их в новую базу, которую тоже нужно аккуратно смоделировать. Это достаточно длинный не очень приятный процесс, часть файлов весьма не плохо документированы, но все что касается серверной части программы, которую тогда использовали для управления сетью, это был просто дикий запад и никакой документации — как хочешь так и понимай эту ненормальную модель. В какой-то момент данные поползли из firewall в новую базу. Было несколько заходов естественно, базу приходилось стирать, исправлять новые найденные проблемы и снова перегружать. В конце концов это было решено, данные стали приходить каждые двадцать минут и загружаться, что сделало жизнь легче. Теперь настал вопрос использования всего этого богатства.
Отступлю на минуту — зачем писать свою ERP? Какой смысл, ведь есть много коробочных решений и кроме того известно что в России большинство привыкли к одной широко известной программе? Простого ответа нет, есть много сложных, но можно сказать так: это надо было сделать потому что конкурировать новой небольшой сети с уже существующими сетями магазинов трудно. Нужно иметь какой-то способ оттолкнуться от всех других, нужен новый подход к конкуренции. Фактически это было большим риском с разных позиций, и с моей точки зрения (2 года уже все-таки) и с точки зрения сети — где гарантия что все пройдет нормально и что не проще установить что используют все? Но дело именно в том, что то, что все используют держит всех на одном уровне, а когда ты на одном уровне со всеми то гарантии на выживание такие-же как и у всех других, кто точно как ты.
Система началась как стандартная Java бизнес система (JVM, Tomcat, Struts, Apache Server, PostgreSQL, еще немного shell и expect), но для более быстрой разработки было создано большое количество генераторов кода. Стандартный код генерируется из стандартных конфигурационных файлов, так создаются первые заготовки общения с базой данных, весь презентационный фасад и все что их связывает (оболочка бизнес логики), это было правильное решение, это сэкономило невероятное количество времени. Буквально то, что делается руками 3-4 дня теперь делалось за пару часов. Скоро стало понятно что работать над этой программой как над 'стандартной' не получится, нужно делать несколько архитектурных решений, которые или сработают и поднимут скорость исполнения или все это вообще накроется, потому как я привык к пользователям, которые ожидают ответ от системы в течении 200-800 миллисекунд, не больше. Но здесь уже начали делать отчеты, которые охватывали около 15 магазинов и промежутки времени минимум в 1 месяц, но вскоре промежутки времени в отчетах выросли до года. То есть человек 40 директоров/менеджеров интересовали продажи категорий товара в 1 или всех магазинах и они хотели видеть данные за 1-12 месяцев сразу. Пришлось перерабатывать как использовалась обьектная модель, никто не хочет ждать отчета 30 минут, да и неприлично такое людям давать. После месяца работы решение было найдено, кроме того теперь каждый пользовательский запрос на отчет был занесен в базу, можно было смотреть уже через саму систему кто что делает, сколько это берет времени, какие они используют параметры. Это стало полезным для наблюдения за работой сотрудников и для обучения людей, потому как система позволяет пользователям писать упрощенный regex для фильтрации продуктов, а люди даже с максимально простым подобием regex имеют некоторые сложности. Но в общем результат оказался нормальным, девяносто процентов запросов теперь делались меньше чем за одну секунду, еще 9 процентов меньше чем за 10 секунд и еще один процент брал 1-2 минуты, что уже легче.
Конечно ERP это не только отчеты по собранным данным, это много другого, например управление входом данных, а здесь тоже свои закавыки. Каким образом обьединить данные из 15 магазинов в одну базу, если в каждом магазине товар заносят в базу по своему? Свои названия, иногда свои штрих кода, свои 'папки', даже свои цены. Для этого системе пришлось научиться автоматически обьединять товары в список возможных идентичных товаров, а потом позволять оператору изменять список, править части данных и записывать эти ассоциации как один товар. Естественно это не легкий процесс не только с точки зрения системы, но оператор сам должен быть в состоянии правильно этим управлять и система должна позволять эти ошибки ловить и потом исправлять (и для этого была создана специальная контрольная панель, в ней разные функции позволяли прогонять различную логику сразу над всеми данными в системе — задаешь несколько параметров, нажимаешь на клавишу и ждешь несколько минут пока она не выплюнет файл с возможными проблемами). Одновременно нужно уже быть в состоянии создавать продукты, и правильно их классифицировать, не хочу углубляться в это, но здесь появилось несколько решений, которых не существует в других системах подобного рода, особенно что касается способа классификации и ее иерархии.
С ERP конечно чем больше функций, тем лучше. Собранных данных стало хватать чтобы добавить к системе компонент для рассылки предложений и рекламы, а затем компонент для анализа данных по покупкам клиентов до и после рассылки. Клиенты стали получать поздравления с днем рождения (и некоторые даже отвечают на авто-поздравления, что весьма радует). Был развит еще один большой компонент для интеграции поставщиков в работу сети, но надо сказать что сначала поставщики весьма сопротивлялись даже идее такого подхода к работе, но так как некоторые все таки были уговорены и перешли на новый способ поставки, а в системе появились графические отчеты, которые в состоянии сравнивать продажи по любым характеристикам (например можно сравнить продажи групп товаров по брэндам и по поставщикам на одном графике за любой промежуток времени и по любым магазинам), то в течении года большинство поставщиков перешли на систему, потому что они просто увидели данные, и с данными, в отличии от голословных утверждений, не поспоришь. С поставщиками количество пользователей выросло в четыре раза, но никаких изменений в скорости не наблюдалось, а кроме того со скоростью помогло то, что было проделанно в следующем пункте.
От сбора и управления полученными данными, до ассоциации множества товаров в более общие товары, применимые сразу во всех магазинах, следующий вопрос: пора убирать существующую систему управления в магазинах и ставить свою, интегрированную, позволяющую полностью нормально работать с каждым магазином, позволяющую вести полный учет всех документов и товаров. С нуля это заняло около трети года, система как обычно двойная — сервер/клиент, сервер интегрирован через API главной платформы, во все стороны потекли документы, уже не файлы, настало время и можно было выключить первичный файловый обмен. В общем за 40 часов все магазины были переведены на новую систему управления, но это так же включило в себя переход на GNU/Linux (Ubuntu), в общем это экономит какие-то деньги на лицензиях, но даже важнее, меньше стало возможности получить какой-то вирус. Система автоматом общается с центральной платформой и с кассами/проверщиками цен, не нужны больше ручные проводки и так называемые z-отчеты больше не брали почти по 2 часа времени как на предидущем решении, это ушло в прошлое. Все это хорошо сказалось а скорости системы, потому что стало возможным переключить внутри кода логику с первичной, (той что работала по принципу — есть куча магазинов, но у них у всех могут быть свои продукты со своими ценами, и хотя это уже было все вместе ассоциированно в общей системе, обратно в магазины эти ассоциации не попадали), на логику второй версии — вся сеть работает на одной общей базе, и это уменьшает требования ко всему, и к используемой памяти и к сложности запросов к БД и к количеству запросов.
С появлением всего документо-оборота в платформе, стало возможным ублажить и бухгалтерию. До этого они были в ручном режиме, и их было просто весьма жалко. У них конечно были необходимые бухгалтерские программы и программы позволяющие оплату через банк в сети, но почти пол-года они мучались с загрузкой данных в свои программы. Они действительно были рады получить возможность автоматической выгрузки нужных им данных в нужном для них формате, а позже их настроение поднял отчет по оплате поставщикам.
Кстати всего этого еще не хватало чтобы показать отчет, который имел бы в себе остатки по любым товарам на любой промежуток времени — это не что-то, о чем сначала задумываешься особенно. Но позже видишь что есть информация, которую нужно собирать специфически только для одного типа отчета, а иначе пострадаешь конкретно если попытаешься что-то такое вычислить на ходу.
Еще предстоит сделать кучу всего и вообще программы такого рода никогда не могут завершиться, нельзя поставить последнюю точку и сказать: все, это максимум, больше здесь делать нечего. Но после двух лет над этим проектом если меня кто-то спросит — стоит ли писать что-то свое, большое, с нуля и с кучей неизвестных? Думаю что отвечу что нужно писать.
Если есть вопросы, пишите в комментариях, я отвечу.
Первым делом нужно было поставить нормальное оборудование вместо того что там было, firewall приобрел в Монреале, два сервера заказал в Калифорнии. Заехал за ними из Онтарио (сам переезжаешь границу, налоги на свой риск), в общем L.A., Торонто, Франкфурт, Питер. Железо подбиралось по нескольким параметрам: база данных с возможностью добавления второго процессора, памяти до 96ГБ и до 16 3.5" дисков. 1U программный сервер уже с двумя процессорами и 32ГБ. На программном сервере два жестких диска на RAID1. На БД два жестких диска под RAID1 и два SSD тоже на своем RAID1, все в коробке 2U. Главная база находится на SSD, на жестких дисках стоит OS и туда же идет резервное копирование. Firewall имеет 6 портов в коробке 1/2U, внутри жесткий диск и по желанию Flash карта, сериальный порт, VGA, и наружный электронный монитор здоровья. Потом установка Red Hat, конфигурация серверов, OpenBSD на firewall. Там была веселая история с носками в железных коробках и всей начинкой в ручной клади, но не в этом суть.
Для начала нужно было все это собрать и установить, что и было проделано с помощью неких 'специалистов по металлу' (еще одна веселая история). После этого была экскурсия по магазинам, где и началась собственно разработка. Первым делом нужно было собрать данные из уже существующих систем в одно целое. Для этого была написана система передающая данные через SSL (OpenBSD очень удобно для этого, кроме того мне импонирует Тео). Данные собирались по заданному расписанию, к счастью много думать о том что именно передавалось не было необходимости, все что шло из касс в сервер магазина и все что шло из сервера в кассы ловилось, записывалось в местную простую файловую 'базу' и ожидало времени для следующей передачи. Система делала попытку запустить модем и после этого передавала. Все данные скапливались у виртуального пользователя OS. Каждый магазин получил инструкцию, чтобы не выключали программу (запустить программу как сервис в не профессиональной версии MS Windows не вышло).
Следующий шаг это конечно разобраться в приходящих скапливающихся файлах, обработать и записать их в новую базу, которую тоже нужно аккуратно смоделировать. Это достаточно длинный не очень приятный процесс, часть файлов весьма не плохо документированы, но все что касается серверной части программы, которую тогда использовали для управления сетью, это был просто дикий запад и никакой документации — как хочешь так и понимай эту ненормальную модель. В какой-то момент данные поползли из firewall в новую базу. Было несколько заходов естественно, базу приходилось стирать, исправлять новые найденные проблемы и снова перегружать. В конце концов это было решено, данные стали приходить каждые двадцать минут и загружаться, что сделало жизнь легче. Теперь настал вопрос использования всего этого богатства.
Отступлю на минуту — зачем писать свою ERP? Какой смысл, ведь есть много коробочных решений и кроме того известно что в России большинство привыкли к одной широко известной программе? Простого ответа нет, есть много сложных, но можно сказать так: это надо было сделать потому что конкурировать новой небольшой сети с уже существующими сетями магазинов трудно. Нужно иметь какой-то способ оттолкнуться от всех других, нужен новый подход к конкуренции. Фактически это было большим риском с разных позиций, и с моей точки зрения (2 года уже все-таки) и с точки зрения сети — где гарантия что все пройдет нормально и что не проще установить что используют все? Но дело именно в том, что то, что все используют держит всех на одном уровне, а когда ты на одном уровне со всеми то гарантии на выживание такие-же как и у всех других, кто точно как ты.
Система началась как стандартная Java бизнес система (JVM, Tomcat, Struts, Apache Server, PostgreSQL, еще немного shell и expect), но для более быстрой разработки было создано большое количество генераторов кода. Стандартный код генерируется из стандартных конфигурационных файлов, так создаются первые заготовки общения с базой данных, весь презентационный фасад и все что их связывает (оболочка бизнес логики), это было правильное решение, это сэкономило невероятное количество времени. Буквально то, что делается руками 3-4 дня теперь делалось за пару часов. Скоро стало понятно что работать над этой программой как над 'стандартной' не получится, нужно делать несколько архитектурных решений, которые или сработают и поднимут скорость исполнения или все это вообще накроется, потому как я привык к пользователям, которые ожидают ответ от системы в течении 200-800 миллисекунд, не больше. Но здесь уже начали делать отчеты, которые охватывали около 15 магазинов и промежутки времени минимум в 1 месяц, но вскоре промежутки времени в отчетах выросли до года. То есть человек 40 директоров/менеджеров интересовали продажи категорий товара в 1 или всех магазинах и они хотели видеть данные за 1-12 месяцев сразу. Пришлось перерабатывать как использовалась обьектная модель, никто не хочет ждать отчета 30 минут, да и неприлично такое людям давать. После месяца работы решение было найдено, кроме того теперь каждый пользовательский запрос на отчет был занесен в базу, можно было смотреть уже через саму систему кто что делает, сколько это берет времени, какие они используют параметры. Это стало полезным для наблюдения за работой сотрудников и для обучения людей, потому как система позволяет пользователям писать упрощенный regex для фильтрации продуктов, а люди даже с максимально простым подобием regex имеют некоторые сложности. Но в общем результат оказался нормальным, девяносто процентов запросов теперь делались меньше чем за одну секунду, еще 9 процентов меньше чем за 10 секунд и еще один процент брал 1-2 минуты, что уже легче.
Конечно ERP это не только отчеты по собранным данным, это много другого, например управление входом данных, а здесь тоже свои закавыки. Каким образом обьединить данные из 15 магазинов в одну базу, если в каждом магазине товар заносят в базу по своему? Свои названия, иногда свои штрих кода, свои 'папки', даже свои цены. Для этого системе пришлось научиться автоматически обьединять товары в список возможных идентичных товаров, а потом позволять оператору изменять список, править части данных и записывать эти ассоциации как один товар. Естественно это не легкий процесс не только с точки зрения системы, но оператор сам должен быть в состоянии правильно этим управлять и система должна позволять эти ошибки ловить и потом исправлять (и для этого была создана специальная контрольная панель, в ней разные функции позволяли прогонять различную логику сразу над всеми данными в системе — задаешь несколько параметров, нажимаешь на клавишу и ждешь несколько минут пока она не выплюнет файл с возможными проблемами). Одновременно нужно уже быть в состоянии создавать продукты, и правильно их классифицировать, не хочу углубляться в это, но здесь появилось несколько решений, которых не существует в других системах подобного рода, особенно что касается способа классификации и ее иерархии.
С ERP конечно чем больше функций, тем лучше. Собранных данных стало хватать чтобы добавить к системе компонент для рассылки предложений и рекламы, а затем компонент для анализа данных по покупкам клиентов до и после рассылки. Клиенты стали получать поздравления с днем рождения (и некоторые даже отвечают на авто-поздравления, что весьма радует). Был развит еще один большой компонент для интеграции поставщиков в работу сети, но надо сказать что сначала поставщики весьма сопротивлялись даже идее такого подхода к работе, но так как некоторые все таки были уговорены и перешли на новый способ поставки, а в системе появились графические отчеты, которые в состоянии сравнивать продажи по любым характеристикам (например можно сравнить продажи групп товаров по брэндам и по поставщикам на одном графике за любой промежуток времени и по любым магазинам), то в течении года большинство поставщиков перешли на систему, потому что они просто увидели данные, и с данными, в отличии от голословных утверждений, не поспоришь. С поставщиками количество пользователей выросло в четыре раза, но никаких изменений в скорости не наблюдалось, а кроме того со скоростью помогло то, что было проделанно в следующем пункте.
От сбора и управления полученными данными, до ассоциации множества товаров в более общие товары, применимые сразу во всех магазинах, следующий вопрос: пора убирать существующую систему управления в магазинах и ставить свою, интегрированную, позволяющую полностью нормально работать с каждым магазином, позволяющую вести полный учет всех документов и товаров. С нуля это заняло около трети года, система как обычно двойная — сервер/клиент, сервер интегрирован через API главной платформы, во все стороны потекли документы, уже не файлы, настало время и можно было выключить первичный файловый обмен. В общем за 40 часов все магазины были переведены на новую систему управления, но это так же включило в себя переход на GNU/Linux (Ubuntu), в общем это экономит какие-то деньги на лицензиях, но даже важнее, меньше стало возможности получить какой-то вирус. Система автоматом общается с центральной платформой и с кассами/проверщиками цен, не нужны больше ручные проводки и так называемые z-отчеты больше не брали почти по 2 часа времени как на предидущем решении, это ушло в прошлое. Все это хорошо сказалось а скорости системы, потому что стало возможным переключить внутри кода логику с первичной, (той что работала по принципу — есть куча магазинов, но у них у всех могут быть свои продукты со своими ценами, и хотя это уже было все вместе ассоциированно в общей системе, обратно в магазины эти ассоциации не попадали), на логику второй версии — вся сеть работает на одной общей базе, и это уменьшает требования ко всему, и к используемой памяти и к сложности запросов к БД и к количеству запросов.
С появлением всего документо-оборота в платформе, стало возможным ублажить и бухгалтерию. До этого они были в ручном режиме, и их было просто весьма жалко. У них конечно были необходимые бухгалтерские программы и программы позволяющие оплату через банк в сети, но почти пол-года они мучались с загрузкой данных в свои программы. Они действительно были рады получить возможность автоматической выгрузки нужных им данных в нужном для них формате, а позже их настроение поднял отчет по оплате поставщикам.
Кстати всего этого еще не хватало чтобы показать отчет, который имел бы в себе остатки по любым товарам на любой промежуток времени — это не что-то, о чем сначала задумываешься особенно. Но позже видишь что есть информация, которую нужно собирать специфически только для одного типа отчета, а иначе пострадаешь конкретно если попытаешься что-то такое вычислить на ходу.
Еще предстоит сделать кучу всего и вообще программы такого рода никогда не могут завершиться, нельзя поставить последнюю точку и сказать: все, это максимум, больше здесь делать нечего. Но после двух лет над этим проектом если меня кто-то спросит — стоит ли писать что-то свое, большое, с нуля и с кучей неизвестных? Думаю что отвечу что нужно писать.
Если есть вопросы, пишите в комментариях, я отвечу.