СПОСОБ И СИСТЕМА ДЛЯ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССОМ ПРЕДПРИЯТИЯ Российский патент 2007 года по МПК G06Q50/00 

Приоритет настоящей заявки заявлен по дате подачи предварительной заявки на патент США № 60/366 547, поданной 25 марта, 2002 г., на изобретение «Способ и система для управления качеством данных предприятия». В данном раскрытии содержится информация, являющаяся объектом охраны авторским правом. Владелец авторского права не возражает против факсимильного воспроизведения любым лицом описания патента или патента в том виде, как он будет представлен в файлах или документах Ведомства США по патентам и товарным знакам. Однако владелец сохраняет за собой все остальные авторские права, связанные с его изобретением, описанным в данных материалах, включая все авторские права на экранные изображения, представленные в материалах заявки для облегчения понимания изобретения.

Область техники

Варианты осуществления настоящего изобретения относятся, в общем, к управлению бизнес-процессом, в частности к способам и системам для автоматизированного управления бизнес-процессом.

Описание известного уровня техники

Автоматизированная обработка информации приносит огромную пользу коммерческой деятельности, так как она существенно снижает расходы на определенные задачи. Каждое предприятие, независимо от того, является ли оно государственной, коммерческой или общественной организацией, вынуждено в процессе работы иметь дело с информацией.

Эта информация используется для привлечения клиентов, ввода заказов, отправки продукции, выписывания счетов клиентам, оплаты работникам и поставщикам, заказа продукции, проведения ревизий и регистрации транзакций между служащими, клиентами и поставщиками, например, в случае коммерческой деятельности.

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

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

Типичные примеры отрицательного влияния ошибок на организацию:

(1) получатели получают множество копий одних и тех же предложений по почте, в результате чего: (а) отправитель тратит впустую средства на почту и печать, и (b) получатель негативно реагирует на эти траты и, как следствие, не заказывает продукцию;

(2) почтовые системы и другие отправители сообщений и посылок не могут доставить значительный процент своего материала запланированным получателям, в результате чего: (а) продукция не доставляется вовремя и возвращается отправителю из-за неправильно указанного адреса, (b) дорогостоящие усилия предпринимаются для определения правильного адреса, переупаковки и отправки продукции, (с) счета возвращаются и не оплачиваются вовремя или вообще не оплачиваются, (d) дорогостоящие усилия предпринимаются для определения правильного адреса и повторной отправки счета, (е) клиентов раздражает плохой сервис, и в результате они переходят к другому поставщику, если это возможно, и (f) все операции по обслуживанию клиентов, выписыванию счетов, сборке и отправке продукции требуют дополнительных ресурсов для выполнения их функций;

(3) отдельные операционные блоки также содержат неправильную информацию о клиентах, в результате чего: (а) попытки, предпринимаемые предприятием для объединения информации, могут быть неполными, дорогостоящими и длительными, и (b) ошибки в отдельных операционных блоках при объединении повышают общий коэффициент ошибок и отрицательно сказываются на возможности обоснованного анализа;

(4) неполная и неточная информация объединяется в информационных хранилищах, операционных массивах данных, файлах информации о потребителях и централизованных массивах данных для процессов CRM (уплаты наличными по получении товара), ERP, SCM и других централизованных процессов, в результате чего: (а) маркетинг не способен точно прогнозировать ценность и потенциал отдельных клиентов и клиентских сегментов, и могут быть потеряны ценные рыночные возможности, (b) клиентам не предоставляется сервис надлежащего уровня и, как следствие, могут быть потеряны клиенты из-за неудовлетворенности сервисом, и (с) мошенничество не выявляется своевременно, что может привести к большим финансовым убыткам предприятия;

(5) операционные блоки не способны определить правильную налоговую юрисдикцию и начисление налогов, в результате: (а) предприятия не могут правильно облагать налогами клиентов и платить правильную сумму соответствующему ведомству, (b) налоговые службы не собирают все подлежащие уплате налоги, (с) клиенты платят больше налогов, чем они должны, и (d) корпорации несут ответственность перед налоговой юрисдикцией и клиентами; и

(6) клиенты недовольны и уходят к конкурентам.

Отрицательное влияние неправильной информации на доходы предприятия легко объяснить на примере обычных массовых почтовых пересылок. Конечно, это всего лишь единственный пример, так как в представленном выше перечне указаны и другие потенциальные воздействия на доходы предприятия.

Компании создают списки клиентов разными способами. Информация, собранная одной частью предприятия, часто используется другими частями организации для выполнения их функций. Если компания имеет подразделение розничной торговли и подразделение торговли по каталогам, то информацию о клиентах можно ввести в массив данных компании в подразделении розничной торговли, в подразделении торговли по каталогам и даже через Интернет. Каждая из этих трех позиций ввода представляет собой ячейку, в которой информация может быть неправильной или дублировать ранее существовавшую информацию. Любая неточность информации при ее сборе, обработке и объединении может повлиять на эффективность множества функций, выполняемых в рамках предприятия.

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

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

Проблема качества данных существует во многих сферах коммерческой деятельности. Известно много решений, предлагавшихся в отношении проблемы качества данных.

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

Обычно коммерческие предприятия выбирают стандартный набор установочных параметров для конкретной функции качества данных, которые представляются им наиболее выгодными. Эти установочные параметры могут, например, удалять ошибки в массиве данных, чтобы «очистить» массив данных до достижения точности данных 95% (что считается очень хорошим результатом).

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

В представленном выше примере компания имеет три коммерческих подразделения - розничной торговли, торговли по каталогам и через Интернет, каждое из которых содержит отдельный массив данных с информацией о клиентах. Обычно, если каждое подразделение пожелает «очистить» свои данные, оно должно приобрести решение для обеспечения качества данных для своего внутреннего применения. Если бы каждое подразделение должно было получить массив данных с точностью 95%, то результат можно было бы считать достаточно хорошим.

Если компания затем попытается создать объединенный массив данных, то возникнет проблема, заключающаяся в том, что ошибки в каждом массиве данных дополнят друг друга. В описанном случае каждый массив данных имеет одинаковую ошибку. Объединенный массив данных будет иметь коэффициент ошибок 0,95×0,95×0,95=0,857375. Это означает, что полученный массив данных будет имеет коэффициент ошибок около 15%, что в три раза выше, чем у каждого массива из тех, которые были объединены. Понятно, что эта проблема становится особенно серьезной, когда объединяются четыре или более массивов данных.

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

Хотя решения, касающиеся качества данных, благоприятны для работы коммерческих предприятий, их возможности ограничены, особенно в тех случаях, когда компании пытаются создать централизованные массивы данных для множества подразделений предприятия или групп подразделений.

Более того, когда коммерческое предприятие желает разработать программу «очистки» своего централизованного массива данных, существующая доктрина диктует, что фирма должна разработать соответствующее программное обеспечение. Разработка программного обеспечения следует тому, что обычно называют жизненным циклом разработки программного обеспечения (ЖЦРП).

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

Кроме того, поскольку стадия определения требований может быть остановлена (т.е. требования «заморожены»), чтобы позволить начаться деятельности по проектированию, известный ЖЦРП не отличается гибкостью и не способен учитывать развивающиеся потребности потребителей программных продуктов.

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

Сущность изобретения

В основу настоящего изобретения положена задача создания системы и способа управления бизнес-процессом, которые позволяют устранить многие недостатки известного уровня техники.

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

Согласно одному варианту изобретения предложены система и способ для управления качеством данных предприятия, которые определяют, анализируют, улучшают и сообщают качественные и количественные аспекты прикладных данных и транзакционных данных, имеющихся на предприятии.

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

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

Кроме того, варианты осуществления настоящего изобретения могут обеспечить более короткий ЖЦРП, в котором несколько известных этапов ЖЦРП объединено таким образом, что сокращается время разработки проекта и упрощается процесс, обеспечивая при этом значительную экономию времени и средств.

Например, в одном варианте стадии определения требований, создания общего проекта, создания детального проекта и разработки могут осуществляться одновременно как одна стадия с использованием интерактивного проектировщика процесса.

Более того, в одном варианте осуществления изобретения путем применения тестовых данных к бизнес-процессам, определенным и реализованным, как описано в данном документе, такие известные стадии ЖЦРП, как тестирование, гарантия качества и испытание, могут осуществляться как одна стадия.

Кроме того, в одном варианте осуществления изобретения каждая из стадий ЖЦРП может быть осуществлена путем взаимодействия пользователя с одним интерфейсом проектировщика процесса, предусмотренным одним продуктом.

Кроме того, в варианте осуществления изобретения может не потребоваться инженер-программист для кодирования в процессе проектирования.

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

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

Другие аспекты изобретения будут понятны из следующего описания и прилагаемых чертежей.

Краткое описание чертежей

Преимущества настоящего изобретения поясняются в следующем подробном описании по меньшей мере одного примерного варианта воплощения изобретения со ссылками на прилагаемые чертежи, на которых:

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

фиг.2 - структурная схема аппаратных средств, которые можно использовать для реализации сервера, спроектированного согласно по меньшей мере одному примерному варианту осуществления изобретения,

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

фиг.4 - функциональная схема, иллюстрирующая взаимосвязь между источниками/пунктами назначения данных, продуктами и процессами в одном варианте осуществления изобретения,

фиг.5 - функциональная схема, иллюстрирующая аппаратные средства, которые можно использовать для реализации системы, согласно по меньшей мере одному варианту осуществления изобретения,

фиг.6 - алгоритм, иллюстрирующий способ, используемый системой управления бизнес-процессом предприятия, согласно по меньшей мере одному примерному варианту осуществления изобретения,

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

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

фиг.9 - пример отчета об ошибках для экранного представления, касающегося индивидуума, согласно по меньшей мере одному варианту осуществления изобретения,

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

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

фиг.12 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для создания процедуры бизнес-процесса согласно по меньшей мере одному варианту осуществления изобретения,

фиг.13 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для добавления источника данных к процессу согласно по меньшей мере одному варианту осуществления изобретения,

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

фиг.15 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для определения выходного пакета для процесса согласно по меньшей мере одному варианту осуществления изобретения,

фиг.16 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для выбора продукта в процессе согласно по меньшей мере одному варианту осуществления изобретения,

фиг.17 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для добавления продукта для использования с процессом согласно по меньшей мере одному варианту осуществления изобретения,

фиг.18 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для выбора получателя данных для процесса согласно по меньшей мере одному варианту осуществления изобретения,

фиг.19 - примерная страница взаимодействия с пользователем графического пользовательского интерфейса для запуска процесса согласно по меньшей мере одному варианту осуществления изобретения,

