Garya sleshiyИзвращенцем справедливей было бы назвать того, кто пытался автоматизировать, да не довел работу до ума.Футы-нуты! Да как же он может довести работу до ума, если это НЕ В ЕГО СИЛАХ ? Разве IT-шник должен создавать каталог сотни тысяч насосов, генераторов, двигателей и прочая-прочая-прочая? И какой IT-шник это реально сможет сделать? Он что, специалист в этой области? Он может выйти на руководство и попросить это сделать. И получить отлуп - дескать, люди заняты, им некогда.

Специалисты в оласти насосной техники, двигателей и проч. - есть, но они действительно заняты на всю катушку. Для того, чтобы разработать такой каталог, нужно этой работой пожертвовать . Что значит "пожертвовать"?" Это значит потерять часть заказов, прибыли, выручки. А некоторых заказчиков, возможно, потерять навсегда.

Программа работает - ее функционала достаточно для автоматизации продаж. Но она в принципе не может стыковаться, например, с программой бухгалтерского учета, которая оперирует справочником номенклатуры . В бухгалтерии справочник номенклатуры какой-то есть, но он создавался стихийно - БУХГАЛТЕРАМИ (!!!) и, естественно, очень далек от того, чтобы соответствовать представлениям сэйлзов.

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

Если я правильно понял, то то что у Вас было решено самопиской, вполне решается в ERP-системах (по крайней мере в одной известной мне) функционалом Конфигуратор продаж. Который предполагает поддержку продаж, да в принципе и производственных заказов на изделия с изменяющимися опциями. И стык с финансами производится не на уровне номенклатуры, а на уровне заказов на продажу/производство. Хотя варианты каждой опции прописывать конечно нужно, но это все равно не столько работы, сколько заводить каждое сочетание опций как отдельную номенклатуру.

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

Подобные ситуации встречаются в позаказном производстве довольно часто, так что вполне возможно что заказы на изделия/товар меняющие опции могли учесть не только в ERP но и в самописках для позаказного производства или организации продаж товаров, имеющих множество многовариантных опций (это я на тот случай, чтобы не заподозрили в том что я вступаю в спор на стороне ERP, против самописок :) )

Garya ImpConsЕсли я правильно понял, то то что у Вас было решено самопиской, вполне решается в ERP-системах (по крайней мере в одной известной мне) функционалом Конфигуратор продаж. Который предполагает поддержку продаж, да в принципе и производственных заказов на изделия с изменяющимися опциями. И стык с финансами производится не на уровне номенклатуры, а на уровне заказов на продажу/производство. Хотя варианты каждой опции прописывать конечно нужно, но это все равно не столько работы, сколько заводить каждое сочетание опций как отдельную номенклатуру.В конфигуратор вводится информация о параметрах заказа. Под параметры подбираются комплектующие с учетом имеющихся ограничений (что с чем стыкуется, а что с чем не стыкуется). Справочника номенклатуры продукции на все комбинации комплектации действительно нет, но есть номенклатурный справочник комплектующих, из которых собирается готовая продукция. То есть, какой-то справочник в ERP-системе обязан быть в любом случае.

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

Т.е. имеем решение - в системе фиксируется закупка/производство (не знаю как Ваш холдинг их получает) насосы без расширенного описания опций, только для того чтобы Вы могли их идентифицироваь внутри. Сейлзы с помощью функциональности Конфигуратора набирают заказ на продажу уже на насос с расширенным пакетом опций. Создается рабочий заказ, лист комплектации состоит только из одного насоса с вашим внутреним набором опций. Рабочий заказ при завершении списывает со склада насос с органиченным набором опций и создает на складе заказ с расширенным набором опций, который мы на основе уже введеного сейлзом заказа на продажу отгружаем клиенту.
Итого в сухом остатке имеем:

Дополнительно работ:
1. Дополнительно нужно ввести опции (сегменты) - но их и в самописке ввести Вам все равно пришлось, если конечно Вы их только не просто текстом описываете
2. Завести дополнительно на группу насосов одну конфигурируемую номенклату, прицепить к ней опции, правила выбора списывамого со склада насоса.
3. Создавать (на основе заказа на прлдажу) и завершать рабочий заказ на создание насоса с расширенными опциями. (Двойной ввод полностью исключен - процесс будет заключатся в запуске определенных приложений)

