Функциональная совместимость бизнес-процессов ( 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, vol. 29. С. 85–98.
- Гихарро, Л. (2007). «Структуры взаимодействия и архитектуры предприятия в инициативах электронного правительства в Европе и США». Ежеквартальная правительственная информация . 24 (2007): 89–101. CiteSeerX 10.1.1.73.7861 . DOI : 10.1016 / j.giq.2006.05.003 .
- Курт Косанке (2005). "ИНТЕРОП-ЕКА'2005, Резюме статей"
- Ричард А. Мартин (2004). Документ "Фонд стандартов для взаимодействия" 2004 г. Международная конференция по интеграции предприятий и технологиям моделирования. 9–11 октября 2004 г. Университет Торонто, Канада.
- Депутат Папазоглу и др. (2000) « Интегрированные производственно-сбытовые цепочки и их значение с точки зрения бизнеса и технологий », Системы поддержки принятия решений 29 2000 стр. 323–342
Внешние ссылки
- Центр развития инфраструктуры электронной коммерции