ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Есть ли будущее у систем интеграции ?
25 сообщений из 358, страница 11 из 15
  11  все
Есть ли будущее у систем интеграции ?
    #33581276
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GaryaПривилегированный пользователь
Участник
...починяю примусНа выходе из клиент-банка каждый входящий документ - это абстрактная платежка неизвестного назначения.Давайте уточним, о какой платежке идет речь. О платежке стороннего юрика/физика "нам", если я правильно понял? Если она инициируется сторонним лицом, то действительно платежка изначально "неизвестного назначения".

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

1. Работник бухгалтерии получил по электронной почте XML-документ, который открывает с помощью InfoPath, видит в нем уже заполненные системой клиент-банк реквизиты (вроде "назначения платежа", "плательщик", номер платежки", "дата платежки" и т.д.)... Но! КРОМЕ этих полей бухгалтер видит еще и дополнительные поля, которых изначально в платежке не было, в частности "Дебет" и "Кредит" (выпадающие списки), которые он должен ЗАПОЛНИТЬ , выполняя работу по "классификации платежа". Поля эти появились в результате уже отработавшего на пути из системы клиент-банк в бухгалтерию XSLT-преобразования. После заполнения необходимых реквизитов работник бухгалтерии нажимает кнопку "Готово", при этом InfoPath контролирует корректность заполнения всех реквизитов и отправляет информацию дальше по траектории бизнес-процесса. А дальше она сама попадает в бухгалтерскую программу как целиком готовые проводки, параллельно отправляется в систему управленческого учета (например), где регистрируется только та информация, которая нужна именно на этом участке, и дополняется той информацией, которой именно на этом участке должна дополнится. Если бухгалтер, например, заболел, платежки не обрабатываются в течении отведенного для этого периода времени, BPMS шлет сообщение "Караул!" главбуху или другому "аварийному" бухгалтеру, который должен будет срочно (на протяжении короткого таймаута) выполнить ту же работу за основного бухгалтера, после чего бизнес-процесс опять пойдет ранее проторенными тропами.

2. Бухгалтерская программа поддерживает работу с "заготовками проводок". Из системы "клиент-банк" информация о платежке проходит от системы клиент-банк через BizTalk минуя бухгалтера напрямую в бухгалтерскую программу в виде "заготовки проводки" с наиболее вероятной корреспонденцией и заполненными остальными реквизитами. Далее BizTalk с заданной периодичностью опрашивает (сканирует) данные бухгалтерской программы, ожидая, что в течение отведенного времени бухгалтер "квалифицирует" платежку и превратит заготовку проводки в настоящую проводку. Либо не сканирует, а ждет, когда триггер, например, пришлет ему сообщение о том, что заготовка проводки бухгалтером обработана. Если в течение заданного времени BizTalk не получает сигнал о "квалификации" платежки, он кричит "Караул!" главному бухгалтеру или отрпавляет сообщение "аварийному" бухгалтеру с требованием срочно обработать заготовки проводок. После получения полной информации по уже сделанной проводке BizTalk может загнать выбранную часть из нее, например, в систему оперативного учета или отправить в специализированное подразделение.

3. Бухгалтерская программа НЕ может делать "заготовок" проводок, бухгалтер НЕ знает, что такое InfoPath. Он просто тупо ждет оригинал банковского документа, который ему должен принести операционист. И когда он его получит, он руками вколачивает наблюдаемую на бумажном документе информацию в бухгалтерскую программу, по дороге "квалифицируя" платежку. Ушлый BizTalk :) тем временем хранит в своих недрах информацию о платежке из системы клиент-банк (длинная транзакция-то запущена...) и с заданной периодичностью сканирует содержимое бухгалтерской программы, дабы обнаружить в ней проводки, связанные с поступившей в него информацией из системы банк-клиент. Если он в течение заданного времени не обнаруживает в бухгалтерской программе ожидаемых им проводок, он кричит "Караул!" бухгалтеру, который должен был их сделать, главбуху и, возможно, шефповару (чтобы бухгалтера за несвоевременно выполненную работу лишили бесплатного обеда :) ). Если же он обнаруживает соответствующую проводку, он выбирает из исходной платежки и из сделанной проводки некоторый нужный другому подразделению конгломерат информации и отправляет ее в это подразделение.

