Garya авторПереходные" процессы есть и в дискретном производстве, дали "отмашку" на приостановку производства данной продукции, а продукция продолжает выпускаться пока не будут выработаны все полуфабрикаты. А в непрерывном производстве можно мгновенно остановить выпуск, неизрасходованный полуфабрикат будет сливаться в резервные емкости или через обратные магистрали "зацикливаться" на каких-то предпоследних стадиях
Да, но в дискретном производстве эти процессы носят дискретный характер.:)
Garya ASUНепрерывное производство - это, как правило, массовое производство, а для массового производства характерна узкая специализация (выпуск ограниченной номенклатуры в больших объемах)Как правило - да. Только и дискретное производство тоже может быть массовым и узкоспециализированным. Это не критерий их разделенияДа, есть поточное дискретное производство. Я не вводил поточность, как критерий деления, моя задача была несколько проще: показать различия в функциях технологов в поточном/массовом (непрерывном и дискретном) производствах.
Garya ASUА в непрерывном производстве можно мгновенно остановить выпуск, неизрасходованный полуфабрикат будет сливаться в резервные емкости или через обратные магистрали "зацикливаться" на каких-то предпоследних стадиях.
....
Непрерывное производство - это, как правило, массовое производство...
....
Технология массового производства меняется очень редко и связана с существенными затратами на модификацию
2 ASU. Забавный ход мысли - от пода к антиподу. :) В итоге я так и не понял Вашу позицию в этом вопросе...Моя позиция состоит в том, что при правильном понимании смысла технологической операции, технологического маршрута, технологический процесса и т.д., можно получить реализацию производственной подсистемы одинаково пригодной для любого вида производства. Существо этих понятий не меняется от непрерывности или дискретности производства.
GaryaИ еще. Один мой знакомый работает главбухом на химкомбинате по производству всяких моющих средств (шампуней, средств для мытья посуды и т.д. и т.п.). Как форму и размер упаковки они меняют чуть ли не каждый день. Ну, и новые продукты выпускают регулярно. И тип производства у них - процессный (имхо, разумеется). Как-то плохо они вписываются в набор Ваших утверждений...Плохо? Тогда действительно плохо... :)
На самом деле речь видимо идет об очень близких видах продукции, скорее всего, речь идет об одном классе продукции в нескольких модификациях (мне трудно поверить, что данное предприятие строит новые технологические линии под каждый новый вид продукции). Возможна и другая ситуация, которая больше характерна для производств подобных производству полиэтиленовой пленки. Здесь начальная стадия (собственно производство полиэтилена) непрерывна, а последующие стадии (например, производство полиэтиленовой тары) дискретно. Такое решение позволяет выпускать широкий спектр продукции, но... это ничуть не противоречит сказанному мной в предыдущем сообщении.
GaryaПо поводу же того, что тип производства - массовый - мелкими партиями, под заказ - под прогноз существенно влияет как на процесс автоматизации, так и на селесообразность проведения самой автоматизации, я согласенДа, но я этого не утверждал :) Мало того, у меня противоположное мнение.

