JP2005510810A - 顧客業務プロセスをコンピュータにより評価するための方法及び装置 - Google Patents

Abstract

コンピュータシステムを使用して電子的な業務プロセスをコンピュータにより評価するための方法及び装置が提供される。コンピュータシステムに到来する業務プロセス（ＧＰ）に包含されている業務プロセスに関連するデータを検査するために、第１の検査ステップではデータの静的な検査が特徴識別に基づき行われ、検査された各データの内容についての仮説が立てられ、第２の検査ステップでは立てられた仮説の動的な検査が行われる。本発明によれば、電子的に識別されたデータ内容の調整が知識ベース（２００）に包含されている顧客固有／資料固有のデータを用いて行われる。

Description

本発明は電子的な顧客業務プロセスをコンピュータにより評価するための方法及び装置並びに、コンピュータシステムにおいて実行する際に本発明による方法の実施に適しているプログラムコードを有するコンピュータプログラム及びこのようなコンピュータプログラムを有する記憶媒体に関する。

本発明の枠内での「評価」の概念は、業務プロセスの識別、構造化及び処理を含む。業務プロセスは例えば注文、納品計画、納品書、注文の変更、照会などと解される。ここでは顧客を表す部門と供給者を表す部門との間の会社内部の過程と、個々の会社とこれらの会社の外部の顧客との間の過程は全く同様に扱うことができる。本発明によるシステムを用いて処理できる過程は業務的且つ産業的な生活の考えられる全ての領域にわたる。殊に本発明によるシステムは産業的な製造プロセス及び生産プロセスの制御と関連しても適している。

いわゆる顧客業務プロセスを評価する際に通常の場合には、関与する２つの側（顧客／発注側と業務受託者／受注側）の少なくとも一方において人間による中間処理が必要である。これの例外がいわゆるシステム・ツー・システムプロセス（Ｓ２Ｓプロセス）であり、このプロセスでは相互に調整された２つの会社システム（ＥＲＰシステム：ＥＲＰ、企業資源計画）が直接相互に通信して、データを交換する。図１は典型的な顧客業務プロセスにおける通信経路の概略図を示す。図１の概略図の左側の部分には顧客（発注側）が表されており、右側には注文を受け取る会社（受注側）が示されている。両方の側においては前述のＳ２Ｓプロセスの場合を除き、人的な処理による関与が通常必要とされる。相互に調節されたＥＲＰシステムが両方の側で使用される場合（これは通常の場合注文量の多い大口顧客の場合にのみ経済的に有用である）には、場合によってはインターネット又はテレファックスによっても行われる業務プロセスも、両方の側の内の少なくとも一方における人的な処理による介入を省略することができる。

殊にＥメール（電子郵便）及びテレファックスを使用して行われる業務プロセスでは、人的な介入の問題が明らかになる。典型的には顧客側においてＥメール又はファックスメッセージが従業員によって（通常の場合コンピュータ、ワークステーションの使用により）作成されて、受注者に伝送される。受注側では同様にして典型的に、到着したＥメール又はテレファックスが従業員によって処理され、関連するデータが会社固有のシステムに供給される。したがって本来は電子的に作成されたデータが新たに人的な介入によって電子データ処理装置に供給される。顧客側において受注者によって用意された、受注者のＥＲＰシステムに調節されている電子的なフォームが使用される場合のみ、到着したＥメールないしテレファックスを直接的に受注者のＥＲＰシステムによってさらに処理することができる。

電話による従来の注文の場合には、顧客が注文を口頭で受注者の従業員に伝え、この従業員が注文を受注者の元に設けられている社内注文システムに入力する。注文を受領する企業内の構造に応じて、注文をシステムに入力する前に担当者へと転送しなけれればならず、この場合その担当者が注文を入力する。顧客は公式の注文受領通知書を注文のシステム入力後に漸く受け取る。

インターネットを介する注文（Ｅコマース・ソリューション）の場合には、顧客はマニュアルでブラウザを介して伝送すべき情報を入力する。このソリューションでは、顧客が通常の場合既に顧客固有の注文システムにおいてエントリを行っているので、既に行ったエントリを再度マニュアル入力しなければならず、顧客に付加的な手間を掛けることになる。

したがって実際には顧客の電子データ処理システムを受注者の相応のシステムに直接的に接続することは非常に困難であることが証明されている。顧客は通常の場合、自身の電子データ処理ハードウェア及びソフトウェアへの必要とされる投資を行うことは既に容易ではない。また顧客は通常の場合、顧客の元に存在する大部分は支店固有の電子データ処理規格を受注者には慣用である規格に適合することも既に容易ではない。他方では、殊に統一されていない顧客集団を持つ潜在的な受注者にとって、顧客の需要及び顧客の電子データ処理システムに調節されている社内規格を導入することも同様に困難である。

ＤＥ１９７ ０６ ４１９ Ａ１からは、機械的な音声処理のための技術を使用する業務プロセスを制御するための方法が公知である。公知の方法では業務プロセスのアクティビティの条件の内の少なくとも１つが自動的に検査される。

さらには市場では、電子的な受領郵便処理の枠内において、到来した業務ドキュメントがスキャンされ、これに続いて自動的に識別、評価され、更なる処理のために管轄の担当者へと転送されるシステムが公知である。

これに対して本発明によれば、請求項１及び６ないし９及び１４記載の特徴を有する、顧客業務プロセスをコンピュータにより評価するための方法及び装置が提供され、この方法及び装置を用いることにより、到来した注文の受注側における処理の際の人的な処理による介入を回避することができ、顧客は受注側の所定のデータ構造又はフォームを有する必要は無い。注文は電子郵便（Ｅメール）、テレファックスによって又は電話でも行うことができる。

相応に、コンピュータシステムに入力される業務プロセス（ＧＰ）へと包含される業務プロセスに関連するデータを検査するために、第１の検査ステップでは特徴識別に基づいてデータを静的に検査して、検査される各データの内容についての仮説を立て、第２の検査ステップでは、この立てられた仮説の動的な検査を行う。本発明の別の実施形態では、コンピュータシステムに入力される業務プロセス（ＧＰ）へと包含される業務プロセスに関連するデータを検査するために、知識ベース（２００）に包含される顧客固有及び／又は資料固有のデータを用いて、電子的に識別されたデータ内容の調整が行われる。

