Как стать автором
Обновить

Комментарии 77

Ты бы отформатировал текст
В смысле больше параграфов?
Пунктуация, стилистика… Очень тяжело читать, по сути не статья, а плохо оформленный выброс сознания. Хотя бы запятые расставили, что ли! Я хотел помочь с исправлением, но стало непонятно, что имелось в виду под некоторыми фразами (к примеру, «не 'pro' версия MS не слишком рада запускать ваши программы как сервисы»), и это гиблое дело забросил.
Все таки я на родном Русском языке уже 16 лет ничего не писал, придется что-то делать с пунктуацией и стилистикой.
вообще я последние 12 лет пишу на /. roman_mir, там наверное у меня стилистика и пунктуация лучше.
Немного поправил, действительно некоторые обороты у меня не годились.
Стек технологий? Java, Spring, Oracle?
«Система началась как стандартная Java бизнес система…»
Проще даже. Java, Struts, PostgreSQL. Expect для переноса данных из firewall на app-server, немного sh тут и там, но совсем легкого. Набросал свой сайт titan-technologies.org
Недоумевал, почему все так гладко прошло, пока не зашел в профиль.
Гладко это только кажется, все таки 2 года работы ушло, то есть были трудности особенно связанные с фактом того, что ритейл мне не знаком был как бизнес, а для системы для магазинов на Linux не просто сделать чтобы некоторые типы устройств работали, у которых только windows драйвера есть. В общем-то мне пришлось изучит сам бизнес, потому как мне не давали жесткие требования, я сам должен был понять где существует необходимость и на что направлять усилия, над чем работать.
Интересное мнение, что если работаешь на той же системе, то расти можешь на том же уровне. Неужели такая зависимость биса от ERP.
Простой ответ: да. Это очень наглядно видно по данным собранным за эти два года, особенно начиная с того момента, когда интегрировали поставщиков в систему и они увидели рост такой, что немногим больше 10 магазинов давали им оборот, который только на 20% ниже оборота, который им дают конкуренты с их пол-сотней магазинов.
На самом деле большая зависимость от аналитики, которой нет в 2х буквенной программе и прочих. У наших поставщиков просто отвратительное управление запасами. У моего поставщика вот уже 2 недели как улетели ПОЛНОСТЬЮ 2 бренда из 5 в самой денежной товарной категории. Иногда запчастей нет по 4-5 месяцев, причем за это время приходит 2 закупки, но в них по 10 запчастей на всю Москву.
Абсолютно верно. Решение этой конкретной проблемы повысило обороты большинства поставщиков, увеличение оборота от 20% до некоторых аномальных ситуаций (300%). То есть сам факт того, что люди заходят в магазин и не могут купить то что им надо это огромный минус, у меня это решено.
А как аналитика связана с управлениями запасами? Зачастую у поставщиков просто руки кривые, поэтому нет достоверной информации в ERP.
Напрямую. Нет статистики продаж, в зависимости от наличия, недели года, и еще кучи факторов, нет средней скорости продаж по дням, неделям, месяцам для каждого товара — как заказать товары с лагом в месяц? Попробуйте эту инфу из 1с выдернуть.
Я выдергивал. У меня была сеть оптовых и розничных точек, на каждой автономная 1С-Торговля 7.7 со своими тараканами. Но в моем случае было несколько сложнее — каждая база ежемесячно обрезалась, и за год набиралось больше сотни баз филиалов. Сливать их в одну — траходром еще тот, нужно серьезное железо и софт. Сделал проще — надстройка «супербаза» открывает базы по отдельности и выдергивает из них нужные данные по условиям, а потом они сводятся в один отчет. По времени это примерно 10 минут за годовой период, если разрешить параллельно открывать базы разных филиалов.

Кроме того, выдранные из баз данные «кешировались» в виде сериализованной сводной таблицы (ТаблицаЗначений сохраненная через ЗначениеВФайл()), видно кто чего смотрел и при желании можно построить другой отчет по уже собранным данным.
На всякий случай я тестирую систему с нагрузкой сто магазинов, надо знать проблемы заранее, так? Получается 40ГБ / год, если брать типичные 10 магазинов и клонировать их чтобы получить 100. 40ГБ для всей базы 100 магазинов за год, это немного данных. Главное чтобы отчеты быстро вылетали. Резать базу тоже можно, но людей интересуют данные за два года, не за месяц. У меня система сама складывает данные всех магазинов в общую базу, из нее можно воспроизвести магазин нажатием клавиши в магазине если там потеряли компьютер например. А так, зачем все это делать, ну вы же занимаетесь RealChat, все теже причины — делаешь что-тио для себя.
В моем случае, 1, 100 или 100 000 магазинов — разницы никакой, просто дольше будет сбор данных. Базы магазинов лежат на флешках или USB-HDD и подключаются по мере необходимости. Видели бы вы, на каком колхозном железе это работало…