gz ASU ... С точки зрения систем автоматизации управления эти различия не являются значимыми
Это верно, если автоматизировать что-то на верхнем уровнеНет. Определите понятие Технологической Операции (ТО), дайте возможность технологам создавать операции, выстраивать из них Технологические Процессы и... забудьте про различия. Различие может проявиться на уровне планирования и (отчасти) диспетчирования производства, но оно (различие) сводимо даже не к методикам, а отдельным расчетным процедурам, используемым в методиках.
gzА если спускаться постепенно вниз, то в любом производстве (независимо от того, дискретное или непрерывное) находятся свои особенностиДа, безусловно. Вопрос только в том, кто должен реализовывать эти особенности: разработчик или пользователь?
gzПример. Автоматизация складского учета. Осуществляется приемка сырья. К нему приложен сертификат качества - процентное содержание ведущих элементов. Надо это свалить в нужную кучу и перерасчитать средневзвешенное содержание ведущих элементовЭта задача не относится к складскому учету, поскольку решается ЦЗЛ (Центральной Заводской Лабораторией) или другим подразделением, отвечающим за входящий контроль качества. Складу совершенно безразлично, что в нем хранят.
gzЗатем из куч отгружают в производство. Осталась маленькая кучка - ее перегребают в другую - снова пересчет составляющихИ это задача не относится к складу, за нее отвечает "входной контроль качества" производственного подразделения (цеха) или та же ЦЗЛ.
gzОпять же учет физических тонн и базовых, а для кокса - учет в сухом весе. И по средневзвешенным ценам. А цена задана для базового веса. Не думаю, что можно найти такую готовую системуИ это не относится к складу, поскольку задача определения цен заготовления, установка внутренних цен, нормативов запаса и т.п. является задачей экономистов. Склад (если это склад по сути, а не по названию) остается складом на любом предприятии. Функций у склада может быть больше или меньше, но это только складские функции, вытекающие из сути склада. Например, где-то надо учитывать не только поток материалов, но и тару, где-то надо проводить комплектацию, где-то надо обслуживать материалы во время хранения и т.д. Но склад не должен быть "отростком" бухгалтерии или сбыта/снабжения, склад не должен решать экономические задачи (но экономисты могут/должны пользоваться информацией формируемой складом). Не смешивайте понятия, и это серьезно облегчит жизнь и разработчикам, и пользователям.

Garya ASUДа, но я этого не утверждал :) Мало того, у меня противоположное мнениеВидимо, я не совсем правильно понял. Если у Вас противоположное мнение, значит оно противоположно и мнению Питеркина (читали его книгу?)Нет, не читал.
GaryaЯ не хочу творить себе кумиров, меня заинтересовала Ваша позиция. Можете ее обосновать?Да, конечно. Собственно, я ее уже обосновал (см. предыдущее сообщение о ТО и ТП).
Garya ASUРазличие может проявиться на уровне планирования и (отчасти) диспетчирования производства , но оно (различие) сводимо даже не к методикам, а отдельным расчетным процедурам, используемым в методиках
ER P - Enterprice Resourse Planning . Всего лишь, только... :)Спасибо, я знаю. Но только должен заметить, что нормального планирования существующие ERP-системы не имеют, к сожалению...
GaryaМожете объяснить, как методика MRP прикручивается к планированию потребности материалов в процессном производстве, например, на предприятии, занимающемся нефтепереработкой и получающей от поставщика сырую нефть по нефтепроводу?MRP (material requirement planning), строго говоря, не планирует, а позволяет пользователю создать план (просто облегчает работу по планированию). MRP-II, в общем случае, тоже "планирует" весьма приближенно. Если мы говорим о нормальном планировании производства, то логика процесса такова: производство получает информацию ЧТО нужно производить от отдела сбыта. Информацию о том СКОЛЬКО производить той или иной продукции оно может также получить от сбыта, но может и определить самостоятельно (например, если рынок сбыта "неограничен", то ответ на вопрос СКОЛЬКО дается по расчету производительности производственных мощностей). Когда известно ЧТО, СКОЛЬКО и к какому СРОКУ нужно произвести, то дальше идет расчет в потребных материалах (BOM - bill of materials) и загрузка производственных мощностей. Расчет производится на основе технологических норм потребления (основных и вспомогательных) материалов на каждой технологической операции. Полученный перечень материалов передается в снабжение, где он агрегируется, фильтруется складскими запасами и "привязывается" к поставщикам. В предложенном Вами случае, планирование может быть "от снабжения", если "узким местом" является именно снабжение, а не сбыт и не производительность производственных мощностей. В этом случае, задается СКОЛЬКО сырой нефти поставит поставщик в плановый период, сбыт (с привлечением экономистов) говорит, что выгоднее производить, а производство отвечает на вопрос сколько данной продукции можно произвести из такого объема сырья.
(Это приближенное и неполное описание, но суть, надеюсь, передает).
GaryaНасколько я себе понимаю, MRP - это не отдельная расчетная процедура, а именно методикаЕсли противопоставлять ее JIT, то можно говорить о методике, а так... процедура :)
GaryaSIC - это тоже методика , которая к предложенному примеру тоже никак не лепится, если стратегия управления строится на информации не из прошлого, а из будущего. И MRP, и SIC могут быть задействованы в расчете потребности материалов. Но это разные методики, хотя на пркатике стараются применять их комбинацию, а не одну из нихНа практике... чего только не увидишь... :)
Garya ASU gzПример. Автоматизация складского учета. Осуществляется приемка сырья. К нему приложен сертификат качества - процентное содержание ведущих элементов. Надо это свалить в нужную кучу и перерасчитать средневзвешенное содержание ведущих элементов Эта задача не относится к складскому учету, поскольку решается ЦЗЛ (Центральной Заводской Лабораторией) или другим подразделением, отвечающим за входящий контроль качества . Складу совершенно безразлично, что в нем хранятСтранно, что поиск ответа на вопрос "СКОЛЬКО чего на складе свалено в кучу?"не относится к складскому учету... Можно узнать, на каком именно предприятии поиском ответа на этот вопрос занимается ЦЗЛ?Чего и сколько свалено можно узнать из анализа приходно/расходных документов или проверкой склада (инвентаризацией). Но ответ на то, что же свалено в конкретную кучу и что получилось в результате смешения, может дать только ЦЗЛ (или другое подразделение с аналогичными функциями).
GaryaЗЫ. Если у предприятия есть все основания доверять прилагаемому на сырье сертификату, то вопрос входного контроля качества вообще может не стоятьСертификат - это бумажка... Ей можно доверять, но проверять никогда не лишне (могут быть хищения при транспортировке, нарушение упаковки и пр.). Конечно, можно также взять сертификат и у транспортной компании и у каждого грузчика... Но за некачественный продукт спросят с нас, а не с наших поставщиков и субподрядчиков.
Garya автор gzОпять же учет физических тонн и базовых, а для кокса - учет в сухом весе. И по средневзвешенным ценам. А цена задана для базового веса. Не думаю, что можно найти такую готовую системуИ это не относится к складу, поскольку задача определения цен заготовления, установка внутренних цен, нормативов запаса и т.п. является задачей экономистов
Зато это относится вообще к задаче управления предприятиемА что задачи управления предприятия решаются складом? Поймите, что я отвечал на вполне конкретный вопрос:
gzПример. Автоматизация складского учета. Осуществляется приемка сырья

