Andr2 ASU...Для того, чтобы снять эти и подобные вопросы удобно использовать простые семантические модели объекта и субъекта управления (в данном контексте: предприятия и его управляющего аппарата)
Не могли бы это пояснить на каком-нибудь примереТрудно ответить на данный вопрос, не иллюстрируя ответ моделями. А описывать семантические модели, не смотря на их простоту, достаточно долго, так как надо спроецировать смысл на известные понятия, сущности и их связи...
Попробуйте представить развитие системы из отдельной подсистемы или развитие подсистемы из отдельной задачи. Например, развитие 1С из бухгалтерской подсистемы в систему управления предприятием. Что получилось в результате? Некая учетная система "чего и как угодно", но системы управления из этого не получится никогда. Управление включает в себя учет (иногда!), но само не является учетом, точно также, как автомобиль не является колесом.
Но проблемы разработчиков 1С родились раньше, чем сами разработчики. Спросите бухгалтера о том, что он думает об управлении предприятием... Ответ в большинстве случаев предопределен. Но о том же можно спросить кладовщика, начальника цеха, финансиста или коммерсанта.
Семантическая модель "отвязана" от любых точек зрения, она представляет собой смысл какого-то понятия или явления. В чем смысл производства, финансовой службы, коммерции, склада и т.п.? Если этот смысл удается передать кратко (желательно одним словом, иначе получим не смысл, а некое определение), полно (смысл можно спроецировать на любую точку зрения), непротиворечиво (любая частная точка зрения не противоречит смыслу), то тогда можно говорить о том, что модель является семантической.

Andr2 ASUСемантическая модель "отвязана" от любых точек зрения, она представляет собой смысл какого-то понятия или явления. ... Если этот смысл удается передать кратко (желательно одним словом, иначе получим не смысл, а некое определение), полно (смысл можно спроецировать на любую точку зрения), непротиворечиво (любая частная точка зрения не противоречит смыслу), то тогда можно говорить о том, что модель является семантическойОчень хочется продолжить :)Мне тоже, но... наверное, это не должно быть в формате форума (по крайней мере, в первой стадии, когда надо просто рассказать об одной - двух моделях).
Andr2Т.е. начинаем строить модель снизу ? - анализируя т.зрения подразделений, выделяя общее в них ?Нет, ни в коем случае. Это весьма распространенное заблуждение! Совокупность всех точек зрения не тождественна предмету исследования (целое не тождественно сумме частностей, об этом много и правильно писал Богданов, а еще за две тысячи лет до него восточные философы).
Andr2Или, имея некое предварительное(apriori) понятие, накладыать на эти точки зрения и смотреть, не выходит что-нибудь за предложенные рамки ?Да, именно так. Но рационально объяснить путь формирования этого исходного "понятия" еще никому не удалось... (насколько мне известно). Однако, из сказанного не следует безнадежность этого мероприятия (формирования исходного семантического представления о предмете). Если не отрицается тезис о том, что "все имеет смысл", то... первый шаг уже сделан.
Andr2Если взять финансовую службу. Можно ли сказать, что смысл финансовой службы - управление денежными средствами предприятия ? Достаточно ли это будет при построении семантической модели ?
А как при построении сем.модели, на каких этапах происходит детализация и до какого уровня ?Управление денежными средствами предприятия - это функция, но не смысл. Функция выводима из смысла, обратное неверно. Вспомните времена, когда предприятия не имели финансовых средств. Означало ли отсутствие денег ненужность финансовой службы? Да, и "финансовая служба" (по смыслу, а не по названию) появилась задолго до появления первых денег, IMHO.

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

Garya2 ASU. Согласен.Спасибо, мне было очень приятно побеседовать с Вами.