このために本発明によれば、受注者の元に設けられている注文システム（また必要に応じて、データバンクを包含する別の既存の電子データ処理システム）が画像及び／又はテキスト識別システムと組み合わせられる。この画像及び／又はテキスト識別システムは必要とされる情報及びデータを受注者に到着した顧客のフォームから抽出し、直接的且つ人的な介入無しに会社固有のＥＲＰシステムを使用することができる。

本発明の有利な実施形態では、既存の注文システムが電話（音声）識別システムと組み合わせられる。この電話（音声）識別システムは電話による音声及び／又はキー入力を識別し、必要に応じて内部注文システムが処理できるディジタルデータに変換する。

有利には受注者の電子データ処理システムと付加的に設けられている本発明による識別システムとの間では、有利には規則的なデータの交換及びデータの調整が行われ、これにより顧客データの識別におけるエラー率は著しく低減され、したがって処理速度が改善される。

本発明の別の有利な実施形態においては、画像及び／又はテキスト識別システムがフォーマット化されていない注文及び他の業務プロセス（例えばボディコピーに記述された手紙又はＥメール）において顧客及び関連する注文指示を識別し、受注者の会社固有のシステムに転送することができる。このことは、既存のシステム（例えば企業ウェアハウスシステム）から顧客及び／又は資料固有の指示が供給されるデータバンクを使用することにより達成することができる。これによって到着したドキュメントにおいて識別された情報及びデータを調整することができ、必要に応じて修正又は補完することができる。データの調整はウェアハウスシステムにファイルされている蓄積データ及び履歴情報に基づき行われる。この実行ロジックによってシステムは例えば顧客を独立して識別し、注文の内容を完全に且つ誤りなく解釈し、会社固有のＥＲＰシステムに関する注文を自動的に発生させることができる。したがって本発明によれば蓄積データシステム及びいわゆるデータウェアハウス（これは、積年の値でありまた有利には照会及び分析に使用される、構造化されて分散された膨大なデータストックと解される）が識別システムと接続される。

識別システムにより提供される識別は本発明によれば２つのステップで実行される。第１のステップではそれ自体公知の特徴識別が行われ、この特徴識別では顧客から伝送された情報が会社システムの理解できるフォーマットに変換される。このことは例えばいわゆるＯＣＲソフトウェア（ＯＣＲ：光学特徴認識、Optical Character Recognition）に基づき、すなわち平分の光学的な識別に基づき行われる。第２のステップではドキュメントの内容、すなわち伝送されたデータ及び情報の意味論的な識別が行われる。このステップは有利には人工知能、意味論的なテキスト識別ないしファジイ調整と結びつけることによって、また（履歴情報に関する）蓄積データシステム及びデータウェアハウスとの接続によって実現される。これらのステップに続いて、２つの識別ステップによって取得された「知識」が受注者の社内システムの理解できるフォーマットに変換される。ここで説明した本発明による経過は図２に示された非常に概略的な機能図で表されている。

図３は若干多少詳細に表した概略的な機能図であり、この機能図では殊に識別システムの領域における経過の部分がより詳細に示されている。識別システム（図３の表示においては単に「システム」と表されている）は顧客業務プロセスＧＰを引き受ける。（最初の）顧客業務プロセスと共に選択的に、顧客はいわゆるセットアップ・データを伝送することもできる。この初期セットアップ・データはシステムにおいて、学習した知識／履歴知識を包含する知識ベースに記憶される。到来した業務プロセスはシステムによって、殊に知識ベースに存在するデータ、すなわち学習した／履歴的な知識及び提供側ＥＲＰシステム情報を使用して検査される。顧客業務プロセスが識別されると（イエス）、識別された情報が社内ＥＲＰシステムと互換性のあるフォーマットに変換される。顧客業務プロセスが識別されなければ（ノー）、殊に本発明によるシステムの実行フェーズにおいて到来した顧客業務プロセスのマニュアルの検査及び拡張が行われる。この場合拡張された形式が識別プロセスを実行するために新たに識別システムへと供給される。

識別システムによって識別された業務プロセスは、ＥＲＰと互換のあるフォーマットへと変換された後にシステム信頼性問合せが実施される。このことは識別率が未だ所定の閾値を下回る場合には、殊に本発明によるシステムの動作の実施フェーズないし初期フェーズにおいて行われる。識別の確率が十分でない場合には（識別率＜ｘ％）、識別された業務プロセスには、この業務プロセスが受注者のＥＲＰシステムにパスされる前に別の検査が実施される。

本発明によるシステムを更に発展させるために、識別プロセスに基づき取得したデータ及び情報、殊に識別された業務プロセスが知識ベースに記憶される（機能図においては破線で示されている）。このことはフォーム又はフォームの特徴及び対応する識別結果の記憶、殊にマニュアルの介入により補完された識別結果の記憶によって、又は注文フォームを使用することなく形成された注文データを伝送することによって、すなわち知識ベースの動的な改善によって行うことができる。

本発明は勿論、コンピュータにおけるコンピュータプログラムの実行の際に本発明による方法の実施に適しているプログラム符号化手段を備えたコンピュータプログラム、並びにデータ担体に記憶されている本発明によるコンピュータプログラムを有するコンピュータが読み出し可能なデータ担体及びこのようなコンピュータが読み出し可能なデータ担体を備えたコンピュータプログラム製品に拡張される。

本発明の更なる利点及び実施形態は従属請求項に記載されており、また以下の説明及び付属の図面より明らかになる。

前述の特徴及び以下で更に説明すべき特徴はそれぞれ示された組合せに制限されるものではなく、本発明の範囲から逸脱することなく別の組合せ又は単独でも使用できる。

本発明は別の実施例に基づき図面に概略的に示されており、または本発明を以下では図面を参照して詳細に説明する。

図１は本発明が基礎とする問題を説明するための概略図である。

図２は本発明の非常に概略的な機能図である。

図３は図２の機能図のより詳細な図である。

図４は本発明による識別ステップの構成である。

図５はフローチャートを基礎とする、電子メッセージ（Ｅメール）の場合における業務パートナを本発明により識別するための概略的な経過である。

図６はフローチャートを基礎とする、テレファックスメッセージの場合における業務パートナを本発明により識別するための概略的な経過である。