фиг.20 - примерный интерактивный дисплей интерфейса проектировщика процесса для графического пользовательского интерфейса согласно по меньшей мере одному варианту осуществления изобретения,

фиг.21 - ряд файлов построения, используемых в варианте осуществления изобретения сервером бизнес-процесса предприятия для построения кодовой реализации бизнес-процесса,

фиг.22 - иллюстрация способа построения библиотеки динамической связи для нового маршрутизатора в варианте осуществления изобретения,

фиг.23a-d - блок-схема, иллюстрирующая способ реализации бизнес-процесса, согласно по меньшей мере одному варианту осуществления изобретения,

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

фиг.25 - пример интерактивной страницы обзора функций, предусмотренной в варианте осуществления изобретения,

фиг.26 - пример части области определения процесса интерактивной страницы проектировщика процесса, предусмотренной в варианте осуществления изобретения,

фиг.27 - пример интерактивной страницы, иллюстрирующий добавление элемента этапа процесса из функциональной библиотеки, в варианте осуществления изобретения,

фиг.28 - пример интерактивной страницы, иллюстрирующий связывание этапов процесса в области определения процесса интерактивной страницы проектировщика процесса, в варианте осуществления изобретения,

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

фиг.30 - пример интерактивной страницы определения продуктов, предусмотренной в варианте осуществления изобретения,

фиг.31 - пример интерактивной страницы определения получателя данных, предусмотренной в варианте осуществления изобретения,

фиг.32 - пример интерактивной страницы выбора продуктов, предусмотренной в варианте осуществления изобретения,

фиг.33 - пример содержания страницы файла шаблона функции, предусмотренной в варианте осуществления изобретения,

фиг.34 - пример интерактивной страницы установок функции, предусмотренной в варианте осуществления изобретения,

фиг.35 - пример интерактивной страницы тестера процесса согласно варианту осуществления изобретения,

фиг.36 - иллюстрация заполненной данными области проекта интерактивной страницы тестера процесса в варианте осуществления изобретения,

фиг.37 - пример интерактивной страницы определения соединения согласно по меньшей мере одному варианту осуществления изобретения,

фиг.38 - иллюстрация сравнительного бизнес-процесса согласно варианту осуществления изобретения, и

фиг.39 - взаимосвязь между интерфейсным модулем, сервером бизнес-процесса предприятия и маршрутизатором в варианте осуществления изобретения.

Подробное описание изобретения

Настоящая заявка испрашивает приоритет предварительной патентной заявки США № 60/366547 от 25 марта 2002 г. на «Способ и систему для управления качеством данных предприятия», полное раскрытие которой включено в настоящее описание посредством ссылки в полном объеме.

Хотя настоящее изобретение описано в связи с его примерными вариантами осуществления, эти примерные варианты не следует рассматривать как ограничивающие объем изобретения. Напротив, альтернативы, модификации и эквиваленты описанных примеров также должны быть включены в сущность и объем изобретения, что определяется прилагаемой формулой изобретения.

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

На фиг.1 изображена иллюстративная схема системы, реализующей или использующей систему управления бизнес-процессом предприятия согласно по меньшей мере одному примерному варианту осуществления изобретения. Изображенная на фиг.1 система 100 управления бизнес-процессом предприятия может содержать сервер 101 бизнес-процесса предприятия, подключенный к одному или нескольким дополнительным клиентам, таким как, без ограничения перечисленным, клиент извлечения, преобразования и загрузки (ИПЗ) 102, клиент интеграции приложений предприятия (ИПП) 103, клиент планирования ресурсов предприятия (ПРП) 104 и клиент управления связями с потребителями (УСП) 105. Сервер 101 бизнес-процесса предприятия может быть также подключен к дополнительным клиентам, таким как клиент-менеджер цепи поставки (МЦП) (не показан). Каждый дополнительный клиент может содержать по меньшей мере одно бизнес-приложение. Кроме того, сервер 101 бизнес-процесса предприятия может быть также связан с массивом 106 информационных данных и массивом 107 данных двумерных файлов, одной или более центральных ЭВМ 108 и Интернет 109. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может быть также подключен к одному или более терминалам, таким как терминал (терминалы) 110 центра обработки вызовов, терминалы 111 ввода данных, терминал (терминалы) 112 локальных пользователей и терминал (терминалы) 113 удаленных пользователей. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может быть сервером качества данных предприятия или сервером бизнес-процесса предприятия, выполненным с возможностью определения и управления качеством данных предприятия.

Сервер 101 бизнес-процесса предприятия может осуществлять связь с узлами предприятия, включая дополнительных клиентов 102-105, массивы 106 и 107 данных, центральные ЭВМ 108, Интернет 109 и терминалы 110-113, с помощью ряда сетей связи, включающих в себя, без ограничения перечисленным, сеть взаимосвязанных сетей, такую как Интернет, локальную вычислительную сеть (ЛВС), глобальную вычислительную сеть (ГВС), интранет, включающую любую из них, и/или телефонную сеть общего пользования (ТСОП), беспроводную сеть или любую их комбинацию. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может осуществлять связь с одним или более узлов предприятия для получения и передачи данных, связанных с транзакциями, а также, как минимум, отчетов об ошибках.

Обычно клиентами 102-105 может быть любой источник данных, который способен посылать или получать данные, такой как, без ограничения перечисленным, сервер или клиентская часть приложения «клиент-сервер». Клиент может выполнять роль ведущего узла, например, для одного или более процессов бизнес-приложений или функций предприятия. Клиенты могут располагаться как внутри, так и снаружи брандмауэра предприятия.

Клиент ИПЗ 102 может конфигурироваться для обеспечения возможности организации извлекать наборы данных из одного источника данных, отображать эти данные в другом источнике данных, преобразовывать данные при необходимости, объединять источники данных и загружать эти данные в источники получателя. Такой клиент ИПЗ 102 может быть изначально ориентирован на пакетную обработку и использовать архитектуру концентратора, в которой преобразования и отображения данных выполняются по мере прохождения данных от их источника к пункту назначения (получателю).

Клиент ИПП 103 может конфигурироваться для обеспечения возможности транзакциям предприятия проходить из одного приложения в другое внутри организации/предприятия и из одной организации в организацию партнера, которая существует в сети ИПП. Такой клиент ИПП 103 может использовать архитектуру концентратора и включать в себя средства для отображения и преобразования данных, связанных с транзакциями предприятия.

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

Клиент УСП 105 может конфигурироваться для управления множеством аспектов взаимодействия между организацией/подразделением и его потребителями, используя целый ряд электронных средств, включая информационно-справочные программы, организаторы продаж, маркетинга, электронной почты и приложения веб-разработки. Такой клиент УСП 104 может использовать архитектуру концентратора и включать в себя средства для отображения и преобразования данных, связанных с ним.

Каждый дополнительный клиент предприятия, включая клиента ИПЗ 102, клиента ИПП 103, клиента ПРП 104, клиента УСП 105, может иметь процессы проверки качества зависящего от поставщика приложения, которые действуют внутри каждого соответствующего приложения сервера. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может содержать интерфейс протокола управления передачей/межсетевого протокола (TCP/IP) для обмена информацией с дополнительными серверами предприятия, включая клиента ИПЗ 102, клиента ИПП 103, клиента ПРП 104 и клиента УСП 105. Информация, которой обмениваются сервер 101 бизнес-процесса предприятия и дополнительные клиенты, может включать в себя команды или запросы от сервера 101 бизнес-процесса предприятия на выполнение одного или более конкретных процессов или функций процесса (или процессов), например процессов для проверки качества данных. Обмениваемая информация может содержать выходные данные процессов или функций проверки качества приложения. Интерфейс связи TCP/IP может позволить серверу 101 бизнес-процесса предприятия соединяться напрямую с любым приложением через сеть предприятия. Альтернативно, интерфейс связи TCP/IP может позволить серверу бизнес-процесса предприятия соединяться с внешними приложениями, например, через Интернет.

По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может получать информацию из массива 106 информационных данных и массива 107 данных двухмерных файлов. В частности, сервер 101 бизнес-процесса предприятия может содержать команды приложения, такие как драйверы массива данных для доступа, хранения или избирательного извлечения информации, содержащейся в массиве 106 информационных данных и массиве 107 данных двухмерных файлов. Эти драйверы массива данных могут быть реализованы в форме программирующих утверждений, предусмотренных, например, в языке структурированных запросов (SQL, версия 7) системы управления массивом данных, а также Transact® SQL (в соответствии с системой управления массивом данных ColdFusion®). Возможны и другие варианты реализации массивов данных, включающие, например, без ограничения перечисленным, Oracle® или IBM DB2®.

В альтернативном варианте система 100 управления бизнес-процессом предприятия может содержать сервер базы данных предприятия (не показан), связанный с сервером 101 бизнес-процесса предприятия и массивом 106 информационных данных и массивом 107 данных двухмерных файлов в целях доступа к хранящейся в них информации. Массив 106 информационных данных может содержать данные приложений или транзакций предприятия, организованные в соответствии с форматом иерархической системы управления массивом данных, например, SQL. Массив 107 данных двухмерных файлов может содержать неиерархические данные приложения предприятия или транзакций.

Сервер 101 бизнес-процесса предприятия может быть также связан с одной или несколькими центральными ЭВМ 108 на предприятии. Центральные ЭВМ 108 могут содержать такие приложения организации или предприятия, как, например, платежные или бухгалтерские системы. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может осуществлять связь с центральными ЭВМ 108 с помощью локальной вычислительной сети (ЛВС), глобальной вычислительной сети (ГВС), выделенных наземных линий или их комбинации, помимо всего прочего.

Кроме того, по меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может быть также связан с одним или более терминалами, такими как терминал (терминалы) центра обработки вызовов 110, терминалы 111 ввода данных, локальный пользовательский терминал (терминалы) 112 и удаленный пользовательский терминал (терминалы) 113, через ЛВС, ГВС, выделенные наземные линии, интранет, Интернет, беспроводную сеть или их комбинации. Поэтому сервер 101 бизнес-процесса предприятия может получать данные транзакций из одного или более терминалов 110-113.

Кроме того, сервер 101 бизнес-процесса предприятия может осуществлять связь с пользователями на одном или более удаленных терминалах 113, используя, например, Интернет 109. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может также содержать веб-браузер или тонкий клиент для этой цели. Веб-браузер отображает данные и способен осуществлять связь с другими компьютерами через сеть, например, такую как Интернет или интранет. Веб-браузер может предоставить пользователю путь навигации, например, через гиперссылки, которые выбираются указательным устройством (таким как компьютерная мышь) или печатаются пользователем. Веб-браузер может использовать протокол, например протокол передачи гипертекста (HTTP) или протокол пересылки файлов (FTP), для передачи данных различного содержания, например документов формата HTML, простых текстовых документов, графических изображений и документов XML (расширяемого языка разметки) для предоставления пользователю через дисплей.

