Aviant АБ Я хотел сказать вот что: тема, которую поднял автор первого поста (бесконечное наращивание возможностей систем не единственный путь дальнейшего развития), известна, разрабатывается, ключевые слова -- SOA, BPM. Окончательные выводы делать естественно рано, поживем -- увидим (а кое-кто не только смотрит, но и руки уже прикладывает). Да. Вообще маятник пошел назад. Люди на своем опыте поняли, что бесконечные "мега системы" не решают проблемы, они устаревают к моменту внедрения. Значит попробуем писать много маленьких, а потом пытаться их связать "на принципиально ином уровне". Ну... посмотрим, что-то в этом наверное есть.
Посмотрите, например, Система, которую можно собирать даже без привлечения разработчиков.

Calm автор Система, которую можно собирать даже без привлечения разработчиков.

Ну вот не верю! НЕ ВЕРЮ!!
Не думаю, что это вопрос веры...

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

Calm авторЧто же касается частных вопросов, то... наверное их лучше разбирать в отдельном обсуждении.
Да из этих частных вопросов складывается работоспособность системы.
Их много и они важны. Да, конечно. Но разбираться в частных вопросах надо тогда, когда решены концептуальные вопросы, IMHO. Иначе, "за деревьями леса не видно"... :)

tobox авторК примеру, зарезервировали мы товар под конкретный заказ. А заказчик не платит и не платит... Через три дня резерв сняли, но... три дня материал (товар) был "заморожен".
Ну и что? бывает и 1 и 2 % таких перцев. Что ж теперь, рисковать не обработать остальные 98% ? Кто говорит, что не надо обрабатывать "остальные 98%"? Говорилось только о том, что обеспечение заказа материалом (товаром) можно реализовать разными способами.

Calm автор Но разбираться в частных вопросах надо тогда, когда решены концептуальные вопросы,
Безусловно так. Прото бывает, что концептуальные вопросы решены так, что частные уже не решаются. Совершенно верно, поэтому вопросам семантики исходных моделей должно уделяться серьезное внимание.

MainFrameВопросы по системе задам. Вопрос сопровождения и быстрой реакции на изменяющиеся бизнес-процессы думаю скоро станет (если уже не стал) краеугольным камнем развития крупных корпоративных систем. Каким образом это решается у Вас? Как я понимаю, Ваша система позиционируется именно в этом отличной от других. Может быть, и концептуально и практически? Существуют разные подходы к созданию систем. В основе реализации практически всех известных ERP-систем лежит т.н. case-method. По своей сути, этот метод состоит в том, что исходная модель «списывается» с одного или нескольких успешных предприятий. Если посмотреть на книги по проектированию, то и они говорят о том же: «Первый этап проектирования представляет собой анализ требований пользователей». Следствием применения данной методики является получение множества частных решений, высокая трудоемкость создания системы, потребность в описании бизнес-процессов на каждом конкретном предприятии, значительная трудоемкость внедрения и сопровождения, недовольство специалистов предприятия (технологов, плановиков, экономистов и пр.) и т.д.
В основе системы «КУБ» лежат семантические модели. Они очень просты и легко воспринимаются руководителями. Их значительно проще реализовывать, внедрять, сопровождать и развивать. Пример модели промышленного предприятия есть в разделе «планирования». При внедрении системы основной упор делается на раскрытие и донесение смысла деятельности до руководителя с последующим обучением использованию программного обучения (собственно, все внедрение состоит из двух функций объяснения и заведения нормативно-справочную информацию). Описывать бизнес-процессы нет никакой необходимости, вместо этого на основе предлагаемых моделей совместно с руководителями предприятия делается анализ организационной структуры предприятия. Важно, чтобы руководитель сам сформулировал существующие проблемы и способы их решения. Это дает определенную гарантию того, что при изменениях во внешней среде или на самом предприятии, руководитель сможет принять правильное решение. А система обладает достаточной гибкостью для реализации любого решения в рамках здравого смысла (семантика (смысл) заложена в исходные модели).