Я пробовал сливать в одну базу. Во-первых, это долго, всякие проверки уникальности и защиты от пересортицы отнимают кучу ресурсов. Если без них, то база быстро раздувается, а fullscan-выборки по времени столько же выполняются. И очень хреново распараллеливается. Основная нагрузка идет на очередь I/O диска, SSD стоят как все железо вместе взятое. Флешки дешевле, и их приобретение не напрягает руководство.

Базы режут по соображениям безопасности. Была рейдерская атака, потеряли данные всего за три дня. А злодеям достался только огрызок базы с начала месяца. =) Флешки если что — легко можно выдернуть и уничтожить — прищемить дверью или разбить каблуком.
Я могу поверить про 'колхозное железо'. Мне пришлось начать с очень хороших машин, потому что я не мог сначала иметь общую базу данных, было как-бы 15 отдельных баз (моя модель данных позволяет иметь одновременно все отдельные точки в одной базе и обращаться с ними как с одной), но после того, как все обобщилось и было приведено к одной главной версии базы, то нагрузка резко уменьшилась. Теперь у меня есть малосильный laptop, на котором все это сразу может бежать. То есть из-за того как все сначала было созданно, требования к оборудованию были очень высокие вначале, а теперь требования намного ниже, что позволяет всему этому работать на том, что можно купить в любом магазине, хотя я никогда этого не рекомендую. Насчет полного сканирования — я этого избегаю, такого быть не должно во время дневной работы сети. Насчет резания баз для безопасности — это все очень грустно, поэтому hosting лучше делать в пещерах Альп.
Да, своя ERP это хорошо, вот только вопрос что с ней будет, если вы покинете эту сеть магазинов?
Проработает год-два, и заглохнет, имхо.
Это существенный минус такого подхода для бизнеса — завязка на одного человека/команду.
Это серьезный вопрос и ответ у меня есть — я работаю сейчас именно над тем, чтобы превратить эту систему в продукт, который бы приносил прибыль. Когда что-то начинает приносить прибыль, то это уже другой разговор. В следующем месяце буду в Петербурге на выставке, показывать проект, потом еду обратно в Канаду, там разговариваю с несколькими возможными инвесторами, а в Германии сейчас работаю над тем, чтобы использовать созданную платформу для внедрения знакомым дентистам, то есть я считаю что успешное хобби можно превратить в прибыль, а прибыль дает причину дальнейшего развития.
Кстати есть еще один ответ на этот вопрос: где гарантия того, что без нового способа ведения бизнеса с полной интеграцией всех магазинов и поставщиков, производителей, где гарантия что эта сеть смогла бы выжить, особенно в текущих кризисных условиях? То есть предприниматель всегда делает рискованные шаги, когда начинает новый бизнес, у него нет уверенности в успехе совершенно. Если принимать во внимание все, что касается ведения нового бизнеса вообще и всего что к этому добавляется, когда новый бизнес открывается в России, то риск и так уже огромный. В такой ситуации что будет через 2 года это конечно вопрос хороший, но нужно еще эти два года продержаться. Первые года бизнес вообще прибыль может не приносить, хорошо если за первые пару лет его можно вывести в ноль. Если система помогает конкурировать сразу, если система помогает конкурировать в течении одного года, и оборот растет по отношению к конкурентам, у которых он падает из-за плохой экономической обстановки, то возможно риск использования новой системы не является риском, а только стоимостью установления нового бизнеса.
Что будет с ней дальше, целиком и полностью зависит от того кто делал.
«Запустил» несколько самописок, которые потом сопровождали другие люди. Проблем не было.
Есть и другая сторона. Франч, внедряющий популярный двухбуквенный продукт, может так налажать, что потом это все можно будет только выкинуть и переделывать с начала.
Так что все зависит от исполнителя. Можно сделать хорошо, а можно плохо…
Да, это правда, но я думаю это общеизвестный факт, что хороших программистов мало?
А для написания хорошой, расширяемой ERP с низким порогом входа как пользователей, так и других программистов нужно быть не просто хорошим, но очень хорошим программистом.
А такого пойди найди еще, да и клейма нет соответствуюшего :)
Для проверки нужно обладать как минимум не меньшими знаниями в этой области.
Любых специалистов своего дела мало… коснулся ремонта в квартире, все тоже самое, большая часть бригад криворукие — нормальных еще поискать…

А написание нормально ERP ничего сложного нет. Это 10 лет назад было сложно. А сейчас куча библиотек которые решают основные проблемы. И библиотек хороших.
Пример: Java+Vaadin+Hibernate+БД. Большая часть проблем в этой связке решена. Надо только нарисовать формочки и забиндить на БД. Бизнес логика в ERP очень простая, в смысле программирования, это же не ядерные реакции моделировать, там на 99% простая математика.