На фиг.2 показана вычислительная платформа, которую можно использовать для реализации сервера 101 бизнес-процесса предприятия согласно по меньшей мере одному варианту изобретения. Как показано на фиг.2, аппаратные средства 200 могут содержать процессор 210, память 220, системный интерфейс 230, пользовательский интерфейс 240 и шину 250 связи/передачи данных/управления, которая связывает элементы 210-240 между собой и позволяет им взаимодействовать и осуществлять связь.

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

Процессор 210 управляет работой других элементов 220-250 на основании команд, выбранных из памяти 220. Эти команды могут включать в себя или быть реализованы как программный код, который предписывает некоторые или все операции предложенных системы 100 и способа управления бизнес-процессом предприятия. Память 220 может содержать этот код, а также область массива для данных, используемых или формируемых системой 100 управления бизнес-процессом предприятия. Процессор 210 может производить выборку команд, декодировать их и действовать сам или предписывать другим элементам 120-150, например, передать данные в память 220 или из нее или работать во взаимодействии с системным интерфейсом 230 или пользовательским интерфейсом 240 (например, для ввода или вывода информации) и т.д.

Фактически процессор 210 может быть реализован в виде нескольких процессоров. Процессор 210 может на основании команд, выбранных из памяти 220, управлять работой других элементов 220-250. Понятно, что управление может быть реализовано процессором 210, находящимся, например, в центральном процессорном устройстве или другом подобном устройстве. Аналогично, процессор 210 и память 220 могут быть реализованы посредством одного или более серверов, связанных с сетью, которая позволяет реализовать пользовательский интерфейс 240 на пользовательском терминале, таком как локальный терминал 112 и удаленный терминал 113, и содержать графический пользовательский интерфейс (ГПИ) на экране терминала.

Пользовательский интерфейс 240 может содержать, например, аппаратные и программные средства для взаимодействия с дисплеем терминала, клавиатурой и мышью и т.п. Кроме того, пользовательский интерфейс 240 может содержать динамики и микрофон, не показанные на чертеже, для вывода и ввода информации к/от пользователя. Пользовательский интерфейс 240 может взаимодействовать с процессором 210, чтобы позволить пользователю взаимодействовать с программами, хранящимися в памяти 220 и используемыми процессором 210, для выполнения операций, описанных ниже.

Сервер 101 бизнес-процесса предприятия можно реализовать, например, в виде частей надлежащим образом запрограммированной вычислительной машины общего назначения. Эту систему можно реализовать, например, в виде физически раздельных аппаратных схем на специализированной интегральной схеме. Таким образом, понятно, что конкретная форма системы 100 может отличаться от представленных в данном описании вариантов. Например, хотя система 100 управления бизнес-процессом предприятия описана как реализуемая в вычислительной машине общего назначения, например персональном компьютере, ясно, что эту систему можно реализовать в сетевой среде, где программное обеспечение, реализующее систему, хранится на одном или более серверах. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может позволить пользователю (например, административному пользователю) добавлять, модифицировать или удалять процессы или этапы бизнес-процесса без остановки сервера 101. Более того, сервер 101 бизнес-процесса предприятия может быть масштабируемым, чтобы он мог легко функционировать в средах массива или кластера серверов и обрабатывать большие объемы данных. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может иметь, например, персональную вычислительную платформу Microsoft Windows™ NT.

По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может содержать одну или больше прикладных программ, содержащих ряд программных команд, которые обеспечивают конфигурирование сервера 101 бизнес-процесса предприятия для выполнения операций бизнес-процесса, как описано в данном документе. В частности, по меньшей мере в одном варианте на фиг.3 проиллюстрирована функциональная схема приложения 300 качества данных предприятия сервера 101 бизнес-процесса предприятия. На фиг.3 приложение 300 качества данных предприятия может содержать архитектуру ядра 301, набор заданных инструментов 302 экранного представления, набор 303 разработчика и интерфейсный модуль 304, который может быть интерфейсом бизнес-аналитика. Архитектура ядра 301 может содержать ряд программных команд для получения прикладных данных или транзакционных данных из одного или нескольких источников данных, анализа полученных данных на наличие ошибок, регистрации выявленных ошибок и формирования по меньшей мере одного отчета об ошибках согласно конкретному запрошенному экранному представлению. Приложение 300 качества данных предприятия может иметь одну или несколько функций, предназначенных для анализа конкретного типа прикладных данных, которые можно получить из одного или более источников данных, для случаев одного или более видов ошибок, присутствующих в прикладных данных. Кроме того, приложение 300 качества данных предприятия может содержать команды, предписывающие передать запрос одному или более дополнительным серверам предприятия, включая сервер ИПЗ 102, сервер ИПП 103, сервер ПРП 104 и сервер УСП 105, запрашивающий исполнение процессов проверки качества конкретного приложения или конкретный набор функций одного или более внутренних процессов приложения. По меньшей мере в одном варианте изобретения сервер 101 бизнес-процесса предприятия может передавать команды/запросы (например, вызовы функции или вызовы процедуры/удаленные вызовы процедуры (УВП)) и получать ответы от соответствующего сервера через интерфейс TCP/IP. Архитектура 301 ядра может иметь многопоточный уровень управления для автоматического преобразования любых унаследованных приложений, не являющихся многопоточными, в многопоточные.

В одном варианте изобретения модуль 304 бизнес-аналитика может содержать последовательности программных команд для реализации интерфейсного модуля (например, интерфейса бизнес-аналитика или ИБА), описанного в данном документе. Эти команды после исполнения сервером 101 бизнес-процесса предприятия позволяют серверу 101 бизнес-процесса предприятия обеспечить интерактивное средство для облегчения взаимодействия пользователя с системой 100 управления бизнес-процессом предприятия. В частности, модуль 304 бизнес-аналитика может содержать команды, обеспечивающие создание графического представления этапов процесса, например, с использованием дисплея и указывающие конкретную операцию, которую должен выполнить сервер бизнес-процесса предприятия при исполнении одного или более технологических этапов бизнес-процесса. Модуль 304 бизнес-аналитика как таковой может быть оверлейным приложением к набору 303 инструментальных средств разработчика. Модуль 304 бизнес-аналитика может также содержать команды, позволяющие серверу 101 бизнес-процесса предприятия извлекать, создавать и компилировать из массива данных, например массива 106 данных, последовательность команд, реализующую бизнес-процесс, определенный взаимодействием пользователя с интерфейсным модулем.

По меньшей мере в одном варианте изобретения система 100 управления бизнес-процессом предприятия может выдавать информацию об ошибках в виде одного или более отчетов об ошибках. Отчеты об ошибках могут быть представлены в соответствии с целым рядом экранных представлений. Инструменты 302 заданного экранного представления могут включать в себя программные команды, связанные с одним или более отчетами об ошибках, предусмотренными в соответствии с набором заданных экранных представлений. Например, инструменты заданных экранных представлений могут выдавать команды, позволяющие серверу 101 бизнес-процесса предприятия выдавать отчет об ошибках, включающий в себя численный подсчет ошибок для источника данных, для экранного представления, предназначенного для менеджера. Другие примерные экранные представления и отчеты описаны ниже.

Набор 303 инструментальных средств разработчика может включать в себя интерфейс прикладного программирования (API), предназначенный для использования пользователями системы 100 управления бизнес-процессом предприятия или назначенными ими третьими лицами при создании и использовании заказных инструментов экранного представления для анализа конкретных данных, источников, синдромов ошибок или для выдачи заказных отчетов в добавление к набору заданных инструментов 302 экранного представления. Не существует никаких ограничений на количество экранных представлений, поддерживаемых системой 100 управления бизнес-процессом предприятия.

По меньшей мере в одном варианте изобретения сервер 101 бизнес-процесса предприятия может быть реализован в соответствии с архитектурой типа «клиент-сервер». Программные команды, включая приложение 300 качества данных предприятия, могут быть реализованы в переносимом исходном коде, например, без ограничения указанным, в родовом коде Microsoft® С. Сервер 101 бизнес-процесса предприятия может быть реализован в соответствии с модульной серверной структурой для поддержки кластеров и массивов серверов. Кроме того, сервер 101 бизнес-процесса предприятия может быть реализован в соответствии с принципом не меняющей состояния архитектуры, чтобы иметь возможность использовать технологию сторонних производителей для выравнивания нагрузки и обеспечения высокой доступности, в целях обеспечения надежности и масштабируемости для обработки больших объемов данных. Кроме того, сервер 101 бизнес-процесса предприятия может использовать технологию «песочницы» (т.е. использовать комбинацию методов синхронизации и изоляции процесса, например, обработки каждого сеанса в отдельном потоке) для обеспечения быстрого и надежного ввода унаследованной технологии, которая не была многопоточной или даже поточно-ориентированной, в среду параллельной обработки в реальном времени.

На фиг.4 представлена функциональная структурная схема, иллюстрирующая одну предлагаемую взаимосвязь между источниками/получателями данных, продуктами и процессами, согласно по меньшей мере одному варианту изобретения. Как показано на фиг.4, сервер 101 бизнес-процесса предприятия может получать/передавать данные приложения или транзакции предприятия от/к одному или более источников/получателей 305 данных. По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может выдавать скорректированные данные после обнаружения ошибки в источнике/получателе 305 данных (например, источнике/получателе данных с 1 по К). Кроме того, сервер 101 бизнес-процесса предприятия может получать ввод процесса из одного или более продуктов 315 (например, продуктов от 1 по М). Продукт 315 может содержать функцию или набор функций. По меньшей мере в одном варианте функция может быть программой в библиотеке, которая возвращает значение или набор значений. Кроме того, сервер 101 бизнес-процесса предприятия может содержать или иметь доступ к одному или более процессам 310 для выполнения, например, функций гарантии качества данных, описанных ниже (например, процессов от 1 до N). По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может вести отдельный журнал 325 ошибок для каждого процесса 310. Результаты из каждого процесса 310, включая любой созданный журнал 325 ошибок, могут храниться и вестись с использованием массива 310 данных журнала (который может быть массивом 160 данных, описанным в связи с фиг.5).

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

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