MainFrameпредполагается , что в крупном предприятии система будет работать на нескольких севрерах. При этом разные подсистемы на разных серверах. Каким образом реализована интеграция ? Данные реплицируются? или сразу используется непосредственный доступ на другие базы? Когда Вы говорите о распределении нагрузки , что Вы имеете в виду ? распределение по функционалу? т.е. бухгалтеры работают с одним серверов, а кадровики с другим? Что представляет собой клиент- это веб-приложение? Да, каждая подсистема может располагаться на отдельном сервере. В этом основа повышения масштабируемости и надежности системы. Есть специальная подсистема «Интегратор», которая отвечает за поддержание единого информационного пространства предприятия. Каждая подсистема работает, как с уникальной информацией, так и с информацией разделяемой с другими подсистемами. Разделение информации основано на частичной, многосторонней, асинхронной репликации. В системе может быть установлено несколько подсистем одного типа. Добавление новых подсистем, равно, как и удаление существующих, выполняется в штатном режиме без остановки системы. То есть, если на предприятии проходит реструктуризация, то система «КУБ» сохраняет свою актуальность и автоматизирует данный процесс.

MainFrameВозможно ли использование отдельных подсистем, в которые данные будут импортироваться из других. Например, нас интересует только планирование. Можем ли мы импортировать в него необходимые даные из других систем Принципиальных ограничений на выполнение «экспорта/импорта» нет. Что касается «планирования», то здесь могут быть проблемы. Дело в том, что в системе «КУБ» планирование отвечает за полноту и непротиворечивость текущей конфигурации системы. Если внешние данные не отвечают этим требованиям, то они будут отвергнуты. Здесь важно понимание сути планирования, не как отдельного акта/процесса, а как жизненно важного элемента системы. К сожалению, планирование в ERP-системах – одно из самых слабых мест.

MainFrameВы настаиваете на отказе от описания бизнес-процессов. Я не фанатик их описания в любой ситуации. Но в некоторых...лучше на примере. Есть некий сложный процесс, в котором участвуют множество людей, они согласовывают кучу объектов, заявки на объекты возвращаются по множеству раз от субъекта, к субъекту, и в конце, концов из множества согласованных объектов, выполняется расчет некоторой интресующей нас в данный момент сущности. Процесс согласования при этом разнесен по времени. Так как часть объектов согласовываются в мае, следующая порция в сентябре и часть в феврале. Участвуют в согласовании множество отделов и руководителей. Каким образом без описания такого запутанного процесса, можно настроить Вашу систему? Да и почему нужно принципиально не описывать? Описание – не цель, но средство... средство понимания сути. Можно ли гарантировать то, что описания бизнес-процессов передают суть? Или, говоря более формально, есть ли способы верификации описаний бизнес-процессов? Увы... Можно провести аналогию с определениями. Определение любого термина и понятия должно передавать их существо (смысл). Но всегда ли это так? Когда мы работаем с руководителями, то просим их определить смысл основных понятий, таких, как производство, склад, финансы и пр. ... всего одним словом. Если руководитель понимает смысл, то проекцию сделать проекцию смысла на действительность (которая постоянно меняется) для него не составит никаких проблем. Кейнс однажды сказал: «Все глупости в экономике происходят из-за непонимания элементарных вещей». Думаю, что в этом он был прав.

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

MainFrameA_S_U, а по поводу верифкации бп. Вот вопрос - а зачем? если ради системы упарвления качеством, то это нужно скорее собсвенно процессы верифицировать (а нужно ли), а не их описания. Если ради автоматизации .. , то тоже - зачем? Лучшими верификаторами будут пользователи. Зачем рисовать - мне больше понятно - чтобы настроить по нарисованному информационную систему на их автоматизацию. А вот верифицировать зачем ?
Верификация – доказательство правильности. Если не доказано, что данный бизнес-процесс описан правильно, то можно ли его реализовывать в виде кода, инструкций и пр.?

MainFrame"руководитель не опсиывает БП". Ок - а как тогда реализуется их автоматизация?
Посмотрите, например, на модель. Эта модель и автоматизируется. Каждая подсистема имеет свою модель. Модели подсистем строятся на основе того смысла, который у них есть в рамках системы. Модели подсистем также автоматизируются. И т.д. вплоть до рабочих мест.

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

Прошу прощения, забыл определить ссылку.

A_S_U Посмотрите, например, на модель