Я себе представляю, что наше с Вами недопонимание было связано с тем, что момент доступности информации для бизнес-подразделений предприятия Вы связывали с помещением этой информации в некую единую базу данных, причем в таком виде, когда она уже полностью "расписана" и дальнейшему уточнению не подлежит. В BPMS же системе информация не находится в централизованном хранилище. Она "размазана", продублирована, представлена в разных ракурсах во множестве разных мест разными способами.
...
Рейтинг: 0 / 0
03.03.2006, 19:22
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33581534
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
Garya ...починяю примусНа выходе из клиент-банка каждый входящий документ - это абстрактная платежка неизвестного назначения.Давайте уточним, о какой платежке идет речь. О платежке стороннего юрика/физика "нам", если я правильно понял? Если она инициируется сторонним лицом, то действительно платежка изначально "неизвестного назначения".

Да, это платежка "извне" "нам". Я указал, что это входящая платежка.
Но, кроме того, что это может быть платеж, связанный с нашей основной деятельностью, это может быть:
- платеж по непрофильной деятельности предприятия;
- возвратный платеж связанный с хозяйственной деятельностью предприятия (инициированный не клиентом);
- возвратный платеж из бюджета (возврат НДС к примеру);
- и тыр и пыр...
Суть этих платежей - за пределы бухгалтерии они не выйдут и на бизнес-процесс никак не повлияют. Хотя разносить их бухгалтерия будет вручную. Однако, основную массу составляют все-таки клиентские платежи (если еще не забыли - мы имеем неколько тысяч клиентов). Рассмотрим, что будет с ними - причем не предполагаемые варианты, а как это делается в реальности:
- На основании Дебетовой стороны платежки программа бухучета, куда попадет пакет данных из клиент-банка, осуществит привязку платежа к конкретному клиенту и попытается на основании суммы связать так-же и с выставленным ранее счетом;
- если документ "привязался" - это позволяет проставить ему корреспонденцию счетов баланса;
- все "непривязавшиеся" платежи корреспондируют на счет "до выяснения" по умолчанию;
- сформированные пакеты документов на проводку сохраняются в бухгалтерской программе без проводки по счетам , каждый пакет (в банке это называют "пачка") сопровождает ся контрольной суммой входящих в пачку документов;
- после потверждения бухгалтером (в процессе проверки бухгалтер может менять привязку) осуществляется проводка документов, тут можно контролировать совпадение сумм на выходе из клиент-банка и разнесенных контрольных сумм;
- при проведении документа на основании внутренней корреспонденции счетов выделются те документы, которые необходимо передавать за пределы бухгалтерии;

Garya
Вы утверждаете, что "классифицировать" платежку должна бухгалтерия. Однако, классифицировать ДЛЯ ЧЕГО ? Для того, чтобы решить свои локальные задачи .

Видите, как минимум одна задача - определение в общем потоке клиентских платежей и их "привязка" - локальной не является.
Такой метод обработки позволяет минимизировать затраты времени на "разнесение" платежей. А если поступать по одному из Ваших сценариев - бухгалтеров на предприятии будет больше, чем инженерного персонала...
Ни одно из перечисленных действий пока никак не отразилось в схеме бизнес-процесса. Почему ? Сейчас мы и переходим к этому вопросу.
Garya
Вот оно!!! Выявлены корни различия точек зрения! Кажется, мы начинаем переходить на один язык. :)