На фиг.5 показаны аппаратные средства, которые можно использовать для реализации системы согласно по меньшей мере одному варианту изобретения. В частности, система 100 управления бизнес-процессом предприятия может содержать по меньшей мере один сервер 101 бизнес-процесса предприятия, а также может содержать массив 160 данных и механизм 170 экранного представления. Массив 160 данных не обязательно должен быть единственным массивом данных, а может представлять собой несколько массивов данных. Например, массив 160 данных может быть, без ограничения перечисленным, базой данных оперативной аналитической обработки (ОАО) или сводной базой данных. Массив 160 данных может содержать, без ограничения перечисленным, команды и правила форматирования, используемые механизмом 170 экранного представления для создания отчета об ошибках согласно одному из нескольких экранных представлений 400. Например, механизм 170 экранного представления может получать из массива 160 данных последовательность команд форматирования и применять полученные таким образом команды для формирования отчета об ошибках согласно соответствующему экранному представлению 400. По меньшей мере в одном варианте каждое экранное представление 400 может быть связано с конкретным набором команд форматирования. Команды форматирования могут быть реализованы в виде команд HTML (языка разметки гипертекста) или XML (расширяемого языка разметки), предназначенных для того, чтобы механизм 170 экранного представления визуализировал интерактивную страницу, содержащую запрошенный отчет об ошибках, в требуемом виде. Интерактивная страница может быть, например, страницей Всемирной паутины или страницей, отображаемой на дисплее терминала 112 или 113 с помощью приложения веб-браузера.

Как видно на фиг.5, система 100 управления бизнес-процессом предприятия может предоставить несколько различных экранных представлений 400, включая, без ограничения перечисленным, экранное представление для конечного пользователя, экранное представление для разработчика, экранное представление для менеджера и экранное представление для руководителя. Примерные экранные представления 400 описаны ниже со ссылками на фиг.7-10.

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

Для поддержки создания отчетов об ошибках согласно ряду экранных представлений 400 массив 160 данных (который может быть базой данных оперативной аналитической обработки (ОАО) или сводной базой данных) может поддерживать информацию отчетов об ошибках в соответствии с «единым видом», в котором информация, содержащаяся в массиве 160 данных, отформатирована и организована соответствующим образом, равно доступным для механизма 170 экранного представления, для формирования любого экранного представления 400 независимо от источника/получателя 305 данных, продукта 315 или процесса 310, из которого были получены данные.

Система 100 управления бизнес-процессом предприятия может регистрировать результаты каждого этапа в процессе из каждого источника данных. Журнал регистрации может предоставить информацию о том, кто отправил эти данные, что произошло на каждом этапе процесса и куда были посланы данные после завершения процесса. Этот журнал можно передавать непосредственно в механизм 170 экранного представления, который может быть системой выдачи графических отчетов, для формирования множества экранных представлений.

По меньшей мере в одном варианте механизм 170 экранного представления может предоставлять графические отчеты различным пользователям, включая руководителей, менеджеров, конечных пользователей и разработчиков процесса, в которых содержится информация о том, как работают они сами, их отдел, организация или процессы. В частности, по меньшей мере одни вариант механизма 170 экранного представления может предоставлять такие экранные представления 400, как, например, экранные представления, предназначенные для руководителей, менеджеров, пользователей и разработчиков. Экранное представление, предназначенное для руководителя, представляет графические отчеты о качестве данных для всей организации. Руководители могут изучить работу каждого сегмента в организации для сравнения их работы и причин проблем качества данных. Руководители также имеют доступ к модулям отчетов для менеджеров и пользователей. Экранное представление, предназначенное для менеджера, представляет собой графические отчеты о качестве данных в организации (организациях) и отделе (отделах) данного менеджера. Менеджеры могут изучить работу своих бизнес-подразделений и отделов и сравнить работу и причины проблем, например, качества данных. Экранное представление, предназначенное для пользователей, представляет собой графические отчеты о качестве данных, которые были введены пользователями в систему. Пользователи могут изучить конкретные проблемы и просмотреть входные и выходные данные и результирующие коды каждого этапа в процессе. Экранные представления, предназначенные для разработчиков, представляют графические отчеты о результатах всех процессов и этапов, так что разработчики могут анализировать результаты и вносить изменения в процесс для улучшения результатов. Разработчики могут корректировать последовательности функций, удалять функции, использовать функции от других поставщиков, добавлять новые функции от различных поставщиков и создавать сами новые функции.

Механизм 170 экранного представления может содержать пакеты статистического моделирования, которые можно использовать для добавления финансового эффекта данных, который подтверждается/корректируется и не подтверждается/не корректируется. По меньшей мере в одном варианте механизм 170 отображения можно реализовать с использованием технологии моделирующего экранного представления, например, Illumitek™ Corp. (Dulles, Virginia).

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

Система 100 управления бизнес-процессом предприятия может иметь возможность сравнения достоинств и недостатков функций и установок каждого поставщика в многоэтапном процессе с использованием продуктов множества поставщиков. Кроме того, система 100 управления бизнес-процессом предприятия может обеспечить быструю и легкую в использовании методику инсталляции продуктов и функций от множества поставщиков для ускорения реализации проектов бизнес-процессов. Следовательно, по меньшей мере один вариант системы 100 управления бизнес-процессом предприятия может быть независящим от поставщика и позволять пользователям осуществлять доступ ко всем функциям, включенным в дополнительные серверы или приложения предприятия, включая существующие продукты поставщиков бизнес-процессов, специализированных кодов или услуг. С помощью описанного в данном документе ориентированного на функцию принципа пользователь может создавать последовательность функций бизнес-процесса, например функций качества данных от различных поставщиков, в любом порядке, определенном с учетом потребностей каждого набора данных и источника данных. Кроме того, пользователь может создавать уникальные процессы 310 и этапы для каждого набора данных в источнике данных, как описано со ссылкой на фиг.11.

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

Система 100 управления бизнес-процессом предприятия может иметь графический пользовательский интерфейс (ГПИ), позволяющий пользователю создать процесс для приложения или набора данных из приложения. Пользователь может задать формат для данных и также может создать отдельные этапы процесса, вызвав специальную функцию (функции) и установку (установки) из имеющегося инструмента для каждого этапа. ГПИ можно реализовать с помощью, например, команд на языке Java®. Пользователь может повторять выполнение этапов создания до тех пор, пока не будет полностью определена и завершена процедура бизнес-процесса. Этот процесс можно представлять, отображать и оперировать им иерархическим способом, при котором один этап может представлять собой многоэтапный подпроцесс. Отображение и описание процесса можно представить на других устройствах вывода, например принтере. Отображение и описание процесса можно экспортировать для просмотра и манипуляции с помощью внешних приложений, таких как текстовый редактор, приложение построения блок-схем или веб-браузер. Затем пользователь может указать получателя (получателей) для результатов процесса и решить, какую информацию следует посылать каждому получателю. Результаты каждого этапа процесса могут регистрироваться в текстовом файле или массиве данных. Данные, сохраненные в текстовом файле или массиве данных, могут использоваться механизмом отображения, который может содержать программу визуализации для создания графических отчетов, которая содержит аналитическую информацию, статистическую информацию, отслеживание данных, анализ расходов и воздействие данных для различных уровней в организации. Эту информацию можно использовать для измерения и контролирования эффективности бизнес-процесса предприятия, например программы качества данных.

На фиг.39 показана взаимосвязь между интерфейсным модулем 304, сервером 101 бизнес-процесса предприятия и маршрутизатором 3905 в одном варианте изобретения. Как показано на фиг.39, входные данные 605 из источника данных, например бизнес-приложения, могут приниматься сервером 101 бизнес-процесса предприятия. В одном варианте входные данные 605 могут содержать идентификатор процесса, указывающий конкретный бизнес-процесс, к которому следует применять входные данные 605. Сервер 101 бизнес-процесса предприятия может быть выполнен с возможностью обнаружения идентификатора процесса во входных данных 605 и передачи входных данных 605 в указанный бизнес-процесс маршрутизатора 3905. В одном варианте маршрутизатор 3905 может содержать интегрированный набор команд, воплощающий один или более бизнес-процессов (например, процессы 1, 2 и 3, показанные на фиг.39). Команды для каждого бизнес-процесса могут содержать вызовы к инструментам 3910 (т.е. функциям), постоянно находящимся вне маршрутизатора 3905, для выполнения этапов процесса, а также к инструментам 3910, полученным из бизнес-приложений, внешних относительно маршрутизатора 3905, но постоянно находящимся в маршрутизаторе 3905.

По меньшей мере в одном варианте изобретения маршрутизатор 3905 может быть заменяемым маршрутизатором, в котором новые версии или загрузки для маршрутизатора 3905 могут заменять текущую версию маршрутизатора 3905 и вводиться в эксплуатацию и обрабатывать график данных без необходимости остановки сервера 101 (т.е. вывода из эксплуатации). Маршрутизатор 3905 может содержать набор команд для текущих активных бизнес-процессов, обеспечиваемых системой 100 управления бизнес-процессом предприятия. Новая версия маршрутизатора 3905 может быть создана и введена в эксплуатацию, чтобы начать обработку графика данных в соответствии с новым или модифицированным процессом. В одном варианте изобретения интерфейсный модуль 304 может создавать набор команд, воплощающий новый или модифицированный бизнес-процесс, в ответ на введенную пользователем информацию о функциях. Пользователь может ввести информацию о функциях с помощью, например, интерактивной страницы проектировщика процесса, предоставленной интерфейсным модулем 304. После замены текущей версии маршрутизатора новой версией входные данные 605 могут обрабатываться согласно новой версии маршрутизатора. Дополнительные детали, касающиеся замены текущей версии маршрутизатора новой версией маршрутизатора, описаны в связи с фиг.23a-d.

Проиллюстрированный на фиг.6 способ 600 может начинаться с того, что сервер 101 бизнес-процесса предприятия получает входные данные на этапе 605. Входные данные 605 можно получать из источника/получателя 305 данных.

Затем управление может перейти к этапу 610, на котором входные данные можно передать маршрутизатору процесса. На основании идентификатора процесса маршрутизатор процесса может направить входные данные в конкретный процесс 310 (например, процесс X). По меньшей мере в одном варианте маршрутизатор процесса позволяет легко и быстро модифицировать процессы и этапы без выключения сервера 101 (т.е. это заменяемый или оперативно заменяемый маршрутизатор).

