Семенов Ф.П.Что же предлагается? Вообще отказаться от описаний! Он предлагает модели, которые содержат в себе механизмы верификации.Подход интересный. Но содержит ли он в себе ИНСТРУМЕНТЫ ? Подозреваю, что нет. Способен ли такой подход СИНТЕЗИРОВАТЬ правильную (более оптимальную, нежели какая-либо другая) модель системы? И при этом ДОКАЗАТЬ , что она действительно самая оптимальная. Полагаю, что нет. Полагаю, что "НЕКТО" выбрав наобум некоторую другую модель, даже не прогняя ее через жесткую верификацию и имея, может быть, даже некоторые недочеты по сравнению с предложенной моделью, в реальных условиях может в итоге оказаться более успешным. Почему? Потому что его интуиция оказалась сильнее всех "верификаций". Он смог включить в систему то, что не догадался включить тот, кто использует верификацию. Верификация так же не является критерием оптимальности системы, ПМСМ. Она может представляться подобным критерием только при выполнении целого ряда оговорок и условий, начинающихся с "если...". А вот в этих самых "если" и находится самая большая засада. Они могут слишком сильно разойтись с реальностью - потому что реальность прогнозируема только до некоторой степени.

Семенов Ф.П.Цитата из письма АСУ: “Если в систему вводится новая подсистема (в структуру предприятия вводится новое подразделение), то необходимо определить для чего нам это нужно, то есть, сказать что полезного она способна делать. Это раз. Два. Что необходимо новой подсистеме для того, чтобы она могла работать. Три. Необходимо увязать потребности и возможности новой подсистемы с возможностями и потребностями других подсистем. Четыре. Надо проверить экономический эффект…”. Далее идет описание экономических методик и планирования.Всё перечисленное делает любой здравомыслящий процессный менеджер, в том числе тот, который не знаком с теорией систем. Только кроме ввода новой подсистемы может произойти изменение существующей - в соответствии с выявленными недочетами ее работы или в связи с изменившимися условиями внешней среды. Я не думаю, что верификация системы может заведомо выявить, например, недостаток чьей-либо квалификации в решении внештатной ситуации, которая всего лишь МОЖЕТ ПРОИЗОЙТИ . Когда же такая ситуация уже произошла, и проблема действительно выявлена, ее необходимо устранить. Так что от проверки практикой невозможно никуда уйти даже после верификации.

Семенов Ф.П.]Пока я еще не могу сделать каких-то окончательных выводов об этом методе.Я тоже не могу сделать окончательных выводов. Но сильно подозреваю, что так называемая "верификация" - это проверка ПРЕДПОЛОЖЕНИЙ на предмет их соответствия опять же ПРЕДПОЛАГАЕМЫМ УСЛОВИЯМ , и ничего более. Эта верификация не позволяет " ДОКАЗАТЬ ", что предположения были изначально верными и модель системы построена наиболее оптимальным образом.

Семенов Ф.П.Гаря, скажи пожалуйста, зачем надо было выгонять интересного собеседника, а потом безответно склонять его в каждом сообщении?Прошу подобных вопросов больше не задавать. Заранее предупреждаю, что буду их резать. Я уже ответил на них. Выгнан он был за нарушение правил, а не потому что мне оппонировал. То, что собеседник он интересный, полностью согласен. Сам бы с интересом выслушал бы его мнение по многим вопросам, но только в рамках цивилизованного обмена мнениями. У него есть возможность вернуться к обсуждению. На текущий момент он ею не воспользовался.
Со своей стороны постараюсь имени A_S_U больше не упоминать.

velfimov2 ФЕБ & Garya
Плиз может я чего-то не допонимаю, но раньше я считал, что если провести разграничительную линию, то ERP обращены лицом к сотрудникам, а MES — к производственному оборудованию и занимается тем, что обеспечивает поставку оперативных данных для той же самой ERP.
MES должна связана непосредственно с производственным оборудованием, которое через системы датчиков заносят данные в автоматическом режиме и передаёт их для оптимизации производственных процессов.
Разъясните не понятки.Однозначной трактовки термина "ERP" просто не существует. Поэтому сколько у них лиц, обращены ли они этими лицами к чему-либо и какими именно - сказать трудно. Тот факт, что большинство ERP-систем базируется на MRP-алгоритмах планирования, не говорит о том, что ERP "вообще" обязательно только на них и должны базироваться.