MainFrame A_S_UВерификация – доказательство правильности. Если не доказано, что данный бизнес-процесс описан правильно, то можно ли его реализовывать в виде кода, инструкций и пр.? ну Вы же реализуете :)) Как и многие другие. Вы можете называть его иначе, не бизнес-процессом, а моделью, это всего лишь вопрос названий , а не семантики. Еще раз повторю, что при внедрении системы «КУБ» бизнес-процессы не описываются и не реализуются (ни теми, кто внедряет, ни разработчиками). «Бизнес-процессы» организуются и изменяются руководством предприятия, исходя из текущих условий. Но модели, заложенные в систему, содержат в себе механизмы верификации и контроля эффективности, которые препятствуют установлению бессмысленной организации работ.
MainFrameВсе правильно. Я так же и вижу эти бизнес-процессы. опять разница скорее связана с терминологией. Можно не рисовать блок схемы, можно не упортреблять словБП, но мрашрута движения и реакции на действия , Вы же все равно определяете Отметьте, что в моем сообщении говорилось только о правилах, но в нем не содержалось никаких описаний «бизнес-процессов».
MainFrameЕще вопрос. А есть ли в Вашей системе понятие - событий и соответсветсвующая им обработка. Т.е. как реализуются асинхронные процессы – слабосвязанные Да. Событийность является одним из важных элементов в организации взаимодействия элементов внутри системы.
MainFrameИ все же - каким образом задаются нестандартные действия в Вашей системе (например, как реакция на утверждающую подпись)? нужен ли при этом разработчик ? Вы смотрите на предприятие, как на «черный ящик», и, наверное, поэтому для Вас так важны «реакции» на непредвиденные обстоятельства или события. Для нас же понятие «нестандартные действия» является нонсенсом. Мы не занимаемся регламентацией деятельности людей или подразделений. В этом нет никакой необходимости.

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

MainFrame A_S_UОтметьте, что в моем сообщении говорилось только о правилах, но в нем не содержалось никаких описаний «бизнес-процессов» Правила - это то русло, по которому течет бизнес-процесс. Но, я человек, равнодущный к слову. Если Вам не нравиться так называть, можно перейти на понятия онтологий (тавтология получилась).
Хорошо, если бизнес-процесс «течет в русле» правил, но это, как раз то, что желательно доказывать, но... чего доказать, увы, нельзя (см. ранее о верификации).

MainFrameКак пользователи (не разработчики) могут описать нестандартное действие. Ведь они должны как минимум задать новые правила (давайте перейдем на удобный Вам язык) Очень трудно отвечать... Давайте попробуем рассуждать в следующей плоскости: а) если некая модель передает смысл (оригинала), то с помощью этого нечто можно передать и любое применение оригинала; б) отход от смысла... не имеет смысла (то есть, абсурден), поэтому ввести новые правила, означает, либо привнесение нового смысла, либо отход от смысла. Но привнесение нового смысла – это качественный переход, изменяющий предназначение (использование ложки для забивания гвоздей).
Для примера. В системе есть инструмент для описания любых технологических процессов. Если в основе этого инструмента лежит семантическая модель графа технологических операций (семантику технологической операции я пока опускаю), то можно допустить, что с помощью этого инструмента можно вполне адекватно описать любой технологический процесс. Мы не указываем пользователям, какие технологические процессы они должны описывать, мы передаем смысл ТП и ТО, и показываем, как с помощью программных средств, входящих в состав системы, можно создать описание ТП данного предприятия. Одна из консультационных фирм, решила примерить это для описания учебного процесса и решила... что это очень удобно (хотя до этого система никем не позиционировалась для применения в учебных курсах). Вот поеду в командировку, будем разбираться... можно ли считать учебный процесс частным случаем технологического процесса.
MainFrameКак они их задают? К примеру, Пользователи купят систему пропуска через турникеты по пластиковым карточкам. У системы с турникетам есть программа, которая сбрасывает все то, что ей передашь по некоторому порту на контролеры турникетов. Но кто-то передать должен и по какому-то правилу. Т.е. нужно сбросить всех тех сотрудников, кто работает (не уволен) и работает в заданном здании - кто должен решить эту проблему? Некие разработчики или Ваша система такова, что позволит это настроить обычному пользователю? В этом примере все просто. Есть планирование, и есть фактическая (учетная) информация по рабочему времени. Как эта информация формируется и попадает в «КУБ» неважно. Если предприятие обратится к нам по вопросу автоматизации ввода информации (непосредственно с турникетов), то мы решим эту проблему. Если на предприятии есть свои разработчики, то они могут сделать эту работу сами.
В самой же системе «КУБ» должна быть полная информация о том, кто работает, уволен, переведен на другую площадку и пр. Но за полноту и своевременность ввода этой информации отвечают пользователи.