GaryaУУУУ.... Скатываемся на флейм... Да, пожалуй... надо прекращать.
Garya ASU...должен заметить, что нормального планирования существующие ERP-системы не имеют, к сожалению...
....
MRP (material requirement planning), строго говоря, не планирует, а позволяет пользователю создать план (просто облегчает работу по планированию). MRP-II, в общем случае, тоже "планирует" весьма приближенно.
Ну, если уж так рассуждать, то компьютеры тоже "не работают". А работают пользователи ЗА КОМПЬЮТЕРАМИ. А компьютеры только облегчают их работу...
Вам не нравится MRP II? Можете сказать, что же вам нравится?Тем, что это ничем не обоснованный перечень функций, собранных случайным образом. Чтобы в MRP-II было возможно нормальное планирование, необходимо, чтобы там присутствовало понятие производства, а там его... нет.
Garya ASUДа, но я этого не утверждал :) Мало того, у меня противоположное мнение.
....
...например, если рынок сбыта "неограничен", то ответ на вопрос СКОЛЬКО дается по расчету производительности производственных мощностей...
Что-то я уже совсем потерял нить ваших рассуждений... То Вы против того, что тип производства влияет на процесс автоматизации, то сами приводите пример разных методов планирования в зависимости от типа производства и условий в которых оно работаетДело, видимо, в том, что понятие автоматизации мы с Вами трактуем различно. Для меня автоматизация - это не просто "коробочка" с набором CD, это процесс, проходящий различно на разных уровнях управления. Вот, например, Вы можете согласиться, что понятия ТО и ТП (тех. операции и тех. процесса) можно абстрагировать от конкретного производства (или, другими словами, описывать единообразно в любом производстве)? Но если это так, то можно предположить, что и диспетчеризация производства может быть абстрагирована от реального производства. Рассуждая далее, легко придти к выводу, что и данные для расчетов (нормативов, планов, показателей) будут одними и теми же. То есть, мы даем технологу инструмент для описания любых тех. процессов по выпуску любой продукции. Мы даем администрации инструмент для диспетчирования любого производства. Это автоматизация? Теперь мы даем экономисту инструмент для составления методик расчета любых показателей (считаем, что исходные данные в системе уже есть). Это автоматизация? Далее мы даем плановику инструмент для составления любых планов на основе любой из методик... Поэтому мне, как разработчику, совершенно безразлично о каком производстве идет речь, по каким методикам производят расчеты и планируют. Я не считаю себя умнее своих пользователей, их консультантов и преподавателей ВУЗов, у которых они учились.
Garya ASUВ предложенном Вами случае, планирование может быть "от снабжения", если "узким местом" является именно снабжение, а не сбыт и не производительность производственных мощностей
Если речь зашла о наличии явных узких мест, то, видимо, имеет смысл применить концепции теории ограничений Голдратта (TOC). Однако, сейчас речь не о том. Давайте уточним. Тип производства - под заказ (ранее Вы, вроде бы, утверждали, что это не существенно). Узкого места в снабжении нет. На трубе имеется кран, с помощью которого можно регулировать подачу сырой нефти. Если его просто открыть на всю катушку, то емкости завода в итоге переполнятся (это для ясности). А завод должен будет заплатить круглую сумму поставщику нефти, не имея достаточной выручки. Управлять задвижкой на трубе с помощью MRP в данном случае НЕ ПОЛУЧИТСЯ (если Вы с эти согласны, то мусолить пример дальше нет смысла), хотя MRP рационально применять в дискретных производствах при работе производства именно под заказХм... Если у меня есть заказ, я открываю кран... создаю и продаю продукцию. С такой задачей MRP справится? На всякий случай кратко повторю рассуждения (заказ - технология производства - потребности в материалах - ... задвижка).
Garya ASU GaryaНасколько я себе понимаю, MRP - это не отдельная расчетная процедура, а именно методика
Если противопоставлять ее JIT, то можно говорить о методике, а так... процедура :)
Категорически не согласен. Не думаю, что APICS стал бы рассусоливать с отдельной процедурой, возводя ее в ранг едва ли не стандартаВы так серьезно относитесь к "творениям" APICS? Ох... напрасно.
GaryaПо поводу JIT не согласен тоже. JIT - это НЕ методика. Это философия управленияЗдесь мы действительно скатимся на flame...
Garya ASUА что задачи управления предприятия решаются складом? Поймите, что я отвечал на вполне конкретный вопрос:
gzПример. Автоматизация складского учета. Осуществляется приемка сырья
Ну и где тут вопрос? Это даже не утверждениеКак пожелаете. Я для себя усмотрел вопрос :)
Garya gzв любом производстве (независимо от того, дискретное или непрерывное) находятся свои особенности
Вы с ним не согласны? Если согласны, то вообще о чем мы тут толчем воду?Я уже сказал, что несогласен.