GaryaЯ выше уже спрашивал, но Вы не ответили. Повторю вопрос:
Или ваша система позволяет сама готовить на компьютере ЧЕРТЕЖИ авиалайнера!!!??? Нет, подготовка чертежей это иная область (проектное производство ), но технология производства авиалайнера для конкретного предприятия должна быть в системе управления промышленным предприятием.
Garya ASUЯ уже говорил Вам, что MRP-II это набор просто функций, но управление несводимо к набору функций, даже один и тот же субъект управления в разных условиях должен иметь разный функциональный набор (передача функций другому субъекту, делегирование функций в “над” и “под” уровни и пр.)А я с этим и не спорю. Просто я считаю что УПРАВЛЕНИЕ осуществляется НЕ программой и НЕ компьютером. По крайней мере, до тех пор, пока не появятся достаточно развитые системы с искусственным интеллектомСогласен. Компьютерные системы должны помогать управлять , но управлять (социальными системами) они будут еще не скоро. И дело, как мне кажется, не только в том, что искуственный интеллект недостаточно развит (пока понятие интеллекта вообще не определено). Не очень понятно, как быть с... ответственностью за принятое решение. Садить в тюрьму или казнить "компьютер"... не слишком разумно:)
GaryaMRP-II предоставляет возможность осознанно руководству применить одну из нескольких стратегий управления предприятием (не все, не все возможные!) в совокупности с одной из нескольких технологий управления (тоже не всеми возможными). Тем не менее, если руководство делает осознанный выбор, то оно держит вожжи в своих рукахДа, я согласен с Вами.
GaryaЕсли же Вы придумали некую семантическую систему, с помощью которой можно описать ЛЮБУЮ стратегию и технологию управления, то... То мне сразу вспоминается Ассемблер. На нем тоже можно реализовать ЛЮБУЮ стратегию и технологию управления, и он также имеет свою семантику. Остается только один вопрос - вопрос трудоемкости описания конкретной задачи с помощью имеющейся семантической схемы. И тут выясняется, что этот вопрос далеко не второстепенный, а можно сказать, вопрос самой первой важности. Если бы он таковым не был, то не возникло бы никаких иных языков программирования и RAD, поскольку они лишь сужают возможности, предоставляемые Ассемблером. Но при этом - за счет более жестких семантических рамок в этих рамках появляется возможность описывать конретные задачи за гораздо меньшее время. Время - это очень существенный фактор. Вот меня и интересует, СКОЛЬКО ВРЕМЕНИ требуется потратить, складывая кубики из вашей семантической модели, чтобы получить реально работающую систему с функциональностью полноценной CAD/CAM-системы?Хорошее сравнение с ассемблером. Но должен заметить, что ассемблеров больше, чем процессоров и каждый из ассемблеров имеет свои сильные и слабые стороны. Это первое. Второе. Языки высокого уровня появились не в качестве альтернативы ассемблеру, а для лучшей семантической связи с задачей, абстрагируясь от частностей машинных команд. Примерно то же самое (и даже больше) можно было сделать, пользуясь только ассемблером и встроенным в ассемблер макроязыком. Выразительная (с точки зрения решения задачи) мощность данного решения выше, чем у большинства ЯВУ, а трудозатраты меньше. Единственный серьезный недостаток такого решения - проблема портируемости (кроссплатформенности). Но есть и значительное преимущество: постепенное (от уровня к уровню) абстрагирование (по направлению от процессора в сторону предметной области). Современные ЯВУ имеют значительно более слабые макроязыки по сравнению с ассемблером (или вообще не имеют макроязыка), а это снижают адаптационные возможности языка. Изучив ЯВУ программист не стремится получить в языке понятия близкие к тем, что существуют в предметной области, он стремится выразить термины предметной области в терминах конкретного языка программирования. И это, с моей точки зрения, очень плохо.
Что касается нашей системы, то здесь все довольно просто: есть уровень системы и существуют уровни подсистем. Можно настраивать всю систему, можно отдельную подсистему, но это разные уровни, и задачи, решаемые на каждом уровне тоже различны. Поэтому не требуется решать высокоуровневую задачу низкоуровневыми средствами.