И тут, боюсь, мы разойдемся окончательно... :(
Поскольку наши взгляды на понятие бизнес-процесса не совпадают радикально. Вы относите туда буквально все , любое шевеление, любую активность на предприятии. Я Вам предлагаю другой взгляд - разделить все информацию имеющую обращение на предприятии на "бизнес" и "технологическую". Причем "бизнес" информация будет пересекаться с информацией "технологической". Вам такое деление кажется субъективным ? А деление персонала на управляющий, технический и вспомогательный Вам таковым не кажется ? А разделение методов анализа на бизнес-анализ, функциональный анализ, системный анализ ?
Еще раз обращаю Ваше внимание (эту трактовку я уже предлагал выше) - в область видимости бизнес-анализа попадает информация требующая:
- принятия решения;
- мониторинга;
Информация может быть одновременно и "бизнес" и "технологической" - установкой соотвествующего признака будут заниматься соотвествующие специалисты независмо друг от друга - т.е., например, бизнес-аналитик работая над моделью бизнес-процесса сам определит - какие данные отметить как "бизнес", из какой точки ИС их забрать и с какой целью.
И, я прошу Вас тщательно обдумать следующий вывод, вот что мы получаем в результате такого деления:
- Разделив на независимые действия обработку бизнес-процесса и действия по обмену информацией мы получаем возможность предельно гибкого анализа и мониторинга бизнес-процесса, т.е. по мере надобности мы можем менять степень декомпозиции какого-либо из участков, например, включив, на какое-то время, мониторинг прохождения отдельных документов внутри бухгалтериии и так-же свободно его(мониторинг) выключить - не затрагивая собственно обмена информацией внутри ИС предприятия .
При этом рассматриваемый "центр интеграции" в архитектурной иерархии ИС предприятия окажется на более низком уровне чем BPMS. Он, центр, становится основным поставщиком структурированной (формализованной) информации для BPMS. И, в то-же время, ничто не мешает нам использовать возможности BPMS в части обработки слабоструктурированной и неформализованной информации, обработки взаимодействий human-human и прочих событий, не попадающих в подмножество "технологической" информации.

Такая вот у нас получается "разница восприятия воображаемых различий"...
...
Рейтинг: 0 / 0
03.03.2006, 23:40
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33581738
инженер планового отдела
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
инженер планового отдела
Гость
Мне кажется, что починяющий примус заблуждается в рассуждениях о платежках (хоть туда, хоть обратно). Все упрощает известная реализация: все деньги платятся только поставщикам услуг (в том числе и государству, предотвращающему бомбардировку нашего предприятия вражескими самолетами), и все деньги приходят только от покупателей наших услуг (плюс, естественно, возвраты). И все это - "бизнес", хотите Вы этого или нет. А уж "бухгалтерия" будет "разносить" или какая-то другая "структура" - какое это имеет значение ?
...
Рейтинг: 0 / 0
04.03.2006, 11:50
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33581744
инженер планового отдела
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
инженер планового отдела
Гость
То есть я хотел сказать что никакого будущего у систем интеграции (между несколькими системами данного предприятия) нет. А вот "интеграционные серверы контроля использования разделяемых расурсов" (например, транспортных единиц) - это интересное направление.
...
Рейтинг: 0 / 0
04.03.2006, 11:58
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33581788
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
инженер планового отделаТо есть я хотел сказать...
Платежи - маленький частный случай обширной задачи интеграции данных в масштабах КИС. Выносить на их, платежей, основе некий "вердикт" - демонстрировать полное непонимание проблемы.

отредактировано модератором
...
Рейтинг: 0 / 0
04.03.2006, 13:06
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582673
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
proposed amendment
Участник
Tov. DrujbaА насчет темы - ОК. Смотрим в будущее. И как, есть оно? Вы то еще не высказались по теме ;)

воскресным вечером позволю себе высказаться по такой совершенно оффтопной теме...

безусловно есть
безусловно такое
безусловно только такое будущее и есть...

несколько странно видеть такую постановку вопроса...

такова природа вещей, если смотреть на них широко и философски...
к этому сводится вся история цивилизации

время разбрасывать камни и время собирать камни
время изобретать и время интегрировать изобретения
время искать в дальних странствиях и время обретать у себя под носом...



процессы интеграции - это аккумулирование и обретение в практике огромных платсов накопленного опыта...

на этом пути отбрасывается избыточное, проводится переоценка качеств, адаптируются к шировкой практике частные решения...

я уверен, что так и будет дальше...
если тысячелетиями так было, почему завтра должно стать иначе?


субуго ИМХО
...
Рейтинг: 0 / 0
05.03.2006, 20:48
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582697
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
Извините что вмешиваюсь в вашу дискуссию, коллеги, но для того чтобы о чем-то договориться, для начала полезно определить о каких конкретно бизнес-процессах идет речь в рассматриваемом примере. Давайте на время отвлечемся от наличия/отсутствия BPM и "Бизтолкового сервера" и просто их сосчитаем:

1) Бизнес-процесс поставки наших услуг клиенту. Обычно такой процесс начинается с того, что клиент у нас что-то заказывает, но в данном случае, если я правильно понимаю, услуга предоставляется клиенту на регулярной основе (ежемесячно). Принципиально это, однако, ничего не меняет. Просто бизнес-процесс инициируется не вводимой вручную заявкой клиента, а автоматической процедурой на основе данных из базы взаимоотношений с клиентами. Так или иначе, фиксируется факт: мы начали (или собираемся начать) предоставлять услугу клиенту. Заканчиваться такой бизнес-процесс либо тем, что мы получили деньги от клиента и закрыли сделку, либо (для полноты картины) денег мы не получили, а понесенные затраты списали в убытки.

2..N) У нас имеется еще N-1 бизнес-процессов, по которым мы продаем какие-то другие товары-услуги или те же, но другим способом, по другим каналам, другим клиентам.

N+1) Бизнес-процесс оплаты, начинающийся с получения выписки банка. Опять-таки, если выписка пришла через банк клиент, разумно стартовать его автоматически; при более традиционном способе работы его может стартовать вручную сотрудник финотдела. Но даже наличие клиент-банка полностью не избавляет от ручной работы.