Какие преимущества перед Вашей самопиской:
1. Заказ на продажу и рабочий заказ интегрированы с финансами и создают проводки автоматически.
2. При желании можно будет при создании заказа на продажу при настроенных правилах, осуществляться контроль совместимости выбираемых опций, например, у насоса с большой мощностью нельзя будет выбрать несовместимый тип двигателя. (но можно и не настраивать)
3. При желание можно настроить ценообразования от выбираемых опций. (но можно и не настраивать).


Garya[quot ImpCons]
Конфигуратор используется обычно в производстве "сборка под заказ" при условии, что комплектующих на порядки меньше, чем вариантов комплектации из них готовой продукции. В частности, этот вариант удобен для конфигурирования компьютеров.

У нас другая ситуация. К "сборке под заказ" никакого отношения не имеет. Просто торговцы оборудованием не упорядочили информацию, с которой работают. И не намерены это делать. Вот и всё.

Согласен, Конфигуратор, чаще используется в самом деле для сборки на заказ, но думаю и для продаж по схеме описанной мной выше подойдет. Хотя извращенность в предлагаемом мной БП, определено тоже есть :).

Конечно если Ваши торговцы уж совсе ничего менять не хотят и не будут, то тогда любое решение не подойдет.

PS: Извиняюсь за офтоппик к главной теме. Но в свое время писал на предмет много опционного гибкого номенклатурного справочника в составе группы постановщиков/программистов самописку, все как Вы описываете - обязательные не обязательные реквизиты и т.п., кучу еще других решений использовали: показывать название/значении опции в названии номенклатуры или не показывать, при заведении проверять на дублирование значение по конкретной опции не проверять и т.п. (сейчас считаю что не оптимальное решение отписали) из-за этого не мог пройти мимо, не сказав свое Фи :)

andbary ImpConsЕсли я правильно понял, то то что у Вас было решено самопиской, вполне решается в ERP-системах (по крайней мере в одной известной мне) функционалом Конфигуратор продаж. Вы сильно не понимаете специфику данной деятельности.
Пример: Клиент заказал продавцу танк зеленого цвета. НО просто изделие клиенту нафиг не нужно, он собрался выполнять на нем определенные им лично действия в течении определенного времени. Посему: Танк + пушка + пулемет + боеприпасы + гарантийное обслуживание + обучение + доставка.


Да вроде понимаю :). Не надо изначально считать всех глупее себя. Garya вполне подробно описал в предыдущих постах ситуацию - чего то не понять довольно тяжело. Может я просто изначально не описал в подробностях что предлагаю? Исправляюсь - прочтите мой ответ Garya. Если я в нем не раскрыл решение Вашей ситуации - готов расписать еще более подробно.

andbary ImpConsИсправляюсь - прочтите мой ответ Garya. Если я в нем не раскрыл решение Вашей ситуации - готов расписать еще более подробно. Ну нету на рынке систем позволяющих продавать "уникальные изделия", а вы пытаетесь всех убедить что они существуют
Поймите! Тут и изделие и сам процесс продажи каждый раз уникален!!!
Можно стандартизировать и потерять клиентов.
P.S. И я не считаю вас глупее, просто выидно, что вы еще с этим не сталкивались и пытаетесь "засунуть" чужие процессы в имеющиеся в вашей системе рамки...

Ну ну, с такой аргументацией как Ваша не поспоришь - раз Вы говорите нету - значит нету :)

Я как то не задумывался о продвижении "моей системы" - тем более Garya :)), прочитал интересную для ситуацию и прокрутил вариант как бы я попытался бы ее решить, - не факт что это ляжет на компанию Garya, для этого нужно делать анализ никак не на форуме, да и с учет конфликт менеджмента, который так хорошо описал Garya.

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

А общие слова об уникальности изделия и уникальности процессов приберегите для тех наших топов, которые так же как и Вы к тому же еще уверенны и в уникальности всех процессов протекающих в их бизнесе, пустой спор - Ваше мнение против моего.

