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