Я проект за 3 месяца один нарисовал. Причем vaadin первый раз видел на тот момент.
Самое главное — это иметь человека который может грамотно объяснить чего требуется. Это даже более важно чем хороший программист. Ибо ошибки заложенные на этапе составления ТЗ исправляются многократно сложнее ошибок программистов.
Как вы интересно и стратегически описали процесс! Очень захватывающе читается.

А что за «двухбуквенная система»? Единица — всё-таки не буква вроде как :-)
Спасибо, а про буквы: привык все называть 'character' или 'char', не важно буква или цифра. Еще из девяностых годов, когда использовал контекстно-зависимую грамматику для компиляторов.
Прошу заметить: 'char' != 'буква'. Может быть, подойдёт вариант 'двухсимвольная'?

"Слово из трёх букв", конечно, более узнаваемый в народе бренд.
так он ведь именно так вам и ответил.
Очень интересно.
Не нравится только очень много маркетинговых слоганов от оторых уже уши вянут…
Не могли бы больше конкретики привести? Ибо из статьи понято только что вы написали свою erp и все… ни какие технологии использовали (прим: все на java это не описание технологий) ни как реализовывали…
Мне показалось, что автору маркетинг ни к чему — писали велосипед для себя.
Обычно приходится писать документацию по архитектуре, дизайну, инструкции по применению и поддержке, но как описать все сразу?

* Java + Apache Tomcat + Struts. Еще немного sh + expect.

* Apache Server + mod_jk.so + ajp13, и для шифрования канала OpenSSL.

* PostgreSQL + DBPool (snaq) — pooling. Можно использовать и pool, который идет с Apache Tomcat.

* Офис и директора / менеджеры используют главную консоль в браузере: HTML+CSS+Javascript.

* Поставщики используют свою похожую консоль, ее могут использовать и все другие пользователи системы, но в принципе им это нужно только если они хотят инициировать электронный заказ по поставщику.

* Магазин имеет Java+Tomcat+PostgreSQL тоже, но клиент здесь Java+Swing. Клиент может использоваться как из магазина так и извне если настроить таким образом, то есть можно управлять одним магазином удаленно просто через этот клиент.

* Сервер магазина и сервер офиса общаются через API выполненное как еще один WAR — это отдельная программа, может быть установленна как на том же сервере где и консоли, но может жить и отдельно. После разговора с магазином, этот 'IOServer' дает знать главной системе что есть определенные изменения данных, потому что некоторые данные сидят в cache и их нужно обновить.

* Когда оператор через главную консоль меняет данные, которые должны будут отразиться в магазине (одном или больше), это записывается для дальнейшей пересылки. Магазины настроенны общаться с офисом переодически, 2-4 раза в час. В магазине в системе public ключ для SSL но так же офисный сервер проверяет что запрос от разрешенного для этого магазина IP адреса.

* Для почты используется java mail, для работы с excel файлами jxl, если нужно интегрировать с windows sign-on, то jcifs (CIFS/SMB), javax comm для сериальных портов, jzebra для принтера штрих этикеток, но здесь правда есть и другие решения, здесь некоторые сложности на Linux, нужно использовать ZPLII и прямые комманды в ОС.

* Использую простую message queue для интра-системных переговоров.

* Ночью система запускает работу, которая используется для организации данных, которые были собраны сегодня и которые понадобятся дальше, то есть если что-то слишком интенсивное, оно выброшено в ночную смену, но так же оно может быть factored (перенесено?) на другой процессор и запущено в любое время если эти данные нужно будут раньше.

* Систему можно сбалансировать через Apache сервер и большее количество Apache Tomcat серверов.

Если внимательно посмотреть то там нет ничего как-бы не стандартного, я вообще считаю что главное в алгоритмах, в решениях какие данные держать в памяти, когда и почему, что выбрасывать, что сжимать, что сериализовать и наоборот. То есть сами базовые технологии всем знакомы и обычны — структура кода и алгоритмы, вся совокупность функций, вот что делает систему, не то из каких языков и библиотек она склеена, не так ли?

Например любой пользователь может видеть продажи по продукту, не только за выбранный период, но и вспомогательные периоды, которые позволяют сделать лучший заказ. Сильная возможность фильтрации данных, по характеристикам, промежуткам времени, промежуткам цифровых значений (от и до суммы или от и до кол-ва, от и до цены и т.д.) Можно фильтровать данные по частям названий, частям кодов, для этого написал свой упрощенный regex.

Сервера построенны как WAR файлы с ant, клиенты, если это не в браузере, это JAR файл — application/applet.

