Давайте не будем смешивать две совершенно разные вещи - "бизнес-процессы" и "еще один продукт". Когда вы настраиваете "КИС", то превращаетесь (хотя бы до некоторой степени) в бизнес-аналитика. То есть, в человека, которые анализирует, какая информация откуда и куда передается (те самые "входы" и "выходы"), в какой последовательности и в зависимости от каких условий обрабатывается. То есть, АСУ, КИС, МЯУ, ERP или BPM - как вы ни называйте средства автоматизации, но для того, чтобы с их помощью начать как-то решать задачи, нужно, хотя бы и не называя бизнес-процессы бизнес-процессами как-то у себя в голове или на бумаге их набросать.
Точно так же программируя на алгоритмическом языке вы можете не рисовать блок-схему алгоритма на бумаге, но так или иначе вы ее рисуете у себя в уме, может быть используя для этого нестандартные обозначения блоков, может быть цветовыми вспышками или мызкальными звуками, но так или иначе без предварительно представленной в виде абстракции-алгоритма последовательности шагов вы не напишете программу на алгоритмисеком языке (разве что абракадабру). И точно так же без представленного "алгоритма бизнеса", составные части которого и именуются "бизнес-процессами" вы не сможете автоматизировать этот бизнес.

Я еще как-то готов понять желание оспорить необходимость приобретения для решения этой задачи дополнительного продукта. Но отрицать необходимость абстрактного описания бизнеса перед его автоматизацией - это уже за пределами моего понимания.

2 проц. "Ну вы и даете" - это не ответ на заданный мною вопрос. Просто представьте, что вы хорошо знаете свое предприятие, что вы руководитель, который РУКОВОДИТ - и всё. Вам в подчинение дали только что нанятого на работу ИТ-специалиста, который понятия не имеет, чем занимается предприятие и какая для этого каша у него внутри варится. Приходит этот специалист, содится напротив вас - и вы должны ему объяснить, что он должен сделать, что именно автоматизировать. КАК вы ему это обясните? В каких абстракциях, образах, понятиях? Только не забудьте, что понятие "бизнес-процесс" мы отвергаем, как богохульное, а также всё остальное, сколь-нибудь на это понятие похожее, пусть даже и именующееся иначе.

Guest_123451. Периодическое сканирование - Требует разработки новых модулей, такой же результат может быть получен использованием тригеров обновления данных в базеЯ рассказал про общие принципы и привел примеры, которые на практике использовать совсем не обязательно... :) Естественно, гораздо удобнее, когда триггер формирует XML-документ и отправляет его в BizTalk, нежели периодически сканировать какую-то таблицу или VIEW. Но тогда это уже не будет примером "сканирования"... :) А вот забирать файлы из папки по мере их появления в ней никаким триггером сделать не получится. Только сканированием.

Guest_123452. В результате поступления информации по одному из информационных каналов - Не совсем понятно кто является источником такой информации.Кто угодно - какое-то приложение, WEB-сервис, другой BizTalk или даже этот же самый (иногда такой прием используется для взаимодействия разных бизнес-процессов, если информация может поступать к некоторому приемнику как откуда-то снаружи, так и изнутри). Это может быть сообщение по электронной почте, плоский файл, полученный по ftp или http, это может быть просто факт появления некоторого файла в заранее заданной папке (это "файловый" канал связи - такой способ реализует совокупность способов 1 и 2, поскольку периодичность сканирования папки задается в настройке самого информационного канала), это может быть сообщение MSMQ или сообщение, полученное командой NET SEND. Вариантов - просто неимоверно много. Самые первые версии BizTalk рассматривали такой способ получения информации о событиях как основной, поэтому этот вариант наиболее развит. И в последних версиях он наиболее существенный.

Guest_123453. В результате истечения заранее заданного таймаута - Это точно приходит из БП.БП - это алгоритм, хранящийся в самом BizTalk. Можно сказать, что BizTalk сам себе ставит "будильник". В принципе, это НЕ информация, поступившая снаружи. Возможно, этот вариант мною приведен действительно не совсем корректно.

Guest_123454. В результате программного вызова из другого приложения - Это точно требует корректировки ПО.Да, требует. Но иногда это удобнее, нежели что-то другое. Например, 1С имеет возможность обращаться к другим приложениям таким способом. Наверное, программеры были бы сильно расстроены, если бы такой возможности не было. Естественно, она используется довольно редко.