図７はフローチャートを基礎とする、ドキュメントの種類ないし業務プロセスを本発明により識別するための概略的な経過である。

図８は情報需要の識別ないし確定を概略的に示しものである。

図９は伝送された業務プロセスからの情報の本発明による識別を概略的に示したものである。

図１０は本発明によるシステムアーキテクチャに関する概観である。

図１１は識別モジュール（モジュール１００）の構成の概略図である。

図１２はドキュメントの内容の本発明による動的な識別の経過をフローチャートで具体的に示したものである。

図５には例示的に、電子的なメッセージ（Ｅメール）の場合における業務パートナ／顧客の識別の経過が概略的に示されている。一例としての説明は、慣例の規格によるＥメールアドレスの構造すなわちuser@2ld.tldを基礎とする。ここで2ldは第２レベルのドメインであり、tldは第１レベルのドメインである。（ここで説明するやり方は勿論、全ての発注者が注文を送信できる受注者の個人Ｅメールアドレスを使用しない場合を表している。何故ならば業務パートナは到着するメールアドレスと結びついており、したがって識別は瑣末なためである。同様のことは個人のファックス番号又は電話番号を割り当てる場合にも該当する）。

電子メッセージが到着すると、送信側（顧客）のＥメールアドレスが業務パートナのデータバンクに記憶されているＥメールアドレスと比較される。記述の例に関して送信者のメールアドレスは「meier@schroeder.de」とする。このメールアドレスが業務パートナのデータバンクに記憶されている場合には、業務パートナは即座に識別され、第２のステップ「ドキュメントの種類／業務プロセスの識別」（図４を参照されたい）を続行することができる。

このメールアドレスが業務パートナのデータバンクに存在しない場合には、第２レベルのドメイン（ここでは「schroeder」）が業務パートナのデータバンク、また必要に応じて社内ＥＲＰシステムにおけるデータストック（顧客リスト）を使用して検索される。

同一又は類似の名称ないし名称の構成要素「Schroeder」を有する会社が発見されなければ、後続のステップにおいてユーザ名（ここでは「meier」）が検索される。ＥＲＰシステムのデータストックにおいて「Meier」という名称を有する顧客が確認されると、その顧客が勤務している会社を第２レベルのドメインから既知のデータと比較する必要がある。確認された顧客Ｍｅｉｅｒが例えばＳｃｈｒｏｅｃｏ ＡＧという名称の会社に勤務している場合には、記憶されているデータ基づき、Ｓｃｈｒｏｅｃｏ ＡＧ社はＳｃｈｒｏｅｄｅｒ ＧｍｂＨ社が属する持株会社であるかを確認することができる。

続く意味論的な検証ないしファジイ分析でもって、Ｓｃｈｒｏｅｃｏ ＡＧのＭｅｉｅｒ氏は実際に高い確率で、検索している業務パートナであるか否かが検査される。

検査のこの第３のステップも成果がないものであれば、最終的な可能性として電子メッセージの全体の内容における意味論的／ファジイな検索に基づき業務パートナが確認される。すなわち識別すべき情報は他の識別ステップにおいて識別された情報も引用することができる。

同様のやり方はテレファックスによる業務プロセスの伝送の場合にも行われる。ここでは識別過程が業務パートナのテレファックス番号に基づき実施される（図６を参照されたい）。

図７は、図４に示されているような、本発明による識別経過における第２のステップ「ドキュメントの種類／業務プロセスの識別」を詳細に示している。構成に応じてこの第２のステップを第１のステップと入れ替えることもできる。すなわち第２のステップを業務パートナの識別前に実施することもできる。このことは、例えばシステムを実施する際の初期段階において僅かな業務プロセスしか方法によって支援されない場合には殊に好適である。しかしながらここでの実施例では図４に示されているようなやり方を基礎とする。すなわちドキュメントの種類／業務プロセスの識別が第２のステップである。

この第２のステップでは先ず業務プロセスデータバンクから、確認された顧客は提供側／受注者とのどのような業務プロセスを有するかという情報が呼び出される。既述の例示的に示したＳｃｈｒｏｅｄｅｒ ＡＧに関して、この会社が以前に業務プロセス「納入計画」及び「注文」を行ったことが明らかになる。続いて、対応するドキュメント例がドキュメントデータバンク内に存在するか否かが検査される。存在する場合には、到着したドキュメントがドキュメント例と一致するか比較される。この比較がやはり一致するないしほぼ一致する場合には、意味論的ないしファジイな検査に基づき、ドキュメントは十分に高い信頼性／確率で注文又は納入計画に関するものであるか否かが確認される。結果として例えば、Ｓｃｈｒｏｅｃｏ ＡＧ社のＭｅｉｅｒ氏が電子的に注文を伝送したことを確認できる。

ドキュメント例が存在しない場合、ないしは存在するドキュメント例との比較結果が否定的である場合には、伝送されたメッセージのテキスト内の意味論的／ファジイ検索に基づき業務プロセスの種類を調べる必要がある。

ステップ３「情報需要の確定（図４を参照されたい）」では、図８の例示的な図に従いテーブルに基づいて、業務プロセス（説明する例では注文）を完全に識別するためにはどのデータが必要であり、また例えばデータウェアハウスにおいて相応に使用可能な情報が何処に存在するかが確認される。

非常に簡単にするためにここでは例示的に、ある注文を完全に識別するために量及び納入日が必要とされることを前提とする。量に対しては顧客すなわちＳｃｈｒｏｅｃｏ ＡＧの履歴的な注文に基づく情報及びデータバンクを介して使用可能な最小注文量などのような製品データを使用することができる。納入日を確認するためにカレンダーまた必要に応じてデータバンクを介して使用可能な製品データ、例えば製造時間などが使用される。確認された情報はドキュメントデータバンクに格納される。

図９は第４のステップでありまた最後のステップでもある「業務プロセスからの情報の識別」の経過を概略的に示している。ここで使用されるデータの概念は複数のデータを表すのではなく単一のデータ情報を意味する。