Может что-то забыл написать, но наверное это главное.
> я вообще считаю что главное в алгоритмах
Самое главное — структура БД :)
Голова, ноги, хвост. Да, правильная структура БД это важно, не менее важно чем алгоритмы.
Статья хорошая спасибо, но вот как то читаю:
Накупили серверов, памяти, рейды…
Бац!
И перешли на Ubuntu, все разобрали и бухгалтеры довольны стали.
Возможно так и есть. Конечно я мог вместо занятия всем этим купаться в океане и написать об этом тоже, но тогда бухгалтеры бы не были довольны и неизвестно как бы сейчас эта сеть магазинов жила — наверное как и все остальные, но хорошо это или плохо?
Когда что-то получается и приносит пользу — это больше хорошо, чем плохо
скажите пожалуйста
эта retail сетка НЕ В РОССИИ?? так?
СПБ.
вот честно… после слов «каждый магазин сам забивает номенклатуру» а мы потом ее «интелектуально» сводим =) даже не знаю… может у меня просто другие реалии нашего ритейла…

исходя из архитектуры, непонятно, а что кассовые модули у вас тоже через веб-работают?
а что делаете когда связи нет? или когда пинг до торонто 300ms ??
или сервера физически в питере, просто вы их «самолетом» под мышкой везли? ;)

ну и вообще, без обид =) я не знаю как называть систему которая отвечает на вопрос «остатки товаров на любую дату» и «выгружает данные в финансовую систему» через два года после разработки… (ну я так понял из текста может ошибаюсь)…

ритейл кстати какой ?? продуктовый? аптеки? FMCG? обувь\одежда?

Мне не на что обижаться, почему? 'Кассовые модули' — POS? Кассовый аппарат в магазине, с ним общается сервер, который установлен в магазине, это компонент который отвечает за работу отдельной точки. Когда сервер установленный в магазине обменивается данными с сервером в офисе, то если эти данные не требуют подтверждения оператора, сервер магазина обновляет данные в кассу. Он так-же часто считывает данные из кассы и обновляет остатки в магазине и отправляет их в центр. Данные передаются часто, идет толко дельта обмен. Главные сервера в СПБ, куда я их привез 2.5 года назад, но сейчас есть hosting в Германии, хотя я смотрю на Швейцарию для этого. Насчет 'остатки товара на любую дату' — это было недавно добавлено, действительно до этого остатки показывались только текущие. Финансовая система отдельная и в нее выгружаются данные, но это точно тоже самое что было и до этой ERP системы. Там тоже данные выгружались в ту финансовую систему. Эта система только для двух вещей: через нее налоги уходят гос-ву и идет оплата поставщикам. Можете называть все это утюгом!

Ритейл какой пока я не буду обсуждать, там больше десятка магазинов и около 40 тысяч наименований.
POS тоже вы писали на java\pgsql? или было взято какое то стандартное решение?
какое оборудование для фискальных регистраторов\POS?

что будет если «сервер магазина»… не сможет видеть POS?

кол-во человек в команде разработки? или это система одного человека?

закуп я так понимаю децентрализованный в этой сетке
каждый управляющий сам делает заказ через «модуль общения с поставщиками»?
протокол общения поставщиков с этим какой? чтото свое на базе SOAP\XML-RPC\JSON, или какой нибудь Biztalk\CommerceML?
Программное обеспечение POS остался тот, что был и при открытии сети, пока-что это не является моей задачей, там стоит фронтол. Если сервер магазина не видит POS, то в интерфейсе компонента магазина в статусе этото POS загорается красным цветом, в офисе в консоли управления всеми магазинам против этого POS красным загорается предупреждение, сам сервер в магазине пытается прогнать «mount -а». Если касса поломана, то при выгрузке z-отчетов можно указать что использовать только те данные, которые уже есть в системе и не пытаться выгрузить этот день из этой кассы еще раз.

Заказы теперь большинство поставщиков делают сами, но в меньшинстве случаев их делают директор/администратор или менеджер в офисе. Поставщику дается доступ в его специальную консоль, то есть для него готов доступ как только он решает перейти на систему. Если его интересует полная интеграция, есть уже несколько модулей подстроенных на то как работают поставщики, в основном excel/текст, хотя есть и RPC, но для RPC они должны будут воспользоваться библиотекой, котороая им будет дана если они хотят так интегрироваться. То есть им не нужно писать/читать XML, это больше как RMI, то как сейчас система магазина общается с офисом.