Guest_12345Итог - много переработки, хотя это и понятно - должен быть предусмотрен механизм передачи сигнала из существующего ПО.Если это ПО других разработчиков и нет никакой возможности там ничего передалать, можно выкрутиться методами 1 и/или 2. Простая операция сохранения некоторого текстового файла в заданной папке может восприниматься бизнес-процессом как событие, на которое он будет автоматически реагировать.

Guest_12345Очень хорошо. Т.е. даже если некоторые продукты старые, разработчики различные, о веб-сервисах слыхом не слыхивали, нет исходников - все равно надо искать и находить возможность интеграции. Это конечно радует (если я правильно понимаю).Если есть exe-шник, поставленный сторонним поставщиком, который что-то где-то автоматически делает (в каком-то своем шифроманном файле), на экране высвечивает результаты - и всё, никаких интерфейсов нет ни к хранилищу информации, ни к приложению, и даже во внешний файл ничего сохранено быть не может... Тогда, конечно, приплыли. Интеграция возможна только там, где интегрируемые части имеют хотя бы какое-нибудь "резьбовое соединение", к которому можно попробовать хоть что-то подобрать, стыкуясь с ним. Разумеется, BizTalk - не волшебник, который может творить чудеса. Стыковаться с тем, что изначально было разработано так, чтобы с ним принципиально не могло ничего и никаким образом состыковаться, он не сможет.

Если вы используете старые досовские приложения, работающие с бинарными файлами уникально-индивидуального формата, но которые хотя бы в текстовом виде могут что-то куда-то сохранить - этого для BizTalk достаточно, чтобы с ним можно было организовать "полуавтоматическое-полуручное" соединение. То есть, обязать сотрудника, работающего с досовским приложением с заданной переидочностью сохранять некоторую информацию в текстовый файл. Да, это тоже не очень удобно, но уже как-то можно выкрутиться.

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

Если это более современное WIN-приложение, которое может само обращаться к чужим интерфейсам, либо предоставить разнообразные интерфейсы к самому себе или к своим данным, если оно умеет что-то отправлять по электронной почте, например, жизнь становится еще более простой и одновременно разнообразной.

Самый идеальный случай, когда приложение может формировать данные в формате XML и отправлять ее самостоятельно куда-либо по каким-либо каналам и одновременно предоставляет WEB-сервисы, с помощью которых BizTalk может не только получить какую-либо порцию информации, но и заставить другое приложение выполнить "внутри себя" какие-то действия. Тогда приложения интегрируются легко и непринужденно. Причем, возможности интеграции приложений в процессе их постоянной модификации не страдают, если WEB-сервисы сохраняют форматы их вызова.

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

Инженер планового отдела1) В самой КИС есть все необходимое для "бизнес-процессов"

КИС с "функциями" СУБП
-------------------------
СУБД


2) "Система управления бизнес процессами" работает сама по себе, и ее нужно как-то интегрировать с КИС

КИС + отдельная СУБП + Система "связи"
-----------------------------------------
СУБД

3) СУБП (вместе с СУБД) является "фундаментом" КИС

КИС
-----
СУБП
-----
СУБД

4) СУБП над КИС

СУБП
-----
КИС
-----
СУБД

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

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

Четкого определения у термина "КИС" нет, но есть устоявшиеся представления о нем, которые как раз и исходят из того, что какое-то хранилище информации и именно в электронном виде для КИС строго обязательно ? В моем представлении КИС не может считаться система обмена информации, не использующая вычислительную технику. То есть, не являющейся набором программно-аппаратных средств, используемых с определенной целью. Однако, не любой набор программно-аппаратных средств является КИС. Точно так же самолет - это не всё, что может хотя бы на 1 см оторваться от земли, но и не всё из того, что может перемещаться в воздухе на расстояние в несколько километров. Итак, давайте уже наконец определимся с тем, что самолет человеку необходим для существенного увеличения скорости его передвижения с отрывом от земли на существенное расстояние (а не метры-сантиметры). То, что может также быстро двигаться как самолет, но не для целей, преследуемых человеком, а аткже то, что может передвигаться по воздуху на значительные расстояния, но не очень быстро или не для целей, преследуемых человеком - нам это не интересно, тьфу на на всех летающих паучков, воздушные шары, гусей-лебедей и метеориты. КИС необходима предприятию для существенного увеличения эффективности управления. Вопрос - ЗА СЧЕТ ЧЕГО ? Очень важный вопрос. И далее идет разбор "поколений технологий повышения эффективности".

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

