WikiDer > Взаимодействие бизнес-процессов
Взаимодействие бизнес-процессов (BPI) - свойство, относящееся к способности разнообразных деловые процессы работать вместе, так называемое «взаимодействие».[1] Это состояние, которое существует, когда бизнес-процесс может соответствовать конкретной цели автоматически используя только необходимый человеческий труд. Обычно BPI присутствует, когда процесс соответствует стандарты которые позволяют ему достичь своей цели независимо от владельца, местонахождения, марки, версии или дизайна Компьютерные системы использовал.
Обзор
Основная привлекательность BPI заключается в том, что бизнес-процесс может начинаться и заканчиваться в любой точке мира, независимо от типов оборудования и программного обеспечения, необходимых для его автоматизации. Из-за своей способности разгрузить человеческий "умственный" труд, BPI рассматривается многими как заключительный этап в эволюции бизнес вычисление. Двойной критерий BPI: конкретная цель и основной человеческий труд оба субъективны.[нужна цитата]
Цели BPI различаются, но, как правило, делятся на следующие категории:
- Включить сквозной сквозная обработка («STP») путем объединения данных и процедур, находящихся в ловушке информационные хранилища
- Позвольте системам и продуктам работать с другими системами или продуктами без особых усилий со стороны клиента.
- Увеличивать продуктивность за счет автоматизации человеческого труда
- Устранение лишних деловые процессы и репликация данных
- Минимизируйте ошибки, присущие ручным процессам
- Представьте основное предприятие программное обеспечение как сервис
- Дайте топ-менеджерам практические средства наблюдение процессы, используемые для запуска деловые операции
- Поощрять развитие новаторский Интернет-бизнес-процессы
- Делайте упор на бизнес-процессы, а не на системы, необходимые для их работы
- Усилить безопасность устраняя пробелы между проприетарный программные системы
- Улучшать Конфиденциальность предоставляя пользователям полный контроль над своими данными
- Включить предприятие в реальном времени сценарии и прогнозы
Бизнес-процесс совместимость ограничивается корпоративным программным обеспечением системы в котором функции предназначены для совместной работы, например модуль расчета заработной платы и модуль главной книги, которые являются частью одного и того же программного пакета, и в контролируемых программных средах, которые используют EDI. Совместимость также присутствует между несовместимыми системами, где промежуточное ПО был применен. Однако в каждом из этих случаев процессы редко проходят проверку BPI, потому что они ограничены информационные хранилища и неспособность систем свободно общаться друг с другом.
История
Термин «функциональная совместимость бизнес-процессов» (BPI) был введен в обращение в конце 1990-х годов, в основном в связи с цепочка значений в электронная коммерция.[2][3] BPI использовался в рекламных материалах различных компаний и является предметом исследования организаций, занимающихся онтологии информатики.
Несмотря на то внимание, которое было уделено, функциональная совместимость бизнес-процессов не применялась за пределами ограниченной среды информационных систем. Возможная причина заключается в том, что BPI требует универсального соответствия стандартам, чтобы бизнес-процесс мог начинаться и завершаться в любой точке мира. Сами стандарты довольно просты - организации используют ограниченный набор общих процессов для управления большей частью своих операций. Совсем другое дело - объединить предприятия для создания и принятия стандартов. В конце концов, мир систем управления характеризуется информационные хранилища. Отказ от разрозненности требует от организаций решения культурных проблем, таких как владение и совместное использование процессов и данных, конкурентные силы и безопасность, не говоря уже о влиянии автоматизации на их рабочую силу.
Хотя расписание или внедрение BPI невозможно предсказать, он остается предметом интереса для организаций и мозговые центры одинаково.
Тестирование на BPI
Чтобы проверить BPI, организация анализирует бизнес-процесс, чтобы определить, соответствует ли он его требованиям. конкретная цель использование основной человеческий труд Только.
В конкретная цель должны быть четко определены от начала до конца. Однако начало и конец очень субъективны. В одной организации процесс может начаться, когда клиент заказывает продукт, и закончиться, когда продукт доставлен клиенту. В другой организации тому же процессу может предшествовать производство и распространение продукции, а за ним может следовать управление послепродажной гарантией и ремонтом.
Основной человеческий труд включает:
- Задачи, которые должны выполняться людьми, потому что отсутствуют практические средства автоматизации. Примеры включают тушение пожара, вождение автобуса и приготовление еды.
- Задачи, которые, по мнению руководства, люди более эффективно выполняют. Примеры включают ответ на телефонный звонок человеческим голосом и личное предложение инвестиционного совета.
- Задачи, в которых стоимость автоматизации превышает стоимость человеческого труда.
Чтобы претендовать на BPI, каждая задача процесса должна быть принята во внимание от начала до конца, включая трудозатраты, возникающие между трещинами, создаваемыми несовместимыми программными приложениями, такими как сбор данных из одной системы и повторный ввод их в другую, а также подготовка отчетов. которые включают данные из разнородных систем. Процесс должен протекать непрерывно, независимо от используемых компьютерных систем. Если в какой-то момент существует несущественный человеческий труд, процесс не проходит проверку BPI.
Достижение BPI
Чтобы убедиться, что деловые процессы могут соответствовать их конкретным целям автоматически используя только необходимый человеческий труд, BPI использует «сервис-ориентированную архитектуру» (SOA), который фокусируется на процессах, а не на технологиях, необходимых для их автоматизации. Широко используемая SOA - это эффективный способ решения проблем, вызванных любыми разрозненная система это сердце каждого информационное хранилище.
SOA имеет практический смысл, поскольку нельзя ожидать, что организации заменят или модифицируют свое текущее корпоративное программное обеспечение для достижения BPI, независимо от связанных с этим преимуществ. Рабочие места многих сотрудников строятся вокруг приложений, которые они используют, и большинство организаций вкладывают значительные средства в свои текущие информационные инфраструктуры, которые настолько сложны, что даже самые незначительные изменения могут оказаться очень дорогостоящими, трудоемкими и разрушительными. Даже если производители программного обеспечения объединятся и приведут свои продукты в соответствие с единым набором стандартов, проблема не будет решена. Помимо ПО от известных производителей, организации используют очень много унаследованные программные системы, пользовательские приложения, ручные процедуры и бумажные формы. Без SOA не может быть и речи об оптимизации такого огромного количества разрозненных внутренних процессов, чтобы они взаимодействовали по всему глобальному спектру предприятий.
Чтобы создать SOA для широкого использования, BPI полагается на централизованную базу данных. хранилище содержащие общие данные и процедуры, общие для приложений во всех отраслях и географических регионах. По сути, репозиторий служит верхним уровнем приложения, позволяя организациям экспортировать свои данные в свою распределенную базу данных и получать необходимые программы, просто войдя в систему через портал. Обеспечить безопасность и коммерческий нейтралитет, хранилище соответствует стандартам, провозглашенным сообществом BPI заинтересованные стороны.
Организации и группы по интересам которые хотят добиться взаимодействия бизнес-процессов, начинают с создания одной или нескольких инициатив BPI.
Смотрите также
- Информационный бункер, антитеза BPI
Рекомендации
- ^ Кристина Цагкани (2005) "Межорганизационное сотрудничество на уровне процессов". Материалы конференции IFIP / ACM SIGAPP INTEROP-ESA, 23–25 февраля, Женева, Швейцария, Издательство Springer Science. Цагкани заявляет:
- Функциональная совместимость бизнес-процессов характеризуется как способность бизнес-операций одной стороны взаимодействовать с бизнес-деятельностью другой стороны, независимо от того, принадлежит ли эта бизнес-деятельность разным подразделениям одного и того же бизнеса или разным бизнесам..
- ^ Асуман Догач изд. (1998) Системы управления рабочими процессами и взаимодействие. Springer-Verlag New York. Димитриос Георгакопулос и Афродита Цалгатиду обсудили
- ... необходимо эффективно управлять жизненным циклом бизнес-процессов, т.е. осуществлять управление бизнес-процессами. и способы как взаимодействие между WFMS и BPMT может обеспечить полную поддержку управления всем жизненным циклом бизнес-процесса.. (стр. 358)
- ^ Дерек Либерт (1999) Будущее электронного рынка. п. 297. Либерт признал, что
- Создание надежного электронного рынка потребует новых концепций, способствующих «взаимодействию бизнес-процессов».
дальнейшее чтение
- О. Adam et al. (2005). Платформа совместной работы для управления бизнес-процессами между предприятиями. Документ Первой международной конференции по взаимодействию корпоративного программного обеспечения и приложений, INTEROP-ESA'2005.
- Халид Белхаджаме, Марко Брамбилла. Описание и открытие бизнес-процессов на основе онтологий. В Труды 10-го семинара по моделированию, развитию и поддержке бизнес-процессов (BPMDS) на CAiSE 2009, Амстердам, июнь 2009 г., Springer LNBIP, т. 29. С. 85–98.
- Гихарро, Л. (2007). «Структуры взаимодействия и архитектуры предприятий в инициативах электронного правительства в Европе и США». Ежеквартальная правительственная информация. 24 (2007): 89–101. CiteSeerX 10.1.1.73.7861. Дои:10.1016 / j.giq.2006.05.003.
- Курт Косанке (2005). "ИНТЕРОП-ЕКА’2005, Резюме статей"
- Ричард А. Мартин (2004). «Основа стандартов для взаимодействия» Документ 2004 г. Международная конференция по интеграции предприятий и технологиям моделирования. 9–11 октября 2004 г. Университет Торонто, Канада.
- М.П. Папазоглу и др. (2000) "Интегрированные цепочки создания стоимости и их значение с точки зрения бизнеса и технологий," Системы поддержки принятия решений 29 2000 с. 323–342