Теперь рассмотрим как эти бизнес-процессы друг с другом взаимодействуют. Бизнесы-процессы 1..N запускаются, доходят до шага "ожидания оплаты" и впадают в спячку, которая может прерваться либо поступлением платежа, либо таймером. Бизнесы-процессы N+1 запускаются, доходят до шага "разноска по сделкам", и на этом шаге идентифицируют экземпляр бизнес-процесса 1..N и шлют ему сигнал "оплата произведена". После чего бизнес-процессы 1..N благополучно отрабатывают до конца. (Можно еще себе представить бизнес-процесс N+2 "выбивание долгов", который запускается бизнес-процессом 1, когда денег мы не получили.)

Бизнес-процессы 1..N -- это "бизнес-процессы с большой буквы". В литературе по BPM часто употребляется термин "end-to-end business process", который мне кажется очень правильным, но для которого у меня нет хорошего перевода. Бизнес-процессы N+1,N+2 от них отличаются -- они не составляют цельную, а являются фрагментом end-to-end цепочки. Выделяем эти фрагменты в отдельные бизнес-процессы просто их технологических соображений, поскольку они одинаковы для всех бизнес-процессов 1..N. Я обычно такие фрагменты называю "подпроцессами", чтобы отличать их от "полноценных" бизнес-процессов. Можно назвать их "технологическими" или "служебными".

Теперь вернемся к BPM, SOA и прочим "нехорошим излишествам". Если рассматривать только бизнес-процессы 1 и N+1, то их запросто можно реализовать в рамках одной системы, вколотив в коды схему и логику процесса. С другой стороны, вполне может сложиться так, что систем у нас оказалось больше одной: например, для бухгалтерии мы используем стандартную, а для тарификации и ведения отношений с клиентом в специфической отрасли разработали свою. Еще у нас есть бизнес-процессы 2..N, которые могут быть вообще неавтоматизированы.

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

С учетом этих обстоятельств, BPM и SOA могут оказаться эффективными средствами. Как именно их лучше применить -- надо смотреть. Например, можно оставить бизнес-процесс N+1 жить внутри бухгалтерской системы, дописав программу, которая будет находить нужный экземпляр бизнес-процессов 1..N по атрибутам поступившей платежки и слать ему сигнал через вебсервис. Можно поступить наоборот -- загнать бизнес-процесс N+1 тоже вовнутрь BPM, а бухгалтерскую систему сделать сервисом, к которому он будет обращаться. BPEL заточен именно на такие задачи пересылки сигналов между экземплярами бизнес-процессов.

И когда будете выбирать оптимальное решение, учтите: BPM мы сюда тащим (ОК, я тащу) не из-за моды, а: 1) Для того чтобы интегрировать системы и людей на основе технологии "правильной" по своим идеям и к тому же технологии мейнстримовой, поддерживаемой сегодня всеми вендорами. 2) Чтобы дать бизнесу свободу -- свободу разработать и применить бизнес-процесс потребительского кредитования или улаживания отношений с неплательщиками, свободу встраивания таймеров, эскалации проблем и прочего реагирования на нештатные ситуации бизнес-процесса. И еще свободу от менеджеров -- владельцев сокровенного знания, но это уже отдельная тема.

Если упустить из виду "живой", изменчивый характер любого бизнеса и рассматривать задачу автоматизации статичной схемы, то преимущества BPM/SOA легко потерять из виду. Впрочем, об этом тут уже кажется говорилось :)
...
Рейтинг: 0 / 0
05.03.2006, 21:24
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582704
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
proposed amendmentвремя разбрасывать камни и время собирать камни
время изобретать и время интегрировать изобретения
время искать в дальних странствиях и время обретать у себя под носом...
...
я уверен, что так и будет дальше...
если тысячелетиями так было, почему завтра должно стать иначе? Дык то что эти тенденции сменяются -- это не вопрос. Вопрос-то в том, какое сейчас время -- время собирать камни или разбрасывать? Философия ответа на него не дает :)

В переводе на ИТ-жаргон собиранию камней соответствует подход "single vendor", а разбрасыванию -- "best of breed". В 90-е доминировал первый: во-первых потому что на концепцию ERP возлагались большие надежды, а во-вторых потому, что технологии интеграции были не сильно эффективными. Сейчас, на мой взгляд, и в том, и в другом произошли существенные изменения, и маятник качнулся в другую сторону.
...
Рейтинг: 0 / 0
05.03.2006, 21:30
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582757
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
АБТеперь рассмотрим как эти бизнес-процессы друг с другом взаимодействуют. Бизнесы-процессы 1..N запускаются, доходят до шага "ожидания оплаты" и впадают в спячку, которая может прерваться либо поступлением платежа, либо таймером.