この識別ステップでは連続的に、必要とされるデータが伝送されたドキュメントから抽出される。実施例における抽出すべき第１のデータは納品量である。ドキュメントデータバンク内に事前に作成されたテーブルに従い、Ｓｃｈｒｏｅｃｏ ＡＧの履歴的な注文データにおいて調査が行われ、例えばＳｃｈｒｏｅｃｏ ＡＧは９０％２０トンの量を注文し、僅か１０％は１０トンの量を注文することが確定される。ＥＲＰデータバンク又は他のデータバンクから、１０トンが最小注文量を表すという情報が得られる。このようにして得られた知識を基礎として、意味論的な識別及び／又は人工知能／ファジイ問合せを用いて、Ｓｃｈｒｏｅｃｏ ＡＧは２０トンを注文するという情報が抽出される。

この実施例における抽出すべき第２のデータは納入日である。ドキュメントデータバンク内に事前に作成されたテーブルに従い、その時点の日よりも前の注文を除外し、（データバンクから得られた）製造時間が１０日である場合には、１０日間の期間の間の注文が最も確率が高いとみなさされる。意味論的な識別及び／又は人工知能／ファジイ問合せを用いて、この識別に基づきＳｃｈｒｏｅｃｏ ＡＧは３週間以内の納入を希望するという情報が抽出される。

実施例及びアルゴリズム
図１０に示した注文識別のための実施例に基づき以下では、顧客の注文を全自動で識別するため、また読み出されて識別された注文をＥＲＰ（企業資源計画）システム（例えばＳＡＰ Ｒ／３タイプ）へと伝送するための、本発明による電子データ処理システム及びソフトウェアシステムを説明する。

本発明によるシステムは以下において詳細に説明するモジュール、すなわち識別モジュール１００、知識ベース２００、拡張モジュール３００、伝送モジュール４００及びＥＲＰシステム５００を包含する。

識別モジュール１００は、ＥＲＰシステムにおいて業務プロセス（例えば注文）を発生させるために必要とされるデータの識別に使用される。ここでは、ＥＲＰシステムにおいて業務プロセス（例えば注文）を発生させるためにエントリされている全てのデータは識別される必要はなく、識別すべきデータを例えば資料蓄積データ及び顧客プロフィールデータによって完全なものにできることを前提とする。

識別モジュール１００の構成要素は以下の通りである：
１１０：入力データに基づいた特徴識別（例えば光学式文字認識）のためのシステム
１２０：静的にデータを識別する、ないし所定のデータ内容に関する仮定を立てるためのシステム
１３０：構成要素１２０の動作を支援するための規則
１４０：構成要素１２０によって立てられた仮定の検証に基づき動的にデータを識別するためのシステム
１５０：構成要素１４０の動作を支援するための判定基準及び規則
１６０：出力装置

モジュール２００（知識ベース）は識別モジュール１００の動作を支援するために使用される。モジュール２００はデータバンク又は双方向に応答可能なＥＲＰシステムの形態の知識ベースである。

知識ベース２００の構成要素は以下の通りである：
２１０：注文可能な資料についての蓄積データ、すなわち関連する商品の品目についてのデータ
２２０：業務パートナについての蓄積データ、すなわち考えられる顧客のプロフィール（例えば所属の一義的な識別番号、宛先、注文の性質、特別な要求などを有する顧客リストにおける情報を包含する）
２３０：関連する業務パートナの履歴的な注文に関するデータ（注文履歴）

拡張モジュール３００は、モジュール２００によって完全には識別されなかった出力データセットをマニュアルで拡張するために使用される。

伝送モジュール４００は、モジュール２００又はモジュール３００により識別されたデータセットを、使用されるＥＲＰシステムによってインポート可能なフォーマットへと拡張及び再フォーマットするために使用される。このために例えばＴＳＩ Ｍｅｒｃａｔｏｒ^（Ｒ）タイプのビジネス統合ソフトウェアが使用される。

それ自体公知の伝送モジュール４００の構成要素は以下の通りである：
４１０：ＥＲＰシステムにおいて業務プロセス（例えば注文）を発生させるためにエントリする必要がある全てのデータを有するデータセットへと、モジュール２００ないし３００から受信した出力データセットを拡張するためのシステム
４２０：使用されるＥＲＰシステムによってインポート可能なフォーマットへと完全なデータセットを変換するためのモジュール
４３０：フォーマット化されたデータセットをＥＲＰシステムに伝送するための出力コンポーネント。

参照番号５００で表されているモジュールは例えばＳＡＰ Ｒ／３タイプのＥＲＰシステムである。

ＥＲＰシステムの構成要素は以下の通りである：
ＥＲＰシステムの通常の機能に加えて以下の構成要素が不可欠である：
５１０：モジュール４００から送信されるようなデータセットを受け取るためのインタフェース
５２０：モジュール２００において表されるデータを、モジュール２００において説明した知識ベースへと出力するためのインタフェース。

モジュールの機能の説明
以下では個々のモジュール及びモジュールの構成要素並びに構成要素のタスクを詳細に説明する。他の業務プロセス、例えば注文の変更、注文のキャンセル、インボイス処理などを識別するために、既述のシステムを相応に修正して同様に本発明に使用することができる。

識別モジュール１００は構成要素「特徴識別」１１０においてデータにアクセスし、このデータに包含されている情報をテキストデータに変換する（図１１を参照されたい）。入力フォーマットは、例えばＢＭＰ、ＢＷ、ＤＣＸ、ＤＩＢ、ＥＭＦ、ＧＩＢ、ＧＩＦ、ＴＩＦ、ＩＬＢＭ、ＪＦＩＦ、ＪＩＦ、ＪＰＥＧ、ＬＢＭ、ＰＣＤ、ＰＣＳ、ＰＩＣ、ＰＩＸ、ＰＳＤ、ＲＧＢ、ＲＬＥ、ＳＧＩ、ＴＧＡ、ＴＩＦＦ又はＷＭＡタイプのような画像データ、例えばPostscript又はAdobe Acrobat ReaderファイルタイプのＰｏｓｔｓｃｒｉｐｔ及びリーダデータファイル、ＨＴＭＬデータファイル又はＸＭＬデータファイルのようなMarkup-Languageデータファイル、例えばマイクロソフト・ワードドキュメントのようなテキスト処理システムのドキュメントデータファイル、例えばＡＳＣＩＩ又はリッチテキストフォーマットのタイプのテキストデータファイルを形成する。識別モジュール１００は可能な範囲で最善にこのデータファイルにおいて包含されているテキストを内容に関して識別し、これらのテキストをテキストＡＳＣＩＩ又はリッチテキストフォーマットのタイプのテキストフォーマットに変換する。このためにデータファイルはそれ自体公知の且つ商慣習上の光学式文字認識（ＯＣＲ）システム、例えばＯＣＥ Ｄｏｃｕｓｔａｒタイプによって読み出され、ＡＳＣＩＩフォーマットデータファイル又はリッチテキストデータファイルとして出力又は再フォーマット化される。