Garya ASUДело, видимо, в том, что понятие автоматизации мы с Вами трактуем различно. Для меня автоматизация - это не просто "коробочка" с набором CD, это процесс, проходящий различно на разных уровнях управления. Вот, например, Вы можете согласиться, что понятия ТО и ТП (тех. операции и тех. процесса) можно абстрагировать от конкретного производства (или, другими словами, описывать единообразно в любом производстве)? Но если это так, то можно предположить, что и диспетчеризация производства может быть абстрагирована от реального производства. Рассуждая далее, легко придти к выводу, что и данные для расчетов (нормативов, планов, показателей) будут одними и теми же. То есть, мы даем технологу инструмент для описания любых тех. процессов по выпуску любой продукции. Мы даем администрации инструмент для диспетчирования любого производства. Это автоматизация? Теперь мы даем экономисту инструмент для составления методик расчета любых показателей (считаем, что исходные данные в системе уже есть). Это автоматизация? Далее мы даем плановику инструмент для составления любых планов на основе любой из методик... Поэтому мне, как разработчику, совершенно безразлично о каком производстве идет речь, по каким методикам производят расчеты и планируют. Я не считаю себя умнее своих пользователей, их консультантов и преподавателей ВУЗов, у которых они учились
Видимо, я торможу. Ниччччего не понимаю... :) CAD/CAM-системы разве не абстрагированы от производства? Когда конструкторская и технологическая документация готовится в CAD/CAM, составляются спецификации и технологический маршрут, и все это импортируется в BOM ERP-системы...”Это” не должно импортироваться, это должно быть частью системы. ТО и ТП – не прихоть технолога, это описание объекта управления. Понимаете? Если в системе управления нет объекта управления, то управления вообще нет (для чего же нужен субъект управления, не имеющий объекта управления). Но “субъект-объект” - только одна (структурная) плоскость рассмотрения управления. Точно также можно/нужно рассматривать методологическую плоскость. Методы управления должны меняться при изменении внешней или внутренней среды... И если мы даем пользователям (управленцам) возможность самостоятельно делать описание субъекта управления, то мы даем им возможность выбирать (формулировать) и метод управления. Но при этом мы объясняем принципы выбора того или иного метода. В общем, это длинная история...
GaryaКогда составляется стратегический план, который уточняется на разных горизонтах планирования, к планированию подключены маркетинговые службы... Когда исходя из полученных прогнозных планов и имеющейся фактической информации по фактическим заказам, а также с учетом изменения фактической ситуации по поставкам, формируется и корректируется оперативный производственный план, при этом оптимизируется загрузка производственных мощностей... Причем, не просто оптимизируется, а в соответствии с выбранной стратегией - "преследования" (минимальный уровень запасов готовой продукции, но загрузка мощностей в разные периоды времени может сильно варьироваться), "сглаживания" (загрузка мощностей на одном уровне, но в некоторые периоды времени уровень готовой продукции очень высок, потому что склад готовой продукции выполняет роль демпфера при колебаниях спроса) и "комбинированная" (урседненная между двумя предыдущими)... Разве это - "коробочка с набором CD"? Разве это не "процесс, проходящий на разных уровнях управления"? Разве это все как-то противоречит MRP II? Где именно, в каком месте?Я уже говорил Вам, что MRP-II это набор просто функций, но управление несводимо к набору функций, даже один и тот же субъект управления в разных условиях должен иметь разный функциональный набор (передача функций другому субъекту, делегирование функций в “над” и “под” уровни и пр.).
Garya ASUДалее мы даем плановику инструмент для составления любых планов на основе любой из методик...
Вы даете ТОЛЬКО плановику? Если нет, то кому еще?См. ранее: экономистам, администрации производственных подразделений, кадровикам, бухгалтерам и т.д. и т.п. Суть в том, что мы не берем на себя решение задач пользователей, мы предлагаем им инструменты для решения их задач. Но важно и то, что эти инструменты интегрируются в единую систему.
GaryaСкажите, инструмент, о котором Вы говорите, может решить такую задачу...Инструмент не решает задач. Молоток сам не забивает гвозди (даже, если это пневмо- или электромолоток), текстовый редактор не набирает тексты... Мне кажется, что Ваша формулировка неверна, но я могу сказать, что с помощью наших инструментов пользователи могут решить описанную Вами задачу. При этом способов решения может быть много (с разной степенью автоматизации).
Garya ASUВы так серьезно относитесь к "творениям" APICS? Ох... напрасноА Вы к чьим творениям относитесь серьезно? Или таких в природе нет?Почему же, такие творения есть... Просто опыт показывает, что “гора”, как правило, “рождает мышь”. Присмотритесь внимательнее (например, с позиций системного анализа) к функциям декларированным APICS в качестве основы MRP-II, присмотритесь к положениям ISO 900X:2000 или к “трудам” CODASYL... Согласитесь, это грустное зрелище, хотя, наверное, поучительное...
Garya ASUЯ уже сказал, что несогласен
Я попытаюсь для себя разжевать вашу позицию, а Вы либо подтвердите, правильно ли я Вас понял или опровергните, ок? Одно предприятие решило применять TOC как стратегию управления. Спустя 2 года, когда все узкие места были практически ликвидированы, она решила изменить стратегию на схожую с методологией MRP. Еще через пару лет она, задавив конкурентов демпинговыми ценами, вышла на тот уровень, когда спрос резко превысил предложение, и стратегия управления запасами MRP оказалась неактуальной, она решила изменить ее на базирующуюся на статистических методах. Еще через некоторое время, увидев, что спрос на рынке продолжает расти, и предложение продолжает существенно отставать от спроса, руководство вновь решило перейти на TOC, сконцентрировавшись на увеличении пропускной способности предприятия. Я правильно понял, что вы изобрели концепцию ERP-системы, которая всё это легко сможет осуществить, облегчив переход с одной стратеги управления на другую. И даже когда в очередной раз в теории управления или в экономических теориях ученые изобретут новый очередной метод управления, ваша система автоматом сможет его реализовать, потому что он в ней изначально таился?В целом, то что Вы сказали, верно... Но проблема в том, что мы ничего не “изобретали”. В основе нашего подхода лежат т.н. семантические модели, то есть, модели адекватно передающие смысл. Смысл не зависит от тех или иных взглядов на него, он абсолютен. То, что Вы написали – это частные проекции смысла на ту или иную действительность. Понимая смысл, Вы можете предложить инструмент для проецирования смысла на любые частные условия.