А насчет засовывания "чужих процесов" в рамки "моей системы", - есть проблема и есть предложение как ее решить, - почему бы не обсудить? Что Вам в этом не нравится? На чем работаю - то и знаю, если считаю что "чужой процесс" засунется в "мою систему" лучше чем решено самопиской - описываю решение. Не было бы мыслей как реализовать - сидел бы и спокойно бы читал трейд.

Garya ImpConsЧто-то я не понял... Вы хотите сказать, что Вам известна ERP-система, в конфигураторе которой можно создать насосный агрегат из "мощности" и "оборотов", вообще забыв о комплектующих и не вводя в нее такие понятия как "двигатель" и "насосная часть"?

Да совершено верно - в справочнике номенклатуры создается конфигурируемая номенклатура например: "насос конфигурируемый" - с сегментами (опциями): мощность, обороты, и добавим для Andbary еще цвет. Заводятся списки значений для этих опций, например мощность: 300W, 1KW, 50KW и т.п.; обороты: 5000, 7000, 20000 и т.п.; цвет: зеленый, красный, синий и т.п.

1) Комплектующих: двигатель и насосная часть в спавочнике номенклатур не заводим

2) В справочнике заводим только к примеру насос № 212, насос №213, насос №214 и т.п. с теми названия которыми пользуются отдел закупок/производства этих насосов и бухгалтерия.

3) Во время создания заказа на продажу (скажем ЗаказПродажи №3) сейлз указывает: покупатель Иванов хочет "насос конфигурируемый" с опциями: мощность - 1KW; обороты - 7000; цвет - зеленый. В зависимости от того настроены ли правила выбора спецификации изделия или нет, либо автоматически, либо вручную выбирается, что для сборки данного насоса требуется, например, насос №213

4) Создается рабочий заказ (скажем РабочийЗаказ №1) на сборку "насоса конфигурированного" для покупателя Иванов с выбранными опциями (мощность - 1KW; обороты - 7000; цвет - зеленый) и прикрепленым листом комплектации с насосом №213 . Создается он на основе ЗаказаПродажи №3.

5) Закрывается РабочийЗаказ №1 - при закрытии заказа списывается со склада насос №213 и появляется "насос конфигурированного" с выбранными опциями (мощность - 1KW; обороты - 7000; цвет - зеленый)

6) "насос конфигурированный" с выбранными опциями (мощность - 1KW; обороты - 7000; цвет - зеленый) отгружается покупателю Иванову по ЗаказуПродажи №3


Созданные системой бухгалтерские пакеты, которые затем можно разнести в Главную книгу:

пункт 5: при закрытие рабочего заказа:

Дт Запасы (по цене насоса №213)
KT Себестоимость готовой продукции (по цене насоса №213)

пункт 6: при отгрузке покупателю:

a) Дт Счета к получению (по цене "насоса конфигурированного")
Кт Доход от реализации (по цене "насоса конфигурированного")
б) Дт Себестоимость готовой продукции (по цене насоса №213)
Кт Себестоимость реализованной продукции (по цене насоса №213)

Garya Если не секрет, что это за ERP-система?

Не секрет - это можно реализовать в Oracle JD Edwards Enterprice One, модулем Конфигуратор Продаж (Sales Configurator).

andbaryПодход меня сильно огорчает...
Сами мы это никогда не видели, но вот в нашей системе это с легкостью решается теоретически.
А если не с легкостью, то у вас "бардак" и плохие сотрудники саботируют наше чудо решение...
Одно и тоже, и никто ничему не учится


Для этого существует этап моделирования системы, на котором Проджект менеджер со стороны Заказчика обязан потребовать от Исполнителя настройки и демонстрации в прототипе(это преднастроенный пример, охватывающий основные требования Заказчика) наиболее важных и критичных БП .

Зачем разрешать Исполнителю настраивать систему (этап конфигурирования) и запускать в промышленую эксплуатацию, ну и соответственно за все эти работы платить, если он, Исполнитель, не продемонстрировал как это работает на этапе Моделирования.

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

Меня огорчат другое - что раз Вы не знаете таких систем, то Вы и не собираетесь слушать пути решений, предлагаемых другими. Конечно проще сказать раз я не знаю систем решающих эту задачу, а сам я над этой задачей думал больше года - то значит и систем таких нет задачу решат, да и слышать я про них не хочу.