構成要素「静的な識別」１２０では、特徴識別１１０の結果生じたデータファイルに基づいて、識別すべきデータについて仮定が立てられる。このために構成要素「規則」１３０は２種類の規則を持つ規則メカニズムを使用する：一方は発見すべきフィールドのフォーマットについての規則［例：注文日付がフォーマット（ＤＤ／ＭＭ／ＹＹＹＹ）又は（ＤＤ／ＭＭ／ＹＹ）又は（ＤＤ−ＭＭ−ＹＹＹＹ）などを有する］であり、他方は仮説を立てるために関連する情報の意味論的なコンテキストについての規則［例：「注文番号は頻繁に特徴列（注文番号．）の近くにある」又は「注文日付は所望の納品日付よりも常に以前のものである」］である。これに基づき構成要素「静的な識別」１２０は例えば「所望の注文量＝１０ｋｇ」という仮説を立てる。モジュール１００によって識別すべき各データについて複数の（矛盾もする）仮説［例：仮説１（注文量）：所望の注文量＝１０ｋｇ、仮説２（注文量）：「所望の注文量＝１００００ｋｇ」］を立てることができる。

仮説は検査のために構成要素「動的な識別」１４０に伝送され、この動的な識別１４０は「静的な識別」１２０から受け取った仮説を構成要素「判定基準／規則」１５０からの判定基準及び規則に基づき、また知識ベース２００を使用して検査する。相応の検査アルゴリズムは図１２に示されている。

図示したアルゴリズムにおける要素は以下のように規定されている：
・識別ステップ（検索されるデータの識別に帰着する）：Ｒ
→計数：ｉ；ｉ∈｛１，．．．，ｉ_ｍａｘ｝
・先行の処理ステップ（構成要素１２０）からのＲ_ｉの考えられる値についての仮説：Ｈ（Ｒ_ｉ）
→計数：ｍ；ｍ∈｛１，．．．，ｍ_ｍａｘ｝
・仮説Ｈｍ（Ｒ_ｉ）についての探究的な検査判定基準：ｊ（Ｒ_ｉ）
→計数：ｎ；ｎ∈｛１，．．．，ｎ_ｍａｘ｝
・仮説Ｈｍ（Ｒ_ｉ）についての確認的な検査判定基準：ｋ（Ｒ_ｉ）
→計数：ｐ；ｐ∈｛１，．．．，ｐ_ｍａｘ｝

構成要素１５０における判定基準は２つのクラスに分割されている。一方は探究的に使用できる判定基準（探究的な判定基準ｊ）であり、他方は探究的ではなく確認的に使用できる判定基準（確認的な判定基準ｋ）である。判定基準はクラスにおいて階層的に配置されており、クラスの最もクリスプな判定基準は第１の判定基準（ｊ_１（Ｒ_ｉ）ないしｋ_１（Ｒ_ｉ））であり、インデクスの数が増すに連れ判定基準のクリスプの度合は減少する。

判定基準の検査をモジュールの構成又は判定基準に応じて、クリスプなイエス／ノー問合せ（考えられる結果はここでは数学的に０又は１で表される）又はファジイ問合せ（ファジイロジック）によって行うことができる。後者の場合には、判定基準の規則によって、また必要に応じて知識ベースからの所属のデータによって規定されたファジイ量について検査すべき仮説のメンバシップを正規化して、区間［０，１］内の値によって表すことができる。各判定基準に関しては信頼区間、すなわち区間内の次のような範囲を表す必要がある。すなわち、ファジイ量についてのメンバシップの値がその範囲内にあるならば、判定基準に対して仮説が成り立つ範囲である。

発見すべき第１（ｉ＝１）のデータ（Ｒ_１）に関して、０以上の仮説［Ｈ_ｍ（Ｒ_１）］が存在するか否かが検査される。存在しない場合にはＲ_１の識別は失敗している。発見すべき別のデータが欠如しているか否かが検査される。欠如している場合にはプロセスは次のデータ（ここでは：Ｒ_２）を用いて続行される。それ以外の場合にはプロセスは終了している。

０以上の仮説［Ｈ_ｍ（Ｒ_１）］が存在する場合には、存在する全ての仮説に対して第１の探究的な判定基準（ｊ_１（Ｒ_ｉ））との互換性が順次検査される。判定基準と互換性のなかった仮説は拒否される。全ての仮説の検査後に残存する仮説［Ｈ_ｍ（Ｒ_１）］がカウントされる。仮説のカウントの結果が１より大きく且つ別の探究的な判定基準が存在する場合には、検査は階層において次に低い判定基準を用いて繰り返される。別の探究的判定基準が存在しないか、仮説のカウントが０である場合にはＲ_１の識別は失敗している。発見すべき別のデータが欠如しているか否かが検査される。欠如している場合には、プロセスは次のデータ（ここでは：Ｒ_２）を用いて続行され、それ以外の場合にはプロセスは終了している。

仮説のカウントの結果が１であった場合には、これは潜在的な解決策が発見されたことを意味する。この解決策が続けて、場合によってその他の探究的な判定基準及び確認的な判定基準を用いて検査される。このために、既に全ての探究的な判定基準が使用されたか否かが検査される。使用されていなかった場合には、階層において次に低い探究的な判定基準との互換性が検査される。互換性が無い場合には、データ（ここでは：Ｒ_１）の識別は失敗している。発見すべき別のデータが欠如しているか否かが検査される。欠如している場合には、プロセスが次のデータ（ここでは：Ｒ_２）を用いて続行され、それ以外の場合にはプロセスは終了している。このループは階層において最も低い探究的な判定基準が使用されるまで実行され続ける。

