JP2002504245A - 運営資源管理システム - Google Patents

Abstract

(57)【要約】 企業内の運営資源を効率的に調達するソフトウェアシステム。要請書記録生成モジュールは要請書についての要請書記録を生成する。その要請書記録は、少なくとも要請者が購買を希望する運営資源を示す。要請書記録生成モジュールは、要請者による入力と、運営資源情報データベースにおける運営資源情報との組み合わせに応じて要請書記録を生成する。承認経路決定モジュールは、要請書記録と、承認規則データベースにおける承認規則とに応じて、要請書記録の承認を要請される複数の承認者候補の一人一人の中から要請書記録についての承認経路を決定する。承認経路処理モジュールは、決定された承認経路に沿って要請書記録を案内し、この承認経路処理手段は、承認経路を首尾よく通過する要請書記録に応答して包括的な承認表示を生成する。

Description

【発明の詳細な説明】 運営資源管理システム関連出願引照 本願は、1997年４月28日に出願された仮出願第60/044,372号に基づく優先権を 主張する。技術分野 本発明は運営資源（オペレーティグリソース）を調達するソフトウエアシステ ムであり、特に運営資源取得周期を自動化するソフトウエアシステムである。背景 現在、運営資源は、典型的なフォーチュン1000社における売り上げの３分の１ までを占める。企業によって購入される全商品及びサービスの殆ど95％がペーパ ーを基礎とする手順を通じて行われる。ペーパーを基礎とする購入が優勢なのは 、電子商取引レガシ（過去の）システムが企業購買手順の大部分に対する解決策 を与えていない証拠である。調査によると運営商品及びサービスコストの5％節 約が概して企業利益の28％増に帰着することを示す。 伝統的に、運営資源（例えば、工業用品、事務用品及び其の他の非生産的供給 品）の購買方法は、極端に細分化され、従って、非能率的にある。望まれるのは 統合された企業全般的解決策である。要約 本発明による、運営資源管理（ＯＲＭ）を通した電子自動化、統合及びてこ作 用を利用した購買は、コストを低減させ、それによって劇的に決算結果を向上さ せるための企業にとって重要な機会を提供する。 運営資源管理は、従来の細分化された運営資源購買方法を置き換える。新技術 を通じて（一実施形態、即ち、イントラネット(ネット内)、エクストラネット（ ネット外）及びJava）運営資源管理は、規模の経済及びてこ作用原料供給関係を 完全に獲得するために、統合された企業電子商業システムを用いて数十年来の非 能率に取って代わる。本発明の運営資源管理システムは、少なくとも３つの重要 な利益を与える。即ち、 ・ 要請から支払を通して購買手順を構成する全機能を統合することによる全 調達周期の自動化。 ・ 規模の経済及び購買専門の任務を戦術的取引手順から戦略的供給連鎖（チ エーン）管理への移行簡易化を通じて低減された運営資源コスト。 ・ 現存データリソース及び供給者電子商業システムを通じての現存企業シス テム及び電子商業システムのてこ作用利用。図面の簡単な説明 図１は、本発明実施形態のエンジニアリングアーキテクチャ（技術体系）を示 す。 図２は、本発明実施形態の拡張可能性アーキテクチャを示す。 図３は、本発明実施形態の調達手順流れ（フロー）を示す。 図４は、本発明実施形態の製品特性記述を示す。 図５は、本発明実施形態の使用者環境特性を示す。 図６は、本発明実施形態のシステム環境特性を示す。 図７は、本発明実施形態に含まれる業務モジュールを示す。 図８は、本発明実施形態のシステムアダプタを示す。 図９は、本発明実施形態に含まれる設置及び実施を示す。望ましい実施形態の詳細な説明 一実施形態においては、本発明による運営資源管理システムは、企業内の商品 及びサービスの購買を自動化する一組のソフトウエアモジュールである。モジュ ールのあるものはネットワークのサーバコンピュータで作動し、モジュールの他 のものは本発明のシステムと共に作動するのが望ましい。企業は、決算結果に直 接利益をもたらす取引き上のコストを低減させかつ総合生産性を増大させること ができる。 ・ 同システムの主要な特性として以下のものが挙げられる。即ち、 ・ 「企業内の任意のデスクトップ使用者インタフェースへの接近」、即ち、使 用者インタフェースは訓練の有無にかかわらず従業員が近づきやすく、要請手順 を通じて従業員を支援しかつ導く。システム使用は選ばれた購買グループに限定 される必要はない。 ・ 「全従業員に対する遍在しかつ容易な情報接近」、即ち、要請者及び承認者 は一様に常にすべての要請の現状を理解することが可能であり、従って、彼らの 要請についての変更に対する接近が常に維持される。 ・ 「証明された承認流れ」、即ち、同システムは、企業の業務規則を強要しか つ要請を確認し、正確かつ完全なデータを確保する。 ・ 「企業と調和させるアダプタ」、即ち、同システムは、ERP、Human Resourc e Management（人的資源管理）Systems(HRMS)、Email(電子メール)system及びデ ィレクトリ（登録簿）サービスのような企業レガシデータソース内に当該システ ムを統合するアダプタを提供する。 ・ 「拡張可能性及び柔軟性」、即ち、同システムは、各個々の会社のデータフ ィールド及び業務規則記載上の完全な柔軟性を与える。 図１を参照すると、同図に示す実施形態100では主要なモジュールは企業商業 サーバ（Enterprise Commerce Server）102であり、それはJavaで書かれたイン トラネットアプリケーションサーバソフトウエアを含むのが望ましい。一組の関 連する顧客側ソフトウエアアプリケーションも同様にJavaで書かれるのが望まし い。Java顧客ソフトウエア112は、各デスクトップ(図１では"Mac",Win95,WinNT 及びUnixとして示される)でWeb走査器（又はその代わりにウエブ走査器を介して 接近できる)で実行するのが望ましく、また要求書（要請書）を作成かつ承認す る使用者インタフェースを与える。Javaサーバソフトウエア102は単一共用機械 で実行しかつバックエンド（後置）サービスを与えるのが望ましい。 企業商業サーバ102を補足するのは多数のAdapter122であり、それらはＥＲＰ 、ＨＲＭＳ，E-mail system及びディレクトリサービスのような企業レガシデー タソース内にシステム100を統合する。システムデザインはモジュラーであり、 企業商業サーバソフトウエア102の修正を要することなく差し込まれる任意の数 のアダプタを考慮している。 実際上、本発明によるシステムは使用しやすい。同システムは、年に１回又は ２回しか購入しない頻度の低い使用者及び殆ど毎日購入する購入代行者、管理者 等の頻度の高い使用者の双方に接近しうる。 大抵のシステム使用者は要請者、即ち、購入を必要とする従業員であろう。臨 時の使用者である要請者の大部分は、顧客ソフトウエア112を介して要請ウイザ ッド（wizard）を用いて要請するであろう。図２は、同システムの一実施形態に おいて一般的にいかに機能性（特定の実施のために抽出され得る特殊な機能性） が配分されるかを示す。参照番号202は要請ウイザッドモジュールを指す。 図３はフローチャートであり、それは典型的な実施形態において、要請書作成 から承認、要請された商品・サービスの受領及び調和まで要請書がどのように処 理されるかを示す。同図において、参照番号302は要請書作成に関連する処理段 階を示す。 図４は、本発明の一実施形態の最高「製品特性」記述を示す。一方図５乃至９ は、より詳細なレベルにおける製品特性を示す図解である。図５から分かるよう に、ウイザッドソフトウエアは使用者環境500の「要請書」部分502内にある。 ウイザッド202、203は、購買を行う手順を通して従業員を案内するために多く の質問を通じて彼を導く。例えば、 ・ 今日は何を買いますか？ 概して、第１の質問は「今日は何を買いますか？」である。ウイザッド202,20 3は答えを探すために幾つかの方法を提供し、常に承認されたアイテム（項目） から選択するように従業員を励ます。多分、従業員は彼自身の個人的に好きな頻 繁に注文するアイテム304リストから１つのアイテムを選ぶに過ぎないであろう 。又は、多分彼は製品情報データベース306を通して探すことによって適切なア イテムを見つけるであろう。又は、多分彼は多数のオンラインカタログ308を通 して見ることによって当該アイテムを探すであろう。（一実施形態において同シ ステムはこのようなオンラインカタログを支援するが、それ自体カタログ許可ツ ールを含まない。） 最後の手段としてのみ、ウイザッドは従業員に供給者及び部品名をはっきり書 き込むよう促す（310）このような特別アイテム、即ち、承認されたリストにな いアイテムを入れることは、概して新しい承認規則をトリガするであろう。例え ば、多くの会社の承認規則は、購買代行者に新アイテムを認めるかどうかの決定 を要求するために、この時点で購買部門が承認ループ内に置かれるようにさせる であろう。特別入力は通常追加の費用を要するので、ウイザッドが手順を通して 可能な限り特別入力を避けるように従業員を導く。 ・ このアイテムの支払者は誰か？ 要求書の他の重要な部分は会計情報、即ち、該アイテムに対して誰が支払うか である。概して会計構成は会社毎に、ディビジョン、デパートメント、アカウン ト又はプロジェク等のように異なる。ウイザッドは、各会社に対して異なった会 計部門を表示かつ照会するよう構成され、従業員が常に関連する適切な選択を確 保するよう支援するように構成され得る。 この流れでウイザッドは、質問及び支払、要請、出荷等に関する他のデータ収 集を続ける。手順全体を通して、書込みよりは走査及び選択、標準回答への従業 員の方向づけ及び誤りのない要求書の収集が強調される。 要求書を扱う従業員はすべて、要請者又は承認者にかかわらず、当該要求書に 意見を加えるか若しくは文書を付けることができる。意見を述べ説明する能力は 、提携を維持し、承認者に要求書が理解しやすくなり、承認者が要請者にフィー ドバックすることを可能にし、要請を承認するかどうかにつき承認者の決定を支 援する方向で大いに役立つ。 要請書が提出された後、他の使用者インタフェースソフトウエア500、即ち、 オーガナイザ（Organizer）504（図5）が活動し始める。望ましい実施形態では 、オーガナイザ504ソフトウエアは、要求書の大きな集合をグループ化かつ編成 するのを支援するようにされた、現存する要求書のフォールダ（紙ばさみ）型視 点（ビユー）を提供する。 要請書が提出されると、承認ソフトウエア（図１の承認エンジン110、図３の 段階322、図６のシステム環境404の承認流れソフトウエア602）が会社の承認規 則を検査し、要請承認に誰が必要かを決定し、望ましくは、承認を待つ要求書が ある旨を第１の必要な承認者に通知する。一実施形態では、E-mail通知メッセー ジは、当人の承認を待つ要求書を表示するために、承認者の走査器を介して彼を 直接オーガナイザソフトウエア504にポイントするURLハイパーリンクを含む。承 認者は承認又は拒否を行い、更なる情報又は明確化を求めて意見をのべる。 要求書に状況変化がある場合にはいつでも、通知ソフトウエア120がE-mail メッセージを送り、要請者及び他のすべての関係者に知らせる。当システムは、 要求書の現状を使用者に知らせるために承認手順全体を通して通知E-mailを用い る。要請者もまた常に要求書の現状をチェックするためにオーガナイザソフトウ エア504を用い、それが完全に承認されたとき誰が承認し若しくは承認しなかっ たかを知るようにすることができる。 オーガナイザ504及び見解表明機構を用いて、承認過程のすべての人（例えば 、承認者、要請者及び購買代行者）が互いに質問し、要求書の現状を観察し、要 求に対する見解を述べて混乱を低減させ連絡を改善するようにすることができる 。 要求書が完全に承認された後、供給者インタフェースソフトウエア330が供給 者と連絡し注文を与えるようにする。当システムは、ファックス及びE-mailのよ うな従来の手段を介して供給者システムと連絡し得る。要求書が完了すると当シ ステムは、要求を検査し、必要な供給者及び当該供給者への望ましい注文方法を 決定し、その方法で要求書を供給者に伝達する。注文を達成するために用いられ るシステム部分は注文モジュール130(図１及び図７参照)として知られる。 注文モジュール702（図７参照）としては、購買カード（Purchasing Card）モ ジュール、直接注文(Direct Order)モジュール及び購買注文(Purchase Order)モ ジュールの３つがある。 最終的に要求書は承認され、提出され、満たされる。既に述べた通り、当シス テムは従来手段（ファックス及びE-mail）を介して注文を継続し得る。しかし、 アイテムがいったん出荷されて要求者の手元に届くと、当該アイテムの領収書の 支払がなされる前に確認されなければならない。 当システムは領収書確認用の使用者インタフェースを含み、それで各種のアイ テムが受取られていることを従業員が確認できる。これらのデスクトップ領収書 はすべてシステム内に記憶され、ERPに統合されることはない。 要請関連人数、即ち、要請者及び承認者に加えて、他の種類の使用者、即ち、 購買部（Purchasing Department）の人員が加わる。購買代行者（Purchasing Ag ents）は会社の購買業務に関して責任を有し、会社が最も適切な供給者と共に業 務を行いかつ従業員が最も適切なアイテムを購入することを確認しなければなら ない。 購買部を要求手順ループ外に置くことが望ましい。しかし、手順全般の管理を 掌握することも同様にのそましい。本システムは、特別な要求書につき異常があ る場合にのみ購買部を引き込むことによってこれらの要望を均衡させる。例えば 、誰かが承認されていない供給者からアイテムを購入せんとする場合若しくは異 例な出荷先を特定せんとする場合には、概して購買代行者が引き込まれるであろ う。 管理ツール（Administrative Tools）ソフトウエア506（図５）を介した購買 部は、どの製品及び供給者が承認されるかを定める。同様に購買部は、承認され た製品及びサービスの集合を記載する製品情報データベース（Product Informat ion Database）を暗黙的又は明示的に管理する。管理ツールソフトウエア506は 、購買代行者に製品情報データベースからアイテムを出し入れする能力、若しく は供給者との関係が変わるか又はさもなければアイテムが陳腐になる場合にアイ テムを除去する能力を購買代行者に与える。 本システムの使用者環境500の他の部分は、報告書（レポート）及びグラフ（R eport Graphs）ソフトウエア508（図5）であり、それは会社がその購買歴史を要 約し、グループ化しかつ理解できるようにさせる。同システムは、随時実行可能 な予め定めた一集合の報告書を発生させるソフトウエアを与え、購買代行者及び システム管理者が彼らの購買手順を向上させかつ自動化の利得を最高にさせるた めに用い得る情報を与えるようにするのが望ましい。この情報は、理解を得かつ その理解を用いて改良を行うための価値ある手段である。即ち、将来最終利用者 よる異なった購買パターンを助長するために、承認手順を修正するか又は供給者 を切り替えるか又は購買の歴史を更新するような改良に用いられる得る。 システム環境404はバックエンド(後置)であり、使用者とは直接対話しないシ ステム部分である。 各会社がわずかに異なったデータを維持しかつわずかに異なった業務規則を実 施ことを欲するので、デザイン上柔軟性及び構成可能性は重要である。柔軟性の 目標を支援するために本システムの一実施形態は、各社が維持しなければならな いわずかに異なった一組のデータフィールドを有することを認識し、会社が当該 組みのデータフィールドを特注できるようにデザインされる。 これらの「拡張可能フィールド」は、システム全体に亘る構成ファイル上に顧 客によって定められ、使用者インタフェースソフトウエアを介しかつ業務規則全 体に亘って利用できる。このようなフィールドがどのように用いられ得るかの例 が本出願全体に亘って見られる。例えば、ある社はその社独自の会計方針及びカ テゴリを記載するために当該組みのデータフィールドを拡張することを望むかも しれない。 特別の要求書に対してどの承認者が要求されるかを決めるために会社で用いる のが承認条件である。当システムは、あらゆる会社に現存する手順をモデル化す るのに十分な程度に柔軟な承認規則を記載する機構を備えるのが望ましい。各社 は社独自の規則集を有するが、それにはしばしば基本的類似性があり、多くの規 則が単純な例から複写可能である。例えば、承認規則は、「もしこの購買額が＄ 25,000を超えかつそれがソフトウエアなら、情報システム(Information Systems )部は購入を承認しなければならない」のような、一組の条件付表現として表さ れ得る。 承認規則については少なくとも注意しなければならない２つのことがある。第 １に、承認規則は、実施過程間に追加されるフィールドを含めて、要求書のあら ゆるフィールドに基づき得る。従って、要求又はラインアイテム量に基づく標準 承認に加えて、例えば、設備管理者（Facilities Manager）が家具購入の承認を 要するか若しくはIS部がコンピュータシステム購入を承認しなければならない。 さらに、承認者任命は会社の特定の個人に与えられるべきではない。むしろ、 特別の任務が、承認者として承認規則に指定され得る。任務の例は“CFO”の任 務である。所定の任意の時間においてこの任務は社内の単一個人によって果たさ れるが、もし新しいCFOが雇われるなら、当該CFOによる承認を待っているすべて の要求書が、一切のシステム保守なしで、新CFOが役に就いたとき彼によって承 認され得る。新CFOである個人が本システムでCFOとして任命される場合当該CFO 任務に対して承認未決のすべての要求書が通知されるであろう。 任務には一群の人を記載し得る。例えば、購買代行者の任務がある。会社には 任意の数の購買代行者が存在し得るが、もし購買代行者任務がある要求書に割り 当てられなら、購買代行者任務により指定されるすべての個人が承認のためにそ れを見る。一実施形態においてもし彼らの一人がそれを承認するなら、その任務 に関して当該要求は承認される。 アダプタ122（図1）及び800（図8）は、本システムを企業の残りのものと連接 するソフトウエアモジュールである。本システムは、すでにこれらのレガシシス テム内に存在するデータを用いて、該システムを現存するサービスに統合するア ダプタ層を通してすべてのデータを獲得かつ記憶する。これは、企業内における 情報複製の防止を助長する。もし特定のデータに対するアダプタがないなら、本 システムは情報を内部に記憶する。しかし、もし企業内のどこかにデータが存在 するなら、該システムはアダプタを通じてデータを利用する。 重要なアダプタは会社のERPシステムに対するアダプタ804である。これらのア ダプタは、各ERP(例えば、Oracle10.4，10.5，10.6，SAP，Baan，D&B，PeopleSo ft等)とインタフェースするように特注され得る。ERPアダプタは、ERPから単純 な情報を入手し得る。即ち、アイテムテンプレート、供給者情報、承認マトリッ クス及び他の比較的静的情報のみならず、測定単位、会計情報等である。アダプ タはすべての承認済み要求書をERP内へ戻して記憶することもできる。 会社内の他の情報ソースは、名前、組織情報、交際情報等の全従業員の記述で ある。しばしばこの情報はHRMSシステムから来る。一実施形態ではHRMSアダプタ 806（例えば、PeopleSoft、Version 5.0）が与えられる。 使用者証明システム用のアダプタ808もある。使用者証明情報は、LDAP、Micro soft Exchange又はUnix NTSのような外部デイレクトリサービスに通常記憶され る。 本システムの実施形態が概観的に広く説明されたので、当該実施形態の構成部 分につき詳説する。使用者環境 本節では従業員が見るシステム部分、即ち、使用者インタフェース及び関連す る支援及びウイザッドシステムつき記載する。 本節を読む場合拡張可能フィールドデザインを心に留めるべきである。即ち、 システムの各例示は、特別の会社に適切な情報を提供するために特注される、わ ずかに異なった使用者インタフェースを持ち得る。この文書はデータフィールド を記載する多くの表を含む。各表は、２種類のフィールドを弁別する。即ち、 ・ 真正（組込み）フィールドは、システムが発見することを期待するフィール ドである。 ・ 外因性フィールドは、概して設置間に加えられる、追加の特注フィールド である。特定の会社が所望するものに依存して任意の数の外因性フィールドが存 在し得る。本システムは、これらのフィールドで情報を記憶かつ表示するが、望 ましい実施形態ではそこに情報を有することに依存しない。この文書は、外因性 フィールドがどのように利用され得るかを例示するためにそれらの多くの例を含 む。要求書 本節は本システムの基本的機能性につき記載する。即ち、要求書を作成するこ とによって従業員があるものを求めていか取り組むかを説明する。 １ 新要求書開始 要求書を作成する使用者インタフェースは、初心者（一年に１度か２度しかシ ステムを用いない者）及び熟練者（殆ど毎日システムを利用する）の双方に適切 でなければならない。 システムは、使用者が少なくとも以下の方法で新しい要求書を作成可能にする 。 ａ 各段階において一連の質問を通じて従業員を導く要求ウイザッドで、大き な状況を辿れるように進行案内的援助をあたえ、従業員に書込みを求める代わり に可能な限り選択リストを提供する。 ｂ 存在するクローン（分枝群）与える。 ２ 要求書充填 要求書は従業員が注文したい任意の個々のラインアイテムを含み得る。一実施 形態では、すべてのラインアイテムに間に割り当てられる要求書の部分及び個々 のラインアイテムに特有の他の部分がある。全要求に適用する情報を初期化する ためにシステムは以下を行う。即ち、 ａ 入手可能な従業員プロファイルから要求分野を満たす。例えば、プロファ イルから出荷情報及びデフォルト部門を初期化する。従業員は特定の要求書につ きこれらのデフォルトのすべてを変え得る。 ｂ 各要求書につき独特な英数字を発生させる。数のフォーマットは、企業構 成の一部として定められるプレフィックスストリング（接頭列）を含み得る。 ｃ 従業員が、要求識別番号より記憶しやすい表題を与え得るようにする。 ｄ 従業員が要求書を用意して他のもののために提出する方法を与える。即ち 、作成者と提出者を別にすることができる。もし要請者と提出者が異なるなら、 標準承認規則は当該要請者を第１承認者とする。 ｅ 従業員は要求書につき保留期日を特定し得る。保留期日とは要求書が実際 に購買に提出される期日である。保留期日前に要求が完全に承認されるなら、シ ステムは同期日まで要求書を保持する。保留期日がない場合には、システムは完 全承認後速やかに要求書を提出する。一実施形態では保留期日は企業全体の特性 であり、もし企業が保留機能を許すことを選択しないなら、全企業に対してシス テム内で回避され得る。 ｆ 従業員は要求書の通貨を特定し、その通貨で要求書の合計を表示可能にす る。 ｇ 従業員が要求書を初期化する時点で各々にタイムスタンプが押される。 以下の表１は、要求書記録のフィールド（欄）の概要である。 表１：要求フィールド ３ ラインアイテム追加 要求書作成後、従業員はそれに対して任意の数の製品及びサービスを要求ライ ンアイテムとして追加できる。本システムは、人手でによる情報書込みを求める よりは、従業員が承認済みソースからアイテムを選択する方向に導く。即ち、イ ンタフェースは、コピー及び選択を重視し、書込みを強調しない。 本システムは、従業員が要求書でラインアイテムを作成するために以下の方法 を与える。即ち、 ａ 製品情報データベース（Product Information Databases）の走査、検索 。 企業用の製品情報データベースは、購入を承認されている全アイテムの集合であ る。 使用者は、木階層（トリーヒエラルキー）を案内として進み得る。例えば、事 務用品(Office Supplies)、コンピュータ周辺装置(Computer Peripherals)、産 業装置（Industrial Equipment）等、次いでネットワークアダプタ(Network Ada pter)、デスクドライブ(Disk Drive)、モニタ（Monitor）等を通じてコンピュー タ周辺装置からの選択を通じて移動し得る。 使用者は同様に以下のフィールドにつき「内容」探索で製品情報データベース を探索し得る。即ち、アイテム説明(Item Description)、提供者部品識別(Suppl ier Part Id)、製造部品識別(Mfg.Part Id)、製造業名（Mfg.Name）及び商品コ ード(CommodityCode)。 ｂ 個人の好物リストからの選択。一実施形態の好物リストは、従業員が好む ものとして選択かつマークした25アイテムに及ぶ「フラット」(flat)リストであ る。 ｃ 製品情報データベース又はあらゆるウエブ（Web）カタログから入手でき ないアイテムを注文するために、人手による入力、書込み又はコピー機能が用い られる。初めから入力する場合、要請者は供給者を示唆するか（クイックピック リストから選択するか又は直接それを書き込むことによって）若しくはそのまま にしておいて購買代行者に選択させるようにすることができる。承認済みソース からでないアイテムに対する要求書は、購買代行者が新しいアイテム及び供給者 を承認することを要するような、概して特殊な承認規則をトリガする。本システ ムは、このような要請を処理する各社独自の規則を定めるのを容易に達成する手 段を与える。 ４ ラインアイテム充填 ラインアイテム追加後、従業員は当該ラインアイテムに対するあらゆる情報を 適切に修正することができる。精度を最高にするために全フィールドにつきクイ ックピックが与えられる。特に、従業員は以下を行い得る。即ち、 ａ 注文すべき量を特定する。 ｂ 出荷及び引渡し宛名を特定する。 ｃ 運送強者又は運送方法を修正する。 ｄ 必要期日を特定し、有効なためにはその期日までにアイテムが到着する期 日を供給者に通知するようにする。 一実施形態における要求書記録内のラインアイテムフィールドは以下の表２で 説明される。 表２：ラインアイテムフィールド ５ 所見及び付記 要求書を扱う全ての従業員は、要請者又は承認者を問わず、要求書に対して所 見を加えるか又は文書を添付し、それを見るものすべてが要求書をよりよく理解 するように助成することができる。所見を述べかつ説明する能力は、要求書が承 認者に理解できるようにするのに大いに役立ち、彼らが要請者にフィードバック しかつ要請を承認にするかどうかにつき決定するのを助成するのを可能にする。 所見を述べる機構は以下の通りである。即ち、 ａ 前後関係を保つためにスレディイング（threading）を用いて使用者が任 意の要求書又はラインアイテムに文字による所見を加えることを可能にする。 ｂ 所見のために使用者が、承認者(Approvers)、要請者(Requesters)、供給 者(Suppliers)、購買（Purchasing）又は全員（All）を含めた見る人を特定する ことを可能にする。所見は特定の人によってのみ見ることができる。 ｃ 使用者が所見に電子文書を付けることを可能にする。標準独立性を確保す るためにこの特性は走査器のメール機能を用いて実施されるのが望ましい。もし 従業員が彼らのメイラー(郵便装置)からアタッチメント（添付物）を送ることが できるなら、彼らは文書を要求書に添付できる。 ６ 完全要求書提出 従業員が要求書の充填を完了し、その提出を要請する場合本システムは、承認 のために要求書を実際に提出する前に以下のチックを行う。 ａ 全ての義務的フィールド（任意選択フィールドとは区分して）を探し、そ れらが値を持つことを確認する。もし失われた値があるなら、さらに編集するた めに使用者に戻される。 ｂ 値を有する各フィールドにつき当該関連フィールドにとって値が有効であ ることを確認するためにそのフィールド内のデータを実証し、さらに会計組合わ せ（例えば、会計（Account）部門等）が有効であることを確認する。もし外因 性フィールド（この会社に対する特注）に対する確認手順があるなら、これらの 確認手続きも実行する。もし無効フィールドがあるなら、さらに編集するために 要求書を使用者に戻す。 ｃ 各ラインアイテムをチェックし、そのラインアイテムに対する推薦購買人 を割り当てる。会社は、要求書内の任意のフィールドに基づいて、ラインアイテ ムに対する購買人任命規則をパラメーターで表すことができる。もしこの供給者 と直接注文協定があるなら、推薦購買人は供給者プロファイルで合意された購買 人であろう。（供給者プロファイルは、有効な直接注文協定の有無を特定する。 ） ｄ システムプロファイルからのデフォルトを用いて対要請書情報を加える。 ｅ 要求書の提出日として、現日時で要求書にタイムスタンプを押す。 ｆ 会社の業務規則に定められる承認規則を用いて、この要求書に対する承認 経路を決定し、従業員が予め承認経路を切ることを可能にする。従業員が、提出 を確認するか若しくはそれを取り消して要求書を編集に戻すかのいずれかを可能 にする。オーガナイザ（Organizer） 要求書を類別し分類する使用者インタフェースソフトウエアは、オーガナイザ 504（図５）として知られている。承認者は、要求書を承認若しくは拒否し、要 請者は現状及び歴史をチェックするためにそれを用いる。 要請書が提出されると、本システムは会社の承認規則をチェックし、どの使用 者がどんな順序で要請承認を求めているかを決定し、次いで注目されることを待 つ要求書があることを第１承認者に知らせる。各承認者は、入力する要求書の書 類ばさみ内に新しい要求書を認め、それを異なった書類ばさみに移すために要求 に対し処置をとることが必要になるであろう。 １ 要求書承認又は否定 承認者がオーガナイザインタフェースに行くと、それが通知メッセージ、ブッ クマーク又は他のハイパーリンクからであっても、オーガナイザはその承認者に 入力する要求書を表示し、各要求書に対して以下の表３内の情報を示す。即ち、 表３：承認要請フィールド 承認者が要求書を処理する場合にはいつでも、本システムは承認者の名前及び 処置時間で要求書にタイムスタンプを押す。 もし承認が必要と記されると、承認者は要求書に対仕手下記の任意の処置をと ることができる。即ち、 ａ 要求を承認する。承認は、この会社の業務規則で特定されるあらゆる通知 をトリガし、この承認者について承認されたことを要請書に記し、承認連鎖にお ける次の承認者のために入力するフォルダに同要請を加える。要請書の承認後、 承認者はそれを他のフォルダ内に移すか若しくはそれを入力フォルダ内に残す。 ｂ 要求を拒否する。承認者が要求を拒否すると、本システムは要請者に電子 メール通知を送り、この一連の承認連鎖におけるさらなる承認要請をすべて停止 させる。もし要請者が拒否通知に応答して何もしないなら、要請は最終的にタイ ムアウト（時間切れ）になる。もし要請者が要請書を修正し手それを再提出する なら、以下のだんかい５）に述べるように、システムは再び承認手順を開始する 。 ｃ この承認の前又は後に、追加の承認者を承認連鎖に加える。例えば、承認 者は「Edに承認するかどうかを尋ね、その後私に戻してください」と言いたいか もしれない。 ｄ 所見を追加する。 ｅ 要求書を修正する。すべての承認者がすべてのフィールドを変え得るとは 限らない。しかし、購買代行者が承認書の任意のフィールドを修正し、他の承認 者が同要求書内の限られた組みのフィールドのみを修正し得る。承認者がどのフ ィールドを修正し得るかの定義は会社のデータフィールド構成の一部であり、概 して設置間に設定される。 承認者が要求書の任意のフィールドを承認すると、システムは求められる承認 を再計算し、そのラインアイテム（もし変わるのがラインアイテムであったなら ）に関するか若しくは全要求（もし要求それ自体が変わったなら）に関する現存 承認のすべてを無効にする。従って、承認規則に依存して、フィールドの修正は 、要求をすでに承認している使用者からの承認をトリガするか若しくは連鎖内へ の新承認者の追加をトリガし得る。 もし承認者が任意（Optional）と記されるなら、この承認者は監視人であり、 真の承認者ではない。監視人は傍観者であり、彼らは要求書を見るが承認は不要 である。監視人は要求書に対して以下の任意の処置をとり得る。即ち、 この承認の前又は後に、追加の承認者を承認連鎖に加える。 所見を加える。 ２ 他人に代わる承認 本システムは、各従業員の個人プロファイルの直属上司情報から得られる連鎖 指令通知を維持する。その情報を用いてシステムは一定の委任された承認者が他 の承認者に代わって承認することを可能にする。即ち、 ａ 同システムは、下級承認者（業務規則により定められる）の承認を待って いる要求書のリストを、承認者が入手することを可能にする。高級承認者は、も し下級承認者と同一指令連鎖内にあるなら、任意の下級者に代わって明示的に承 認し得る。 ３ 要求書又は承認の除去 ａ 要請者は、承認手順中任意の時点で自身の要求書を取り消すことができる 。取り消された要請書は未提出状態に戻され、それまでに記録されているすべて の承認は除去される。 ｂ 購買代行者の任務を有する従業損は、あらゆる要求書から承認を除去する ことができる。 ４ 要求書編成 オーガナイザは、従業員が一群の要求書を編成するのを助長する。それは従 業員に下記事項を可能にさせる。即ち、 ａ 該略図で表示されるあらゆるフィールドによって要求書を分類する。即ち 、もしフィールドの欄見出しがあるなら、従業員はそのフィールドに整列できる 。 ｂ 該略図で表示されるあらゆるフィールドによって要求書をこす。即ち、も しフィールドの欄見出しがあるなら、表示されている情報を制限するために従業 員はそのフィールドの値を用いることができる。 ｃ すべてのラインアイテム、承認及び所見を含めてあらゆる要求書の詳細を 調べる。 ｄ 調査の結果をフォルダに入れる。例えば、購買代行者は特定の供給者から のアイテムにつきすべての末決要求書を再吟味したいと欲するかもしれない。 ｅ すべての要求書をレターペーパに印字する。 ｆ 統合されたファックス支持プラットフォーム（台）ですべての要求書をフ ァックスする。 さて、サーバ構成自体の一部ではない変更を行う意味で、システムの管理につ き述べる。１ 個人プロファイル保守 従業員の個人プロファイルが、本システム使用者の値を設定する構成ファイル に記載される。個人プロファイル内には２種類の情報、即ち、人的資源データフ ィールド及び特定データフィールドがある。人的資源データフィールドは、もし 現場にあるなら、HRMSアダプタから初期化され、同様にHRMSアダプタから定期的 に更新されるのが望ましい。完全にシステム内に特定データフィールドが作り出 されかつ保守される。 システムは以下の機能を有する。即ち、 ａ 従業員が、UIの残りのものと首尾一貫した形で、彼ら自身の個人プロファ イルの特定フィールドを検査、編集することを可能にする。 ｂ 会社の承認規則に記載されているように、個人プロファイルのすべての変 化を承認のために提出する。 ｃ 従業員が、HRMSアダプタから通される人的資源データフィールドを見るこ とを可能にする。 ｄ 従業員が、彼らの好みのリストについてアイテムを追加又は除去すること を可能にする。 以下の表４は、個人プロファイルの特定データフィールドを列記する。 表４：個人プロファイルフィールド ２ システムプロファイル保守 本システムは、例えばシステムの構成値を含む。システムプロファイル（その 例は表５に示される）はシステムが設置されるとき作成される。それは第一に新 従業員用のプロファイルを作成するときに用いられるデフォルトを設定すること を意図する。 システムは、 ａ 管理者が、簡単なテキストエディタ又はスプレッドシートを用いてシステ ムプロファイルのフィールドを変えることを可能にする。 表５：システムプロファイルフィールド ３ 製品情報データベース保守 会社の製品情報データベースは、社内購買につき承認されるアイテム用のアイ テムテンプレートの収集である。アイテムテンプレートの例は表６に例示される 。会社の購買部門（Purchasing Department）は概して製品情報データベースを 保守する責任があり、それを正確かつ価値ある資源にするのを助長する。 システムは、購買代行者がアイテムテンプレートを作成し、編集し、除去する ことを可能にする。この機能性は購買代行者のみが利用できる。それは以下の機 能を可能にする。即ち、 ａ 新アイテムテンプレートの作成。新アイテムテンプレートを作成する必要 性は、製品情報データベースにないアイテムに対する要求書がある場合に最もし ばしば起こる。もし購買代行者が当該アイテムを承認することを決定するなら、 そのために新テンプレートを作成し、それを製品情報データベースに加えるかど うかを決定するであろう。 ｂ 現存するアイテムテンプレートを編集する。購買代行者は現アイテムテン プレートを修正できる(例えば、供給者情報又は価格を更新する)。 ｃ 現アイテムテンプレートを除去する。もし購買代行者が当該アイテムが無 効又はもはや推薦できないと決定すると、購買代行者は製品情報データベースか らアイテムを非活動化することができる。これは、供給業者との関係が変化する か若しくは当該供給業者から特定アイテムがもはや入手されない場合のように、 あらゆる理由につき起こり得る。購買代行者がこのような変更をする場合には、 当該変更によって影響されるものがあるかどうか調べるために、オーガナイザビ ューを用いてすべての未決要求書をチェックすることができる。 ｄ 供給業者からのテキストファイルをSICコード{WHAT IS SIC}で読込み、こ れらのSICコードを内部商品コード内にマップし、その後関連するアイテムを製 品情報データベース内に加える。 ｅ 製品情報データベースの階層的視点を作りかつ保守し、使用者がカテゴリ 周囲を通して移動する物を発見できるようにする。 表６：アイテムテンプレート システムは、購買会社が要約し、分析し、理解しかつ彼らのから購買手順を改 良するのを助長するために報告機能を与える。システムは、予め定められた多く の報告書と共に入手され、報告書は購買パターン（例えば、我々の購入は多すぎ るか又は少なすぎるか？）から手順それ自体（例えば、タイムリーに承認しない のはだれか？）及ぶ。この情報は、例えば、承認手順を修正するか若しくは供給 者を切り替えることによって、会社がその実務を向上させるのを助長し得る。 １．レポートの定義 システムは、システムに含まれている情報を分類及びグループ化するための 様々なレポートを提供する。そのレポート出力機能により、従業員はレポートを パラメータ表示するとともにそれらを実行することができるが、特別なレポート は定義できない。 従業員は以下のことを実行することができる。 ａ．出力されたどのレポートの結果でもファイルに保存することができる。２ つの出力フォーマットが存在する。即ち、人間の消費に関して、一つはスプレッ ドシートによって読み出すことができるもので、もう一つは単純なテキストであ る。 ｂ．出力されたどのレポートでもプリントすることができる。 ｃ．どのレポートに対してもレポート期間を定義することができる。レポート の期間は、「全期、今日／週／月／年／４半期、昨日／週／月／年／４半期、他 (特別な開始日及び終了日が特定できる場合には)」のように、記述することがで きる。４半期の定義はシステムのプロファイルから設定される。２．すべての従業員のための標準的なレポート 以下の表７はすべての従業員が利用できる標準的なレポートを示す。 表７：すべての従業員のための標準的なレポート ３．購買担当者が利用できる標準的なレポート 表８に示すような、購買担当者としての職務を持つすべての従業員が利用でき る標準的なレポートを提供する。 表８：購買担当者のための標準的なレポート システム環境 承認の流れ 各会社は、一般的に、各要求を承認しなければならない者を確定にするための その会社独自の承認手順を持つ。システムは、一組の「承認規則」を用いてその ような手続を具体化しており、その「承認規則」は各会社がパラメータ表示する とともに拡張することができる。その承認規則は配置手順の一部として規定され ているが、顧客のシステム管理者によっていつでも変更することができる。 その承認規則は望ましくはどのようなテキストファイルエディタでも編集でき るようなテキストファイルに記憶される。 １．承認規則のパラメータ表示 この承認規則の最も簡単なフォームは表形式のファイルフォーマットであり、 それはその規則で使用される値を記述する。そのファイルフォーマットによって 、顧客は以下のことを行うことができる。 ａ．表形式のファイル内の値を編集することによって承認規則をパラメータ表 示することができる。例えば、会社は、その承認規則自体を変更することなく、 さまざまな管理レベルによる承認と関連づけられるべきルの総額を変更すること ができる。 ｂ．システムが実行されている間にパラメータを変更することができる。シス テムはダウンタイム無しで新たなパラメータを読み込む。 ２．承認規則 承認規則を記述するために、システムは、ファイル承認のどのような条件又は 条件の組をも記述することができる程度の概して融通のきく簡単なスクリプト言 語を提供する。各規則は以下のものを持つ。 ａ．この規則が呼び出された理由の説明として用いられる弁明フィールド。 ｂ．この規則がいつ適用されるかを決定する属性。この属性は、例えば、商品 、適用期間、購入量、輸送アドレス又は特定の会社が追加した注文で作られた（ 即ち、拡張性がある）フィールドまでも含む要求のどのようなフィールドにも基 づくことができる。 ｃ．属性が適用されたときの結果。この結果はどの１つの職務又は複数の職務 が要求を承認しなければならないのかを表わす。例えば、会社が、購買担当者の 職務を持つ従業員に、２００ドルを越える総額に関するとともにデフォルト輸送 先アドレスとは異なる輸送先アドレスを持つどのような要請をも承認することを 要求す規則ルを定めることができるであろう。その特別の総額、即ち、２００ド ルは、表形式のファイルに明記されることになる。即ち、属性−結果は規則ファ イル中に存在することになる。 ｄ．どの承認を逐次行うことができるかということと、どれを同時に行うこと ができるのかを説明する方法。例えば、編成は連続する管理承認は逐次行うこと を望むが、他の承認（設備及びＩＳ）は同時に行うことを望むであろう。 ３．バイヤー割当て規則 要求内の各ラインアイテムは購買担当者に割り当てられている。システムは、 承認要請を出す前にその割り当てられた購買担当者を指定する。各会社は、承認 規則を規定した際に用いた手順と同じ手順を用いて、購入者を割り当てる方法に 関して独自の規則を規定することができる。例えば、会社は購入者の割当てが商 品の種類及び購入量の両方に依存することを望むかもしれない。 ４．エスカレーション及びタイムアウト システムは、承認者が承認要請に対し応答していない場合に、手動で又は自動 的に、承認をエスカレートさせる機能を提供する。承認要請をエスカレートさせ ると、それは管理連鎖を上に移動し承認者の直属上司まで達する。 システムは、エスカレーションに関して以下の特徴を提供する。 ａ．要請者が要請を手動でエスカレートすることができる。 ｂ．承認者が、システムのプロファイルで定められているエスカレーション期 限内に承認要請に対し応答していない場合には、システムは自動的にその承認要 請をエスカレートする。エスカレーションは、必要場合に応じてだれかがアクシ ョンをとるか又は管理者がいない従業員まで連鎖を昇りつづける。 ｃ．要求がある所定の期限内に承認されなかった場合には、システムプロファ イルに規定されているように、その要求はタイムアウトになる。即ち、提出され たが特定の期限内に完全には承認されなかったようなどのような要求も管理者ま でエスカレートされる。 ｄ．一旦承認要請がエスカレートされると、元の指定された承認者はその要請 に対してもはやアクションをとることはできない。 ５．権限の委任 権限の委任（ＤＯＡ）は特定の期間、例えば、承認者が休暇を採っているとき にそのものからある承認者に代えることである。１つの実施例では、システムは 以下の方法で権限の委任を支援している。 ａ．どの従業員もある期間自分の権限を他の従業員に委任することができる。 ＤＯＡは開始日、終了日及びこのＤＯＡが実施されている理由を説明するコメン トフィールドを含む。このＤＯＡはその従業員の個人プロファイルに記憶される 。即ち、個人プロファイルをすべて変更するのと同様に、権限の委任は会社の承 認規則に従属する。従業員は同時に２以上のものに権限を委任することはできず 、さらに、２以上の指定されたものにＤＯＡを分割することもできない。 ｂ．ある従業員に権限の委任があり、その委任日が満了していない場合に、シ ステムはその代行者がその従業員の地位で承認を行えるようにすることができる 。 ｃ．オーディト・トレールの一部として権限の委任のすべてを記録する。分担されたサービス １．承認及びユーザーの権利 すべての従業員は、システムを利用するためにログインをしさらに承認されな ければならない。システムには３種類のユーザーが存在する。即ち、購買担当者 、管理者及び従業員である。購買担当者及び管理者は、従業員が許容されていな いいくつかのオペレーションを行うことができる。以下の表９は、ある種のユー ザーに限定されているオペレーションを示す。 表９：承認を必要とするユーザーの権利 ２．イベント及び通知 システムは、何が特定の要求をし続けているのかについてすべての利害のある ものに情報を提供し続けることをサポートするように設計された通知機能を提供 する。システムは、従業員に通知するためのトリガである一組のイベントとその 通知の受取人を規定する。一実施例では、その一組のイベントのカストマイズは 存在しない。 システムは、以下のことを行う。 ａ．以下の表１０に概要を示す各規定されたイベントに対しｅメールを通知す る。その通知メッセージには望ましくは管理組織へのハイパーテキストリンクが 含まれる。 ｂ．従業員がイベントごとの通知頻度をカストマイズ化できるようにする。そ の通知頻度は非通知、即時又はインターバルをおいてというように特定すること ができる。ここで、そのインターバルは秒、分、時間又は日数の整数である。従 業員が非通知を指定することができるか否かの決定は望ましくはシステムプロフ ァイルの一部である。即ち、ほぼ通知を止めることができるか否かを選択するこ とは会社ごとに行われる決定である。 表１０：通知を必要とするイベント ３．データベース支援 システムはデータベースを使用して、すべての内部データを記憶するとともに 、クライアントとエンタープライズサーバーとの間のすべての取引きを記録する 。一つの実施例では、このデータベースはOracleデータベースサーバーに存在す る。 ４．顧客サポート及びフィードバック 顧客がシステムをどのように使用しており、さらに、それらのものがシステム の使用をどのように使用したいのかを理解するために、顧客側からのフィードバ ックは重要である。そのようなフィードバックを促進するために、システムは以 下のことを行う。 ａ．簡単なフィードバックコマンドを提供して顧客がｅメールでの提案を行え るようにする。 ｂ．サポートのネットワークグループ又はウエブサイトを提供する。 ｃ．重大なシステムエラーが発生したときにはそれを伝える。 ｄ．各月の終わりにｅメールによって、月ごとのラインアイテムの総数の統計 を送る。 ５．ｅメール統合 システムがすでに同じ場所（例えば、ＳＭＴＰ）に置かれたｅメールプログラ ムを統合すると、システムはｅメールを使って従業員に通知を送ることができる ようになる。ビジネスモジュール ビジネスモジュールはシステムから分離できる部品である。発注モジュール 発注モジュールは完全に承認された要求を受け取りそれを履行するために提出 することを行うシステムの一部である。要求が完全に承認されたときには、シス テムは以下のことを行う。 ・ それに、最終承認の日付及び時間のタイムスタンプを押す。 ・ 要求をチェックしてどの供給者が必要であるかを決定し、その特定された 供給者のサイトが２以上存在する場合には、１つの供給者サイトを選択する。 ・ 各供給者ごとに望ましい発注モジュールを選択し、それを用いてオーダー を伝達する。 ３つの発注モジュールは、購入カードモジュール、ダイレクトオーダーモジュ ール及び購入オーダーモジュールである。 １．購入カードモジュール 購入カードの発注モジュールは、１つの支払方法として購入カードの使用をサ ポートする。購入カード（ｐカード）は、特定の従業員又は供給者に関連させる ことができるが、そのカードが有効であること及び適切に用いられることを保証 するため管理者によって保持される。購入カードの取り引きは、定期的に、その 購入カードを発行した銀行と一致させられる。 システムは、以下に表１１に示すように、各購入カードと関連する以下のデー タを維持する。 表１１：購入カードと関連するデータ 購入カードモジュールにより以下のことが行える。 ａ．管理者はカードを従業員に割り当て、購入カード上の失効日付又は承認範 囲を変更することができる。 ｂ．完全に承認された各要求に対し、ｐカードをこの購入に用いることができ るのか否かを確認する。 ・ 供給者がｐカードを承諾することを保証し、そうでなければ、別の発注モ ジュールを選択する。 ・ ｐカード番号を選択する。供給者がゴーストのｐカードを持つ場合には、 それは優先するｐカード番号である。そうでなく、従業員があるｐカード番号を 持つ場合にはそれを用いる。そうでなければ、他の発注モジュールを選択する。 ・ 購入総額をチェックする。それがその購入カードの取引きごとの限度を超 えている場合には、いくつかの他の発注モジュールを選択する。 ｃ．購入カードを用いた各取引きに対し、システムは、表１２に示すようにデ ータを記録する。そのデータは、取引きに関するプリント出力レポートを用いて 、月ごとに銀行と一致調整させられる。一致調整に用いられたレポートは「承認 済み不一致」を示すが、その値（即ち、ｐカードの注文総額）は、税金及び引渡 し料を含まないが、銀行の値はそれを含むからである。 表１２：ｐカード取り引きにおけるデータ レポート 会社がこのモジュールを購入するときには、追加の入手できる標準的なレポー トが存在する。以下の表１３及び１４に示すようなレポートが提供される。 表１３：従業員用レポート 表１４：購入に関するレポート １．ダイレクト注文（ＤＯ） ダイレクト注文モジュールは、ＥＲＰシステムにおいて要求を記憶することな く、購入者と供給者との間で直接に注文の通信をサポートする発注モジュールで ある。ダイレクト請求契約の下では典型的には注文には制約は存在しない。その ダイレクト注文契約には、期間及び条件が含まれるとともに、請求の頻度が指定 されている。 供給者との間にダイレクト注文契約が存在する場合には、システムは以下のこ とを実行する。 ａ．商品のテンプレート内でダイレクト注文に関してトランスファー方法が指 定されたことをチェックする。購入注文（ＰＯ）又はＤＯ注文モジュールのどれ も商品テンプレート内で指定されなかった場合には、供給者のプロファイルがそ のトランスファー方法のためにチェックされる。その供給者のプロファイルがダ イレクト注文を指示する場合にはそれが方法となる。そうでなければ、それはＰ Ｏとして取り扱われる。 ｂ．供給者のプロファイルで指定されているように、ファクシミリ又はｅメー ルを経由して要求を直接供給者に伝達する。供給者に伝達されたすべての要求は オーディト・トレールデータベースに記録される。受取り確認の情報はシステム に保持されるだけである。 ｃ．購入担当部が供給者からのマスターの計算書と一致させることを補助する ために、システムからの取り引きのレポートを提供する。このレポートの頻度に は供給者からのレポートの頻度が反映される。 ２．購入注文 購入注文のモジュールは発注モジュールであり、その場合はＥＲＰシステムに おける購入要求となる。システムはＥＲＰ要求としてその要求をＥＲＰアダプタ ーに伝達する。一度でも要求がＥＲＰにあると、購買担当者は標準的なＥＲＰオ ペレーションを用いてそれを操作して工程を完了することができる。例えば、担 当者は典型的にその要求から自動的に購入注文を作成し、それを印刷し、そして それを履行のために供給者に送る。受取り 注文が承認されて供給者に提示及び伝達された後、結局は、その供給者は、商 品を輸送し、要求者はそれを受け取ることになる。商品が受け取られたときには 、要求者はその商品を受け取ったことを通知しなければならない。受取りは支払 いを生じさせる最終的な通知となる。 システムは、受取りを通知するためのユーザーインタフェースを備えており、 それにより、従業員は様々な商品を受け取ったことを記録することができる。そ の受取りはシステムに記録され、たとえＥＲＰが存在しても、基本的なＥＲＰと の対話は存在しない。実行の間に設定することのできるシステム・レベル・トグ ルは受け取りモジュールが機能できるようにする。 １．商品の受け取りの通知 システムは、従業員が物理的に商品を受け取ったことを表わすための簡単なフ ォーム（このフィールドを以下の表１５に示す）を提供する。この受取りインタ フェースにより以下のことが実行できる。 ａ．従業員は、注文した商品の受取りを承認することと、受け取った商品の数 を記録することができ、それは以下の表の情報を示す。その従業員は単一のライ ンアイテム又は全体の要求のいずれかを承認することができる。 ｂ．従業員は全体の要求又は個別のラインアイテムのいずれも拒否できる。従 業員が何かを拒否する選択をしたときには、システムはその拒否の種類を説明す る自由な形式のコメントを請求する。従業員はその情報をコメントの中で伝える ことができるが、数量に関しては一部を拒否することはできない。 表１５：受取り承認のフィールド 承認及び通知 従業員が商品を拒否した場合には、システムは購買担当者に通知し、その拒否 を記録する。レポート 表１６及び１７に示すレポートは、コアシステムによってレポートのコアリス トに加えることができる。 表１６：従業員用レポート 表１７：購入者用レポート システムアダプター システムは可能な場合にはアダプターを用いることが望ましく、これにより、 既に入手したどの情報の重複をも回避することができる。しかし、システムは、 それらのアダプターの内のどのアダプターの存在にも依存してなく、会社が特定 のサービスを持っていない場合又はそれを利用できるアダプターが存在しないと きには、スタンドアロンとして実行することができる。ディレクトリーサービスアダプター システムは望ましくは会社内のディレクトリーサービスからユーザー名及びパ スワードを利用することができるが、それは、そのようなサービスが会社に存在 するとともに、会社が適当なアダプターを持つ場合である。会社が認証サービス を持たない場合には、システム自体が従業員の氏名及びパスワード情報を記憶し 、それにより、適当に承認されたシステム管理者が新たなユーザーを設定するこ とができるようになる。 １．ＬＤＡＰ認証アダプター ＬＤＡＰ（ライトウエイト・ディレクトリー・アクセス・プロトコル）までの ディレクトリーサービスアダプターが提供される。ＬＤＡＰは、インターネット クライアント、アプリケーション及びＷＷＷサーバーに標準的な方法を提供して インターネットを越えてディレクトリー情報にアクセスできるようにするプロト コルである。 そのＬＤＡＰは以下のことを行う。 ａ．ＬＤＡＰプロトコルを用いて会社全体のパスワードにアクセスし、さらに 、それらのパスワードを用いて従業員を認証する。 ｂ．顧客のＬＤＡＰサーバーがリアルタイムの認証をサポートする程度に高速 な場合には、ユーザーのリアルタイム認証を提供する。人的資源管理システムアダプター ＨＲＭＳシステムは、名前、メールストップ及び組織構造のような従業員の情 報を維持するために用いられる。利用できるＨＲＭＳアダプターが存在しない場 合には、システムは、従業員のデータをシステム自体のデータベースに記憶し、 また、適当な認証されたシステムアダプター管理者が従業員を追加／削除／変更 することができるような基本的な従業員マネージメントをサポートする。 １．PeopleSoft ＨＲＭＳアダプター PeopleSoftシステムへのＨＲＭＳアダプター、バージョン５が提供される。 そのPeopleSoftアダプターは、以下のことを行う。 ａ．規則的にPeopleSoftデータベースから従業員の情報を抽出し、新たな従業 員が作られた場合にはシステムを更新する。新たな従業員の更新が発生したとき には、システムは利用できるときにはＨＲＭＳからフィールドに書込みを行う。 他の追加のフィールドは、それらの直属の上司からの、又はマネージャーがシス テム内に存在しないか見つからないときにはシステムプロファイルからの初期設 定値を用いて初期化される。 ｂ．以下の表１８に示すフィールドを抽出する。 表１８：人的資源データ ＥＲＰアダプター ＥＲＰアダプターはシステムを企業のＥＲＰシステムに統合する部品である。 このアダプターは各ＥＲＰ（例えば、Oracle 10.4、10.5、10.6、ＳＡＰ、Baan 、Ｄ＆Ｂ他）ごとにカストマイズされる。 システムの一実施例は、アダプターをOracle ＥＲＰバージョン10.4、10.5及 び10.6に提供する。 １．要求アダプター この要求アダプターはＥＲＰと統合される基本的な部品である。それは、完全 に承認された要求をそのＥＲＰにプッシュし、そこでは、それらはＥＲＰシステ ムの購入注文（ＰＯ）に変換される。そのアダプターはそれらの要求に対する購 入注文番号を引き戻し、そのＰＯ番号を各ラインアイテムと関連する非本質的な データフィールドとして記憶する。 このアダプターは各ラインアイテムごとに以下のデータをプッシュする。 記述 コメント 要求者氏名、要求者がＥＲＰに存在する場合。そのようなユーザー名がＥ ＲＰ存在しない場合には、標準的なキャッチオールユーザー になる。 承認 数量 ユニットプライス 測定の単位 輸送先及び引渡し先アドレス 部品番号 部品の説明 精算情報 輸送方法の詳細−−運搬会社及び運搬方法 供給者 ２．測定単位のアダプター システムはＥＲＰから測定単位のセットを引き出し、それをユーザーインタフ ェースの中で使用する。システムは以下のデータを引き出す。 名前 略語 測定の基本ユニット 測定の基本ユニットへの変換 ３．精算情報アダプター システムは、会社のために規定された精算の詳細がどのようなものであろうと もＥＲＰから精算情報を引き出す。例えば、精算フィールドは以下のものでもよ い。 会社名 会社のビジネス単位 部門 口座 プロジェクト情報 ４．商品コードアダプター システムはＥＲＰから商品コード情報を引き出す。商品コードの正確な構造は 会社に依存する。例えば、 商品名 商品ごとの精算情報。 ５．通貨レート表アダプター システムは、通貨の交換が必要なときにはいつでもレート表を用いてＥＲＰか ら通貨レート表を引き出す。このアダプターは通貨の表を引き出し、各レートご とに変換し、以下の情報を導く。 通貨の名前 通貨レート 指定レートが有効な日付 有効通貨のリスト ６．供給者プロファイルアダプター システムは、周期的に、ＥＲＰから供給者の情報を引き出し、その供給者の情 報を供給者プロファイルに記憶する。このアダプターは、以下のことを行う。 ａ．ＥＲＰから新たに設定された供給者を引き出す。購買担当者は、誰かが新 たな商品を要求したときには新たな供給者のプロファイルを作る必要がある。即 ち、要求に特別のアイテムが含まれていたときには、その購買担当者は、適当な 供給者を探し出し、その供給者のプロファイルをＥＲＰに追加する。それからそ の変更はシステムに引き戻される。 システムの供給者プロファイルは以下の表１９に示すフィールドを持つ。 表１９：供給者プロファイルデータ 一実施例の特徴：システム要件 １．スケーラビィリティ ａ．−ヶ月に少なくとも１０,０００点の要請書を支援するシステムを与える 。 ｂ．少なくとも２０,０００の供給者を支援するシステムを与える。 ｃ．少なくとも３５,０００人の雇用者を支援するシステムを与える。 ｄ．一つの場所におけるシステムの多重例についての体系的な支援を与える。 サーバー支援の各例は、一つのＥＲＰ例のみである。サーバーの多重例の間の「 ロールアップ("roll-up")」能力はない。 ２．クライアント支援プラットフォーム Java支援によりウェブ・ブラウザ(Web browser)内で実行するJavaクライアン ト。以下のプラットフォームおよびシステムで検査された。 ・ウインドゥズＮＴ４.０上のマイクロソフト（商標名）インターネットイク スプローラ（商標名）３.０１以降。 ・ウインドゥズ９５で動作するマイクロソフト（商標名）インターネットイク スプローラ（商標名）３.０１以降。 ・アップルマッキントッシュ（商標名）で動作するマイクロソフト（商標名） インターネットイクスプローラ（商標名）３.０１以降。 ・ウインドゥズＮＴ（商標名）４.０上で動作するネットスケープ（商標名） ナビケータ（商標名）３.０１以降。 ・ウインドゥズ９５（商標名）上で動作するネットスケープ（商標名）ナビケ ータ（商標名）３.０１以降。 ・アップルマッキントッシュ（商標名）上で動作するネットスケープ（商標名 ）ナビゲータ（商標名）３.０１以降。 Sun Solaris上で動作するネットスケープ（商標名）ナビゲータ（商標名）３. ０１以降。 ・HP-UX(HPユニックス)上で動作するネットスケープ(商標名)ナビゲータ(商標 名）３.０１以降。 ３．サーバー支援プラットフォーム ａ．マイクロソフト（商標名）ウインドゥズＮＴ（商標名）４.０が動作する 専用のインテル（商標名）ペンチナム・プロ・システム上で動作するサーバーの 実行を与える。以下の最小サーバー形態を与える。 ・プロセッサ インテル（商標名）ペンチナム・プロまたは２００ＭＨｚ以上の 互換品 ・キャッシュメモリ ２５６ＫＢキャッシュ以上 ・メモリ １２８ＭＢ ＲＡＭ以上 容量 データベースの大きさに依存して４ＧＢハードドライブ以上の容量 ｂ．Solaris 2.5.1,Oracle RDBMS 7.3.2.3,Netscape Enterprise Server 2.0. 1 が動作するSun Machine上で動作するサーバーの実行を与える。 ４．構成 ａ．導入するに先だって、サイトについての基本的な情報を集めるためのテン プレートを与える。即ちホストDBMS、運営・システム、ERPおよびHRMSインター フェース、ｅメールインターフェース、会計および購買手順、供給者データ、ク ライアントハードウェアおよびソフトウェア、支援ブラウザ、ネットワーク形態 、および業務規則である。 ｂ．テキストファイルエディタを用いて拡張可能なフィールドと承認規則を構 成する。 ５．データベース供給 移行期間の互換性のために、システムは、その外部から手動で承認される要請 書をデーターベースへ供給する能力を与える。この機能は、紙の要請書から電子 化への企業移行を支援するのに使い勝手のよいものとして意図されている。 システムは、紙の要請書の全体を、署名の手順を用いることなく、システムへ 導入する処理を可能とする。この方式で導入された要請書は報告書に現れるが、 承認要請書または通知書は生成せず、購買代行者の直接介入を伴わずに製品情報 データベースの一部になることはない。 ６．独立型システム(standalone system) この欄では、システムが独立型であり、即ちＥＲＰアダプタが存在しないと きに、基本的な機能を与えることのみに利用可能なシステムの特徴を説明する。 ａ．購買注文書を印刷出力してこれを供給者へ転送させる能力を与える。印刷 された購買注文書は、標準的な備考（例えば供給者の期限および条件）と購買注 文番号とを含む。これはシステムが購買注文書を生成する唯一の機会である。 ｂ．生成されたＰＯを供給者へ送るのに先だって、そのＰＯを購買代行者に変 更させることを可能とする。 ｃ．更なる供給者のためのユーザーインターフェースを与え、供給者適合機能 の簡易版を与える。 本明細書に説明した本発明の実施例に対する様々な代替例が、本発明の実践に より採用し得ることを理解されたい。以下の請求項は、本発明の目的を規定する ものとして意図されており、それらの請求項の目的の範囲内にある方法および装 置ならびにそれらの均等物を包含する。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＬ，ＡＭ，Ａ Ｔ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ， ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ， ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，Ｓ Ｅ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 カールストロム、ブライアン アメリカ合衆国、カリフォルニア州 95054、サンタ・クララ、ランニング・ウ オーター・コート 2343 (72)発明者 エルキン、ブライアン アメリカ合衆国、カリフォルニア州 94086、サニーベール、ナンバー48、リー ド・アベニュー 1180 (72)発明者 ハガティー、ポール アメリカ合衆国、カリフォルニア州 94555、フレモント、ウェブフット・ルー プ 34032 (72)発明者 ハスキン、ガイ アメリカ合衆国、カリフォルニア州 94086、サニーベール、エリカ・ドライブ 944 (72)発明者 ピュタネク、ボリス アメリカ合衆国、カリフォルニア州 94025、メンロ・パーク、ローレル・スト リート 1175

Claims (1)

1. 【特許請求の範囲】 １．企業内の運営資源の効率的調達のためのソフトウェアシステムであって、 要請書のための要請書記録を生成する要請書記録生成手段であり、その要請 書記録は少なくとも、要請者が購買を希望する運営資源を示し、前記要請書の ための要請書記録を生成する要請書記録生成手段は、要請者による入力と、運 営資源情報データベース内の運営資源情報との組み合わせに応答する要請書記 録生成手段と、 前記要請書記録と承認規則データベースにおける承認規則とに応答して、前 記要請書記録の承認を要求される複数の承認者候補の一人一人の中から前記要 請書記録についての承認経路を決定する承認経路決定手段と、 前記決定された承認経路に沿って前記要請書記録を案内する承認経路処理手 段であり、この承認経路処理手段は、前記承認経路を首尾よく通過する前記要 請書記録に応答して包括的な承認表示を生成する承認経路処理手段とを備える システム。 ２．請求項１のシステムであり、所望の運営資源の供給者への注文記録を生成し 、且つこの注文を供給者へ連絡する注文生成手段を更に備えるシステム。 ３．請求項２のシステムであり、前記要請書記録が前記供給者の表示を含むシス テム。 ４．請求項２のシステムであり、前記注文生成手段が、供給者データベースに応 じて前記注文を前記供給者へ連絡する方法を決定する手段を含むシステム。 ５．請求項１のシステムであり、前記承認経路処理手段決定手段が、 前記注文記録についての前記承認経路を少なくとも部分的には前記要請書記 録における注文量フィールドに応じて決定するシステム。 ６．請求項１のシステムであり、前記要請書記録生成手段が、要請者に関する個 人プロファイルデーターベースから要請者に関する情報を検索する手段を含む システム。 ７．請求項６のシステムであり、前記個人プロファイルから検索された情報が、 運営資源の送達が望まれる送り先を示すアドレス情報と、前記要請者が勤める 部署とを含むシステム。 ８．請求項６のシステムであり、前記要請者に関する個人プロファイルから検索 された前記要請者についての情報を、前記要請者に無効にさせる手段を更に含 むシステム。 ９．請求項１のシステムであり、前記要請書記録生成手段が、前記要請書に対し て特有の識別名を割り当てる手段を含むシステム。 10．請求項１のシステムであり、前記要請書記録生成手段が、ユーザーによりユ ーザ入力手段を介して前記要請書に割り当てられた特有の識別名を受け取る手 段を含むシステム。 11．請求項１のシステムであり、前記要請書記録生成手段が、 ユーザ入力手段を介してユーザーから待機時間の表示を受け取る手段を含み 、 前記承認経路処理手段が、前記待機時間の発生に応じて、前記承認経路に沿 う前記要請書の案内を開始するシステム。 12．請求項１のシステムであり、 包括的承認表示に応答して要請書を提出する要請書提出手段を更に含むと共 に、 前記要請書記録生成手段が、ユーザ入力手段を介してユーザーから待機時間 の表示を受け取る手段を含み、 前記要請書提出手段が、前記待機時間の発生に際してのみ前記要請書を提出 するシステム。 13．請求項１のシステムであり、前記要請書記録生成手段が、 要請者から通貨単位を指定する入力を受け取る手段と、 指定された通貨単位の運営資源についての購買量を報告する手段とを含むシ ステム。 14．請求項１のソフトウェアシステムであり、 動産データベースプログラムからデータを検索するアダプタ手段を更に備え 、 前記要請書記録生成手段は、前記動産データベースプログラムから検索され たデータを用いて前記要請書記録のフィールドを終了することにより、既に有 効なデータの重複を回避するソフトウェアシステム。 15．請求項１４のソフトウェアシステムであり、前記アダプタ手段が、前記企業 のディレクトリサービスとインターフェースするディレクトリサービスアダプ タであるソフトウェアシステム。 16．請求項１５のソフトウェアシステムであり、前記アダプタ手段が、前記企業 の人的資源管理システムとインターフェースする人的資源管理システムアダプ タであるソフトウェアシステム。 17．請求項１６のソフトウェアシステムであり、前記アダプタ手段が、周期的に 前記動産データベースプログラムへ相互作用するソフトウェアシステム。 18．請求項１４のソフトウェアシステムであり、前記アダプタ手段が、包括的承 認表示に応答して、前記要請書を前記企業のＥＲＰシステムへ転送する手段を 含むソフトウェアシステム。 19．請求項１８のソフトウェアシステムであり、前記アダプタ手段が、前記企業 のＥＲＰシステムから前記要請書に対応する購買注文番号を検索する手段を更 に含むソフトウェアシステム。 20．請求項１８のソフトウェアシステムであり、前記アダプタ手段が、前記企業 のＥＲＰシステムから供給者情報を検索する手段を更に含むソフトウェアシス テム。 21．請求項２０のソフトウェアシステムであり、前記企業のＥＲＰシステムから 検索された前記供給者情報に基づいて供給者特性を形成する手段を更に備える ソフトウェアシステム。 22．請求項１のソフトウェアシステムであり、 前記承認規則の各々が属性と結果とを含み、 前記承認経路決定手段が、前記属性を適用することにより特定の一つの承認 経路を前記要請書記録の少なくとも一つのフィールドへ適用するか否かを決定 すると共に、 前記承認経路決定手段は、特定の一つの承認経路を適用すると決定したとき に、前記承認規則の結果の適用により前記承認規則を参照して前記承認経路を 決定するソフトウェアシステム。 23．請求項１のソフトウェアシステムであり、 記承認規則データベースが、必要な承認者が要請書を連続的に承認せねばな らず、且つ要請書が連続的に承認し得る場合の序列規定を含むと共に、 前記承認経路処理手段が、前記序列規定に応じて作動するソフトウェアシス テム。 24．請求項２６のシステムであり、前記承認経路処理手段が、前記承認経路に沿 った前記要請書記録の位置に応じて、前記要請書になすべき行為が要請される その位置に承認者がいることを通知する通知手段を含むシステム。 25．請求項２４のソフトウェアシステムであり、前記承認経路処理手段が、 承認者によりなされた行為の結果としての前記要請書の現状の変化を認識す る現状変化認識手段と、 前記現状変化認識手段に応答して作動して前記現状変化の要請者を通知する 通知手段とを含むソフトウェアシステム。 26．請求項１のソフトウェアシステムであり、 前記承認経路における特定の位置において前記承認者によりなされる行為が 、前記要請書の承認と拒絶とのうちの一方を含むと共に、 前記承認経路処理手段が、前記特定の位置で前記要請書を承認する前記承認 者に応じて、前記要請書を前記承認経路における次の位置へ移動させるソフト ウェアシステム。 27．請求項２６のソフトウェアシステムであり、 前記承認経路処理手段が、非応答処理手段を含み、この非応答処理手段は、 前記要請書が、前記承認経路における前記特定の位置において、その位置の前 記承認者により何の行為も為されずにおかれた時間に応じて、その何の行為も なさなかった承認者と所定の関係にある他の承認者へ前記要請書を移動させる ソフトウェアシステム。 28．請求項２６のソフトウェアシステムであり、 前記所定の関係が、ＥＲＰデータベースにおいて規定された一連のコマンド データにより示されると共に、 前記システムが、前記ＥＲＰデータベースからの一連のコマンドデータデー タにアクセスするためのＥＲＰアダプタを更に備えるソフトウェアシステム。 29．請求項２６のソフトウェアシステムであり、 前記承認経路における次の位置への前記要請書の移動に応じて、前記次の位 置において前記要請書に行為をなすことが要請される承認者を通知する通知手 段を更に備えるソフトウェアシステム。 30．請求項２６のソフトウェアシステムであり、 前記承認経路における特定の場所における前記承認者により為される行為が 、前記要請書記録の少なくとも一部を変更することを含むと共に、 前記承認処理手段が変更応答手段を含み、この変更応答手段は、要請書を変 更する承認者に応答して作動して、前記承認経路決定手段に前記変更された要 請書に応じた代替的な承認経路を決定させるソフトウェアシステム。 31．請求項１のシステムであり、前記承認経路処理手段が、非応答処理手段を含 み、この非応答処理手段は、要請者からの要請に応じて、何の行為もなさなか った第１の承認者から、この何の行為もなさなかった承認者と所定の関係にあ る第２の承認者へ前記要請書を移動させるシステム。 32．請求項３１のシステムであり、第１の承認者からの前記要請の移動に応じて 、前記承認経路処理手段が、第１の承認者が前記要請書に行為を為すことを防 止するシステム。 33．請求項３１のシステムであり、前記所定の関係が少なくとも部分的に前記承 認規則に規定されているシステム。 34．請求項１のシステムであり、 第１の承認者からの要請を受けて、前記承認経路が第１の承認者に代わって 第２の承認者を含むように、前記承認経路処理手段を構成することにより、第 ２の承認者に対する第１の承認者の権限を委任する権限委任手段を更に備える システム。