Затем управление может перейти к этапу 615, на котором процесс 310 (например, процесс X) может получить входные данные и передать их на каждый этап многоэтапного процесса. Примером бизнес-процесса может служить процесс качества данных, такой как операция подтверждения адреса, в которой транзакционные данные (полученные из источника/получателя 305 данных, связанного с конкретным приложением предприятия) сравниваются с надежным источником, например базой данных почтовой службы США. Затем управление может перейти ко второму этапу 620 и после этого к следующим этапам (например, этапу N) 635. После каждого этапа в процессе 310 его результаты можно ввести в журнал 630 регистрации, например журнал 315 регистрации ошибок, и эти данные передаются на следующий этап. Результаты каждого этапа процесса 310 и журнал ошибок 315 могут содержаться в массиве 625 данных, таком как массив 160 данных. Как упоминалось выше, массив 625 данных (и массив данных 160) может быть, без ограничения перечисленным, базой данных оперативной аналитической обработки (ОАО) или сводной базой данных. Регистрация может включать в себя регистрацию сервером (например, регистрацию всех транзакций, принятых сервером, регистрацию статистики сервера), а также регистрацию процесса (например, подробную регистрацию каждого этапа в процессе, которую можно использовать для анализа транзакционных данных и возможностей продукта).

После завершения последнего этапа процесса 310 управление может перейти к этапу 640, на котором результаты процесса могут быть применены к структуре выходных данных. Выходные данные можно затем направить в источник/к получателю 305 данных, после чего обработка для способа 600 может закончиться.

По меньшей мере в одном варианте процесс 310 может содержать, без ограничения перечисленным, такие поля, как ROME_ID, ROME_TIME, SECT_CODE, SOURCE_DEST, SUB_SOURCE_DEST, RETURN_CODE и INPUT COMPONENT 1-N. Каждый этап процесса 310 может содержать, без ограничения перечисленным, такие поля, как ROME_UID, ROME_TIME, PRODUCT_ID, PRODUCT_RC, STEP_ID и OUTPUT COMPONENT 1-М. Каждый пакет данных может иметь уникальный идентификатор (например, «ROME_ID»), который можно использовать для отслеживания результатов множества посылок одного и того же пакета данных.

Как описано выше со ссылками на фиг.5, например, по меньшей мере в одном варианте изобретения сервер 101 бизнес-процесса предприятия может предоставлять отчеты об ошибках в соответствии с одним или более экранными представлениями 400. На фиг.7 показан пример отчета об ошибках на экранном представлении, предназначенном для руководителя, созданном согласно по меньшей мере одному варианту изобретения. Как видно на фиг.7, экранное представление 700 для руководителя может содержать один или более отчетов об ошибках, представляющих информацию об ошибках в данных для ряда отделов 705 предприятия. Например, примерное экранное представление 700 для руководителя, показанное на фиг.1, может представлять отчет об ошибках для отделов 705, включающих в себя отделы маркетинга, финансов, продаж, развития, веб-отделы и отделы поддержки потребителей, обеспечивающий запросившему пользователю (например, руководителю предприятия) обзор таких аспектов предприятия как, например, качество данных, чтобы можно было предпринять, например, корректирующие меры. По меньшей мере в одном варианте изобретения неверные или ошибочные записи могут маркироваться для указания, что они не были исправлены, и причины этого.

В частности, отчет об ошибках может представлять в численном и графическом виде с использованием таких инструментов, как графики 715 и 720, ранжирующий или статистический анализ ошибок, обнаруженных в заданном наборе данных приложения или транзакционных данных предприятия. Например, по меньшей мере в одном варианте система 100 управления бизнес-процессом предприятия может выполнять процессы анализа, которые предоставляют информацию запрашивающему пользователю, например, без ограничения перечисленным, ранги ошибок 720 в данных, обнаруженных для приложений в различных отделах 705, индикатор 710 интенсивности графика для транзакционных данных, проходящих в отдел 705 и из него, график 715 производительности, показывающий изменение производительности для каждого отдела 705 во времени, и классификацию 725 ошибок процесса по достоинствам и недостаткам, расходам и доходам, связанным с качеством данных для отделов 705.

Аналогично, на фиг.8-10 представлены примеры отчета об ошибках для экранного представления 800, предназначенного для поддержки пользователя, экранного представления 900, касающегося индивидуума, и экранного представления 1000, предназначенного для менеджера, соответственно, согласно по меньшей мере одному варианту изобретения. Элементы со ссылочными номерами, идентичными тем, которые имеются на фиг.7, соответствуют описанным выше элементам.

В частности, для экранного представления 900, касающегося индивидуума, система 100 управления бизнес-процессом предприятия может обеспечить обзор для запросившего пользователя, например, ошибок в данных, приписываемых конкретному индивидууму. Например, на фиг.9 показана классификация 725 ошибок процесса с указанием достоинств и недостатков, потерь и прибыли, связанных с конкретным индивидуумом 905, а также типы 910 ошибок, совершаемых индивидуумом 905, и количество ошибок, распределенных во времени 915, приписываемых данному индивидууму 905. Примерная классификация 725 ошибок в отчете об ошибках на фиг.9 показывает, что индивидуум 905 работает хорошо (т.е. делает мало ошибок) при вводе информации адреса, плохо (т.е. делает много ошибок) при вводе имен, допустил 80, 74 и 22 ошибки за разные периоды времени, и его ошибки в данных стоили предприятию 800 долларов.

Кроме того, для экранного представления 1000, предназначенного для менеджера, система 100 управления бизнес-процессом предприятия может предоставить обзор запросившему пользователю (т.е. менеджеру предприятия) ошибок в данных, приписываемых отдельным индивидуумам 905 и в группе. Например, на фиг.10 показана классификация 725 ошибок процесса с указанием достоинств и недостатков, потерь и прибыли, связанных с множеством индивидуумов 905, а также типы ошибок 910, совершенных каждым индивидуумом 905, и количество ошибок, распределенных во времени 915 (например, по времени суток), приписываемых данной группе. Можно также предоставить график 1005 потерь за период времени с указанием ежедневных потерь, понесенных предприятием из-за ошибок в данных, приписываемых каждому индивидууму 905.

По меньшей мере в одном варианте система 100 управления бизнес-процессом предприятия может предоставить возможность пользователю (например, административному пользователю) создавать и запускать бизнес-процессы 310 для исполнения сервером 101 бизнес-процесса предприятия. На фиг.11 представлен алгоритм способа 1100 запуска примерного процесса качества данных для системы 100 управления бизнес-процессом предприятия согласно по меньшей мере одному варианту. Способ 1100 может начинаться с этапа 1105 после того, как сервер 101 бизнес-процесса предприятия получит пользовательский запрос на создание процесса 310. Пользователь может ввести запрос на создание процесса 310, например, с помощью указательного устройства, для выбора соответствующей гиперссылки на интерактивной странице, обеспеченной частью графического пользовательского интерфейса в приложении 300 качества данных предприятия.

Затем управление может перейти к этапу 1110, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю создать имя процесса и выбрать источник данных для процесса 310. На фиг.12 представлен пример интерактивной страницы 1200, предоставленной сервером 101 бизнес-процесса предприятия, на которой пользователь может ввести имя процесса, описание и соответствующий источник 305 данных.

Затем управление может перейти к этапу 1115, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю ввести новый источник 305 данных, если это необходимо. Если пользователь реагирует путем запроса добавления нового источника 305 данных, управление может перейти к этапу 1120, на котором сервер 101 бизнес-процесса предприятия может создать и выдать интерактивную страницу 1300 для пользователя, чтобы он добавил источник 305 данных. На фиг.13 представлен пример интерактивной страницы 1300, предоставленной сервером 101 бизнес-процесса предприятия, на которой пользователь может добавить источник 305 данных путем ввода такой информации, как, без ограничения перечисленным, имя источника данных, описание, IP-адрес, номер порта и идентификатор платформы.

Затем управление может перейти к этапу 1125, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю создать входной пакет для процесса 310. На фиг.14 представлен пример интерактивной страницы 1400, предоставленной сервером 101 бизнес-процесса предприятия, на которой пользователь может создать входной пакет путем ввода информации атрибутов, таких как, без ограничения перечисленным, имя входного элемента, тип, длина и описание. Тип входного элемента может указывать тип данных для входного пакета, такой как, без ограничения перечисленным, булевы данные, символы, лигатура, широкие символы (юникод), десятичные числа с плавающей точкой, целые числа, длинные целые числа или короткие целые числа.

Затем управление может перейти к этапу ИЗО, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю создать выходной пакет для процесса 310. На фиг.15 показан пример интерактивной страницы 1500, представленной сервером 101 бизнес-процесса предприятия, на которой пользователь может создать выходной пакет путем ввода информации атрибутов, таких как, без ограничения перечисленным, имя выходного элемента, тип, длина и описание. Тип выходного элемента может указывать тип данных для выходного пакета, такой как, без ограничения перечисленным, булевы данные, символы, лигатура, широкие символы (юникод), десятичные числа с плавающей точкой, целые числа, длинные целые числа или короткие целые числа.

Затем управление может перейти к этапу 1135, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю выбрать продукт 315 (или функцию, или набор функций, в зависимости от ситуации) для связи с процессом 310. Продукт 315 может содержать функцию или набор функций. На фиг.16 показан пример интерактивной страницы 1600, предоставленной сервером 101 бизнес-процесса предприятия, с помощью которой пользователь может выбирать продукт 315 посредством ввода, как минимум, выбора продукта 315, например, из выпадающего списка, и описание продукта.

Затем управление может перейти к этапу 1140, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю добавить продукт 315, если это необходимо. Если пользователь реагирует путем запроса добавления продукта 315, управление может перейти к этапу 1145, на котором сервер 101 бизнес-процесса предприятия может создать и выдать интерактивную страницу 1700 для пользователя, предназначенную для добавления продукта 315. На фиг.17 показан пример интерактивной страницы 1700, предоставленной сервером 101 бизнес-процесса предприятия, на которой пользователь может добавить продукт 315 посредством ввода информации, такой как, без ограничения перечисленным, имя продукта, тип продукта, версия и шаблон продукта. В приложении А представлена примерная последовательность псевдокодовых команд для создания шаблона продукта.

Затем управление может перейти к этапу 1150, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю выбрать получателя 305 данных для процесса 310. На фиг.18 показан пример интерактивной страницы 1800, представленной сервером 101 бизнес-процесса предприятия, на которой пользователь может ввести имя и описание получателя данных.

Затем управление может перейти к этапу 1155, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю ввести нового получателя 305 данных, если это необходимо. Если пользователь отвечает просьбой добавить нового получателя 305 данных, управление может перейти к этапу 1160, на котором сервер 101 бизнес-процесса предприятия может создать и выдать интерактивную страницу (не показана), чтобы пользователь мог добавить получателя 305 данных посредством ввода информации, такой как, без ограничения перечисленным, имя получателя данных, IP-адрес, номер порта и описание. По меньшей мере в одном варианте все или часть данных, выданных сервером 101 бизнес-процесса предприятия, может направляться одному или более получателей 305 данных.