Сейчас уже пишется это небольшой и разрозненой по миру командой.
Всетаки непонятно… Зачем поставщику делать заказ в вашей системе? Он же поставляет вам товар а не заказывает у вас… путаница какая-то…
Можно делать заказ несколькими способами, один из способов это использовать нашу систему заказа и данные переходят и в систему поставщика. Это всего лишь другой способ создания заказа, а зачем так делать — у нас больше данных для более точного создания заказа, которых поставщик не имеет.
Вы не поняли… Дело не в способах составления заказа а в самом факте заказа.
Поставщик вам поставляет товар. Зачем ему делать заказ в вашей системе? Поставщику в принципе не зачем лезть в вашу систему…
Почему не понял, я даже ответил: у нас больше данных. Поставщик в своей системе не имеет детальных данных о том, как идут продажи изо-дня в день, он имеет данные о суммах поставок.
Про продажи понятно. Непонятно что поставщик у вас заказывает )
Поставщик или управляющий магазином/администратор создает электронный заказ в системе. Заказ можно изменить и потом применить и этот заказ уходит в систему поставщика и после подтверждения в магазин. Поставщик не заказывает товар у нас, он создает электронный заказ у нас.
Опять в сторону… не интересно что можно делать с заказом. Не надо расказывать что вы делаете или можете делать с заказом.
Тут вопрос: зачем поставщик сам себе заказ делает из системы своего клиента? Я не могу понять юзкейс или бизнес процесс этого…
Есть причина, и это переходит в причину почему вообще поставщики переходят на работу с этой системой на линии, хотя их для этого переводят на реализацию. В этом смысл всей этой новой программы, это не тот способ работы, к которому все привыкли.
Осмелюсь предположить что не то чтобы сам поставщик делает заказ, но тот кто сидит в конкретном магазине делает заказ что ему нужно, но формат данных из этого заказа одобрен поставщиком и он использует эту форму так как своей аналогичной не имеет, за это он получает плюшку — месячные отчеты — сколько и чего он доставил и на какую сумму.
Например, молочные продукты. У них срок хранения маленький, впрок набирать нельзя и каждый вечер составляется «заказ» для пополнения проданого днем. Заказ в кавычках — потому что не дилер его составляет, а сам поставщик на основе данных дилера.
Вот вы внятно показали что к чему. Спасибо.

А автор только воду разливает общими словами… или он просто сам непонимает что делает…
Просто может он больше с технической стороны смотрит а вам нужно «простым» языком расказать :)
Есть поставщики брендов, для которых мы были, соответственно, дилерами и дистрибьюторами. И поставщик бренда хотел видеть все подробности продаж его товаров. Для этого нужно либо открывать гостевой доступ к нашим базам, либо каждый день/неделю/месяц отсылать подробные отчеты в определенном формате. Я сделал в виде отчетов, но были попытки сделать онлайновую базу, заодно в ней заказы принимать. Увы, тогда ничего хорошего не получилось по техническим причинам, да и опыта было маловато. Сейчас бы получилось, но я уже там не работаю.
Сейчас как раз нечто похожее пишу.
Есть головной поставщик. есть его диллеры у диллеров есть суб диллеры и т.д. уровней вложенности не ограниченно.

Задача сделать так чтобы они все работали в единой базе.
Отгрузка от дилера становится автоматом приходом для субдилера и т.д.
Поставщики брендов хотят видет ситуацию в реальном времени.
Ну вот, то что у нас сделано, все имеют доступ к разрешенным им данным в одной базе через свои специфические консоли.
если поставщик видит продажи по сети…
то можно ограничить по кол-ву сверху, чтобы поставщик не мог перетарить сетку… и в тоже время точно мог завести товар в магазин
«Перетарить сетку» — это зависит от того, как поставщик видит бизнес. Если он видит магазины только как конечную точку, куда надо скинуть продукты, то тогда есть такая проблема. Если работать с поставщиком правильно, то он не будет перетаривать сетку, специфически это зависит от метода оплаты за поставленный продукт.
Как именно отправляются заказ поставщику? Просто говоришь им «Вот формат заказа, вот формат ответа. Либо делаете, либо мы с вами не работаем»? Не очень понял про Excel в этой связке.
Или просто в личном кабинете поставщики видят «Сделан заказ товара 1 на 10 штук, товара 2 на 20 штук», переносят руками в свою систему (1С и прочее), и нажимают рядом кнопочку «заказ принят»?
Не интегрированному поставщику заказ отправляют в excel файле, который создают в одной из систем (Титан / Деймос). Там есть подходящие типы отчетов, которые используют для генерирования заказов.

Если же поставщик интегрирован (пользуется системой Деймос), то
1. Он может импортировать excel торг 12 файлы, и они попадают в магазины как электронные накладные
2. Он может создавать заказ в Деймосе, но также заказ за него может создавать один из работников сети магазинов. В данном случае мы позволяем поставщику выгружать файл заказа в одном из двух предусмотренных форматов (excel, текст), если же сеть и поставщик договариваются, то можем выгружать в формате, который поставщик предпочитает.
3. У некоторых (крупных) поставщиков можем принимать заказ через электронную почту, если все на что они идут это импортирование электронной накладной.

Импортирование накладных приходящие от поставщиков тоже кстати делается из файлов различного формата. Торг 12 в основном, но не принципиально. Мы интегрируем формат файла поставщика сами, главное чтобы в нем хватало информации (количества, штрих кода, цены, налоги, суммы, номер накладной и дата).

