Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Сахават, ну почему все темы превращаются в обсуждение вашей системы? То, что ваша система супер-пупер мы поняли. По существу ИСХОДНОГО вопроса еще что-нибудь будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2005, 16:11 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
mazzyСахават, ну почему все темы превращаются в обсуждение вашей системы? То, что ваша система супер-пупер мы поняли. По существу ИСХОДНОГО вопроса еще что-нибудь будет? 1. Не только Аксаптп нуждается в рекламе. 2. Сообщение по существу. Говорят, что надо управлят изменчивыми БП. А я показываю, что есть и неизменчивые. Как Вы помните у меня классное дерево спецификаций и многовариантные технологии, но Заказчик заплатил за жесткий, привязанный БП. Почему меня не любят дефочки?! (С) Паниковский ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2005, 16:17 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
процКруто: производство - это не бизнес. Так бы сразу и сказали, что все ваши глубокомысленные рассуждения относятся только к торговле (якобы) и вопросов к вам бы не было.Ну-ну, не утрируйте, плз. Производство ради производства - это не бизнес. Это склады, забитые готовой продукцией, Это рабочие на "трехдневке" и зарплата раз в три-четыре месяца:( Это мы проходили, знаем. Про то, что заказчику нужны не дрели, а дырки читали? процПро ТПП вы наверное никогда не слышалиСлыхивали. Если Вы говорите о технологической подготовке производства. И производство это самое видывали. И ERP ставили, и на все /ш наступали. Только какое отношение это к теме имеет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2005, 16:22 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов1. ***** 2. Сообщение по существу. Говорят, что надо управлят изменчивыми БП. А я показываю, что есть и неизменчивые. Как Вы помните у меня классное дерево спецификаций и многовариантные технологии, но Заказчик заплатил за жесткий, привязанный БП. Почему меня не любят дефочки?! (С) Паниковский ?! Сахават, у вас есть своя ветка http://sql.ru/forum/actualthread.aspx?tid=170432 Пожалуйста, не забивайте эфир везде, куда дотянетесь. Дайте послушать, что другие говорят. Пожалуйста. Пожалуйста, вернемся к теме? Garya, я например хотел бы продолжить читать развернувшуюся дискуссию про бизнес-процессы и подходы по их отображению в различных системах, а не очередной топик про программу уважаемого Сахавата. Garya, не буду вмешиваться в эту тему. Делай как сам считаешь нужным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2005, 23:40 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Добрый день, уважаемые коллеги! Огромное спасибо за данную тему и обсуждения её! Очень интересно (читал и вникал 3 дня). Согласен со многими мыслями. Но особо всё-таки хотел отметить инженера - я полностью его понимаю и согласен с тем, что в комплексе про MBP очень мало было сказано Абсолютно с таким же видением, как у него, пришёл на этот форум. Извиняюсь за то что не по существу - не удержался просто ... Щас готовлю вопросы и мысли по существу :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 07:53 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
извиняюсь - "BPM" ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 07:59 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
1. Бизнес - процессы существовали всегда, на любом предприятии, только подходы к автоматизации деятельности предприятий (учёт логики, учёт данных и мета-данных, и учёт истории действий над объектами учёта) были разные. 2. Мне пока подход BPM автоматизации на предприятии представляется лишь надстройкой (необязательно внешней) над ERP, CRM, бухг. и др. учётными и информационными системами. При том, что главный плюс в BPM'е, который я выделяю - это стандартизация. 3. Принципы BPM применяются уже давным давно во всех системах, только разрозненными, часто не до конца автоматизированными, методами . 4. Я бы назвал BPM - вынос логики и связей на ещё более высокий уровень программирования. 5. Всё, что предлагает BPM можно реализовать (или уже реализованно) в любой системе / системах, только более трудоёмкими способами. Скажем, это обобщение опыта человечества в написании сложных комплексных систем и предложение по подходу к их написанию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:34 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Теперь, к нашим баранам - сразу оговорюсь, будет пока сумбурно ... Пример - торговля. Бизнес-цель деятельности торговой фирмы - предоставить услуги и выполнить работы по доставке товара клиенту. Рассмотрим самый простой вариант уже выполненного бизнес - процесса: фирма доставила один товар клиенту под заказ. Алгоритм выполнения операций (бизнес-шагов или простейших бизнес-операций) в разрезе BPM подхода: 1. Оформление клиентом заказа на товар 2. Выписать счёт клиенту 3. Принять деньги от клиента 4. Заказать товар у поставщика 5. Оплатить поставщику за товар 6. Отгрузить товар со склада поставщика 7. Транспортировать товар до транзитного склада 8. Принять товар на транзитный склад 9. Отгрузить товар с транзитного склада 10. Доставить (транспортировать) клиенту товар 11. Оплатить транспортной компании ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:37 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Теперь, как вариант, есть (внутри корпоративной системы) следущие (учётные или функциональные) под-системы (чёрные ящики) : 1. Учёт документов 1.1. Учёт договоров (договора с поставщиками, транспортными компаниями, клиентами и прочее). Здесь хранятся в каком-нить виде условия договора и, тарифы, к примеру, настройки всевозможные и прочее. 1.2. Финансовый учёт (Счета, платёжки, выписка ...) 1.3. Учёт заказов (заказы поставщику, заказы клиентов) 1.4. Складской учёт (товарные накладные, фактуры, счета-фактуры и прочее) 1.5. Логистический учёт (учёт движений товаров, схемы движений, настройки и прочее) 2. Учёт товаров и услуг 2.1. Прайс - лист поставщиков (чужие) 2.2. Товары "в движении" (свои) 3. Бухгалтерский учёт (проводки, счета, планы счетов и прочее) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:42 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Теперь, как автоматизация деятельности происходила бы в классической корпоративной системе : 1. Нет чёрных ящиков и каждая под-система должна знать друг о друге => это выливается просто в заполнении и хранении ссылок в структурах под-систем друг на друга, к примеру : "Оплата" должна знать на прямую, что это было за "Счёт", который должен знать напрямую, что он выписан по заказу (З1), за товар (Т1). Заказ <-> Товар Счёт <-> Заказ <-> Товар Оплата <-> Счёт <-> Заказ <-> Товар ... 2. Логика будет размазанной - то есть операция "оплата за выписанный счёт по заказу за товар" скорее всего будет лежать в под-системе "Финансовый учёт", где есть и другие виды операций по оплатам, не относящиеся к заказам клиента, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:44 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Что предлагает BPM, на мой взгляд : Просто прочертить границу в а) хранении данных и б) хранении логики то есть все данные и логику сделать "private". "Public" - сделать только логику (или данные в худшем случае), которая бы выполняла : а) заполнение "privаte" данных своей под-системы б) выдача "private" данных для работы других (чужих) под-систем. Какие данные необходимы для чужих систем и знает только надстройка BPM в разрезе бизнес - операций. BPM <-> Заказ BPM <-> Товар BPM <-> Счёт BPM <-> Оплата ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:46 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
проц... производство - это не бизнес Клятых буржуинов еще не упомянули... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 09:55 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
То есть по моим ощущениям, BPM выделили в системе ещё одну общность - операции (действия над объектами) и поставили её в центр всей системы обеспечения автоматизации (не важно - или комплекса систем, важно, что в центре). И сказали, что операции (не суть важно - бизнес или не бизнес - операции ... :-) ) могут обладать общими свойствами (напр. - стоимость, временнАя стоимость, риски, вх. и вых. данные + вх. и вых. логика + шлюзы (способы получения) и прочее), взаимосвязями друг с другом (бизнес операция-1 БП1 связана с БП2 параллельной, жёсткой или не жёсткой связью), логикой связи (условная связь, и прочее. Далее, чтобы не зашивать всё в код - вынесли связи и настройки в схему бизнес - процесса (наподобие справочника). Далее, когда выполняется сам процесс, снабдили механизмами задач и персональной маршрутизации, которые опираются опять же на схему и мета-логику схемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 10:09 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
То, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. Хотя , понятно, BPMS и не для этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 10:49 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
MainframeТо, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. "Сон про не сон и про не сон сон" (C). Вы что хотели сказать-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 11:16 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
MainframeТо, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. Хотя , понятно, BPMS и не для этого. А и не помогут никакие настройки и язык диспетчирования. Все это уже было. Объекты сами должны договариватся, подписываясь на услуги чужих и публикую свои, отслеживая чужие и публикую свои события и состоянии. Никто не мешает создать вспомогательные объекты по агрегации и маршрутизации, по протоколированию и т.д.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 11:26 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Vitaly2000Бизнес - процессы существовали всегда, на любом предприятии, только подходы к автоматизации деятельности предприятий (учёт логики, учёт данных и мета-данных, и учёт истории действий над объектами учёта) были разные. Это чересчур расширительное толкование, под него можно подвести все что угодно. Vitaly2000Мне пока подход BPM автоматизации на предприятии представляется лишь надстройкой (необязательно внешней) над ERP, CRM, бухг. и др. учётными и информационными системами Иными словами, ERP, CRM и прочие -- это прикладной, а BPMS и DBMS -- системный софт. Vitaly2000Я бы назвал BPM - вынос логики и связей на ещё более высокий уровень программирования. Взгляд, имеющий под собой основание. Опять-таки, просматривается аналогия с DBMS -- там было отделение логики данных от бизнес-логики. Vitaly2000Всё, что предлагает BPM можно реализовать (или уже реализованно) в любой системе / системах, только более трудоёмкими способами. Скажем, это обобщение опыта человечества в написании сложных комплексных систем и предложение по подходу к их написанию. Можно было бы согласиться, если ограничиться рассмотрением статической картинки. Но в динамике -- в ситуации меняющихся требований и бизнес-правил -- BPM дает новое качество. "Только более трудоемкие способы" -- в действительности это пропасть, отделяющая реализуемое от недостижимого. Vitaly2000Пример - торговля. Бизнес-цель деятельности торговой фирмы - предоставить услуги и выполнить работы по доставке товара клиенту. Рассмотрим самый простой вариант уже выполненного бизнес - процесса: фирма доставила один товар клиенту под заказ. Рассматривая нарочито простой вариант, легко выплеснуть вместе с водой ребенка: в рамках такого примера непонятно, чем не устраивает "просто хорошая ERP-система" и зачем изобретать еще одно трехбуквенное сокращение (позиция инженера планового отдела). На самом же деле качество и всякие хитрые особенности этого бизнес-процесса -- это вопрос жизни и смерти компании. Будешь поступать тупо и незамысловато, просто и "как все" -- будешь едва концы с концами сводить и в конце концов будешь бит либо глобальной торговой сетью, либо энергичным конкурентом из твоего же города. Изобретешь свой собственный бизнес-процесс, достоинства которого смогут оценить твои клиенты -- получишь шанс стать живой легендой типа Wall-Mart. И тут подстерегает развилка: можно попытаться внедрить новый бизнес-процесс в стиле реинжиниринга бизнес-процессов (по-американски, по Хаммеру, в общем большим скачком), а можно в стиле BPM (или по-японски) -- сначала взять его под контроль и довести его до идеала где радикальными усовершенствованиями, а где и тонкой доводкой. Причем и то, и другое можно делать вообще безо всякого специального софта (не только в теории, есть примеры и в жизни). Поэтому я призываю быть поаккуратнее с терминологией: BPM -- это не софт, а управленческая методология. BPMS, или BPM-система -- вот это софт, со своими интересными айтишникам (но не бизнесменам) заморочками, который эту методологию поддерживает, примерно так же, как бухгалтерская программа поддерживает двойную запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 11:43 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
АБ MainframeТо, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. "Сон про не сон и про не сон сон" (C). Вы что хотели сказать-то? Как всегда хочется серебряной пули. Проблема в том, что BPMS решают некоторую задачу сопровождения сложных систем - в смысле маршрутизации сообщений. Но оставляют за кадром другие проблемы той же сложной области - сопровождения сложных систем. Это не в укор BPMS. Это в том направлении, что проблем дальше еще больше. Что больное место сопровождения не торлько связь и маршрутизация, но и собственно внутренность тех узловых мест, которые BPMS связывают. Они тоже меняются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 12:15 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Причем решать эту прроблему, предпочтительней не внутри каждой системы, а тоже как бы сверху. Т.е. единым подходом пройтись по разным системам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 12:18 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Объекты сами должны договариватся, подписываясь на услуги чужих и публикую свои, отслеживая чужие и публикую свои события и состоянии. точно, именно так и построены нормальные диспетчеры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 12:25 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов MainframeТо, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. Хотя , понятно, BPMS и не для этого. А и не помогут никакие настройки и язык диспетчирования. Все это уже было. Объекты сами должны договариватся, подписываясь на услуги чужих и публикую свои, отслеживая чужие и публикую свои события и состоянии. Никто не мешает создать вспомогательные объекты по агрегации и маршрутизации, по протоколированию и т.д.. Да? а я как раз и рассматриваю BPM : 1) как объекты BPM в которых хранятся настройки (скажем перспектива) 2) как интерфейсы, позволяющие совершить операцию в данный момент времени 3) так и запись этих действий (ретроспектива) - экземпляры объектов BPM было бы глупо не писать следы действий ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 12:38 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Vitaly2000 Сахават ЮсифовА и не помогут никакие настройки и язык диспетчирования. Все это уже было. Объекты сами должны договариватся, подписываясь на услуги чужих и публикую свои, отслеживая чужие и публикую свои события и состоянии. Никто не мешает создать вспомогательные объекты по агрегации и маршрутизации, по протоколированию и т.д.. Да? а я как раз и рассматриваю BPM : 1) как объекты BPM в которых хранятся настройки (скажем перспектива) 2) как интерфейсы, позволяющие совершить операцию в данный момент времени 3) так и запись этих действий (ретроспектива) - экземпляры объектов BPM было бы глупо не писать следы действий ...И Вы правы. Возможно Сахават Юсифов имеет в виду свою собственную BPM-систему, но есть и вполне нормальные решения, которые обсуждались и в этом разделе форума, в том числе. Давайте вернемся к тому набору компонент, из которого состоит всякая, уважающая себя:) BPM-система: 1. средства проектирования (графический дизайнер, хранилище данных) 2. движок, который запускает экземпляры процессов и следит за их исполнением 3. средства мониторинга. Схема, нарисованная в дизайнере, сохраняется в репозитории, после чего она может исполняться (т.е. стартуются процессы, их экземпляры сохраняются и их можно контролировать, анализировать, просто любоваться). Кроме того, схему можно (даже нужно) изменить, доработать при помощи того же графического дизайнера. После этого следующие экземпляры процессов будут вести себя по вновь описанным правилам. Такой подход к управлению бизнес-процессами позволяет легче пережить момент внедрения (потому что автоматизирует процесс как есть). После анализа и выявления слабых мест, схема дорабатывается, не нанося никакого ущерба уже работающим процессам. Для интеграции с существующими приложениями кое-какие усилия приложить все же придется, но навряд ли Вы меняете свои приложения так кардинально раз в неделю, чтобы система этого не пережила. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 13:18 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Vitaly2000 Сахават Юсифов MainframeТо, чего , как мне кажется не хватает в BPMS , это настроек на изменения внутренности БП, или точнее может быть даже не самого процесса, а объектов процесса, но как следствие и самого БП. Хотя , понятно, BPMS и не для этого. А и не помогут никакие настройки и язык диспетчирования. Все это уже было. Объекты сами должны договариватся, подписываясь на услуги чужих и публикую свои, отслеживая чужие и публикую свои события и состоянии. Никто не мешает создать вспомогательные объекты по агрегации и маршрутизации, по протоколированию и т.д.. Да? а я как раз и рассматриваю BPM : 1) как объекты BPM в которых хранятся настройки (скажем перспектива) 2) как интерфейсы, позволяющие совершить операцию в данный момент времени 3) так и запись этих действий (ретроспектива) - экземпляры объектов BPM было бы глупо не писать следы действий ... А в чем новизна - то? Что это дает кроме доп. усилий для сомнительной интеграции? Чем не устраивают всякие shedulerы + messengerы + хотя бы те же bat,cmd? Другое дело - хранилось бы граф маршрутов, были бы определены интерфейсы вершин и регистрация изменения состояний вершин с генерацие событий для смежных вершин. А реализация интерфейсов было бы отдана на откуп местным или привлеченным программерам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 13:28 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовНЕ ЗЛОУПОТРЕБЛЯЙТЕ ОВЕРКВОТИНГОМ отредактировано модератором А в чем новизна - то? Что это дает кроме доп. усилий для сомнительной интеграции? Чем не устраивают всякие shedulerы + messengerы + хотя бы те же bat,cmd? Другое дело - хранилось бы граф маршрутов, были бы определены интерфейсы вершин и регистрация изменения состояний вершин с генерацие событий для смежных вершин. А реализация интерфейсов было бы отдана на откуп местным или привлеченным программерам. хм... я об этом и говорю ... правда немного наверное коряво ... но полностью то что ты сказал - я так себе и представляю BPM ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 13:40 |
|
||
|
Процессный подход - замена функциональной вертикали. Какие трудности и ошибки?
|
|||
|---|---|---|---|
|
#18+
И ещё скажу одну вещь - BPM, если рассматривать как подход к написанию системы автоматизации деятельности предприятия, должен быть внедрён везде, на всех уровнях системы. То бишь, есть узлы, которые смотрят друг на друга на одном уровне и в классическом подходе должны напрямую быть увязанными, а в BPM - через BPM-операции, например так: ОПЕРАЦИЯ-А { ОПЕРАЦИЯ-А1[заказ] -> ОПЕРАЦИЯ-А2[счёт] -> ОПЕРАЦИЯ-А3[оплата] -> ОПЕРАЦИЯ-А4[транспортировка] } Идём дальше, например : ОПЕРАЦИЯ-А2[счёт] { ОПЕРАЦИЯ-А21[выписка счёта за заказ] -> ОПЕРАЦИЯ-А22[подтверждение счёта] -> ОПЕРАЦИЯ-А23[отправка клиенту] } Идём дальше, например : ОПЕРАЦИЯ-А21 [выписка счёта за заказ] { ОПЕР-А211[выбор заказа] -> ОПЕР-А212[внесение клиента] -> ОПЕР-А213[заполнение реквизитов счёта] } Таким образом, в ОПЕРАЦИЯ-А21 [выписка счёта] , задействуются допустим 2 под-системы: Заказы и Счета, которые друг о друге ничего не знають. А вот операция А-21 знает и о тех и о других. Вопрос как она будет их знать (связывать) ? Обращением к предыдущей операции "ОПЕРАЦИЯ-А1[заказ]" или через хранимую в верхней операции ОПЕРАЦИЯ-А ссылку на заказ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2005, 13:52 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=33458734&tid=1528186]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
92ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 268ms |
| total: | 487ms |

| 0 / 0 |