Затем управление может перейти к этапу 1165, на котором сервер 101 бизнес-процесса предприятия может предложить пользователю запустить процесс 310. На фиг.19 показан пример интерактивной страницы 1900, предоставленной сервером 101 бизнес-процесса предприятия, на которой пользователь может просматривать и подтверждать информацию, связанную с процессом 310, как было описано выше. Сводная информация процесса, предоставленная на странице 1900, может содержать, без ограничения перечисленным, имя процесса, его источник 305 данных, описание входных и выходных данных, соответствующий перечень продуктов 315 и пункт (пункты) назначения 305 данных для выхода процесса. После создания процесса 310 его можно отредактировать (т.е. отредактировать исходный код). Отредактированные команды процесса можно компилировать в маршрутизаторе процесса. По меньшей мере в одном варианте команды могут быть командами исходного кода.

Обработка для способа 1100 может заканчиваться этапом 1170.

Следует отметить, что вывод данных из описанных системы и способа может быть передан полностью или частично одному или более получателей 305. Иными словами, все выходные данные можно направить одному получателю 305. Альтернативно, части выходных данных можно направить множеству получателей 305.

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

По меньшей мере один вариант системы 100 управления бизнес-процессом предприятия может содержать интерфейсный модуль, пример которого описан более конкретно ниже. Интерфейсный модуль может также содержать аспекты пользовательского интерфейса, описанного выше. В одном варианте интерфейсный модуль 304 может быть реализован как компонент приложения 300 качества данных предприятия, как показано на фиг.3. Интерфейсный модуль может предоставлять пользователю средства определения, создания, изменения, тестирования и исполнения последовательности функциональных этапов для бизнес-процесса, использующего систему 100 управления бизнес-процессом предприятия. В частности, интерфейсный модуль может иметь интерактивный инструмент графически ориентированного описания процесса, который позволяет пользователю определять или изменять бизнес-процесс, например, путем выбора и перемещения (например, с использованием операции графического интерфейса «перетащить и оставить») символов, относящихся к функциям процесса в то место дисплея, которое представляет конкретный этап процесса. Каждый этап процесса может быть представлен, например, в виде одной или более функциональных пиктограмм, сгруппированных вместе, как показано в общем виде на фиг.20. На фиг.20 изображен примерный вариант интерактивного дисплея 2000 интерфейса проектировщика процесса, предусмотренный согласно по меньшей мере одному варианту изобретения. Следовательно, интерфейсный модуль проектировщика процесса можно использовать для определения или указания бизнес-процесса, который должна выполнять система 100 управления бизнес-процессом предприятия. В качестве оверлейного приложения к набору 303 инструментов разработчика интерфейсный модуль 304 может предоставлять интерактивные страницы, подобные изображенным на фиг.12-19, описанным выше, или в дополнение к ним.

В качестве функции может использоваться поименованный раздел программы, который выполняет определенную задачу. В этом смысле функция может быть процедурой или программой некоторого типа. Некоторые языки программирования делают различие между функцией, которая возвращает значение, и процедурой, которая выполняет некоторую операцию, но не возвращает значение. Большинство языков программирования имеет заранее написанный набор функций, который хранится в библиотеке. Можно также разработать специализированные функции для выполнения специальных задач. Например, в языке С и некоторых других языках программирования функцией является поименованная процедура, которая выполняет отдельный сервис. Оператор на языке, запрашивающий эту функцию, называется вызовом функции.

Представленный на фиг.20 интерактивный дисплей 2000 проектировщика процесса может содержать библиотеку 2005 функций, область 2010 ввода процесса, область 2015 определения этапа процесса и область 2020 вывода процесса. Каждый этап 2025 процесса может быть представлен, например, в виде одного или группы вводов 2030 функций, выводов 2040 функций и идентификаторов 2035 функций в области 2015 определения этапа процесса. Каждый ввод 2030 функции может быть (или может не быть) связан с входным элементом 2075 в области 2010 ввода процесса с помощью, например, связи 2045. Связь 2045 также упоминается как соединение или «путь». Аналогично, каждый вывод 2040 функции может быть (или может не быть) связан с выходным элементом 2080 в области вывода процесса 2020, например, с помощью связи 2045. В одном варианте связи 2045 можно использовать для представления направленного потока информации от источника получателю, например от входного элемента 2075 к вводу 2030 функции. Потоком информации может управлять по меньшей мере один маршрутизатор, который использует информацию заголовка пакета и таблицу маршрутизации для определения получателя или цели. Кроме того, этапы 2025 процесса могут быть связаны для формирования, например, цепочки последовательных этапов 2025 процесса, подлежащих последовательному выполнению в бизнес-процессе.

На фиг.25 показан пример интерактивной страницы обзора функций согласно одному варианту изобретения. Изображенная на фиг.25 страница 2500 обзора функций может предоставлять перечень всех функций, включенных в настоящее время в библиотеку 2005 функций. При этом функции могут быть упорядочены в соответствии с целым рядом критериев, например, в хронологическом порядке по времени их создания.

На фиг.26 показан пример части области определения процесса интерактивной страницы 200 проектировщика процесса, предусмотренной в одном варианте.

Каждый этап 2025 процесса может представлять конкретную операцию, которую должен выполнять сервер бизнес-процесса предприятия при исполнении данного этапа 2025 процесса. В частности, этап 2025 процесса может включать в себя один или более вводов 2030 функций и выводов 2040 функций. Кроме того, идентификатор 2035 функций может представлять конкретную операцию, подлежащую исполнению, с использованием ввода (вводов) 2030 функции для получения вывода 2040 (выводов) функций. В одном варианте система 100 управления бизнес-процессом предприятия может выполнять много различных этапов 2025 процесса от множества поставщиков приложений в одном бизнес-процессе. По меньшей мере в одном варианте идентификатор 2035 функции может служить для указания функций и элементов функций конкретного поставщика приложения, чье приложение (приложения) используется предприятием. Кроме того, система 100 управления бизнес-процессом предприятия может поддерживать множество бизнес-процессов.

По меньшей мере в одном варианте пользователь системы 100 управления бизнес-процессом предприятия может взаимодействовать с интерактивным дисплеем 200 проектировщика процесса для создания и изменения этапов 2025 процесса, которые образуют данный бизнес-процесс. В частности, пользователь может манипулировать, перемещать и связывать пиктограммы или символы дисплея, представляющие вводы 2030 функции, выводы 2040 функции, идентификаторы 2035 функции, входные элементы 2076, выходные элементы 2080 и связи 2045, используя, например, указательное устройство терминалов 110-113. Альтернативно, для этой цели можно использовать клавиатуру. Например, новый ввод 2030 функции можно добавить к этапу 2025 процесса путем перетаскивания с фиксацией по новому месту (например, выбора) ввода 2030 новой функции из библиотеки 2005 функций в требуемый этап 2025 процесса области 2015 определения этапа процесса. На фиг.27 показана примерная интерактивная страница проектировщика процесса 2000, иллюстрирующая добавление элемента этапа 2025 процесса из библиотеки 2005 функций согласно одному варианту изобретения. Если новый ввод 2030 функции требует наличия элемента 2075 ввода, то пользователь может, например, перетащить требуемый элемент 2075 ввода из библиотеки 2005 функций в область 2010 ввода и добавить связь 2045 от элемента 2075 нового ввода к новому вводу 2030 функции. На фиг.28 показан пример интерактивной страницы 2000 проектировщика процесса, иллюстрирующий связывание этапов 2025 процесса в области определения процесса интерактивной страницы проектировщика процесса, согласно одному варианту изобретения.

В одном варианте ввод 2030 функции может содержать условный оператор для указания альтернативных действий, которые следует предпринять после того, как произошло (или не произошло) указанное событие. На фиг.29 показан пример части 2900 интерактивной страницы, с помощью которой можно определить условный оператор для элемента этапа процесса, согласно по меньшей мере одному варианту изобретения.

На фиг.30 показан пример интерактивной страницы 3000 определения продукта в варианте, подобном изображенному на фиг.17. На фиг.31 показан пример интерактивной страницы 3100 определения получателя данных в варианте, подобном изображенному на фиг.18. На фиг.32 показан пример интерактивной страницы 3200 выбора продуктов в варианте, подобном изображенному на фиг.16.

По меньшей мере в одном варианте система 100 управления бизнес-процессом предприятия может находить, создавать и компилировать из массива данных, например, такого как массив 106 данных, последовательность команд, реализующую бизнес-процесс, который определен проектировщиком процесса интерфейсного модуля. В одном варианте интерфейсный модуль 304 сервера 101 бизнес-процесса предприятия может получить последовательность команд, реализующую один или более бизнес-процессов, которые определены, например, с помощью интерфейсного модуля из массива 106 данных, для исполнения сервером 101 бизнес-процесса предприятия.

По меньшей мере в одном варианте интерфейсный модуль 304 может компоновать (т.е. строить) последовательность команд, реализующую этапы 2025 процесса, определенные проектировщиком процесса интерфейсного модуля, в виде последовательности этапов построения с использованием ряда файлов построения. На фиг.21 показан набор файлов построения, использованных в одном варианте сервером бизнес-процесса предприятия для построения кодовой реализации бизнес-процесса. На фиг.21 набор файлов построения для бизнес-процесса может в одном варианте содержать по меньшей мере один файл (файлы) 2050 построения временных этапов, файл 2055 этапов процесса, один или более файлов 2060 атрибутов функции, один или более временных файлов 2065 соответствующей функции и файл 2070 процесса. Система 100 управления бизнес-процессом предприятия может использовать эти файлы в одном варианте для реализации бизнес-процесса, определенного бизнес-аналитиком, например, с помощью проектировщика процесса интерфейсного модуля, следующим образом.

В одном варианте все функции, которые были добавлены к системе управления бизнес-процессом предприятия, могут появиться в библиотеке 2005 функций (фиг.20). Каждая функция может быть идентифицирована в библиотеке 2005 функций, например, именем функции и пиктограммой. Файл 2060 атрибутов функции может содержать всю необходимую информацию, например, в формате XML, так что при добавлении этой функции в качестве этапа в процесс функция будет отображаться на проектировщике 200 процесса интерфейсного модуля с правильным количеством вводов 2030 функции, выводов 2040 функции и будет иметь соответствующие установки, определенные параметрами содержания полей данных, использованных или созданных данной функцией. В одном варианте каждая функция в системе 100 управления бизнес-процессом предприятия имеет собственный файл 2060 атрибутов функции. Этап 2025 функции показывает пример функции, как она появляется при использовании проектировщика 2000 процесса интерфейсного модуля при добавлении в качестве этапа к бизнес-процессу. Когда функция добавляется к бизнес-процессу, интерфейсный модуль 304 сначала считывает файл 2060 атрибутов функции для данной функции. После считывания файла 2060 атрибутов функции интерфейсный модуль 304 создает необходимые элементы ввода и вывода для этой функции, как они определены в файле 2060 атрибутов функции.