Если интересуетесь, могу показать на линии.
Допустим поставщик заказал что-то в Excel или получил Excel с заказом. Дальше как данные попадают в его внутреннюю систему (если он не интегрирован), руками?
У большинства поставщиков свои системы, и если они никогда раньше не импортировали заказы от других сетей или магазинов, то это их дело. Мы можем вызывать API поставщика для импорта какого-то файла в их систему, но замечу что из сотен поставщиков, ни один ни попросил об этом. Да, большинство берут заказ и как-то его вводят в свою систему. Мы даем интерфейс для импортирования заказов и накладных, если поставщик имел бы похожую систему, он мог бы тоже самое делать с сетями: дать им интерфейс для импортирования заказов.

Интересно это наша система позволяет создавать в себе заказ и многие поставщики этим пользуются, создают заказ у нас в системе, экспортируют его в файл, а дальше что-то делают с файлом. Есть даже поставщики, которые именно руками вбивают заказы, и им наша система помогла упростить процесс. Пример: менеджер поставщика делает заказ, но потом она звонит какому-то оператору и ЧИТАЕТ заказ по телефону и оператор этот заказ набивает в их систему! Мы дали поставщику наш интерфейс для создания заказов, менеджер теперь у нас в системе создает заказ, экспортирует и посылает оператору по электронной почте, наша система сохраняет им кучу времени. Почему все так? Люди работают как могут, кто знает.
И ведь кто-то в наше время ещё пишет собственные ERP… Счастливчики. Хотя я бы очень хотел взглянуть на подробное обоснование, зачем нужно именно написать свою собственную, а не доработать существующую.
Есть одно «НО» — это не полноценная ERP, это, судя по описанию, CRM + SCM.

А CRM-ов я уже штуки 3 написал, это не сложно. =)
Это кстати точно не CRM. Никакого отношения к CRM вообще не имеет. Это действительно SCM, но так же и ERP, системой описывается и выполняется большое количество бизнес процессов внутри сети, достаточно процессов автоматизировано, есть управление обращения с клиентами, управление процессов общения с поставщиками.
Вернее не CSM :) Нужно кончать со всеми трехбуквенными сокращениями.
С моей точки зрения: делаешь что-то для себя. Например раньше в свободное время я писал всякий 'free source': addons.mozilla.org/en-US/firefox/user/659/ — leetkey, russkey, anykey, booktextmark. Всякая старая всячина. Ну а здесь намного больше нужно сделать, и я вижу это как инвестирование, а дописывать что-то существующее меня не интересует. С точки зрения магазинов: им нужен способ конкурировать с другими, у кого все вот так, как все привыкли, они относительно новая сеть и у них много конкурентов, это поиск.
А что здесь подробно обосновывать?

СтоимостьГотового = ПО + Доработка + Стоимость сопровождения
СтоимостьСвоего = Разработка + Стоимость сопровождения

Стоимость это мера денег и времени.

Если СтоимостьГотового существенно меньше СтоимостьСвоего , то выгодно брать готовое иначе можно свое делать.

Плюс очень много доп факторов, которые в различных случаях могут выйти на первый план. Типа ВендорЛок, работоспособность под линухом (очень часто ERP пишут под винду онли) и т.д.

К тому же в готовых ERP не всегда возможно реализовать нужный функционал…
вот я сейчас тоже стою перед выбором начать писать (опыта в создании таких систем 0) или таки использовать что то готовое но приспособить под потребности «заказчика». Мои интерес в создании собственного велосипеда конечно :) бо заказчик друг друга, и ограничения по времени как бы нет (в течении года хорошобы чтоб заработало), но то что они (предприятие по продаже продуктов и готовой пищи — типа салаты, супы, вторые блюда для доставки...) счас все делают на разных листиках и екселе — меня повергло в ужас… и их бизнес растет и начиняются не стыковки… причем самое сложное чем персонал владет это ексель — в лучшем случае, посему клиент в браузере должны освоить просто, но это должно выглядить просто и без нагромождения, лаконично и прямо доступно) те системы что я просмотрел или не имеют понятного интерфейса (даже мне сложно понять куда что нужно нажать — опыт ведения бизнеса в ретаил системе имеется) или стоимость заоблачная для компании из 15 человек, так что написать свое может быть даже выгодно, бо максимально точно можно вписаться в потребности данного типа предпиятия, ну а мои издержки как бы покрываются желанием научится програмировать такие системы так что мы как говорится нашли друг друга :)
либо Ваш час не стоит ничего, либо управляющие магазинов не умеют считать деньги :)
сейчас есть множество достойных ерп-срм систем, классные пакеты для аналитики и пр. за вполне приемлемые деньги.
Либо что-то еще :)
Так как были вопросы в личку по нагрузке на систему то решил оставить комментарий с данными:

Вот отчет показывающий использование системы (удалил все графы кроме двух, количество запросов и общее время потраченное на все запросы в секундах). Каждый ряд представляет собой одного пользователя. В данном случае 95 пользователей и эти данные выбраны с 1 по 29 марта 2013. Сразу скажу что моя ERP система обрабатывает отчеты очень быстро за счет правильной модели данных и правильного использования оперативной памяти для того, чтобы держать в памяти такие данные, которые во первых используются во всем, во вторых данные, которые одновременно и возможно держать в памяти (они не заполнят всю память собой) и содержание их в памяти действительно ускорит работу отчетов. 90% отчетов выполняются меньше чем за 1 секунду, 95% отчетов выполняются меньше чем за 5 секунд, 99% отчетов выполняются меньше чем за 15 секунд, но бывают исключительные ситуации, когда сразу выполняется много отчетов и некоторые отчеты все равно достаточно медленные, самый медленный отчет, который сейчас есть может быть сделан приблизительно за 300 секунд.

Эта ERP система одновременно обслуживает пользователей и управляет работой сети, то есть обьединяет в одну информационную сеть 13 магазинов и 85 поставщиков (это те, кто в системе, всего поставщиков около 120). Каждые 5 минут идет синхронизация данных между магазинами и центром. Также система используется для рассылки сообщений, обработки электронных накладных. Также сейчас в системе поставщикам дали возможность загружать картинки и прицеплять их к товарам, продвигается создание электронного каталога (следующий шаг электронный магазин и обьединенным управлением обычных и электронного магазина одними и теми же людьми и функциями)

1-29 марта, один ряд = один уникальный пользователь
всего запросов всего секунд
2 1
7 2
11 3
15 7
16 11
17 8
19 2
22 5
25 75
25 16
28 15
30 35
32 28
35 22
35 17
36 20
38 50
40 30
42 33
47 21
48 34
56 37
58 32
60 47
60 30
64 47
65 57
76 31
77 1
77 69
85 28
85 47
86 47
88 64
90 53
91 43
92 148
95 77
105 84
114 83
117 90
117 132
117 89
124 98
130 84
132 93
133 95
135 116
141 125
143 89
144 766
148 92
149 79
154 83
157 119
157 113
161 89
162 137
164 110
167 68
176 185
179 118
190 77
195 216
207 154
219 104
223 71
230 183
231 635
235 197
300 234
315 272
316 183
323 812
323 1118
358 137
364 257
386 2312
412 103
620 167
656 3421
657 622
728 702
734 2970
763 797
819 2019
991 1141
1057 1747
1099 391
1138 299
1202 1425
2392 2390
3992 3679
9057 1288
— 95 пользователей

Система расчитана на рост, в ней больше мощности чем необходимо на данный момент, в общем она может использоваться с одной машины и имея две машины мы можем в случае проблемы с одной из них так и делать.

Программный сервер:

Supermicro 1U Server with 650Watts High efficiency Power Supply
(Key Features
1. Up to Dual Intel® 64-bit Xeon® Quad-Core or Dual-Core, with 667 / 1066 / 1333 MHz FSB
2. Up to 32GB DDR2 667 & 533 SDRAM Fully Buffered DIMM (FB-DIMM)
3. Left Universal Slot (Full-height, Full-length): 1 64-bit 133MHz PCI-X OR 1 (x8) PCI-Express
4. Right Universal Slot (Low-profile): 1 64-bit 133MHz PCI-X OR 1 (x8) PCI-Express
5. Intel® (ESB2/Gilgal) 82563EB Dual-port Gigabit Ethernet Controller
6. 4 x 3.5" Hot-swap SATA Drive Bays
7. 560W High-efficiency Power Supply)

2 x Intel Xeon Quad-Core E5405 2GHz 1333MHz 771pin 12MB CPUs
32GB DDR2-667 Supermicro cert ECC RAM
2 x Seagate 1TB sata2 Enterprise hard drives(Raid 1/mirror)
3ware 2-channel controller card kit
Slim CD-ROM

top — 14:07:18 up 40 days, 21:11, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 182 total, 1 running, 181 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32690192k total, 32531156k used, 159036k free, 260196k buffers
Swap: 18366456k total, 0k used, 18366456k free, 26528148k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23810 tomcat 20 0 23.3g 2.5g 10m S 3.0 7.9 45:11.53 java
3831 apache 20 0 249m 17m 2904 S 0.7 0.1 0:52.25 httpd
5529 apache 20 0 249m 17m 2876 S 0.7 0.1 0:20.40 httpd
2505 apache 20 0 249m 17m 2904 S 0.3 0.1 0:46.95 httpd
5123 apache 20 0 251m 19m 2900 S 0.3 0.1 0:23.63 httpd
5528 apache 20 0 249m 17m 2872 S 0.3 0.1 0:19.73 httpd
12439 apache 20 0 249m 17m 2872 S 0.3 0.1 0:13.69 httpd
15514 apache 20 0 249m 17m 2868 S 0.3 0.1 0:09.67 httpd
15515 apache 20 0 249m 17m 2868 S 0.3 0.1 0:09.28 httpd
15516 apache 20 0 249m 17m 2868 S 0.3 0.1 0:09.58 httpd
1 root 20 0 4076 856 596 S 0.0 0.0 0:01.00 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0


Главный модуль ERP на Apache Tomcat:

JAVA_OPTS="$JAVA_OPTS -Xms2000m -Xmx19000m -Xss2m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC"

(еще сервер используется для демо ERP системы и еще документационной системе в другом Tomcat Apache



в Apache сервере для различных программных контекстов приходится использовать такие параметры:
SSLRenegBufferSize 80000000 — это используется для запросов системы синхронизации данных между магазинами
SSLRenegBufferSize 1000000 — это используется для запросов формирующихся поставщиками (в это входят и импорты накладных, загрузка изображений товара)

lspci
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01)
04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
06:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)
08:00.0 PCI bridge: Intel Corporation 6702PXH PCI Express-to-PCI Bridge A (rev 09)
0a:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)

— Сервер базы данных:

Supermicro 2U power Server with 800W Redundant
Power Supply/12 hot- plug drive space
(Motherboard Features:
1. Up to Dual Intel® 5500 series Xeon® Quad/Dual-Core, with QPI up to 6.4 GT/s
2. Intel® 5520 (Tylersburg) Chipset
3. Up to 96GB DDR3 1333/ 1066/ 800MHz ECC Registered DIMM / 24GB Unbuffered DIMM
4. Intel® 82573V/L Dual-port Gigabit Ethernet Controller
5. LSI 1068E 8-Port SAS Controller; RAID 0, 1, 10; RAID 5 optional
6. 6x SATA2 (3 Gbps) Ports via ICH10R Controller
7. 2 (x16) PCI-E 2.0, 1 (x4) PCI-E (in x 8 slot), 3x PCI 33MHz slots
8. Realtek ALC883 7.1 HD Audio
9. 2x IEEE 1394a Headers
10. IPMI 2.0 (SIMLC) Slot t
)

1 x Intel Xeon Quad-Core E5504 2GHz 4.8GT/s 1366pin 4MB CPU
48GB DDR3-1333 ECC RAM
2 x X25-M SSD drives (Raid 1/mirror)
2 x 1TB sata2 Seagate ES drives(Raid 1/mirror)
2 x 3ware 2 port controller card kit
Rails

top — 14:05:25 up 40 days, 21:08, 1 user, load average: 0.10, 0.34, 0.43
Tasks: 147 total, 2 running, 145 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 49067492k total, 48819492k used, 248000k free, 626136k buffers
Swap: 14254072k total, 7004k used, 14247068k free, 46557548k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
302 postgres 20 0 12.1g 2460 1104 S 0.3 0.0 1:02.79 postmaster
1478 root 20 0 6880 332 272 S 0.3 0.0 33:56.09 irqbalance
27380 root 20 0 14856 1176 856 R 0.3 0.0 0:00.07 top
1 root 20 0 4076 708 600 S 0.0 0.0 0:00.74 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.13 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root RT -5 0 0 0 S 0.0 0.0 0:00.16 migration/1

00:00.0 Host bridge: Intel Corporation X58 I/O Hub to ESI Port (rev 13)
00:01.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 1 (rev 13)
00:03.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 3 (rev 13)
00:07.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 7 (rev 13)
00:0e.0 Host bridge: Intel Corporation Device 341c (rev 13)
00:0e.1 Host bridge: Intel Corporation Device 341d (rev 13)
00:0e.2 Host bridge: Intel Corporation Device 341e (rev 13)
00:14.0 PIC: Intel Corporation X58 I/O Hub System Management Registers (rev 13)
00:14.1 PIC: Intel Corporation X58 I/O Hub GPIO and Scratch Pad Registers (rev 13)
00:14.2 PIC: Intel Corporation X58 I/O Hub Control Status and RAS Registers (rev 13)
00:14.3 PIC: Intel Corporation X58 I/O Hub Throttle Registers (rev 13)
00:16.0 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.1 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.2 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.3 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.4 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.5 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.6 System peripheral: Intel Corporation X58 Chipset QuickData Technology Device (rev 13)
00:16.7 System peripheral: Intel Corporation DMA Engine (rev 13)
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 1
00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 5
00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 6
00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller
00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller
00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller
00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller
01:02.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
02:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)
03:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)
04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
05:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)
06:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4550]
06:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Series]

PostgreSQL
postgresql.conf:


max_connections = 300

shared_buffers = 12000MB

work_mem = 256MB

maintenance_work_mem = 200MB

wal_level = archive

wal_buffers = 32MB

checkpoint_segments =32

archive_timeout = 20min

autovacuum = on

autovacuum_vacuum_scale_factor = 0.0004

autovacuum_analyze_scale_factor = 0.00004


Не знаю поможет это кому-то или нет, но могу сказать еще что эта ERP система сильно отличается от других тем, что использует память машины по другому и поэтому дает пользователям мгновенные данные, а это сильно увеличивает ее пользу.

вот это кстати да, про память, просмотреные мной безплатные системы — это какие-то неповоротливые монстры даже при генерировании простеньких отчетов
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.