Очень часто - не возникает состояния "ожидания оплаты", даже на начальном этапе после подписания договора могут начинаться уже "телодвижения" по подключнию и началу предоставления услуг. Особенно - когда, по каким-либо соображениям, отсуствует начальный платеж(плата за подключение или что-то аналогичное). Такая ситуация - не редкость и не экзотика.

АБ
нам достаточно будет чтобы клиент дал номер карточки, и мы будем забирать деньги с его счета сами.

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

Но это все лирика. Я на что хочу обратить, еще раз, внимание участников диспута: на приципиальный, с моей точки зрения, момент разделения (насколько это окажется возможным) задач интеграции данных(приложений, сервисов) и управления безнес-процессами предприятия.
Возможно, это выглядит противоречащим самой идее процессного управления. Но, посмотрите, что мы, в этом случае, получаем:
- интеграция осуществляется самостоятельной задачей с использованием любых доступных способов (от файлов до сервисов) при этом собственно "центр интеграции" аккамулирует всю информацию о процессах взаимодействия внутри предприятия, плюс информация из собственно прикладных систем - всяческие журналы изменений вести не вчера научились;
- BPMS, не обремененная обеспечением интеграционных задач, служит именно для отображения хода процессов и представления полученной из прикладных систем (включая интеграционную часть) информации необходимой для анализа, мониторинга и принятия решений;
При этом бизнес-аналитик получает гораздо большую свободу в построении бизнес-модели предприятия - в силу минимального прямого влияния BPMS на собственно ход процессов. С точки зрения концепции "непрерывных изменений" он, бизнес-аналитик, получит возможность произвольного перестроения модели по мере анализа различных участков (подпроцессов) какого-либо процесса, возможность декомпозиции до интересующего уровня одного или нескольких участков и возврат обратно на более высокий уровень абстракции, без прямого вмешательства в ход собственно процесса.
Т.е. принимается решение - обратить внимание на такой-то участок(этап, подпроцесс) - модель модифицируется превращая то, что-бы ло атомарным "квадратиком", в цепочку реально существующих и выполняющихся взаимодействий. После того, как собрано достаточное для анализа количество информации модель можно вернуть в прежнее состояние - если пришли к выводу, что на данном этапе изменения данного участка не нужны(нецелесообразны, неэффективны).
...
Рейтинг: 0 / 0
05.03.2006, 22:32
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582770
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
...починяю примусОчень часто - не возникает состояния "ожидания оплаты", даже на начальном этапе после подписания договора могут начинаться уже "телодвижения" по подключнию и началу предоставления услуг. Естественно, я ведь и говорю о предоставлении услуг. А заключение договора (в данном случае являющегося по сути рамочным) -- это отдельный бизнес-процесс, который я оставил за списком.

...починяю примусА вот это - точно уже экзотика. И фантастика - в ближайшем обозримом будущем. Фантастика в нашей жизни уже не является экзотикой :) Посмотрите вокруг: кто-нибудь ожидал что будет такой бум потребительского кредитования? Да дело и не в кредитовании, я его привел просто для примера. Дело в том, что новшества в бизнесе стали появляться чаще, чем мы к тому привыкли.

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

...починяю примусбизнес-аналитик, получит возможность произвольного перестроения модели по мере анализа различных участков (подпроцессов) какого-либо процесса, возможность декомпозиции до интересующего уровня одного или нескольких участков и возврат обратно на более высокий уровень абстракции, без прямого вмешательства в ход собственно процесса Т.е. модель сама по себе, а "собственно процесс" -- сам по себе? Плавали, знаем. Это как раз то чем занимается туча консультантов с Аресом. Рисуют себе, рисуют... могут одну схему нарисовать, могут еще десяток -- того же самого бизнес-процесса, и столь же правильных. Сказать что совсем никакого толку от этого конечно нельзя, но по сравнению с прямым исполнением схемы в BPM толк мизерный.

...починяю примусBPMS, не обремененная обеспечением интеграционных задач, служит именно для отображения хода процессов и представления полученной из прикладных систем (включая интеграционную часть) информации необходимой для анализа, мониторинга и принятия решений Но если отложить теоретические дебаты и обратиться к практике, то может оказаться что мы с Вами ратуем почти что за одно и то же. Я тоже считаю, что на первом этапе надо смоделировать бизнес-процесс и выполнять его в BPM "вручную", т.е. не привязывая к прикладным системам. И только на втором этапе, когда схема утрясется (т.е. после 10 итераций) заняться привязыванием программ к шагам бизнес-процесса. Последовательность такая, потому что эффект на первом этапе больше, а затраты больше на втором. Но Вы, похоже, ратуете за то, чтобы первым этапом и ограничиться? С этим трудно согласиться. И потом, это гладкий, а не ступенчатый процесс: приделали к одной системе вебсервисы -- проинтегрировали ее, потом еще и еще, разумно выбирая очередность и темп интеграции.
...
Рейтинг: 0 / 0
05.03.2006, 22:54
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33582799
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
АБТ.е. модель сама по себе, а "собственно процесс" -- сам по себе? Плавали, знаем. Это как раз то чем занимается туча консультантов с Аресом. Рисуют себе, рисуют... могут одну схему нарисовать, могут еще десяток -- того же самого бизнес-процесса, и столь же правильных. Сказать что совсем никакого толку от этого конечно нельзя, но по сравнению с прямым исполнением схемы в BPM толк мизерный.