В одном варианте интерфейсный модуль 304 может содержать мастер функции, который предоставляет последовательность интерактивных страниц пользователю, чтобы помочь ему импортировать ранее созданную функцию в библиотеку или изменить существующую функцию. Мастер функции может содержать интерактивные поля одной или более интерактивных страниц, в которые пользователь может ввести имя функции, выбрать пиктограмму функции, ввести соответствующее имя продукта, ввести тип функции и добавить описание функции. Мастер функции может предоставить шаблон функции в ответ на введенную пользователем информацию. Шаблоны функций могут поддерживаться, например, с помощью файлов 2065 шаблонов функций. Шаблон функции может содержать последовательность команд, которые определяют различные аспекты функции (например, переменные). Действительные значения для каждой переменной функции можно определять по установке функции, которая соответствует каждой переменной функции. На фиг.23 показан пример содержания страницы 3300 файла шаблонов функций, предусмотренного в одном варианте изобретения.

После добавления функции к бизнес-процессу можно создать файл 2050 временного этапа. В одном варианте файл 2050 временного этапа может быть в формате XML. Файл 2050 временного этапа может содержать всю информацию о данной функции, касающуюся данного этапа бизнес-процесса. Важно отметить, что файл временных этапов может быть различным для каждого этапа, даже если он исходит из одной и той же функции.

Кроме того, как показано на фиг.21, интерфейсный модуль 304 может создать файл 2055 этапов процесса, когда необходимо создать бизнес-процесс. В одном варианте файл 2055 этапов процесса может быть объединенной группой файлов 2050 временных этапов, связанной с этим бизнес-процессом.

И, наконец, интерфейсный модуль 304 может создать файл 2070 набора команд процесса следующим образом. Сначала интерфейсный модуль 304 может считать файл 2055 этапов процесса. Так как каждый этап в нем может соответствовать функции в библиотеке функций, интерфейсный модуль может найти файл 2060 атрибутов функции для каждого этапа в файле 2055 этапов процесса и затем отобразить данные файла 2055 этапов процесса на соответствующие поля файла 2060 атрибутов функции. Затем, после того как информация из файла 2055 этапов процесса была связана с соответствующими полями файла 2055 атрибутов функции, интерфейсный модуль 304 может отобразить каждый файл 2060 атрибутов функции на файл 2065 шаблона функции. Файл 2065 шаблона функции может в одном варианте содержать команды исходного кода (например, исходного кода С) для добавления к последовательности команд, реализующих процесс. Кроме того, согласно по меньшей мере одному варианту изобретения, файл 2065 шаблона функции может иметь XML-теги, которые соответствуют полям в соответствующем файле 2060 атрибутов функции. После добавления исходного кода файла шаблона функции к исходному коду в файле 2070 набора команд процесса, интерфейсный модуль 304 может заменить XML-теги в файле 2065 шаблона функции данными, которые были предоставлены в файле 2060 атрибутов функции, которые, в свою очередь, являются данными, полученными из файла 2055 этапов процесса.

В одном варианте изобретения после создания нового файла 2070 набора команд процесса приложение 300 качества данных предприятия может создать новый DLL-маршрутизатор, включающий в себя новый файл 2070 исходного кода процесса, показанный на фиг.22. По меньшей мере в одном варианте файл 2070 набора команд может содержать команды исходного кода. В соответствии с фиг.22 приложение 300 качества данных предприятия может создать новый DLL-маршрутизатор 2071, включающий в себя новый файл 2070 набора команд процесса (например, файл 1 процесса) вместе с другими файлами набора команд процесса (например, файлами 2-К процесса). Новый DLL-маршрутизатор 2071 может затем загружаться сервером 101 бизнес-процесса предприятия и предоставляться для использования для исполнения нового процесса.

На фиг.23a-d представлена блок-схема, иллюстрирующая более конкретно способ реализации бизнес-процесса согласно по меньшей мере одному варианту изобретения. На фиг.23 способ может начинаться с этапа 2300 и переходить к этапу 2302. На этапе 2302 пользователь может послать запрос в сервер 101 бизнес-процесса предприятия на создание или изменение бизнес-процесса. В одном варианте запрос пользователя может быть передан терминалом 110, 111, 112 или 113 в сервер 101 бизнес-процесса предприятия с помощью сети, например сети на пакетной основе. Примером пакетной сети является Интернет. Пользователь может быть, например, бизнес-аналитиком. В одном варианте запрос может быть представлен в формате XML. В ответ сервер 101 бизнес-процесса предприятия может выдать в запросивший терминал 110, 111, 112 или 113 интерактивную страницу, например интерактивный дисплей 2000 проектировщика процесса интерфейсного модуля. В одном варианте интерактивный дисплей 2000 проектировщика процесса интерфейсного модуля может быть представлен в виде интерактивной страницы формата XML, пригодной для отображения на терминале с использованием приложения веб-браузера терминала.

Затем управление может перейти к этапу 2304, на котором пользователь может пожелать добавить этап процесса или модифицировать этап бизнес-процесса (см. фиг.20). Затем управление может перейти к этапу 2306, на котором пользователь может определить, что функция, которую следует прибавить к этапу процесса или для которой следует прибавить новый этап процесса, должна быть добавлена в библиотеку функций. В этом случае управление может перейти к этапу 2308. В противном случае управление может перейти к этапу 2312.

На этапе 2308 пользователь может ввести информацию, определяющую новую функцию, в библиотеку функций. Такая информация может включать в себя, без ограничения перечисленным, имя функции и пиктограмму функции. Имя функции может представлять собой краткое описание операции, обеспечиваемой данной функцией. Пиктограмма функции может быть символом, представляющим поставщика приложения, из которого взята эта функция. В одном варианте все функции, используемые в этапах процесса, должны быть включены в библиотеку функций.

Затем управление может перейти к этапу 2310, на котором пользователь может определить конкретные атрибуты функции с использованием файла атрибутов функции. Файл атрибутов функции может включать в себя всю информацию, необходимую для определения информации функции, в формате XML, так что при добавлении этой функции в качестве этапа в бизнес-процесс функция будет отображаться на проектировщике процесса интерфейсного модуля с правильным числом вводов функции и выводов функции, а также с соответствующими установками функции. В одном варианте файл атрибутов функции может быть представлен в формате XML. Также в одном варианте каждая функция в библиотеке функций может иметь соответствующий файл атрибутов функции. На фиг.34 показан пример интерактивной страницы 3400 установок функций, предусмотренной в одном варианте.

Затем управление может перейти к этапу 2312, на котором может быть создан файл временного этапа следующим образом. Когда к бизнес-процессу добавляется функция, интерфейсный модуль может сначала считать файл атрибутов функции для данной функции. После чтения файла атрибутов функции интерфейсный модуль может создать необходимые элементы ввода и вывода для данной функции, как они определены в файле атрибутов функции. В одном варианте файл временного этапа может быть представлен в формате XML. Файл временного этапа может содержать всю информацию о функции, относящейся к этому этапу в бизнес-процессе. Важно отметить, что файл временных этапов может быть различным для каждого этапа, даже если он исходит из одной и той же функции.

Затем управление может перейти к этапу 3214, на котором интерфейсный модуль может создать файл этапов процесса. В одном варианте файл этапов процесса может быть объединенной и составленной группой файлов временного этапа, связанных с данным бизнес-процессом.

Затем управление может перейти к этапу 3216, на котором интерфейсный модуль может найти файл атрибутов функций для каждого этапа в файле этапов процесса. После этого управление может перейти к этапу 2318, на котором интерфейсный модуль может отобразить данные файла этапов процесса на соответствующие поля файла атрибутов функции. Затем управление может перейти к этапу 2320, на котором интерфейсный модуль может отобразить каждый файл атрибутов функции на файл шаблона функции. Файл шаблона функции может в одном варианте содержать команды исходного кода (например, исходного кода С), подлежащие добавлению к последовательности команд, реализующих этот процесс. Кроме того, по меньшей мере один вариант файла шаблона функции может содержать XML-теги, которые соответствуют полям в соответствующем файле атрибутов функции.

Затем управление может перейти к этапу 2322, на котором интерфейсный модуль может заменить XML-теги в файле шаблона функции данными, которые были предоставлены в файл атрибутов функции, которые в свою очередь являются данными, взятыми из файла этапов процесса.

Затем управление может перейти к этапу 2324, на котором интерфейсный модуль может скомпоновать заполненные данными файлы шаблона функции в файл набора команд процесса, содержащий последовательность программных команд, реализующих данный процесс. Затем управление может перейти к этапу 2326, на котором интерфейсный модуль может сохранить файл набора команд процесса в массиве данных. Файл набора команд может быть, без ограничения, файлом исходного кода.

Затем управление может перейти к этапу 2328, на котором приложение ядра приложения качества данных предприятия может определить, указал ли пользователь данный бизнес-процесс как тестовый или производственный. В одном варианте модуль 304 бизнес-аналитика может предоставить пользователю интерактивную страницу (не показана) для указания, следует ли выполнять тестовое или производственное построение маршрутизатора. Если процесс тестовый, управление может перейти к этапу 2330, изображенному на фиг.23с. Если процесс производственный, управление может перейти к этапу 2350 на фиг.23d.

На этапе 2330 фиг.23с, на котором после построения нового файла набора команд для тестового процесса приложение ядра приложения качества данных предприятия может построить новый DLL-маршрутизатор, включающий в себя новый файл набора команд тестового процесса (см. фиг.22). Набор команд тестового процесса можно оптимизировать для производства.

Затем управление может перейти к этапу 2332, на котором интерфейсный модуль может известить сервер бизнес-процесса предприятия, что новый маршрутизатор готов к загрузке. Затем управление может перейти к этапу 2334, на котором сервер бизнес-процесса предприятия может сделать паузу и остановить ввод всех транзакций в текущий маршрутизатор, позволив закончить обработку всех транзакций, находящихся в маршрутизаторе в настоящее время, и разгрузить текущий маршрутизатор.

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

Затем управление может перейти к этапу 2338, на котором после получения извещения, что текущий маршрутизатор разгружен, интерфейсный модуль может архивировать текущий (т.е. «старый») маршрутизатор, заменить его вновь созданным маршрутизатором и известить сервер бизнес-процесса предприятия о загрузке нового маршрутизатора.