Второе поколение технологий ориентировано на тех, кто уже почти достиг предела эффективности, опираясь на технологии первого поколения, кто уже смог осознать ограничения этого подхода. Самые важные ограничения:

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

2) Предполагаемая технологиями первого поколения концентрация ВСЕЙ информации в едином систематизированном хранилище оказалась достижимой на практике только до некоторой степени. В силу высокой трудоемкости разработки качественных и сложных программных продуктов наиболее эффективными оказались не очень большие, не очень дорогие и не очень сложные продукты, но лучшие в своем классе узко решаемых задач. Встал вопрос наиболее эффективного их объединения в единый комплекс взаимодействующих программных приложений. Технологии первого поколения не давали четкого ответа на этот вопрос. Возникли идеи специализированных интеграционных центров, которые смогли бы эту задачу решать наиболее эффективно.

3) Наиболее существенные ограничения оказались при обмене информацией множества различных предприятий. Оказалось, что технологии первого поколения, концентировавшиеся на систематизации информации только в рамках одного предприятия, натыкаются на серьезные ограничения при обменен информацией различных предприятий, каждое из которых следует своим локально разработанным методикам, не согласованными с партнерами по ведению бизнеса. В условиях, когда тесная интеграция предприятий с использованием B2B, B2C, CSRP и т.п. дает существенный выигрыш бизнесу, технологии первого поколения столкнулись с серьезными ограничениями.

Таким образом, BPM - это составная часть технологий второго поколения. Реализующие ее программные продукты способны преодолеть ограничения 1), 2) и 3). Инженер, вы полагаете их не столь существенными? Вы не желаете их преодолевать? Ок, дело хозяйское...

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

Процессный подход отличается от функционального как раз тем, что ориентирован на "быструю смену картинок". Еще он ориентирован на устранение искусственно созданных ограничений. Я уже об этом выше говорил. Я понимаю, что всю глубину второго нюанса осознать очень не просто. И специально попытаюсь его проиллюстрировать. В функции вашего системного администратора входит обязанность подметания пола в своем отделе? Нет? А почему??? Разве он не в состоянии выполнять это простое действие? Ведь он работает в режиме "пожарной команды" - иногда аврал, а иногда и заняться нечем... Уборка мусора не связана с жесткими требованиями ко времени ее выполнения. Когда аврал - она может и подождать. А когда сисадмину нечего делать - ведь он мог бы подмести пол в рабочем помещении? Почему же он этого не делает? Если приглядеться, то можно увидеть, что предприятие просто напрасно и неэффективно расходует средства на лишнюю уборщицу.
Кладовщик - аналогично. Иногда к нему очередь. Но иногда за воротами - шаром покати. Почему бы ему в эти периоды не разобрать письма, не заточить карандаши для всех прочих сотрудников, не выполнить еще какую-либо работу? Это не его ФУНКЦИИ ?
Я намеренно привел несколько "скандальные" примеры, чтобы вы смогли ощутить до костного мозга ту пропасть, которая разделяет функциональный и процессный подход и понять, что под лобной костью воткнут большой тормоз, который мешает мыслить подобными категориями, заставляя сосредоточиться на структуре. Реальные ресурсы, которые могут быть изысканы при переходе на процессное управление, не исчисляются лишь одной зарплатой вспомогательных сотрудников - они гораздо-гораздо обширнее.

Особо следует акцентировать внимание на серьезном переосмыслении в процессном подходе роли CEO, менеджера, руководителя. Один из родоначальников процессного подхода М.Хаммер утверждает "...Самым последним делом в реинжениринге является чувство собственной значимости менеджеров, поскольку одна из вещей, диктуемых реинжинирингом, состоит в том, что "заведующий - это не так уж и важно".

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

Процессный подход предусматривает исключение не имеющих никакого смысла барьеров. Есть лишь ресурсы, обладающие заданным набором характеристик, и цели, которых с помощью этих ресурсов требуется достигнуть. Всё. Далее идет распределение (по возможности наиболее оптимальное и непредвзятое) ресурсов по целям и задачам. И если вдруг заболеет и не выйдет на работу тот, кто обычно втыкает саженцы в лунки, то два других работника не будут тупо один за другим выкапывать и тут же закапывать лунки, потому что это и только это определено их ФУНКЦИЯМИ или задано СТРУКТУРОЙ.