MRP ориентирован на объемно-календарное планирование. MES реализуют алгоритм диспетчеризации, ориентированный на пооперационное управление до самого низового уровня. Есть еще алгоритмы APS, которые до некоторой степени также могут использоваться для этих целей. Каких-то кардинальных отличий, четкой грани между APS и MES лично я не наблюдаю (отмечаю, что это IMHO!). APS изначально появились как "дополнения" к ERP-системам, а позже стали включаться в ядро некоторых ERP-систем как их неотъемлемая часть. Поэтому противопоставлять APS и ERP просто некорректно. MES - класс спеицализированных программных продуктов, ориентированных прежде всего на пооперационную диспетчеризацию производства (зачастую с накруткой вокруг этого всякого "окружения"). Но в последнее время в составе некоторых ERP-систем стали появляться алгоритмы, фактически ничем не уступающие полноценным MES, представленным в виде отдельных продуктов. Если ФЕБ считает иначе, я прошу его дать сравнительную характеристику алгоритмов диспетчеризации, встроенных, например, в ERP-систему "IT-предприятие" в сравнении с классическим ПО класса MES.

2 velfimov. Чтобы вставить в текст URL, который сможет выглядеть в виде гиперссылки, нужно просто перед ним поставить два слеша. Пример:

Модератор: 2 iscrafm. Постарайтесь быть более вежливым. Иначе мне придется принять меры.

Семенов Ф.П.И еще об инструментах: “Любая программа или комплекс программ – это только инструмент, инструмент должен быть адекватен решаемым задачам. Если есть понимание модели предприятия и управления, тогда можно выбрать или создать необходимые инструменты”.Инструменты можно "выбрать" только в том случае, если они заведомо имеются в модели. Если они изначально туда не были заложены, сами собой они там не появятся. Если в ПО не был заложен такой инструмент как диаграмма Ганта, а было лишь табличное представление, значит менеджеру приделся "ломать глаза" об табличное представление, и в итоге проглядеть что-то очень важное, хотя в другом программном продукте, не использующем никакой верификации, другой такой же менеджер сможет быстрее решать задачи и при этом не пропустить что-то важное. Если в какой-либо программный продукт включены оптимизационные математические алгоритмы (MES, например), то, воспользовавшись этими алгоритмами, можно получить более оптимальную диспетчеризацию производства (это ведь тоже область управления, не так ли?), если же составляющий модель управления не имеет в распоряжении этих алгоритмов, как он ни верифицируй свою схему, он получит МЕНЕЕ ОПТИМАЛЬНОЕ , нежели с помощью MES-алгоритмов, расписание производственных заданий. Исходя из не совсем корректных обобщенных "постулатов", можно прийти к моделям ценообразования на предприятии, не удовлетворяющем потребности рынка, иным, нежели TOC, и не смотря на все верификации может выясниться, что TOC позволяет проводить более оптимальную ценовую политику и при этом добиваться более быстрого роста объемов выручки и прибыли. Просто потому, что модель системы не разбита до той степени детализации, чтобы обнаружить в ней принципиальное отличие потоков, проходящих через "бутылочные горлышки" и мимо них. Скажите, в предлагаемых моделях фигурирует ли отдельное транспортное средство, отдельно взятый станок, отдельный токарь, или они представлены обобщенными группами элементов, "варево" внутри которых моделью уже не анализируется и не контролируется?

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

2 Семенов Ф.П. Хочу дополнить ранее сказанное.

Что такое собственно "верификация"? В каких ситуациях и как часто она производится? Если только лишь в ситуациях "добавления подсистемы" - то насколько можно доверять верификации, прошедшей 10 лет назад, год назад, месяц, неделю, день, минуту? Ведь условия существования системы постоянно изменяются, не так ли? Допустим, при существующих условиях мы разработали модель системы, частью которой является подсистема ценообразования. Мы ее верифицировали и пришли к выводу, что цены лучше всего указывать в USD, потому что (тра-та-та - обоснование - доказательство - не придерешься...). Верифицировали ее мы год назад. А завтра выйдет постановление Правительства, в соответствии с которым (а также в связи с уже свершимшимся фактом конвертации российского рубля) цены во всех прайсах, публичной информации и т.д. и т.п. не имеют права указываться не только в USD, но даже в у.е. - только в российских рублях. Начиная с этого момента ранее верифицированная модель системы перестала быть корректной. Что говорит теория систем о том, каким образом поддерживается актуальность верифицированной схемы? Или она вообще по этому поводу ничего не говорит? Я понимаю, что приведенный мною пример слишком очевиден - наверняка кто-то сообразит внести изменения в структуру системы и провести ее повторную верификацию. Но ведь могут быть ситуации существенно более "тонкие" и малозаметные. Это примерно то, на что мне указывали пальцем, мол, где гарантия, что ничего нигде не забыли. А где гарантия, что верифицированная модель не устареет через 5 минут и ее не понадобится повторно верифицировать?

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