Andr2to ASU
Такой вопрос - приходилось ли Вам работать с предприятиями типа гор(обл)газов или водоканалов ? [население/тарифы/льготы и прочая прелесть :) ]Нет, не приходилось.

MVM Andr2to ASU
Такой вопрос - приходилось ли Вам работать с предприятиями типа гор(обл)газов или водоканалов ? [население/тарифы/льготы и прочая прелесть :) ]Мне приходилось. Это же не производство. Это оказание услугСпорное утверждение. Проведите грань между оказанием услуг и производством.

gzЕсть конкретная система автоматизации управления, реализующая какиие-то функции на конкретном предприятии. А есть некие инструментальные средства, с использованием которых разрабатывается эта система автоматизации управления
Видимо, ASU, имея в виду второе и используя его понятийный аппарат, пытался пояснить свою мысль. Согласен, что с этой точки зрения все правильно.
Хотя, если шагнуть вверх, то можно рассмотреть этот вопрос с позиций вообще теории управления, а затем, поднявшись еще выше, - с точки зрения причинно-следственных связей.
Я же имел в виду конкретную реализацию с наполнением (в виде "расчетных процедур", "алгоритмов", "бизнес-логики" ...)Первое. Действительно, есть программные инструментальные средства разработки, но я имел ввиду не их. Речь шла об инструментах для пользователей. Можно написать программу расчета себестоимости продукции, но можно дать пользователям инструмент для создания расчетных схем. В первом случае, разработчики обречены на то, чтобы стать рабами своего же “детища” (добавляя новые методики расчетов в свою программу или изменяя существующие методики). В первом случае, разработчики обязаны быть квалифицированными специалистами в каждой конкретной предметной области. В первом случае, пользователи зависят от желания, возможностей и способностей программистов. Во втором случае... все проще.
Второе. Построение системы управления надо начинать с теории систем, с теории управления и т.д. Как же иначе?
Третье. Я тоже имел ввиду ”конкретную реализацию с наполнением (в виде "расчетных процедур", "алгоритмов", "бизнес-логики" ...)”, только видимо, Вы подразумевали, что наполнение делается разработчиками, а я то, что наполнение делается пользователями.
gzМне бы тоже хотелось знать, что такое склад и что такое складские функции. И если есть методика разложения задачи на отдельные составляющие, готовые решения или средства разработки, это большой плюс. Не имея этого, к сожалению, при решении конкретных задач приходится привязываться к "конкретике".
Да, анализ выполняет ЦЗЛ, а отвечает за качество ОТК (кстати не входит в состав ЦЗЛ, а подчиняется непосредственно руководству предприятия). И если есть система управления качеством, это хорошо, хотя от склада должна быть "протянута ниточка" к этой системе. Не имея этой системы и "ниточки", имеем спецификуСовершенно верно! И у Вас есть выбор: либо бесконечно реализовывать специфику, либо... построить систему, не требующую этого. А что такое склад (смысловое содержание этого понятия), ранее было сказано в статье, на которую я давал ссылку и Garya: Garyaсклад готовой продукции выполняет роль демпфера при колебаниях спросаЯ бы только уточнил, что любой склад – это демпфер. Как и любой демпфер, склад предназначен для сглаживания неравномерностей входного и выходного потоков. Неравномерности могут быть временные, объемные и комбинированные.
gzДалее - цены, нормативы запасов - отвечают экономисты. Ну и что из этого ? Любая позиция на складе характеризуется колличественными, качественными параметрами, ценами, местом хранения, МОЛ и т.д. Допустим также, для отслеживания складских остатков и сравнения их с нормативами нужна какая-то другая, не складская системаПростите, этого я не понял. Возможно, Вы хотели сказать, что информация об остатках может быть востребована другой подсистемой для каких-то ее (подсистемы) целей.
gzВообще говоря, разлагать на составляющие можно до бесконечностиС. Бир считал также, но я думаю, что это заблуждение.
gzСледовать каким-то канонам, конечно, надо. Однако, на чем-то все-таки надо остановиться. Не всегда согласуясь с "канонами". И вводить специфику. И добавлять складские операции, и еще много чегоЯ не говорю ни о каких канонах, я говорю только о смысле (семантике). Если что-то предлагается сделать вопреки смыслу, то это бессмысленно (по определению).
gzTo ASU. Опуститесь на "грешную землю", дойдите до нас "грешников" и дайте нам "понятия", как жить нам "по понятим", а также рецепты построения систем управления - мы будем очень рады. А просто так - поболтать об "отростках" бухгалтерии мы и сами "могем"Смысл открыт каждому независимо от возраста, вероисповедания, цвета кожи, образования и пр. Но никто не может вложить смысл другому. Можно пользоваться метафорами (склад – демпфер), но... “Дао, переданное словами, - не есть подлинное Дао” (Лао-цзы). И Вы можете судить о том, правильна ли метафора или нет, но путь к метафоре (проекция смысла (склад) на понятийный аппарат (демпфер)) все равно останется “за кадром”. Нет учебников и нет учителей, способных передать смысл...
gzС уважением - один из неучей-смешивателей понятий, по соместительству разработчик вышеупомянутых системВидимо я Вас обидел, прошу меня извинить, я не имел таких намерений. Я тоже “неуч”... но не вижу в этом ничего плохого. Лао-цзы сказал: “Мудрый многого не знает, знающий много не мудр”, а я не стремлюсь к знаниям, но хотелось бы прикоснуться к Мудрости.

Andr2 ASU Andr2to ASU
Такой вопрос - приходилось ли Вам работать с предприятиями типа гор(обл)газов или водоканалов ? [население/тарифы/льготы и прочая прелесть :) ]Нет, не приходилось. А возможно ли (в принципе) получение Вашей помощи в автоматизации такого предприятия ? В каких-либо границах - от простой консультации до проведения обследования предприятия... и далее вплоть до внедрения, скажем на основе Ваших разработок ? Заинтересовал подходДа, возможно. С моей точки зрения, есть три ключевые класса предприятий: производственные, "логистические" (транспорт, торговля) и финансовые. Других быть не может. И неважно на какую "отрасль" мы делаем проекцию этих классов. В данном случае, можно сделать проекцию на коммунальные предприятия или любые другие.
Помощь может быть оказана на трех уровнях:
1. Мы передадим Вам модели, поможем организовать работу команд(ы) разработчиков, расскажем/покажем методику внедрения;
2. Мы сделаем проект по нашим моделям, а Ваши разработчики его реализуют;
3. Мы разработаем систему и передадим ее Вам со всей документацией (включая модели, проектные схемы и исходные коды, разумеется).