続いて確認的な判定基準が存在するか否かが検査される。存在しない場合には、Ｒ_１の識別は成功している。その他の残った仮説には解決値が割り当てられる（例：顧客Ｍｅｉｅｒは一義的に注文者として発見され、仮説、注文者＝Ｍｅｉｅｒには顧客Ｍｅｉｅｒの注文番号がデータベースから割り当てられる）。次いで発見すべき別のデータが欠如しているか否かが検査される。欠如している場合には、プロセスは次のデータ（ここでは：Ｒ２）を用いて続行され、それ以外の場合にはプロセスは終了している。

少なくとも１つの確認的な判定基準が存在する場合には、階層において最も高い確認的な判定基準（ここでは：ｋ_１（Ｒ_１））との互換性が検査される。互換性が無い場合には、データの識別（ここでは：Ｒ_１）は失敗している。発見すべき別のデータが欠如しているか否かが検査される。欠如している場合には、プロセスは次のデータ（ここでは：Ｒ_２）を用いて続行され、それ以外の場合にはプロセスは終了している。

互換性がある場合には、別の確認的な判定基準が存在するか否かが検査される。存在しない場合にはＲ_１の識別は成功しており、前述のようにしてさらに処理が行われる。別の確認的な判定基準が存在する場合には、階層において次に低い確認的な判定基準（ここでは：ｋ_２（Ｒ_１））と仮説との互換性が検査される。このループは最も低い確認的な判定基準までさらに継続される。

第１の経過に基づき説明したプロセスは発見すべき全てのデータについて継続される。

使用される判定基準は内容的に知識ベース（構成要素２００）内のデータを参照する。つまり、例えば発注者（例えば：Ｒ_１＝発注者）を検索する場合の判定基準は次のようなものでよい：「仮説に挙げられた会社名は同一の名称又は類似の名称で知識ベース内の顧客リストに存在する」。

発見すべきデータも判定基準も階層的に配置されており、したがって識別の際にはその都度先行の部分プロセスの結果を参照することができるので、複雑性は低減し、また所定のデータの識別の確率を上昇させることができる。

例えば発注者が既に発見されていれば、商品受取人（例：Ｒ_２＝商品受取人）の同定の際の判定基準は次のようなものでよい：「仮説に挙げられた会社アドレスは同一のアドレス又は類似のアドレスで知識ベース内の顧客リストに存在し、しかもＲ_１の発見に成功していた場合には、この発注者に対応付けられている商品受取人アドレスのリスト内に存在する」。

出力モジュール１６０は、発見すべき全てのデータ（Ｒ_１からＲ_ｍａｘ）が構成要素「動的な識別」１４０によって発見されたか否かを検査する。発見されている場合には、これらの発見されたデータ（Ｒ_１からＲ_ｍａｘ）が伝送モジュール４００に伝送され、発見されなかった場合には、データは手動の拡張のためにモジュール３００へと伝送される。

説明のために一例を簡潔に仮定のデータ、仮説、判定基準などを用いて詳細に表す：
Ｒ_１は発注者（売られる側：ｓｏｌｄ−ｔｏ）であり、Ｒ_２＝Ｒ_ｍａｘは商品受取人（送られる側：ｓｈｉｐ−ｔｏ）とする。

モジュール１３０における規則は、文字列は大文字で始まるものでなければならないというものである。モジュール１１０によってデータファイルに変換されたドキュメントにおいて、この規則に応じる語「Ｍｅｉｅｒ」、「Ｍｕｅｌｌｅｒ」及び「Ｓｃｈｕｌｚｅ」がモジュール１２０によって発見される。これらの語に従い仮説：Ｈ_１（Ｒ_１）：発注者＝「Ｍｅｉｅｒ」、Ｈ_２（Ｒ_１）：発注者＝「Ｍｕｅｌｌｅｒ」、Ｈ_３（Ｒ_１）：発注者＝「Ｓｃｈｌｕｔｚｅ」が立てられる。

第１の探究的な判定基準は以下のものとする：仮説に挙げられた発注者は知識ベース（モジュール２００）内の顧客データバンクに存在する。第１の仮説に関しては検査によって知識ベース内に「Ｍｅｉｅｒ ＧｍｂＨ」が発見される。ファジイ検査によって、仮説Ｈ_１（Ｒ_１）からは値「Ｍｅｉｅｒ」のメンバシップについて例えば０．８の値が生じた。この判定基準に対する信頼区間は０．６〜１であるので、この検査に対する仮説は成り立つものである。

Ｈ_２（Ｒ_１）では値「Ｏｂｅｒｍｕｅｌｌｅｒ ＡＧ」しか発見されず、この値には０．４のメンバシップが割り当てられる。したがって結果は信頼区間から外れている。したがって仮説Ｈ_２（Ｒ_１）は却下される。

Ｈ_３（Ｒ_１）では仮説は同様に成り立ち、その結果２つの仮説がそのまま残ることになる。

第２の探究的な判定基準は前述した過程と類似するが、仮説Ｈ_１（Ｒ_１）のみがさらに残る結果となる。すなわちＭｅｉｅｒ ＧｍｂＨが発注者とみなされる。それにもかかわらずもう１つの探究的な判定基準が残っている。この判定基準はＭｅｉｅｒ ＧｍｂＨに適用される。Ｍｅｉｅｒ ｇｍｂＨはこの判定基準に対しても成り立つ。つまり探究的な判定基準はいわば確認的な判定基準に変換されたといえる。相応にして、確認的な判定基準を用いてＭｅｉｅｒ ＧｍｂＨの検査が継続される前に、残った探究的な判定基準が使用されることになる。仮説がこの判定基準に対しても成り立つ場合には、Ｒ_１の識別は正しいものであり、その結果はＭｅｉｅｒ ＧｍｂＨの顧客番号、例えば「４７１１」である。検査結果が否定である場合に判定基準の確認的な使用が即座に仮説を却下するものではなく、相応に仮説品質の評価パラメータへと導入されるシステムデザインも同様に考えられる。この評価パラメータは全ての判定基準の実施後に相応の信頼区間と比較され、信頼閾値を下回った際に初めて仮説を却下する。