Мне такое сравнение кажется не совсем корректным - в данном случае схема "живет" на реальном процессе и реальных данных о его выполнение на каждом конкретном шаге (и на разных итерациях одного и того-же шага). И может следовать за изменениями процесса.

АБНо если отложить теоретические дебаты и обратиться к практике, то может оказаться что мы с Вами ратуем почти что за одно и то же. Я тоже считаю, что на первом этапе надо смоделировать бизнес-процесс и выполнять его в BPM "вручную", т.е. не привязывая к прикладным системам. И только на втором этапе, когда схема утрясется (т.е. после 10 итераций) заняться привязыванием программ к шагам бизнес-процесса. Последовательность такая, потому что эффект на первом этапе больше, а затраты больше на втором. Но Вы, похоже, ратуете за то, чтобы первым этапом и ограничиться?
Не совсем так, мне кажется. Просто меняется уровень зависимости модели от отдельных (некоторых или всех, в зависимости от сложности) участников процесса. Там, где есть возможность отслеживать реальные действия участника не по его специально выполненному для мониторинга действию (какому-либо действию в собственно BPMS), а по реальному действию в самом процессе (обработке документа, отсылке сообщения и т.п.).
Давайте еще раз - к нашим услугам. Платежи, в таком варианте у нас будут ходить из банка в бухгалтерию без отображения в BPMS - нет предмета для мониторинга/принятия решения (пока мы не объявили на предприятии "месячник борьбы с платежами" :). Напоминать бухгалтеру по поводу каждой платежки, что он затем тут и сидит, что-б их, платежки, разбирать - что за порядки такие у нас в конторе ? Бизнес-событием, для работающей в реальном времени модели, становится либо превышение кредитного лимита конкретным потребителем - с эскалацией в BPMS соответствующих процедур, либо, на другом уровне абстракции - превышение общей задолженности (работать совсем без задолженности таким предприятиям, как правило, не получается) по предприятию в целом или группе клиентов, либо какие-то другие агрегатные значения. Кто будет считать нужные значения и агрегаты - вопрос не принципиальный, где-то будет удобней считать внутри приложения и "выталкивать" в BPMS, где-то - BPMS будет "вытягивать" из приложения нужные данные и их анализировать. Эскалированные BPMS процессы уже будут жить в реальном времени (как и сам мониторинг возникновения подобных событий). Это, на мой взгляд - далеко не "бумажный Арис".
...
Рейтинг: 0 / 0
05.03.2006, 23:27
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583373
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
То есть Вы предлагаете бизнес-процесс в BPMS не доводить до платежа, а завершать раньше? Как-то мне это предложение кажется чересчур экстравагантным. Непонятно зачем его в таком случае и запускать (имеется в виду бизнес-процесс 1). Видимо Вы склоняетесь к тому, чтобы его, основной по сути бизнес-процесс, вколотить в прикладную программу, и BPMS к нему не привлекать. Может оно и разумно, учитывая массовость этого процесса. Имется выбор между гибкостью (как ответом на изменчивость) и производительностью (как ответом на массовость), и решение естественно за вами. Хотя 5 тысяч экземпляров бизнес-процесса в месяц (или сколько там у вас клиентов?) какой-то особой производительности и не требуют.
...
Рейтинг: 0 / 0
06.03.2006, 10:48
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583375
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
WJТ.е. как только в системе А изменилась/добавилась запись, то в общей БД эта запись тут же появилась,обновилась. Так?
Ну конечно, общее информационное поле называется.
...
Рейтинг: 0 / 0
06.03.2006, 10:48
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583393
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
Garya
Проц, судя по всему, остался в эре ERP. В его систему из внешних источников информация не поступает - она замкнута на саму себя.
Давайте не путайте себя и других.
Есть интеграция внутри одного предприятия - ее мы и рассматриваем.
Связь с внешним миром - другая песня , другие средства и называется по другому. Можете открыть отдельный топик - поговорим.
...
Рейтинг: 0 / 0
06.03.2006, 10:54
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583405
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
АБ Сказал. А неудобный встречный вопрос по производительности ODBC предпочел проигнорировать.