Затем управление может перейти к этапу 2340, на котором сервер бизнес-процесса предприятия может загрузить и инициализировать новый маршрутизатор и разрешить ввод транзакций в новый маршрутизатор.

Затем управление может перейти к этапу 2342, на котором сервер бизнес-процесса предприятия может известить интерфейсный модуль о том, что новый маршрутизатор загружен.

Затем управление может перейти к этапу 2344, на котором после получения извещения о том, что новый маршрутизатор загружен, интерфейсный модуль может выдать в терминал пользователя интерактивную страницу тестера процесса. На фиг.35 показана примерная интерактивная страница 3500 тестера процесса согласно одному варианту. Интерактивная страница 3500 тестера процесса может содержать список 3505 этапов тестирования процесса.

Затем управление может перейти к этапу 2346, на котором терминал может выдать интерактивную страницу тестера процесса пользователю через, например, дисплей приложения веб-браузера. На фиг.36 показана заполненная данными область определения процесса на интерактивной странице 3500 тестера процесса в одном варианте, в котором интерфейсный модуль заменил XML-теги в файле шаблона функции данными, которые были представлены в файле атрибутов функции.

Затем управление может перейти к этапу 2348, на котором способ может быть завершен.

На этапе 2350 на фиг.23d после создания нового файла набора команд процесса производства приложение ядра приложения качества данных предприятия может построить новый DLL-маршрутизатор, содержащий новый файл набора команд процесса производства (см. фиг.22). Набор команд процесса производства можно оптимизировать для производства.

Затем управление может перейти к этапу 2352, на котором интерфейсный модуль может известить сервер бизнес-процесса предприятия о том, что новый маршрутизатор готов к загрузке. Затем управление может перейти к этапу 2354, на котором сервер бизнес-процесса предприятия может сделать паузу и остановить ввод всех транзакций в текущий маршрутизатор, позволив закончить обработку всех транзакций, находящихся в настоящее время в маршрутизаторе, и разгрузить текущий маршрутизатор.

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

Затем управление может перейти к этапу 2358, на котором после получения извещения о том, что текущий маршрутизатор разгружен, интерфейсный модуль может архивировать текущий (т.е. «старый») маршрутизатор, заменить его вновь созданным маршрутизатором и известить сервер бизнес-процесса предприятия о загрузке нового маршрутизатора.

Затем управление может перейти к этапу 2360, на котором сервер бизнес-процесса предприятия может загрузить и инициализировать новый маршрутизатор и разрешить ввод транзакций в новый маршрутизатор.

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

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

Затем управление может перейти к этапу 2366, на котором терминал может выдать интерактивную страницу главных процессов пользователю через, например, дисплей приложения веб-браузера.

Затем управление может перейти к этапу 2368, на котором способ может быть завершен.

По меньшей мере в одном варианте сервер 101 бизнес-процесса предприятия может находить и исполнять конкретный бизнес-процесс после получения пакета входных элементов, связанных с этим бизнес-процессом, из источника данных через соединение. По меньшей мере в одном варианте изобретения такое соединение может быть файлом динамически подключаемой библиотеки (DLL-файлом), который отображает входные данные и выходные данные функции бизнес-приложения на соответствующие информационные поля функций соответствующего бизнес-процесса. На фиг.37 показан пример интерактивной страницы 3700 определения соединения, с помощью которой пользователь может определить соединение, согласно по меньшей мере одному варианту. Каждое приложение предприятия может иметь соответствующее соединение, поддерживаемое, например, с использованием массива 106 данных, которое отображает свои функции на один или более бизнес-процессов, исполняемых сервером 101 бизнес-процесса предприятия. После получения соответствующего пакета входных элементов сервер 101 бизнес-процесса предприятия может найти и исполнить соответствующий бизнес-процесс и сформировать его результирующие выходные элементы. В одном варианте сервер 101 бизнес-процесса предприятия может послать пакет, содержащий выходные элементы, получателю данных через соединение для дальнейшей обработки. Соединение может инкапсулировать информацию маршрутизации данных, указывающую путь между узлами предприятия. В одном варианте соединение может быть штепсельным соединением для пакетной сети, например TCP/IP.

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

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

Например, один вариант системы управления бизнес-процессом предприятия может быть направлен на приложения биометрического и охранного характера, например, без ограничения перечисленным, определение, создание и исполнение бизнес-процессов, которые включают в себя функции из бизнес-приложений, использующих анализ отпечатков пальцев, сканирование/визуализацию сетчатки глаз, идентификацию голоса, а также сопоставление и сравнение внешних признаков. В конкретном примере такого бизнес-процесса работника компании могут попросить предоставить отпечаток пальца, чтобы он мог войти на территорию компании. Когда работник помещает палец на сканер отпечатка пальца, данные, представляющие уникальное сканированное изображение, могут быть отправлены в процесс, поддерживаемый системой управления бизнес-процессом предприятия. Этот процесс может включать в себя, например, сравнение данных сканированного отпечатка пальца с набором действительных отпечатков с помощью одной или более функций из разных инструментов программ сопоставления отпечатков, которые пытаются подтвердить аутентичность личности работника по базе данных отпечатков пальцев работников предприятия. Если личность работника подтверждена, то может быть послан сигнал из системы управления бизнес-процессом предприятия в устройство управления доступом к двери, чтобы разблокировать дверь и позволить работнику войти.

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

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

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

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

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

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

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

И, наконец, в другом примере вариант системы управления бизнес-процессом предприятия может быть направлен на приложения отображения на основе программного обеспечения, например, без ограничения перечисленным, на определение, построение и исполнение бизнес-процессов, которые включают в себя функции из бизнес-приложений, применяющих программное обеспечение сопоставления информации и поиска по базе данных. В конкретном примере такой бизнес-процесс может включать в себя сопоставление информации и просмотры массивов данных на наличие информации, связанной с операциями центра обработки вызовов. В частности, оператор центра обработки вызовов может принять вызов от потребителя, в котором потребитель предоставляет оператору центра вызовов информацию имени и адреса. Оператор центра вызовов может ввести эту информацию с помощью, например, интерактивной страницы, а затем инициировать запрос о поиске. Запрос о поиске может вызвать посылку информации имени и адреса в бизнес-процесс, поддерживаемый системой управления бизнес-процессом предприятия, который может выполнить, например, следующие операции:

а) стандартизировать данные имени и адреса,

b) создать ключ соответствия,

с) выполнить последовательность просмотров баз данных с помощью ключа соответствия, созданного на этапе b,

d) каждый просмотр базы данных возвратит некоторую информацию, которая будет использована для создания временной записи,

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

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

Кроме того, по меньшей мере в одном варианте сервер бизнес-процесса может быть выполнен с возможностью выбора и исполнения набора предпочтительных функций, каждая из которых получена из одного из множества различных бизнес-приложений. Сервер бизнес-процесса может выбрать одну функцию из множества подобных функций, предоставляемых бизнес-приложениями, например, на основании эвристического выбора. Примером такого эвристического выбора может быть процент ошибок, обнаруженных функцией, при сравнении множества подобных функций, применяемых к данному набору выходных данных бизнес-приложения. Каждое из бизнес-приложений может являться или не являться продуктом разных поставщиков. Альтернативно, критерии выбора функции могут быть указаны пользователем через интерактивную страницу интерфейсного модуля. Таким образом, система управления бизнес-процессом предприятия может выбрать набор предпочтительных или «лучших аналогов» из предлагаемых различными бизнес-приложениями.

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

ПРИЛОЖЕНИЕ А

Схема шаблона продукта

Компилировать тип связи

Заголовок раздела /*Тип связи*/

Время выполнения: Если вы связываетесь с DLL без использования заголовков или lib. файлов

Время компиляции: Если продукт, который вы вызываете, имеет заголовки и lib. файлы

Местоположения файла

Заголовок раздела /*Местоположения файла*/

Заголовок =: Предоставить местоположение файла заголовка

Lib =: Предоставить местоположение lib. файла

Глобальные определения

Заголовок раздела: /*Глобальные определения*/

Здесь вы будете определять любые глобальные переменные, которые должны использоваться всеми процессами

См. примеры

Глобальные переменные инициализации

Заголовок раздела: /*Глобальные переменные инициализации*/

Этот раздел используется, если вам нужно определить любые переменные инициализации, которые должны использоваться всеми процессами

См. примеры

Глобальная функция (функции) инициализации

Заголовок раздела: /*Глобальная функция (функции) инициализации*/

Вызовы функции к продукту, которые используются всеми процессами

См. примеры

Глобальные переменные завершения

Заголовок раздела: /*Глобальные переменные завершения*/

Этот раздел используется для определения любых переменных, которые требуются для глобальных функций завершения

Глобальная функция (функции) завершения

Заголовок раздела: /*Глобальная функция (функции) завершения*/

Вызовы функции к продуктам, которые используются всеми процессами

Заголовки

Заголовок раздела: /*3аголовки*/

Здесь определяются имена заголовков

Пример: # включить «3аголовок.h»

См. примеры

Переменные

Заголовок раздела: /*Переменные*/

Здесь вы определяете переменные, подлежащие использованию данным продуктом

Выделение памяти

Заголовок раздела: /*Выделение памяти*/

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

Установка для вызова функции

Заголовок раздела: /*Ввод*/

Здесь вы устанавливаете параметры, которые должны быть переданы в продукт

Вызов продукта

Заголовок раздела: /*Функция (функции)*/

Сюда направится вызов функции к продукту

См. примеры

Вывод вызова функции

Заголовок раздела: /*Вывод*/

Сюда вы будете копировать результаты вызова функции к выходному пакету при необходимости

См. примеры

Освобождение памяти

Заголовок раздела: /*Освобождение памяти*/

Если вы выделили память для любой структуры данных выше, то освободите их здесь

Изобретение относится к управлению бизнес-процессом предприятия, а именно к определению и исполнению бизнес-процессов, образованных из одного или более бизнес-приложений, имеющихся на предприятии. Техническим результатом является повышение эффективности проведения бизнес-процессов. Система содержит сервер, маршрутизатор и интерфейс для определения и исполнения таких бизнес-процессов. Бизнес-процесс качества данных обнаруживает, корректирует, анализирует и сообщает качественные и количественные характеристики прикладных данных и транзакционных данных, имеющихся на предприятии. Предусмотрен интерфейсный модуль, с помощью которого пользователь может выбирать и определять информацию определения функции для бизнес-процесса. 2 н. и 26 з.п. ф-лы, 39 ил.

1. Система управления бизнес-процессом предприятия, содержащая

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