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

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

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

Что здесь требует программирования? Процесс заведения формул в системе "КУБ" сделан проще, чем в Excel.

A_S_UЕсли все необходимые товары есть в наличии, то формируются внутренние накладные на те склады, где размещены указанные в товаре заказы. Прошу прощения, должно быть написано: "указанные в заказе товары" :)

Сахават ЮсифовНастраиваемая система должна дать возможность создавать классы, объекты, коллекции, таймеры, модели, симуляторы ... без программирования. ... а еще она должна давать возможность печь пирожки, стирать носки и завязывать шнурки на ботинках... :)

Сахават ЮсифовЯ уважаю чужой труд и Вас не в чем не обвиняю.Хм... Ну, и на том, спасибо :)
Сахават ЮсифовНо концепция кубиков (как говорил MainFrame) обязывет иметь много чего из того, что предложил я и еще кучу вещей и совсем не претендует на реализацию "склад" и т.д. Боюсь, что мы с Вами под "кубиками" понимаем нечто совсем разное... Вы подразумеваете одно, а я совсем другое. Из наших "кубиков" (подсистем) можно собирать предприятия, из "кубиков" (предприятий) можно собирать холдинги и корпорации, а еще из разных видов "кубиков" (предприятий) строить макроэкономические модели регионов, отраслей и ... т.д.
А Вы про какие "кубики" говорите?

Гулин Федор>>Что здесь требует программирования? Процесс заведения формул в системе "КУБ" сделан проще, чем в Excel.

Кто в данном конкретном примере будет писать эту формулу
(пользователь или программист ) ?
кто отвечать за результаты если ошибочно ?
зы если не сложно приведите пример формулы - попроще Формулу будет составлять экономист, он же будет ее тестировать и отвечать за результат. Задача системы состоит в том, чтобы предоставить экономисту возможность получения необходимой исходной информации, и возможность сохранения расчитанной информации.

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