Ｒ_２に関しても同様のことが行われるが、ここではＭｅｉｅｒ ＧｍｂＨは発注者であるという情報だけを使用できる。商品受取人を検索する場合には、例えば知識ベースを発注者４７１１、すなわちＭｅｉｅｒ ＧｍｂＨに対応付けられている商品受取人に限定することができる。

１人の発注者が発見された際にも、出力コンポーネント１６０は検索した２つの要素のいずれも発見されたことを確認する。したがって情報は後処理のためのモジュール３００ではなく、さらなる処理のためのモジュール４００へと転送される。

ワークステーションモジュール３００はモジュール１００の出力部１６０から、全てのデータは完全には識別されなかったデータセットを受け取る。ここで専門担当官は画面において、識別されたなかったデータフィールドをマニュアルで後処理することが可能である。このためにシステムは専門担当官にシステムデザインに応じて、ソフトコピーすなわち画面上にオリジナルドキュメントを提供するか、ハードコピー例えば紙に印刷したものを作成する。専門担当官は、どの値が相応のフィールドに割り当てられているかを理解して、相応のデータをモジュール３００に順応させることができる。ここでモジュールデザインに応じて専門担当官には自由選択的に、構成要素１２０において立てられた仮説を基礎とする選択可能性を提供することができる。後処理が成功した後では、ワークステーションモジュール３００はデータを伝送モジュール４００に伝送する。

例えば注文量が確定されなかった場合には、専門担当官は注文量をオリジナルのドキュメントから調べて、この注文量をワークステーションモジュール３００におけるインタフェースを介してデータセットに付加する。別のデータが欠如していなければ、モジュールはデータを前述のようにモジュール４００に転送する。

伝送モジュール４００は完全なデータをモジュール１００又は３００から受け取る。これらのデータはシステムデザインに応じて、業務過程この例では注文をＥＲＰシステムにおいて開始できるようにするためには完全に十分なものではない可能性もある。構成要素４１０は、データセットに存在するようなデータとの組み合わせにおいて必須に規定されている情報を用いてデータセットを拡張する。これは例えば、商品を発送するために顧客と製品の組合せが所定のものである場合に必然的に使用されるウェアハウスが考えられる。

データセットの拡張後にこのデータセットを構成要素４２０において、モジュール５００におけるＥＲＰシステムが処理できるフォーマットに変換する必要がある。モジュール５００において例えばＳＡＰ Ｒ／３タイプのシステムが使用される場合には、構成要素４２０はデータセットを例えばＳＡＰ中間ドキュメント（ＩＤｏｃ）に変換する。

構成要素４３０は結果をＥＲＰシステムに伝送する。すなわちここで説明する実施例においては構成要素４３０はＩＤｏｃをＳＡＰ Ｒ／３システムに送信する。

ＥＲＰシステム（モジュール）５００は少なくとも商慣習上の機能を有するＥＲＰシステムである。例えばそのようなシステムはＳＡＰ社のモデルＲ／３である。

ＥＲＰシステムは構成要素４３０から得るデータセットを処理するためにこのデータセットを受け取れることができなくてはならない。このために、形成されたフォーマットを処理するインタフェースが必要とされる。すなわちここで説明する例ではＩＤｏｃを処理できるインタフェース（構成要素５１０）が必要とされる。別の機能はここで説明するシステムの一部ではなく商慣習上のものであるので、これについてはさらに説明はしない。例外は構成要素５２０である：知識ベース（モジュール２００）はＥＲＰシステムからの所定の情報にアクセスできなくてはならない。このことはシステムデザインに応じて、ＥＲＰシステム内のデータ保守部、すなわち例えばＳＡＰのデータウェアハウスへと知識ベースが直接的に（オンラインで）アクセスすることによって、又は、周期的又は随時にトリガされる関連する情報を知識ベースのデータバンクに直接的にダウンロードすることによって行われる。すなわち必要なデータウェアハウスにはモジュール５００から必要なデータが供給されることが保証されなければならない。

本発明による注文が電話によって行われる場合には、有利な実施例によれば以下のように経過となる。

本発明によるシステムはそれ自体公知の相互的な呼出応答装置を包含し、この呼出応答装置は顧客が注文コールを行った際にその顧客を迎え入れて、注文経過を共にする。この際、顧客情報はキー入力又は音声入力を用いて行われる。

顧客は顧客番号及び／又は識別番号及び認証番号（ＰＩＮ）を順に通知する。ここで本発明はこのようなＰＩＮ通知が無くとも、前述の識別システムに基づき機能することを言及しておく。

引き続き顧客は、注文が新たな注文であるか又は既に行われた注文の処理（変更／取消）であるかを通知することができる。新たな注文の場合には顧客は商品受取人番号、顧客注文番号、商品番号、所望量及び所望の納期を通知する。注文の変更又は取消を行う場合には、顧客はその時点において顧客には既知の受注者の注文番号を通知し、また変更か取消かを通知する。変更の場合には顧客は新たな量及び／又は新たな納期を通知する。

本発明によれば、顧客は引き続き自分の通知の要約を聞く。音声入力の場合には記録された注文入力が呼出応答装置によって顧客に対して「読み出され」、すなわち再生され、キー入力の場合には顧客に対してキー入力に基づき電子的に形成される音声通知が再生される。顧客はこれに基づき、変更、別の注文及び／又は注文の確認を行うことができる。

電話による注文の過程が終了すると、顧客情報は内部注文システムに取り込まれ、この注文システムにおいて前記で詳述したように注文の妥当性についての検査が行われる。検査が成功すると、顧客は自動的に生成された注文受領通知書を電子ポスト又はテレファックスによって受け取る。

本発明の殊に有利な実施形態では、顧客の電話による通知の検査が注文と並行して行われるので、顧客は電話による注文の過程の間でさえも、注文（ないし変更希望／取消希望）が受領され、またどの注文番号が注文に割り当てられたかについて、自動的な返信を受け取ることができる。

別の考えられる変形では、顧客が電話をした際にその時点で顧客に既知である注文番号を通知し、注文システム（ＥＲＰシステム）から注文は依然として成立していないか（すなわち生産は行われていない、又は発送は行われていない）、配給されていないか（すなわち生産はされたが、依然発送はされていない）又は既に発送されたかについての応答を得ることによって、顧客は注文の状態を電話によっての問合せることもできる。