Garya ImpCons1) Комплектующих: двигатель и насосная часть в спавочнике номенклатур не заводимВ ERP-системе чаще всего используется справочник номенклатуры товара/продукции и справочник комплектующих одновременно (обычно в виде BOM). Я полагал, что как минимум требуется хотя бы один из них. В нашем случае не было ни того, ни другого. Из этого ответа я понял, что справочник комплектующих не заводится. Но как быть с собственно номенклатурой товара/продукции? Смотрим дальше...



В BOM собственно заведется насос №213, как я писал ранее:
3) Во время создания заказа на продажу (скажем ЗаказПродажи №3) сейлз указывает: покупатель Иванов хочет "насос конфигурируемый" с опциями: мощность - 1KW; обороты - 7000; цвет - зеленый. В зависимости от того настроены ли правила выбора спецификации изделия (это и есть BOM) или нет, либо автоматически, либо вручную выбирается, что для сборки данного насоса требуется, например, насос №213

Garya ImpCons
2) В справочнике заводим только к примеру насос № 212, насос №213, насос №214 и т.п. с теми названия которыми пользуются отдел закупок/производства этих насосов и бухгалтерия.Ага! Так значит какой-то справочник всё-таки есть! И это справочник номенклатуры товара/продукции. Позиции которого привязываются к конкретному клиентскому заказу. В нашем же случае привязка происходила уже в бухгалтерии методом "совместного разбора полетов". В документах на отгрузку фигурирует никакая не номенклатура, а именно параметры клиентского заказа . То есть "насос зеленый 3квт 3000 об/мин" - именно так, без указания конкретной модели, если в заказе конкретная модель не указана. Собственно в самописке, автоматизирующей процесс управления продажами, никаких справочников кроме перечней часто используемых параметров клиентского заказа, нет. Нет никаких "насосов №212, 213 и 214". Они возникают только в бухгалтерской программе, где номенклатурный справочник товара/готовой продукции присутствует .


Да совершенно верно насос № 212, насос №213, насос №214 - это как раз те номенклатуры которыми пользуются у Вас бухгалтера в своей программе - но так как я в JDE рассматриваю интегрированное решение, то и пишу что они должны быть заведены в справочник номенклатуры.
В документах на отгрузку в предлагаемом мной решениии так же будет указана никак не насос №213, а имено насос конфтгурируемый, зеленый, 3КВт, 3000 об/мин, т.к. сейлз вбивал в Заказ продажи, на основании которого производится отгрузка, именно насос конфигурируемый, то что потом рабочим заказом спишется (через ВОМ а затем список комплектации) насос №213 покупатель в своих документах нигде не увидет.

Garya
Пытаясь перевести всю эту ситуацию в термины IT, можно представить, что "параметры клиентского заказа" - это совокупность условий фильтрации номенклатуры, по которым теоретически должны быть отобраны соответствующие им записи массива номенклатуры, которых может быть а) пустое множество б) одна запись в) множество записей. Причем, отбор должен происходить с ранжированием этих записей по приоритетам 1) имеются в наличии на складе в свободном остатке, 2) имеются на складе, но зарезервированы под другие клиентские заказы 3) в наличии не имеются, но уже заказаны поставщику, 4) требуют оформления нового заказа поставщику, цена не требует повторной проработки (это значит, что на протяжении двух последних месяцев подобный заказ поставщику уже производился) и 5) требуют оформления нового заказа поставщику, цена заказа требует повторной проработки.

Поскольку в самописке справочник номенклатуры как таковой отсутствует, то никакого массива, на который накладываются условия фильтрации, просто нет. Условие фильтрации - есть, а то, на что оно накладывается - нет! :)

Теперь уместно вспомнить о том, чем справочник отличается от "регистра" (опа, выскочил 1С-овский термин, прошу пардона). Справочник, словарь, перечень - это условно-постоянная информация. А регистр - условно-переменная. Регистр фиксирует потоковые операции, а справочники этот поток параметризируют, раскладывают по полочкам, расслаивают по аналитическим разрезам.