MainFrameA_S_U, мой интерес вызван большим уважением, к тем идеям, что Вы пропогандируете, и хочу Вас поблагодарить, Ваш давний спор с Garya несколько месяцев назад натолкнул меня на многие полезные мысли. Cпасибо.
MainFrameИ тем не менее, тогда ожидалось большего от продукута, чем то, что сейчас на сайте выставлено. Хотя больше или меньше, это как посмотртеть. Ожидалось (мной), что это будет инструмент, что там не будут явно выраженных стандартных модулей - управления персоналом, склады, снабжения и т.п. Скорее это будет нечто более абстрактное, из чего можно при необходимости сконстурировать и управления персоналом и снабжения и планирование. Поэтмоу сейчас я пытаюсь стыковать то "мое не понимание", с нынешним результатом. Пока это трудно. Наверное, я, либо плохо изложил свои мысли, либо был неправильно понят. Одним из «страшных зол» современности, я считаю стремление к универсальности. И мне бы не пришло в голову создавать некий «универсальный конструктор». Таких «конструкторов» сейчас достаточно много, многие из «тяжелых» ERP-систем, по сути, и есть такие конструктора. Мы же постарались донести то, что представляет собой любое промышленное предприятие, то есть, передать смысл, заложенный в понятие «промышленное предприятие». Далее мы раскрываем смысл каждого элемента системы (каждой подсистемы), и утверждаем, что просто манипулируя этими подсистемами можно получить адекватные модели любых [промышленных] предприятий. Точно также, в каждой подсистеме, раскрывается смысл каждого элемента, из которого она состоит, и манипулируя этими элементами можно получить любую вариацию подсистемы данного типа. Например, типично в ERP-системах используются разные модели для разных видов производств (поточное, (крупно-, средне-, мелко-)серийное, индивидуальное, проектное, ремонтное). Но в системе «КУБ» можно получить любое из этих производств... силами самих пользователей в рамках выполняемых ими своих прямых обязанностей.
Но возможность «конструирования» не тождественно понятию «универсальности». Скажем в рамках подсистемы производства можно говорить о любом производстве, но только о производстве. А создавать нечто, из чего можно собрать «отдел кадров», «производство», «логистику» или «финансы»... это не ко мне.
MainFrameИ второй момент. Мы сейчас действительно рассматриваем как вариант поиск отдельной подсистемы планирования, связанной с вопросами финансов, мат. ценностней. (Планирование вопросов связанных с учебным процессом мы решаем сами). Такой чтобы в нее сгружать те данные, которые у нас есть в других системах. Вопрос их корректности решаемый. Может быть мы как-нибудь сможем пересечься с Вами (хотя Екатеринбург и далеко, но бывают туда командировки у наших управленцев)? Можно воспользоваться Вашей эл. почтой на сайте ? Да, конечно, можно воспользоваться эл. почтой.

iscrafmСкажите A_S_U, система о которой Вы рассказываете имеет материальное воплощение, или это идеи? Просто по Вашей ссылке никакой информации на этот счет нет. Да, конечно, и не только в нашей стране.
iscrafm A_S_U
Есть планирование, и есть фактическая (учетная) информация по рабочему времени. Как эта информация формируется и попадает в «КУБ» неважно. Если предприятие обратится к нам по вопросу автоматизации ввода информации (непосредственно с турникетов), то мы решим эту проблему. Если на предприятии есть свои разработчики, то они могут сделать эту работу сами.
В самой же системе «КУБ» должна быть полная информация о том, кто работает, уволен, переведен на другую площадку и пр. Но за полноту и своевременность ввода этой информации отвечают пользователи
В итоге возвращаемся к старому доброму программированию индивидуальных задач. И с каждым разом их будет больше и больше. Успехов. Вы надеюсь не отрицаете, что при выпуске нового типа устройств, подключаемых к компьютеру необходимы драйвера? Точно также, для того, чтобы информация поступала в систему от какого-то внешнего устройства (в данном случае с турникета) необходимо соединить ПО турникета с системой. Только и всего, хотя, конечно, это задача индивидуальна в той мере, в какой уникален данный турникет.