したがって本発明は、顧客がボディコピー（body copy）テキスト、その他のフォーマット化されていないテキスト、電話に基づいて、又はそれどころか固有の注文フォーマットを使用して業務プロセスを行うことを可能にし、この業務プロセスを人間による介入なしで、ないしは極僅かな介入でもって完全に且つ正確に識別し、さらに処理することができる。

本発明が基礎とする問題を説明するための概略図である。 本発明の非常に概略的な機能図である。 図２の機能図のより詳細な図である。 本発明による識別ステップの構成である。 フローチャートを基礎とする、電子メッセージ（Ｅメール）の場合における業務パートナを本発明により識別するための概略的な経過である。 フローチャートを基礎とする、テレファックスメッセージの場合における業務パートナを本発明により識別するための概略的な経過である。 フローチャートを基礎とする、ドキュメントの種類ないし業務プロセスを本発明により識別するための概略的な経過である。 情報需要の識別ないし確定を概略的に示しものである。 伝送された業務プロセスからの情報の本発明による識別を概略的に示したものである。 本発明によるシステムアーキテクチャに関する概観である。 識別モジュール（モジュール１００）の構成の概略図である。 ドキュメントの内容の本発明による動的な識別の経過をフローチャートで具体的に示したものである。

Claims (18)

1. コンピュータシステムを使用して電子的な業務プロセスをコンピュータにより評価するための方法において、
   前記コンピュータシステムに到来する業務プロセス（ＧＰ）に包含されている業務プロセスに関連するデータを検査するために、第１の検査ステップでは静的な検査を特徴識別に基づき行い、検査された各データの内容について仮説を立て、第２のステップでは前記立てられた仮説の動的な検査を行うことを特徴とする、電子的な業務プロセスをコンピュータにより評価するための方法。
2. 記憶されている判定基準及び規則に前記動的な検査を基づき行う、請求項１記載の方法。
3. 知識ベースを参照して前記動的な検査を行う、請求項１又は２記載の方法。
4. 業務プロセスの入力を電子的に、電子郵便、テレファックス、ＯＣＲ特徴認識及び／又は電話により行う、請求項１から３までのいずれか１項記載の方法。
5. 識別された前記業務プロセスに関連するデータを自動的に経過プロセスシステム（５００）に転送し、該経過プロセスシステム（５００）は前記データに基づき前記業務プロセスを全自動で実行する、請求項１から４までのいずれか１項記載の方法。
6. コンピュータシステムを使用して電子的な業務プロセスをコンピュータにより評価するための方法において、
   前記コンピュータシステムに到来する業務プロセス（ＧＰ）に包含されている業務プロセスに関連するデータを検査するために、電子的に識別されたデータ内容を知識ベース（２００）内に包含されている顧客固有／資料固有のデータを用いて調整することを特徴とする、電子的な業務プロセスをコンピュータにより評価するための方法。
7. 識別された業務に関連するデータが前記知識ベース（２００）のデータと一致しない場合には、該業務に関連するデータを前記知識ベース（２００）の内容に基づき訂正する、請求項６記載の方法。
8. 前記知識ベース（２００）の内容に基づく訂正を行えない場合には、前記業務プロセス（ＧＰ）をマニュアルで拡張するための拡張モジュール（３００）に供給する、請求項７記載の方法。
9. 入力インタフェース、識別モジュール（１００）、知識ベース（２００）、伝送モジュール（４００）及び経過プロセスシステム（５００）を備えた、電子的な業務プロセスをコンピュータにより評価するためのコンピュータシステムにおいて、
   入力インタフェースを介してコンピュータシステムに到来する業務プロセス（ＧＰ）に包含されている業務プロセスに関連するデータを前記識別モジュール（１００）において検査するために、第１の検査ステップ（１２０）ではデータの静的な検査を特徴識別に基づき行い、検査された各データの内容について仮説を立て、第２の検査ステップ（１４０）では前記立てられた仮説の動的な検査を行うことを特徴とする、電子的な業務プロセスをコンピュータにより評価するためのコンピュータシステム。
10. 記憶されている判定基準及び規則に基づき前記動的な検査を行う、請求項９記載のコンピュータシステム。
11. 前記知識ベース（２００）を参照して前記動的な検査を行う、請求項９又は１０記載のコンピュータシステム。
12. 業務プロセスの入力を電子的に、電子郵便、テレファックス、ＯＣＲ特徴認識及び／又は電話により行う、請求項９から１１までのいずれか１項記載のコンピュータシステム。
13. 前記識別モジュール（１００）により識別された業務プロセスに関連するデータを、伝送モジュール（４００）により自動的に前記経過プロセスシステム（５００）に転送し、該経過プロセスシステム（５００）は前記データに基づき業務プロセスを全自動で実行する、請求項９から１２までのいずれか１項記載のコンピュータシステム。
14. コンピュータシステムを使用して電子的な業務プロセスをコンピュータにより評価するためのコンピュータシステムにおいて、
    前記コンピュータシステムに到来する業務プロセス（ＧＰ）に包含されている業務に関連するデータを検査するために、電子的に識別されたデータ内容を、知識ベース（２００）に包含されている顧客固有／資料固有のデータを用いて調整することを特徴とする、電子的な業務プロセスをコンピュータにより評価するためのコンピュータシステム。
15. 識別された業務に関連するデータが前記知識ベース（２００）のデータと一致しない場合には、該業務に関連するデータを前記知識ベース（２００）の内容に基づき訂正する、請求項１４記載のコンピュータシステム。
16. 拡張モジュール（３００）をさらに包含し、該拡張モジュール（３００）は、前記業務に関連するデータの訂正を前記知識ベース（２００）の内容に基づき行えない場合には、業務プロセスデータのマニュアルでの拡張に使用される、請求項１５記載のコンピュータシステム。
17. コンピュータが読み出し可能な媒体と、コンピュータシステムにおいてコンピュータプログラムが実行される場合に請求項１から８までのいずれか１項記載の方法の実施に適しているプログラムコードを有する、前記コンピュータが読み出し可能な媒体に記憶されているコンピュータプログラムとを備えたコンピュータプログラム製品。
18. コンピュータシステムにおいてコンピュータプログラムが実行される場合に請求項１から８までのいずれか１項記載の方法の実施に適しているプログラムコードを有するコンピュータプログラム。

Images