Извините про ODBC как то пропустил. Но в любом случае при чем здесь ODBC ?Есть и другие механизмы. Главное что бы напрямую без посредников, преобразований, файлов и тд.
Вы все время тянете нас к файловому обмену - зачем ? Ведь напрямую всегда лучше, разве это не очевидно ?
...
Рейтинг: 0 / 0
06.03.2006, 10:58
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583423
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
процЕсть интеграция внутри одного предприятия - ее мы и рассматриваем.
Связь с внешним миром - другая песня , другие средства и называется по другому. Кто это "мы"?! И какие это "другие средства"?! Как бы не так: сегодня эти задачи раздельно принципиально не рассматриваются, потому что границы между "нашим предприятием" и окружающим миром становятся зыбкими и условными. Конкурентная борьба ведется уже не между отдельными предприятиями, а между цепочками поставщиков. Посмотрите хоть на автопром: АвтоВАЗ -- это не предприятие "внутри", а цепочка, в которой завод занимается только сборкой. Или на ИКЕА, которая размещает заказы на российских в том числе предприятиях. Для BPM/SOA, рассматриваемых как средство интеграции, все равно, одно предприятие Вы рассматриваете или цепочку. А вот если Вы зациклились на единой базе, тогда конечно возникает желание подогнать задачу под ответ и ограничиться интеграцией "внутри предприятия".
...
Рейтинг: 0 / 0
06.03.2006, 11:03
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583436
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
процЕсть и другие механизмы. Главное что бы напрямую без посредников, преобразований, файлов и тд. Главное что бы напрямую без посредников, преобразований, файлов и тд. Ну хорошо, давайте не будем толочь воду в ступе. Вот Вам задача: надо извлечь данные из базы (10 таблиц, число записей в нескольких из них свыше миллиона) и представить их в виде отчета Excel (с рамками и прочим форматированием). Мы ее решаем при помощи SQL и XSLT, Вам такое решение не нравится. Предложите лучшее.
...
Рейтинг: 0 / 0
06.03.2006, 11:08
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583538
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
АБТо есть Вы предлагаете бизнес-процесс в BPMS не доводить до платежа, а завершать раньше?
Я предлагаю бизнес-процесс вообще никак не привязывать к платежу. Неужели я настолько непонятно свот мысли излагаю ? Вот-же:
автор
Бизнес-событием, для работающей в реальном времени модели, становится либо превышение кредитного лимита конкретным потребителем - с эскалацией в BPMS соответствующих процедур, либо, на другом уровне абстракции - превышение общей задолженности (работать совсем без задолженности таким предприятиям, как правило, не получается) по предприятию в целом или группе клиентов, либо какие-то другие агрегатные значения.

Ну не понимаю я вашего(и Garya) желания затащить в бизнес-модель абсолютно все, "что шевелится"...
...
Рейтинг: 0 / 0
06.03.2006, 11:37
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583570
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
...починяю примусЯ предлагаю бизнес-процесс вообще никак не привязывать к платежу Вы не говорите какой именно бизнес-процесс Вы не хотите привязывать к платежу. Вы ведь не считаете что он тут один? Пока Вы не называете свои бизнес-процессы, путаница неизбежна.

Если мы рассматриваем бизнес-процесс предоставления услуг (номер 1 в моей классификации), то его не привязывать к платежу нельзя. По крайней мере на логическом уровне; реализация может быть любой, в частности, можно этот бизнес-процесс вообще явно (т.е. при помощи BPMS) не автоматизировать.

Но Вы похоже говорите о каком-то другом бизнес-процессе. Догадываться о каком именно не хочется, лучше Вы сами его обрисуйте.
...
Рейтинг: 0 / 0
06.03.2006, 11:47
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583732
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
АБНо Вы похоже говорите о каком-то другом бизнес-процессе. Догадываться о каком именно не хочется, лучше Вы сами его обрисуйте.
Обрисовал уже . Бизнес-процесс стартует по событию носящему, по сути, характер "исключения" - выбор квоты/лимита на объем услуг, достижения порога неснижаемого остатка, "красное" сальдо счета и т.п. Стартовавший процесс может иметь несколько вариантов "урегулирования" ситуции, с назначением сроков и перевода процесса в режим ожидания по времени либо поступлению платежа и вариант, когда отношения с клиентом прекращаются а задолженность списывается.
В "нормальном" режиме работы соверешенно не понятно - зачем "тащить" в BPMS каждый клиентский платеж. Я это уже, наверное, с десяток раз повторил...
...
Рейтинг: 0 / 0
06.03.2006, 12:25
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33583979
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АБ
Участник
...починяю примусБизнес-процесс стартует по событию носящему, по сути, характер "исключения"... Все-таки жалко, что Вы упорно не хотите его назвать, а упорно говорите просто о "бизнес-процессе", как будто он тут один-единственный.