Так вот, термины, которыми оперируют наши поставщики, также не являются структурой типа "справочник". Скорее это атрибут движения, вроде номера или даты документа. В той самописке, о которой я рассказываю, сделан просто умопомрачительный "финт ушами"... :) Когда оформляется заказ поставщику, он тоже оформляется в терминологии "фильтра", а не "номенклатуры". Кажое "условие фильтрации" - это атрибут движения. Фактическое движение фактической номенклатуры происходит только на складе, но отражение оно находит только в головах кладовщиков, а не в учетной системе. Каждое движение в системе выглядит туманно - этакое "облако в штанах", но оно отслеживается по фазам. Примерно так: клиентом заказано зеленых насосов с мощностью 3квт 5 шт, поставщику заказано зеленых насосов с мощностью 3 квт 8 шт, из них 5 шт - под клиентский заказ, 3 шт - в запасы на склад под будущие заказы.

Когда сэйлзы производят замену одних "облаков в штанах" на другие, они накладывают фильтры на массив ранее накопленных фильтров. И накладываемые же имим фильтры в свою очередь становятся частью массива фильтров. Вот такая рекурентная фильтрация фильтрами самих себя... :)

Полагаю, что ни в каком JDE ничего подобного таки сделать не получится. Я прав? :)

Может не совсем четко уловил суть :), но попробую ответить:
- Справочник номенклатуры для конфигурируемого изделия состоит из таблиц в которых хранятся реквизиты для обычной номенклатуры + таблицы в которой содержатся значения сегментов для конфигурируемых изделий, т.е. конечно если Вы захотите завести новый параметр у конфигурируемог товара придется добавить новый сегмент и добавить все допустимые его значения.

- Насчет выбора какой насос из справочника используемого бухгалтерией нужно отгрузить покупателю - раскажу как работает Правила включения в BOM, можете настроить в системе условия: Если выбирается сегмент Мощность = 3KBт и сегмент Обороты = 7000, то в BOM чтобы попадал насос №212; а при выборе Мощность = 3KBт и сегмент Обороты = 5000, то в BOM чтобы попадал насос №215. Насчет приоритетов (присутствие на складе/в заказе думаю да ничего такого нет)

- Если конечно Вам требуется дальше оперировать номенклатурой, определенной как конфигурируемая для заказов на закупку на основании заказов на продажу, тогда да, согласен Конфигуратор тут уже не подходит. С самого начала не было этого озвучено - из-за этого предлагал решение следующей локальной задачи: В единной системе сейлзов/бухгалтерии оформление сейлзами заказов на продажу с расширенным описанием номенклатуры, на основе которых создается рабочий заказ списывающий по финансам номенклатуру уже оприходованную на склад в рабочих названиях закупщиков/бухгалтерии. Если же сложная номенклатура нужна кроме сейлзов еще и закупщикам, а потом еще окажется что на основании ее еще нужно и делать планирование закупок на основании прогнозов, то уж конечно Конфигуратор продаж в этом случае не подойдет. Если бы Вы сами производили эти насосы - то думаю Конфинуратор продаж был бы как раз для Вас.

andbary ImpConsOracle JD Edwards Enterprice One, модулем Конфигуратор Продаж (Sales Configurator). Еще раз: Вы накладываете "чужой опыт" (реализованный в JD Edwards) на иной бизнес, с иными требованиями.
Да, один раз настроив схему она у вас будет работать, Но на следующем заказе схему придется перестраивать, поскольку каждый заказ (это хорошо видно по фильтрам Garya) представляет из себя объект имеющий свою совокупность свойств и признаков. Для клиента использование вашей схемы приведет к потере гибкости при работе и данное требование критично (каждый раз создавать новый конфигуратор на каждый заказ возможно, но трудоемко).


Зачем на каждый заказ свой конфигуратор?

Что такое насос конфигурируемый? Это одна запись в справочнике номенклатуры с признаком что она конфигурированная. Затем в таблицах с сегментами : мощность, обороты, цвет. Продумайте хорошо какие еще бывают параметры и все их заложите, в новом заказе появился новый параметр например Тип топлива - добавьте к насосу конфигурируемому еще один сегмент Тип топлива: Бензин, электричество и в каждом новом заказе на продажу сейлз кроме мощности,оборотов и цвета сможет вводить и Тип топлива.
Для Вашего танка заведите еще одну запись танк конфигурируемый в справочнике номенклатур и сегменты: цвет, наличие пулемета, наличие пушки, наличие боеприпасов, определите правила попадания в BOM, либо танка со всеми примочками, либо танка без оружия, пулемета, пушки, боеприпасов и т.п.
Сколько у Вас будет изделий со сложными опциями - столько и записей в справочнике номенклатур.