GaryaЯВУ создает менее оптимальный код, нежели это можно сделать непосредственно на ассемблере. И... если, например, в языке 1С нет команд формирования графических фигур на экране, то - приехали. Нужно построить, а - нету! Приходится выкручиваться левой ногой через правое ухо (сначала нарисовать фигуру, затем подцепить ее как элемент формы, например). Во многих ЯВУ нет команд, выполняющих циклический сдвиг битов. И многого другого нет. Но тем не менее - ими пользуются! Гораздо чаще, чем Ассемблером. ПОЧЕМУ? Потому что подобная "всеобъемлемость" ценой высоких расходов на разработку оказывается слишком затратной, слишком трудоемкой, слишком несовершеннойМне кажется, что это довольно распространенное заблуждение. В Вашем высказывании присутствует недооценка возможностей макроязыков ассемблера. С помощью макроязыка можно получать достаточно мощные конструкции, не уступающие по своим возможностям конструкциям ЯВУ. И затраты на разработку программ на ассемблере вполне сравнимы с затратами на разработку программ на ЯВУ (это утверждение не является голословным и я могу подтвердить его примерами). Неиспользование ассемблера имеет иные корни. Какой язык наиболее популярен в мире? Basic! Но является ли он наименее трудозатратным/удобным при разработке программ? GaryaВы утверждаете, что придумали новую семантическую модель, с помощью которой можете описать все и вся на производственном предприятииНет, видимо я недостаточно повторял, что
а) мы ничего не выдумывали;
б) семантическая модель не предназначена для описаний, она просто передает смысл того или иного понятия/явления;
в) мы не занимаемся описаниями, наша цель состоит в том, чтобы донести семантику до руководителей предприятия и подразделений. А специалисты предприятия, используя предложенные модели, могут определить структуру своего предприятия и управления, распределить функции, отстроить сценарии работы (процессы). GaryaНо производственное предприятие начинается с проектирования производства(Видимо речь идет о проектировании продукции?) GaryaИ не только начинается, но и продолжается. Фактически на каждом заводе сидят конструктора и технологи. И они там не лапу сосут в зимней спячке. Они работают, совершенствуют конструкцию и техпроцесс. Давеча вот Вы сказали: ASU”Это” не должно импортироваться, это должно быть частью системы. ТО и ТП – не прихоть технолога, это описание объекта управления. Понимаете?Вы это просто так сказали? Ведь Вы меня убедили! Я согласен с Вами! И чуть позже: ASUНет, подготовка чертежей это иная область (проектное производство), но технология производства авиалайнера для конкретного предприятия должна быть в системе управления промышленным предприятиемНу как же так? У вас же универсальная семантика, с помощью которой можно описать ЛЮБЫЕ процессы. Ведь разработка конструкторской и технологической документации - это неотрывная часть производственного процессаВо-первых, давайте опустим слово “универсальность”, оно здесь неуместно. Во-вторых, нет никакого противоречия в том, что я сказал. Проектное производство (а КБ – это частный случай проектного производства) действительно самостоятельное производство. Можно делать проект самостоятельно, можно заказать его “на стороне”. Если проектное производство является частью предприятия, то оно должно управляться наряду с другими подразделениями/подсистемами данного предприятия.
Технология производства – иная область. В отличие от конструкторского проекта, который собственно описывает продукцию, технология должна сказать, как произвести эту продукцию на конкретном предприятии . То есть, технология является менее отчуждаемой, более привязанной к конкретной специфике предприятия (к типам его оборудования, сырьевой базе, климатическим условиям и пр.). И если конструкторскую документацию можно получить извне, то получить документацию по технологической подготовке конкретного производства намного сложнее. Да, существуют проектные технологические организации, которые разрабатывают “технологии” производства различных видов продукции. Но я не случайно взял в кавычки слово “технологии”, поскольку здесь речь идет об только общих принципах и методах, без указания требований к конкретному оборудованию, квалификации персонала и пр. И данные рекомендации по технологии производства должны быть адаптированы к конкретному производству (в отличие, от конструкторской документации). Так понятнее? GaryaЛадно, авиалайнер, дейсвтительно сложная штука. Разрабатывает конструкторскую документацию обычно одна организация. Проводит испытания - другая. Запускает в серию - третья. Но если завод производит чайники/пылесосы, то все это находится на одном предприятии, и отделить одно от другого можно только рубанув по живому и сделав предприятию больноНе согласен. В теории систем есть понятия “слабых” и “сильных” связей. В сочетании с семантикой подсистем это позволяет получить
а) структуру предприятия;
б) принципы декомпозиции всей системы и ее подсистем;
в) схему управления предприятием при внутренних и/или внешних изменениях.
Те деления, о котором Вы пишите, относятся к пяти фазам “жизненного цикла” продукции (моделирование, проектирование, планирование, производство, эксплуатация). Каждая из этих фаз может реализовываться в рамках одного предприятия или разных предприятий (то есть, обычное разделение труда). GaryaК чему я это? Да к тому, что одна лишь семантика не может в принципе решить проблем мироздания вообще и управления в частностиХм... Давайте вспомним. “В начале было Слово...”. В оригинале написано, не “Слово”, а “Логос”. Логос можно перевести и как “слово”, и как “мысль”. То есть, “проблемы мироздания” - это проблемы утраты Логоса :) GaryaРаз Вы не можете в своей семантике автоматизировать работу конструктора, значит Ваша семантика имеет ограничения функциональности по сравнению со специализированными CAD/CAM-системами. Я прав?Я не говорил, что не могу автоматизировать работу конструкторов. Я могу автоматизировать управление проектными организациями (просто, я занимаюсь системами управления, а не CAD-системами). GaryaИ если я прав, не логично ли будет предположить, что это может быть не единственная область жизни производственного предприятия, которая не очень гармонично вписывается в предложенную Вами семантическую модель?Пока не очень понятно, откуда взялась дисгармония? Повторю, что с точки зрения управления предприятием совершенно безразлично, откуда берутся чертежи (извне или из собственного КБ). Если предприятие имеет свое КБ, то управление этим КБ должно быть частью общей системы управления. А поскольку речь идет о системах управления, а не CAD-системе, то мне непонятно, почему система управления должна включать в себя CAD-систему. Так можно дойти до того, что замена простого рубанка у плотника на электрорубанок потребует изменить систему управления... GaryaЯ приведу только один пример. Во всех имеющихся системах управления предприятием имеется некоторая ориентированная на выбранную семантическую модель структура хранения информации о контрагентах (поставщиках и/или покупателях). Имеется проблема идентификации имеющейся в системе информации и сопоставление ее с той информацией, которая вновь поступает в систему. Там, где эта проблема вообще не решается, возникают многочисленные дубликаты и клоны одной и той же организации. Где с лишним пробелом в названии, где в разной вариации сокращений разных частей наименований. ИНН проблему не решает - не всегда он известен (в момент выписки счета он может быть неизвестен), а у некоторых РАЗНЫХ организаций может быть один ИНН (не делайте круглые глаза, я уже за вас их сделал, когда впервые с эти столкнулся). Небольшая неточность в работе может привести к формированию некорреткных данных о взаимо расчетах, и не только в них. Можно ли победить эту проблему СЕМАНТИЧЕСКИМИ методами? Уверен, что нет.
К чему это я? Там, где в ERP-системах действительно имеются проблемы, Ваша, семантическая, наверняка тоже спасует. А вот каких новых проблем она может добавить - это уже вопрос, наверное, не к Вам, а к независимым экспертамЗадача семантической модели не в том, чтобы отлавливать ошибки при вводе информации или устанавливать уникальность ИНН, а в том, чтобы исходя из смысла предприятия выстроить его структуру, дать методы оптимизации структуры при изменениях на самом предприятии и вовне; отразить смысл подразделений (подсистем) и т.п. Другими словами, на основании смысла получать проекции на любую плоскость рассмотрения, выявлять истоки проблем и находить способы их решений. Мы точно также перенесли смысл предприятия на его систему управления, и, далее, на проект программной системы. GaryaСемантическая ограниченность ERP-систем мне не кажется серьезным недостаткомДословно это означает, что ограничение (отсутствие) смысла не является недостатком. Позволю себе не согласиться с таким утверждением. На мой взгляд утрата смысла – это корень всех остальных проблем, недостатков и сложностей. Но это моя частная точка зрения. Garya"Не это главное" (Тот самый Мюнхаузен (с) ), вспоминая Ассемблер. ИМХО, конечно. Я более чем уверен, что Ваша семантическая система также функционально ограничена (верно выше сказали, что опускаться сверху вниз можно только до определенного уровня, а Вы не согласились, видимо полагая, что сможете расщепить любое предприятие до кварков), и именно это обстоятельство является препятствием для развертываения внутри нее функциональности CAD/CAM-системыВаши выводы кажутся мне поспешными.
Нет никакой необходимости расщеплять предприятие до кварков, это ничего не добавит в представление о том, как управлять предприятием. Знания о том, из каких атомов состоит камень не уточнит траектории его полета... Garya ASUПоэтому не требуется решать высокоуровневую задачу низкоуровневыми средствамиЭто бабушка на двое сказала...У нас с Вами разные бабушки :) GaryaПри решении высокоуровневой задачи высокоуровневыми же средствами можно получить проблемы на нижних уровнях. И получают. 1С - очень живописный тому пример (вернулись к теме топика ). Вопрос только в сопоставлении проигрыша от этих проблем с экономией времении и иных ресурсов от выбранного метода решения задачиЗдесь смешаны два понятия: уровень и адекватность. Проблемы 1С проистекают не из того, что они создали высокоуровневое средство, а в том, что они создали средство неадекватное той задаче, которую взялись решать.

guest9876 ASUВообще об этом лучше А.А. Богданова не напишешь. В “Тектологии” вопросы соединений/разделений разобраны очень подробно.
Похоже на новую религию и новую библию.
Новая мода - новые веяния - из области описаний регламента, перестройки, переписывания регламентов.
Подход - под любое предприятие подкладывать готовые модели,Во-первых, говорить о новизне идей, которым уже 100 лет ("Тектология" была издана в 1911 году), как-то... странно. Во-вторых, ничего сравнимого по глубине с данной работой не было сделано за весь 20-й век. В-третьих, "Тектология" выстроена логически, а это характерно для научных работ, а не для религиозных трактатов. Ну, и, наконец, сам А.А. Богданов (Малиновский) не причислял себя не только к религиозным деятелям, но и к философам.