...починяю примусВ "нормальном" режиме работы соверешенно не понятно - зачем "тащить" в BPMS каждый клиентский платеж. Я это уже, наверное, с десяток раз повторил... Бизнес-процесс поставки услуги объективно существует. И так же объективно в него входит этот самый платеж, вопрос "тащить -- не тащить" тут не стоит. Другое дело, что управлять этим бизнес-процессом можно без BPMS -- закодировать его в монолитном приложении или вообще обрабатывать вручную.

Просто мы с Garya (возьму на себя такую смелость), независимо придя к выводу, что BPMS -- "просто правильная вещь" (и в этом смысле вещь схожая с DBMS), по умолчанию задействуем ее везде. Вам нужны особые аргументы для использования BPMS, нам -- для неиспользования .
...
Рейтинг: 0 / 0
06.03.2006, 13:28
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33584180
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
АБ
Вот Вам задача: надо извлечь данные из базы (10 таблиц, число записей в нескольких из них свыше миллиона) и представить их в виде отчета Excel (с рамками и прочим форматированием). Мы ее решаем при помощи SQL и XSLT, Вам такое решение не нравится. Предложите лучшее.
в Excel свыше миллиона не влезет, в остальном тривиальная задачка:
читаем данные из БД и засовываем прямо в шаблон Excel или считываем формулы из Excel вычисляем значения и засовываем обратно (механизм DDE или OLE)
...
Рейтинг: 0 / 0
06.03.2006, 14:12
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33584193
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
АБграницы между "нашим предприятием" и окружающим миром становятся зыбкими и условными.
мысль ваша понятна, однако все таки есть разница между собственной КИС и другими конторами. да и firewallы зачем то все ставят :).
...
Рейтинг: 0 / 0
06.03.2006, 14:15
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33584227
проц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
проц
Гость
АББизнес-процесс поставки услуги объективно существует.
А вот и нет. Это абстракция, которую можно определить любым удобным образом, сделать один большой БП или много маленьких. Проектирование БП - это проектирование технологии, а сами БП - это технологические процессы обработки информации, в отличие от технологических процессов обработки металлов резанием. Отсюда следует что управление БП - это уровень АСУ ТП. А АСУ ТП не может быть основой интеграции - не тот уровень.
...
Рейтинг: 0 / 0
06.03.2006, 14:23
| Ответить | Цитировать | Написать  
Есть ли будущее у систем интеграции ?
    #33584293
...починяю примус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
...починяю примус
Участник
АБВсе-таки жалко, что Вы упорно не хотите его назвать, а упорно говорите просто о "бизнес-процессе", как будто он тут один-единственный.

Что есть "назвать" в Вашем понимании ? Придумать название ? Я Вам описал (причем - неоднократно) суть бизнес-процесса. Что еще я должен "назвать" ?

АББизнес-процесс поставки услуги объективно существует. И так же объективно в него входит этот самый платеж, вопрос "тащить -- не тащить" тут не стоит. Другое дело, что управлять этим бизнес-процессом можно без BPMS...

Опять "за рыбу деньги"... Да нет там ни момента ни предмета управления - ровно до возникновения описанного выше бизнес-события (исключения) с которого начнется и управление и те или иные связанные с управлением действия. Не раньше. Кроме того, я перечислил явные (и, на мой взгляд, немаловажные) преимущества от "развязки" бизнес-модели и интеграции.

АБ
Просто мы с Garya (возьму на себя такую смелость), независимо придя к выводу, что BPMS -- "просто правильная вещь" (и в этом смысле вещь схожая с DBMS), по умолчанию задействуем ее везде. Вам нужны особые аргументы для использования BPMS, нам -- для неиспользования .
Объяснение из разряда "потому-что", на мое сугубое HO, может проистекать, в лучшем случае, от непонимания сути обсуждаемого предмета или явления. Я уже не говорю про смысл действия... Использование СУБД, к которой вам так полюбилось аппелировать, имеет, как минимум, одну оправданную цель - сохранить некую информацию. Какую цель преследует использование BPMS "по умолчанию" ?
...
Рейтинг: 0 / 0
06.03.2006, 14:42
| Ответить | Цитировать | Написать  
25 сообщений из 358, страница 11 из 15
  11  все
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Есть ли будущее у систем интеграции ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]