Причем тут один заказ - один конфигуратор?

andbaryДа, можно использовать вашу схему по другому, к примеру создать самописку (в моем случае использовались шаблоны Excel) вместо вашего конфигуратора и заносить в систему информацию только на этапе подтверждения заказа (когда изделие уже создано и все его свойства известны и утверждены) и достичь необходимой гибкости .
В принципе все ( все ) решаемо, вопрос в цене этого решения (ресурсах на его решение).
В моем случае было достаточно создать порядка 8 "конфигураторов" изделия и я бы закрыл данную проблемы, вот только для конкретного бизнеса данная проблема с большей легкостью (читай эффективностью) решалась шаблонами Excel (которые перестраиваются в зависимости от поставщика (где то 1-2 раза в год) специально обученным человеком).


Короче мы явно понимаем под Конфигуратором разные вещи. Что такое 8 конфигураторов ??? - Ничего не пойму. Конфигуратор продаж - это модуль который объединяет справочник конфигурируемых изделий, создание заказов на продажу конфигурируемого изделия, создание рабочих заказов конфигурируемого изделия, отгрузку конфигурируемого изделия, проводку в финансы продажи и рабочего заказа. Прочтите описание справочника конфигурируемого изделия в этом посте в моем ответе на Ваше первое утверждение.

andbary[quot ImpCons]
У меня есть возможность привязывать к изделию (объекту) иных документов (расходов) в течении времени существования заказа и получить спустя некоторое время калькуляцию всех расходов.
Думаю и у вас есть такая возможность, но опять вопрос в цене решения (в том числе и с учетом описанных в этом топике проблем с "чужим опытом").

Можно подумать Ваша разработка не является для Garya чужим опытом? И проблем внедрения Вашей разработки в условиях работы предприятия Garya не было бы никаких?
Поймите я не навязываю, а тем более не продаю никому JDE. Я расказываю что там есть и как возможно было бы реализовать проблему там.

andbary[quot ImpCons]
P.S. Закупка изделия на основании шаблона решается просто, как создать закупку на основании конфигуратора головная боль...


Насчет закупки я уже написал Garya - да, не предназначен Конфигуратор продаж для закупок.

Модератор: отредактировано

andbary

За тон приношу извинения!

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

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

А что Вы предлагаете спорить только посредством филосовских расуждений? - Ну уж не могу - я в этом не силен. Поэтому и прошу дискуссировать со мной по тематике, а не о философии предмета.

Модератор: цитата вырезана

andbaryЯ в самом начале написал следующее:
1. Абсолютное большинство таких систем разработаны в прошлом веке и содержат структуры разработанные еще раньше, на принципах которые безнадежно устарели. Разработка и поддержка таких структур стоит очень и очень дорого, что приводит к существенному увеличению стоимости эксплуатации.
2. На практике, не весь «мировой опыт» стоит использовать. Жизнь тоже не стоит на месте и кроме новых операций в системах имеется множество устаревших и чуждых (не применимых в данных условиях). Их наличие опять же приводит к существенным затратам (производитель их поддерживает, так как они используются у других клиентов) а разработчик должен помнить что в поле ХА всегда должно быть определенное значение ХУ.
3. Огромный функционал строился на протяжении многих лет и различными командами разработчиков (различной квалификации) с использованием различных средств и методов. Да конечно все весьма сурово тестировалось, но к чему приведет значение ХИ в поле ХА в новой ситуации известно одному Богу.
4. Оптимальный уровень денормализации зависит от множества условий, а системы считаются чуть ли не «коробочными». В условиях реальной эксплуатации это приводит к огромным сложностям при исправлении ошибок. «Корректирующие проводки» не добавляют порядка в данных.
5. «Что русскому по кайфу, то немцу смерть». Верно ли обратное, вопрос философский, но все (все) системы обладают тьмой процедур требующих пунктуального соблюдения кучи правил. Западные компании обладают развитым бюрократическим аппаратом и для них это уже «в крови». Стоимость ввода такого аппарата не включается в стоимость ПО, но без него трудно иметь чистые (с небольшим количеством ошибок) данные. К тому же содержание бюрократии стоит денег и уменьшает гибкость (читай конкурентность) компаний.

Я не знаю JDE (на уровне неспосредственной работы), но данный продукт обладает или нет указанными выше свойствами???

Ну Вы как заметили, я на этот Ваш пост и не отвечал, т.к. считаю что Вас не переубедить в обратном, да и зачем мне это?

JDE я назвал только как ответ на вопрос Garya в какой ERP можно завести опции(сегменты) номенклатуры не заводя их как комплектующие.

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

andbary ImpConsЗачем на каждый заказ свой конфигуратор?
Сколько у Вас будет изделий со сложными опциями - столько и записей в справочнике номенклатур. Наверно правильней было бы с моей стороны написать конфигурация заказа, вот только у каждой конфигурации свои справочники опций, которые не совместимы и которые постоянно изменяются.

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

andbary[quot ImpCons] 1. Я в курсе как работает калькуляция в 4х активно используемых системах, во всех случаях она в общем весьма стандартна, и я уверен, что и в JDE достаточно стандартный механизм. В данном случае себестоимость это себ. изделия+расходные материалы в комплекте+доставка+сервис (все перечисленное идет по различным документам (часть обычно без отражения в бухгалтерских проводках) и в течении достаточно большого периода времени). Расчет нужен для калькуляции конечных затрат по заказу и аналитики (тупой пример, продали вроде дорого, но из за дурного клиента были резкие затраты на сервис и комплектующие).

Но я к сожалению не знаю что это за 4 активно используемые системы и как там реализуется калькуляция и похожа ли они на реализацию в JDE. Может настройка калькуляции в JDE похоже как раз на Вашу :-). Поэтому и предлагаю о чем не знаем не писать, а писать только о том что знаем - иначе голословные утверждения.

andbary
2. Я могу точно сказать, что жесткая реализация одного механизма в рамках одной задачи, всегда (при грамотном проектировании) лучше стандартного (который используется на все случаи жизни)

Граммотное проектирование - сложное понятие. Не всегда у проектировщика самописки больше опыта чем у разработчиков ERP, даже если как Вы пишите реализовывали это решение 20 лет назад. Почему Вы считаете что любой проектировщик спроектирует жесткую реализацию механизма в рамках одной задачи лучше чем реализовывали подобную специфическую проблему разработчики ERP на основании запросов от клиентов и внедренцов этой ERP? Все таки проектировщику самописки надо обладать хотя бы таким же уровнем компетенции и знаниями реализации данной проблемы что и постановщикам по написанию ERP-системы, а там уж люди с опытом и отнюдь не в программировании а в функциональных областях сидят, причем в узкофункциональных областях. Я в свое время как проектировщик (в группах до 10 человек) пректировал КИС под логистику, производство и финансы, под конкретное предприятие но не могу похвастаться что спроектировал хотя бы один модуль, лучше чем скажем это релизовано в JDE. Может сейчас позанимавшись несколько лет ERP отдельные куски смогу спроектировать в чем то лучше, но для реализации потребуются не маленькие ресурсы. Конечно счас услышу - значит плохой был проектировщик и т.п., но скажите, а много народа занимающихся самописками, имеют хороший функциональный опыт именно в той узкоспециальной задаче которую нужно именно в определенный момент решить?

andbary
3. Просто сравните вашу реализацию с шитами екселя, и ответьте на вопрос, что дешевле и функциональней. С учетом того, что это не поточное производство.

Не стану сравнивать - потому как, нормально сравнить можно только детально разобравшись, как Вы это сделали в Exel. А нам с Вами это нужно?

andbary
4. Опыт... Для меня вы ответили и на основной вопрос темы.
Поверьте, я не говорю, что JDE плохая система (вообще какая то ERP система), тема именно в путях развития, как и на основании чего двигаться вперед.
Дискуссию по поводу путей развития считаю безполезной - т.к. каждый для себя путь развития определил - а переубеждать кого то в ошибочности его решения считаю бесполезным и неблагодарным занятием.